LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

Consolidated several sections together, hence the removal of several files. Creation of a seperate chapter on Layering 

Binh.
This commit is contained in:
binh 2005-02-09 13:29:44 +00:00
parent e54d6e945a
commit 28e0702f8c
18 changed files with 2824 additions and 3777 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
LDP/guide/docbook/Linux-Networking/DDS-Switched56.xml
View File

@ -1,21 +0,0 @@
<sect1 id="DDS-Switched56">
<title>DDS-Switched56</title>
<para>
DDS (Digital Data Service) and Switched 56 are types types of dedicated
digital line provided by phone carriers. DDS lines are more
expensive than dedicated analog lines, but support a more consistent quality.
DDS lines support a speed of 56 Kbps. A device called a CSU/DSU (Channel
Service Unit/Digital Service Unit) is used to connect the network to the
dedicated line.
</para>
<para>
Switched 56 is an alternative to DDS that provides the same type of
connection, but in a circuit-switched format. The line is available
on demand rather than continuously, and you are billed for the hours that
you use it. ISDN has largely replaced Switched 56 for this purpose.
</para>
</sect1>

10
LDP/guide/docbook/Linux-Networking/DECnet.xml
View File

@ -1,10 +0,0 @@
<sect1 id="DECnet">
<title>DECnet</title>
<para>
Support for DECnet is currently being worked on. You should expect it
to appear in a late 2.1.* kernel.
</para>
</sect1>

15
LDP/guide/docbook/Linux-Networking/DLC.xml
View File

@ -1,15 +0,0 @@
<sect1 id="DLC">
<title>DLC</title>
<para>
DLC (Data Link Control) is a transport protocol developed by IBM for SNA
(System Network Architecture), a protocol suite for network communication
with mainframe computers. Particular versions of DLC are called SDLC
(Synchronous Data Link Control) and HDLC (High-level Data Link Control).
Along with its main uses in mainframe communication, DLC is the protocol
used by many network-aware printers such Hewlett-Packard's JetDirect
interface.
</para>
</sect1>

1110
LDP/guide/docbook/Linux-Networking/Diald.xml
View File

File diff suppressed because it is too large Load Diff

106
LDP/guide/docbook/Linux-Networking/EQL.xml
View File

@ -1,106 +0,0 @@
<sect1 id="EQL">
<title>EQL</title>
<para>
EQL provides a means of utilizing multiple point to point lines such
as PPP, SLIP or PLIP as a single logical link to carry TCP/IP. Often,
it is cheaper to use multiple lower speed lines than to have one high
speed line installed. In short, EQL is multiple line traffic equaliser.
</para>
<para>
EQL is integrated into the Linux kernel. The EQL device name is `eql'.
With the standard kernel source you may have only one EQL device per
machine.
</para>
<para>
<screen>
Kernel Compile Options:
Network device support --->
[*] Network device support
<*> EQL (serial line load balancing) support
</screen>
</para>
<para>
To support this mechanism the machine at the other end of the lines
must also support EQL. Linux, Livingstone Portmasters and newer dial-
in servers support compatible facilities.
</para>
<para>
To configure EQL you will need the EQL tools which are available from:
metalab.unc.edu.
</para>
<para>
Configuration is fairly straightforward. You start by configuring the
eql interface. The eql interface is just like any other network
device. You configure the IP address and mtu using the ifconfig
utility, so something like:
</para>
<para>
<screen>
root# ifconfig eql 192.168.10.1 mtu 1006
</screen>
</para>
<para>
Next you need to manually initiate each of the lines you will use.
These may be any combination of point to point network devices. How
you initiate the connections will depend on what sort of link they
are, refer to the appropriate sections for further information.
</para>
<para>
Lastly you need to associate the serial link with the EQL device, this
is called `enslaving' and is done with the eql_enslave command as
shown:
</para>
<para>
<screen>
root# eql_enslave eql sl0 28800
root# eql_enslave eql ppp0 14400
</screen>
</para>
<para>
The `estimated speed' parameter you supply eql_enslave doesn't do
anything directly. It is used by the EQL driver to determine what
share of the datagrams that device should receive, so you can fine
tune the balancing of the lines by playing with this value.
</para>
<para>
To disassociate a line from an EQL device you use the eql_emancipate
command as shown:
</para>
<para>
<screen>
root# eql_emancipate eql sl0
</screen>
</para>
<para>
You add routing as you would for any other point to point link, except
your routes should refer to the eql device rather than the actual
serial devices themselves, typically you would use:
</para>
<para>
<screen>
root# route add default eql
</screen>
</para>
<para>
The EQL driver was developed by Simon Janes, simon@ncm.com.
</para>
</sect1>

48
LDP/guide/docbook/Linux-Networking/Ethernet.xml
View File

@ -1,48 +0,0 @@
<sect1 id="Ethernet">
<title>Ethernet</title>
Ethernet
Ethernet is the most common network architecture worldwide. It was developed by Xerox,
Intel and DEC in the late 1960s and revised as Ethernet 2.0 in 1982. Ethernet networks
the CSMA/CD (carrier sense multiple access with collision detection) media access method,
defined in IEEE 802.3.
There are three Ethernet standards for different media:
See P41 of Oreilly "MSCE Networking"
10BaseT
10Base2
10Base5
Fast Ethernet
Fast Ethernet, also known as 100BaseT, is a new standard for 100 Mbps Ethernet. Fast Ethernet
can use two-pair Category 5 cable of four-pair Category 3-5 cable.
100BaseT uses a physical star topology identical to that used by 10BaseT, but requires that
all equipment (hubs, NICs, and repeaters) support 100 Mbps speeds. Some NICs and hubs can support
both standards, but all devices on the network need to be configured to use the same standard.
Several manufacturers devleloped 100 Mbps Ethernet devices before 100BaseT became a standard. The
most popular of these, 100VG-AnyLan, is still widely used. This standard uses a demand priority
access method rather than CSMA/CD, and also supports networks that combine Ethernet and Token
Ring packets.
> Start Binh
GigE
GigE Ethernet, also known as 1000BaseT or Gigabit Ethernet. GigE can only use Cat 5 cable.
GigE uses the same topology as that of Fast Ethernet (ie. physical star topology). Like Fast Ethernet
though it requires that hubs/switches on the LAN to be GigE capable. If not it will revert back to
100BaseT, and if this is not available to 10BaseT Ethernet.
> End Binh
* Ethernet-Howto
</sect1>

58
LDP/guide/docbook/Linux-Networking/FDDI.xml
View File

@ -1,58 +0,0 @@
<sect1 id="FDDI">
<title>FDDI</title>
<para>
FDDI (Fiber Distributed Data Interface) is a high-speed, reliable, long-distance
networking scheme often used for network backbones and networks that require
high bandwidth. FDDI uses fiber optic cable wired in a true ring. It supports
speeds up to 100 Mbps and a maximum distance bewteen nodes of 100 kilometers
(62 miles).
</para>
<para>
FDDI uses token-passing scheme wired into two rings, primary and secondary. The
primary ring is used for normal networking. When a failure is detected, the
secondary ring is used in the opposite direction to compensate for the failure
in the primary ring.
</para>
<para>
The advantages of FDDI are their high speed, long distance, and reliablity.
The token-passing scheme used by FDDI is also more sophisticated than that
of Token Ring: it allows multiple packets to be on the ring at once, and
allows certain nodes to be given higher priority than the rest. The
disadvantage of FDDI is its high cost and the difficult in installing and
maintaing fiber optic cable.
</para>
<para>
FDDI device names are `fddi0', `fddi1', `fddi2' etc. The first card
detected by the kernel is assigned `fddi0' and the rest are assigned
sequentially in the order they are detected.
</para>
<para>
Larry Stefani, lstefani@ultranet.com, has developed a driver for the
Digital Equipment Corporation FDDI EISA and PCI cards.
</para>
<para>
When you have your kernel built to support the FDDI driver and
installed (the compilation options are given below), configuration
of the FDDI interface is virtually identical to that of an ethernet
interface. You just specify the need to replace the Ethernet interface
names with appropriate FDDI interface names in the ifconfig and route commands.
</para>
<para>
<screen>
Kernel Compile Options:
Network device support --->
[*] FDDI driver support
[*] Digital DEFEA and DEFPA adapter support
</screen>
</para>
</sect1>

262
LDP/guide/docbook/Linux-Networking/Frame-Relay.xml
View File

@ -1,262 +0,0 @@
<sect1 id="Frame-Relay">
<title>Frame-Relay</title>
<para>
Frame relay is a protocol used with leased lines to support speeds up to
1.544 Mbps. Frame realy uses packet switching over a phone company's
network. Frame realy connections use a virtual circuit, called
a PVC (private virtual circuit), to establish connections. Once established,
connections use a low overhead and do not provide error correction.
</para>
<para>
A frame realy compatible router is used to attach the LAN to the frame
relay line. Frame relay lines are available in speeds ranging from 56 Kbps
to 1.544 Mbps, and varying proportionally in cost. One advantage of frame
relay is that bandwidth is available on demand: you can install a line
at 56 Kbps and later upgrade it to a higher speed by ordering the service
from the carrier, usually without replacing any equipment.
</para>
<para>
It was specifically designed and is well suited to data communications traffic
that is of a `bursty' or intermittent nature. You connect to a Frame Relay
network using a Frame Relay Access Device (FRAD). The Linux Frame Relay
supports IP over Frame Relay as described in RFC-1490.
</para>
<para>
The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI
encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s).
</para>
<para>
<screen>
Kernel Compile Options:
Network device support --->
<*> Frame relay DLCI support (EXPERIMENTAL)
(24) Max open DLCI
(8) Max DLCI per device
<*> SDLA (Sangoma S502/S508) support
</screen>
</para>
<para>
Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay
support and configuration tools.
</para>
<para>
Currently the only FRAD supported are the Sangoma Technologies S502A,
S502E and S508.
</para>
<para>
To configure the FRAD and DLCI devices after you have rebuilt your
kernel you will need the Frame Relay configuration tools. These are
available from ftp.invlogic.com. Compiling and installing the tools
is straightforward, but the lack of a top level Makefile makes it a
fairly manual process:
</para>
<para>
<screen>
user% tar xvfz .../frad-0.15.tgz
user% cd frad-0.15
user% for i in common dlci frad; make -C $i clean; make -C $i; done
root# mkdir /etc/frad
root# install -m 644 -o root -g root bin/*.sfm /etc/frad
root# install -m 700 -o root -g root frad/fradcfg /sbin
root# install -m 700 -o root -g root dlci/dlcicfg /sbin
</screen>
</para>
<para>
Note that the previous commands use sh syntax, if you use a csh
flavour instead (like tcsh), the for loop will look different.
</para>
<para>
After installing the tools you need to create an /etc/frad/router.conf
file. You can use this template, which is a modified version of one of
the example files:
</para>
<para>
<screen>
# /etc/frad/router.conf
# This is a template configuration for frame relay.
# All tags are included. The default values are based on the code
# supplied with the DOS drivers for the Sangoma S502A card.
#
# A '#' anywhere in a line constitutes a comment
# Blanks are ignored (you can indent with tabs too)
# Unknown [] entries and unknown keys are ignored
#
[Devices]
Count=1 # number of devices to configure
Dev_1=sdla0 # the name of a device
#Dev_2=sdla1 # the name of a device
# Specified here, these are applied to all devices and can be overridden for
# each individual board.
#
Access=CPE
Clock=Internal
KBaud=64
Flags=TX
#
# MTU=1500 # Maximum transmit IFrame length, default is 4096
# T391=10 # T391 value 5 - 30, default is 10
# T392=15 # T392 value 5 - 30, default is 15
# N391=6 # N391 value 1 - 255, default is 6
# N392=3 # N392 value 1 - 10, default is 3
# N393=4 # N393 value 1 - 10, default is 4
# Specified here, these set the defaults for all boards
# CIRfwd=16 # CIR forward 1 - 64
# Bc_fwd=16 # Bc forward 1 - 512
# Be_fwd=0 # Be forward 0 - 511
# CIRbak=16 # CIR backward 1 - 64
# Bc_bak=16 # Bc backward 1 - 512
# Be_bak=0 # Be backward 0 - 511
#
#
# Device specific configuration
#
#
#
# The first device is a Sangoma S502E
#
[sdla0]
Type=Sangoma # Type of the device to configure, currently only
# SANGOMA is recognized
#
# These keys are specific to the 'Sangoma' type
#
# The type of Sangoma board - S502A, S502E, S508
Board=S502E
#
# The name of the test firmware for the Sangoma board
# Testware=/usr/src/frad-0.10/bin/sdla_tst.502
#
# The name of the FR firmware
# Firmware=/usr/src/frad-0.10/bin/frm_rel.502
#
Port=360 # Port for this particular card
Mem=C8 # Address of memory window, A0-EE, depending on card
IRQ=5 # IRQ number, do not supply for S502A
DLCIs=1 # Number of DLCI's attached to this device
DLCI_1=16 # DLCI #1's number, 16 - 991
# DLCI_2=17
# DLCI_3=18
# DLCI_4=19
# DLCI_5=20
#
# Specified here, these apply to this device only,
# and override defaults from above
#
# Access=CPE # CPE or NODE, default is CPE
# Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
# Clock=Internal # External or Internal, default is Internal
# Baud=128 # Specified baud rate of attached CSU/DSU
# MTU=2048 # Maximum transmit IFrame length, default is 4096
# T391=10 # T391 value 5 - 30, default is 10
# T392=15 # T392 value 5 - 30, default is 15
# N391=6 # N391 value 1 - 255, default is 6
# N392=3 # N392 value 1 - 10, default is 3
# N393=4 # N393 value 1 - 10, default is 4
#
# The second device is some other card
#
# [sdla1]
# Type=FancyCard # Type of the device to configure.
# Board= # Type of Sangoma board
# Key=Value # values specific to this type of device
#
# DLCI Default configuration parameters
# These may be overridden in the DLCI specific configurations
#
CIRfwd=64 # CIR forward 1 - 64
# Bc_fwd=16 # Bc forward 1 - 512
# Be_fwd=0 # Be forward 0 - 511
# CIRbak=16 # CIR backward 1 - 64
# Bc_bak=16 # Bc backward 1 - 512
# Be_bak=0 # Be backward 0 - 511
#
# DLCI Configuration
# These are all optional. The naming convention is
# [DLCI_D<devicenum>_<DLCI_Num>]
#
[DLCI_D1_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=64
# Bc_fwd=512
# Be_fwd=0
# CIRbak=64
# Bc_bak=512
# Be_bak=0
[DLCI_D2_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=16
# Bc_fwd=16
# Be_fwd=0
# CIRbak=16
# Bc_bak=16
# Be_bak=0
</screen>
</para>
<para>
When you've built your /etc/frad/router.conf file the only step
remaining is to configure the actual devices themselves. This is only
a little trickier than a normal network device configuration, you need
to remember to bring up the FRAD device before the DLCI encapsulation
devices. These commands are best hosted in a shell script, due to
their number:
</para>
<para>
<screen>
#!/bin/sh
# Configure the frad hardware and the DLCI parameters
/sbin/fradcfg /etc/frad/router.conf || exit 1
/sbin/dlcicfg file /etc/frad/router.conf
#
# Bring up the FRAD device
ifconfig sdla0 up
#
# Configure the DLCI encapsulation interfaces and routing
ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
route add -net 192.168.10.0 netmask 255.255.255.0 dlci00
#
ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
route add -net 192.168.11.0 netmask 255.255.255.0 dlci00
#
route add default dev dlci00
#
</screen>
</para>
</sect1>

65
LDP/guide/docbook/Linux-Networking/IPX.xml
View File

@ -1,65 +0,0 @@
<sect1 id="IPX">
<title>IPX</title>
<para>
IPX and SPX are proprietary protocols that were developed during the
early 1980s by Novell for use in NetWare networks.
NetWare became the de facto standard network operating system (NOS) of
first generation LANs. Novell complemented its NOS with a
business-oriented application suite and client-side connection utilities.
They were based on protocols used in Xerox's XNS (Xerox Network Systems)
network architecture.
IPX (Internetwork Packet Exchange) is a connectionless protocol that works
at the network layer of the OSI model, and SPX (Sequenced Packet Exchange)
is a connection-orientated protocol that works at the transport layer.
</para>
<para>
These protocols are often easier to configure than TCP/IP and are routable,
so they make a good alternative for some networks, particularly small
peer-to-peer networks. However, TCP/IP is more suitable for larger
LANs and WANs.
</para>
<para>
Frame types are one aspect of IPX networks that sometimes does require
configuration. The frame type determines the order and type of data included
in the packet. Typical frame types used in NetWare networks
802.2 and 802.3.
</para>
<para>
Linux has a very clean IPX/SPX implementation, allowing it to be
configured as an:
· IPX router
· IPX bridge
· NCP client and/or NCP Server (for sharing files)
· Novell Print Client, Novell Print Server
And to:
· Enable PPP/IPX, allowing a Linux box to act as a PPP server/client
· Perform IPX tunnelling through IP, allowing the connection of two
IPX networks through an IP only link
</para>
How do I configure the kernel for IPX networking support?
<para>
<screen>
IPX ( AF_IPX )
Kernel Compile Options:
Networking options --->
[*] The IPX protocol
[ ] Full internal IPX network
</screen>
</para>
* IPX-SPX HOWTO
</sect1>

100
LDP/guide/docbook/Linux-Networking/IPv6.xml
View File

@ -1,100 +0,0 @@
<sect1 id="IPv6">
<title>IPv6</title>
<para>
2.1. What is IPv6?
IPv6, sometimes also referred to as IPng (IP Next Generation)
is a new layer 3 protocol (see [http://www.linuxports.com/howto/
intro_to_networking/c4412.htm#PAGE103HTML] linuxports/howto/
intro_to_networking/ISO - OSI Model) which will supersede IPv4 (also known as
IP).
It was designed to address many issues including, the shortage of
available IP addresses, lack of mechanisms to handle time-sensitive
traffic, lack of network layer security, etc.
IPv4 was designed long time ago ([http://www.faqs.org/rfcs/rfc760.html]
RFC 760 / Internet Protocol from January 1980) and since its inception, there
have been many requests for more addresses and enhanced capabilities. Latest
RFC is [http://www.faqs.org/rfcs/rfc2460.html] RFC 2460 / Internet Protocol
Version 6 Specification. Major changes in IPv6 are the redesign of the
header, including the increase of address size from 32 bits to 128 bits.
Because layer 3 is responsible for end-to-end packet transport using packet
routing based on addresses, it must include the new IPv6 addresses (source
and destination), like IPv4. It is anticpated that the larger name space
and accompanying improved addressing scheme, which will prove to provide
a major improvement on routing performance.
For more information about the IPv6 history take a look at older IPv6 related
RFCs listed e.g. at [http://www.switch.ch/lan/ipv6/references.html] SWITCH
IPv6 Pilot / References.
-----------------------------------------------------------------------------
2.2. History of IPv6 in Linux
The years 1992, 1993 and 1994 of the IPv6 History (in general) are covered by
following document: [http://www.laynetworks.com/users/webs/IPv6.htm#CH3] IPv6
or IPng (IP next generation).
To-do: better time-line, more content...
-----------------------------------------------------------------------------
2.2.1. Beginning
The first IPv6 related network code was added to the Linux kernel 2.1.8 in
November 1996 by Pedro Roque. It was based on the BSD API:
diff -u --recursive --new-file v2.1.7/linux/include/linux/in6.h
¬ linux/include/linux/in6.h
--- v2.1.7/linux/include/linux/in6.h Thu Jan 1 02:00:00 1970
+++ linux/include/linux/in6.h Sun Nov 3 11:04:42 1996
@@ -0,0 +1,99 @@
+/*
+ * Types and definitions for AF_INET6
+ * Linux INET6 implementation
+ * + * Authors:
+ * Pedro Roque <******>
+ *
+ * Source:
+ * IPv6 Program Interfaces for BSD Systems
+ * <draft-ietf-ipngwg-bsd-api-05.txt>
The shown lines were copied from patch-2.1.8 (e-mail address was blanked on
copy&paste).
-----------------------------------------------------------------------------
2.2.2. In between
Because of lack of manpower, the IPv6 implementation in the kernel was unable
to follow the discussed drafts or newly released RFCs. In October 2000, a
project was started in Japan, called [http://www.linux-ipv6.org/] USAGI,
whose aim was to implement all missing, or outdated IPv6 support in Linux. It
tracks the current IPv6 implementation in FreeBSD made by the [http://
www.kame.net/] KAME project. From time to time they create snapshots against
current vanilla Linux kernel sources.
-----------------------------------------------------------------------------
2.2.3. Current
Unfortunately, the [http://www.linux-ipv6.org/] USAGI patch is so big, that
current Linux networking maintainers are unable to include it in the
production source of the Linux kernel 2.4.x series. Therefore the 2.4.x
series is missing some (many) extensions and also does not confirm to all
current drafts and RFCs (see [http://www.ietf.org/html.charters/
ipv6-charter.html] IP Version 6 Working Group (ipv6) Charter). This can cause
some interoperability problems with other operating systems.
-----------------------------------------------------------------------------
2.2.4. Future
[http://www.linux-ipv6.org/] USAGI is now making use of the new Linux kernel
development series 2.5.x to insert all of their current extensions into this
development release. Hopefully the 2.6.x kernel series will contain a true
and up-to-date IPv6 implementation.
-----------------------------------------------------------------------------
</sect1>

141
LDP/guide/docbook/Linux-Networking/Layering.xml Normal file
View File

@ -0,0 +1,141 @@
<sect1 id="Foreward">
<title>Foreward</title>
<para>
Using a virtual machine concept, each layer is a virtual machine, with layer
one being the real machine. The top layer provides the highest level
functionality or the functions that are most abstracted from the physical
world. The top layer is directly interpreted by human beings. The bottom layer
provides the lowest level functionality, ie. it is strongly related to the
physical world and (preferably) is not interpreted by human beings.
In a layered model, entities forming the corresponding layers on different machines are
called peers and protocols forms a central part of network software. The layered approach
to networks and general software engineering principles adopted add to the structure
of network software. Each layer performs a small set of well defined functions (services)
required by the layer above it.
The layered approach offers a communication setting where layer n on one machine can have a
conversation with layer n on the other mahine. Layer n-protocol is essentially a set of rules
and conventions facilitating this conversation. This includes addressing and specification of
necessary DU's (Data Units).
You should note that this communication between layers is virtual. There is no physical or
direct communication between layers of two layer-n hosts. The actual communication takes
place at the lowest layer (usually called the physical layer). The conglomeration of layers
and corresponding layer protocols form a network architecture.
The general consensus in computing is that a typical data unit exchanged between systems
should consist of the address of the transmitting computer, the address of the receiving
computer, the actual data being transmitted, as well as a checksum.
This leads us to the problem of addressing. In order for computers to communicate properly
it was generally agreed by Ethernet card manufacturers that all NIC cards would possess a
48 bit unique address. This is called a MAC address but is often called the hardware address
of these cards. This aids portability and modularity of LAN (Local Area Network) technology and
software to a major extent. The data units here are called as frames. This is all you need
really to have a small network.
However, there exists a fundamental problem if you were to extend this idea to larger systems
(ie. greater than 100 nodes). It is extremely difficult to keep track of and maintain such a
network due to administrators having to keep track of the name of each and every system and
deciding what the name of new computers on the network will be.
For this reason, the idea of hostnames and network addresses were developed. For example,
on the LAN a computer may be called "computer" but on the internet it may be referred to
as "computer.network.com". The idea behind network addressing came to be known simply now
as IP (Internet Prococol) addressing.
You could say that the idea behind computer network addressing is roughly synonymous with that
of the rather mundane telephone network. To call a number in your region all you have to do
is dial that number. To call a number in another state you must add a number of other digits
to the start of the number. To call a number that is overseas you must add further digits
to the beginning of the now burgeoning number. The only difference between telephone and
network addressing is that you add numbers to the front rather than at the end of the address.
To this day, it has been found that by utilising so called layer architecture for networks,
suitable protocols and appropriate communication technologies the issues of network
application interfacing, network addressing and network functionality can be addressed
successfully.
There are eight main network technology issues that must be addressed at each layer in the
architecture though. These are outlined below:
1. Mechanism of identifying senders and receivers: addressing.
2. Rules for data transfer: simplex, half-duplex, or full-duplex.
3. Logical channels: sharing a link among a number of connections.
4. Error control strategies: correction and detection.
5. Sequencing protocols for the correct order of messages: put messages in the correct order.
6. Incompatible speed between fast sender and slow receiver.
7. Message fragmentation and assembly.
8. Strategies for choosing routes.
To study the above issues in detail please consult, Tannenbaum 4th edition.
These design issues become recurring themes that are usually addressed by each and every
layer in the architecture. As a stark example, although error detection and correction is
undertaken by the low level transmission protocol that sends characters from a terminal
to the display, the user will also implement error detection and correction at the highest
level by deleting an incorrect character and retyping.
A concept of an interface is central to layered network architecture. It is important
to recognise implementation and design issues and pertaining to interfaces of layers
and their respective functions and services.
- entity: in software, it is sometimes called a process; in hardware in hardware it
could mean in pratice an I/O chip
- peer enties: entities at the same layer in different machines/devices
- service provider: eg. layer n, a layer that provides a service
- service receiver: eg. layer n + 1, a layer that receives a service
- service access point (SAP): a point where service is accessed, for example a
function call in software, or the telephone for a telephone company
- protocol data unit (PDU): a data unit that is communicated between peer entities
- service data unit (SDU): the PDU from the serice receiver
- protocol control information (PCI): is appended by a service receiver to an SDU
in order to indicated the type of service required and forms the IDU
- interface data unit (IDU): the data unit that is given from a service receiver to
a service provider.
The term "service" can be deemed to mean a number of things. These are outlined
below.
Quality of Service: each service is chractereised by a quality of service. For example,
reliable service by such applications as file transfer - the data must be delivered
correctly but it may be unusually delayed. However, voice and video transmission may
allow some error in the data but does not allow delayed data.
Connection and connectionless services are the two fundamental categories. The
distinctions between them may be intuitive but there are subtle differences. For
example, a connection-orientated services allows two communicating parties to make
use of the connection in any way they like - a telephone connection can even be
used for transmitting fax and digital information as the service provider doesn't
process the communication at any point through the network.
However a connectionless services does not provide such a convenience because
for example a letter may be packaged and processed along the way, being stamped
for accounting, delivered using a car or plane, etc....
A service is formally specified by a set of primitives (operations) that define
the service interface. The primitives differ for different services. As a simple
example, a service may provide the following primitives:
1. LISTEN: listen for an incoming communication request
2. CONNECT: make a communication request
3. RECEIVE: receive data of a communication
4. SEND: send data of a communication
5. DISCONNECT: disconnect or discontinue a communication
As discussed before, each layer has specfic functions and offers certain services
to the layer above it. A service is a set of primitives (operations) that a layer
provides to the layer above it. In the definition of services, we do not specify
their implementation. The implementation is only visible to the provider of the
service.
A protocol defines the implementation of the service and is not visible to the
user of the service. A protocol is a set of rules governing the format and
meaning of the frames, packets, or messages within a layer and can be changed
at will by entities, provided that they do not change the service visible to their
users.
</sect1>

487
LDP/guide/docbook/Linux-Networking/Leased-Line.xml
View File

@ -1,487 +0,0 @@
<sect1 id="Leased-Line">
<title>Leased-Line</title>
_______________________________________________________________________________
<sect>
<para>
Configuring your modem and pppd to use a 2 wire twisted pair leased
line.
</para>
1.2. What is a leased line
<para>
Any fixed, that is permanent, point to point data communications link,
which is leased from a telco or similar organisation. The leased line
involves cables, such as twisted pair, coax or fiber optic, and may
involve all sorts of other hardware such as (pupin) coils,
transformers, amplifiers and regenerators.
</para>
<para>
This document deals with:
Configuring your modem and pppd to use a 2 wire twisted pair
leased line.
</para>
<para>
This document does NOT deal with:
SLIP, getting or installing pppd, synchronous data
communication, baseband modems, xDSL.
</para>
1.3. Assumptions
<para>
You should already have a working pppd on your system. You also need
Minicom or a similar program to configure your modems.
</para>
2. Modem
<para>
A leased line is not connected to a telephone exchange and does not
provide DC power, dial tone, busy tone or ring signal. This means that
your modems are on their own and have to be able to deal with this
situation.
</para>
<para>
You should have 2 identical (including firmware version) external
modems supporting both leased line and dumb mode. Make sure your
modems can actually do this! Also make sure your modem is properly
documented. You also need:
</para>
· 2 fully wired shielded RS232 cables. The shield should be connected
to the connector shell (not pin 1) at both ends (not at one end).
· A RS232 test plug may be handy for test purposes.
· 2 RJ11 cords, one for each end of the leased line.
· A basic understanding of `AT' commands.
2.1. Modem Configuration
<para>
A note on modem configuration and init strings in general: Configure
your modem software such as minicom or (m)getty to use the highest
possible speed; 57600 bps for 14k4 and 115200 bps for 28k8 or faster
modems. Lots of people use very long and complicated init strings,
often starting with AT&F and containing lots of modem brand and -type
specific commands. This however is needlessly complicated. Most
programs feel happy with the same modem settings, so why not write
these settings in the non volatile memory of all your modems, and only
use `ATZ' as an init string in all your programs. This way you can
swap or upgrade your modems without ever having to reconfigure any of
your software.
</para>
<para>
Most programs require you to use the following settings;
</para>
· Fixed baud rate (no auto baud)
· Hardware bidirectional RTS-CTS flow control (no x-on/x-off)
· 8 Bits, no parity, 1 stopbit
· The modem should produce the TRUE DCD status (&C1)
· The modem should NOT ignore the DTR status (&D2 or &D3)
<para>
Check this with AT&V or AT&Ix (consult your modem documentation)
</para>
<para>
These settings are not necessarily the same as the default factory
profile (&F), so starting an init string with AT&F is probably not a
good idea in the first place. The smart thing to do is probably to use
AT&F only when you have reason to believe that the modem setup stored
in the non volatile memory is really screwed up. If you think you
have found the right setup for your modems, write it to non volatile
memory with AT&W and test it thoroughly with Z-modem file transfers of
both ASCII text and binary files. Only if all of this works perfectly
should you configure your modems for leased line.
</para>
<para>
Find out how to put your modem into dumb mode and, more importantly,
how to get it out of dumb mode; The modem can only be reconfigured
when it is not in dumb mode. Make sure you actually configure your
modems at the highest possible speed. Once in dumb mode it will
ignore all `AT' commands and consequently will not adjust its speed to
that of the COM port, but will use the speed at which it was
configured instead (this speed is stored in a S-register by the AT&W
command).
</para>
<para>
Now configure your modem as follows;
</para>
· Reset on DTR toggle (&D3, this is sometimes a S register). This
setting is required by some ISP's!
· Leased line mode (&L1 or &L2, consult your modem documentation)
· The remote modem auto answer (S0=1), the local originate (S0=0)
· Disable result codes (Q1, sometimes the dumb mode does this for
you)
· Dumb mode (\D1 or %D1, this is sometimes a jumper) In dumb mode the
modem will ignore all AT commands (sometimes you need to disable
the ESC char as well).
<para>
Write the configuration to non-volatile memory (&W).
</para>
2.2. Test
<para>
Now connect the modems to 2 computers using the RS232 cables and
connect the modems to each other using a RJ11 lead. Use a modem
program such as Minicom (Linux), procom or telix (DOS) on both
computers to test the modems. You should be able to type text from
one computer to the other and vice versa. If the screen produces
garbage check your COM port speed and other settings. Now disconnect
and reconnect the RJ11 cord. Wait for the connection to reestablish
itself. Disconnect and reconnect the RS232 cables, switch the modems
on and off, stop and restart Minicom. The modems should always
reconnect at the highest possible speed (some modems have speed
indicator leds). Check whether the modems actually ignores the ESC
(+++) character. If necessary disable the ESC character.
</para>
<para>
If all of this works you may want to reconfigure your modems; Switch
off the sound at the remote modem (M0) and put the local modem at low
volume (L1).
</para>
2.3. Examples
2.3.1. Hi-Tech
<para>
This is a rather vague `no name clone modem'. Its config string is
however typical and should work on most modems.
</para>
<para>
Originate (local):
ATL1&C1&D3&L2%D1&W&W1
</para>
<para>
Answer (remote):
ATM0L1&C1&D3&L2%D1S0=1&W&W1
</para>
2.3.2. Tornado FM 228 E
<para>
This is what should work;
</para>
<para>
Originate (local):
ATB15L1Q1&C1&D3&L2&W&W1
</para>
<para>
Answer (remote):
ATM0B15M0Q1&C1&D3&L2S0=1&W&W1
</para>
<para>
Move the dumb jumper from position 2-3 to 1-2.
</para>
<para>
Due to a firmware bug, the modems will only connect after being hard
reset (power off and on) while DTR is high. I designed a circuit which
hard resets the modem on the low to high transition of DTR. The
FreeBSD pppd however, isn't very happy about this. By combining the
setting &D0 with a circuit which resets on the high to low transition
instead, this problem can be avoided.
</para>
2.3.3. Tron DF
<para>
The ESC char should be disabled by setting S2 > 127;
</para>
<para>
Originate:
ATL1&L1Q1&C1&D3S2=171\D1&W
</para>
<para>
Answer:
ATM0&L2Q1&C1&D3S0=1S2=171\D1&W
</para>
2.3.4. US Robotics Courier V-Everything
<para>
The USR Sportster and USR Courier-I do not support leased line. You
need the Courier V-everything version for this job. There is a
webpage on the USR site `explaining' how to set-up your Courier for
leased line. However, if you follow these instructions you will end up
with a completely brain dead modem, which can not be controlled or
monitored by your pppd.
</para>
<para>
The USR Courier can be configured with dip switches, however you need
to feed it the config string first. First make sure it uses the right
factory profile. Unlike most other modems it has three; &F0, &F1 and
&F2. The default, which is also the one you should use, is &F1. If you
send it an AT&F, however it will load the factory profile &F0! For
the reset on DTR toggle you set bit 0 of S register 13. This means you
have to set S13 to 1. Furthermore you need set it to leased line mode
with &L1; ATS13=1&L1&W The dip switches are all default except for the
following:
<para>
<para>
3 OFF Disable result codes
4 ON Disable offline commands
5 ON For originate, OFF For answer
8 OFF Dumb mode
</para>
3. PPPD
<para>
You need a pppd (Point to Point Protocol Daemon) and a reasonable
knowledge of how it works. Consult the relevant RFC's or the Linux PPP
HOWTO if necessary. Since you are not going to use a login procedure,
you don't use (m)getty and you do not need a (fake) user associated
with the pppd controlling your link. You are not going to dial so you
don't need any chat scripts either. In fact, the modem circuit and
configuration you have just build, are rather like a fully wired null
modem cable. This means you have to configure your pppd the same way
as you would with a null modem cable.
</para>
<para>
For a reliable link, your setup should meet the following criteria;
</para>
· Shortly after booting your system, pppd should raise the DTR signal
in your RS232 port, wait for DCD to go up, and negotiate the link.
· If the remote system is down, pppd should wait until it is up
again.
· If the link is up and then goes down, pppd should reset the modem
(it does this by dropping and then raising DTR), and then try to
reconnect.
· If the quality of the link deteriorates too much, pppd should reset
the modem and then reestablish the link.
· If the process controlling the link, that is the pppd, dies, a
watchdog should restart the pppd.
3.1. Configuration
<para>
Suppose the modem is connected to COM2, the local IP address is
`Loc_Ip' and the remote IP address is `Rem_Ip'. We want to use 576 as
our MTU. The /etc/ppp/options.ttyS1 would now be:
</para>
<para>
<screen>
crtscts
mru 576
mtu 576
passive
Loc_Ip:Rem_Ip
-chap
modem
#noauth
-pap
persist
</screen>
</para>
<para>
Stuff like `asyncmap 0', `lock', `modem' and `-detach' are probably
already in /etc/ppp/options. If not, add them to your
/etc/ppp/options.ttyS1. So, if the local system is 192.168.1.1 and
the remote system is 10.1.1.1, then /etc/ppp/options.ttyS1 on the
local system would be:
</para>
<para>
<screen>
crtscts
mru 576
mtu 576
passive
192.168.1.1:10.1.1.1
-chap
modem
#noauth
-pap
persist
</screen>
</para>
<para>
The options.ttyS1 on the remote system would be:
</para>
<para>
<screen>
crtscts
mru 576
mtu 576
passive
10.1.1.1:192.168.1.1
-chap
modem
#noauth
-pap
persist
</screen>
</para>
<para>
The passive option limits the number of (re)connection attempts. The
persist option will keep pppd alive in case of a disconnect or when it
can't connect in the first place. If you telnet a lot while doing
filetransfers (FTP or webbrowsing) at the same time, you might want to
use a smaller MTU and MRU such as 296. This will make the remote sys­
tem more responsive. If you don't care much about telnetting during
FTP, you could set the MTU and MRU to 1500. Keep in mind though, that
UDP cannot be fragmented. Speakfreely for instance uses 512 byte UDP
packets. So the minimum MTU for speakfreely is 552 bytes. The noauth
option may be necessary with some newer distributions.
</para>
3.2. Scripts
3.2.1. Starting the pppd and keeping it alive
<para>
You could start the pppd form a boot (rc) script. However, if you do
this, and the pppd dies, you are without a link. A more stable
solution, is to start the pppd from /etc/inittab;
</para>
<para>
<screen>
s1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200
</screen>
</para>
<para>
This way, the pppd will be restarted if it dies. Make sure you have a
`-detach' option (nodetach on newer systems) though, otherwise inittab
will start numerous instances of pppd, will complaining about
`respawning too fast'.
</para>
<para>
Note: Some older systems will not accept the speed `115200'. In this
case you will have to set the speed to 38400 en set the `spd_vhi' flag
with setserial. Some systems expect you to use a `cua' instead of
`ttyS' device.
</para>
3.2.2. Setting the routes
<para>
The default route can be set with the defaultroute option or with the
/etc/ppp/ip-up script;
</para>
<para>
<screen>
#!/bin/bash
case $2 in
/dev/ttyS1)
/sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0
;;
esac
</screen>
</para>
<para>
Ip-up can also be used to sync your clock using netdate.
</para>
<para>
Of course the route set in ip-up is not necessarily the default route.
Your ip-up sets the route to the remote network while the ip-up script
on the remote system sets the route to your network. If your network
is 192.168.1.0 and your ppp interface 192.168.1.1, the ip-up script on
the remote machine looks like this;
</para>
<para>
<screen>
#!/bin/bash
case $2 in
/dev/ttyS1)
/sbin/route add -net 192.168.1.0 gw 192.168.1.1 netmask 255.255.255.0
;;
esac
</screen>
</para>
<para>
The `case $2' and `/dev/ttyS1)' bits are there in case you use more
than one ppp link. Ip-up will run each time a link comes up, but only
the part between `/dev/ttySx)' and `;;' will be executed, setting the
right route for the right ttyS. You can find more about routing in
the Linux Networking HOWTO section on routing.
</para>
3.3. Test
<para>
Test the whole thing just like the modem test. If it works, get on
your bike and bring the remote modem to the remote side of your link.
If it doesn't work, one of the things you should check is the COM port
speed; Apparently, a common mistake is to configure the modems with
Minicom using one speed and then configure the pppd to use an other.
This will NOT work! You have to use the same speed all of the time!
</para>
</sect>
<sect>
T1-T4
<para>
A T1 line is a high-speed, dedicated, point-to-point leased line that
includes 24 seperate 64 Kbps channles for voice and data. Other lines
of this type, called T-carrier lines, support larger numbers of channels.
T1 and T3 lines are the most commonly used.
</para>
<para>
<screen>
Carrier Channels Total Bandwidth
T1 24 1.544 Mbps
T2 96 6.312 Mbps
T3 672 44.736 Mbps
T4 4032 274.176 Mbps
</screen>
</para>
<para>
While the specification for T-carrier lines does not mandate a particular
media type, T1 and T2 are typically carried on copper, and T3 and T4
typically use fiber optic media. DS1, DS2, DS3, and DS4 are an alternate
type of line equivalent to T1-T4, and typically use fiber optic media.
</para>
SONET (Synchronous Optical Network)
<para>
A leased-line system using fiber optic media to support data speeds up to
2.4 Gbps. SONET services are sold based on optical carier (OC) levels. OC
levels are calculated as multiples of the OC-1 speed, 51.840 Mbps. For
example, OC-3 level would correspond with a data speed of 155 Mbps and
OC-12 level would equate to a data transfer rate of 622 Mbps. OC-1 and
OC-3 are the most commonly used SONET lines.
</para>
</sect>

26
LDP/guide/docbook/Linux-Networking/NetBEUI.xml
View File

@ -1,26 +0,0 @@
<sect1 id="NetBEUI">
<title>NetBEUI</title>
<para>
NetBEUI (NetBIOS Extended User Interface) is a transport-layer protocol
developed by Microsoft and IBM. NetBEUI was mainly intended as a basic
protocol to support NetBIOS (Network Basic Input/Output System), the
Windows standard for workstation naming, communications, and file sharing.
</para>
<para>
NetBEUI is a fast protocol with a low overhead, which makes it a good
choice for small networks. However, it is a non-routable protocol.
Networks that use NetBEUI can be use bridges for traffic management,
but cannot use routers. Another disadvantage is its proprietary nature.
NetBEUI is supported by few systems other than Windows.
</para>
<para>
Although NetBEUI was developed by Microsoft and was the default protocol
for some operating systems (such as Windows for Workgroups and Windows 95),
Microsoft recommends TCP/IP over NetBEUI for most Windows NT networks.
</para>
</sect1>

192
LDP/guide/docbook/Linux-Networking/PLIP.xml
View File

@ -1,192 +0,0 @@
<sect1 id="PLIP">
<title>PLIP</title>
<para>
PLIP (Parallel Line IP), is like SLIP, in that it is used for
providing a point to point network connection between two machines,
except that it is designed to use the parallel printer ports on your
machine instead of the serial ports (a cabling diagram in included in
the cabling diagram section later in this document). Because it is
possible to transfer more than one bit at a time with a parallel port,
it is possible to attain higher speeds with the plip interface than
with a standard serial device. In addition, even the simplest of
parallel ports, printer ports, can be used in lieu of you having to
purchase comparatively expensive 16550AFN UART's for your serial
ports. PLIP uses a lot of CPU compared to a serial link and is most
certainly not a good option if you can obtain some cheap ethernet
cards, but it will work when nothing else is available and will work
quite well. You should expect a data transfer rate of about 20
kilobytes per second when a link is running well.
</para>
7.2. PLIP for Linux-2.0
<para>
PLIP device names are `plip0', `plip1 and plip2.
</para>
<para>
<screen>
Kernel Compile Options:
Network device support --->
<*> PLIP (parallel port) support
</screen>
</para>
<para>
The PLIP device drivers competes with the parallel device driver for
the parallel port hardware. If you wish to use both drivers then you
should compile them both as modules to ensure that you are able to
select which port you want to use for PLIP and which ports you want
for the printer driver. Refer to the ``Modules mini-HOWTO'' for more
information on kernel module configuration.
</para>
<para>
Please note that some laptops use chipsets that will not work with
PLIP because they do not allow some combinations of signals that PLIP
relies on, that printers don't use.
</para>
<para>
The Linux plip interface is compatible with the Crynwyr Packet Driver
PLIP and this will mean that you can connect your Linux machine to a
DOS machine running any other sort of tcp/ip software via plip.
</para>
<para>
In the 2.0.* series kernel the plip devices are mapped to i/o port and
IRQ as follows:
</para>
<para>
<screen>
device i/o IRQ
------ ----- ---
plip0 0x3bc 5
plip1 0x378 7
plip2 0x278 2
</screen>
</para>
<para>
If your parallel ports don't match any of the above combinations then
you can change the IRQ of a port using the ifconfig command using the
`irq' parameter (be sure to enable IRQ's on your printer ports in your
ROM BIOS if it supports this option). As an alternative, you can
specify ``io='' annd ``irq='' options on the insmod command line, if
you use modules. For example:
</para>
<para>
<screen>
root# insmod plip.o io=0x288 irq=5
</screen>
</para>
<para>
PLIP operation is controlled by two timeouts, whose default values are
probably ok in most cases. You will probably need to increase them if
you have an especially slow computer, in which case the timers to
increase are actually on the other computer. A program called
plipconfig exists that allows you to change these timer settings
without recompiling your kernel. It is supplied with many Linux
distributions.
</para>
<para>
To configure a plip interface, you will need to invoke the following
commands (or add them to your initialization scripts):
</para>
<para>
<screen>
root# /sbin/ifconfig plip1 localplip pointopoint remoteplip
root# /sbin/route add remoteplip plip1
</screen>
</para>
<para>
Here, the port being used is the one at I/O address 0x378; localplip
amd remoteplip are the names or IP addresses used over the PLIP cable.
I personally keep them in my /etc/hosts database:
</para>
<para>
<screen>
# plip entries
192.168.3.1 localplip
192.168.3.2 remoteplip
</screen>
</para>
<para>
The pointopoint parameter has the same meaning as for SLIP, in that it
specifies the address of the machine at the other end of the link.
</para>
<para>
In almost all respects you can treat a plip interface as though it
were a SLIP interface, except that neither dip nor slattach need be,
nor can be, used.
</para>
<para>
Further information on PLIP may be obtained from the ``PLIP mini-
HOWTO''.
</para>
7.3. PLIP for Linux-2.2
<para>
During development of the 2.1 kernel versions, support for the
parallel port was changed to a better setup.
</para>
<para>
<screen>
Kernel Compile Options:
General setup --->
[*] Parallel port support
Network device support --->
<*> PLIP (parallel port) support
</screen>
</para>
<para>
The new code for PLIP behaves like the old one (use the same ifconfig
and route commands as in the previous section, but initialization of
the device is different due to the advanced parallel port support.
</para>
<para>
The ``first'' PLIP device is always called ``plip0'', where first is
the first device detected by the system, similarly to what happens for
Ethernet devices. The actual parallel port being used is one of the
available ports, as shown in /proc/parport. For example, if you have
only one parallel port, you'll only have a directory called
/proc/parport/0.
</para>
<para>
If your kernel didn't detect the IRQ number used by your port,
``insmod plip'' will fail; in this case just write the right number to
/proc/parport/0/irq and reinvoke insmod.
</para>
<para>
Complete information about parallel port management is available in
the file Documentation/parport.txt, part of your kernel sources.
</para>
· PLIP information can be found in The Network Administrator Guide
<http://metalab.unc.edu/mdw/LDP/nag/nag.html>
PLIP allows the cheap connection of two machines.
It uses a parallel port and a special cable, achieving speeds of
10kBps to 20kBps.
</sect1>

16
LDP/guide/docbook/Linux-Networking/PPP-and-SLIP.xml
View File

@ -1,16 +0,0 @@
<sect1 id="PPP-and-SLIP">
<title>PPP and SLIP</title>
<para>
The Linux kernel has built-in support for PPP (Point-to-Point-
Protocol) and SLIP (Serial Line IP). PPP is the most popular
way individual users access their ISPs (Internet Service
Providers).
· Linux PPP HOWTO <http://metalab.unc.edu/mdw/HOWTO/PPP-HOWTO.html>
· PPP/SLIP emulator <http://metalab.unc.edu/mdw/HOWTO/mini/SLIP-PPP-
Emulator.html>
</sect1>

2683
LDP/guide/docbook/Linux-Networking/Protocols-and-Standards.xml
View File

File diff suppressed because it is too large Load Diff

1219
LDP/guide/docbook/Linux-Networking/Token-Ring.xml
View File

File diff suppressed because it is too large Load Diff

42
LDP/guide/docbook/Linux-Networking/X25.xml
View File

@ -1,42 +0,0 @@
<sect1 id="X25">
<title>X25</title>
<para>
X.25 is a circuit based protocol developed in the 1970s for packet switching
by the C.C.I.T.T. (a standards body recognized by Telecommunications
companies in most parts of the world), allowing customers to share access to
a PDN (Public Data Network). These networks, such as Sprintnet and Tymnet,
were the most practical way to connect large companies at the time,
and are still used by some companies. PDNs are networks that have local
dial-up access points in cities throughout the country and use dedicated lines
to network between these cities. Companies would dial up in two locations to
connect their computers.
</para>
<para>
Computers, routers, or other devices that access a PDN using the X.25
protocols are called data terminal equipment, or DTEs. DTEs without built-in
support for X.25 is a protocol with a relatively high overhead, since it
provides error control and accounting for users of the network.
</para>
<para>
The X.25 protocol supports speeds up to 64 Kbps. This makes it impractical for
many networks, but it is an inexpensive alternative for low-bandwidth
applications. X,25 is a protocol with a relatively high overhead, since it
provides error control and accouting for users of the network.
</para>
<para>
An implementation of X.25 and LAPB are being worked on and recent
2.1.* kernels include the work in progress. Jonathon Naylor
jsn@cs.nott.ac.uk is leading the development and a
mailing list has been established to discuss Linux X.25 related
matters. To subscribe send a message to: majordomo@vger.rutgers.edu
with the text "subscribe linux-x25" in the body of the message.
Early versions of the configuration tools may be obtained from
Jonathon's ftp site at ftp.cs.nott.ac.uk.
</para>
</sect1>