Data Communications With Voip

Data Communication w/
Emphasis of VOIP
(COMP 22)
Encoded by: arfel c. arcabal
Prepared by: marl t. gonzalez
PHASE I: DATA COMMUNICATION
1
F.C. Ledesma Avenue, San Carlos City, Negros Occidental
Tel. #: (034) 312-6189 / (034) 729-4327
What is Data Communication?
The distance over which data moves within a computer may vary from a few
thousandths of an inch, as is the case within a single IC chip, to as much as several
feet along the backplane of the main circuit board. Over such small distances, digital
data may be transmitted as direct, two-level electrical signals over simple copper
conductors. Except for the fastest computers, circuit designers are not very concerned
about the shape of the conductor or the analog characteristics of signal transmission.
Frequently, however, data must be sent beyond the local circuitry that constitutes a
computer. In many cases, the distances involved may be enormous. Unfortunately, as
the distance between the source of a message and its destination increases, accurate
transmission becomes increasingly difficult. This results from the electrical distortion of
signals traveling through long conductors, and from noise added to the signal as it
propagates through a transmission medium. Although some precautions must be taken
for data exchange within a computer, the biggest problems occur when data is
transferred to devices outside the computer's circuitry. In this case, distortion and noise
can become so severe that information is lost.
Data Communications concerns the transmission of digital messages to devices external

to the message source. "External" devices are generally thought of as being
independently powered circuitry that exists beyond the chassis of a computer or other
digital message source. As a rule, the maximum permissible transmission rate of a
message is directly proportional to signal power and inversely proportional to channel
noise. It is the aim of any communications system to provide the highest possible
transmission rate at the lowest possible power and with the least possible noise.
Lesson I:
2
Tel. #: (034) 312-6189 / (034) 729-4327
Reference Models
· ISO OSI reference model
A set of protocol is open if:
· Protocol details are publicly available

· Changes are managed by an organization whose membership and transactions are open
to the public.
A system that implements open protocols is called an open system.
International Organization for Standards (ISO) prescribes a standard to connect open systems
· Open system interconnect (OSI)
Figure 6: The (OSI) Seven Layer Model
Physical Layer
Specification of voltage levels, cables, connectors, timing of bots, electrical access and
maintenance of circuit (i.e. corresponds to the basic hardware).
Data Link Layer
Transforms basic physical services to enable the transmission of units of data called frames.
Frames carry data between two points on the same type of physical network, and maybe
relayed if the network is extended. They normally contain low level addressing information and
3
Tel. #: (034) 312-6189 / (034) 729-4327
some error checking. This layer may be involved in arbitrating access to the physical network.
The Data Link Layer detects, and possibly corrects errors in the physical layer.
Network
Controls routing of data by providing an address domain, and in consequence the routing of
messages. This addressing is separate from the hardware which implements the network
connections, i.e. specifies how addresses are assigned and who packets are forwarded from one
end of the network to another.
Transport
Provides an interface for the upper layers to communication facilities. The presence of this layer
obscures the underlying network hardware and topology from the applications. A very complex
set of protocols are required for this layer!
Session
The protocols for this year specify how to establish a communication session with a remote
system (e.g., How to login to a remote timesharing computer). Specifications for security details
such as authentication using passwords are described in this layer.
Presentation
Layer 6 protocols specify how to represent data. Such protocols are needed because different
brands of computer use different internal representation for integer and characters. Thus layer 6
protocols are needed to translate from the representation on one computer to the representation
on another.
Application Layer
This is where the application using the network resides. Common network applications include
remote login, file transfer, e-mail, and web page browsing.
Internet Protocol Suite

The internet protocol suite, commonly referred to as TCP/IP, was developed about 25
years ago by DARPA for the ARPANET. The goal of the TCP/IP is to interconnect existing, often
dissimilar, networks. Fundamental structure is a packet switched system in which distinct
networks are connected by store-and-forward routers. The Internet Protocols are used in the
Internet. The Table below compares the TCP/IP protocol with the OSI.
4
Tel. #: (034) 312-6189 / (034) 729-4327
Transport Control Protocol (TCP)
This layer creates a connection between sender receiver using port numbers. This layer can
ensure that the receiver is not overrun with data (end-to-end flow control). TCP can multiplex
multiple connections (using port numbers) over a single IP line. TCP can perform end-to-end
error correction.
Internet Protocol (IP)
Allows for the sending of high priority data. IP prepares a packet for transmission across the
Internet. The IP header is encapsulated onto a transport data packet. The IP packet is then
passed to the next layer where further network information is encapsulated onto it.
· IP addresses are represented by 32-bit unsigned binary values.

· Normally expressed in a dotted decimal format: 168.167.8.3 is a valid IP address.
· The numeric form is used by IP software. The mapping between numeric IP address and
easy-to-read symbolic name (mopipi.ub.bw) is done by the Domain Name System (DNS)
The Application Layer
The purpose of the application layer is to allow two application programs on different hosts to
work together.
The Transport Layer
The purpose of the transport layer is to allow two host computers to talk to one another even if
they have very different internal designs, such as a PC and a workstation server.
The Internet Layer
The purpose of the internet layer is to route packets from the source host to the destination host
across one or more networks connected by routers. TCP required the use of the Internet
Protocol (IP) at the internet layer.
The Network Interface Layer
The purpose of this layer is to govern the movement of messages from a source station to a
destination station or router across a single network containing switches.
And to govern the transmission of bits one at a time over a wire, radio, or other connection
between station and a switch, between pairs of switches, or between a switch and a router.
5
Tel. #: (034) 312-6189 / (034) 729-4327
Below is a diagram of Internet protocol examples. The first column shows the TCP/IP layers. The
other two columns indicate example protocol stacks that are commonly used in market.
Organization of the Internet
· A handful of network service provider (NSPs) (e.g. BT) maintain a series of

nationwide links
· Links are like pipes- data flows through the pipes.
· NSPs are continually adding links with extra capacity to cater for increased Internet
use
Individually, we connect to the Internet via an ISP (Internet Service Provider) which in turn
connects to the backbone.
The setup below shows a typical Internet. Users (PC’s or Terminals) connect to an (Internet
Service Provider)ISP. The ISP in turn connects to the Network Service Provider (NSP).
Figure 9: Typical Set-up of the Internet

Internet Service Providers (ISPs)
Some are free – although many charge a monthly fee
Requirements
· Computer
· Modem
6
Tel. #: (034) 312-6189 / (034) 729-4327
· Phone line
A normal phone line does not provide particularly fast access to the internet – 56K bps
World Wide Web
This is a particular part of the internet which allows users to view information stored on
participating computers
Information is stored on pages which can be accessed directly, or via hypertext links
Who controls the Internet?
Although there is no overall governing body to issue regulations and directives for the internet,
The Internet Society (ISOC) serves as the standardizing body for the internet community. ISOC
is organized and managed by the Internet Architecture Board (IAB). The IAB on the one hand
relies on the Internet Engineering Task Force (IETF) for issuing new standards, and the Internet
Assigned Numbers Authority (IANA) for coordinating values shared among multiple protocols.
The Request For Comment (RFC) editor is responsible reviewing and publishing new standards
documents.
The IETF is itself governed by the Internet Engineering Steering Group (IESG), and it is further
divided into areas and working groups where new specs are discussed and new standards
proposed. The Internet Standards Process (in RFC 2026) is concerned with all protocols,
procedures and conventions that are used by the Internet.
Standardization Process
To have new standard approved:
Applicants submit the spec to IESG where it will de discussed and reviewed
· On positive conclusion by IESG:
They issue a last call notification to allow spec to be reviewed by Internet community
· Final approval by IESG
Internet draft is recommended to IETF for publication as RFC
Voice Over IP (VoIP)
VoIP can simply be defined as the transmission of voice over IP networks. Originating and
Terminating devices can be traditional telephones, fax machine and multimedia PC’s, etc.
Generally based on the following technology. VoIP gateways that provide enterprise-based dial
7
Tel. #: (034) 312-6189 / (034) 729-4327
tone solutions (i.e., VoIP gateways seek to save toll charges by routing long distance calls over
dedicated data lines between company offices).
The following routes are possible with VoIP
· Computer to Computer
· Computer to Handset
· Handset to Handset
Figure 10: Handset-to-Handset IP Technology
Above, Figure 10 shows a typical VoIP call using two handsets at either terminating endpoints. Below,
Figure 11 shows a different VoIP scenario, where a call is between two computers at terminating ends.
Figure 11: Computer-to-Computer IP Technology
8
Tel. #: (034) 312-6189 / (034) 729-4327
Voice QoS Problems with IP
IP was designated for carrying data, so it does not provide real time guarantees but only
provides best effort service. For voice communications over IP to become acceptable to the
users, the delay needs to be less than a threshold value. To ensure good quality of voice, we can
use either Echo Cancellation, Packet Prioritization (giving higher priority to voice packets) or
Forward Error Correction.
Interoperability with PSTN
In a public network environment, products from different vendors need to operate with
each other if voice over IP is to become common among users. To achieve interoperability,
standards are being devised and the most common standard for VoIP is the H.323 standard, or
SIP (Session Initiation Protocol). SIP seems to be the latest fashionable protocol in VoIP.
Security
Security problems exist because in the Internet anyone can capture the packets meant for
someone else. Some security can be provided by using encryption and tunneling. The common
tunneling protocol used is Layer 2 Tunneling protocol and the common encryption mechanism
used is Secured Sockets Layer (SSL).
H.323
H.323 is the ITU-T standard that vendors may use to provide Voice over IP service. H.323
provides the technical requirements for voice communication over IP networks. It was originally
developed for video teleconferencing on IP networks, from H.320 Video Telephony over
Narrowband ISDN. The first version was released in 1996 while the second version of H.323
came into effect in January 1988. The standard encompasses both point to point
communications and multipoint conferences.
What is wrong with H.323
At the top of the list is call setup time. Since H.323 first establishes a session and only then
negotiates the features and capabilities of the session, call setup can take significantly longer
than an average PSTN call: H.323 doesn’t scale well. A case in point is H.323 addressing.
Creating separate phone-numbering schemes complicates interconnecting carrier networks.
Critics also charge that the H.323 standard itself is too large and complex to make deployment
easy. “H.323 is built in a telecom manner”
SIP
9
Tel. #: (034) 312-6189 / (034) 729-4327
Session Initiation Protocol (SIP) = a change from telephony’s “calls” between handsets
controlled by the network to “sessions” which can be between processes on any platform
anywhere in the Internet and with both control and media content in form and hence can be
easily manipulated. Thus a separate voice network is not necessary. Open and distributed nature
enables lots of innovation (since both control and media can be manipulated and “events” are no
longer restricted to start and end of calls).
Advantages of SIP
The intelligence is pushed to the network edge where processing capability is available in
desktop computers.
SIP allows multiparty calls to be setup using IP multicast capabilities.
With SIP, one can ‘fork’ calls, i.e. call two different extension from a single line. The extension
that gets picked up first gets the call. This is useful if the receiver has two different offices.
How SIP works
SIP is a simple, ASCII-based protocol that uses requests and responses to establish
communication among the various components in the network and to ultimately establish a
conference between two or more end points.
Users in a SIP network are identified by unique SIP addresses. A SIP address is similar to an
e-mail address and is in the format of sip:userID@gateway.com. The user ID can be either a
user name or an E. 164 address.
Users register with a registrar server using their assigned SIP address. The registrar server
provides this information to the location server upon request.
When a user initiates a call, a SIP request is sent to a SIP server. The request includes the
address of the caller and the address of the intended callee
Convergence
ICT convergence involves the coming together of information distribution infrastructures;

interactive information storage and processing capabilities; and widespread availability of
consumer electronics products, publishing and IT content.
One of the first practical examples of convergence was the coming together of certain technical
elements of IT and telecommunications, which manifested itself in the digitization of
telecommunications switching and the application of IT to telecommunications terminal
equipment.
The OSI Reference Model

10
Tel. #: (034) 312-6189 / (034) 729-4327
Modern computer networks are designed in a highly structured way. To reduce their design
complexity, most networks are organized as a series of layers, each one built upon its
predecessor.
The OSI Reference Model is based on a proposal developed by the International Organization for
Standardization (ISO). The model is called ISO OSI (Open Systems Interconnection) Reference
Model because it deals with connecting open systems - that is, systems that are open for
communication with other systems.
The OSI model has seven layers. The principles that were applied to arrive at the seven layers
are as follows:
1. A layer should be created where a different level of abstraction is needed.
2. Each layer should perform a well defined function.
3. The function of each layer should be chosen with an eye toward defining internationally
standardized protocols.
4. The layer boundaries should be chosen to minimize the information flow across the interfaces.
5. The number of layers should be large enough that distinct functions need not be thrown
together in the same layer out of necessity, and small enough that the architecture does not
become unwieldy.
THE OPEN SYSTEMS INTERCONNECTION MODEL
The International Standards Organization (ISO) has developed a universal architecture for
computer communications. This standard, known as the Open Systems Interconnection Model,
or OSI model, breaks down the task of communications into seven independent layers, each
with its own tasks. OSI’s purpose is to permit communications among devices made by many
manufacturers. The exact methods for performing these tasks, including the protocols we
discuss later in this Section, are still evolving. Almost all of the major host computer
manufacturers have supported the concept of OSI in principle, even though their current product
offerings may not all comply with OSI. The Corporation for Open Systems, or COS, is a
non-profit corporation formed in 1985 consisting of representatives of major host computer
manufacturers of that era, including Control Data, DEC, Hewlett-Packard, Honeywell, IBM, NCR,
Tandem, Unisys, Wang, Xerox, and others. The corporation’s purpose is to facilitate the
evolution of intervendor compatibility from a model to a reality. Perhaps the most significant
contribution of the OSI model is that it provides all of us with a common language for describing
communications tasks and functions.
The seven layers of OSI are shown in Fig. 7-1. Each layer represents a particular function.
Sometimes, each function is performed by a separate piece of hardware or software. Other
times, a single program may perform the functions of several layers. All of the layers are
11
Tel. #: (034) 312-6189 / (034) 729-4327
necessary for communications to occur. The different layer classifications are somewhat
arbitrary, and a different standards committee might have chosen to break the communications
functions into more or fewer layers. For example, we might describe the process of driving to
work as “(1) Open the car door. (2) Sit down. (3) Close the door. (4) Insert the key. (5) Turn
the key,” and so on. Another person might describe the same process as “(1) Get in the car. (2)
Start the car. (3) Put the car in gear,” and so on. We are all describing the same task, and both
descriptions are correct and accurate; however, each description chooses to break up the
process of driving to work into different tasks. Similarly, the ISO-OSI model chooses to divide
the function of computer communications into seven layers, though more or fewer layers could
easily have been chosen. Rather than examine each layer’s functions in detail, we merely
highlight its most important functions.
The lowest layers, known as the Physical Layer, or Layer 1, are responsible for the
transmission of bits. The Physical Layer is always implemented using hardware; this layer
encompasses the mechanical, electrical, and functional interface. This layer is the interface to
the outside world, where ones and zeroes leave and enter the device, usually using electronic
signals as specified by interface standards. Examples of Physical Layer standards are RS-232-C,
RS-449, RS-422-A, and RS-423-A.
HOST COMPUTER
Application Layer (7)
Presentation Layer (6) Higher

Session Layer (5)
layers
Transport Layer (4)
Network Layer (3)

Lower
Data Link Layer (2) layers
Physical Layer (1)
FIGURE 7-1 Layers of the Open Systems Interconnection Model
The Data Link Layer or Layer 2, assembles the data bits into a block, or frame, which is
then sent to the Physical Layer for transmission. It is often also responsible for ensuring
error-free, reliable transmission of data. The Data Link Layer typically scrutinizes the bits
received to determine if errors occurred during transmission. This layer is often able to request
retransmission or correction of any errors using protocols such as BSC, SDLC, HDLC, and PPP,
presented later in this Section.
The Network Layer, or Layer 3, is responsible for setting up the appropriate routing of
messages throughout a network. This layer is the only layer concerned with the types of
switching networks used to route the data. The routing of data between networks, and through
packet switching networks, is also handled by the Network Layer. We discuss packet switching
networks further in Section 8.
12
Tel. #: (034) 312-6189 / (034) 729-4327
These layers of OSI (Physical, Data Link and Network) are usually referred to as the lower
layers. Layers 4 through 7 (Transport, Session, Presentation, and Application) are usually
referred to as the higher layers, or upper layers.
The Transport Layer, or Layer 4, is responsible for isolating the function of the lower
layers from the higher layers. This layer will accept messages from higher layers and break
these messages down into messages that can be accepted by the lower layers. For example, a
file being transferred may contain thousands of characters; the lower layers may be transmitting
data 100 characters at a time, so the Transport Layer breaks the file into many blocks, each 100
character long. If communication technology changes and longer messages can be accepted in
the future, the Transport Layer will need modification, but not either higher layers. The
Transport Layer is also responsible for monitoring the quality of the communications channel and
for selecting the most cost-efficient communication service based on the reliability required for a
particular transmission.
The Session Layer, or Layer 5, request that a logical connection be established based on
the end user’s request. In this case, an end user might be the terminal operator using the
computer. For example, if the user wants to transfer a file, the Session Layer is informed of the
location of the file on the user’s system and the location of the destination file on the remote
host computer. Any necessary log-on and password procedures are also usually handled by this
layer. The Session Layer is also responsible for terminating the connection.
The Presentation Layer, or Layer 6, provides format and code conversion services. For
example, if the host computer is connected to many different types of printers, each printer may
require different character sequences to invoke special features, such as boldface and italics.
The Presentation Layer handles all of necessary formatting. In addition, if files are being
transferred from the host computer of one manufacturer to the host computer of another, there
may be different file formats, or even different character codes. The Presentation Layer would
handle any necessary conversion (e.g., ASCII-to-EBCDIC conversion).
The Application Layer, or Layer 7, provides access to the network for the end user. The
user’s capabilities on the network are determined by the Application Layer software, which can
be tailored to the needs of the user. Some Application Layer software might permit remote
terminals only to access a host computer; other Application Layer software might also permit file
transfers. Network management statistics, diagnostics, and other on-line monitoring capabilities
can also be implemented in this layer.
We have already mentioned that the Physical Layer must be implemented in hardware.
Since this layer is the only part of the model where bits are actually transmitted, it is also the
only part of the model requiring hardware implementation. The other layers all manipulate the
data in some way, perhaps adding to it or modifying it, but all of these techniques can generally
be performed using software. However, since functions can be performed more efficiently and
inexpensively by hardware than by software, some functions of the Data Link and Network
13
Tel. #: (034) 312-6189 / (034) 729-4327
Layers are sometimes implemented in hardware. The higher layers are almost always
implemented in software.
Lesson II:
Serial Networks & Protocols
DTE and DCE
The terms DTE and DCE are very common in the data communication market. DTE is short for
Data Terminal Equipment and DCE stands for Data Communications Equipments. But what do
they really mean? As the full DTE name indicates this is a piece of device that ends a
communication line, whereas the DCE provides a path for communication.
Let’s say we have a computer on which wants to communicate with the Internet through a
modern and a dial-up connection. To get to the Internet you tell you modern to dial the number
of your provider. After your modems has dialed the number, the modem of the provider will
answer your call and your will hear a lot of noise. Then it becomes quiet and you see your login
prompt or your dialing program tells you the connection is established. Now you have a
connection with the server from your provider and you can wander the Internet.
In this example you PC is a Data Terminal (DTE). The two modems (yours and that one of your
provider) are DCEs, they make the communication between you and to provider possible. But
now we have to look at the server of your provider. Is that a DTE or DCE?
The answer is a DTE. It ends the communication line between you and the server. Although it
gives you the possibility to surf around the glode. The reason why it is a DTE is that when you
want to go from your provides server to another place it uses another interface. So DTE and
DCE are interface dependent. It is e.g. possible that for your connection to the serve, the server
is a DTE, but that same server is a DCE for the equipment that it is attached to on the rest of
the Net.
(Data Terminating Equipment) A communications device that is the source or destination of

signals on a network. It is typically a terminal or computer. Contrast with DCE.
14
Tel. #: (034) 312-6189 / (034) 729-4327
(Data Communications Equipment or Data Circuit-terminating Equipment) A device that
establishes maintains and terminates a session on a network. It may also convert signals for
transmission. It is typically the modem.
Data Rates
A data transfer rate (or often just data rate) is the amount of digital data that is moved from
one place to another in a given time, usually in a second's time. The data transfer rate can be
viewed as the speed of travel of a given amount of data from one place to another. In general,
the greater the bandwidth of a given path, the higher the data transfer rate.
In telecommunications, data transfer is usually measured in bits per second. For example, a
typical low-speed connection to the Internet may be 33.6 kilobits per second (Kbps). On
Ethernet local area networks, data transfer can be as fast as 10 megabits per second. Network
switches are planned that will transfer data in the terabit range. In earlier telecommunication
systems, data transfer was sometimes measured in characters or blocks (of a certain size) per
second. Data transfer time between the microprocessor or RAM and devices such as the hard
disk and CD-ROM player is usually measured in milliseconds.
15
Tel. #: (034) 312-6189 / (034) 729-4327
In computers, data transfer is often measured in bytes per second. The highest data transfer
rate to date is 14 terabits per second over a single optical fiber, reported by Japan's Nippon
Telegraph and Telephone (NTT DoComo) in 2006.
<communications, unit> (Or "data Transfer rate", "transmission rate") The amount of data
transferred per second by a communications channel or a computing or storage device.
Data rate is measured in units of bits per second (written "b/s" or "bps"), bytes per second
(Bps), or baud.
When applied to data rate, the multiplier prefixes "kilo-", "mega-", "giga-", etc. (and their
abbreviations, "k", "M", "G", etc.) always denote powers of 1000. For example, 64 kbps is
64,000 bits per second. This contrasts with units of storage where they stand for powers of
1024, e.g. 1 KB = 1024 bytes.
Flow Control
In communications, the process of adjusting the flow of data from one device to another to
ensure that the receiving device can handle all of the incoming data. This is particularly
important where the sending device is capable of sending data much faster than the receiving
device can receive it.
There are many flow control mechanisms. One of the most common flow control protocols for
asynchronous communication is called xon-xoff. In this case, the receiving device sends a an
xoff message to the sending device when its buffer is full. The sending device then stops sending
data. When the receiving device is ready to receive more data, it sends an xon signal.
Flow control can be implemented in hardware or software, or a combination of both.
TCP manages limited network bandwidth by performing flow control.

Modern data networks are designed to support a diverse range of hosts and communication
mediums. Consider a 200MHz Pentium-based host transmitting data to a 25MHz 80386/SX.
Obviously, the Pentium will be able to drown the slower processor with data. Likewise, consider
two hosts, each using an Ethernet LAN, but with the two Ethernets connected by a 28.8 Kbps
modem link. If one host begins transmitting to the other at Ethernet speeds, the modem link will
quickly become overwhelmed. In both cases, flow control is needed to pace the data transfer at
an acceptable speed.
Request/reply flow control requires each data packet to be acknowledge by the remote host
before the next packet is sent. Sliding window algorithms, used by TCP, permit multiple data
packets to be in simultaneous transit, making more efficient use of network bandwidth. Finally,
Internet's Unreliable Delivery Model allows packets to be discarded if network resources are not
available, and demands that protocols make provisions for retransmission.
The collection of techniques used in serial communications to stop the sender sending data until
the receiver can accept it. This may be either {software flow control} or {hardware flow
control}. The receiver typically has a fixed size {buffer} into which received data is written as
soon as it is received. When the amount of buffered data exceeds a "high water mark", the
16
Tel. #: (034) 312-6189 / (034) 729-4327
receiver will signal to the transmitter to stop transmitting until the process reading the data has
read sufficient data from the buffer that it has reached its "low water mark", at which point the
receiver signals to the transmitter to resume transmission. (1995-03-22)
Synchronous Communication Adapters for use on HP Alpha Systems
Models
4-port Intelligent Synchronous Communications Adapter 3X-PBXDD-AB
2-port Intelligent Synchronous Communications Adapter 3X-PBXDD-AA
Introduction
The Digi DataFire SYNC 2000 adapters available from HP provide remote WAN and SNA
connectivity for PCI servers, which make them ideal for branch offices of central sites. X.25 is a
proven packet switched technology that has been around for many years. X.25 provides 100
percent error correction and network-managed flow control. It guarantees that every packet will
arrive at its destination without any errors. This is a slow, deliberate process that involves a
great deal of overhead and is widely used internationally where leased lines are not readily
available.
High –speed Synchronous WAN Communications

Subscribers pay a variable rate based on connect time and packets transmitted. Frame Relay is
designed as the successor to X.25 for transmitting data over the phone network. It is also a
packet switching protocol, but is provides no guarantee of data integrity. Frame Relay links have
more in common with dedicated lines than switched lines, but the cost can be substantially lower
for an equivalent capacity, as subscribers pay a variable rate based on bandwidth and the
committed information rate.
Intelligent Synchronous Adapters

The Digi DataFire SYNC 2000 is a family of intelligent synchronous communication adapters that
provide advanced server-based Wide Area Network (WAN) solutions. Available in two-and
four-port models. The DataFire SYNC 2000 2P and 4P models are mid-level, intelligent WAN
adapters based on the Motorola MPC860 PowerQUICC processor running at 25 MHz and 40 MHz,
respectively. All DataFire SYNC 2000 adapters run Frame Relay FRF.9 compression to boost
throughout. All DataFire SYNC 2000 models work with PCI-based servers running at either 3.3-
or 5-volts. Four MB of on-board RAM supports T1/E1 speeds on all ports in full-duplex mode.
Cables are available for the common interfaces-V.24 EIA-530, V.35, V.36, V11 and EIA-449.
Each port uses an optional independent cable, allowing any combination of electrical interfaces
to be used. The cable is automatically configured when plugged into the board, eliminating
troublesome configuration options. Each port can report the status of all compliant modem
signals and attached cables. Each interface also can measure and report the speed of modems
and CSU/DSUs for faster troubleshooting.
Async
17
Tel. #: (034) 312-6189 / (034) 729-4327
Asynchrony is the state of not being synchronized. Contrast with plesiochronous systems. In
terms of digital logic and data transfer, an asynchronous object does not require a clock signal.
Examples:
· asynchronous circuit
· asynchronous communication
· Asynchronous Transfer Mode
· asynchronous serial interfaces
· packet switched systems such as Ethernet or internet protocol
· asynchronous computer APIs
· Collaborative editing systems
· Asynchronous Cellular Automaton
Telecommunications - Asynchronous (stop/start) data transmission
This is an extension to telegraph methods used by computer terminals from the model 33
teletype to VDUs/VDTs (Video Display Units/Terminals). When serial data is transmitted, timing
information must be sent to allow the information to be correctly decoded at the distant end.
Bit synchronization information is required to allow the receiver to sample each bit at the correct
time. Character synchronization allows the receiver to divide the data stream into characters, ie
to know where each character starts and stops.
In asynchronous operation both bit and character synchronization are provided by the start and
stop bits, when nothing is being transmitted a continuous mark (logic 1) is being sent to line,
when a character is sent the start bit causes a 1 -> 0 transition, 1.5 bit lengths after that will be
the middle of the first bit, each bit is then sampled in turn until the stop bit which is always 1 to
ensure a 1 -> 0 transition at the start of the next character.
Therefore no additional timing signals need to be provided by the modem but the terminal must
know what speed is being transmitted to sample at the correct rate.
Users have to sort out, baud rates, parity, number of stop bits/ data bits and any handshaking.
this is how a CR is sent to line
---+ +---+ +-------+ +--------------1=mark

|||||||||||
+---+ +---+ +-----------+ 0=space
s1234567ps
18
Tel. #: (034) 312-6189 / (034) 729-4327
tat
almro
rssip
tddt
Stop/start is used when connecting to the Public Network pad.
line rate 110 b/s line rate > 110 b/s
number of stop bits PAD min 2 min 1
DTE-C min 1 min 1
coding of parity bit optional in all transmissions from the DTE-C, however in all user data
transmitted or received by the DTE-C the coding of all 8 bits (7 character bits plus parity bit) will
be passed transparently between the DTE-C and DTE-P. All characters generated by the PAD (eg
PAD service signals) will be transmitted with even parity.
Sync (Synchronization)
Synchronization (or Sync) is a problem in timekeeping which requires the coordination of

events to operate a system in unison. The familiar conductor of an orchestra serves to keep the
orchestra in time. Systems operating with all their parts in synchrony are said to be synchronous
or in sync. Some systems may be only approximately synchronized, or plesiochronous. For some
applications relative offsets between events need to be determined, for others only the order of
the event is important.
Today, synchronization can occur on a global basis due to GPS-enabled timekeeping systems.
Transport
Apart from its use for navigation (see John Harrison), synchronization was not important in
transportation until the nineteenth century, when the coming of the railways made travel fast
enough for the differences in local time between adjacent towns to be noticeable.
In some territories, sharing of single railroad tracks was controlled by the timetable. Thus strict
timekeeping was a safety requirement. To this day, railroads can communicate and signal along
their tracks, independently of other systems for safety.
Communication
The lessons of timekeeping are part of engineering technology. In electrical engineering terms,
for digital logic and data transfer, a synchronous object requires a clock signal.
19
Tel. #: (034) 312-6189 / (034) 729-4327
Timekeeping technologies such as the GPS satellites and Network time protocol (NTP) provide
real-time access to a close approximation to the UTC timescale, and are used for many
terrestrial synchronization applications.
Synchronization is an important concept in the following fields:
· Computer science "In computer science, especially parallel computing, synchronization

means the coordination of simultaneous threads or processes to complete a task in order
to get correct runtime order and avoid unexpected race conditions."
· Telecommunication
· Physics The idea of simultaneity has many difficulties, both in practice and theory.
· Cryptography
· Multimedia
· Photography
· Music (rhythm)
· Synthesizers
Synchronization has several subtly distinct sub-concepts:
· Rate synchronization
· Phase synchronization
· Time offset synchronization
· Time order synchronization
Some uses of synchronization

Whilst well-designed time synchronization is an important tool for creating reliable systems,
excessive use of synchronization where it is not necessary can make systems less fault-tolerant,
and hence less reliable.
· Film synchronization of image and sound in sound film.
· Synchronization is important in fields such as digital telephony, video and digital audio
where streams of sampled data are manipulated.
· Arbiters are needed in digital electronic systems such as microprocessors to deal with
asynchronous inputs. There are also electronic digital circuits called synchronizers that
attempt to perform arbitration in one clock cycle. Synchronizers, unlike arbiters, are prone
to failure. (See metastability in electronics).
20
Tel. #: (034) 312-6189 / (034) 729-4327
· Encryption systems usually require some synchronization mechanism to ensure that the
receiving cipher is decoding the right bits at the right time.
· Automotive transmissions contain synchronizers which allow the toothed rotating parts
(gears and splined shaft) to be brought to the same rotational velocity before engaging
the teeth.
· Synchronization is also important in industrial automation applications.
· Time codes are often used as a means of synchronization in film, video, and audio
applications.
· Flash photography, see Flash synchronization
· File synchronization is used to maintain the same version of files on multiple computing
devices. For example, an address book on a telephone might need to by synchronized
with an address book on a computer.
· Software applications must occasionally incorporate application-specific data

synchronization in order to mirror changes over time among multiple data sources at a
level more granular than File synchronization. An example use of this is the Data
Synchronization specification of the Open Mobile Alliance, which continues the work
previously done by the SyncML initiative. SyncML was initially proposed to synchronize
changes in personal address book and calendar information from computers to mobile
phones, but has subsequently been used in applications that synchronize other types of
data changes among multiple sources, such as project status changes.
· The term synchronization is also sometimes used for the transfer of content from a
computer to an MP3 player connected to it.
High-Level Data Link Control
High-Level Data Link Control (HDLC) is a bit-oriented synchronous data link layer protocol
developed by the International Organization for Standardization (ISO). The original ISO
standards for HDLC were:
· ISO 0009 — Frame Structure
· ISO 4335 — Elements of Procedure
· ISO 6159 — Unbalanced Classes of Procedure
· ISO 6256 — Balanced Classes of Procedure
The current standard for HDLC is ISO 13239, which replaces all of those standards.
HDLC provides both connection oriented and connectionless service.
21
Tel. #: (034) 312-6189 / (034) 729-4327
HDLC can be used for point to multipoint connections, but is now used almost exclusively to
connect one device to another, using what is known as Asynchronous Balanced Mode (ABM). The
other modes are Normal Response Mode and Asynchronous Response Mode.
Framing
HDLC frames can be transmitted over synchronous or asynchronous links. Those links have no
mechanism to mark the beginning or end of a frame, so the beginning and end of each frame
has to be identified. This is done by using a frame delimiter, or flag, which is a unique sequence
of bits that is guaranteed not to be seen inside a frame. This sequence is '01111110', or, in
hexadecimal notation, 7E. Each frame begins and ends with a frame delimiter.
When no frames are being transmitted on a synchronous link, a frame delimiter is continuously
transmitted on the link. Using the standard NRZI encoding from bits to line levels (0 bit =
transition, 1 bit = no transition), this generates a continuous bit pattern:
01111110011111100111111001111110
_____________ _____________ _____________ _____________
_/ \_/ \_/ \_/ \
This is used by modems to train and synchronize their clocks via phase-locked loops.
Actual binary data could easily have a sequence of bits that is the same as the flag sequence. So
the data's bit sequence must be transmitted so that it doesn't appear to be a frame delimiter.
On synchronous links, this is done with bit stuffing. The sending device ensures that any
sequence of 5 contiguous 1-bits is automatically followed by a 0-bit. A simple digital circuit
inserts a 0-bit after 5 1-bits. The receiving device knows this is being done, and will
automatically strip out the extra 0-bits. So if a flag is received, it will have 6 contiguous 1-bits.
The receiving device see 6 1-bits and knows it is a flag — otherwise the 6th bit would have been
a 0-bit.
This also (again, assuming NRZI encoding of the output) provides a minimum of one transition
per 6 bit times, so the receiver can stay in sync with the transmitter.
Asynchronous links using serial ports or UARTs just send bits in groups of 8. They lack the
special bit-stuffing digital circuits. Instead they use "control-octet transparency", also called
"byte stuffing" or "octet stuffing". The frame boundary octet is 01111110, (7E in hexadecimal
notation). A "control escape octet", has the bit sequence '01111101', (7D hexadecimal). The
escape octet is sent before a data byte with the same value as either an escape or frame octet.
Then, the following data has bit 5 (counting from right to left and starting at zero) inverted. For
example, the data sequence "01111110" (7E hex) would be transmitted as "01111101
01011110" ("7D 5E" hex). Any octet value can be escaped in the same fashion.
Structure
The contents of an HDLC frame, including the flag, are
22
Tel. #: (034) 312-6189 / (034) 729-4327
Add r es (Optional
Flag Control Information FCS
s Flag)
8 8 or 16 Variable length, 0 or more bits, in 16 or 32

8 bits 8 bits
bits bits multiples of 8 bits
Note that the end flag of one frame can be (but does not have to be) the beginning (start) flag
of the next frame.
Note that the data comes in groups of 8 bits. The telephone and teletype systems arranged most
long-haul digital transmission media to send bits eight at a time, and HDLC simply adapts that
standard to send bulk binary data. Voice is encoded by A-law or u-law into 8-bit samples.
Teletypes send 8-bit codes to represent each character.
The FCS is the Frame Check Sequence, and is a more sophisticated version of the parity bit. The
field contains the result of a binary calculation that uses the bit sequences that make up the
'Address', 'Control' and 'Information' fields. The calculation is designed to detect errors in the
transmission of the frame — lost bits, flipped bits, extraneous bits — so that the frame can be
dropped by the receiver if an error is detected. It is this method of detecting errors that can set
an upper bound on the size of the data portion of the frame. Essentially, the longer the length of
the data portion of the frame becomes, the harder it is to guarantee that certain types of
transmission errors will be found. There are multiple types of Frame Check Sequence, and the
most commonly used in this context will be CRC-16 or CRC-CCITT.
The FCS is needed to detect transmission errors. When HDLC was designed, long-haul digital
media were designed for telephone systems, which only need a bit error rate of 1×10−5 errors
per bit. Digital data for computers normally requires a bit error rate better than 1×10−12 errors
per bit. By checking the FCS, the receiver can discover bad data. If the data is ok, it sends an
"acknowledge" packet back to the sender. The sender can then send the next frame. If the
receiver sends a "negative acknowledge" or simply drops the bad frame, the sender either
receives the negative acknowledge, or runs into its time limit while waiting for the acknowledge.
It then retransmits the failed frame. Modern optical networks have reliability substantially better
than 1×10−5 errors per bit, but that simply makes HDLC even more reliable.
Types of Stations (Computers), and Data Transfer Modes

· Primary terminal is responsible for operation control over the link. It issues the frames
which are called commands.
· Secondary terminal operates under the control of the primary. Frames issues, are
responses only. Primary is linked with secondaries by multiple logical links.
23
Tel. #: (034) 312-6189 / (034) 729-4327
· Combined terminal, has the features of both primary and secondary terminals. It issues
both commands and responses.
HDLC Operations, and Frame Types
I-Frames (user data)

Contain user data, sequence number of the transmitted frame, piggybacking acknowledgment
number of received I-Frame. Their maximum window size is 7 or 127. I-Frames also contain
poll/final (P/F) bit. Depending on response mode,
· In NRM the primary terminal sets the P-bit to poll. The secondary sets the F-bit in last
I-frame to a response.
· IN ARM and ABM, the P/F bits are used to force response.
S-Frames (control)
Used both for flow and error control.
Receive Ready (RR)

· used as positive acknowledgement (thruN(r)-1) and a request that no more I-frames be
sent until a subsequent RR is in use.
· Primary terminal can issue a POLL by P-bit setting
· Secondary terminal responds with F-bit set, if it has no data to send.
Receive Not Ready (RNR)

· Used as positive ACK and a request that no more i-frames should be sent till the
subsequent RR is received.
· Either Primary or Combined station can set P-bit to solicit the receive status of a
secondary/combined station.
· Secondary/Combined station response to Poll with F-bit set if the station is busy.
Reject (REJ)
Uses Go-Back-N technique (Retransmit from N(r))
Selective Reject
Uses Selective Repeat Technique ((Repeat N(r))
24
Tel. #: (034) 312-6189 / (034) 729-4327
U-Frames
· Mode settings (SNRM, SNRME, SARM, SARME, SABM, SABME, UA, DM, RIM, SIM, RD,
DISC)
· Information Transfer(UP, UI)
· Recovery (FRMR, RSET)
· Invalid Control Field
· Data Field Too Long
· Data field not allowed with received Frame Type
· Invalid Receive Count
· Miscellaneous (XID, TEST)
Link Configurations
Link configurations can be categorized as being either:
· Unbalanced, which consists of one primary terminal, and one or more secondary
terminals.
· Balanced, which consists of two peer terminals.
HDLC Data Transfer Modes illustrated

The three link configurations are:
· Normal Response Mode (NRM) is an unbalanced

configuration in which only the primary terminal may
initiate data transfer. The secondary terminal transmits
data only in response to commands from the primary
terminal. The primary terminal polls the secondary
terminal(s) to determine whether they have data to transmit, and then selects one to
transmit.
· Asynchronous Response Mode (ARM) is an unbalanced configuration in which secondary

terminals may transmit without permission from the primary terminal. However, the
primary terminal still retains responsibility for line initialization, error recovery, and logical
disconnect.
· Asynchronous Balanced Mode (ABM) is a balanced configuration in which either station

may initiate the transmission.
25
Tel. #: (034) 312-6189 / (034) 729-4327
HDLC Command and response repertoire
· Commands (I, RR, RNR, (SNRM or SARM or SABM) DISC
· Responses (I, RR, RNR, UA, DM, FRMR)
Basic Operations
· Initialization can be requested by either side. When the six-mode set-command is issued.
This command:
· Signals the other side that initialization is requested
· Specifies the mode, NRM, ABM, ARM
· Specifies whether 3 or 7 bit sequence numbers are in use.
The HDLC module on the other end transmits (UA) frame when the request is accepted. And if
the request is rejected it sends (DM) disconnect mode frame.
Functional Extensions (Options)

· For Switched Circuits
· Commands: ADD - XID
· Responses: ADD - XID, RD
· For 2-way Simultaneous commands & responses are ADD - REJ
· For Single Frame Retransmission commands & responses: ADD - SREJ
· For Information Commands & Responses: ADD - Ul
· For Initialization
· Commands: ADD - SIM
· Responses: ADD - RIM
· For Group Polling
· Commands: ADD - UP
· Extended Addressing
· Delete Response I Frames
· Delete Command I Frames
26
Tel. #: (034) 312-6189 / (034) 729-4327
· Extended Numbering
· For Mode Reset (ABM only) Commands are: ADD - RSET
· Data Link Test Commands & Responses are: ADD - TEST
· Request Disconnect. Responses are ADD - RD
· 32-bit FCS
HDLC Command/Response Repertoire
Command C-Field Format

Type Of /
Name Description Info 8...7...6...5...4...3...2...1....
Frame
.
Response
User exchange
Information(I) C/R .-N(R)-... P/F.....-N(S)-..0
data
Receive Ready to
Supervisory Positive
Ready C/R receive .-N(R)-... P/F...0...0...0...1
(S) Acknowledgement
(RR) I-Frame
Receive
Not
Not Positive
C/R Ready to .-N(R)-... P/F...0...1...0...1
Ready Acknowledgement
receive
(RNR)
Reject Negative
C/R go back N .-N(R)-... P/F...1...0...1...0
(REJ) Acknowledgement
Selective
Negative selective
Reject C/R .-N(R)-... P/F...1...1...0...1
Acknowledgement reject
(SREJ)
Unnumbered Frames
Command
C-Field Format
/
Name Description Info
8...7...6...5...4...3...2...1.....
Response
Set normal response Set mode; = 7 bit sequence

C ..1...0...0...P...1...1...0...1
SNRM extended number
Set normal response Set mode; = 7 bit sequence
C ..1...1...0...P...1...1...1...1
extended mode SNRME extended number
27
Tel. #: (034) 312-6189 / (034) 729-4327
Set asynchronous Set mode; = 7 bit sequence
C ..0...0...0..P/F..1...1...0...1
response SARM extended number
Set asynchronous
Set mode; = 7 bit sequence
response extended mode C ..0...1...0...P..1...1...1...1
extended number
SARME
Set asynchronous
balanced/extended mode C ..0...0...1..P/F..1...1...1...1
extended number
SABM
Set asynchronous
balanced extended mode C ..0...1...1...P...1...1...1...1
extended number
SABME
Set initialization mode Initialize link in the addressed
C ..0...0...0..P/F..0...1...1...1
SIM control function station
Terminate logical
Disconnect DISC C ..0...1...0..P/F..0...0...1...1
link connection
of one of hte
Unnumbered Acknowledge
R set-mode ..0...1...0....F..0...0...1...1
Acknowledgement UA acceptance
commands.
Responder in
Disconnect Mode (DM) R
Disconnect Mode
Requested Disconnect Responder for
R ..0...1...0..P/F..0...0...1...1
(RD) Disc Command
Request Initialization Initialization Request for SIM
R
Mode (RIM) needed command
Unnumbered Information Used to control
C/R ..0...0...0..P/F..0...0...1...1
(UI) exchange information
control
Unnumbered Poll (UP) C Used to solicit ..0...0...1..P....0...0...1...1
information
Reset (RSET) C Used for recovery Resets N(R), N(S) ..1...0...0..P....1...1...1...1
Exchange Indication (XID) C/R Used to Request/ Report Status ..1...0...1..P/F..1...1...1...1
Exchange
Test (TEST) C/R identical fields for testing ..1...1...1..P/F..0...0...1...1
information
of unacceptable
Frame Reject FRMR C/R Report receipt
frame
SDLC: Synchronous Data Link Control by IBM
28
Tel. #: (034) 312-6189 / (034) 729-4327
The Synchronous Data Link Control (SDLC) protocol, an IBM data link layer protocol for use in
the Systems Network Architecture (SNA) environment.
The data link control Layer provides the error-free movement of data between the Network
Addressable Units (NAUs) within a given communication network via the Synchronous Data Link
Control (SDLC) Protocol. The flow of information passes down from the higher layers through
the data link control Layer and is passed into the physical control Layer. It then passes into the
communication links through some type of interface. SDLC supports a variety of link types and
topologies. It can be used with point-to-point and multipoint links, bounded and unbounded
media, half-duplex and full-duplex transmission facilities, and circuit-switched and
packet-switched networks.
SDLC identifies two types of network nodes: primary and secondary. Primary nodes control the
operation of other stations, called secondaries. The primary polls the secondaries in a
predetermined order, and secondaries can then transmit if they have outgoing data. The
primary also sets up and tears down links and manages the link while it is operational.
Secondary nodes are controlled by a primary, which means that secondaries can send
information to the primary only if the primary grants permission.
SDLC primaries and secondaries can be connected in four basic configurations:
· Point-to-point- Involves only two nodes, one primary and one secondary.
· Multipoint- Involves one primary and multiple secondaries.
· Loop- Involves a loop topology, with the primary connected to the first and last
secondaries. Intermediate secondaries pass messages through one another as they
respond to the requests of the primary.
· Hub go-ahead- Involves an inbound and an outbound channel. The primary uses the
outbound channel to communicate with the secondaries. The secondaries use the inbound
channel to communicate with the primary. The inbound channel is daisy-chained back to
the primary through each secondary.
SDLC has a few derivatives which are adopted in different environment:
· HDLC, an ISO protocol for x.25 network
· LAPB, an ITU-T protocol used in the ISDN network
· LAPF, an ITU-T protocol used in the Frame Relay network
· IEEE 802.2, often referred to as LLC and has three types, used in the local area network
· QLLC, used to transport SNA data across X.25 networks
Protocol Structure - SDLC: Synchronous Data Link Control by IBM
29
Tel. #: (034) 312-6189 / (034) 729-4327
1 byte 1-2 bytes 1-2 bytes variable 2 byte 1 byte
Flag Address field Control field Data FCS Flag
· Flag- Initiates and terminates error checking.
· Address- Contains the SDLC address of the secondary station, which indicates whether
the frame comes from the primary or secondary.
· Control- Employs three different formats, depending on the type of SDLC frame used:
· Information (I) frame- Carries upper-layer information and some control

information.
· Supervisory (S) frame- Provides control information. An S frame can request and
suspend transmission, report on status, and acknowledge receipt of I frames. S
frames do not have an information field.
· Unnumbered (U) frame- Supports control purposes and is not sequenced. A U

frame can be used to initialize secondaries. Depending on the function of the U
frame, its control field is 1 or 2 bytes. Some U frames have an information field.
· Data- Contains a path information unit (PIU) or exchange identification (XID) information.
· Frame check sequence (FCS)- Precedes the ending flag delimiter and is usually a cyclic
redundancy check (CRC) calculation remainder.
LAPB: Link Access Procedure Balanced
Link Access Procedure, Balanced (LAPB) is a data link layer protocol used to manage
communication and packet framing between data terminal equipment (DTE) and the data
circuit-terminating equipment (DCE) devices in the X.25 protocol stack. LAPB, a bit-oriented
protocol derived from HDLC, is actually the HDLC in BAC mode (Balanced Asynchronous Class).
LAPB makes sure that frames are error free and properly sequenced.
LAPB shares the same frame format, frame types, and field functions as SDLC and HDLC. Unlike
either of these, however, LAPB is restricted to the Asynchronous Balanced Mode (ABM) transfer
mode and is appropriate only for combined stations. Also, LAPB circuits can be established by
either the DTE or DCE. The station initiating the call is determined to be the primary, and the
responding station is the secondary. Finally, LAPB use of the P/F bit is somewhat different from
that of the other protocols.
In LAPB, since there is no master/slave relationship, the sender uses the Poll bit to insist on an
immediate response. In the response frame this same bit becomes the receivers Final bit. The
receiver always turns on the Final bit in its response to a command from the sender with the Poll
bit set. The P/F bit is generally used when either end becomes unsure about proper frame
30
Tel. #: (034) 312-6189 / (034) 729-4327
sequencing because of a possible missing acknowledgement, and it is necessary to re-establish a
point of reference.
LAPB's Frame Types:
· I-Frames (Information frames): Carries upper-layer information and some control

information. I-frame functions include sequencing, flow control, and error detection and
recovery. I-frames carry send and receive sequence numbers.
· S-Frames (Supervisory Frames): Carries control information. S-frame functions include

requesting and suspending transmissions, reporting on status, and acknowledging the
receipt of I-frames. S-frames carry only receive sequence numbers.
· U-Frames (Unnumbered Frames): carries control information. U-frame functions include

link setup and disconnection, as well as error reporting. U-frames carry no sequence
numbers
Protocol Structure - LAPB: Link Access Procedure Balanced

The format of LAPB frame is as follows:
1 byte 1 byte 1-2 bytes Variable 2 bytes 1 byte
Flag Address field Control field Data/Information FCS Flag
· Flag - The value of the flag is always (0x7E). In order to ensure that the bit pattern of the
frame delimiter flag does not appear in the data field of the frame (and therefore cause
frame misalignment), a technique known as Bit Stuffing is used by both the transmitter
and the receiver.
· Address field - In LAPB, the address field has no meaning since the protocol works in a
point to point mode and the DTE network address is represented in the layer 3 packets.
· Control field - it serves to identify the type of the frame. In addition, it includes sequence
numbers, control features and error tracking according to the frame type.
· Modes of operation - LAPB works in the Asynchronous Balanced Mode (ABM). This mode is
totally balanced (i.e., no master/slave relationship) and is signified by the SABM(E) frame.
Each station may initialize, supervise, recover from errors, and send frames at any time.
The DTE and DCE are treated as equals.
· FCS - The Frame Check Sequence enables a high level of physical error control by allowing
the integrity of the transmitted frame data to be checked.
31
Tel. #: (034) 312-6189 / (034) 729-4327
· Window size - LAPB supports an extended window size (modulo 128) where the number of
possible outstanding frames for acknowledgement is raised from 8 to 128.
LAPD
The LAPD (Link Access Protocol - Channel D) is a layer 2 protocol which is defined in CCITT
Q.920/921. LAPD works in the Asynchronous Balanced Mode (ABM). This mode is totally
balanced (i.e., no master/slave relationship). Each station may initialize, supervise, recover from
errors, and send frames at any time. The protocol treats the DTE and DCE as equals.
The format of a standard LAPD frame is as follows:
Fla g Address field Control field Information FCS Flag
LAPD frame structure

F l a g
The value of the flag is always (0x7E). In order to ensure that the bit pattern of the frame
delimiter flag does not appear in the data field of the frame (and therefore cause frame
misalignment), a technique known as Bit Stuffing is used by both the transmitter and the
receiver.
Address field
The first two bytes of the frame after the header flag is known as the address field. The format
of the address field is as follows:
8 7 6 5 4 3 2 1
SAPI C/R EA1
TEI EA2
LAPD address field
EA1 First Address Extension bit which is always set to 0.
C/R Command/Response bit. Frames from the user with this bit
set to 0 are command frames, as are frames from the
network with this bit set to 1. Other values indicate a
response frame.
EA2 Second Address Extension bit which is always set to 1.
TEI Terminal Endpoint Identifier. Valid values are as follows:
Used by non-automatic TEI assignment user
0-63
equipment.
64-126
Used by automatic TEI assignment equipment.
Used for a broadcast connection meant for all
127
Terminal Endpoints.
Control field
The field following the Address Field is called the Control Field and serves to identify the type of
32
Tel. #: (034) 312-6189 / (034) 729-4327
the frame. In addition, it includes sequence numbers, control features and error tracking
according to the frame type.
F C S
The Frame Check Sequence (FCS) enables a high level of physical error control by allowing the
integrity of the transmitted frame data to be checked. The sequence is first calculated by the
transmitter using an algorithm based on the values of all the bits in the frame. The receiver then
performs the same calculation on the received frame and compares its value to the CRC.
Window size
LAPD supports an extended window size (modulo 128) where the number of possible
outstanding frames for acknowledgement is raised from 8 to 128. This extension is generally
used for satellite transmissions where the acknowledgement delay is significantly greater than
the frame transmission times. The type of the link initialization frame determines the modulo of
the session and an "E" is added to the basic frame type name (e.g., SABM becomes SABME).
Frame types
The following are the Supervisory Frame Types in LAPD:
RR Information frame acknowledgement and indication to
receive more.
REJ Request for retransmission of all frames after a given
sequence number.
RNR Indicates a state of temporary occupation of station (e.g.,
window full).
The following are the Unnumbered Frame Types in LAPD:
DISC Request disconnection
UA Acknowledgement frame.
DM Response to DISC indicating disconnected mode.
FRMR Frame reject.
SABM Initiator for asynchronous balanced mode. No
master/slave relationship.
SABME SABM in extended mode.
UI Unnumbered Information.
XID Exchange Information.
There is one Information Frame Type in LAPD:
Info Information transfer frame.
33
Tel. #: (034) 312-6189 / (034) 729-4327
LAPM
Link Access Procedure for Modems, LAPM is an error control protocol defined in ITU-T
recommendations V.42. Like the MNP protocols, LAPM uses cyclic redundancy checking (CRC)
and retransmission of corrupted data (ARQ) to ensure data reliability.
Lesson III:
Analogue Networks, Modems and Multiplexers
PSTN and Leased line (2 and 4 wire)
PSTN (public switched telephone network) is the world's collection of interconnected

voice-oriented public telephone networks, both commercial and government-owned. It's also
referred to as the Plain Old Telephone Service (POTS). It's the aggregation of circuit-switching
telephone networks that has evolved from the days of Alexander Graham Bell ("Doctor Watson,
come here!"). Today, it is almost entirely digital in technology except for the final link from the
central (local) telephone office to the user.
In relation to the Internet, the PSTN actually furnishes much of the Internet's long-distance
infrastructure. Because Internet service providers ISPs pay the long-distance providers for
access to their infrastructure and share the circuits among many users through
packet-switching, Internet users avoid having to pay usage tolls to anyone other than their ISPs.
Analog Modems
Analog modems use the existing telephone infrastructure to link sites together. The telephone
cabling supports analogue frequencies in the range 300Hz to 3400KHz, and is primarily designed
for speech. The available bandwidth of the speech circuits provided by telecommunication
companies imposes limits on the available speed in bits per second that can be transmitted.
The modems implement a dial-up connection. A connection is made between the two modems
by dialing the number assigned to the other modem, using the existing dial up telephone
network. Generally, connections are established for limited duration's. This suits remote access
users who might want to dial into their network after hours, or small offices which dial into their
34
Tel. #: (034) 312-6189 / (034) 729-4327
internet service provider at regular intervals during the day to exchange (upload and download)
e m a i l .
Current Modem standards are

Standard Speed in bps
V.21 300
V.22 1200
V.22bis 2400
V.32 9600
V.32bis 14400
V.FC 19200
V.34 28800
V.34+ 33600
The speeds stated above are maximum speeds, and often, modems fail to achieve this. Errors
caused by noise on the telecommunication lines often cause modems to fall back to a much
lower speed, in order to reduce the number of errors. Thus a high speed modem rated at
33600bps often achieves a throughput of 9600bps due to the existing phone lines being too
error prone to support the higher rate.
Another problem that occurs is with modems that utilize compression techniques. Often,
compression is measured on the transmission of uncompressed files like text files. When these
same compression modems are asked to deal with the transfer of compressed files like .ZIP files,
they do not perform well, and effectively either transfer at a much reduced rate or no
compression at all. Some typical compression type modems are MNP4 and MNP5. In addition,
modems utilizing the different compression schemes often fail to communicate properly with
compression enabled. This is due to variances in manufacturers implementations of compression
algorithms.
Advantages Disadvantages Common Usage
Widely available Low speed Remote access
Low Cost Error Prone Low bandwidth
requirements like email
Most interoperate Technology changing Roving users
reliably rapidly
35
Tel. #: (034) 312-6189 / (034) 729-4327
Portable
Dedicated Lines (Leased Line)

Dedicated lines are fixed connections which do not involve dialing. They are permanent end to
end connections. The telecommunications company provides a dedicated high speed connection
between the two desired locations, at speeds ranging from as low as 9600bps to as high as
45Mbps. The higher the speed, the greater the cost, which is usually a fixed monthly rental
charge (does not include data charges, only rental charges).
The connection is available 24 hours a day, seven days a week, and is thus suited to companies
who want permanent connections between their office branches, or perhaps to a company who
wants a permanent connection to the Internet (they are providing a WWW server for people to
access).
The basic unit of measurement for dedicated lines is a T1 connection, which supports
1.544Mbps. A T3 connection supports 45Mbps. Fractional T1 circuits are available in units of
64Kbps, with connections of 384Kbps, 512Kbps and 768Kbps being common.
The connection is implemented with two units
· Channel Service Unit (CSU)

This provides the interface to the dedicated line
· Data Service Unit (DSU)

This interfaces between the CSU and the customers equipment, using RS232 for low
speeds up to 56Kbps, and V.35 (RS-422/499) for higher speeds
It is common to have the units as a single component. The CSU/DSU is normally the
demarcation zone which defines where the customers responsibility ends the the
telecommunications company begins. Most telecommunication companies provide the ability to
perform real-time monitoring of the connection via the CSU/DSU.
Private and secure Locked into Connecting large sites
Tele - c o mm uni c a tio ns
pricing regime
Cost effective for regular High monthly rental Establishment of a
transfer of large permanent internet
amounts of data presence
Fixed costs easier to
budget for than if you
pay for data transferred
Packet Switching (X.25)
Packet switching has been around for some time now. It is an established technology which
36
Tel. #: (034) 312-6189 / (034) 729-4327
sends data across a packet switched network in small parcels called packets. If the data packets
travel the same path to the destination, this is called virtual circuit, if packets can travel any
path, not necessarily the same as each other, this is called datagram.
Packet switched connections are normally in the speed of 19.2Kbps to 64Kbps, though some
higher speed connections may be available in certain countries. It is a dial-up switched
connection, in that the user pays connection charges, traffic charges and time charges. As such,
its not suitable for permanent connections.
X.25 was designed to be implemented over noisy analogue phone lines, thus has a lot of built in
error control. With today's relatively low error links, this can result in an unnecessary overhead.
An X.25 connection supports a number of virtual circuits which are each numbered. These
represent a time division of the available bandwidth of the connection. This division into virtual
circuits allows each VC to support a single device. X.25 uses the lower 3 levels of the OSI model.
The virtual circuit is a full duplex connection which is established for the duration of the call.
Devices which do not have built in packet switched support can be interfaced to a packet
switched network using a Packet Assembly/Disassembly (PAD) unit. This allows existing
computers or terminals to be connected.
Integrated Services Digital Network (ISDN)

ISDN was developed in order to provide the user with a single interface which supported a range
of different devices simultaneously. The basic ISDN connection is a 2B + D connection, that is, 2
B channels each of 64Kbps, and a single D channel of 16Kbps. The B channels are designed to
carry user data, whilst the D channel is meant to carry control and signaling information. This
format is known as the Basic Rate Interface (BRI), which also provides for frame control and
other heads, which gives an overall capacity of 192Kbps per BRI ISDN connection.
Higher capacity circuits are available. ISDN uses the existing telecommunications dial-up
infrastructure, though special ISDN connection interface boxes are required at the users
premises. Each B channel can be used separately or combined with other B channels to achieve
higher speeds.
The Primary Rate Interface (PRI) offers 23B channels and one D channel at 64Kbps (North
America and Japan) giving a total of 1.544Mbps. The PRI for Europe, Australia and some other
parts of the world is 30B channels and one D channel at 64Kbps giving a total of 2.048Mbps.
Not available in all centers or Periodic Internet Access (for
Low fixed cost
countries email etc)
Scalable (B circuits can be Not suited to mobile users (users LAN-LAN remote connections
combined for greater speeds) dialing in via remote access) which are not permanent
Fast call set up times
Line Drivers
Device designed to increase the strength of a signal, which helps ensure that the signal reaches
its destination.
37
Tel. #: (034) 312-6189 / (034) 729-4327
Over half of the broadband modems and line cards shipping today depend on Analog Devices'
high-performance line drivers. ADI's cable line drivers have been selected by the industry's
leading manufacturers for DOCSIS 1.0 and 2.0 cable modems as well as the newest and most
advanced cable set top boxes. ADI's xDSL line drivers are the most widely deployed in the world
and are used in both Central Office (CO) DSLAM and DLC line cards as well as Customer Premise
(CPE) modems. These high performance / low power dissipation drivers enable efficient high
port count line cards and superior customer modem performance.
Balanced Line Driver & Receiver
Sometimes, you just can't get rid of that %$#*& hum, no matter what you do. Especially with
long interconnects (such as to a powered sub-woofer), earth loops can be a real pain. For this
reason, just about all professional equipment uses balanced lines, which, if properly executed,
will eliminate the hum completely.
With this simple project, you can have balanced lines too, simply adapting the unbalanced inputs
and outputs of your hi-fi gear to become balanced, and then back to unbalanced at the other
end. You can even be extra cunning, and power the remote converter from the cables carrying
the signal. Professionally, this is called "Phantom Feed", and is used to power microphones and
other low current equipment. The version I have shown is actually a differential feed. Whilst not
as good as a true 48V phantom powering circuit, it does work, and makes an interesting
experiment (if nothing else).
Description
Before we start, a brief description of the standard (unbalanced) and balanced line is in order.
An unbalanced line is the type you have on the hi-fi, typically using an RCA connector, and
feeding the signal through a coaxial cable. The inner cable carries the signal, and the outer
shield is a screen, to prevent RF interference and general airborne noise from being picked up on
the signal lead.
This is fine, except for one small detail - the shield must also carry the signal! This is the return
path, and is required in all electrical connections - otherwise there is no current flow and the
system will probably just hum softly (or loudly) with none of the wanted signal.
The problem with electricity (like water and most people) is that it always takes the path of least
resistance, so when two pieces of equipment are connected, most likely there will be signal plus
hum, because of the dreaded earth loop. This is formed when both items are connected to the
mains earth, and also have their earth (zero Volt) points joined via the shields of the signal
leads.
In some cases it is possible to disconnect the earth at one end of the cable - some people have
also disconnected the mains (safety) earth. Both achieve the same result, but disconnecting the
mains earth is extremely dangerous. Unfortunately, the result is not always as one would hope.
38
Tel. #: (034) 312-6189 / (034) 729-4327
RF interference can become much worse, and other noises become apparent that were absent
before.
In contrast, a balanced connection uses two wires for the signal (much like the telephone
circuit), with the signal equal in amplitude in each wire, but opposite in phase. Only the out of
phase signal is detected by the remote balanced receiver, and any in phase (common mode)
signal is rejected. RF interference and other noise will be picked up equally by both wires in the
cable and so will be in phase. It will therefore be rejected by the receiver. In this way, it is
possible to have long interconnects, with the shield connected at one end only. This cuts the
earth loop, and the balanced connection ensures that only the wanted signal is passed through
to the amplifier(s).
It is very important that the two signal leads are twisted together, and the tighter the twist, the
better. The shield prevents RF and other interfering signals from causing too much trouble, and
the final signal should be free from hum and noise. The shield serves the same function in an
unbalanced circuit, but is less effective due to the fact that it usually serves as the signal return
path, and any signal that does get through becomes part of the signal.
The idea of this project is to give you some options, and to assist in creating a solution - it
should not be seen as a complete solution in itself. There are many variables - far too many to
be able to say with complete confidence that this WILL prevent all hum and other interference. It
might, but it is likely that some experimentation will be needed to get the results you want.
Note that for both transmitter and receiver, it is essential that 1% (or better) tolerance resistors
are used. If the trimming option is implemented, then you could use 5% resistors, and you will
be able to adjust the circuit to get maximum common mode rejection - however I recommend
that you use the 1% metal film resistors. For the small extra cost you get much higher stability,
and lower noise.
Figure 1 - Balanced Line Transmitter
The transmitter uses one opamp to buffer the signal, and the other to buffer and invert it. This
creates a balanced signal, where as the signal swings positive on one lead, it swings exactly the
same amount negative on the other. The 220 Ohm resistors at the output ensure stability with
39
Tel. #: (034) 312-6189 / (034) 729-4327
any lead, and are also used to attenuate the signal slightly. The signal swing from the
transmitter (across both wires) is double the voltage of the input signal.
Figure 2 - Balanced Line Receiver
The receiver has an optional 3.3k resistor across the inputs (RO) to help balance the input
against minor variations in cable impedance between the individual lines. The 220pF capacitor is
for HF rolloff, and will attenuate any RF that might get picked up by the lead. Any common mode
signal - where both leads provide a signal of the same polarity to the receiver circuit; typically
noise - is rejected, leaving only the wanted signal.
The rest of the circuit is a conventional balanced input stage. This particular configuration is
somewhat notorious for having unequal input impedances referred to earth. The 3.3k resistor
helps this (a little, anyway), and the 220pF capacitor also assists at higher frequencies. A more
complex circuit could have been used, but that would require 3 opamps, and for the intended
task would offer few real advantages.
With the capacitor value chosen, there is about 0.1dB attenuation at 20kHz - if you don't like
this idea, reduce the value to 100pF, however since 0.1dB is quite inaudible, there seems little
point.
With the values shown, there is a very slight overall gain of just over 0.3dB. This is unlikely to be
a problem. The circuit is designed to send the maximum level possible across the balanced
cable, and most of the attenuation is performed at the receiver. This will reduce any noise picked
up by a further 6dB for the transmitter / receiver pair.
It is also possible to ensure that the common mode rejection is as good as it can possibly get, by
making R10 variable. I suggest that you use an 8.2k fixed resistor, with a 5k multi-turn trimpot
in series. To balance the circuit, you may use an oscillator and millivoltmeter, or just a small
battery and a multimeter.
Join the two inputs together, and connect the battery or audio oscillator between the two joined
inputs and earth. Adjust the trimpot until there is 0V at the output - the common mode signal is
40
Tel. #: (034) 312-6189 / (034) 729-4327
now gone completely. Typically, this circuit will give a common mode rejection of about 40dB if
not trimmed as described, but trimming will let you improve on this considerably.
Although this transmitter and receiver pair will probably allow the use of unshielded
interconnects, I don't recommend this. Use a good quality shielded twin microphone cable. The
earthing of the shield should normally be done at the receiver end, but in some cases you might
find that the noise rejection is better if the transmitter end is earthed. Experimentation will be
needed.
Phantom Power (For the Experimenter)

It is possible to run this unit with the signal leads also carrying the power for the receiver. We
could use conventional phantom feed (using a 48V supply), but it is easier to use a differential
feed, with the +ve and -ve supply voltages on the signal leads. The basic scheme is shown in
Figure 3. This may be found to reduce common mode rejection, and it is essential that the
power is completely noise free, or it will become part of the signal! If this method is to be tried,
use the trimming option, so the supply feed resistors can be catered for. Alignment with a
battery will no longer be possible, and a signal generator will have to be used - with coupling
capacitors to each signal line.
The resistor RO must be removed in this configuration. I would strongly recommend that
an output coupling capacitor is used from the Out terminal of the receiver, since it is
likely that there will be some DC offset due to capacitor leakage currents.
Figure 3 - Differential "Phantom" Powering
The voltage to the receiver opamp is reduced by this technique, and the maximum signal level
will be reduced too. Only by experimenting will you be able to determine the exact power losses
and maximum signal level attainable. The tests I did indicate that you should not expect more
than about 1V RMS, but you might get more depending on the opamp used for the receiver. The
power feed resistors also load the transmitter, and reduce its output capability somewhat. You
might want to experiment with a low-power opamp (such as an LF351) as the receiver, as this
will allow a higher supply voltage and more signal before distortion.
41
Tel. #: (034) 312-6189 / (034) 729-4327
I would expect that the most likely use for this arrangement would be for a remote sub-woofer,
where it may be very inconvenient to have to create an additional power supply. I can't say that
I am completely happy with this arrangement, but it does work. A 48V phantom supply would be
better, but it is not likely that too many constructors will want to go to this trouble.
Figure 4 - Overall Frequency Response of Differential Feed and Both Circuits
The shield will now have to be connected at each end, but one end can be earthed using a 10
Ohm resistor, which should be bypassed with a 100nF capacitor. Again, experimentation is
needed to determine which end should have the "hard" earth. Make sure that the connectors are
polarised so that power cannot be connected the wrong way around. Diodes may be added if
desired to provide proper protection. These should be in parallel with the receiver filter caps
(C+ve and C-ve), because a series connection will reduce the voltage further (there is not a lot
to start with, so a further reduction would be a disaster).
Use of a multi-cored cable and suitable connectors will allow you to run the power supply on
separate wires in the cable, and the additional cost of the cable and connectors is likely to be
offset by the simpler circuit and better performance. This may not always be possible, hence the
differential phantom feed.
42
Tel. #: (034) 312-6189 / (034) 729-4327
Lesson IV:
Permanent Digital Networks
BT Kilo stream
About BT Kilo Stream
Private Services are specially designed for businesses which rely heavily on communications.
They provide permanently connected analogue and digital, voice and data circuits, between
different sites, for the exclusive use of the business.
Speech Line and Keyline analogue circuits are used for straightforward voice or low-speed data
applications. However, once you are regularly in touch with the same locations, making
increased use of e-mail or exchanging larger and larger data files, then switching to Kilo Stream
or the Kilo Stream N (the fastest Kilo Stream service for speech or data) digital services should
result in substantial cost savings.
In fact, because Kilo Stream circuits are leased for a fixed tariff, the more you use them, the
more cost effective they become. Kilo Stream comes in a range of different speeds, from
2.4kbit/s to 1,024kbit/s, to suit the needs and the budget of any business customer.
43
Tel. #: (034) 312-6189 / (034) 729-4327
KiloStream services offer a resilient, high quality connection, and are available with a range of
added-value packages to deliver an average performance target of 99.95%.
Key benefits of KiloStream include;
· Physical point-to-point connectivity - assuring high levels of security
· A state of the art network - providing very high levels of reliability and circuit availability
· Geographical coverage - extending over 99% of the UK
· 2-week provision
· Absence of modems - saving cost and adding reliability
· Connectivity applications, including data, voice and image; and, with suitable
multiplexors, a mixture of all three.
Key features of KiloStream N include;
· Cost effectiveness where ordinary KiloStream is insufficient
· A smooth evolution path for network growth
· Easy accommodation of specialist applications such as CAD/CAM and video-conferencing
· High quality transmission, performance and reliability
· Resilience - both separation/diversity & disaster recovery service available
· TotalCare support
· Nation-wide geographical coverage
· 6 week provision
The Private Service you choose will depend on the volume and kind of information you wish to
communicate
Analogue or digital circuits up to 64kbit/s are mainly used for low-speed voice or data
applications, such as PC terminal users at branch offices who need on-line access to a host
computer for electronic data interchange (EDI), file transfer or remote printing facilities.
At 64kbit/s, you can transmit voice and data, linking together local area networks (LANs) for
order processing and stock control, or make Internet access more widely available. And at
speeds of 128kbit/s and above, KiloStream N can be used for voice or data applications, to
connect complete systems, for high speed faxing, or video conferences.
44
Tel. #: (034) 312-6189 / (034) 729-4327
Finally, when you decide that you need more bandwidth, you'll find it simple to migrate to the
MegaStream service, enabling your business to access even more applications as it grows.
There is a Private Service to suit your precise geographical and traffic requirements. Whether
you work across the country or around the world, you will benefit from a single, seamless
private network which is right for your business.
The cost of upgrading from analogue to digital private services, and from KiloStream to
KiloStream N has reduced in real terms, making it more affordable for smaller businesses.
There are a variety of discounts, and a range of term-based contracts available to suit any
business, and a bandwidth-based option with discount levels which increase in line with usage.
All of which will help you to keep your costs down.
With the right Private Service, reliability comes as standard. With KiloStream you can expect a
resilient and high quality connection, achieving an average network performance target of
99.95% error free seconds a year. There is even the option of KiloStream Assured Restore
automatic back-up which offers very high levels of circuit availability. Moreover, with KiloStream,
you get BT's TotalCare maintenance service within tariff. That means for no extra cost, you will
have the peace of mind of a guaranteed fault response time of 4 hours, any time, any day - or
night.
Kilo Stream coverage is global and seamless. You can be sure of cost-effective migration into
even faster bandwidths when you want them. Kilo Stream is your fast track into the future of
telecoms.
BT Megastream
MegaStreams are available nationally. Generally, BT will provide the whole leased line from end
to end. MegaStream2, a 2Mbit/s leasedline, is the standard product.
FEATURES:
· MegaS tream provides ‘always on’ high speed voice and data transmission across
point-to-point Private Cicuits.
· It enables users to connect remote networks, mainframes and complete systems,

permanently and securely.
· MegaStream can drive a business to new levels of productivity.
· Companies that rely heavily on voice and data backbone networks, or who are expanding
their e-commerce operations should consider upgrading to a MegaStream solution.
· There is a choice of 2,8,34,45,140,155 or 622 Mbit/s bandwidth, Interface options that

include X.21, G.703 AND STM1.
45
Tel. #: (034) 312-6189 / (034) 729-4327
SONET/SDH
SONET and SDH are a set of related standards for synchronous data transmission over fiber
optic networks. SONET is short for Synchronous Optical NETwork and SDH is an acronym for
Synchronous Digital Hierarchy. SONET is the United States version of the standard published by
the American National Standards Institutue (ANSI). SDH is the international version of the
standard published by the International Telecommunications Union (ITU).
The SONET/SDH Digital Hierarchy
The following table lists the hierarchy of the most common SONET/SDH data rates:
Optical Level Electrical Level Line Rate (Mbps) Payload Rate (Mbps) Overhead Rate (Mbps) SDH Equivalent
OC-1 STS-1 51.840 50.112 1.728 -
OC-3 STS-3 155.520 150.336 5.184 STM-1
OC-12 STS-12 622.080 601.344 20.736 STM-4
OC-48 STS-48 2488.320 2405.376 82.944 STM-16
OC-192 STS-192 9953.280 9621.504 331.776 STM-64
OC-768 STS-768 39813.120 38486.016 1327.104 STM-256
Other rates (OC-9, OC-18, OC-24, OC-36, OC-96) are referenced in some of the standards
documents but were never widely implemented. It is possible other higher rates (e.g. OC-3072)
may be defined in in the future.
The "line rate" refers to the raw bit rate carried over the optical fiber. A portion of the bits
transferred over the line are designated as "overhead". The overhead carries information that
provides OAM&P (Operations, Administration, Maintenance, and Provisioning) capabilities such
as framing, multiplexing, status, trace, and performance monitoring. The "line rate" minus the
"overhead rate" yields the "payload rate" which is the bandwidth available for transferring user
data such as packets or ATM cells.
The SONET/SDH level designations sometimes include a "c" suffix (such as "OC-48c"). The "c"
suffix indicates a "concatenated" or "clear" channel. This implies that the entire payload rate is
available as a single channel of communications (i.e. the entire payload rate may be used by a
single flow of cells or packets). The opposite of concatenated or clear channel is "channelized".
In a channelized link the payload rate is subdivided into multiple fixed rate channels. For
example, the payload of an OC-48 link may be subdivided into four OC-12 channels. In this case
the data rate of a single cell or packet flow is limited by the bandwidth of an individual channel.
ANSI SONET Standards

The American National Standards Institute (ANSI) coordinates and approves SONET standards.
The standards are actually developed by Committee T1 which is sponsored by the Alliance for
Telecommunications Industry Solutions (ATIS) and accredited by ANSI to create network
interconnection and interoperability standards for the United States. T1X1 and T1M1 are the
primary T1 Technical Subcommittees responsible for SONET. T1X1 deals with "digital hierarchy
46
Tel. #: (034) 312-6189 / (034) 729-4327
and synchronization". T1M1 deals with "internetworking operations, administration,
maintenance, and provisioning (OAM&P). Listed below are some of the most commonly cited
SONET standards available from ANSI. Refer to the ANSI web site at http://www.ansi.org for a
complete list of SONET standards along with information on purchasing the documents.
· ANSI T1.105: SONET - Basic Description including Multiplex Structure, Rates and Formats
· ANSI T1.105.01: SONET - Automatic Protection Switching
· ANSI T1.105.02: SONET - Payload Mappings
· ANSI T1.105.03: SONET - Jitter at Network Interfaces
· ANSI T1.105.03a: SONET - Jitter at Network Interfaces - DS1 Supplement
· ANSI T1.105.03b: SONET - Jitter at Network Interfaces - DS3 Wander Supplement
· ANSI T1.105.04: SONET - Data Communication Channel Protocol and Architectures
· ANSI T1.105.05: SONET - Tandem Connection Maintenance
· ANSI T1.105.06: SONET - Physical Layer Specifications
· ANSI T1.105.07: SONET - Sub-STS-1 Interface Rates and Formats Specification
· ANSI T1.105.09: SONET - Network Element Timing and Synchronization
· ANSI T1.119: SONET - Operations, Administration, Maintenance, and Provisioning

(OAM&P) - Communications
· ANSI T1.119.01: SONET: OAM&P Communications Protection Switching Fragment
Lesson V:
ISDN Networks and Equipment
47
Tel. #: (034) 312-6189 / (034) 729-4327
Multiple BRIs may be used where PRIs are required on the customer site, but PRI from the
carrier may be either unavailable or prohibitively expensive.
This solution is also an simple and low-cost method of using BRIs to provide fractional PRIs (with
fewer than 30 "B" channels). Convert the BRIs into one or more PRIs.
Benefits include:
· Providing PRIs where they may not be available
· Using low cost BRIs (both installation, deposit and rental) to reduce costs
· Using BRIs to build a Fractional PRI where the carrier

may not offer a sub-30 "B" channel PRI option.
Liberator can also assist in Gateway type applications

or where a piece of comms equipment has a different
interface to that of the network or installed base.
48
Tel. #: (034) 312-6189 / (034) 729-4327
In the example below a PRI Gateway uses Liberator to extract a PRI from an otherwise BRI
environment. No changes are needed to the network or PABX. This application is explored in
more detail in the VoIP Migration and Gateway application pages.
ISDN (Integrated Services Digital Network) is an all digital communications line that allows for
the transmission of voice, data, video and graphics, at very high speeds, over standard
communication lines. ISDN provides a single, common interface with which to access digital
communications services that are required by varying devices, while remaining transparent to
the user. Due to the large amounts of information that ISDN lines can carry, ISDN applications
are revolutionizing the way businesses communicate.ISDN is not restricted to public telephone
networks alone; it may be transmitted via packet switched networks, telex, CATV networks, etc.
The ISDN is illustrated here in relation to the OSI model:
ISDN applications
49
Tel. #: (034) 312-6189 / (034) 729-4327
ISDN Channels:
B Channel
· Operate at 64 Kbps. Carries information for user services including voice,

audio,
video and digital data.
D Channel
· Operate at 16 Kbps. Carries signals between the user and the network. This
may also
carry user data packets.
H Channel
· Operate at N X 64 Kbps. Carrries information for user services including
voice,
audio, video and digital data.
Types of ISDN
· Narrow Band ISDN
· Broad Band ISDN- Not used in India.
Narrow Band ISDN-User Network Interface
· Basic Rate Access (BRA): 2B + D

2 Channels of 64 Kbps for Speech and Data
1 Channel of 16 Kbps for Signalling
· Primary Rate Access (PRA): 30B + D

30 Channels of 64 Kbps to carry Speech and Data
50
Tel. #: (034) 312-6189 / (034) 729-4327
ISDN is based on a number of fundamental building blocks. First, there are two types of ISDN
"channels" or communication paths:
· B - c h a n n e l
The Bearer ("B") channel is a 64 kbps channel which can be used for voice, video, data, or
multimedia calls. B-channels can be aggregated together for even higher bandwidth
applications.
· D - c h a n n e l
The Delta ("D") channel can be either a 16 kbps or 64 kbps channel used primarily for
communications (or "signaling") between switching equipment in the ISDN network and
the ISDN equipment at your site.
These ISDN channels are delivered to the user in one of two pre-defined configurations:
· Basic Rate Interface (BRI)

BRI is the ISDN service most people use to connect to the Internet. An ISDN BRI
connection supports two 64 kbps B-channels and one 16 kbps D-channel over a standard
phone line. BRI is often called "2B+D" referring to its two B-channels and one D-channel.
The D-channel on a BRI line can even support low-speed (9.6 kbps) X.25 data, however,
this is not a very popular application in the United States.
· Primary Rate Interface (PRI)

ISDN PRI service is used primarily by large organizations with intensive communications
51
Tel. #: (034) 312-6189 / (034) 729-4327
needs. An ISDN PRI connection supports 23 64 kbps B-channels and one 64 kbps
D-channel (or 23B+D) over a high speed DS1 (or T-1) circuit. The European PRI
configuration is slightly different, supporting 30B+D.
BRI is the most common ISDN service for Internet access. A single BRI line can support up to
three calls at the same time because it is comprised of three channels (2B+D). Two voice, fax or
data "conversations," and one packet switched data "conversation" can take place at the same
time. Multiple channels or even multiple BRI lines can be combined into a single faster
connection depending on the ISDN equipment you have. Channels can be combined as needed
for a specific application (a large multimedia file transfer, for example), then broken down and
reassembled into individual channels for different applications (normal voice or data
transmissions).
What Do I Use It For?
ISDN offers the speed and quality that previously was only available to people who bought
expensive, point-to-point digital leased lines. Combined with its flexibility as a dial-up service,
ISDN has become the service of choice for many communications applications. Popular ISDN
applications include:
· Internet access
· Telecommuting/remote access to corporate computing
· Video conferencing
· Small and home office data networking
Why Should I Use ISDN to Access the Internet?
More and more people are discovering that ISDN is the right Internet answer.
As the Internet becomes more and more information-intensive with graphics, sound, video and
multimedia, your ability to take advantage of these new resources depends on the speed of your
Internet connection. Can your existing connection handle these large files quickly and cleanly?
Does it take forever to download files? Are your downloads frequently aborted because of
transmission errors?
With ISDN, your Internet access is:
· Even faster
By combining your two B-channels you have access to up to 128 kbps -- more than four
times as fast as a 28.8 kbps modem on a standard phone line. And ISDN's digital
technology assures you the cleanest connection to the Internet so you won't be slowed down by
re-transmissions because of old analog technology.
52
Tel. #: (034) 312-6189 / (034) 729-4327
· More efficient and economical
ISDN brings increased capabilities, reduced costs and improved productivity to organizations both
large and small. When you're looking for something on the Internet, you can get there faster. You
can be more productive because you aren't waiting as long to get to that next website or
download that large file.
ISDN Services
Six types of services

q Circuit switched calls over a B or H channel
q Semi-permanent connections over a B or H channel
q Packet switched calls over a B or H channel
q Packet switched calls over a D channel
q Frame relay calls over a B or H channel
q Frame relay calls over a D channel
ISDN Services (BRI & PRI)
Basic Rate Interface

BRI is provisioned with two 64 Kbps B-channels (bearer channels) and one 16 Kbps D-channel
(data channel). Each of the B-channels can support voice or data for POTS (Plain Old Telephone
Service), FAX, or internet access. They can also be "bonded" together for a single 128 Kbps
circuit.
Normally one B-channel is used for regular phone calls and the other B-channel is used for dial
up Internet access. The D-channel is most commonly used for retail credit card verification (i.e.
swiping devices or smart cash registers).
BRI Applications
· SOHO (Small Office/Home Office) applications (two phone lines on a single cable pair for
POTS, FAX, or dial-up Internet access)
· Video Conferencing (normally with bonded B-channels)
· Retail credit card verification (using the D-channel)
Primary Rate Interface
53
Tel. #: (034) 312-6189 / (034) 729-4327
PRI is provisioned with 23 64kps B-channels and one 64Kbps D-channel. Each of
the B-channels can support voice or data for POTS (Plain Old Telephone Service),
FAX, or Internet access. Multiple channels can also be bonded together to provide
for full motion video conferencing. The D-channel is a full 64Kbps and is used for
signaling.
PRI provides a direct digital connection via a 1.544 Mbps facility to customers
with PRI compatible CPE (Customer
Premise Equipment). A PRI will give you access to both voice and data services (such as DOD,
DID, inbound calls, outbound calls, 800 service, and circuit switched data) on a single circuit.
This eliminates the need for numerous individual dedicated circuits.
PRI Applications
· PBX to PBX connectivity (PBX Trunking)
· Videoconferencing
· Connecting dial-tone to ISPs (for dial-up Internet access traffic)
· Consolidation of multiple circuits onto a single facility (reduce line mileage charges)
PRI Channel Configurations

· 23B + D Channel Configuration- All ISDN-PRI arrangements must have at least one
23B + D channel arrangement. The D channel is for signaling and control functions. The
twenty-three B channels provide 64 Kbps paths for the transfer of customer information.
· 23B + Backup D Channel Configuration- This feature provides a backup D channel as

a standby spare, in the event that the primary D channel fails. It is required when more
than forty-seven B channels (three or more pipes) are controlled by a single primary D
channel. If the first D channel fails, the signaling switches to the backup D channel
automatically.
Available Features
· Circuit Switched Voice- digital voice transmission provides clear transmissions for voice
communications.
· Circuit Switched Data (Clear Channel 64 Kbps)- With its out-of-band signaling,
ISDN-PRI offers clear 64 Kbps channels for data communications.
· Dedicated B Channel Configuration- Services such as DOD, DID, inbound calls,

outbound calls, and 800 service can be directly assigned to specific B channels, similar to
Digital Hand-off Service.
· Call-by-Call Service Selection- As an option to the dedicated B channel arrangement, B

channels may be configured to access multiple services on a per-call basis. The customer
54
Tel. #: (034) 312-6189 / (034) 729-4327
premises equipment signals the local central office as to what type of service to access for
each call. This feature brings about trunking efficiency and potential savings in trunking
costs.
· Calling Line ID- ISDN-PRI is the only technology available that allows PBX users to have
access to the directory number ( up to 10-digits) of the calling party. Directory number
availability mirrors Caller ID service.
Passive Bus Communication for ISDN
An apparatus for providing passive bus communication in an ISDN without use of services of
central office includes a passive bus suitable for ISDN D-channel frame communication, the
passive bus having an echo channel and having a plurality of terminal devices couples to the
passive bus. A receiving circuit is coupled to the passive bus for receiving D-channel frames
containing a SAPI address transmitted from the terminal devices over the passive bus. A
decoding circuit is coupled to the receiving circuit for decoding D-channel addresses transmitted
from the terminal devices over the passive bus. The decoding circuit includes a circuit for
determining if one of the D-channel frames from the terminal devices includes a predetermined
SAPI address. A switching circuit is coupled to and responsive to the decoding circuit, and
implements a logical communications channel between two or more of the plurality of terminal
devices when the D-channel frame includes the predetermined SAPI address. The switching
circuit echoes D-channel over the echo channel of the passive bus for receipt by the terminal
devices (TE) coupled to the passive bus and inhibits transmission of the D-channel frames to the
central office when the D-channel frames include the predetermined SAPI address. The TE
monitors the D-echo channel to receive the local passive bus communication in addition to
contention resolution.
ISDN Number and Address:

An ISDN address comprises of an ISDN number plus some additional digits that
identify a Specific terminal beyond the point designed by the ISDN number
Country Code National Subscriber Number ISDN Sub

Destination Address
<------- National ISDN Number ------------->
<------------------------------- International ISDN Number ---------->
<------------------------------- ISDN Address---------------------------------------------->
The international ISDN number has a maximum length of 15 digits. Sub address provide
additional
addressing capacity outside of ISDN Numbering plan. It allows upto 4 digits in length that is
transparent to
the public Network.
55
Tel. #: (034) 312-6189 / (034) 729-4327
ISDN Addressing
q E.164 designed for ISDN allows up to 15 digits
= Superset of E.163 for telephony (12 digits)
q Country code: 1 to 3 digits
q National Destination Code: Provider ID or Area code
q ISDN Address = ISDN number + ISDN subaddress
Country
Code
National
Destination
Code
ISDN
Subscriber
Number
ISDN Subaddress
(Max 40 digits)
National ISDN Number
International ISDN Number (max 15 digits)
ISDN Address (max 55 digits)
Raj Jain The Ohio State University
18
q X.121 Data Networks
Other Addressing Structures Other Addressing Structures
Zone Network term. number
Data country code National number
Country code National significant number 9
Telex destination code National telex number 8
Initial domain
identifier
Domain specific
part
Authority and
format identifier
E.163
Country code PDN code
Data Network Identification Code
q ISO 7498
Other Addressing (Cont.)
q IDI = Initial domain identifier
q DSP = Domain specific part
q AFI = Authority and format identifier (Six
authorities):
m Four ITU controlled: Packet-switched Data
Networks (PSDN), Telex, Packet-switched
Telephone Networks (PSTN), ISDN.
56
Tel. #: (034) 312-6189 / (034) 729-4327
m Two ISO Controlled:
q ISO geographic domain: Assigned by countries
q International organization domain, e.g., NATO.
q AFI = 44 Þ ISDN in decimal, 45 Þ ISDN in binary
ISDN Equipments
Because ISDN is such a flexible service, you'll need to understand a few more components than
you would with an Internet connection over your standard phone line. This tutorial provides help
getting started with ISDN and more technical details about ISDN.
You can click on the diagram below for more information.
Types Of Equipment
ISDN requires different equipment than analog dial-up or even digital leased line service. To
connect to the Internet, your equipment should include:
Network Termination Device 1 (NT1) and Power Supply
· Network Termination Device 1 (NT1)

The NT1 is a simple device that serves as an interface between the ISDN BRI line and your
other ISDN equipment. It converts the physical wiring interface delivered by Southwestern
Bell to the wiring interface needed by your ISDN equipment, and also provides a testing
point for troubleshooting.
Many ISDN terminal adapters and some ISDN routers (see below) have the NT1 function
built-in. This makes for an easier installation and also reduces the total cost of your ISDN
setup. However, a separate NT1 is more flexible in that it can support multiple ISDN
devices.
· Power Supply
The power supply plugs into a standard wall outlet and provides power to the ISDN line.
Unlike a standard phone line, Southwestern Bell does not provide the power on the ISDN
57
Tel. #: (034) 312-6189 / (034) 729-4327
line. For this reason, we recommend that customers consider keeping their analog phone
service as insurance for use during emergency power outages.
ISDN Routers
These devices perform a function similar to that of a standard router. Using an ISDN router,
multiple computers on a LAN can share a single ISDN BRI connection. Because ISDN routers use
Ethernet connections (typically 10 Mbps), they can take full advantage of ISDN's speed. Many of
the most popular ISDN routers also support analog voice, modem, or fax applications, as well as
sophisticated network management capabilities. ISDN routers are typically more than twice as
expensive as TAs, but they are often worth the money since they allow multiple computers on a
small LAN to leverage your ISDN investment.
Physical Interfaces
The ISDN standard defines several physical wiring interfaces, but most users only need to be
familiar with one or two.
· U - I n t e r f a c e
The U-interface is the 2-wire interface your phone company delivers for connection to the
NT1. Many of the newer ISDN networking devices, such as the 3Com Impact, include a
built-in internal NT-1 and power supply, so they can connect directly to the U-interface.
Manufacturers may describe this feature as a "built-in NT-1" or simply as a U-Interface
ISDN TA.
· S/T Interface
The S/T-interface is the 4-wire interface between the NT1 and the ISDN networking
equipment such as an ISDN TA or router. An S/T interface is used when the NT1 is a
separate device.
· Other interfaces
The interface between your ISDN networking equipment and your computer is usually one
of the standard industry interfaces. For example, an External TA will use the computer's
serial COM port such as RS232. ISDN routers will use a standard Ethernet connection,
either directly to a computer's NIC card or via an intermediary Ethernet hub.
Configuring your ISDN Line and Equipment

You will need the following information to program your ISDN equipment. Make sure that you
receive this information when you order your ISDN line.
Switch Type
The "engines" of the ISDN phone network are the complex network switches which deliver the
service. There are two dominant switches that provide ISDN: Lucent Technology's (formerly a
part of AT&T) 5ESS and Northern Telecom's DMS100. While those two switches provide the
58
Tel. #: (034) 312-6189 / (034) 729-4327
same basic features and functionality, they differ in how they interact with your ISDN
equipment. The DMS100 will also vary according to which software version is being used. It is
important that you find out which switch type and which software version will be providing you
with ISDN service, so you can order your ISDN service and set your ISDN networking equipment
parameters correctly.
In Southwestern Bell Internet Services territory, the possible switches and software versions
are:
· Lucent Technology (formerly a part of AT&T) 5ESS - NI2 (National ISDN version 2) and/or
AT&T custom ISDN software
· Northern Telecom DMS100 - Custom ISDN software
· Northern Telecom DMS100 - NI1 (National ISDN version 1) software
ISDN Phone Number (Directory Number)

Your ISDN phone line will be assigned a phone number just like a standard phone line. However,
depending on which kind of switch you are served from and how you are going to use the ISDN
service, you may get one phone number per ISDN line or one phone number for each ISDN
B-channel. It is important for you to define how you plann to use your ISDN line so
Southwestern Bell can assign the correct number of phone numbers.
· D M S 1 0 0
A DMS switch always assumes a multipoint configuration. If you are served from a
DMS-100 switch, you should receive two phone numbers, one for each B-channel.
· 5 E S S
If you receive your ISDN service from a 5ESS switch, you need to choose either a
"point-to-point" or "multipoint" configuration. If you only intend to connect a single
device/application to your ISDN line, then you only need the point-to-point configuration.
With the point-to-point configuration you are assigned a single phone number per ISDN
line (not one for each B-channel). If you intend to connect multiple devices/applications,
then you need the multipoint configuration. With multipoint configuration you are assigned
a phone number for each device connected.
Service Profile Identifier (SPID)
A SPID is an additional identifier used to identify the ISDN device to the telephone network. A
SPID looks like a telephone number with extra digits. However, depending on which kind of
switch you are served from and how you are going to use the ISDN service, you may not need a
SPID or you may need a SPID for each B-channel, or each device. It is important for you to
define how you plan to use your ISDN line so Southwestern Bell can assign the correct number
of SPIDs.
59
Tel. #: (034) 312-6189 / (034) 729-4327
· D M S 1 0 0
A DMS switch always assumes a multipoint configuration. If you are served from a
DMS-100 switch, you should receive two SPIDs, one for each B-channel.
· 5 E S S
If you receive your ISDN service from a 5ESS switch, you need to choose either a
"point-to-point" or "multipoint" configuration. If you only intend to connect a single
device/application (such as the 3COM Impact) to your ISDN line, then you only need the
point-to-point configuration and you are not assigned any SPIDs. If you intend to connect
multiple devices/applications, then you need the multipoint configuration. For example,
connecting the 3COM Impact's analog port to an analog phone would be a multipoint
configuration. With the multipoint configuration you are assigned a SPID for each device
connected.
Terminal Identifier (TID)
Specific to a National ISDN-1 BRI line from a DMS100 switch, is the need for a terminal identifier
(TID). The TID is comprised of two additional digits used in conjunction with the SPID when
initializing devices. The TID is intended for use on all non-initializing terminals. All terminals in
use today are initializing terminals, and most do not require a specific TID. To minimize
confusion, it is recommended that you use "00" on each terminal device, no matter how many
terminal devices there are. For further clarification, you should check with your ISDN equipment
vendor for their recommendation.
Wiring your Location for ISDN

Inside Wiring
By regulation, Southwestern Bell ISDN service ends at what is called the demarcation point
("demarc") usually just outside your residence or in an apartment building basement. You are
responsible for the wiring from the demarcation point to your ISDN equipment including the wall
jacks. You will want your ISDN phone jacks close to your ISDN equipment for the best
performance. You can choose to have Southwestern Bell install and maintain this "inside wiring"
for an additional charge, or you can use an electrical contractor.
While some homes and offices may need to be re-wired for ISDN, most will not. The copper
twisted pair wiring that currently provides standard analog phone service can be successfully
used for ISDN. However, with the increasingly popularity of multiple lines you may not have
spare wiring available for your ISDN service. Therefore, additional cabling may be necessary.
60
Tel. #: (034) 312-6189 / (034) 729-4327
ISDN Phone Jacks
There are three types of jacks associated with ISDN. It is important to check your equipment
documentation to verify which jacks you need and then order the correct jack. Most terminal
adapters come with the necessary cabling to plug into regular RJ11 phone jacks.
· R J 1 1
This is the standard analog phone jack, and is used to deliver 2-wire service. The phone
company will often install this jack for ISDN unless otherwise requested. However, some
NT1s required the wider RJ45 or SJA11C jack. The 3Com Impact phone cable has an RJ11
plug on one end to connect to a RJ11 wall jack.
· R J 4 5
This jack is slightly wider than the RJ11, and has 8 pins but can still be used to deliver
2-wire service such as ISDN BRI. Again, some NT1s require this jack and their associated
connecting cable with the RJ45 plug will not fit into an RJ11 jack. The 3Com Impact phone
cable has an RJ45 plug on one end for the RJ45 jack on the back of the Impact unit itself.
· S J A 1 1
This is identical to the RJ45 jack, but is a non-regulated product and therefore is
significantly less expensive than the RJ45. Specifically request this jack when ordering
your ISDN service.
61
Tel. #: (034) 312-6189 / (034) 729-4327
Lesson VI:
Packet switched Networks & x.25
Refers to protocols in which messages are divided into packets before they are sent. Each packet
is then transmitted individually and can even follow different routes to its destination. Once all
the packets forming a message arrive at the destination, they are recompiled into the original
message.
Most modern Wide Area Network (WAN) protocols, including TCP/IP, X.25, and Frame Relay, are
based on packet-switching technologies. In contrast, normal telephone service is based on a
circuit-switching technology, in which a dedicated line is allocated for transmission between two
parties. Circuit-switching is ideal when data must be transmitted quickly and must arrive in the
same order in which it's sent. This is the case with most real-time data, such as live audio and
video. Packet switching is more efficient and robust for data that can withstand some delays in
transmission, such as e-mail messages and Web pages.
A new technology, ATM, attempts to combine the best of both worlds -- the guaranteed delivery
of circuit-switched networks and the robustness and efficiency of packet-switching networks.
X.25
A popular standard for packet-switching networks. The X.25 standard was approved by the
CCITT (now the ITU) in 1976. It defines layers 1, 2, and 3 in the OSI Reference Model.
An X.25 network transfers data via packet switching. With this method, information
is taken from many different users and combined into discrete data packets. These
data packets are then forwarded to the Packet Data Network (PDN). Each data
packet is quickly routed through the network "cloud" to its destination using self-contained
routing information.
Packet Switching
Packet switching uses "virtual" circuits; the data is characterized into packets which
are switched in a logical fashion over a circuit shared by many different subscribers.
Unlike circuit switching, where the user actually has exclusive use of the circuit (a
dedicated connection), a packet switched user has a "virtual" connection. The
connection only appears to be dedicated. Instead of creating a permanent link
between parties, the packet-switched circuit is set up on demand and lasts for the
duration of that call only.
A primary advantage of the X.25 network is that packet switching offers a
significant cost savings compared to circuit switching. It is similar to dial-up for data
but your business will only have to pay for the time that the caller is talking.
Originally designed as a secure method for the transport of voice traffic over analog
lines, CCITT X.25 (as well as X.3, X.28, X.29, X.75 and X.480) specifies how
terminals talk to packet forming devices, how these packet assemblers talk to
62
Tel. #: (034) 312-6189 / (034) 729-4327
packet switches, and how packet switching nodes talk to each other.
X.25 Networks
In an X.25 network, a Packet Assembler/Disassembler (PAD) assembles individual
asynchronous transmissions from many DTEs into a single, synchronous X.25
packet. This synchronous packet can be up to 128 data bytes long and resembles
an IBM SDLC block with a few extra control bytes.
The PAD acts as a point-to-point 56 Kbps statistical multiplexer and uses buffers to
send packets to an X.25 switch. This switch separates and routes the packets to
their destination according to a predetermined algorithm. Each packet may then
take a different route through multiple switches within the X.25 network cloud.
Because a large amount of errors are often experienced when using analog lines,
X.25 uses an intricate acknowledge and retransmission scheme. As packets move
through the network, each switch checks the packets for errors, acknowledges
receipt and retransmits as necessary. An X.25 PAD is also used at the receiving end
to disassemble the X.25 synchronous packets into individual asynchronous user
information.
An X.25 network may be used in a variety of environments. For instance, X.25 is
well suited in applications where:
X.25 Applications
1.Communications are primarily asynchronous (though frequent synchronous
applications are now being used).
2.Line quality may not be good (X.25's error correction capabilities overcome poor
line quality).
3.Data volume is relatively small and bursty.
4.A company wants to use packet switching to decrease transmission expenses.
PVC
Permanent virtual circuit, a virtual circuit that is permanently available. The only difference
between a PVC and a switched virtual circuit (SVC) is that an SVC must be reestablished each
time data is to be sent. Once the data has been sent, the SVC disappears. PVCs are more
efficient for connections between hosts that communicate frequently.
PVCs play a central role in Frame Relay networks. They're also supported in some other types of
networks, such as X.25.
SVC
Switched virtual circuit, a temporary virtual circuit that is set up and used only as long as data
is being transmitted. Once the communication between the two hosts is complete, the SVC
disappears. In contrast, a permanent virtual circuit (PVC) remains available at all times.
The X.25 SVC Address Key Paths screen (#162) in Figure 7-8 “X.25 SVC Address Key Paths” is
displayed when you press the [Go To SVCPATH] function key at the General X.25
63
Tel. #: (034) 312-6189 / (034) 729-4327
Configuration screen (Figure 7-5 “General X.25 Protocol Screen”). It is also displayed when you
type the path name:
@NETXPORT.NI.NIname.PROTOCOL.X25.SVCPATH
in the Command window of any screen and press the [Enter] key, where NIname is a
configured X.25 NI.
Figure 7-8 X.25 SVC Address Key Paths
The X.25 address key is a label which associates an X.25 address with an IP address from the
network directory. This provides you the address of the remote host and the values of the
connection parameters you selected to use when communicating with that host. Every remote
address defined in the path table must be assigned a default facilities set. You may configure
up to 2048 SVC address keys under an X.25 NI, and if configuring multiple X.25 NI's,
no address key can be used more than once per system.
The default facilities set must be one of the defined facility sets in the X.25 User Facility Set
screen (NETXPORT.NI.NIname.PROTOCOL.X25.FACSET).
64
Tel. #: (034) 312-6189 / (034) 729-4327
POOL is the X.25 address key reserved for calls to and from nodes whose addresses are not
defined in this X.25 SVC Address Key Path screen. When a POOL X.25 address key is used, any
system, even one that is not identified in this screen, can access this node. HP recommends that
you use the name portion of the formal node name (name.domain.organization) as the X.25
address key. You can have a maximum of 2048 address keys in the SVC path tables and 128
address keys in the PVC path tables. If configuring multiple X.25 NI's, no address key can
be used more than once per system. POOL can also be used with level 3 programmatic
access when specifying an X.25 address directly in a NetIPC call (for example, the IPCDEST call)
Fields
X.25 address key (Required.) The X.25 address key identifies a remote node to which your
node can establish a connection. The address key can have up to eight
alphanumeric characters, the first of which must be alphabetic.
X.25 address This is the X.25 address of the remote node for X.25 public data networks
(PDN) or a private X.25 network. The X.25 address can have up to 15 digits.
The X.25 address will not be used if you configure a POOL address key, or if
you are configuring a link for a DDN network.
Default: None.
Default facilities set name

The name of one of the facility sets you defined at the User Facility Set
screen. This set of facilities is associated with the connections you have
previously defined. This field is required if you define an address key.
Default: None
Security The level of security you wish to assign to this particular entry. The possible
values are as follows:
· IN is the level of security you assign to accept only incoming calls from
the specified remote address.
· OU is the level of security you assign to accept only outgoing calls to

the specified remote address. All incoming calls are rejected.
· IO is the level of security you assign to accept both incoming and

outgoing calls.
· LK is the level of security you assign to lock this entry so that no calls,
incoming or outgoing, are accepted. LK is useful if you are using POOL
to accept calls from all nodes, but you want to exclude a few nodes
from accessing this node. Enter the nodes you want to restrict in this
65
Tel. #: (034) 312-6189 / (034) 729-4327
screen and specify LK as the security.
x.25 Overview
X.25 is an International Telecommunication Union-Telecommunication Standardization Sector

(ITU-T) protocol standard for WAN communications that defines how connections between user
devices and network devices are established and maintained. X.25 is designed to operate
effectively regardless of the type of systems connected to the network. It is typically used in the
packet-switched networks (PSNs) of common carriers, such as the telephone companies.
Subscribers are charged based on their use of the network. The development of the X.25
standard was initiated by the common carriers in the 1970s. At that time, there was a need for
WAN protocols capable of providing connectivity across public data networks (PDNs). X.25 is
now administered as an international standard by the ITU-T.
X.25 Devices and Protocol Operation

X.25 network devices fall into three general categories: data terminal equipment (DTE), data
circuit-terminating equipment (DCE), and packet-switching exchange (PSE). Data terminal
equipment devices are end systems that communicate across the X.25 network. They are
usually terminals, personal computers, or network hosts, and are located on the premises of
individual subscribers. DCE devices are communications devices, such as modems and packet
switches, that provide the interface between DTE devices and a PSE, and are generally located in
the carrier's facilities. PSEs are switches that compose the bulk of the carrier's network. They
transfer data from one DTE device to another through the X.25 PSN. Figure 17-1 illustrates the
relationships among the three types of X.25 network devices.
Figure 17-1 DTEs, DCEs, and PSEs Make Up an X.25 Network
66
Tel. #: (034) 312-6189 / (034) 729-4327
Packet Assembler/Disassembler
The packet assembler/disassembler (PAD) is a device commonly found in X.25 networks. PADs
are used when a DTE device, such as a character-mode terminal, is too simple to implement the
full X.25 functionality. The PAD is located between a DTE device and a DCE device, and it
performs three primary functions: buffering (storing data until a device is ready to process it),
packet assembly, and packet disassembly. The PAD buffers data sent to or from the DTE device.
It also assembles outgoing data into packets and forwards them to the DCE device. (This
includes adding an X.25 header.) Finally, the PAD disassembles incoming packets before
forwarding the data to the DTE. (This includes removing the X.25 header.) Figure 17-2 illustrates
the basic operation of the PAD when receiving packets from the X.25 WAN.
Figure 17-2 The PAD Buffers, Assembles, and Disassembles Data Packets
X . 2 5 Session
Establis
hment
X . 2 5 s ess io ns
a r e
establish
ed when one DTE
device c o nt a cts
another t o
request a
communi
cation s e s s io n .
The DTE device
67
Tel. #: (034) 312-6189 / (034) 729-4327
that receives the request can either accept or refuse the connection. If the request is accepted,
the two systems begin full-duplex information transfer. Either DTE device can terminate the
connection. After the session is terminated, any further communication requires the
establishment of a new session.
X.25 Virtual Circuits

A virtual circuit is a logical connection created to ensure reliable communication between two
network devices. A virtual circuit denotes the existence of a logical, bidirectional path from one
DTE device to another across an X.25 network. Physically, the connection can pass through any
number of intermediate nodes, such as DCE devices and PSEs. Multiple virtual circuits (logical
connections) can be multiplexed onto a single physical circuit (a physical connection). Virtual
circuits are demultiplexed at the remote end, and data is sent to the appropriate destinations.
Figure 17-3 illustrates four separate virtual circuits being multiplexed onto a single physical
circuit.
Figure 17-3 Virtual Circuits Can Be Multiplexed onto a Single Physical Circuit
T w o types of
X.25 virtual circuits exist: switched and permanent. Switched virtual circuits (SVCs) are
temporary connections used for sporadic data transfers. They require that two DTE devices
establish, maintain, and terminate a session each time the devices need to communicate.
Permanent virtual circuits (PVCs) are permanently established connections used for frequent and
consistent data transfers. PVCs do not require that sessions be established and terminated.
Therefore, DTEs can begin transferring data whenever necessary because the session is always
active.
The basic operation of an X.25 virtual circuit begins when the source DTE device specifies the
virtual circuit to be used (in the packet headers) and then sends the packets to a locally
connected DCE device. At this point, the local DCE device examines the packet headers to
determine which virtual circuit to use and then sends the packets to the closest PSE in the path
of that virtual circuit. PSEs (switches) pass the traffic to the next intermediate node in the path,
which may be another switch or the remote DCE device.
When the traffic arrives at the remote DCE device, the packet headers are examined and the
destination address is determined. The packets are then sent to the destination DTE device. If
68
Tel. #: (034) 312-6189 / (034) 729-4327
communication occurs over an SVC and neither device has additional data to transfer, the virtual
circuit is terminated.
The X.25 Protocol Suite

The X.25 protocol suite maps to the lowest three layers of the OSI reference model. The
following protocols are typically used in X.25 implementations: Packet-Layer Protocol (PLP), Link
Access Procedure, Balanced (LAPB), and those among other physical-layer serial interfaces
(such as EIA/TIA-232, EIA/TIA-449, EIA-530, and G.703). Figure 17-4 maps the key X.25
protocols to the layers of the OSI reference model.
Figure 17-4 Key X.25 Protocols Map to the Three Lower Layers of the OSI Reference Model
Packet-Layer Protocol
PLP is the X.25 network layer protocol. PLP manages packet exchanges between DTE devices
across virtual circuits. PLPs also can run over Logical Link Control 2 (LLC2) implementations on
LANs and over Integrated Services Digital Network (ISDN) interfaces running Link Access
Procedure on the D channel (LAPD).
The PLP operates in five distinct modes: call setup, data transfer, idle, call clearing, and
restarting.
69
Tel. #: (034) 312-6189 / (034) 729-4327
Call setup mode is used to establish SVCs between DTE devices. A PLP uses the X.121
addressing scheme to set up the virtual circuit. The call setup mode is executed on a
per-virtual-circuit basis, which means that one virtual circuit can be in call setup mode while
another is in data transfer mode. This mode is used only with SVCs, not with PVCs.
Data transfer mode is used for transferring data between two DTE devices across a virtual
circuit. In this mode, PLP handles segmentation and reassembly, bit padding, and error and flow
control. This mode is executed on a per-virtual-circuit basis and is used with both PVCs and
SVCs.
Idle mode is used when a virtual circuit is established but data transfer is not occurring.
It is executed on a per-virtual-circuit basis and is used only with SVCs.
Call clearing mode is used to end communication sessions between DTE devices and to
terminate SVCs. This mode is executed on a per-virtual-circuit basis and is used only with SVCs.
Restarting mode is used to synchronize transmission between a DTE device and a locally
connected DCE device. This mode is not executed on a per-virtual-circuit basis. It affects all the
DTE device's established virtual circuits.
Four types of PLP packet fields exist:
• General Format Identifier (GFI)—Identifies packet parameters, such as whether the

packet carries user data or control information, what kind of windowing is being used, and
whether delivery confirmation is required.
• Logical Channel Identifier (LCI)—Identifies the virtual circuit across the local DTE/DCE
interface.
• Packet Type Identifier (PTI)—Identifies the packet as one of 17 different PLP packet
types.
• User Data—Contains encapsulated upper-layer information. This field is present only in data
packets. Otherwise, additional fields containing control information are added.
Link Access Procedure, Balanced

LAPB is a data link layer protocol that manages communication and packet framing between DTE
and DCE devices. LAPB is a bit-oriented protocol that ensures that frames are correctly ordered
and error-free.
70
Tel. #: (034) 312-6189 / (034) 729-4327
Three types of LAPB frames exist: information, supervisory, and unnumbered. The information
frame (I-frame) carries upper-layer information and some control information. I-frame functions
include sequencing, flow control, and error detection and recovery. I-frames carry send- and
receive-sequence numbers. The supervisory frame (S-frame) carries control information.
S-frame functions include requesting and suspending transmissions, reporting on status, and
acknowledging the receipt of I-frames. S-frames carry only receive-sequence numbers. The
unnumbered frame (U frame) carries
control information. U-frame functions
include link setup and disconnection, as
well as error reporting. U frames carry no
sequence numbers.
The X.21bis Protocol
X.21bis is a physical layer protocol used in

X.25 that defines the electrical and
mechanical procedures for using the physical
medium. X.21bis handles the activation and
deactivation of the physical medium
connecting DTE and DCE devices. It supports point-to-point connections, speeds up to 19.2
kbps, and synchronous, full-duplex transmission over four-wire media. Figure 17-5 shows the
format of the PLP packet and its relationship to the LAPB frame and the X.21bis frame.
Figure 17-5 The PLP Packet Is Encapsulated Within the LAPB Frame and the X.21bis Frame
LAPB Frame Format

LAPB frames include a header, encapsulated data, and a trailer. Figure 17-6 illustrates the
format of the LAPB frame and its relationship to the PLP packet and the X.21bis frame.
The following descriptions summarize the fields illustrated in Figure 17-6:
• Flag—Delimits the beginning and end of the LAPB frame. Bit stuffing is used to ensure that
the flag pattern does not occur within the body of the frame.
• Address—Indicates whether the frame carries a command or a response.
• Control—Qualifies command and response frames and indicates whether the frame is an
I-frame, an S-frame, or a U-frame. In addition, this field contains the frame's sequence number
and its function (for example, whether receiver-ready or disconnect). Control frames vary in
length depending on the frame type.
• Data—Contains upper-layer data in the form of an encapsulated PLP packet.
• FCS—Handles error checking and ensures the integrity of the transmitted data.
71
Tel. #: (034) 312-6189 / (034) 729-4327
Figure 17-6 An LAPB Frame Includes a Header, a Trailer, and Encapsulated Data
X.121 Address Format
X.121 addresses are used by the X.25 PLP in call setup mode to establish SVCs. Figure
17-7 illustrates the format of an X.121 address.
The X.121 Address field includes the International Data Number (IDN), which consists of two fields: the
Data Network Identification Code (DNIC) and the National Terminal Number (NTN).
DNIC is an optional field that identifies the exact PSN in which the destination DTE device is located. This
field is sometimes omitted in calls within the same PSN. The DNIC has two subfields: Country and PSN.
The Country subfield specifies the country in which the destination PSN is located. The PSN field specifies
the exact PSN in which the destination DTE device is located.
The NTN identifies the exact DTE device in the PSN for which a packet is destined. This field varies in
length.
72
Tel. #: (034) 312-6189 / (034) 729-4327
Lesson VII:
Frame Relay
Sometimes referred to as Fast packet, it is designed for modern networks which do not need lots
of error recovery (unlike packet switching). Typical Frame relay connections range from 56Kbps
to 2Mbps. Frame relay is similar to packet switching X.25, but is more streamlined giving higher
performance and greater efficiency.
Frame relay, like X.25, implements multiple virtual circuits over a single connection, but does so
using statistical multiplexing techniques which yields a much more flexible and efficient use of
the available bandwidth. FR includes a cyclic redundancy check (CRC) for detecting corrupted
data, but does not include any mechanism for corrected corrupted data.
In addition, because many higher level protocols include their own flow control algorithms, FR
implements a simple congestion notification mechanism to notify the user when the network is
nearing saturation.
F r a m e F o r m a t
The format of FR frames is shown in the diagram below. Flags define a frames start and end.
The address field is 16 bytes long, 10 of which comprise the actual circuit ID (Data Link
Connection Identifier). The DLCI identifies the logical connection that is multiplexed into the
physical channel. Three bits of the address field are allocated to congestion control.
FR also supports multi-casting, the ability to

send to more than one destination
simultaneously. Four reserved DLCI
values (1019 to 1022) are designated as
multicast groups.
A d v a nt a Commo
ges n Usage
Disadvantages
Relatively high initial
Low incremental cost per Interconnecting lots of
connection (PVC) remote LAN's together
cost
73
Tel. #: (034) 312-6189 / (034) 729-4327
Exploits recent advances in
network technology
Supports multicasting
A d d i t i o n a l R e f e r e n c e s
Asynchronous Transfer Mode (ATM)

ATM breaks data into small chunks of fixed size cells (48 bytes of data plus a 5 byte overhead).
ATM is designed for handling large amounts of data across long distances using a high speed
backbone approach. Rather than allocating a dedicated virtual circuit for the duration of each
call, data is assembled into small packets and statistically multiplexed according to their traffic
characteristics.
One problem with other protocols which implement virtual connections is that some time slots
are wasted if no data is being transmitted. ATM avoids this by dynamically allocating bandwidth
for traffic on demand. This means greater utilization of bandwidth and better capacity to handle
heavy load situations.
When an ATM connection is requested, details concerning the connection are specified which
allow decisions to be made concerning the route and handling of the data to be made. Typical
details are the type of traffic [video requires higher priority], destination, peak and average
bandwidth requirements [which the network can use to estimate resources and cost structures],
a cost factor [which allows the network to chose a route which fits within the cost structure] and
other parameters.
UNDER SONSTRUCTION
155Mbps
622Mbps
Digital Subscriber Line (xDSL)

xDSL is a high speed solution that allows megabit bandwidth from tele-communications to
customers over existing copper cable, namely, the installed telephone pair to the customers
premises (called the local loop). With the high penetration and existing infrastructure of copper
cable to virtually everyone's home (for providing a voice telephone connection), xDSL offers
significant increases in connection speed and data transfers for access to information.
In many cases, the cost of relaying fiber optic cable to subscriber premises is prohibitive. As
access to the Internet and associated applications like multi-media, tele-conferencing and on
demand video become pervasive, the speed of the local loop (from the subscriber to the
telephone company) is now a limiting factor. Current technology during the 1980's and most of
the 1990's has relied on the use of the analog modem with connection rates up to 56Kbps, which
is too slow for most applications except simple email.
74
Tel. #: (034) 312-6189 / (034) 729-4327
xDSL is a number of different technologies that provide megabit speeds over the local loop,
without the use of amplifiers or repeaters. This technology works over non-loaded local loops
(loaded coils were added by telephone companies on some copper cable pairs to improve voice
quality). xDSL coexists with existing voice over the same cable pair, the subscriber is still able to
use their telephone, at the same time. This technology is referred to seamless.
To implement xDSL, a terminating device is required at each end of the cable, which accepts the
digital data and converts it to analogue signals for transmission over the copper cable. In this
respect, it is very similar to modem technology.
xDSL provides for both symmetric and asymmetric configurations.

Asymmetric Symmetric
Bandwidth is higher in one direction Bandwidth same in both directions
Suitable for Web Browsing Suitable for video-conferencing
Variations of xDSL
There are currently six variations of xDSL.
xDSL Technology Meaning Rate
2 x 64Kbps circuit switched
DSL Digital Subscriber Line 1 x 16Kbps packet switched
(similar to ISDN-BRI)
2.048Mbps over two pairs at
HDSL High-bit-rate DSL
a distance up to 4.2Km
Single-pair or Symmetric
S-HDSL/SDSL 768Kbps over a single pair
High-bit-rate DSL
ADSL Asymmetric DSL up to 6Mbps in one direction
An extension of ADSL which supports
RADSL Rate Adaptive DSL a variety of data rates depending upon
the quality of the local loop
Very High-bit-rate Up to 52Mbps in one direction and
VDSL
asymmetric DSL 2Mbps in the other direction.
Frame Relay is a high-performance WAN protocol that operates at the physical and data link
layers of the OSI reference model. Frame Relay originally was designed for use across
Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other
network interfaces as well. This chapter focuses on Frame Relay's specifications and applications
in the context of WAN services.
Frame Relay is an example of a packet-switched technology. Packet-switched networks enable

end stations to dynamically share the network medium and the available bandwidth. The
following two techniques are used in packet-switching technology:
• Variable-length packets
75
Tel. #: (034) 312-6189 / (034) 729-4327
• Statistical multiplexing
Variable-length packets are used for more efficient and flexible data transfers. These packets are
switched between the various segments in the network until the destination is reached.
Statistical multiplexing techniques control network access in a packet-switched network. The

advantage of this technique is that it accommodates more flexibility and more efficient use of
bandwidth. Most of today's popular LANs, such as Ethernet and Token Ring, are packet-switched
networks.
Frame Relay often is described as a streamlined version of X.25, offering fewer of the robust
capabilities, such as windowing and retransmission of last data that are offered in X.25. This is
because Frame Relay typically operates over WAN facilities that offer more reliable connection
services and a higher degree of reliability than the facilities available during the late 1970s and
early 1980s that served as the common platforms for X.25 WANs. As mentioned earlier, Frame
Relay is strictly a Layer 2 protocol suite, whereas X.25 provides services at Layer 3 (the network
layer) as well. This enables Frame Relay to offer higher performance and greater transmission
efficiency than X.25, and makes Frame Relay suitable for current WAN applications, such as LAN
interconnection.
Frame Relay Standardization

Initial proposals for the standardization of Frame Relay were presented to the Consultative
Committee on International Telephone and Telegraph (CCITT) in 1984. Because of lack of
interoperability and lack of complete standardization, however, Frame Relay did not experience
significant deployment during the late 1980s.
A major development in Frame Relay's history occurred in 1990 when Cisco, Digital Equipment
Corporation (DEC), Northern Telecom, and StrataCom formed a consortium to focus on Frame
Relay technology development. This consortium developed a specification that conformed to the
basic Frame Relay protocol that was being discussed in CCITT, but it extended the protocol with
features that provide additional capabilities for complex internetworking environments. These
Frame Relay extensions are referred to collectively as the Local Management Interface (LMI).
Since the consortium's specification was developed and published, many vendors have
announced their support of this extended Frame Relay definition. ANSI and CCITT have
subsequently standardized their own variations of the original LMI specification, and these
standardized specifications now are more commonly used than the original version.
Internationally, Frame Relay was standardized by the International Telecommunication

Union—Telecommunications Standards Section (ITU-T). In the United States, Frame Relay is an
American National Standards Institute (ANSI) standard.
Frame Relay Devices

Devices attached to a Frame Relay WAN fall into the following two general categories:
76
Tel. #: (034) 312-6189 / (034) 729-4327
• Data terminal equipment (DTE)
• Data circuit-terminating equipment (DCE)
DTEs generally are considered to be terminating equipment for a specific network and typically
are located on the premises of a customer. In fact, they may be owned by the customer.
Examples of DTE devices are terminals, personal computers, routers, and bridges.
DCEs are carrier-owned internetworking devices. The purpose of DCE equipment is to provide
clocking and switching services in a network, which are the devices that actually transmit data
through the WAN. In most cases, these are packet switches. Figure 10-1 shows the relationship
between the two categories of devices.
Figure 10-1 DCEs Generally Reside Within Carrier-Operated WANs
The connection between a DTE device and a DCE device consists of both a physical layer
component and a link layer component. The physical component defines the mechanical,
electrical, functional, and procedural specifications for the connection between the devices. One
of the most commonly used physical layer interface specifications is the recommended standard
(RS)-232 specification. The link layer component defines the protocol that establishes the
connection between the DTE device, such as a router, and the DCE device, such as a switch. This
chapter examines a commonly utilized protocol specification used in WAN networking: the Frame
Relay protocol.
Frame Relay Virtual Circuits

Frame Relay provides connection-oriented data link layer communication. This means that a
defined communication exists between each pair of devices and that these connections are
associated with a connection identifier. This service is implemented by using a Frame Relay
77
Tel. #: (034) 312-6189 / (034) 729-4327
virtual circuit, which is a logical connection created between two data terminal equipment (DTE)
devices across a Frame Relay packet-switched network (PSN).
Virtual circuits provide a bidirectional communication path from one DTE device to another and
are uniquely identified by a data-link connection identifier (DLCI). A number of virtual circuits
can be multiplexed into a single physical circuit for transmission across the network. This
capability often can reduce the equipment and network complexity required to connect multiple
DTE devices.
A virtual circuit can pass through any number of intermediate DCE devices (switches) located
within the Frame Relay PSN.
Frame Relay virtual circuits fall into two categories: switched virtual circuits (SVCs) and
permanent virtual circuits (PVCs).
Switched Virtual Circuits

Switched virtual circuits (SVCs) are temporary connections used in situations requiring only
sporadic data transfer between DTE devices across the Frame Relay network. A communication
session across an SVC consists of the following four operational states:
• Call setup—The virtual circuit between two Frame Relay DTE devices is established.
• Data transfer—Data is transmitted between the DTE devices over the virtual circuit.
• Idle—The connection between DTE devices is still active, but no data is transferred. If an
SVC remains in an idle state for a defined period of time, the call can be terminated.
• Call termination—The virtual circuit between DTE devices is terminated.
After the virtual circuit is terminated, the DTE devices must establish a new SVC if there is
additional data to be exchanged. It is expected that SVCs will be established, maintained, and
terminated using the same signaling protocols used in ISDN.
Few manufacturers of Frame Relay DCE equipment support switched virtual circuit connections.
Therefore, their actual deployment is minimal in today's Frame Relay networks.
Previously not widely supported by Frame Relay equipment, SVCs are now the norm. Companies
have found that SVCs save money in the end because the circuit is not open all the time.
Permanent Virtual Circuits

Permanent virtual circuits (PVCs) are permanently established connections that are used for
frequent and consistent data transfers between DTE devices across the Frame Relay network.
Communication across a PVC does not require the call setup and termination states that are
used with SVCs. PVCs always operate in one of the following two operational states:
• Data transfer—Data is transmitted between the DTE devices over the virtual circuit.
78
Tel. #: (034) 312-6189 / (034) 729-4327
• Idle—The connection between DTE devices is active, but no data is transferred. Unlike SVCs,
PVCs will not be terminated under any circumstances when in an idle state.
DTE devices can begin transferring data whenever they are ready because the circuit is
permanently established.
Data-Link Connection Identifier

Frame Relay virtual circuits are identified by data-link connection identifiers (DLCIs). DLCI
values typically are assigned by the Frame Relay service provider (for example, the telephone
company).
Frame Relay DLCIs have local significance, which means that their values are unique in the LAN,
but not necessarily in the Frame Relay WAN.
Figure 10-2 illustrates how two different DTE devices can be assigned the same DLCI value
within one Frame Relay WAN.
Figure 10-2 A Single Frame Relay Virtual Circuit Can Be Assigned Different DLCIs on Each End of a VC
Congestion-Control Mechanisms
Frame Relay reduces network overhead by implementing simple congestion-notification
mechanisms rather than explicit, per-virtual-circuit flow control. Frame Relay typically is
implemented on reliable network media, so data integrity is not sacrificed because flow control
can be left to higher-layer protocols. Frame Relay implements two congestion-notification
mechanisms:
• Forward-explicit congestion notification (FECN)
• Backward-explicit congestion notification (BECN)
FECN and BECN each is controlled by a single bit contained in the Frame Relay frame header.
The Frame Relay frame header also contains a Discard Eligibility (DE) bit, which is used to
identify less important traffic that can be dropped during periods of congestion.
79
Tel. #: (034) 312-6189 / (034) 729-4327
The FECN bit is part of the Address field in the Frame Relay frame header. The FECN mechanism
is initiated when a DTE device sends Frame Relay frames into the network. If the network is
congested, DCE devices (switches) set the value of the frames' FECN bit to 1. When the frames
reach the destination DTE device, the Address field (with the FECN bit set) indicates that the
frame experienced congestion in the path from source to destination. The DTE device can relay
this information to a higher-layer protocol for processing. Depending on the implementation,
flow control may be initiated, or the indication may be ignored.
The BECN bit is part of the Address field in the Frame Relay frame header. DCE devices set the
value of the BECN bit to 1 in frames traveling in the opposite direction of frames with their FECN
bit set. This informs the receiving DTE device that a particular path through the network is
congested. The DTE device then can relay this information to a higher-layer protocol for
processing. Depending on the implementation, flow-control may be initiated, or the indication
may be ignored.
Frame Relay Discard Eligibility

The Discard Eligibility (DE) bit is used to indicate that a frame has lower importance than other
frames. The DE bit is part of the Address field in the Frame Relay frame header.
DTE devices can set the value of the DE bit of a frame to 1 to indicate that the frame has lower
importance than other frames. When the network becomes congested, DCE devices will discard
frames with the DE bit set before discarding those that do not. This reduces the likelihood of
critical data being dropped by Frame Relay DCE devices during periods of congestion.
Frame Relay Error Checking

Frame Relay uses a common error-checking mechanism known as the cyclic redundancy check
(CRC). The CRC compares two calculated values to determine whether errors occurred during
the transmission from source to destination. Frame Relay reduces network overhead by
implementing error checking rather than error correction. Frame Relay typically is implemented
on reliable network media, so data integrity is not sacrificed because error correction can be left
to higher-layer protocols running on top of Frame Relay.
Frame Relay Local Management Interface

The Local Management Interface (LMI) is a set of enhancements to the basic Frame Relay
specification. The LMI was developed in 1990 by Cisco Systems, StrataCom, Northern Telecom,
and Digital Equipment Corporation. It offers a number of features (called extensions) for
managing complex internetworks. Key Frame Relay LMI extensions include global addressing,
virtual circuit status messages, and multicasting.
The LMI global addressing extension gives Frame Relay data-link connection identifier (DLCI)
values global rather than local significance. DLCI values become DTE addresses that are unique
in the Frame Relay WAN. The global addressing extension adds functionality and manageability
to Frame Relay internetworks. Individual network interfaces and the end nodes attached to
80
Tel. #: (034) 312-6189 / (034) 729-4327
them, for example, can be identified by using standard address-resolution and discovery
techniques. In addition, the entire Frame Relay network appears to be a typical LAN to routers
on its periphery.
LMI virtual circuit status messages provide communication and synchronization between Frame
Relay DTE and DCE devices. These messages are used to periodically report on the status of
PVCs, which prevents data from being sent into black holes (that is, over PVCs that no longer
exist).
The LMI multicasting extension allows multicast groups to be assigned. Multicasting saves
bandwidth by allowing routing updates and address-resolution messages to be sent only to
specific groups of routers. The extension also transmits reports on the status of multicast groups
in update messages.
Frame Relay Network Implementation

A common private Frame Relay network implementation is to equip a T1 multiplexer with both
Frame Relay and non-Frame Relay interfaces. Frame Relay traffic is forwarded out the Frame
Relay interface and onto the data network. Non-Frame Relay traffic is forwarded to the
appropriate application or service, such as a private branch exchange (PBX) for telephone
service or to a video-teleconferencing application.
A typical Frame Relay network consists of a number of DTE devices, such as routers, connected
to remote ports on multiplexer equipment via traditional point-to-point services such as T1,
fractional T1, or 56-Kb circuits. An example of a simple Frame Relay network is shown in Figure
10-3.
Figure 10-3 A Simple Frame Relay Network Connects Various Devices to Different Services over a WAN
81
Tel. #: (034) 312-6189 / (034) 729-4327
The majority of
Frame Relay
networks deployed
today are
provisioned by
service providers
that intend to offer
transmissio n
services to
customers. This is
often referred to as
a public Frame Relay
service. Frame Relay
is implemented in
both public
c a rrie r-p ro vid e d
networks and in
private enterprise
networks. The
following section
examines the two
methodologies for
deploying Frame
Relay.
Public Carrier-Provided Networks

In public carrier-provided Frame Relay networks, the Frame Relay switching equipment is
located in the central offices of a telecommunications carrier. Subscribers are charged based on
their network use but are relieved from administering and maintaining the Frame Relay network
equipment and service.
Generally, the DCE equipment also is owned by the telecommunications provider.

DTE equipment either will be customer-owned or perhaps will be owned by the
telecommunications provider as a service to the customer.
The majority of today's Frame Relay networks are public carrier-provided networks.
Private Enterprise Networks

More frequently, organizations worldwide are deploying private Frame Relay networks. In private
Frame Relay networks, the administration and maintenance of the network are the
82
Tel. #: (034) 312-6189 / (034) 729-4327
responsibilities of the enterprise (a private company). All the equipment, including the switching
equipment, is owned by the customer.
Frame Relay Frame Formats

To understand much of the functionality of Frame Relay, it is helpful to understand the structure
of the Frame Relay frame. Figure 10-4 depicts the basic format of the Frame Relay frame, and
Figure 10-5 illustrates the LMI version of the Frame Relay frame.
Flags indicate the beginning and end of the frame. Three primary components make up
the Frame Relay frame: the header and address area, the user-data portion, and the frame
check sequence (FCS). The address area, which is 2 bytes in length, is comprised of 10
bits representing the actual circuit identifier and 6 bits of fields related to congestion
management. This identifier commonly is referred to as the data-link connection identifier
(DLCI). Each of these is discussed in the descriptions that follow.
Standard Frame Relay Frame

Standard Frame Relay frames consist of the fields illustrated in Figure 10-4.
Figure 10-4 Five Fields Comprise the Frame Relay Frame
The following descriptions summarize the basic Frame Relay frame fields illustrated in Figure
10-4.
• Flags—delimit the beginning and end of the frame. The value of this field is always the same
and is represented either as the hexadecimal number 7E or as the binary number 01111110.
• Address—Contains the following information:
– DLCI—The 10-bit DLCI is the essence of the Frame Relay header. This value represents the
virtual connection between the DTE device and the switch. Each virtual connection that is
multiplexed onto the physical channel will be represented by a unique DLCI. The DLCI values
have local significance only, which means that they are unique only to the physical channel on
which they reside. Therefore, devices at opposite ends of a connection can use different DLCI
values to refer to the same virtual connection.
83
Tel. #: (034) 312-6189 / (034) 729-4327
– Extended Address (EA)—The EA is used to indicate whether the byte in which the EA value
is 1 is the last addressing field. If the value is 1, then the current byte is determined to be the
last DLCI octet. Although current Frame Relay implementations all use a two-octet DLCI, this
capability does allow longer DLCIs to be used in the future. The eighth bit of each byte of the
Address field is used to indicate the EA.
– C/R—The C/R is the bit that follows the most significant DLCI byte in the Address field. The
C/R bit is not currently defined.
– Congestion Control—This consists of the 3 bits that control the Frame Relay
congestion-notification mechanisms. These are the FECN, BECN, and DE bits, which are the last
3 bits in the Address field.
Forward-explicit congestion notification (FECN) is a single-bit field that can be set to a value of 1
by a switch to indicate to an end DTE device, such as a router, that congestion was experienced
in the direction of the frame transmission from source to destination. The primary benefit of the
use of the FECN and BECN fields is the capability of higher-layer protocols to react intelligently to
these congestion indicators. Today, DECnet and OSI are the only higher-layer protocols that
implement these capabilities.
Backward-explicit congestion notification (BECN) is a single-bit field that, when set to a value of
1 by a switch, indicates that congestion was experienced in the network in the direction opposite
of the frame transmission from source to destination.
Discard eligibility (DE) is set by the DTE device, such as a router, to indicate that the marked
frame is of lesser importance relative to other frames being transmitted. Frames that are
marked as "discard eligible" should be discarded before other frames in a congested network.
This allows for a basic prioritization mechanism in Frame Relay networks.
• Data—Contains encapsulated upper-layer data. Each frame in this variable-length field

includes a user data or payload field that will vary in length up to 16,000 octets. This field serves
to transport the higher-layer protocol packet (PDU) through a Frame Relay network.
• Frame Check Sequence—Ensures the integrity of transmitted data. This value is computed
by the source device and verified by the receiver to ensure integrity of transmission.
84
Tel. #: (034) 312-6189 / (034) 729-4327
LMI Frame Format
Frame Relay frames that conform to the LMI specifications consist of the fields illustrated in Figure 10-5.
Figure 10-5 Nine Fields Comprise the Frame Relay That Conforms to the LMI Format
The following descriptions summarize the fields illustrated in Figure 10-5.
• Flag—Delimits the beginning and end of the frame.
• LMI DLCI—Identifies the frame as an LMI frame instead of a basic Frame Relay frame. The
LMI-specific DLCI value defined in the LMI consortium specification is DLCI = 1023.
• Unnumbered Information Indicator—Sets the poll/final bit to zero.
• Protocol Discriminator—Always contains a value indicating that the frame is an LMI

frame.
• Call Reference—Always contains zeros. This field currently is not used for any purpose.
• Message Type—Labels the frame as one of the following message types:
– Status-inquiry message—Allows a user device to inquire about the status of the network.
– Status message—Responds to status-inquiry messages. Status messages include

keepalives and PVC status messages.
• Information Elements—Contains a variable number of individual information elements

(IEs). IEs consist of the following fields:
85
Tel. #: (034) 312-6189 / (034) 729-4327
– IE Identifier—Uniquely identifies the IE.
– IE Length—Indicates the length of the IE.
– Data—Consists of 1 or more bytes containing encapsulated upper-layer data.
• Frame Check Sequence (FCS)—Ensures the integrity of transmitted data.
Congestion Control
Congestion control is about controlling traffic entry into telecommunication networks, so as to
avoid congestive collapse by attempting to avoid; or by detecting oversubscription of any of the
processing or link capabilities of the intermediate nodes and networks and taking resource
reducing steps, such as sending packets more slowly. For instance, a max-min fair allocation of
data emission is a congestion control scheme.
Congestion Notification
A signaling technique used by data transmission systems in order to indicate the status of
network congestion. Devices that are communicating data across a network rely on congestion
notification to determine when to send or delay the transmission of data packets.
Forward congestion notification indicates to upstream data switching devices that data is being
transmitted through congested channels and some of the data or packets may be discarded.
Backward congestion notification indicates to downstream devices that data is going through
congested channels.
What is BECN/FECN?
In a frame relay network, FECN (forward explicit congestion notification) is a header bit
transmitted by the source (sending) terminal requesting that the destination (receiving) terminal
slow down its requests for data. BECN (backward explicit congestion notification) is a header bit
transmitted by the destination terminal requesting that the source terminal send data more
slowly. FECN and BECN are intended to minimize the possibility that packets will be discarded
(and this have to be resent) when more packets arrive than can be handled.
If the source terminal in a communication circuit generates frequent FECN bits, it indicates that
the available network bandwidth (at that time) is not as great as can be supported by the
destination terminal. Likewise, if the destination generates frequent BECN bits, it means the
available network bandwidth (at that time) is not as great as can be supported by the source. In
either case, the root cause is lack of available bandwidth at the times during which FECN or
BECN bits are generated. This can occur because of outdated or inadequate network
infrastructure, heavy network traffic, high levels of line noise, or portions of the system going
down. Identifying and resolving these issues can improve overall network performance,
especially when the system is called upon to carry a large volume of traffic.
86
Tel. #: (034) 312-6189 / (034) 729-4327
Lesson VIII:
ATM & SMDS
ATM:(Asynchronous Transfer Mode)
An international ISDN high-speed, high-volume, packet-switching transmission protocol

standard. ATM uses short, uniform, 53-btye cells to divide data into efficient, manageable
packets for ultrafast switching through a high performance communications network. The
53-byte cells contain 5-byte destination address headers and 48 data bytes. ATM is the first
packet-switched technology designed from the ground up to support integrated voice, video and
data communications applications. It is well suited to high speed WAN transmission bursts. ATM
currently accommodates transmission speeds from 64 Kbps to 622Mbps. ATM may support
gigabit speeds in the future.
SDMS: (Switched Multimegabit Data Service)
SMDS is a connectionless, cell-switched data transport service that offers total end-to-end
applications solutions. With SMDS, organizations have the flexibility they need for distributed
computing and bandwidth-intensive applications. At the same time, because SMDS supports
both existing and emerging technologies, it provides the scalability organizations need to
support the applications of the future.
Used to interconnect multiple node LANs and WANs through the public telephone network, SMDS
eliminates the need for carrier switches to establish a call path between two points of data
transmission. Instead, SMDS access devices pass 53-byte cells to a carrier switch. The switch
reads addresses and forwards cells one-by-one over any available path to the desired endpoint.
SMDS addresses ensure that the cells arrive in the right order. The benefit of this connectionless
"any-to-any" service is that it puts an end to the need for precise traffic-flow predictions and
connections only between fixed locations. With no need for a pre-defined path between devices,
data can travel over the least congested routes in an SMDS network, providing faster
transmission, increased security and greater flexibility to add or drop network sites.
Asynchronous Transfer Mode Switching

Asynchronous Transfer Mode (ATM) is an International Telecommunication
Union-Telecommunications Standards Section (ITU-T) standard for cell relay wherein information
for multiple service types, such as voice, video, or data, is conveyed in small, fixed-size cells.
ATM networks are connection-oriented. This chapter provides summaries of ATM protocols,
87
Tel. #: (034) 312-6189 / (034) 729-4327
services, and operation. Figure 27-1 illustrates a private ATM network and a public ATM network
carrying voice, video, and data traffic.
Figure 27-1 A Private ATM Network and a Public ATM

Network Both Can Carry Voice, Video, and Data Traffic
Standards
ATM is based on the efforts of the ITU-T Broadband Integrated Services Digital Network
(B-ISDN) standard. It was originally conceived as a high-speed transfer technology for voice,
video, and data over public networks. The ATM Forum extended the ITU-T's vision of ATM for use
over public and private networks. The ATM Forum has released work on the following
specifications:
• User-to-Network Interface (UNI) 2.0
• UNI 3.0
• UNI 3.1
• UNI 4.0
• Public-Network Node Interface (P-NNI)
• LAN Emulation (LANE)
• Multiprotocol over ATM
ATM Devices and the Network Environment

ATM is a cell-switching and multiplexing technology that combines the benefits of circuit
switching (guaranteed capacity and constant transmission delay) with those of packet switching
(flexibility and efficiency for intermittent traffic). It provides scalable bandwidth from a few
megabits per second (Mbps) to many gigabits per second (Gbps). Because of its asynchronous
nature, ATM is more efficient than synchronous technologies, such as time-division multiplexing
(TDM).
With TDM, each user is assigned to a time slot, and no other station can send in that time slot. If
a station has much data to send, it can send only when its time slot comes up, even if all other
time slots are empty. However, if a station has nothing to transmit when its time slot comes up,
the time slot is sent empty and is wasted. Because ATM is asynchronous, time slots are available
88
Tel. #: (034) 312-6189 / (034) 729-4327
on demand with information identifying the source of the transmission contained in the header of
each ATM cell.
ATM Cell Basic Format

ATM transfers information in fixed-size units called cells. Each cell consists of 53 octets, or bytes.
The first 5 bytes contain cell-header information, and the remaining 48 contain the payload
(user information). Small, fixed-length cells are well suited to transferring voice and video traffic
because such traffic is intolerant of delays that result from having to wait for a large data packet
to download, among other things. Figure 27-2 illustrates the basic format of an ATM cell.
Figure 27-2 An ATM Cell Consists of a Header and Payload Data
ATM Devices
An ATM network is made up of an ATM switch and ATM endpoints. An ATM switch is responsible
for cell transit through an ATM network. The job of an ATM switch is well defined: It accepts the
incoming cell from an ATM endpoint or another ATM switch. It then reads and updates the cell
header information and quickly switches the cell to an output interface toward its destination. An
ATM endpoint (or end system) contains an ATM network interface adapter. Examples of ATM
endpoints are workstations, routers, digital service units (DSUs), LAN switches, and video
coder-decoders (CODECs). Figure 27-3 illustrates an ATM network made up of ATM switches and
ATM endpoints.
Figure 27-3 An ATM Network Comprises ATM Switches and Endpoints
89
Tel. #: (034) 312-6189 / (034) 729-4327
ATM Network Interfaces
An ATM network consists of a set of ATM switches interconnected by point-to-point ATM links or
interfaces. ATM switches support two primary types of interfaces: UNI and NNI. The UNI
connects ATM end systems (such as hosts and routers) to an ATM switch. The NNI connects two
ATM switches.
Depending on whether the switch is owned and located at the customer's premises or is publicly
owned and operated by the telephone company, UNI and NNI can be further subdivided into
public and private UNIs and NNIs. A private UNI connects an ATM endpoint and a private ATM
switch. Its public counterpart connects an ATM endpoint or private switch to a public switch. A
private NNI connects two ATM switches within the same private organization. A public one
connects two ATM switches within the same public organization.
An additional specification, the broadband intercarrier interface (B-ICI), connects two public
switches from different service providers. Figure 27-4 illustrates the ATM interface specifications
for private and public networks.
Figure 27-4 ATM Interface Specifications Differ for Private and Public Networks
90
Tel. #: (034) 312-6189 / (034) 729-4327
ATM Cell Header Format
An ATM cell header can be one of two formats: UNI or NNI. The UNI header is used for
communication between ATM endpoints and ATM switches in private ATM networks. The NNI
header is used for communication between ATM switches. Figure 27-5 depicts the basic ATM cell
format, the ATM UNI cell header format, and the ATM NNI cell header format.
Figure 27-5 An ATM Cell, ATM UNI Cell, and ATM NNI Cell Header Each Contain 48 Bytes of Payload
Unlike the UNI, the NNI header does not include the Generic Flow Control (GFC) field.
Additionally, the NNI header has a Virtual Path Identifier (VPI) field that occupies the first 12
bits, allowing for larger trunks between public ATM switches.
91
Tel. #: (034) 312-6189 / (034) 729-4327
ATM Cell Header Fields
In addition to GFC and VPI header fields, several others are used in ATM cell header fields. The
following descriptions summarize the ATM cell header fields illustrated in Figure 27-5:
• Generic Flow Control (GFC)—Provides local functions, such as identifying multiple stations
that share a single ATM interface. This field is typically not used and is set to its default value of
0 (binary 0000).
• Virtual Path Identifier (VPI)—In conjunction with the VCI, identifies the next destination
of a cell as it passes through a series of ATM switches on the way to its destination.
• Virtual Channel Identifier (VCI)—In conjunction with the VPI, identifies the next
destination of a cell as it passes through a series of ATM switches on the way to its destination.
• Payload Type (PT)—Indicates in the first bit whether the cell contains user data or control
data. If the cell contains user data, the bit is set to 0. If it contains control data, it is set to 1.
The second bit indicates congestion (0 = no congestion, 1 = congestion), and the third bit
indicates whether the cell is the last in a series of cells that represent a single AAL5 frame (1 =
last cell for the frame).
• Cell Loss Priority (CLP)—Indicates whether the cell should be discarded if it encounters
extreme congestion as it moves through the network. If the CLP bit equals 1, the cell should be
discarded in preference to cells with the CLP bit equal to 0.
• Header Error Control (HEC)—Calculates checksum only on the first 4 bytes of the header.
HEC can correct a single bit error in these bytes, thereby preserving the cell rather than
discarding it.
ATM Services
Three types of ATM services exist: permanent virtual circuits (PVC), switched virtual circuits
(SVC), and connectionless service (which is similar to SMDS).
PVC allows direct connectivity between sites. In this way, a PVC is similar to a leased line.
Among its advantages, PVC guarantees availability of a connection and does not require call
setup procedures between switches. Disadvantages of PVCs include static connectivity and
manual setup. Each piece of equipment between the source and the destination must be
manually provisioned for the PVC. Furthermore, no network resiliency is available with PVC.
An SVC is created and released dynamically and remains in use only as long as data is being
transferred. In this sense, it is similar to a telephone call. Dynamic call control requires a
signaling protocol between the ATM endpoint and the ATM switch. The advantages of SVCs
92
Tel. #: (034) 312-6189 / (034) 729-4327
include connection flexibility and call setup that can be handled automatically by a networking
device. Disadvantages include the extra time and overhead required to set up the connection.
ATM Virtual Connections

ATM networks are fundamentally connection-oriented, which means that a virtual channel (VC)
must be set up across the ATM network prior to any data transfer. (A virtual channel is roughly
equivalent to a virtual circuit.)
Two types of ATM connections exist: virtual paths, which are identified by virtual path identifiers,
and virtual channels, which are identified by the combination of a VPI and a virtual channel
identifier (VCI).
A virtual path is a bundle of virtual channels, all of which are switched transparently across the
ATM network based on the common VPI. All VPIs and VCIs, however, have only local significance
across a particular link and are remapped, as appropriate, at each switch.
A transmission path is the physical media that transports virtual channels and virtual paths.
Figure 27-6 illustrates how VCs concatenate to create VPs, which, in turn, traverse the media or
transmission path.
Figure 27-6 VCs Concatenate to Create VPs
ATM Switching Operations

The basic operation of an ATM switch is straightforward: The cell is received across a
link on a known VCI or VPI value. The switch looks up the connection value in a local translation
table to determine the outgoing port (or ports) of the connection and the new VPI/VCI value of
the connection on that link. The switch then retransmits the cell on that outgoing link with the
appropriate connection identifiers. Because all VCIs and VPIs have only local significance across
a particular link, these values are remapped, as necessary, at each switch.
ATM Reference Model

The ATM architecture uses a logical model to describe the functionality that it supports. ATM
functionality corresponds to the physical layer and part of the data link layer of the OSI
reference model.
The ATM reference model is composed of the following planes, which span all layers:
• Control—This plane is responsible for generating and managing signaling requests.
93
Tel. #: (034) 312-6189 / (034) 729-4327
• User—This plane is responsible for managing the transfer of data.
• Management—This plane contains two components:
– Layer management manages layer-specific functions, such as the detection of failures and
protocol problems.
– Plane management manages and coordinates functions related to the complete system.
The ATM reference model is composed of the following ATM layers:
• Physical layer—Analogous to the physical layer of the OSI reference model, the ATM
physical layer manages the medium-dependent transmission.
• ATM layer—Combined with the ATM adaptation layer, the ATM layer is roughly analogous to
the data link layer of the OSI reference model. The ATM layer is responsible for the simultaneous
sharing of virtual circuits over a physical link (cell multiplexing) and passing cells through the
ATM network (cell relay). To do this, it uses the VPI and VCI information in the header of each
ATM cell.
• ATM adaptation layer (AAL)—Combined with the ATM layer, the AAL is roughly analogous
to the data link layer of the OSI model. The AAL is responsible for isolating higher-layer
protocols from the details of the ATM processes. The adaptation layer prepares user data for
conversion into cells and segments the data into 48-byte cell payloads.
Finally, the higher layers residing above the AAL accept user data, arrange it into packets, and
hand it to the AAL. Figure 27-7 illustrates the ATM reference model.
94
Tel. #: (034) 312-6189 / (034) 729-4327
Figure 27-7 The ATM Reference Model Relates to the Lowest Two Layers of the OSI Reference Model
The ATM Physical Layer

The ATM physical layer has four functions: Cells are converted into a bitstream, the transmission
and receipt of bits on the physical medium are controlled, ATM cell boundaries are tracked, and
cells are packaged into the appropriate types of frames for the physical medium. For example,
cells are packaged differently for SONET than for DS-3/E-3 media types.
The ATM physical layer is divided into two parts: the physical medium-dependent (PMD)
sublayer and the transmission convergence (TC) sublayer.
The PMD sublayer provides two key functions. First, it synchronizes transmission and reception
by sending and receiving a continuous flow of bits with associated timing information. Second, it
specifies the physical media for the physical medium used, including connector types and cable.
Examples of physical medium standards for ATM include Synchronous Digital
Hierarchy/Synchronous Optical Network (SDH/SONET), DS-3/E3, 155 Mbps over multimode fiber
(MMF) using the 8B/10B encoding scheme, and 155 Mbps 8B/10B over shielded twisted-pair
(STP) cabling.
95
Tel. #: (034) 312-6189 / (034) 729-4327
The TC sublayer has four functions: cell delineation, header error control (HEC) sequence
generation and verification, cell-rate decoupling, and transmission frame adaptation. The cell
delineation function maintains ATM cell boundaries, allowing devices to locate cells within a
stream of bits. HEC sequence generation and verification generates and checks
the header error control code to ensure valid data. Cell-rate decoupling maintains
synchronization and inserts or suppresses idle (unassigned) ATM cells to adapt the rate of valid
ATM cells to the payload capacity of the transmission system. Transmission frame adaptation
packages ATM cells into frames acceptable to the particular physical layer implementation.
ATM Adaptation Layers: AAL1

AAL1, a connection-oriented service, is suitable for handling constant bit rate sources (CBR),
such as voice and videoconferencing. ATM transports CBR traffic using circuit-emulation
services. Circuit-emulation service also accommodates the attachment of equipment currently
using leased lines to an ATM backbone network. AAL1 requires timing synchronization between
the source and the destination. For this reason, AAL1 depends on a medium, such as SONET,
that supports clocking.
The AAL1 process prepares a cell for transmission in three steps. First, synchronous samples (for
example, 1 byte of data at a sampling rate of 125 microseconds) are inserted into the Payload
field. Second, Sequence Number (SN) and Sequence Number Protection (SNP) fields are added
to provide information that the receiving AAL1 uses to verify that it has received cells in the
correct order. Third, the remainder of the Payload field is filled with enough single bytes to equal
48 bytes. Figure 27-8 illustrates how AAL1 prepares a cell for transmission.
Figure 27-8 AAL1 Prepares a Cell for Transmission So That the Cells Retain Their Order
96
Tel. #: (034) 312-6189 / (034) 729-4327
ATM
Adaptati
o L a y e r sn:
AAL2
Another traffic
type has timing
requirem
ents like CBR but
tends to b e
bursty in nature.
This is c a lle d
variable bit rate
( V B R ) traffic.
T h i s t yp ic a lly
includes services
character
ized as
packetize
d voice or video
that do not have a constant data transmission speed but that do have requirements similar to
constant bit rate services. AAL2 is suitable for VBR traffic. The AAL2 process uses 44 bytes of the
cell payload for user data and reserves 4 bytes of the payload to support the AAL2 processes.
VBR traffic is characterized as either real-time (VBR-RT) or as non-real-time (VBR-NRT). AAL2

supports both types of VBR traffic.
ATM Adaptation Layers: AAL3/4

AAL3/4 supports both connection-oriented and connectionless data. It was designed for network
service providers and is closely aligned with Switched Multimegabit Data Service (SMDS).
AAL3/4 is used to transmit SMDS packets over an ATM network.
AAL3/4 prepares a cell for transmission in four steps. First, the convergence sublayer (CS)
creates a protocol data unit (PDU) by prepending a beginning/end tag header to the frame and
appending a length field as a trailer. Second, the segmentation and reassembly (SAR) sublayer
fragments the PDU and prepends a header to it. Then the SAR sublayer appends a CRC-10
trailer to each PDU fragment for error control. Finally, the completed SAR PDU becomes the
Payload field of an ATM cell to which the ATM layer prepends the standard ATM header.
An AAL 3/4 SAR PDU header consists of Type, Sequence Number, and Multiplexing Identifier
fields. Type fields identify whether a cell is the beginning, continuation, or end of a message.
Sequence number fields identify the order in which cells should be reassembled. The Multiplexing
97
Tel. #: (034) 312-6189 / (034) 729-4327
Identifier field determines which cells from different traffic sources are interleaved on the same
virtual circuit connection (VCC) so that the correct cells are reassembled at the destination.
ATM Adaptation Layers: AAL5

AAL5 is the primary AAL for data and supports both connection-oriented and connectionless
data. It is used to transfer most non-SMDS data, such as classical IP over ATM and LAN
Emulation (LANE). AAL5 also is known as the simple and efficient adaptation layer (SEAL)
because the SAR sublayer simply accepts the CS-PDU and segments it into 48-octet SAR-PDUs
without reserving any bytes in each cell.
AAL5 prepares a cell for transmission in three steps. First, the CS sublayer appends a
variable-length pad and an 8-byte trailer to a frame. The pad ensures that the resulting PDU
falls on the 48-byte boundary of an ATM cell. The trailer includes the length of the frame and a
32-bit cyclic redundancy check (CRC) computed across the entire PDU. This allows the AAL5
receiving process to detect bit errors, lost cells, or cells that are out of sequence. Second, the
SAR sublayer segments the CS-PDU into 48-byte blocks. A header and trailer are not added (as
is in AAL3/4), so messages cannot be interleaved. Finally, the ATM layer places each block into
the Payload field of an ATM cell. For all cells except the last, a bit in the Payload Type (PT) field is
set to 0 to indicate that the cell is not the last cell in a series that represents a single frame. For
the last cell, the bit in the PT field is set to 1.
ATM Addressing
The ITU-T standard is based on the use of E.164 addresses (similar to telephone numbers) for
public ATM (B-ISDN) networks. The ATM Forum extended ATM addressing to include private
networks. It decided on the subnetwork or overlay model of addressing, in which the ATM layer
is responsible for mapping network layer addresses to ATM addresses. This subnetwork model is
an alternative to using network layer protocol addresses (such as IP and IPX) and existing
routing protocols (such as IGRP and RIP). The ATM Forum defined an address format based on
the structure of the OSI network service access point (NSAP) addresses.
Subnetwork Model of Addressing

The subnetwork model of addressing decouples the ATM layer from any existing higher-layer
protocols, such as IP or IPX. Therefore, it requires an entirely new addressing scheme and
routing protocol. Each ATM system must be assigned an ATM address, in addition to any
higher-layer protocol addresses. This requires an ATM address resolution protocol (ATM ARP) to
map higher-layer addresses to their corresponding ATM addresses.
NSAP Format ATM Addresses

The 20-byte NSAP-format ATM addresses are designed for use within private ATM networks,
whereas public networks typically use E.164 addresses, which are formatted as defined by
ITU-T. The ATM Forum has specified an NSAP encoding for E.164 addresses, which is used for
98
Tel. #: (034) 312-6189 / (034) 729-4327
encoding E.164 addresses within private networks, but this address can also be used by some
private networks.
Such private networks can base their own (NSAP format) addressing on the E.164 address of
the public UNI to which they are connected and can take the address prefix from the E.164
number, identifying local nodes by the lower-order bits.
All NSAP-format ATM addresses consist of three components: the authority and format identifier
(AFI), the initial domain identifier (IDI), and the domain-specific part (DSP). The AFI identifies
the type and format of the IDI, which, in turn, identifies the address allocation and
administrative authority. The DSP contains actual routing information.
Note Summarized another way, the first 13 bytes form the NSAP prefix that answers the
question, "Which switch?" Each switch must have a prefix value to uniquely identify it. Devices
attached to the switch inherit the prefix value from the switch as part of their NSAP address. The
prefix is used by switches to support ATM routing.
The next 6 bytes, called the end station identifier (ESI), identify the ATM element attached to
the switch. Each device attached to the switch must have a unique ESI value.
The last byte, called the selector (SEL) byte, identifies the intended process within the device
that the connection targets.
Three formats of private ATM addressing differ by the nature of the AFI and IDI. In the
NSAP-encoded E.164 format, the IDI is an E.164 number. In the DCC format, the IDI is a data
country code (DCC), which identifies particular countries, as specified in ISO 3166. Such
addresses are administered by the ISO National Member Body in each country. In the ICD
format, the IDI is an international code designator (ICD), which is allocated by the ISO 6523
registration authority (the British Standards Institute). ICD codes identify particular international
organizations.
The ATM Forum recommends that organizations or private network service providers use either
the DCC or the ICD formats to form their own numbering plan.
Figure 27-9 Three Formats of ATM Addresses Are Used for Private Networks
99
Tel. #: (034) 312-6189 / (034) 729-4327
ATM Address Fields
The following descriptions summarize the fields illustrated in Figure 27-9:
• AFI—Identifies the type and format of the address (E.164, ICD, or DCC).
• DCC—Identifies particular countries.
• High-Order Domain-Specific Part (HO-DSP)—Combines the routing domain (RD) and

the area identifier (AREA) of the NSAP addresses. The ATM Forum combined these fields to
support a flexible, multilevel addressing hierarchy for prefix-based routing protocols.
• End System Identifier (ESI)—Specifies the 48-bit MAC address, as administered by the
Institute of Electrical and Electronic Engineers (IEEE).
• Selector (SEL)—Is used for local multiplexing within end stations and has no network
significance.
• ICD—Identifies particular international organizations.
• E.164—Indicates the BISDN E.164 address.
100
Tel. #: (034) 312-6189 / (034) 729-4327
ATM Connections
ATM supports two types of connections: point-to-point and point-to-multipoint.
Point-to-point connects two ATM end systems and can be unidirectional (one-way
communication) or bidirectional (two-way communication). Point-to-multipoint connects a
single-source end system (known as the root node) to multiple destination end systems (known
as leaves). Such connections are unidirectional only. Root nodes can transmit to leaves, but
leaves cannot transmit to the root or to each other on the same connection. Cell replication is
done within the ATM network by the ATM switches where the connection splits into two or more
branches.
It would be desirable in ATM networks to have bidirectional multipoint-to-multipoint connections.

Such connections are analogous to the broadcasting or multicasting capabilities of shared-media
LANs, such as Ethernet and Token Ring. A broadcasting capability is easy to implement in
shared-media LANs, where all nodes on a single LAN segment must process all packets sent on
that segment.
Unfortunately, a multipoint-to-multipoint capability cannot be implemented by using AAL5, which

is the most common AAL to transmit data across an ATM network. Unlike AAL3/4, with its
Message Identifier (MID) field, AAL5 does not provide a way within its cell format to interleave
cells from different AAL5 packets on a single connection. This means that all AAL5 packets sent
to a particular destination across a particular connection must be received in sequence;
otherwise, the destination reassembly process will be incapable of reconstructing the packets.
This is why AAL5 point-to-multipoint connections can be only unidirectional. If a leaf node were
to transmit an AAL5 packet onto the connection, for example, it would be received by both the
root node and all other leaf nodes. At these nodes, the packet sent by the leaf could be
interleaved with packets sent by the root and possibly other leaf nodes, precluding the
reassembly of any of the interleaved packets.
ATM and Multicasting

ATM requires some form of multicast capability. AAL5 (which is the most common
AAL for data) currently does not support interleaving packets, so it does not support
multicasting.
If a leaf node transmitted a packet onto an AAL5 connection, the packet could be intermixed
with other packets and be improperly reassembled. Three methods have been proposed for
solving this problem: VP multicasting, multicast server, and overlaid point-to-multipoint
connection.
Under the first solution, a multipoint-to-multipoint VP links all nodes in the multicast group, and
each node is given a unique VCI value within the VP. Interleaved packets hence can be identified
101
Tel. #: (034) 312-6189 / (034) 729-4327
by the unique VCI value of the source. Unfortunately, this mechanism would require a protocol
to uniquely allocate VCI values to nodes, and such a protocol mechanism currently does not
exist. It is also unclear whether current SAR devices could easily support such a mode of
operation.
A multicast server is another potential solution to the problem of multicasting over an ATM
network. In this scenario, all nodes wanting to transmit onto a multicast group set up a
point-to-point connection with an external device known as a multicast server (perhaps better
described as a resequencer or serializer). The multicast server, in turn, is connected to all nodes
wanting to receive the multicast packets through a point-to-multipoint connection. The multicast
server receives packets across the point-to-point connections and then retransmits them across
the point-to-multipoint connection—but only after ensuring that the packets are serialized (that
is, one packet is fully transmitted before the next is sent). In this way, cell interleaving is
precluded.
An overlaid point-to-multipoint connection is the third potential solution to the problem of

multicasting over an ATM network. In this scenario, all nodes in the multicast group establish a
point-to-multipoint connection with each other node in the group and, in turn, become leaves in
the equivalent connections of all other nodes. Hence, all nodes can both transmit to and receive
from all other nodes. This solution requires each node to maintain a connection for each
transmitting member of the group, whereas the multicast-server mechanism requires only two
connections. This type of connection also requires a registration process for informing the nodes
that join a group of the other nodes in the group so that the new nodes can form the
point-to-multipoint connection. The other nodes must know about the new node so that they can
add the new node to their own point-to-multipoint connections. The multicast-server mechanism
is more scalable in terms of connection resources but has the problem of requiring a centralized
resequencer, which is both a potential bottleneck and a single point of failure.
ATM Quality of Service

ATM supports QoS guarantees comprising traffic contract, traffic shaping, and traffic policing.
A traffic contract specifies an envelope that describes the intended data flow. This envelope
specifies values for peak bandwidth, average sustained bandwidth, and burst size, among
others. When an ATM end system connects to an ATM network, it enters a contract with the
network, based on QoS parameters.
Traffic shaping is the use of queues to constrain data bursts, limit peak data rate, and smooth
jitters so that traffic will fit within the promised envelope. ATM devices are responsible for
adhering to the contract by means of traffic shaping. ATM switches can use traffic policing to
enforce the contract. The switch can measure the actual traffic flow and compare it against the
agreed-upon traffic envelope. If the switch finds that traffic is outside of the agreed-upon
parameters, it can set the cell-loss priority (CLP) bit of the offending cells. Setting the CLP bit
makes the cell discard eligible, which means that any switch handling the cell is allowed to drop
the cell during periods of congestion.
102
Tel. #: (034) 312-6189 / (034) 729-4327
ATM Signaling and Connection Establishment
When an ATM device wants to establish a connection with another ATM device, it sends a
signaling-request packet to its directly connected ATM switch. This request contains the ATM
address of the desired ATM endpoint, as well as any QoS parameters required for the
connection.
ATM signaling protocols vary by the type of ATM link, which can be either UNI signals or NNI
signals. UNI is used between an ATM end system and ATM switch across ATM UNI, and NNI is
used across NNI links.
The ATM Forum UNI 3.1 specification is the current standard for ATM UNI signaling. The UNI 3.1
specification is based on the Q.2931 public network signaling protocol developed by the ITU-T.
UNI signaling requests are carried in a well-known default connection:
VPI = 0, VPI = 5.
The ATM Connection-Establishment Process

ATM signaling uses the one-pass method of connection setup that is used in all modern
telecommunication networks, such as the telephone network. An ATM connection setup proceeds
in the following manner. First, the source end system sends a connection-signaling request. The
connection request is propagated through the network. As a result, connections are set up
through the network. The connection request reaches the final destination, which either accepts
or rejects the connection request.
Connection-Request Routing and Negotiation

Routing of the connection request is governed by an ATM routing protocol (Private
Network-Network Interface [PNNI], which routes connections based on destination and source
addresses), traffic, and the QoS parameters requested by the source end system. Negotiating a
connection request that is rejected by the destination is limited because call routing is based on
parameters of initial connection; changing parameters might affect the connection routing.
Figure 27-10 highlights the one-pass method of ATM connection establishment.
Figure 27-10 ATM Devices Establish Connections Through the One-Pass Method
103
Tel. #: (034) 312-6189 / (034) 729-4327
ATM Connection-Management Messages
A number of connection-management message types, including setup, call proceeding, connect,
and release, are used to establish and tear down an ATM connection. The source end system
sends a setup message (including the address of the destination end system and any traffic QoS
parameters) when it wants to set up a connection. The ingress switch sends a call proceeding
message back to the source in response to the setup message. The destination end system next
sends a connect message if the connection is accepted.
The destination end system sends a release message back to the source end system if the
connection is rejected, thereby clearing the connection.
Connection-management messages are used to establish an ATM connection in the following

manner. First, a source end system sends a setup message, which is forwarded to the first ATM
switch (ingress switch) in the network. This switch sends a call proceeding message and invokes
an ATM routing protocol. The signaling request is propagated across the network. The exit
switch (called the egress switch) that is attached to the destination end system receives the
setup message. The egress switch forwards the setup message to the end system across its
UNI, and the ATM end system sends a connect message if the connection is accepted. The
connect message traverses back through the network along the same path to the source end
system, which sends a connect acknowledge message back to the destination to acknowledge
the connection. Data transfer can then begin.
PNNI
PNNI provides two significant services: ATM topology discovery and call establishment. For
switches to build connections between end points, the switch must know the ATM network
topology. PNNI is the ATM routing protocol that enables switches to automatically discover the
topology and the characteristics of the links interconnecting the switches. A link-state protocol
104
Tel. #: (034) 312-6189 / (034) 729-4327
much like OSPF, PNNI tracks things such as bandwidth on links. When a significant event occurs
that changes the characteristics of a link, PNNI announces the change to the other switches.
When a station sends a call setup request to its local switch, the ingress switch references the
PNNI routing table to determine a path between the source and the intended destination that
meets the QoS requirements specified by the source. The switch attached to the source then
builds a list defining each switch hop to support the circuit to the destination. This is called the
designated transit list (DTL).
VCI = 18 is reserved for PNNI.
Integrated Local Management Interface

Integrated Local Management Interface (ILMI) enables devices to determine status of
components at the other end of a physical link and to negotiate a common set of operational
parameters to ensure interoperability. ILMI operates over a reserved VCC of VPI = X, VCI = 16.
Administrators may enable or disable ILMI at will, but it is highly recommended to enable it.
Doing so allows the devices to determine the highest UNI interface level to operate (3.0, 3.1,
4.0), UNI vs. NNI, as well as numerous other items. Furthermore, ILMI allows devices to share
information such as NSAP addresses, peer interface names, and IP addresses. Without ILMI,
many of these parameters must be manually configured for the ATM attached devices to operate
correctly.
Note The VCI values of 0 through 31 are reserved and should not be used for user traffic. Three
frequently encountered VCI values are shown in Table 27-1.
Table 27-1 Commonly Used VCI Values
VCI Function
5 Signaling from an edge device to its switch (ingress switch)
16 ILMI for link parameter exchanges
18 PNNI for ATM routing
LAN Emulation
LAN Emulation (LANE) is a standard defined by the ATM Forum that gives to stations attached
via ATM the same capabilities that they normally obtain from legacy LANs, such as Ethernet and
Token Ring. As the name suggests, the function of the LANE protocol is to emulate a LAN on top
of an ATM network. Specifically, the LANE protocol defines mechanisms for emulating either an
IEEE 802.3 Ethernet or an 802.5 Token Ring LAN. The current LANE protocol does not define a
separate encapsulation for FDDI. (FDDI packets must be mapped into either Ethernet or Token
105
Tel. #: (034) 312-6189 / (034) 729-4327
Ring-emulated LANs [ELANs] by using existing translational bridging techniques.) Fast Ethernet
(100BaseT) and IEEE 802.12 (100VG-AnyLAN) both can be mapped unchanged because they
use the same packet formats. Figure 27-11 compares a physical LAN and an ELAN.
Figure 27-11 ATM Networks Can Emulate a Physical LAN
The LANE protocol

defines a service
interface for higher-layer (that is, network layer) protocols that is identical to that of existing
LANs. Data sent across the ATM network is encapsulated in the appropriate LAN MAC packet
format. Simply put, the LANE protocols make an ATM network look and behave like an Ethernet
or Token Ring LAN—albeit one operating much faster than an actual Ethernet or Token Ring LAN
network.
It is important to note that LANE does not attempt to emulate the actual MAC protocol of the
specific LAN concerned (that is, CSMA/CD for Ethernet or token passing for IEEE 802.5). LANE
requires no modifications to higher-layer protocols to enable their operation over an ATM
network. Because the LANE service presents the same service interface of existing MAC
protocols to network layer drivers (such as an NDIS- or ODI-like driver interface), no changes
are required in those drivers.
The LANE Protocol Architecture

The basic function of the LANE protocol is to resolve MAC addresses to ATM addresses. The goal
is to resolve such address mappings so that LANE end systems can set up direct connections
between themselves and then forward data. The LANE protocol is deployed
in two types of ATM-attached equipment: ATM network interface cards (NICs) and
internetworking and LAN switching equipment.
ATM NICs implement the LANE protocol and interface to the ATM network but present the
current LAN service interface to the higher-level protocol drivers within the attached end system.
The network layer protocols on the end system continue to communicate as if they were on a
known LAN by using known procedures. However, they are capable of using the vastly greater
bandwidth of ATM networks.
106
Tel. #: (034) 312-6189 / (034) 729-4327
The second class of network gear to implement LANE consists of ATM-attached LAN switches and
routers. These devices, together with directly attached ATM hosts equipped with ATM NICs, are
used to provide a virtual LAN (VLAN) service in which ports on the LAN switches are assigned to
particular VLANs independently of physical location. Figure 27-12 shows the LANE protocol
architecture implemented in ATM network devices.
Figure 27-12 LANE Protocol Architecture Can Be Implemented in ATM Network Devices
Note The LANE protocol does not directly affect ATM switches. As with most of the other ATM
internetworking protocols, LANE builds on the overlay model. As such, the LANE protocols operate
transparently over and through ATM switches, using only standard ATM signaling procedures.
LANE Components
The LANE protocol defines the operation of a single ELAN or VLAN. Although multiple ELANs can
simultaneously exist on a single ATM network, an ELAN emulates either an Ethernet or a Token
Ring and consists of the following components:
• LAN Emulation client (LEC)—The LEC is an entity in an end system that performs data
forwarding, address resolution, and registration of MAC addresses with the LAN Emulation
Server (LES). The LEC also provides a standard LAN interface to higher-level protocols on legacy
LANs. An ATM end system that connects to multiple ELANs has one LEC per ELAN.
• LES—The LES provides a central control point for LECs to forward registration and control
information. (Only one LES exists per ELAN.) The LES maintains a list of MAC addresses in the
ELAN and the corresponding NSAP addresses.
107
Tel. #: (034) 312-6189 / (034) 729-4327
• Broadcast and Unknown Server (BUS)—The BUS is a multicast server that is used to
flood unknown destination address traffic and to forward multicast and broadcast traffic to
clients within a particular ELAN. Each LEC is associated with only one BUS per ELAN.
• LAN Emulation Configuration Server (LECS)—The LECS maintains a database of LECs

and the ELANs to which they belong. This server accepts queries from LECs and responds with
the appropriate ELAN identifier—namely, the ATM address of the LES that serves the appropriate
ELAN. One LECS per administrative domain serves all ELANs within that domain.
Because single server components lack redundancy, Cisco has overcome this shortcoming by
implementing a proprietary solution called Simple Server Redundancy Protocol. SSRP works with
any vendors LECs; however, it requires the use of Cisco devices as server components. It allows
up to 16 LECSs per ATM LANE network and an infinite number of LES/BUS pairs per ELAN. The
ATM Forum also released a vendor-independent method of providing server redundancy: Lane
Emulation Network-Network Interface (LNNI). Therefore, servers from different vendors can
provide interoperable redundancy.
Figure 27-13 illustrates the components of an ELAN.
Figure 27-13 An ELAN Consists of Clients, Servers, and Various Intermediate Nodes
108
Tel. #: (034) 312-6189 / (034) 729-4327
.
LAN Emulation Connection Types

The Phase 1 LANE entities communicate with each other by using a series of ATM VCCs. LECs
maintain separate connections for data transmission and control traffic. The LANE data
connections are data-direct VCC, multicast send VCC, and multicast forward VCC.
Data-direct VCC is a bidirectional point-to-point VCC set up between two LECs that want to
exchange data. Two LECs typically use the same data-direct VCC to carry all packets between
them rather than opening a new VCC for each MAC address pair. This technique conserves
connection resources and connection setup latency.
Multicast send VCC is a bidirectional point-to-point VCC set up by the LEC to the BUS.
Multicast forward VCC is a unidirectional VCC set up to the LEC from the BUS. It typically is a
point-to-multipoint connection, with each LEC as a leaf.
Figure 27-14 shows the LANE data connections.
Control connections include configuration-direct VCC, control-direct VCC, and control-distribute

VCC. Configuration-direct VCC is a bidirectional point-to-point VCC set up by the LEC to the
LECS. Control-direct VCC is a bidirectional VCC set up by the LEC to the LES. Control-distribute
VCC is a unidirectional VCC set up from the LES back to the LEC (this is typically a
point-to-multipoint connection). Figure 27-15 illustrates LANE control connections.
Figure 27-14 LANE Data Connections Use a Series of VCLs to Link a LAN Switch and ATM Hosts
109
Tel. #: (034) 312-6189 / (034) 729-4327
Figure 27-15 LANE
Control Connections Link the LES, LECS, LAN Switch, and ATM Host
LANE Operation
The operation of a LANE system and components is best understood by examining these stages
of LEC operation: performing initialization and configuration, joining and registering with the
LES, finding and joining the BUS, and performing data transfer.
110
Tel. #: (034) 312-6189 / (034) 729-4327
Initialization and Configuration
Upon initialization, an LEC finds the LECS to obtain required configuration information. It begins
this process when the LEC obtains its own ATM address, which typically occurs through address
registration.
The LEC must then determine the location of the LECS. To do this, the LEC first must locate the
LECS by one of the following methods: by using a defined ILMI procedure to determine the LECS
address, by using a well-known LECS address, or by using a well-known permanent connection
to the LECS (VPI = 0, VCI = 17). (The well-known permanent connection is not commonly
used.)
After the LEC discovers the LECS's NSAP, the LEC sets up a configuration-direct VCC to the LECS
and sends an LE_CONFIGURE_REQUEST message. If a matching entry is found, the LECS
returns a LE_CONFIGURE_RESPONSE message to the LEC with the configuration information
that it requires to connect to its target ELAN, including the following: ATM address of the LES,
type of LAN being emulated, maximum packet size on the ELAN, and ELAN name (a text string
for display purposes).
Joining and Registering with the LES

When an LEC joins the LES and registers its own ATM and MAC addresses, it does so by
following three steps:
1. After the LEC obtains the LES address, the LEC optionally clears the connec-
tion to the LECS, sets up the control-direct VCC to the LES, and sends an LE_JOIN_REQUEST
message on that VCC. This allows the LEC to register its own MAC and ATM addresses with the
LES and (optionally) any other MAC addresses for which it is proxying. This information is
maintained so that no two LECs will register the same MAC or ATM address.
2. After receipt of the LE_JOIN_REQUEST message, the LES checks with the LECS via its open
connection, verifies the request, and confirms the client's membership.
3. Upon successful verification, the LES adds the LEC as a leaf of its point-to-multipoint
control-distribute VCC and issues the LEC a successful LE_JOIN_RESPONSE message that
contains a unique LAN Emulation client ID (LECID). The LECID is used by the LEC to filter its own
broadcasts from the BUS.
Finding and Joining the BUS

After the LEC has successfully joined the LECS, its first task is to find the BUS's ATM address to
join the broadcast group and become a member of the emulated LAN.
First, the LEC creates an LE_ARP_REQUEST packet with the MAC address 0xFFFFFFFF. Then the
LEC sends this special LE_ARP packet on the control-direct VCC to the LES. The LES recognizes
111
Tel. #: (034) 312-6189 / (034) 729-4327
that the LEC is looking for the BUS and responds with the BUS's ATM address on the
control-distribute VCC.
When the LEC has the BUS's ATM address, it joins the BUS by first creating a signaling packet
with the BUS's ATM address and setting up a multicast-send VCC with the BUS. Upon receipt of
the signaling request, the BUS adds the LEC as a leaf on its point-to-multipoint multicast forward
VCC. The LEC is now a member of the ELAN and is ready for data transfer.
Data Transfer
The final state, data transfer, involves resolving the ATM address of the destination LEC and
actual data transfer, which might include the flush procedure.
When a LEC has a data packet to send to an unknown destination MAC address, it must discover
the ATM address of the destination LEC through which the particular address can be reached. To
accomplish this, the LEC first sends the data frame to the BUS (via the multicast send VCC) for
distribution to all LECs on the ELAN via the multicast forward VCC. This is done because
resolving the ATM address might take some time, and many network protocols are intolerant of
delays.
The LEC then sends a LAN Emulation Address Resolution Protocol Request (LE_ARP_Request)
control frame to the LES via a control-direct VCC.
If the LES knows the answer, it responds with the ATM address of the LEC that owns
the MAC address in question. If the LES does not know the answer, it floods the
LE_ARP_REQUEST to some or all LECs (under rules that parallel the BUS's flooding of the actual
data frame, but over control-direct and control-distribute VCCs instead of the multicast send or
multicast forward VCCs used by the BUS). If bridge/switching
devices with LEC software participating in the ELAN exist, they respond to the LE_ARP_REQUEST
if they service the LAN device with the requested MAC address.
This is called a proxy service.
In the case of actual data transfer, if an LE_ARP message is received, the LEC sets up a
data-direct VCC to the destination LEC and uses this for data transfer rather than the BUS path.
Before it can do this, however, the LEC might need to use the LANE flush procedure, which
ensures that all packets previously sent to the BUS were delivered to the destination prior to the
use of the data-direct VCC. In the flush procedure, a control frame is sent down the first
transmission path following the last packet. The LEC then waits until the destination
acknowledges receipt of the flush packet before using the second path to send packets.
Multiprotocol over ATM

Multiprotocol over ATM (MPOA) provides a method of transmitting data between ELANs without
needing to continuously pass through a router. Normally, data passes through at least one
router to get from one ELAN to another. This is normal per-hop routing as experienced in LAN
environments. MPOA, however, enables devices in different ELANs to communicate without
needing to travel hop by hop.
112
Tel. #: (034) 312-6189 / (034) 729-4327
Figure 27-16 illustrates the process without MPOA in part A and with MPOA in part B. With
MPOA-enabled devices, only the first few frames between devices pass through routers. This is
called the default path. The frames pass from ELAN to ELAN through appropriate routers. After a
few frames follow the default path, the MPOA devices discover the NSAP address of the other
device and then build a direct connection called the shortcut for the subsequent frames in the
flow.
The edge devices that generate the ATM traffic are called multiprotocol clients (MPC) and may be
an ATM-attached workstation, or a router. The inter-ELAN routers are called multiprotocol
servers (MPS) and assist the MPCs in discovering how to build a shortcut. MPSs are always
routers.
This reduces the load on routers because the routers do not need to sustain the continuous flow
between devices. Furthermore, MPOA can reduce the number of ATM switches supporting a
connection, freeing up virtual circuits and switch resources in the ATM network. Figure 27-16
illustrates the connection before and after the shortcut is established.
Note that MPOA does not replace LANE. In fact, MPOA requires LANE version 2.
Figure 27-16 A Comparison of Inter-ELAN Communications without (Part A) and with (Part B) MPOA
Lesson IX:
INTRODUCTION to IP
Introduction to IP
IP stands for Internet Protocol. It is the method by which data is transmitted over the Internet.
25.1 Internet Communication
113
Tel. #: (034) 312-6189 / (034) 729-4327
At a hardware level, network cards are capable of transmitting packets (also called datagrams)
of data between one another. A packet contains a small block of, say, 1 kilobyte of data (in
contrast to serial lines, which transmit continuously). All Internet communication occurs through
transmission of packets, which travel intact, even between machines on opposite sides of the
world.
Each packet contains a header of 24 bytes or more which precedes the data. Hence, slightly
more than the said 1 kilobyte of data would be found on the wire. When a packet is transmitted,
the header would obviously contain the destination machine. Each machine is hence given a
unique IP address--a 32-bit number. There are no machines on the Internet that do not have an
IP address.
The header bytes are shown in Table 25.1.

Table 25.1: IP header bytes
Bytes Description
bits 0-3: Version, bits 4-7: Internet Header Length
0
(IHL)
1 Type of service (TOS)
2-3 Length
4-5 Identification
6-7 bits 0-3: Flags, bits 4-15: Offset
8 Time to live (TTL)
9 Type
10-11 Checksum
12-15 Source IP address
16-19 Destination IP address
20-IHL*4-1 Options + padding to round up to four bytes
Data begins at IHL*4 and ends at Length-1
Version for the mean time is 4, although IP Next Generation (version 6) is in the (slow) process
of deployment. IHL is the length of the header divided by 4. TOS (Type of Service) is a
somewhat esoteric field for tuning performance and is not explained here. The Length field is
the length in bytes of the entire packet including the header. The Source and Destination are
the IP addresses from and to which the packet is coming/going.
The above description constitutes the view of the Internet that a machine has. However,
physically, the Internet consists of many small high-speed networks (like those of a company or
a university) called Local Area Networks, or LANs. These are all connected to each other by
lower-speed long distance links. On a LAN, the raw medium of transmission is not a packet but
an Ethernet frame. Frames are analogous to packets (having both a header and a data portion)
but are sized to be efficient with particular hardware. IP packets are encapsulated within frames,
where the IP packet fits within the Data part of the frame. A frame may, however, be too small
to hold an entire IP packet, in which case the IP packet is split into several smaller packets. This
group of smaller IP packets is then given an identifying number, and each smaller packet will
114
Tel. #: (034) 312-6189 / (034) 729-4327
then have the Identification field set with that number and the Offset field set to indicate its
position within the actual packet. On the other side of the connection, the destination machine
will reconstruct a packet from all the smaller sub packets that have the same Identification
field.
The convention for writing an IP address in human readable form is dotted decimal notation like
152.2.254.81, where each number is a byte and is hence in the range of 0 to 255. Hence the
entire address space is in the range of 0.0.0.0 to 255.255.255.255. To further organize the
assignment of addresses, each 32-bit address is divided into two parts, a network and a host
part of the address, as shown in Figure 25.1.
Figure 25.1: IP address classes

The network part of the address designates the LAN, and the host part the particular machine on
the LAN. Now, because it was unknown at the time of specification whether there would one day
be more LANs or more machines per LAN, three different classes of address were created.
Class A addresses begin with the first bit of the network part set to 0 (hence, a Class A address
always has the first dotted decimal number less than 128). The next 7 bits give the identity of
the LAN, and the remaining 24 bits give the identity of an actual machine on that LAN. A Class B
address begins with a 1 and then a 0 (first decimal number is 128 through 191). The next 14
bits give the LAN, and the remaining 16 bits give the machine. Most universities, like the address
above, are Class B addresses. Lastly, Class C addresses start with a 1 1 0 (first decimal number
is 192 through 223), and the next 21 bits and then the next 8 bits are the LAN and machine,
respectively. Small companies tend use Class C addresses.
In practice, few organizations require Class A addresses. A university or large company might
use a Class B address but then would have its own further subdivisions, like using the third
dotted decimal as a department (bits 16 through 23) and the last dotted decimal (bits 24
through 31) as the machine within that department. In this way the LAN becomes a
micro-Internet in itself. Here, the LAN is called a network and the various departments are each
called a subnet.
25.2 Special IP Addresses
Some special-purposes IP addresses are never used on the open Internet. 192.168.0.0 through
192.168.255.255 are private addresses perhaps used inside a local LAN that does not
communicate directly with the Internet. 127.0.0.0 through 127.255.255.255 are used for
communication with the localhost--that is, the machine itself. Usually, 127.0.0.1 is an IP address
pointing to the machine itself. Further, 172.16.0.0 through 172.31.255.255 are additional
115
Tel. #: (034) 312-6189 / (034) 729-4327
private addresses for very large internal networks, and 10.0.0.0 through 10.255.255.255 are for
even larger ones.
25.3 Network Masks and Addresses
Consider again the example of a university with a Class B address. It might have an IP address
range of 137.158.0.0 through 137.158.255.255. Assume it was decided that the astronomy
department should get 512 of its own IP addresses, 137.158.26.0 through 137.158.27.255. We
say that astronomy has a network address of 137.158.26.0. The machines there all have a
network mask of 255.255.254.0. A particular machine in astronomy may have an IP address of
137.158.27.158. This terminology is used later. Figure 25.2 illustrates this example.
Figure 25.2: Dividing an address into network and host portions

25.4 Computers on a LAN
In this section we will use the term LAN to indicate a network of computers that are all more or
less connected directly together by Ethernet cables (this is common for small businesses with up
to about 50 machines). Each machine has an Ethernet card which is referred to as eth0
throughout all command-line operations. If there is more than one card on a single machine,
then these are named eth0, eth1, eth2, etc., and are each called a network interface (or just
interface, or sometimes Ethernet port) of the machine.
LANs work as follows. Network cards transmit a frame to the LAN, and other network cards read
that frame from the LAN. If any one network card transmits a frame, then all other network
cards can see that frame. If a card starts to transmit a frame while another card is in the
process of transmitting a frame, then a clash is said to have occurred, and the card waits a
random amount of time and then tries again. Each network card has a physical address of 48
bits called the hardware address (which is inserted at the time of its manufacture and has
nothing to do with IP addresses). Each frame has a destination address in its header that tells
what network card it is destined for, so that network cards ignore frames that are not addressed
to them.
Since frame transmission is governed by the network cards, the destination hardware address
must be determined from the destination IP address before a packet is sent to a particular
machine. This is done is through the Address Resolution Protocol (ARP). A machine will transmit
a special packet that asks ``What hardware address is this IP address?'' The guilty machine
then responds, and the transmitting machine stores the result for future reference. Of course, if
116
Tel. #: (034) 312-6189 / (034) 729-4327
you suddenly switch network cards, then other machines on the LAN will have the wrong
information, so ARP has time-outs and re-requests built into the protocol. Try typing the
command arp to get a list of hardware address to IP mappings.
25.5 Configuring Interfaces
Most distributions have a generic way to configure your interfaces. Here, however, we first look
at a complete network configuration using only raw networking commands.
We first create a lo interface. This is called the loopback device (and has nothing to do with
loopback block devices: /dev/loop? files). The loopback device is an imaginary network card that
is used to communicate with the machine itself; for instance, if you are telneting to the local
machine, you are actually connecting via the loopback device. The ifconfig ( inter face configure)
command is used to do anything with interfaces. First, run
/ s b i n / i f c o n f i g l o d o w n
/sbin/ifconfig eth0 down
to delete any existing interfaces, then run
/sbin/ifconfig lo 127.0.0.1
which creates the loopback interface.
Create the Ethernet interface with:

/sbin/ifconfig eth0 192.168.3.9 broadcast 192.168.3.255 netmask 255.255.255.0
The broadcast address is a special address that all machines respond to. It is usually the first or last
address of the particular network.
Now run
/sbin/ifconfig
to view the interfaces. The output will be
eth0 Li nk encap:Et hern et HW addr 00:00 :E8 :3 B:2D:A2
inet addr:192.168.3.9 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1359 errors:0 dropped:0 overruns:0 frame:0
5 TX packets:1356 errors:0 dropped:0 overruns:0 carrier:0
c o l l i s i o n s : 0 t x q u e u e l e n : 1 0 0
I n t e r r u p t : 1 1 B a s e a d d r e s s : 0 x e 4 0 0
l o L i n k e n c a p : L o c a l L o o p b a c k
10 i n e t a d d r : 1 2 7 . 0 . 0 . 1 M a s k : 2 5 5 . 0 . 0 . 0
U P L O O P B A C K R U N N I N G M T U : 3 9 2 4 M e t r i c : 1
RX packets:53175 errors:0 dropped:0 overruns:0 frame:0
TX packets:53175 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
which shows various interesting bits, like the 48-bit hardware address of the network card (hex bytes
00:00:E8:3B:2D:A2).
117
Tel. #: (034) 312-6189 / (034) 729-4327
25.6 Configuring Routing
The interfaces are now active. However, nothing tells the kernel what packets should go to what
interface, even though we might expect such behavior to happen on its own. With UNIX, you
must explicitly tell the kernel to send particular packets to particular interfaces.
Any packet arriving through any interface is pooled by the kernel. The kernel then looks at each
packet's destination address and decides, based on the destination, where it should be sent. It
doesn't matter where the packet came from; once the kernel has the packet, it's what its
destination address says that matters. It is up to the rest of the network to ensure that packets
do not arrive at the wrong interfaces in the first place.
We know that any packet having the network address 127.??? .??? .??? must go to the loopback
device (this is more or less a convention). The command,
/sbin/route add -net 127.0.0.0 netmask 255.0.0.0 lo
adds a route to the network 127.0.0.0, albeit an imaginary one.
The eth0 device can be routed as follows:

/sbin/route add -net 192.168.3.0 netmask 255.255.255.0 eth0
The command to display the current routes is
/sbin/route –n
( -n causes route to not print IP addresses as host names) with the following output:
K e r n e l I P r o u t i n g t a b l e
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
This output has the meaning, ``packets with destination address 127.0.0.0/255.0.0.0 [The
notation network/mask is often used to denote ranges of IP address.]must be sent to the
loopback device,'' and ``packets with destination address 192.168.3.0/255.255.255.0 must be
sent to eth0.'' Gateway is zero, hence, is not set (see the following commands).
The routing table now routes 127. and 192.168.3. packets. Now we need a route for the
remaining possible IP addresses. UNIX can have a route that says to send packets with
particular destination IP addresses to another machine on the LAN, from whence they might be
forwarded elsewhere. This is sometimes called the gateway machine. The command is:
/sbin/route add -net <network-address> netmask <netmask> gw \
<gateway-ip-address> <interface>
This is the most general form of the command, but it's often easier to just type:
/sbin/route add default gw <gateway-ip-address> <interface>
when we want to add a route that applies to all remaining packets. This route is called the
default gateway. default signifies all packets; it is the same as
/ s bi n/ ro ut e a dd - net 0 .0 .0 .0 netm a sk 0 .0 .0 .0 g w <g a t ewa y - ip - a dd r es s > \
118
Tel. #: (034) 312-6189 / (034) 729-4327
<interface>
but since routes are ordered according to netmask, more specific routes are used in preference
to less specific ones.
Finally, you can set your host name with:

hostname cericon.cranzgot.co.za
A summary of the example commands so far is
/ s b i n / i f c o n f i g l o d o w n
/ s b i n / i f c o n f i g e t h 0 d o w n
/ s b i n / i f c o n f i g l o 1 2 7 . 0 . 0 . 1
/sbin/ifc onfig e th0 192.168.3.9 bro adcast 192.168.3.255 netmask 255.255.255.0
5/ s b i n / r o u t e a d d - n e t 1 2 7 . 0 . 0 . 0 n e t m a s k 2 5 5 . 0 . 0 . 0 l o
/sbin/route add -net 192.168.3.0 netmask 255.255.255.0 eth0
/ s b i n / r o u t e a d d d e f a u l t g w 1 9 2 . 1 6 8 . 3 . 2 5 4 e t h 0
hostname cericon.cranzgot.co.za
Although these 7 commands will get your network working, you should not do such a manual
configuration. The next section explains how to configure your startup scripts.
25.7 Configuring Startup Scripts
Most distributions will have a modular and extensible system of startup scripts that initiate
networking.
25.7.1 RedHat networking scripts

RedHat systems contain the directory /etc/sysconfig/, which contains configuration files to
automatically bring up networking.
The file /etc/sysconfig/network-scripts/ifcfg-eth0 contains:

D E V I C E = e t h 0
I P A D D R = 1 9 2 1. 6 8 . 3 . 9
N E T M A S K = 2 5 5 . 5 2 5 . 2 5 5 . 0
N E T W O R K = 1 9 2 . 1 6 8 . 3 . 0
5B R O A D C A S T = 1 9 2 . 1 6 8 . 3 . 2 5 5
ONBOOT=yes
The file /etc/sysconfig/network contains:
N E T W O R K I N G = y e s
H O S T N A M E = c e r i c o n . c r a n z g o t . c o . z a
GATEWAY=192.168.3.254
You can see that these two files are equivalent to the example configuration done above. These
two files can take an enormous number of options for the various protocols besides IP, but this
is the most common configuration.
119
Tel. #: (034) 312-6189 / (034) 729-4327
The file /etc/sysconfig/network-scripts/ifcfg-lo for the loopback device will be configured
automatically at installation; you should never need to edit it.
To stop and start networking (i.e., to bring up and down the interfaces and routing), type
(alternative commands in parentheses):
/ e t c / i n i t . d / n e t w o r k s t o p
( / e t c / r c . d / i n i t . d / n e t w o r k s t o p )
/ e t c / i n i t . d / n e t w o r k s t a r t
( /etc/rc.d/init.d/network start )
which will indirectly read your /etc/sysconfig/ files.
You can add further files, say, ifcfg-eth1 (under /etc/sysconfig/network-scripts/) for a secondary
Ethernet device. For example, ifcfg-eth1 could contain
D E V I C E = e t h 1
I P A D D R = 1 9 2 . 1 6 8 . 4 . 1
N E T M A S K = 2 5 5 . 2 5 5 . 2 5 5 . 0
N E T W O R K = 1 9 2 . 1 6 8 . 4 . 0
5B R O A D C A S T = 1 9 2 . 1 6 8 . 4 . 2 5 5
ONBOOT=yes
and then run echo "1" > /proc/sys/net/ipv4/ip_forward to enable packet forwarding between
your two interfaces.
25.7.2 Debian networking scripts

Debian, on the other hand, has a directory /etc/network/ containing a file
/etc/network/interfaces. [As usual, Debian has a neat and clean approach.] (See also
interfaces(5).) For the same configuration as above, this file would contain:
i f a c e l o i n e t l o b a c o p k
i f a c e h 0 e t i n e t s t a t i c
a d r ed s s 1 9 2 . 1 6 8 . 3 . 9
n e t m a s k 2 5 5 . 2 5 5 . 2 5 5 . 0
5 gateway 192.168.3.254
The file /etc/network/options contains the same forwarding (and some other) options:
i p _ f o r w a r d = n o
s p o o f p r o t e c t = y e s
syncookies=no
To stop and start networking (i.e., bring up and down the interfaces and routing), type
/ e t c / i n i t . d / n e t w o r k i n g s t o p
/etc/init.d/networking start
which will indirectly read your /etc/network/interfaces file.
120
Tel. #: (034) 312-6189 / (034) 729-4327
Actually, the /etc/init.d/networking script merely runs the ifup and ifdown commands. See
ifup(8). You can alternatively run these commands directly for finer control.
We add further interfaces similar to the RedHat example above by appending to the
/etc/network/interfaces file. The Debian equivalent is,
i f a c e l o i n e t l o o p b a c k
i f a c e e t h 0 i n e t s t a t i c
ad r de s s 1 9 2 . 1 6 8 . 3 . 9
n e
m a s t k 2 5 5 . 2 5 5 . 2 5 5 . 0
5 g a
e w a t y 1 9 2 . 1 6 8 . 3 . 2 5 4
i f a c ee t h 1 i n e t s t a t i c
a d d r e s s 1 9 2 . 1 6 8 . 4 . 1
netmask 255.255.255.0
and then set ip_forward=yes in your /etc/network/options file.
Finally, whereas RedHat sets its host name from the line HOSTNAME=... in
/etc/sysconfig/network, Debian sets it from the contents of the file /etc/hostname, which, in the
present case, would contain just
cericon.cranzgot.co.za
25.8 Complex Routing -- a Many-Hop Example
Consider two distant LANs that need to communicate. Two dedicated machines, one on each
LAN, are linked by some alternative method (in this case, a permanent serial line), as shown in
Figure 25.3.
Figure 25.3: Two remotely connected networks

This arrangement can be summarized by five machines X, A, B, C, and D. Machines X, A, and B
form LAN 1 on subnet 192.168.1.0/26. Machines C and D form LAN 2 on subnet
192.168.1.128/26. Note how we use the `` /26'' to indicate that only the first 26 bits are
121
Tel. #: (034) 312-6189 / (034) 729-4327
network address bits, while the remaining 6 bits are host address bits. This means that we can
have at most IP addresses on each of LAN 1 and 2. Our dedicated serial link comes
between machines B and C.
Machine X has IP address 192.168.1.1. This machine is the gateway to the Internet. The
Ethernet port of machine B is simply configured with an IP address of 192.168.1.2 with a default
gateway of 192.168.1.1. Note that the broadcast address is 192.168.1.63 (the last 6 bits set to
1).
The Ethernet port of machine C is configured with an IP address of 192.168.1.129. No default

gateway should be set until serial line is configured.
We will make the network between B and C subnet 192.168.1.192/26. It is effectively a LAN on
its own, even though only two machines can ever be connected. Machines B and C will have IP
addresses 192.168.1.252 and 192.168.1.253, respectively, on their facing interfaces.
This is a real-life example with an unreliable serial link. To keep the link up requires pppd and a
shell script to restart the link if it dies. The pppd program is covered in Chapter 41. The script for
Machine B is:
# ! / b i n / s h
w h i l e t r u e ; d o
pppd lock local mru 296 mtu 296 nodetach nocrtscts nocdtrcts \
192.168.1.252:192.168.1.253 /dev/ttyS0 115200 noauth \
5 lc p - e c ho - int e r v a l 1 lc p - e c ho - fa ilur e 2 lc p- m a x- te r m ina te 1 lc p - r e sta r t 1
done
Note that if the link were an Ethernet link instead (on a second Ethernet card), and/or a genuine
LAN between machines B and C (with subnet 192.168.1.252/26), then the same script would be
just
/sbin/ifconfig eth1 192.168.1.252 broadcast 192.168.1.255 netmask \
255.255.255.192
in which case all `` ppp0'' would change to `` eth1'' in the scripts that follow.
Routing on machine B is achieved with the following script, provided the link is up. This script
must be executed whenever pppd has negotiated the connection and can therefore be placed in
the file /etc/pppd/ip-up, which pppd executes automatically as soon as the ppp0 interface is
available:
/ s b i n / r o u t e d e l d e f a u l t
/sbin/route add -net 192.168.1.192 netmask 255.255.255.192 dev ppp0
/sbin/ro ut e add -net 192.168.1.128 ne tmask 255.255.255.192 gw 192.168.1.253
/ s b i n / r o u t e a d d d e f a u l t g w 1 9 2 . 1 6 8 . 1 . 1
5
echo 1 > /proc/sys/net/ipv4/ip_forward
Our full routing table and interface list for machine B then looks like this [RedHat 6 likes to add
(redundant) explicit routes to each device. These may not be necessary on your system]:
122
Tel. #: (034) 312-6189 / (034) 729-4327
De s tin a t io n Gateway G enm ask F la g s M e tr ic R e f U se Ifa ce
192.168.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.1.253 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
5 192.168.1.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
192.168.1.192 0.0.0.0 255.255.255.192 U 0 0 0 ppp0
192.168.1.128 192.168.1.253 255.255.255.192 UG 0 0 0 ppp0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
10
eth0 Link encap:Ethernet HWaddr 00:A0:24:75:3B:69
inet addr: 192.168.1.2 Bcast:192.168.1.63 M ask:255.255.255.192
i n e t a d d r : 1 2 7 . 0 . 0 . 1 M a s k : 2 5 5 . 0 . 0 . 0
15 p p p 0 L i n k e n c a p : P o i n t - t o - P o i n t P r o t o c o l
inet addr:192.168.1.252 P-t-P:192.168.1.253 Mask:255.255.255.255
On machine C we can similarly run the script,
# ! / b i n / s h
w h i l e t r u e ; d o
pppd lock local mru 296 mtu 296 nodetach nocrtscts nocdtrcts \
192.168.1.253:192.168.1.252 /dev/ttyS0 115200 noauth \
5 lc p - e c ho - int e r v a l 1 lc p - e c ho - fa ilur e 2 lc p- m a x- te r m ina te 1 lc p - r e sta r t 1
done
and then create routes with
/ s b i n / r o u t e d e l d e f a u l t
/sbin/route add -net 192.168.1.192 netmask 255.255.255.192 dev ppp0
/ s b i n / r o u t e a d d d e f a u l t g w 1 9 2 . 1 6 8 . 1 . 2 5 2
5 echo 1 > /proc/sys/net/ipv4/ip_forward

Our full routing table for machine C then looks like:
De s tin a t io n Gateway G enm ask F la g s M e tr ic R e f U se Ifa ce
192.168.1.129 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.1.252 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
5 192.168.1.192 0.0.0.0 255.255.255.192 U 0 0 0 ppp0
192.168.1.128 0.0.0.0 255.255.255.192 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.252 0.0.0.0 UG 0 0 0 ppp0
10 e t h 0 Link encap:Ethernet HWaddr 00:A0:CC:D5:D8:A7

inet a d d r : 19 2.1 68.1 .1 2 9 B c as t: 19 2.1 68.1 .1 9 1 M a sk : 25 5.2 55.2 5 5.1 92
i n e t a d d r : 1 2 7 . 0 . 0 . 1 M a s k : 2 5 5 . 0 . 0 . 0
123
Tel. #: (034) 312-6189 / (034) 729-4327
p p p 0 L i n k e n c a p : P o i n t - t o - P o i n t P r o t o c o l
15 inet addr:192.168.1.253 P-t-P:192.168.1.252 Mask:255.255.255.255
Machine D can be configured like any ordinary machine on a LAN. It just sets its default gateway
to 192.168.1.129. Machine A, however, has to know to send packets destined for subnet
192.168.1.128/26 through machine B. Its routing table has an extra entry for the
192.168.1.128/26 LAN. The full routing table for machine A is:
De s tina t io n Gateway G enm ask F la g s M etric R e f U se Ifa ce
192.168.1.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
192.168.1.128 192.168.1.2 255.255.255.192 UG 0 0 0 eth0
5 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
To avoid having to add this extra route on machine A, you can instead add the same route on
machine X. This may seem odd, but all that this means is that packets originating from A
destined for LAN 2 first try to go through X (since A has only one route), and are then redirected
by X to go through B.
The preceding configuration allowed machines to properly send packets between machines A
and D and out through the Internet. One caveat: ping sometimes did not work even though
telnet did. This may be a peculiarity of the kernel version we were using, **shrug**.
25.9 Interface Aliasing -- Many IPs on One Physical Card
(The file /usr/src/linux/Documentation/networking/alias.txt contains the kernel documentation

on this.)
If you have one network card which you would like to double as several different IP addresses,
you can. Simply name the interface eth0:n where n is from 0 to some large integer. You can use
ifconfig as before as many times as you like on the same network card--
/sbin/ifconfig eth0:0 192.168.4.1 broadcast 192.168.4.255 netmask 255.255.255.0
--in addition to your regular eth0 device. Here, the same interface can communicate to three
LANs having networks 192.168.4.0, 192.168.5.0, and 192.168.6.0. Don't forget to add routes to
these networks as above.
25.10 Diagnostic Utilities
It is essential to know how to inspect and test your network to resolve problems. The standard
UNIX utilities are explained here.
25.10.1 ping
124
Tel. #: (034) 312-6189 / (034) 729-4327
The ping command is the most common network utility. IP packets come in three types on the
Internet, represented in the Type field of the IP header: UDP, TCP, and ICMP. (The first two,
discussed later, represent the two basic methods of communication between two programs
running on different machines.) ICMP stands for Internet Control Message Protocol and is a
diagnostic packet that is responded to in a special way. Try:
ping metalab.unc.edu
or specify some other well-known host. You will get output like:
PING metalab.unc .edu ( 152.19.254.81) fro m 192.168.3.9 : 56(84) by tes o f dat a.
64 bytes from 152.19.254.81: icmp_seq=0 ttl=238 time=1059.1 ms
5 64 bytes from 152.19.254.81: icmp_seq=3 ttl=238 time=1179.9 ms
What is happening is that ping is sending ICMP packets to metalab.unc.edu, which is
automatically responding with a return ICMP packet. Being able to ping a machine is often the
acid test of whether you have a correctly configured and working network interface. Note that
some sites explicitly filter out ICMP packets, so, for example, ping cnn.com won't work.
ping sends a packet every second and measures the time it takes to receive the return
packet--like a submarine sonar ``ping.'' Over the Internet, you can get times in excess of 2
seconds if the place is remote enough. On a local LAN this delay will drop to under a millisecond.
If ping does not even get to the line PING metalab.unc.edu..., it means that ping cannot resolve
the host name. You should then check that your DNS is set up correctly--see Chapter 27. If ping
gets to that line but no further, it means that the packets are not getting there or are not getting
back. In all other cases, ping gives an error message reporting the absence of either routes or
interfaces.
traceroute
traceroute is a rather fascinating utility to identify where a packet has been. It uses UDP packets
or, with the -I option, ICMP packets to detect the routing path. On my machine,
traceroute metalab.unc.edu
traceroute to metalab.unc.edu (152.19.254.81), 30 hops max, 38 byte packets
1 192.168.3.254 (192.168.3.254) 1.197 ms 1.085 ms 1.050 ms
2 192.168.254.5 (192.168.254.5) 45.165 ms 45.314 ms 45.164 ms
3 cranzgate (192.168.2.254) 48.205 ms 48.170 ms 48.074 ms
5 4 cranzposix (160.124.182.254) 46.117 ms 46.064 ms 45.999 ms
5 cismpjhb.posix.co.za (160.124.255.193) 451.886 ms 71.549 ms 173.321 ms
6 cisap1.posix.co.za (160.124.112.1) 274.834 ms 147.251 ms 400.654 ms
7 saix.posix.co.za (160.124.255.6) 187.402 ms 325.030 ms 628.576 ms
125
Tel. #: (034) 312-6189 / (034) 729-4327
8 ndf-core1.gt.saix.net (196.25.253.1) 252.558 ms 186.256 ms 255.805 ms
10 9 ny-core.saix.net (196.25.0.238) 497.273 ms 454.531 ms 639.795 ms
10 bordercore6-serial5-0-0-26.WestOrange.cw.net (166.48.144.105) 595.755 ms 595.
174 ms *
11 corerouter1.WestOrange.cw.net (204.70.9.138) 490.845 ms 698.483 ms 1029.369
ms
12 core6.Washington.cw.net (204.70.4.113) 580.971 ms 893.481 ms 730.608 ms
15 13 204.70.10.182 (204.70.10.182) 644.070 ms 726.363 ms 639.942 ms
14 mae-brdr-01.inet.qwest.net (205.171.4.201) 767.783 ms * *
15 * * *
16 * wdc-core-03.inet.qwest.net (205.171.24.69) 779.546 ms 898.371 ms
17 atl-core-02.inet.qwest.net (205.171.5.243) 894.553 ms 689.472 ms *
18 atl-edge-05.inet.qwest.net (205.171.21.54) 735.810 ms 784.461 ms 789.592 ms
20 19 * * *
20 * * unc-gw.ncren.net (128.109.190.2) 889.257 ms
21 unc-gw.ncren.net (128.109.190.2) 646.569 ms 780.000 ms *
22 * helios.oit.unc.edu (152.2.22.3) 600.558 ms 839.135 ms
gives
You can see that there were twenty machines [This is actually a good argument for why
``enterprise''-level web servers have no use in non-U.S. markets: there isn't even the network
speed to load such servers, thus making any kind of server speed comparisons superfluous.] (or
hops) between mine and metalab.unc.edu.
tcpdump
tcpdump watches a particular interface for all the traffic that passes it--that is, all the traffic of
all the machines connected to the same hub (also called the segment or network segment). A
network card usually grabs only the frames destined for it, but tcpdump puts the card into
promiscuous mode, meaning that the card is to retrieve all frames regardless of their destination
hardware address.
IP Addresses
About IP Addresses
The key to understanding IP, and all of the issues related to IP, is knowing what a routing table
looks like and the effects each IP topic has on the entries in a routing table. To begin with, let's
review the basics. IP addresses are 32 bit numbers, most commonly represented in dotted
decimal notation (xxx.xxx.xxx.xxx). Each decimal number represents eight bits of binary data,
and therefore can have a decimal value between 0 and 255. IP addresses most commonly come
as class A, B, or C. It's the value of the first number of the IP address that determines the class
to which a given IP address belongs. Class D addresses are used for multi-cast applications.
126
Tel. #: (034) 312-6189 / (034) 729-4327
(For a full explanation of class D addresses, refer to "Diving Through the Layers" .) The range of
values for these classes are given below.
Class Range Allocation
A 1-126 N.H.H.H
B 128-191 N.N.H.H
C 192-223 N.N.N.H
D 224-239 Not applicable
N=Network
H=Host
Note 1: 127.0.0.0 is a class A network,

but is reserved for use as a loopback address
(typically 127.0.0.1).
Note 2: The 0.0.0.0 network is reserved for use as the default route.
Note 3: Class D addresses are used by groups of hosts or routers
that share a common characteristic: e.g. all OSPF devices
respond to packets sent to address 224.0.0.2
Note 4: Class E addresses exist (240-248),
but are reserved for future use
The class of an address defines which portion of the address identifies the Network number and
which portion identifies the Host, as illustrated above, as N and H.
So, without any subnetting (which we will come to a little later), a routing table will keep track of
a) network numbers, b) the next hop router to use to get to that network, and c) the interface
this next hop router is reachable through. A simple network with the corresponding routing table
for a Cisco router is illustrated below.
127
Tel. #: (034) 312-6189 / (034) 729-4327
C 199.2.2.0 directly connected Ethernet 0
C 10.0.0.0 directly connected Token-ring 1
C 152.8.0.0 directly connected Ethernet 1
I 200.1.1.0 via 152.8.1.2 Ethernet 1
Since Cisco doesn't give headings for these columns, you need to know what each column
consists of. The first column of the routing table indicates how the network number was
discovered. C stands for Connected and I indicates the network was learned from the IGRP
routing protocol. For a full description of the routing table as it appears in a UNIX host and a
Cisco router, refer to "Should RIP Rest In Peace" .
The important thing to realize is that while a routing table keeps track of network numbers, no
one assigns a network number to any piece of equipment. Every interface of a router or host
connected on the network must have an IP address and a subnet mask defined (many pieces of
equipment will assign a default subnet mask if none is applied). From this IP address and subnet
mask, the network number is derived by the IP stack and tracked in the routing table.
(This is the exact opposite of what happens in a NetWare network. In NetWare, you assign a
network number to a server LAN card, which is used by all workstations on that wire. The
workstations use MAC addresses as IPX node numbers.)
Routing tables can get very large. Internet backbone routers can have over 40,000 routes
defined in them. In most corporate networks, the routing table is much smaller, as there are not
so many subnets that need to be reached.
Many large routers, particulary internet routers, use a method called Classless Interdomain
Routing (CIDR) to reduce the number of entries a router needs in its routing table. If we
imagine, for instance, that all the Class C addresses that start with the value 194 are allocated
for use in Europe, it would significantly reduce the number of entries in Internet routers in the
US if there was only one entry for all these class C addresses, rather than a separate entry in
the routing table for each one. CIDR works if (as in this example) all the networks with the first
octet value of 194 are physically located in one area of the network.
IP addresses are used to deliver packets of data across a network and have what is termed
end-to-end significance. This means that the source and destination IP address remains constant
as the packet traverses a network. Each time a packet travels through a router, the router will
reference it's routing table to see if it can match the network number of the destination IP
address with an entry in its routing table. If a match is found, the packet is forwarded to the
next hop router for the destination network in question (note that a router does not necessarily
know the complete path from source to destination--it just knows the next hop router to go to).
If a match is not f ound, one of two things happens. The packet may be forwarded to the router
defined as the default gateway, or the packet may be dropped by the router. (In the language of
TCP/IP, a gateway is a router.)
Packets are forwarded to a default router in the belief that the default router has more network
information in its routing table and will therefore be able to route the packet correctly on to its
final destination. This is typically used when connecting a LAN with PCs on it to the Internet.
128
Tel. #: (034) 312-6189 / (034) 729-4327
Each PC will have the router that connects the LAN to the Internet defined as its default
gateway.
A default gateway is seen in a routing table of a host as follows: the default route 0.0.0.0 will be
listed as the destination network, and the IP address of the default gateway will be listed as the
next hop router.
If the source and destination IP addresses remain constant as the packet works its way through
the network, how is the next hop router addressed? In a LAN environment this is handled by the
MAC (Media Access Control) address, as illustrated below. The key point is that the MAC
addresses will change every time a packet travels though a router, however, the IP addresses
will remain constant.
PC1Router E0 Router E1 PC2

MAC Address M1 M2 M3 M4
Software (IP) address 11 12 13 14
A packet sent from PC1 to PC2 will look like this at point A:
Destination Source Destination Source Data

MAC MAC IP IP
M2 M1 14 11 1001001
A packet sent from PC1 to PC2 will look like this at point B:
Destination Source Destination Source Data

MAC MAC IP IP
M4 M3 14 11 1001001
IP-based Networks
Modern digital technology allows different sectors, e.g. telecom, data, radio and television, to be
merged together. This occurrence, commonly known as convergence, is happening on a global
scale and is drastically changing the way in which both people and devices communicate. At the
129
Tel. #: (034) 312-6189 / (034) 729-4327
center of this process, forming the backbone and making convergence possible, are IP-based
networks.
Services and integrated consumer devices for purposes such as telephony, entertainment,
security or personal computing are constantly being developed, designed and converged
towards a communication standard that is independent from the underlying physical connection.
The cable network, for instance, first designed for transmitting television to the consumer, can
now also be utilized for sending e-mail, surfing the Web or even monitoring a network camera
sending live pictures from another continent. Furthermore, these features are also available over
other physical networks, e.g. telephone, mobile phone, satellite and computer networks.
This white paper introduces the central components of IP-based network technology, and in
doing so it will demonstrate the tremendous benefits this new technology has to offer.
Basics in network communication
The Internet has become the most powerful factor guiding the ongoing convergence process.
This is mainly due to the fact that the Internet protocol suite has become a shared standard
used with almost any service. The Internet protocol suite consists primarily of the Internet
Protocol (IP) and the Transport Control Protocol (TCP); consequently, the term TCP/IP
commonly refers to the whole protocol family.
IP-based networks are of great importance in today’s information society. At first glance, this
technology might appear a bit confusing and overwhelming. Therefore, we’ll start by presenting
the underlying network components upon which this technology is built.
A network is comprised of two fundamental parts, the nodes and the links. A node is some type
of network device, such as a computer. Nodes are able to communicate with other nodes
through links, like cables. There are basically two different network techniques for establishing
communication between nodes on a network: the circuit-switched network and the
packet-switched network techniques. The former is used in a traditional telephone system, while
the latter is used in IP-based networks.
A circuit-switched network creates a closed circuit between two nodes in the network to establish
a connection. The established connection is thus dedicated to the communication between the
two nodes. One of the immediate problems with dedicated circuits is wasted capacity, since
almost no transmission uses the circuit 100 percent of the time. Also, if a circuit fails in the
middle of a transmission, the entire connection must be dropped and a new one established. For
illustration purposes, take a look at a telephone connection over a circuit-switched network
(Figure 1).
130
Tel. #: (034) 312-6189 / (034) 729-4327
Network nodes
Established
connection
Network link
Figure 1: A circuit-switched network utilizes a dedicated closed circuit
IP-based networks on the other hand utilize a packet-switched network technology, which uses
available capacity much more efficiently and minimizes the risk of possible problems, such as a
disconnection. Messages sent over a packet-switched network are first divided into packets
containing the destination address. Then, each packet is sent over the network with every
intermediate node and router in the network determining where the packet goes next. A packet
does not need to be routed over the same links as previous related packets. Thus, packets sent
between two network devices can be transmitted over different routes in the event of a link
breakdown or node malfunction.
Transmission Fundamentals
IP-based network solutions are both flexible and economical substitutes for solutions that utilize
old network technologies. The diverse properties between these technologies result from how
information is represented, transmitted and managed. Information is simply structured
collections of data, and thus takes its meaning from the interpretation we give it. There are two
fundamental types of data, analog and digital, and both possess different behaviors and
characteristics.
Analog data is expressed as continuously variable waves and thus takes on continuous values.
Examples include voice and video.
Digital data on the other hand is represented as a sequence of bits, or ones and zeros. This
digitization allows any kind of information to be measured and represented as digital data. So,
text, sound and pictures can be represented as a sequence of bits. Digital data can also be
compressed to allow higher transmission rates and it can be encrypted for secure transmissions.
In addition, a digital signal is exact and any related noise can easily be filtered out. Digital data
can be transmitted through three general types of media—metal such as copper; optical fiber or
radio waves.
The techniques represented below offer the first building block for digital communications, the
cable and antenna layer (Figure 3). This layer allows us to send and receive digital data over a
131
Tel. #: (034) 312-6189 / (034) 729-4327
wide variety of media. However, more building blocks are required for successful digital
communication.
Cable and antenna layer
Figure 3: Cable and antenna layer - the first building block
The Local Area Network Infrastructure

This section will go one step further by discussing digital communication. You might ask, “What
is the difference between transmission and communication?” Consider an analogy from human
speech. Think about the acoustic waves in the air generated by speaking. These waves are
transmitted, but they are a long way from communicating. The words that come out must be
organized to make any sense. If they come out to quickly or too slowly, the speaker will not be
understood. If many people speak simultaneously no one is understood. If someone speaks a
language you don’t understand, information is lost. Speaking generates information, but it is
not necessarily communicated, or understood.
Digital communication has similar problems that need to be overcome. The receiver must know
how message bits are organized to understand the message. The receiver must know the rate at
which the bits are arriving to interpret the message. Additionally, some rules must specify what
will happen if many network devices try to use a shared media simultaneously. The best way to
ensure that network devices send and receive in compatible ways is to adhere to standardized
protocols that define the rules and the manner in which the devices initiate and carry on
communication.
We have until now focused on communication between two network devices. However, several
different connection strategies and protocols exist that can be used to maintain communication
among many network devices.
Local Area Networks (LANs) are used for connecting network devices over a relatively short
distance. Typically, a LAN operates in a limited space, such as an office building, a school or a
home. LANs are usually owned and managed by a single person or organization. They also use
certain specific connectivity technologies, often some type of shared media.
An important feature of a LAN is its topology, where the term topology refers to the layout of
connected network devices on a network. We can think of topology as a network's shape.
Network topologies can be categorized into the following basic types:
· The bus topology uses a shared communication medium, often referred to as a

common bus, to connect all network devices (Figure 4). A device that wants to communicate
with another device on the network sends the packet onto the bus. All devices that are
132
Tel. #: (034) 312-6189 / (034) 729-4327
connected to the bus will receive the sent packet but the intended recipient is the only device
that actually accepts and processes the packets.
Figure 4: Bus topology uses a common bus to connect network devices
· · The ring topology is structured in such a way that every network device on the
network has exactly two neighbors for their communication purposes. All packets travel
along a ring in the same direction (Figure 5).
Figure 5: Ring topology uses a ring structure to connect network devices
· · The star topology features a logical communication center to which all network
devices are directly connected. Each device requires a separate cable to the central point
and consequently all packets will travel through the communication center.
There are several different protocols that can be utilized together with each network topology.
Aside from identifying the standards of communications between the network devices, a protocol
sets the technical specifications needed to transmit data within a network. To transmit a
message to another device in a network, the message is split into data packets. These data
packets are then transmitted via the communication media and are reassembled again at the
receiving end.
133
Tel. #: (034) 312-6189 / (034) 729-4327
The standardized protocols utilize different network topologies together with the cable and
antenna layer to build different LAN architectures that are either wired or wireless. These
protocols offer the second building block for successful digital communications, the transmission
layer (Figure 7).
Transmission layer
Figure 7: Transmission layer - the second building block
Interconnecting LANs in an IP-based Architecture
So far, we have described how network devices can communicate over different types of LANs.
However, different LANs are designed for different goals and needs. Hence, every so often it is
necessary to interconnect several LANs to allow communication over the network boundaries.
Such a geographically scattered, interconnected collection of LANs is commonly referred to as a
Wide Area Network (WAN). Probably the most familiar WAN is the Internet, which spans most
of the globe.
Shared communication architecture is required for all users, such as private persons,
enterprises, public administration offices and other organizations, to be able to exchange digital
information with one another over a WAN. This architecture should be an open standard and
support different transmission layer protocols, particularly those that can be used over a variety
of transmission media. Fortunately, the Internet protocol suite provides a well-designed solution
that fits these requirements.
5.1 The Internet protocol suite

The Internet protocol suite is a layered protocol family where each layer builds upon the layer
below it, adding new functionality. The lowest layer is concerned purely with sending and
receiving data utilizing the transmission layer. At the top are protocols designed for specific
tasks, such as sending and receiving motion pictures, sound and control information. The
protocols in between handle things such as dividing the message data into packets and
forwarding them reliably between network devices.
134
Tel. #: (034) 312-6189 / (034) 729-4327
5.2 Internet Protocol
The Internet Protocol (IP) is the basis of the Internet protocol suite and is the single most
popular network protocol in the world. IP enables data to be transmitted across and between
local area networks, hence the name: Inter-net Protocol. Data travels over an IP-based network
in the form of IP packets (data units). Each IP packet includes both a header and the message
data itself, where the header specifies the source, the destination, and other information about
the data.
IP is a connectionless protocol where each packet is treated as a separate entity, like a postal
service. Any mechanisms for ensuring that sent data arrives in a correct and intact manner are
provided by higher-layer protocols in the suite.
Each network device has at least one IP address that uniquely identifies it from all other devices
on the network. In this manner, intermediate nodes can correctly guide a sent packet from the
source to the destination.
5.3 Transport Protocol

The Transport Control Protocol (TCP) is the most common protocol for assuring that an IP packet
arrives in a correct and intact manner. TCP provides reliable transmission of data for upper layer
applications and services in an IP environment. TCP offers reliability in the form of a
connection-oriented, end-to-end packet delivery through an interconnected network.
5.4 An Internet Protocol suite summary

The Internet Protocol suite provides an adaptation to the transmission layer protocols and offers
a standardized architecture for communication over an interconnected collection of LANs, i.e. a
WAN. This is a tremendous advance, mainly because we’re able to connect and communicate
over different physical connections in a standardized way. With IP as the basis, the Internet
Protocol suite provides the third building block for successful digital communications, the IP layer
(Figure 8).
135
Tel. #: (034) 312-6189 / (034) 729-4327
IP layer
Transmission layer
Figure 8: IP layer - the third building block
Benefit from the IP-based Architecture
The Internet Protocol suite brings together all transmission layer protocols into a single,
standardized protocol architecture, which can be utilized by applications for different
communication purposes. As a direct result, any application that supports TCP/IP will also be
able to communicate over any IP-based network.
It should be easy to see that this standardized architecture has revolutionized network communication.
An ever-increasing number of applications that transfer text, sound, live pictures and more utilize
IP-based architecture. All these applications and application protocols constitute the application layer and
provide the fourth, and final, building block for successful digital communications (Figure 9)[1].
136
Tel. #: (034) 312-6189 / (034) 729-4327
Application layer
IP layer
Transmission layer
Figure 9: Application layer - the fourth building block
Convergence
Modern digital technology allows for convergence where different services, and combinations of
these services, can be provided through infrastructures that formerly accommodated only one
type of service. There are three major factors that create the conditions for convergence: digital
technology, transmission technology and standardized communication protocols. Digital
technology allows all information—text, sound and motion pictures, for example—to be
represented as bits and transmitted as sequences of ones and zeros. Transmission technology
enables better utilization of available capacity in different infrastructures. Consequently, services
that require high capacity can be provided by infrastructures previously able to deliver only
simpler services.
We have already seen how IP-based technology provides an excellent architecture for the
process of ongoing convergence. At the heart of the Internet Protocol suite is the Internet
Protocol, which represents the building block that uniformly connects different physical networks
with a variety of applications. In addition, presently available IP-based solutions can be fully
integrated with other available systems.
Case Study
137
Tel. #: (034) 312-6189 / (034) 729-4327
So far we have discussed the structure of the IP-based architecture, especially in comparison
with traditional circuit-switched networks. However, the preceding sections have not contained
any real applications that take advantage of this architecture. IP-based architecture creates
great opportunities for new application domains. Hence, applications that previously could not be
realized can now be successfully implemented. Additionally, application domains built upon older
technologies derive increased functionality when utilizing IP-based technology. For illustration,
consider an application domain that has clearly taken advantage of IP-based architecture: visual
surveillance systems.
In today’s society, the demand for visual surveillance systems has been steadily increasing.
Different camera solutions are used for monitoring activities in a variety of environments, such
as shops, enterprise buildings and prisons. Up until recently, Closed Circuit Television systems
(CCTV systems) were the only alternative for such monitoring. These dedicated systems typically
require their own communication link between the camera and the monitor. This separate link is
expensive to buy, install and maintain. Camera images are transmitted over the dedicated
cabling network to time-lapse video recorders or dedicated monitors at a control center.
A modern IP-based visual surveillance system on the other hand is not limited in the same way
as a traditional CCTV system. Enterprises can install network cameras, IP-based visual
surveillance cameras that plug directly into the enterprise network. Such cameras have their
own IP address, much like any network device. The main differences between these systems and
CCTV systems are that video digitization is performed at the camera level and the Internet
Protocol suite is utilized for transferring the pictures onto the network. This is beneficial since
IP-based networks are generally available in most buildings, and because TCP/IP can be utilized
with almost any existing network, there is probably no need for extra cabling. A network
camera system, in comparison with a CCTV system, also saves money by reducing the amount
of dedicated equipment needed to manage the security system. For example, no dedicated
monitors are required.
An IP-based solution also allows images to be remotely stored and monitored over any
interconnected network, such as the Internet. This alone creates huge advantages for
enterprises that wish to outsource the monitoring of their offices and facilities to a third party
surveillance and monitoring center. This center simply needs a password and the IP-address to
access live pictures, via the Internet, from a camera placed anywhere in the world. Moreover,
the IP-based architecture creates a new world in which different applications can be completely
integrated. For instance, motion pictures can be distributed to other network solutions, such as
factory control management systems and access control systems.
Conclusion
138
Tel. #: (034) 312-6189 / (034) 729-4327
The Internet Protocol suite has rapidly grown into a widespread, fundamental building block for
information exchange. As communication technology becomes increasingly important, there is
growing pressure to use this technology to reduce costs without sacrificing any capabilities or
benefits. IP-based networks address many of the problems faced in this complex environment,
while providing an elegant solution that meets present needs, as well as those to come.
Ultimately, all forms of communications, including data, voice, motion pictures and
entertainment, will converge into a common transporting network.
The primary benefits of an IP-based network strategy are the cost savings and operational
improvements from using one converged network instead of several smaller networks dedicated
to specific purposes, like data, voice and motion pictures. The second most important group of
benefits from network convergence is in enabling new applications. New applications not only
drive cost reductions; they can also be a source of new revenue as they provide value essential
to enterprises and users.
Convergence is here and the benefits are real. Now it’s time to pick strategic partners--those
who understand the broad scope of needs and are committed to meeting them--and take the
first step towards an IP-based future.
PHASE II: “Voice Over IP – VOIP”
Introduction to VOIP
Since the telephone was invented in the late 1800s, telephone communication has not changed
substantially. Of course, new technologies like digital circuits, DTMF (or, "touch tone"), and
caller ID have improved on this invention, but the basic functionality is still the same. Over the
years, service provides made a number of changes "behind the scenes" to improve on the kinds
and types of services offered to subscribers, including toll-free numbers, call-return, call
forwarding, etc. By and large, users do not know how those services work, but they did know
two things: the same old telephone is used and the service provider charges for each and every
little incremental service addition introduced.
In the 1990s, a number of individuals in research environments, both in educational and

corporate institutions, took a serious interest in carrying voice and video over IP networks,
especially corporate intranets and the Internet. This technology is commonly referred to today
as VoIP and is, in simple terms, the process of breaking up audio or video into small chunks,
transmitting those chunks over an IP network, and reassembling those chunks at the far end so
that two people can communicate using audio and video.
This idea of VoIP is certainly not new, as there are research papers and patents dating back
several decades and demonstrations of the concept given at various times over the years. VoIP
took center stage with the "information super highway" (or, the Internet) concept that was
popularized by former Vice President Al Gore in the 1990s, as the Internet would make it
139
Tel. #: (034) 312-6189 / (034) 729-4327
possible to interconnect every home and every business with a packet-switched data network.
Before Al Gore's effort to grow the Internet, the Internet was generally limited to use in
academic environments, but the possibility of mass deployment of the Internet sparked this
renewed interest in VoIP.
Why is VoIP Important?
One of the most important things to point out is that VoIP is not limited to voice
communication. In fact, a number of efforts have been made to change this popular marketing
term to better reflect the fact that VoIP means voice, video, and data conferencing. All such
attempts have failed up to this point, but do understand that video telephony and real-time text
communication ( ToIP), for example, is definitely within the scope of the VoIP.
VoIP is important because, for the first time in more than 100 years, there is an opportunity to
bring about significant change in the way that people communicate. In addition to being able to
use the telephones we have today to communicate in real-time, we also have the possibility of
using pure IP-based phones, including desktop and wireless phones. We also have the ability to
use videophones, much like those seen in science fiction movies. Rather than calling home to
talk to the family, a person can call home to see the family.
One of the more interesting aspects of VoIP is that we also have the ability to integrate a
stand-alone telephone or videophone with the personal computer. One can use a computer
entirely for voice and video communications (softphones), use a telephone for voice and the
computer for video, or can simply use the computer in conjunction with a separate voice/video
phone to provide data conferencing functions, like application sharing, electronic whiteboarding,
and text chat.
VoIP allows something else: the ability to use a single high-speed Internet connection for all
voice, video, and data communications. This idea is commonly referred to as convergence and is
one of the primary drivers for corporate interest in the technology. The benefit of convergence
should be fairly obvious: by using a single data network for all communications, it is possible to
reduce the overall maintenance and deployment costs. The benefit for both home and corporate
customers is that they now have the opportunity to choose from a much larger selection of
service providers to provide voice and video communication services. Since the VoIP service
provider can be located virtually anywhere in the world, a person with Internet access is no
longer geographically restricted in their selection of service providers and is certainly not bound
to their Internet access provider.
In short, VoIP enables people to communicate in more ways and with more choices.
How Does VoIP Work?
It is very easy to get into a discussion that is very technical and confusing to most readers. The
purpose of this section will be to provide a very high-level overview of Voice over IP ( VoIP)
aimed at those who do not consider themselves experts in the subject and hopefully with
enough clarity that it serves as a good introduction to most readers.
140
Tel. #: (034) 312-6189 / (034) 729-4327
Many people have used a computer and a microphone to record a human voice or other sounds.
The process involves sampling the sound that is heard by the computer at a very high rate (at
least 8,000 times per second or more) and storing those "samples" in memory or in a file on the
computer. Each sample of sound is just a very tiny bit of the person's voice or other sound
recorded by the computer. The computer has the wherewithal to take all of those samples and
play them, so that the listener can hear what was recorded.
VoIP is based on the same idea, but the difference is that the audio samples are not stored
locally. Instead, they are sent over the IP network to another computer and played there.
Of course, there is much more required in order to make VoIP work. When recording the sound
samples, the computer might compress those sounds so that they require less space and will
certainly record only a limited frequency range. There are a number of ways to compress audio,
the algorithm for which is referred to as a "compressor/de-compressor", or simply CODEC.
Many CODECs exist for a variety of applications (e.g., movies and sound recordings) and, for
VoIP, the CODECs are optimized for compressing voice, which significantly reduce the bandwidth
used compared to an uncompressed audio stream. Speech CODECs are optimized to improve
spoken words at the expense of sounds outside the frequency range of human speech. Recorded
music and other sounds do not generally sound very good when passed through a speech
CODEC, but that is perfectly OK for the task at hand.
Once the sound is recorded by the computer and compressed into very small samples, the
samples are collected together into larger chunks and placed into data packets for transmission
over the IP network. This process is referred to packetization. Generally, a single IP packet will
contain 10 or more milliseconds of audio, with 20 or 30 milliseconds being most common.
Vint Cerf, who is often called the Father of the Internet, once explained packets in a way that is
very easy to understand. Paraphrasing his description, he suggested to think of a packet as a
postcards sent via postal mail. A postcard contains just a limited amount of information. To
deliver a very long message, one must send a lot of postcards. Of course, the post office might
lose one or more postcards. One also has to assemble the received postcards in order, so some
kind of mechanism must be used to properly order to postcards, such as placing a sequence
number on the bottom right corner. One can think of data packets in an IP network as
postcards.
Just like postcards sent via the postal system, some IP data packets get lost and the CODECs
must compensate for lost packets by "filling in the gaps" with audio that is acceptable to the
human ear. This process is referred to as packet-loss concealment (PLC). In some cases,
packets are sent multiple times in order to overcome packet loss. This method is called,
appropriately enough, redundancy. Another method to address packet loss, known as
forward-error correction (FEC), is to include some information from previously transmitted
packets in subsequent packets. By performing mathematical operations in a particular FEC
scheme, it is possible to reconstruct a lost packet from information bits in neighboring packets.
Packets are also sometimes delayed, just as with the postcards sent through the post office. This
is particularly problematic for VoIP systems, as delays in delivering a voice packet means the
information is too old to play. Such old packets are simply discarded, just as if the packet was
141
Tel. #: (034) 312-6189 / (034) 729-4327
never received. This is acceptable, as the same PLC algorithms can smooth the audio to provide
good audio quality.
Computers generally measure the packet delay and expect the delay to remain relatively
constant, though delay can increase and decrease during the course of a conversation. Variation
in delay (called jitter) is the most frustrating for IP devices. Delay, itself, just means it takes
longer for the recorded voice spoken by the first person to be heard by the user on the far end.
In general, good networks have an end-to-end delay of less than 100ms, though delay up to
400ms is considered acceptable (especially when using satellite systems). Jitter can result in
choppy voice or temporary glitches, so VoIP devices must implement jitter buffer algorithms to
compensate for jitter. Essentially, this means that a certain number of packets are queued
before play-out and the queue length may be increased or decreased over time to reduce the
number of discarded, late-arriving packets or to reduce "mouth to ear" delay. Such "adaptive
jitter buffer" schemes are also used by CD recorders and other types of devices that deal with
variable delay.
Video works in much the same way as voice. Video information received through a camera is
broken into small pieces, compressed with a CODEC, placed into small packets, and transmitted
over the IP network. This is one reason why VoIP is promising as a new technology: adding
video or other media is relatively simple. Of course, there are certain issues that must be
considered that are unique to video (e.g., frame refresh and much higher bandwidth
requirements), but the basic principles of VoIP equally apply to video telephony.
Of course there is much more to VoIP than just sending the audio/video packets over the
Internet. There must also be an agreed protocol for how computers find each other and how
information is exchanged in order to allow packets to ultimately flow between the
communicating devices. There must also be an agreed format (called payload format) for the
contents of the media packets. We will describe some of the popular VoIP protocols in the next
section.
Through this section, we have focused on computers that communicate with each other.
However, VoIP is certainly not limited to desktop computers. VoIP is implemented in a variety of
hardware devices, including IP phones, analog terminal adapters (ATAs), and gateways. In
short, a large number of devices can enable VoIP communication, some of which allow one to
use traditional telephone devices to interface with the IP networks: one does not have to throw
out existing equipment to migrate to VoIP.
VoIP Protocols
There are a number of protocols that may be employed in order to provide for VoIP
communication services. In this section, we will focus on those which are most common to the
majority of the devices deployed and being deployed today.
142
Tel. #: (034) 312-6189 / (034) 729-4327
Virtually every device in the world uses a standard called Real-Time Protocol (RTP) for
transmitting audio and video packets between communicating computers. RTP is defined by the
IETF in RFC 3550. The payload format for a number of CODECs are defined in RFC 3551,
though payload format specifications are defined in documents also published by the ITU and in
other IETF RFCs. RTP also addresses issues like packet order and provides mechanisms (via the
Real-Time Control Protocol, or RTCP, also defined in RFC 3550) to help address delay and jitter.
One of the areas of concern for people communicating over the Internet is the potential a person
to eavesdrop on communication. To address these security concerns, RTP was improved upon
with the result being called Secure RTP (defined in RFC 3711). Secure RTP provides for
encryption, authentication, and integrity of the audio and video packets transmitted between
communicating devices.
Before audio or video media can flow between two computers, various protocols must be
employed to find the remote device and to negotiate the means by which media will flow
between the two devices. The protocols that are central to this process are referred to as
call-signaling protocols, the most popular of which are H.323 and Session Initiation Protocol
(SIP) and they both rely on static provisioning, RAS ( ITU-T Rec. H.225.0), DNS, TRIP (RFC
3219), ENUM (RFC 3762), and other protocols to find other users.
H.323 and SIP both have their origins in 1995 as researchers looked to solve the problem of how
two computers can initiate communication in order to exchange audio and video media streams.
H.323 enjoyed the first commercial success, due to the fact that those working on the protocol
in the ITU worked quickly to publish the first standard in early 1996. SIP, on the other hand,
progressed much more slowly in the IETF, with the first draft published in 1996, but the first
recognized "standard" published later in 1999. SIP was revised over the years and re-published
in 2002 as RFC 3261, which is the currently recognized standard for SIP. These delays in the
standards process resulted in delays in market adoption of the SIP protocol.
Fundamentally, H.323 and SIP allow users to do the same thing: to establish multimedia
communication (audio, video, or other data communication). However, H.323 and SIP differ
significantly in design, with H.323 borrowing heavily from legacy communication systems and
being a binary protocol, and with SIP not adopting many of the information elements found in
legacy systems and being an ASCII-based protocol. Supporters of each protocol have debated at
length as to which approach is better and the results are certainly mixed.
Over the years, there have been a lot of papers debating H.323 vs. SIP, but most of the
arguments have often been "religious" in nature (e.g., "ITU vs. IETF" and "binary versus
ASCII"). Very few of the papers and reports have compared the protocol on the basis of
functionality and what really matters: does the protocol do the job? The fact is, both can do the
job, though H.323 is superior in a number of ways: better interoperability with the PSTN, better
support for video, excellent interoperability with legacy video systems (e.g., H.320), and
reliable out-of-band transport of DTMF. SIP, being a "session initiation protocol", was not
designed to address many of the problems that were raised and solved in legacy communication
systems. SIP was also popularized in the market through misstatements that it was "easy to
143
Tel. #: (034) 312-6189 / (034) 729-4327
implement and debug". The truth is that there is a certain amount of complexity in any
communication system and, no matter how one looks at it, it requires about the same amount of
work to do the same thing two different ways.
In the simplest deployment, the SIP implementation is certainly easier to develop and
troubleshoot. However, there are very few real-world deployments that are "simple". As a result,
SIP proponents have defined a number of non-standard variations of SIP (e.g., SIP-T and SIP-I),
as well as a number of non-standard extensions in order to carry the necessary information or
provide the required functionality. Some have said that there are as many variations of SIP as
there are SIP deployments.
Today, H.323 still commands the bulk of the VoIP deployments in the service provider market
for voice transit, especially for transporting voice calls internationally. H.323 is also widely used
in room-based video conferencing systems and is the #1 protocol for IP-based video systems.
SIP has, most recently, become more popular for use in instant messaging systems, though
there have been no successful commercial deployments of SIP-based instant messaging at the
time of this writing.
Both H.323 and SIP can be referred to as "intelligent endpoint protocols". What this means is
that all of the intelligence required to locate the remote endpoint and to establish media streams
between the local and remote device is an integral part of the protocol. There is another class of
protocols which is complementary to H.323 and SIP referred to as "device control protocols".
Those protocols are H.248 and MGCP.
To understand the purpose of H.248 and MGCP, it is important to first understand the function of
a gateway. A gateway is a device that offers an IP interface on one side and some sort of
legacy telephone interface on the other side. The legacy telephone interface may be complex,
such as an interface to a legacy PSTN switch, or may be a simple interface that allows one to
connect one or a few traditional telephones. Depending on the size and purpose of the gateway,
it may allow IP-originated calls to terminate to the PSTN (and vice-versa) or may simply provide
a means for a person to connect a telephone to the Internet.
Originally, gateways were viewed as monolithic devices that had call control (H.323/SIP) and
hardware required to control the PSTN interface. In 1998, the idea of splitting the gateway into
two logical parts was proposed: one part, which contains the call control logic, is called the
media gateway controller (MGC) or call agent (CA), and the other part, which interfaces with
the PSTN, is called the media gateway (MG). With this functional split, a new interface existed
(going between the MGC and MG), driving the necessity to define MGCP and H.248.
Some service providers provide users with devices that implement H.248 or MGCP (or
comparable protocols). In the core of the network, some device serving as the MGC provides the
H.323 or SIP logic necessary to properly terminate VoIP calls around the world.
Outside of H.323/SIP and H.248/MGCP, there are also non-standard protocols introduced by
various companies that have been very successful in the market. Skype is one such company
that has been extremely successful using a proprietary protocol. Which protocol is best for you?
144
Tel. #: (034) 312-6189 / (034) 729-4327
It really depends on your requirements, but most people simply want to make a phone call and,
as such, it really does not matter.
VoIP-Enabled Services
Many people have proclaimed that VoIP enables all kinds of new services that were never
possible before. This is certainly true, though the hype far exceeds reality and what is practical.
Even so, there are a number of new capabilities which are practical and will come forward as we
continue to deploy VoIP systems.
Video telephony is probably the first new service that will come forward that helps set VoIP
apart from traditional telephone systems. Service providers are already rolling out services
offering video terminals to allow people to call friends and family using video-enabled phones.
VoIP also allows one to potentially launch calls from the PC, determine the availability of friends
and family members (called "presence"), control telephone services from the PC, etc. The
market acceptance of most of these new kinds of services are questionable at this point, but the
potential is there and has certainly garnered a tremendous amount of focus from companies
trying to find a niche in this new market.
The one business application that VoIP, video telephony (or, videoconferencing), and instant
messaging will enable is application sharing and electronic whiteboarding. The ITU has defined
a suite of protocols (called T.120) to address this application and it has been used in tools like
Microsoft NetMeeting. While NetMeeting met some success, it failed to gain wider market
adoption due to the fact that it was somewhat difficult to set up and use in a corporate
environment. By having better integration with the phone and wider deployment of VoIP,
businesses will probably find the ability to do application sharing and electronic whiteboarding
very appealing in order to improve productivity. These kinds of services that are related to VoIP
are most exciting.
Hype vs. Reality
VoIP has enjoyed a significant amount of hype in the marketplace. It was initially viewed as a
way to get free phone calls over the Internet and has evolved to being viewed as the technology
that will replace the legacy PSTN. There have been literally hundreds of companies who have
entered the market, the vast majority of which have failed. As with any new technology, there is
a certain time required to grow the market and the growth of the VoIP market has been much
slower than anticipated.
Even so, VoIP is real, it works, and companies that have been able to "hang in there" are
starting to reap the reward. Literally hundreds of thousands of end users and a very large
number of enterprise customers are now using VoIP as their primary phone service. Also, while
many people do not know, a very large percentage of international phone calls going over IP
VoIP networks today.
The work on VoIP is far from over, though. Many experts in the field are still actively working to
make improvements on the technology. Over time, it should prove to be an adequate replace to
the current PSTN used around the world today and is already an adequate replacement in
145
Tel. #: (034) 312-6189 / (034) 729-4327
limited deployments, such as enterprise environments where network quality-of-service (QoS) is
well-managed. It also works extremely well for residential users who are willing to sacrifice a
little voice quality for significantly lower telephone costs. Companies like Vonage provide an
excellent service to such residential customers.
With that said, there is still a lot of hype. The technology does not always deliver the same QoS
as the PSTN, so customers on networks that are not well-managed may hear distorted or poor
quality audio. As a practical matter, nobody today can come to a person's home and help install
VoIP service so the customer can use VoIP service on all phones in the house. This may sound
like a small matter, but some people simply cannot or will not do the necessary re-wiring in the
home. Finally, some service providers offer very different levels of service and have varying
degrees of reliability. It's not uncommon with some service providers to see phone calls to a
destination work one day and not the next. This fact is not the fault of VoIP, but due to the fact
that some new, smaller VoIP service providers do not have the resources to provide the same
level of reliability found in the older, mature, well-funded PSTN.
As service providers mature in their business, the quality on all fronts will improve. Until then,
VoIP will remain a viable technology that should be approached with some caution. Users of the
technology need to understand the limits and the potential issues before using VoIP as a
replacement for current service. Residential customers should keep a mobile phone as a back-up
"just in case" and enterprise customers should take the necessary steps to provide Quos on
corporate networks.
Next Generation Network (NGN)
One of the interesting side-effects of VoIP is that the technology has forced all of the incumbent
service providers around the world to pause and re-examine their own business. They have all
come to one realization: VoIP will replace the PSTN and is a serious threat to their current
business model.
In an effort to regain control of the explosion of new service providers and competition that will
erode their revenues, traditional service providers have initiated a new effort referred to as the
Next Generation Network (NGN). The definition of the NGN seems fairly benign as defined in ITU
Recommendation Y.2001:
Next Generation Network (NGN): a packet-based network able to provide telecommunication
services and able to make use of multiple broadband, QoS-enabled transport technologies and in
which service-related functions are independent from underlying transport-related technologies.
It offers unrestricted access by users to different service providers. It supports generalized
mobility which will allow consistent and ubiquitous provision of services to users.
Any person who reads this definition and understands the technology would summarize this
definition as "a well-managed Internet". This certainly sounds encouraging for those who hope
to perpetuate the growth of VoIP and other multimedia services.
Unfortunately, not all things are as they appear. One of the statements made in the NGN
specifications is that the IP Multimedia Subsystem (IMS) defined by 3GPP is at the core of the
NGN and "all other" IP services (including data collaboration, movies-on-demand, Internet radio,
146
Tel. #: (034) 312-6189 / (034) 729-4327
etc.) is simply lumped into one small part of the NGN and is given little or no attention at all. As
such, the NGN can rightfully be viewed as a very-much voice-centric effort with no real desire to
grow and encourage other non-voice services.
The NGN work has a long way to go, but there is certainly a lot of hype around the effort and
quite possibly one that will result in stunting the growth of new services and new choices in the
market. In any case, it is far too early to tell what kind of impact the NGN effort will have on the
market.
Voice over Internet Protocol (VoIP), is a technology that allows you to make voice calls using a
broadband Internet connection instead of a regular (or analog) phone line. Some VoIP services
may only allow you to call other people using the same service, but others may allow you to call
anyone who has a telephone number - including local, long distance, mobile, and international
numbers. Also, while some VoIP services only work over your computer or a special VoIP phone,
other services allow you to use a traditional phone connected to a VoIP adapter.
Voice over Internet Protocol, also called VoIP, IP Telephony, Internet telephony,
Broadband telephony, Broadband Phone and Voice over Broadband is the routing of
voice conversations over the Internet or through any other IP-based network.
Companies providing VoIP service are commonly referred to as providers, and protocols which
are used to carry voice signals over the IP network are commonly referred to as Voice over IP
or VoIP protocols. They may be viewed as commercial realizations of the experimental Network
Voice Protocol (1973) invented for the ARPANET providers. Some cost savings are due to
utilizing a single network - see attached image[1] - to carry voice and data, especially where
users have existing underutilized network capacity that can carry VoIP at no additional cost.
VoIP to VoIP phone calls are sometimes free, while VoIP to PSTN may have a cost that's borne
by the VoIP user.
There are two types of PSTN to VoIP services: DID (Direct

Inward Dialing) and access numbers. DID will connect
the caller directly to the VoIP user while access numbers
require the caller to input the extension number of the
VoIP user. Access numbers are usually charged as a local
call to the caller and free to the VoIP user while DID
usually has a monthly fee.[2] There are also DIDs that are
free to the VoIP user but chargeable to the caller.
Frequently Asked Questions
How VoIP / Internet Voice Works

VoIP services convert your voice into a digital signal that
travels over the Internet. If you are calling a regular
phone number, the signal is converted to a regular
telephone signal before it reaches the destination. VoIP
can allow you to make a call directly from a computer, a special VoIP phone, or a traditional
147
Tel. #: (034) 312-6189 / (034) 729-4327
phone connected to a special adapter. In addition, wireless "hot spots" in locations such as
airports, parks, and cafes allow you to connect to the Internet and may enable you to use VoIP
service wirelessly.
What Kind of Equipment Do I Need?

A broadband (high speed Internet) connection is required. This can be through a cable
modem, or high speed services such as DSL or a local area network. A computer, adaptor, or
specialized phone is required. Some VoIP services only work over your computer or a special
VoIP phone, while other services allow you to use a traditional phone connected to a VoIP
adapter. If you use your computer, you will need some software and an inexpensive
microphone. Special VoIP phones plug directly into your broadband connection and operate
largely like a traditional telephone. If you use a telephone with a VoIP adapter, you'll be able to
dial just as you always have, and the service provider may also provide a dial tone.
Is there a difference between making a Local Call and a Long Distance Call?
Some VoIP providers offer their services for free, normally only for calls to other subscribers to
the service. Your VoIP provider may permit you to select an area code different from the area in
which you live. It also means that people who call you may incur long distance charges
depending on their area code and service.
Some VoIP providers charge for a long distance call to a number outside your calling area,
similar to existing, traditional wireline telephone service. Other VoIP providers permit you to call
anywhere at a flat rate for a fixed number of minutes.
If I have VoIP service, who can I call?

Depending upon your service, you might be limited only to other subscribers to the service, or
you may be able to call anyone who has a telephone number - including local, long distance,
mobile, and international numbers. If you are calling someone who has a regular analog phone,
that person does not need any special equipment to talk to you. Some VoIP services may allow
you to speak with more than one person at a time.
What Are Some Advantages of VoIP?

Some VoIP services offer features and services that are not available with a traditional phone, or
are available but only for an additional fee. You may also be able to avoid paying for both a
broadband connection and a traditional telephone line.
What Are Some disadvantages of VoIP?

If you're considering replacing your traditional telephone service with VoIP, there are some
possible differences:
· Some VoIP services don't work during power outages and the service provider may not
offer backup power.
· Not all VoIP services connect directly to emergency services through 9-1-1. For additional
information, see www.voip911.gov.
148
Tel. #: (034) 312-6189 / (034) 729-4327
· VoIP providers may or may not offer directory assistance/white page listings.
Can I use my Computer While I talk on the Phone?

In most cases, yes.
Can I Take My Phone Adapter with me When I Travel?

Some VoIP service providers offer services that can be used wherever a high speed Internet
connection available. Using a VoIP service from a new location may impact your ability to
connect directly to emergency services through 9-1-1. For additional information, see
www.voip911.gov.
Does my Computer Have to be Turned on?

Only if your service requires you to make calls using your computer. All VoIP services require
your broadband Internet connection to be active.
How Do I Know If I have a VoIP phone Call?

If you have a special VoIP phone or a regular telephone connected to a VoIP adapter, the phone
will ring like a traditional telephone. If your VoIP service requires you to make calls using your
computer, the software supplied by your service provider will alert you when you have an
incoming call.
149
Tel. #: (034) 312-6189 / (034) 729-4327
150
Tel. #: (034) 312-6189 / (034) 729-4327
Lesson X:
Introduction
If you've never heard of VoIP, get ready to change

the way you think about long-distance phone calls.
VoIP, or Voice over Internet Protocol, is a
method for taking analog audio signals, like the
kind you hear when you talk on the phone, and
turning them into digital data that can be
transmitted over the Internet.
How is this useful? VoIP can turn a standard

Internet connection into a way to place free
phone calls. The practical upshot of this is that by
using some of the free VoIP software that is
available to make Internet phone calls, you are
bypassing the phone company (and its charges)
entirely.
VoIP is a revolutionary technology that has the potential to completely rework the world's phone
systems. VoIP providers like Vonage have already been around for a little while and are growing
steadily. Major carriers like AT&T are already setting up VoIP calling plans in several markets
around the United States, and the FCC is looking seriously at the potential ramifications of VoIP
service.
Above all else, VoIP is basically a clever "reinvention of the wheel." In this article, we'll explore
the principles behind VoIP, its applications and the potential of this emerging technology, which
will more than likely one day replace the traditional phone system entirely.
The interesting thing about VoIP is that there is not just one way to place a call. There are three
different "flavors" of VoIP service in common use today:
· ATA - The simplest and most common way is through the use of a device called an
ATA (analog telephone adaptor). The ATA allows you to connect a standard phone to
your computer or your Internet connection for use with VoIP. The ATA is an
analog-to-digital converter. It takes the analog signal from your traditional phone and
converts it into digital data for transmission over the Internet. Providers like Vonage
and AT&T CallVantage are bundling ATAs free with their service. You simply crack the
ATA out of the box, plug the cable from your phone that would normally go in the wall
socket into the ATA, and you're ready to make VoIP calls. Some ATAs may ship with
additional software that is loaded onto the host computer to configure it; but in any
case, it is a very straightforward setup.
· IP Phones - These specialized phones look just like normal phones with a handset,
cradle and buttons. But instead of having the standard RJ-11 phone connectors, IP
phones have an RJ-45 Ethernet connector. IP phones connect directly to your router
151
Tel. #: (034) 312-6189 / (034) 729-4327
and have all the hardware and software necessary right onboard to handle the IP call.
Wi-Fi phones allow subscribing callers to make VoIP calls from any Wi-Fi hot spot.
· Computer-to-computer - This is certainly the easiest way to use VoIP. You don't
even have to pay for long-distance calls. There are several companies offering free or
very low-cost software that you can use for this type of VoIP. All you need is the
software, a microphone, speakers, a sound card and an Internet connection,
preferably a fast one like you would get through a cable or DSL modem. Except for
your normal monthly ISP fee, there is usually no charge for computer-to-computer
calls, no matter the distance.
If you're interested in trying VoIP, then you should check out some of the free VoIP software
available on the Internet. You should be able to download and set it up in about three to five
minutes. Get a friend to download the software, too, and you can start tinkering with VoIP to get
a feel for how it works.
The Role of VOIP
Phone Phishing: The role of VoIP in phone attacks
It's happened three times in the past six months. Due to "irregularities" on my credit card
account, I've received voice mails asking me to call my bank at a telephone number mentioned
in the voice mails. Do I call that number? Not with the rise of phone phishing. As users grow
wiser about traditional email-based phishing scams, the bad guys add nasty new twists, the
latest being phone phishing. These techniques, which borrow ideas from traditional phishing,
phone-based social engineering and the emerging widespread deployment of low-cost VoIP, take
two forms. Enterprises that help their users cope with phone phishing now will be better
prepared to defend themselves when the attacks evolve into more serious phone-based spear
phishing attacks.
In its most common incarnation today, phone phishing involves an attacker sending spoofed
spam email that appears to come from a bank, financial services institution or government
agency, claiming that the user's account has been frozen due to fraudulent activity. The email
tells users to call a phone number included in the email to reactivate their credit cards or other
financial accounts. When a user calls this number, a friendly voice message claiming to be a
financial institution prompts the user to enter an account number and/or PIN. The reassuring
voice explains that the account has been reactivated. Unfortunately for the unwitting user, a
fraudster has just harvested vital account information.
Another form of phone phishing is even more insidious, bypassing the spam email all together.
In these scams, attackers use automated scripts to initiate VoIP calls to phone numbers in a
targeted area code. The script uses the wide-open nature of most VoIP services to spoof caller
152
Tel. #: (034) 312-6189 / (034) 729-4327
ID, so that each call appears to come from a legitimate bank. When the script encounters a
user's voice mailbox (either through a plain old telephone service line or another VoIP number),
it leaves a voice message saying that the user's account has been frozen, and exhorts the user
to call a given number to provide the account information, which, of course, the attacker
harvests. Given that voice messages are now being spewed out spam-style, some people refer
to this voice mail spam as SPIT (Spam over Internet Telephony).
It gets even worse. Attackers can gather some account information in advance, such as a name,
credit card number and/or phone number. They pilfer this information from an e-commerce site,
buy it on the black market or retrieve it by other means. The phishing attacks, then, are a
means to complete the information for the account. Attackers gather the expiration date,
three-digit security code, PIN and/or billing address by tricking the user into giving it over the
phone. With this full account data, an attacker can more easily make fraudulent transactions and
create a cloned credit card, a more valuable commodity on the black market than a mere list of
account numbers. Thus, the phone phishing voice mail may include the user's credit card
number, duping the user to call back and provide the remaining account information.
Why are attackers turning to phone phishing? Because it's easy and it works. Attackers rely on
plentiful and disposable VoIP service, along with free, open-source PBX software, such as
Asterisk, which can be used to set up those annoying but professional sounding interactive voice
prompts. Thus, phone phising is also cheap. Using these technologies, attackers can establish a
virtual phone presence from any country in the world using a local telephone number with VoIP
forwarding the call overseas, mimicking the features of a legitimate financial services institution
located in the United States or Europe.
In the near future, the stakes for enterprises might rise even higher, as phone phishers begin to
borrow another idea from traditional phishing, namely spear phishing. Today, email-based spear
phishing attacks are increasingly popular, using targeted emails directed to one organization
attempting to trick its users into installing software or releasing sensitive information in a
focused compromise. With the anticipated rise of phone spear phishing, attackers will trick
enterprise users with emails that contain a phone number to call or even voice messages urging
some action. Using VoIP, the attackers can pretend to be inside the organization itself by using a
nearby phone number, when the attacker is really located across the planet. Phone spear
phishing is essentially targeted, automated, phone-based social engineering on a mass scale.
To protect your organization against phone phishing, start by augmenting your user awareness
program to advise your users about this threat. Explain how it affects them personally and how
they can protect themselves. Tell them that they should never blindly trust email, especially
emailed requests to call phone numbers. And, they shouldn't blindly trust voice mails, especially
those that appear to come from their bank or other financial institutions.
Furthermore, tell your users never to give sensitive information over the phone to unexpected
callers, even if they already have some of the user's personal information. Tell your users to
hang up and call their financial services institution using the number on the back of their card,
which they should write down and keep in a safe place other than their purse or wallet. The
phone number can also be found on a recent statement or the institution's Web site.
153
Tel. #: (034) 312-6189 / (034) 729-4327
You should check whether your enterprise PBX or call manager software has any capabilities for
detecting and filtering repeated calls from an outside number scanning your own phone
numbers. These features, originally created to combat the scourge of war dialing and aggressive
telemarketers, can now help detect and prevent phone phishing in enterprise environments.
Often, PBXes have these capabilities, but they are shut off by default. Turn them on, at least as
an experiment, to try to detect these kinds of attacks against your organization.
Next, update your corporate policies and user awareness program to address targeted phishing
attacks. Specifically, make sure your employees know that certain information, such as
passwords, should never be sent via email or discussed on the phone, no matter who asks for it.
Tell employees who receive such email or phone calls to call the contact number for your
organization's incident handling team, who should review such incidents on a regular basis.
Because some employees have difficulty differentiating between incident handling teams and
help desks, make sure you train help desk personnel to forward any instances of such activity to
your incident response team.
Role of VOIP in a Call Center
Business means interaction with persons and organizations that share common objectives which
leads to conclusions of business goals. This stands true for any business. To get a clear
understanding of the concept of call centers, we need to examine the business process, which
primarily revolves around the purchase or sale of a product, service or concept. It all begins with
an initiating call to make inquiry, based on one’s needs or wants and taking it to logical
conclusion. This day to day interaction is the foundation on which the concept of call center
rests. Interaction may take place between various group of persons, broadly categorized as
Customer and seller; Employer and Employees and so on.
Timely and accurate dissemination of information is what aids the business and in fact facilitates
growth. The concept of call centers has come to its high level of sophistication from rather
humble beginnings that of a telephone operator or an inquiry desk, where one can call in for
information or physically make an inquiry.
With the rapid pace of telecommunications technology development, it has become possible to
use the state of the art systems and equipment to exchange voice, data, and chat. This is made
possible by VOIP. Today, VOIP plays a very crucial role in the call center industry.
The reason why a company might choose VOIP is because it allow them to reduce cost and also
helps them in bringing about a tremendous increase in the level of customer service. With a call
154
Tel. #: (034) 312-6189 / (034) 729-4327
center which is based on IP, the customers call is terminated directly on an IP call server. All the
agents have an IP phone application in their computer and do not rely on a separate telephone
set. An IP based Automatic Call Distributor direct the IP call to the agents PC call is that it
provides for end to end IP transmission without utilizing pulse code modulation conversion or
circuit switched networks. Apart from this it also allows coordination between voice call, web
session, and host software services without having to develop complex computer telephone
integration application.
The main advantage of VOIP is that it allows call centers equipped with the appropriate
connectivity and bandwidth to operate from virtually anywhere in the world, thus taking
advantage of labor availability and competitive labor costs. Because the Call Center uses the
Internet to route the calls, it does not incur into overseas charges (it does however incur VSat
connectivity charges). VOIP call centers pay for Internet connection rather that paying enormous
international long distance charges.
Comparative analysis - TCP - UDP
TCP
Abbreviation of Transmission Control Protocol, and pronounced as separate letters. TCP is one of
the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets,
TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees
delivery of data and also guarantees that packets will be delivered in the same order in which
they were sent.
TCP stands for Transmission Control Protocol. It is described in STD-7/RFC-793. TCP is a

connection-oriented protocol that is responsible for reliable communication between two end
processes. The unit of data transferred is called a stream, which is simply a sequence of bytes.
Being connection-oriented means that before actually transmitting data, you must open the
connection between the two end points. The data can be transferred in full duplex (send and
155
Tel. #: (034) 312-6189 / (034) 729-4327
receive on a single connection). When the transfer is done, you have to close the connection to
free system resources. Both ends know when the session is opened (begin) and is closed (end).
The data transfer cannot take place before both ends have agreed upon the connection. The
connection can be closed by either side; the other is notified. Provision is made to close
gracefully or just abort the connection.
Being stream oriented means that the data is an anonymous sequence of bytes. There is nothing
to make data boundaries apparent. The receiver has no means of knowing how the data was
actually transmitted. The sender can send many small data chunks and the receiver receive only
one big chunk, or the sender can send a big chunk, the receiver receiving it in a number of
smaller chunks. The only thing that is guaranteed is that all data sent will be received without
any error and in the correct order. Should any error occur, it will automatically be corrected
(retransmitted as needed) or the error will be notified if it can't be corrected.
At the program level, the TCP stream look like a flat file. When you write data to a flat file, and
read it back later, you are absolutely unable to know if the data has been written in only one
chunk or in several chunks. Unless you write something special to identify record boundaries,
there is nothing you can do to learn it afterward. You can, for example, use CR or CR LF to
delimit your records just like a flat text file.
At the programming level, TWSocket is fairly simple to use. To send data, you just need to call
the Send method (or any variation such as SendStr) to give the data to be transmitted.
TWSocket will put it in a buffer until it can be actually transmitted. Eventually the data will be
sent in the background (the Send method returns immediately without waiting for the data to be
transmitted) and the OnDataSent event will be generated once the buffer is emptied.
To receive data, a program must wait until it receives the OnDataAvailable event. This event is
triggered each time a data packet comes from the lower level. The application must call the
Receive method to actually get the data from the low-level buffers. You have to Receive all the
data available or your program will go in an endless loop because TWSocket will trigger the
OnDataAvailable again if you didn't Receive all the data.
As the data is a stream of bytes, your application must be prepared to receive data as sent from
the sender, fragmented in several chunks or merged in bigger chunks. For example, if the
sender sent "Hello " and then "World!", it is possible to get only one OnDataAvailable event and
receive "Hello World!" in one chunk, or to get two events, one for "Hello " and the other for
"World!". You can even receive more smaller chunks like "Hel", "lo wo" and "rld!". What happens
depends on traffic load, router algorithms, random errors and many other parameters you can't
control.
156
Tel. #: (034) 312-6189 / (034) 729-4327
On the subject of client/server applications, most applications need to know command
boundaries before being able to process data. As data boundaries are not always preserved, you
cannot suppose your server will receive a single complete command in one OnDataAvailable
event. You can receive only part of a request or maybe two or more request merged in one
chunk. To overcome this difficulty, you must use delimiters.
Most TCP/IP protocols, like SMTP, POP3, FTP and others, use CR/LF pair as command delimiter.
Each client request is sent as is with a CR/LF pair appended. The server receives the data as it
arrives, assembles it in a receive buffer, scans for CR/LF pairs to extract commands from the
received stream, and removes them from the receive buffer.
UDP
Short for User Datagram Protocol, a connectionless protocol that, like TCP, runs on top of IP
networks. Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a
direct way to send and receive datagrams over an IP network. It's used primarily for
broadcasting messages over a network.
UDP stands for User Datagram Protocol. It is described in STD-6/RFC-768 and provides a
connectionless host-to-host communication path. UDP has minimal overhead:; each packet on
the network is composed of a small header and user data. It is called a UDP datagram.
UDP preserves datagram boundaries between the sender and the receiver. It means that the
receiver socket will receive an OnDataAvailable event for each datagram sent and the Receive
method will return a complete datagram for each call. If the buffer is too small, the datagram
will be truncated. If the buffer is too large, only one datagram is returned, the remaining buffer
space is not touched.
UDP is connectionless. It means that a datagram can be sent at any moment without prior
advertising, negotiation or preparation. Just send the datagram and hope the receiver is able to
handle it.
UDP is an unreliable protocol. There is absolutely no guarantee that the datagram will be
delivered to the destination host. But to be honest, the failure rate is very low on the Internet
and nearly null on a LAN unless the bandwidth is full.
Not only the datagram can be undelivered, but it can be delivered in an incorrect order. It
means you can receive a packet before another one, even if the second has been sent before the
first you just received. You can also receive the same packet twice.
157
Tel. #: (034) 312-6189 / (034) 729-4327
Your application must be prepared to handle all those situations: missing datagram, duplicate
datagram or datagram in the incorrect order. You must program error detection and correction.
For example, if you need to transfer some file, you'd better set up a kind of zmodem protocol.
The main advantages for UDP are that datagram boundaries are respected, you can broadcast,
and it is fast.
The main disadvantage is unreliability and therefore complicated to program at the application
level.
ADDRESSING
TCP and UDP use the same addressing scheme. An IP address (32 bits number, always written
as four 8-bit number expressed as unsigned 3-digit decimal numbers separated by dots such as
193.174.25.26) and a port number (a 16-bit number expressed as a unsigned decimal number).
The IP address is used by the low-level protocol (IP) to route the datagram to the correct host
on the specified network. Then the port number is used to route the datagram to the correct
host process (a program on the host).
For a given protocol (TCP or UDP), a single host process can exist at a time to receive data sent
to the given port. Usually one port is dedicated to one process.
advantages of tcp
· the operating system does all the work. you just sit back and watch the show. no need to have
the same bugs in your code that everyone else did on their first try; it's all been figured out for
you.
· since it's in the os, handling incoming packets has fewer context switches from kernel to user
space and back; all the reassembly, acking, flow control, etc is done by the kernel.
· tcp guarantees three things: that your data gets there, that it gets there in order, and that it
gets there without duplication. (the truth, the whole truth, and nothing but the truth...)
· routers may notice tcp packets and treat them specially. they can buffer and retransmit them,
and in limited cases preack them.
· tcp has good relative throughput on a modem or a lan.
disadvantages of tcp
· the operating system may be buggy, and you can't escape it. it may be inefficient, and you
158
Tel. #: (034) 312-6189 / (034) 729-4327
have to put up with it. it may be optimized for conditions other than the ones you are facing,
and you may not be able to retune it.
· tcp makes it very difficult to try harder; you can set a few socket options, but beyond that you
have to tolerate the built in flow control.
· tcp may have lots of features you don't need. it may waste bandwidth, time, or effort on
ensuring things that are irrelevant to the task at hand.
· tcp has no block boundaries; you must create your own.
· routers on the internet today are out of memory. they can't pay much attention to tcp flying
by, and try to help it. design assumptions of tcp break down in this environment.
· tcp has relatively poor throughput on a lossy, high bandwidth, high latency link, such as a
satellite connection or an overfull t1.
· tcp cannot be used for broadcast or multicast transmission.
· tcp cannot conclude a transmission without all data in motion being explicitly acked.
disadvantages of udp
· there are no guarantees with udp. a packet may not be delivered, or delivered twice, or
delivered out of order; you get no indication of this unless the listening program at the other end
decides to say something. tcp is really working in the same environment; you get roughly the
same services from ip and udp. however, tcp makes up for it fairly well, and in a standardized
manner.
· udp has no flow control. implementation is the duty of user programs.
· routers are quite careless with udp. they never retransmit it if it collides, and it seems to be the
first thing dropped when a router is short on memory. udp suffers from worse packet loss than
tcp.
advantages of udp
· it doesn't restrict you to a connection based communication model, so startup latency in
distributed applications is much lower, as is operating system overhead.
· all flow control, acking, transaction logging, etc is up to user programs; a broken os
implementation is not going to get in your way. additionally, you only need to implement and
use the features you need.
159
Tel. #: (034) 312-6189 / (034) 729-4327
· the recipient of udp packets gets them unmangled, including block boundaries.
· broadcast and multicast transmission are available with udp.
disadvantages of tcp for file transfer

· startup latency is significant. it takes at least twice rtt to start getting data back.
· tcp allows a window of at most 64k, and the acking mechanism means that packet loss is
misdetected. tcp stalls easily under packet loss. tcp is more throttled by rtt than bandwidth.
· tcp transfer servers have to maintain a separate socket (and often separate thread) for each
client.
· load balancing is crude and approximate. especially on local networks that allow collisions, two
simultaneous tcp transfers have a tendency to fight with each other, even if the sender is the
same.
advantages of udp for file transfer

· latency can be as low as rtt if the protocol is suitably designed.
· flow control is up to user space; windows can be infinite, artificial stalls nonexistant, latency
well tolerated, and maximum speeds enforced only by real network bandwidth, yet actual
speeds chosen by agreement of sender and receiver.
· receiving an image simultaneously from multiple hosts is much easier with udp, as is sending
one to multiple hosts, especially if they happen to be part of the same broadcast or multicast
group.
a single sending host with multiple transfers proceeding can balance them with excellent
p r e c i s i o n .
The Internet runs on a hierarchical protocol stack. A simplified version of this is shown in figure 1
. The layer common to all Internet applications is the IP (Internet Protocol) layer. This layer
provides a connectionless, unreliable packet based delivery service. It can be described as
connectionless because packets are treated independently of all others. The service is unreliable
because there is no guarantee of delivery. Packets may be silently dropped, duplicated or
delayed and may arrive out of order. The service is also called a best effort service, all attempts
to deliver a packet will be made, with unreliability only caused by hardware faults or exhausted
r e s o u r c e s .
As there is no sense of a connection at the IP level there are no simple methods to provide a
160
Tel. #: (034) 312-6189 / (034) 729-4327
quality of service (QoS). QoS is a request from an application to the network to provide a
guarantee on the quality of a connection. This allows an application to request a fixed amount of
bandwidth from the network, and assume it will be provided, once the QoS request has been
accepted. Also a fixed delay, i.e. no jitter and in order delivery can be assumed. A network that
supports QoS will be protected from congestion problems, as the network will refuse connections
that request larger resources than can be supplied. An example of a network that supports QoS
is the current telephone network, where every call is guaranteed the bandwidth for the call. Most
users at some point have heard the overloaded signal where the network cannot provide the
requested resource required to make a call.
The application decides which transport protocol is used. The two protocols shown here, TCP and
UDP are the most commonly used ones. TCP provides a reliable connection and is used by the
majority of current Internet applications. TCP, besides being responsible for error checking and
correcting, is also responsible for controlling the speed at which this data is sent. TCP is capable
of detecting congestion in the network and will back off transmission speed when congestion
occurs. These features protect the network from congestion collapse.
As discussed in the introduction, VoIP is a real-time service. For real-time properties to be

guaranteed to be met, a network with QoS must be used to provide fixed delay and bandwidth.
It has already been said that IP cannot provide this. This then presents a choice. If IP is a
requirement, which transport layer should be used to provide a system that is most likely to
meet real-time constraints.
As TCP provides features such as congestion control, it would be the preferred protocol to use.
Unfortunately due to the fact that TCP is a reliable service, delays will be introduced whenever a
bit error or packet loss occurs. This delay is caused by retransmission of the broken packet,
along with any successive packets that may have already been sent. This can be a large source
of jitter.
TCP uses a combination of four algorithms to provide congestion control, slow start, congestion
avoidance, fast retransmit and fast recovery. These algorithms all use packet loss as an
indication of congestion, and all alter the number of packets TCP will send before waiting for
acknowledgments of those packets. These alterations affect the bandwidth available and also
change delays seen on a link, providing another source of jitter.
161
Tel. #: (034) 312-6189 / (034) 729-4327
Figure 1: Simplified IP protocol stack
Combined, TCP raises jitter to an unacceptable level rendering TCP unusable for real-time
services. Voice communication has the advantage of not requiring a completely reliable transport
level. The loss of a packet or bit error will often only introduce a click or a minor break into the
output.
For these reasons most VoIP applications use UDP for the voice data transmission. UDP is a thin
layer on top of IP that provides a way to distinguish among multiple programs running on a
single machine. UDP also inherits all of the properties of IP that TCP attempts to hide. UDP is
therefore also a packet based, connectionless, best-effort service. It is up to the application to
split data into packets, and provide any necessary error checking that is required.
Because of this, UDP allows the fastest and most simple way of transmitting data to the
receiver. There is no interference in the stream of data that can be possibly avoided. This
provides the way for an application to get as close to meeting real-time constraints as possible.
UDP however provides no congestion control systems. A congested link that is only running TCP
will be approximately fair to all users. When UDP data is introduced into this link, there is no
requirement for the UDP data rates to back off, forcing the remaining TCP connections to back
off even further. This can be though of as UDP data not being a ``good citizen''. The aim of this
project is to characterise the quantity of this drop off in TCP performance.
TCP vs. UDP
TCP UDP
· C o n n e c t i o n - O r i e n t e d · C o n n e c t i o n l e s s
· Reliability in delivery of messages · No attempt to fragment messages
· Splitting messages into datagrams · No reassembly and synchronization
· Keep track of order (or sequence) · In case of error, message is retransmitted
· Use checksums for detecting errors · No acknowledgment
o Remote procedures are not idempotent o Remote procedures are idempotent

162
Tel. #: (034) 312-6189 / (034) 729-4327
o Reliability is a must o Server and client messages fit completely
o Messages exceed UDP packet size within a packet
o The server handles multiple clients (UDP is
stateless)
Server Process
socket()
|
bind()
| TCP Server Process UDP
listen socket() |
| Client Process | Client Process
accept() socket() bind() |
| | | socket()
Get a blocked
<-1-> connect() recvfrom() |
client
| | | bind()
read() <-2-- write() Get a blocked client |
<--
| | | sendto()
-
process request | process request |
| | | |
---
write --3-> read() sendto() recvfrom()
>
163
Tel. #: (034) 312-6189 / (034) 729-4327
LESSON XI:
Standards
Voice over Internet Protocol (VoIP) networks combine the best of voice and data
communications networking technologies. But that combination also creates some challenges, as
the industry attempts to meld the best of circuit switching (from the voice side) and packet
switching (from the data side) into single technology.
Perhaps the biggest challenge for network managers comes in the area of multivendor
interoperability—the concept that allows hardware and software from different vendors to be
integrated into a cohesive system. But since vendors typically approach each other from a
competitive, rather than collaborative point of view, some neutral parties are required to referee
these interactions. Enter the standards bodies, internationally recognized groups whose purpose
is to define and document implementation rules, called standards. Networking standards are
typically developed by a committee, which is made up of interested parties, including inventors,
developers, and vendors, that have an interest in a specific technology. Most committees are
international in scope, and meet in person on a rather infrequent basis—from every few months
to every few years—to hash out major issues, but rely heavily on online collaboration for most of
their research.
Two key groups produce standards that influence VoIP technologies. The first is the International
Telecommunications Union, or ITU, which is headquartered in Geneva, Switzerland. The ITU's
work dates back to the 1860s when agreements were developed to support connections between
individual country's telegraph facilities.
As new technologies—radio, television, satellite, digital telephony, and now VoIP—have

emerged, the ITU has expanded and grown. At the present time, the ITU's work is divided into
three sectors: the Radiocommunication Sector (called ITU-R), which manages the available
wireless spectrum; the Telecommunication Standardization Sector (ITU-T), which develops
internationally-agreed upon networking standards; plus the Telecommunications Development
Sector (ITU-D), which endeavors to make modern telecommunications services available to
people in developing countries. ITU-T efforts have produced many international networking
standards, including Integrated Services Digital Network (ISDN) and Asynchronous Transfer
Mode (ATM), with a focus on wide area networking technologies (harkening back to their early
days in international telegraph interconnections.). ITU-T standards are designated by a letter,
which identifies a specific area of technology, followed by a series of numbers which identify the
particular standard. For example, standards beginning with the letter H deal with audiovisual
and multimedia systems, including VoIP. One of the often-quoted VoIP standards in this area is
H.323, titled Packet-based Multimedia Communications Systems. ITU-T standards are available
online from the ITU-T.
The other key player in the VoIP standards world is the worldwide Internet Society. The Internet
Society has served as the global clearinghouse for Internet-related technologies since 1992, and
as such is substantially younger than the ITU. This age difference causes a difference in focus as
164
Tel. #: (034) 312-6189 / (034) 729-4327
well—where the ITU has a rich history in circuit switched communications, such as voice, the
more youthful ISOC concentrates more on packet switching and data transmission.
Like the ITU, however, the ISOC parcels its work into smaller groups, including the Internet
Architecture Board (IAB), the Internet Research Task Force (IRTF), the Internet Engineering
Steering Group, and the Internet Engineering Task Force (IETF). The IETF is responsible for
developing and publishing Internet Standards, which are called Request for Comments, or RFC
documents. RFCs begin as draft documents from a specific Working Group, and after extensive
review and approvals are assigned a number, and then made available online by the RFC Editor.
Example RFCs would include the Internet Protocol (IP), RFC 791; Transmission Control Protocol
(TCP), RFC 793, the Hypertext Transmission Protocol (HTTP), RFC 2616, and the Session
Initiation Protocol (SIP), RFC 3261.
Other organizations may also influence VoIP standards, but with a more regional or
technology-specific focus. These include: the American National Standards Institute (ANSI); the
European Telecommunications Standards Institute (ETSI); the World Wide Web Consortium
(W3C); and the International Multimedia Teleconferencing Consortium (IMTC).
What is H.323?
H.323 is an umbrella recommendation from the ITU Telecommunication Standardization Sector
(ITU-T), that defines the protocols to provide audio-visual communication sessions on any
packet network. It is currently implemented by various Internet real-time applications such as
NetMeeting and Ekiga (the latter using the OpenH323 implementation). It is a part of the H.32x
series of protocols which also address communications over Integrated Services Digital Network
(ISDN), Public switched telephone network (PSTN) or Signaling System 7 (SS7). H.323 is
commonly used in Voice over IP (VoIP, Internet Telephony, or IP Telephony) and Internet
Protocol (IP)-based videoconferencing. Its purpose is thus similar to that of the Session Initiation
Protocol (SIP).
H.323 was originally created to provide a mechanism for transporting multimedia applications
over LANs but it has rapidly evolved to address the growing needs of VoIP networks.
One strength of H.323 was the relatively early availability of a set of standards, not only defining
the basic call model, but in addition the supplementary services, needed to address business
communication expectations. H.323 was the first VoIP standard to adopt the Internet
Engineering Task Force (IETF) standard Real-time Transport Protocol (RTP) to transport audio
and video over IP networks.
H.323 is based on the ITU-T Recommendation Q.931 protocol and is suited for interworking
scenarios between IP and ISDN, respectively between IP and QSIG. A call model, similar to the
ISDN call model, eases the introduction of IP Telephony into existing networks of ISDN based
PBX systems. A smooth migration towards IP based Private Branch exchange (PBX) systems
becomes plannable.
165
Tel. #: (034) 312-6189 / (034) 729-4327
Within the context of H.323, an IP based PBX is, simply speaking, a H.323 Gatekeeper as well as
a provider of supplementary services.
Protocols
H.323 references many other ITU-T protocols like:
· H.225.0 protocol is used to describe call signaling, the media (audio and video), the
stream packetization, media stream synchronization and control message formats.
· H.245 control protocol for multimedia communication, describes the messages and
procedures used for opening and closing logical channels for audio, video and data,
capability exchange, control and indications.
· H.450 describes the Supplementary Services
· H.235 describes security in H.323
· H.239 describes dual stream use in videoconferencing, usually one for live video, the
other for presentation
· H.460.17-19 describes firewall traversal in H.323
· H.261 H.263 H.264 describes video encoding
Lesson XII:
Requirement required and its function
The role of the following terms:
H.323 Terminals:
H.323 Terminals are the endpoints on the LAN that provide real-time two way
communications. The H.323 standard states that all H.323 Terminals must support voice,
with video and data being optional. Hence the basic form of an H.323 Terminal is the IP
Phone; however most H.323 Terminals are Video Conferencing Systems. The H.323
standard specifies what modes must be supported so that all these endpoints can work
together. H.323 Terminals must support H.245 protocol to control channel usage and
capabilities; Q.931 protocol for call setup and signalling; RAS
166
Tel. #: (034) 312-6189 / (034) 729-4327
(Registration/Admission/Status) protocol to communicate with the Gatekeeper and
RTP/RTCP protocol to sequence audio and video packets.
When initiating an H.323 Video Conference, we need some means of identifying the
User or H.323 Endpoint that we wish to conference with. The thought of having to
remember IP addresses is daunting enough; but the use of DHCP to dynamically allocate
the IP address of an endpoint means that this method is impractical. Hence the concept of
a Dial Plan and the use of an H.323 User Number registered to a Gatekeeper.
A Dial Plan is simply a method of allocating a unique number to an H.323 Endpoint.

This number is referred to as the H.323 User Number and when registered with a
Gatekeeper, we have a means of translating this User Number into an IP address.
The H.323 User Number is often loosely referred to as the E.164 Number.
Gatekeepers:
Although the H.323 standard describes the Gatekeeper, as an optional component, it is

in practice an essential tool for defining and controlling how voice and video
communications are managed over the IP network. Gatekeepers are responsible for
providing address translation between an endpoints current IP address and its various
H.323 aliases, call control and routing services to H.323 endpoints, system management
and security policies. These services provided by the Gatekeeper in communicating
between H.323 endpoints are defined in RAS.
Gatekeepers provide the intelligence for delivering new IP services and applications.
They allow network administrators to configure, monitor and manage the activities of
registered endpoints, set policies and control network resources such as bandwidth usage
within their H.323 zone. Registered endpoints can be H.323 Terminals, Gateways or
MCU's.
Only one Gatekeeper can manage a H.323 zone, but this zone could include several
Gateways and MCU's. Since a zone is defined and managed by only one Gatekeeper,
endpoints such as Gateways and MCU's that also have a built-in Gatekeeper must provide
a means for disabling this functionality. This ensures that multiple H.323 endpoints that
contain a Gatekeeper can all be configured into the same zone. The INVISION 12/24
series from RADVISION combines Gateway and MCU functionality in one box and has an
embedded Gatekeeper that can be disabled; this allows the zone to be controlled by a
more powerful Gatekeeper such as the Enhanced Communications Server within the
viaIP-400 or utilise the PBX like features of the Media Xchange Manager™.
With media networks becoming more and more complex, the ability for the administrator
to effectively manage and control their usage becomes crucial. To address these issues,
VCON have introduced Media XchangeManager™, MXM. From a remote console, the
administrator can now perform centralised management functions such as configure
endpoints, monitor the status and availability of endpoints, control and limit bandwidth
usage and more. MXM automatically generates Call Detail Reports, CDR; which can be
167
Tel. #: (034) 312-6189 / (034) 729-4327
used for network planning or billing purposes. With video telephony services such as Call
Forward, Call Transfer and Call Pickup, MXM provides the functions that make Video
Conferencing as simple as making a telephone call. Furthermore, MXM includes an H.323
Gatekeeper.
Interconnected Gatekeeper Zones:
As stated earlier, the Gatekeeper defines the zone and manages the registered endpoints
within. To call an endpoint within the same zone, we simply dial that endpoints H.323
User Number. But what happens when we want to call an endpoint that is located in
another zone? Well, we then also need to know the zone where that endpoint is
registered. Each Gatekeeper on the same network is identified by a unique number, its
Zone Number. To call an endpoint in a different zone, we prefix that endpoints H.323
User Number with its Zone Number and dial this extended number.
The telephone analogy to the Gatekeeper Zone Number is the STD code for the local
exchange. If we want to telephone a person locally, we just dial their local number, but if
we want to telephone somebody further afield, we need to prefix their local number with
their STD code.
Behind the scenes, all the Gatekeepers on the network must know how they are related to
eachother. The diagram below shows the two different relationships in which Gatekeepers
can be networked and interoperate together.
When Gatekeepers are arranged in a single tier 'Peer-to-Peer' manner with no particular
hierarchical structure, they are termed as being Neighbour Gatekeepers. This would
typically be on a corporate network within a multi-site company who has a Gatekeeper at
each site. Each Gatekeeper manages its own site (Zone), with inter-zone communications
routed directly between zones and controlled on an individual basis specifically defined by
the direct relationship between each Gatekeeper.
When the Gatekeepers are arranged in a multi-tier manner with a hierarchical structure,
they are termed as being Directory Gatekeepers (DGK). This would typically be within a
168
Tel. #: (034) 312-6189 / (034) 729-4327
large scale deployment such as the national schools network. Whilst each Gatekeeper still
manages its own zone, inter-zone communications are routed indirectly on a Parent-Child
basis between zones.
A Directory Gatekeeper only knows its Parent and Child Gatekeepers. If the Gatekeeper
does not know the Zone of the dialled number, it routes the call to its Parent DGK, which
then searches its database to see if the Zone known. If not known, this Parent routes the
call to its Parent and so on until it eventually reaches a Parent DGK that has a Child DGK
that matches the Zone. The call is then routed down through each Child DGK tier until it
reaches the specific endpoint.
Gateways:
H.320 and H.323 systems can interoperate with the use of a Gateway. Essentially, the
Gateway provides translation between circuit-switched networks ISDN and packet-based
networks LAN, enabling the endpoints to communicate. To do this, it must translate
between the H.225 to H.221 transmission formats and between the H.245 to H.242
communications control protocols. The Gateway also has to transcode between the
various audio and video codecs used between the LAN and ISDN devices.
Most Gateways have multiple BRI connections and can support several conferences
simultaneously. For example, a Quad BRI Gateway, such as the gw-B40 from
RADVISION can simultaneously support either four conferences at 128Kbps, two at
256Kbps or one at 384Kbps and one at 128Kbps. Furthermore, the gw-P20 card option
of the viaIP has two PRI interfaces and can support up to 60 concurrent voice calls.
Most Gateways work in conjunction with, or include a Gatekeeper functionality. A real

world H.323 implementation of a Gateway working in conjunction with a Gatekeeper is
in a Multimedia Call Centre were needs-based call routing and a variety of other
automatic call distribution features are used.
Dedicated Multipoint Control Units (MCUs):
To allow three or more participants into a conference, most H.323 systems usually require
a Multipoint Conference Server (MCS). This is also referred to as an H.323 Multipoint
Control Unit (H.323 MCU). This is not the same as an H.320 MCU; hence it is important
169
Tel. #: (034) 312-6189 / (034) 729-4327
to be clear about what you mean when using the term MCU; see section below on H.320
MCU.
The H.323 MCU's basic function is to maintain all the audio, video, data and control
streams between all the participants in the conference. Whilst most H.323 MCU's, such
as the mcu-15v or mcu-xx cards with the viaIP are hardware based, VCON have
introduced the VCON Conference Bridge™, VCB that provides a basic software MCU
capable of allowing Ad-Hoc Conferencing in both Continuous Presence or Voice-Activated
Switching modes.
The main components of an H.323 MCU are the multipoint controller MC and the optional
multipoint processor MP. The MC is the conference controller and handles H.245
negotiations between all terminals to determine common capabilities for audio and video
processing. The MC also controls conference resources such as multicasting. Most H.323
systems support IP multicast and use this to send just one audio and one video stream to
the other participants. The MC does not actually deal directly with any of the audio, video
and data streams. This is left to the MP, which does all the audio mixing, data distribution
and video switching/mixing of the bits. It also provides the conversion between different
codecs and bit rates. Both the MC and MP functions can exist in one unit or as part of
other H.323 components. Most H.323 MCU's work in conjunction with, or include a
Gatekeeper functionality.
H.320 conferences are essentially a point-to-point connection and need to use an H.320
MCU to link and manage all the ISDN lines in order to hold a conference with three or
more participants.
The H.320 MCU's basic function is to maintain the communications between all the
participants in the conference. H.320 MCU's are hardware based as they need to connect
170
Tel. #: (034) 312-6189 / (034) 729-4327
to all of the ISDN lines from each participant. For example, to manage a conference
between four H.320 systems, each at 384Kbps (3xBRI), the H.320 MCU needs to connect
the twelve BRI's. This is typically done as 24 x 64Kbps channels within a Primary Rate
Interface, (PRI).
Note that an H.320 MCU is not the same as an H.323 MCU!
Endpoint with Embedded MCU:
An alternative to using a dedicated MCU for small conferences involving 3 or 4 participants

is to equip one of the endpoints with an embedded multipoint capability. The Polycom
VSX 7000s has an embedded multipoint options that supports itself and up to 3 other
sites in a Voice-Activated or Continuous Presence session. Furthermore, the VSX 7000s
has both BRI or PRI ISDN options that when used in conjunction with the multipoint
capability, allows mixed-mode operation between both ISDN and IP networks. In a
simplistic manner, it also acts like a Gateway, bridging between the other 2 or 3 ISDN and
IP endpoints.
Using a Gateway and Gatekeeper:
The opportunities offered by using a Gateway in conjunction with a Gatekeeper are

much more than just translation between a LAN and ISDN device. Most vendors
Gateways have a built-in Gatekeeper as well as multiple BRI connections that allow
several conferences to be held simultaneously.
By installing a Quad BRI Gateway with a Gatekeeper or registered with MXM, a

company could provide access to the outside world via eight ISDN lines paired as 4 BRI's.
On this side of the Gateway, these BRI's can be grouped in various permutations to
support calls at 64Kbps, 128Kbps, 256Kbps or 384Kbps. On the LAN side of the
Gateway, access could be given to numerous H.323 Terminals located on the corporate
network.
Whilst the Gateway provides the physical links and translation between control and data
formats, it is the Gatekeeper that establishes and manages the conference. The
Gatekeeper manages the entire H.323 zone and all its registered endpoints.
171
Tel. #: (034) 312-6189 / (034) 729-4327
Furthermore, if the Gateway was registered with MXM, then the users could take
advantage of additional services such as Simplified Outbound Dialling, whereby they
simply dial 9+ISDN Number.
Using a Gateway, Gatekeeper and H.323 MCU:
The opportunities offered by using a Gateway in conjunction with a Gatekeeper and

MCU are much more than just translation between a LAN and ISDN device. With the MCU
adding the ability to hold a conference between three more participants, when used in
conjunction with a Gateway, participants can be located on either a H.323 or H.320
endpoint. Furthermore, by using the Continuous Presence feature, participants can see
more than just who is speaking. The actual number of participants viewable in a
Continuous Presence conference is a function of the MCU used and maybe subject to
network constraints. The Continuous Presence feature within the viaIP enables the
simultaneous display of up to 16 conference participants in a variety of layouts.
When an H.323 endpoint registers with the Gatekeeper, it registers its IP address; its
H.323 User Number and maybe an H.323 Alias as means of identification. As the
Gateway provides services to H.323 Terminals in terms of outbound calls to H.320
Terminals or Telephones, when it registers with the Gatekeeper, it registers the services
it supports. In the above example, the Gatekeeper has to manage 3 different calling
routes; LAN to LAN; LAN to WAN and WAN to LAN.
Calling Procedures:
In the LAN to LAN situation, the Gatekeeper can locate the correct H.323 Terminal by
translating its H.323 User Number or Alias into its IP address without any Gateway
interaction.
In the LAN to WAN situation, when the Gatekeeper receives a service request, it
recognises this as belonging to the Gateway and returns the IP address of the Gateway
to the calling H.323 Terminal. The H.323 Terminal can now call the Gateway with the
service code and the ISDN numbers for the H.320 Terminal. The Gateway determines
the required service from the service code and calls the ISDN numbers of the H.320
172
Tel. #: (034) 312-6189 / (034) 729-4327
Terminal. When connected, the Gateway calls the H.323 Terminal and completes the
connection.
In the WAN to LAN situation, when the Gateway receives a service request, it has to
forward it to the correct H.323 Terminal. This is achieved by using one of the Gateways
incoming call routing methods; these typically being Multiple Subscriber Numbering,
MSN; Terminal Control Strings, TCS-4; Interactive Voice Response, IVR or Default
Extension.
With MSN, a group of phone numbers are assigned to the ISDN line. When each H.323
Terminal registers with the Gatekeeper, it is assigned to one of these phone numbers.
Hence, when the H.320 Terminal calls the MSN number, it is routed through the
Gateway to the H.323 Terminal after the Gatekeeper has translated the MSN number
into the corresponding IP address.
TCS-4 is a special routing method for H.320 Terminals to call H.323 Terminals via a
Gateway when MSN is not available. With TCS-4, the H.323 Terminal is identified
using its H.323 User Number registered with the Gatekeeper. When the H.320
Terminal calls the Gateways ISDN number followed by a deliminator and the H.323
User Number, it is routed through the Gateway to the H.323 Terminal after the
Gatekeeper has translated the H.323 User Number into the corresponding IP address.
IVR is a commonly used automated call answering system that presents a voice menu
and allowing users to respond using Dual Tone Multi-Frequency DTMF signals entered via
a keypad/keyboard. When an incoming call from an H.320 Terminal activates the IVR
system, the Gateway establishes a connection and playbacks the IVR audio recording
that prompts the user to identify the required H.323 Terminal by its H.323 User
Number. The H.320 Terminal user then enters the H.323 User Number using DTMF
signals. The IVR system interprets the DTMF signals and forwards the H.323 User
Number to the Gatekeeper that translates it into the corresponding IP address.
Any H.323 Terminal can be defined as the Default Extension, which basically allows
any call not routed by any other method to be forwarded to this endpoint.
Gatekeeper
A gatekeeper is an optional component in an H.323 network that is responsible for call
admission, address resolution, routing call signaling, etc. The gatekeeper is sometimes referred
to as a soft switch. However, the role of the gatekeeper may not really be that of a soft switch,
but simply an address resolution function. The role and scope of the gatekeeper in any network
is really up to the service provider or enterprise deploying the H.323 network.
If a gatekeeper is present, it will most certainly use the RAS protocol defined in ITU-T
Recommendation H.225.0 to communicate with endpoints. RAS is used to provide a means for
the device to register with the gatekeeper, request permission to accept or place calls, and to
obtain address information for called entities.
173
Tel. #: (034) 312-6189 / (034) 729-4327
Gatekeepers may also route the call signaling, though it is not required. If a gatekeeper routes
the call signaling, it can more fully control the call from start to finish and provide mid-call
services, such as call transfer, call forward on busy or no-answer, ring multiple lines
simultaneously, etc.
Gatekeepers are comparable in function to SIP proxy servers.
M G C P
RFC: 2705 ftp://ftp.isi.edu/in-notes/rfc2705.txt

M G C P
Media Gateway Control Protocol (MGCP) is used for controlling telephony gateways from
external call control elements called media gateway controllers or call agents. A telephony
gateway is a network element that provides conversion between the audio signals carried on
telephone circuits and data packets carried over the Internet or over other packet networks.
MGCP assumes a call control architecture where the call control intelligence is outside the
gateways and handled by external call control elements. The MGCP assumes that these call
control elements, or Call Agents, will synchronize with each other to send coherent commands to
the gateways under their control. MGCP is, in essence, a master/slave protocol, where the
gateways are expected to execute commands sent by the Call Agents.
The MGCP implements the media gateway control interface as a set of transactions. The
transactions are composed of a command and a mandatory response. There are eight types of
c o m m a n d s :
MGCP Commands
MGC --> MG CreateConnection: Creates a connection between two
endpoints; uses SDP to define the receive capabilities
of the paricipating endpoints.
MGC --> MG ModifyConnection: Modifies the properties of a
connection; has nearly the same parameters as the
CreateConnection command.
MGC <--> MG DeleteConnection: Terminates a connection and
collects statistics on the execution of the connection.
MGC --> MG NotificationRequest: Requests the media gateway to
send notifications on the occurrence of specified
events in an endpoint.
MGC <-- MG Notify: Informs the media gateway controller when
observed events occur.
MGC --> MG AuditEndpoint: Determines the status of an endpoint.
MGC --> MG AuditConnection: Retrieves the parameters related to
a connection.
MGC <-- MG RestartInProgress: Signals that an endpoint or group
of endpoints is take in or out of service.
174
Tel. #: (034) 312-6189 / (034) 729-4327
MGC=Media Gateway Controller
MG=Media Gateway
· CreateConnection.
· ModifyConnection.
· DeleteConnection.
· NotificationRequest.
· Notify.
· AuditEndpoint.
· AuditConnection.
· RestartInProgress.
The first four commands are sent by the Call Agent to a gateway. The Notify command is sent
by the gateway to the Call Agent. The gateway may also send a Delete Connection. The Call
Agent may send either of the Audit commands to the gateway. The Gateway may send a
RestartInProgress command to the Call Agent.
All commands are composed of a command header, optionally followed by a session description.
All responses are composed of a response header, optionally followed by a session description.
Headers and session descriptions are encoded as a set of text lines, separated by a carriage
return and line feed character (or, optionally, a single line-feed character). The headers are
separated from the session description by an empty line.
MGCP uses a transaction identifier to correlate commands and responses. Transaction identifiers
have values between 1 and 999999999. An MGCP entity cannot reuse a transaction identifier
sooner than 3 minutes after completion of the previous command in which the identifier was
used.
The command header is composed of:
· A command line, identifying the requested action or verb, the transaction identifier, the
endpoint towards which the action is requested, and the MGCP protocol version,
· A set of parameter lines, composed of a parameter name followed by a parameter value.
The command line is composed of:
· Name of the requested verb.
· Transaction identifier correlates commands and responses. Values may be between 1 and
999999999. An MGCP entity cannot reuse a transaction identifier sooner than 3 minutes
after completion of the previous command in which the identifier was used.
175
Tel. #: (034) 312-6189 / (034) 729-4327
· Name of the endpoint that should execute the command (in notifications, the name of the
endpoint that is issuing the notification).
· Protocol version.
These four items are encoded as strings of printable ASCII characters, separated by white
spaces, i.e., the ASCII space (0x20) or tabulation (0x09) characters. It is recommended to use
exactly one ASCII
space
separator.
MCU
A Multipoint Control Unit (MCU) is a device commonly used to bridge videoconferencing
connections.
The Multipoint Control Unit is an endpoint on the LAN which provides the capability for 3 or more
terminals and gateways to participate in a multipoint conference. The MCU consists of a
mandatory Multipoint Controller (MC) and optional Multipoint Processors (MPs).
176
Tel. #: (034) 312-6189 / (034) 729-4327
Lesson XIII:
Protocols used and their functions
H.323
H.323 is an International Telecommunications Union (ITU) standard that provides specification
for computers, equipment, and services for multimedia communication over networks that do
not provide a guaranteed quality of service. H.323 computers and equipment can carry real-time
video, audio, and data, or any combination of these elements. This standard is based on the
Internet Engineering Task Force (IETF) Real-Time Protocol (RTP) and Real-Time Control Protocol
(RTCP), with additional protocols for call signaling, and data and audiovisual communications.
Users can connect with other people over the Internet and use varying products that support
H.323, just as people using different makes and models of telephones can communicate over
Public Switched Telephone Network (PSTN) lines. H.323 defines how audio and video information
is formatted and packaged for transmission over the network. Standard audio and video codecs
encode and decode input/output from audio and video sources for communication between
nodes. A codec (coder/decoder) converts audio or video signals between analog and digital
forms.
Also, H.323 specifies T.120 services for data communications and conferencing within and next
to an H.323 session. Most importantly, this T.120 support means that data handling can occur
either in conjunction with H.323 audio and video, or separately.
Microsoft and more than 120 other leading companies have announced their intent to support
and implement H.323 in their products and services. This broad support establishes H.323 as
the standard for audio and video conferencing over the Internet.
Benefits
H.323 products and services offer the following benefits to users:
· Products and services developed by multiple manufacturers under the H.323 standard can
interoperate without platform limitations. H.323 conferencing clients, bridges, servers, and
gateways support this interoperability.
177
Tel. #: (034) 312-6189 / (034) 729-4327
· H.323 provides multiple audio and video codecs that format data according to the
requirements of various networks, using different bit rates, delays, and quality options. Users
can choose the codecs that best support their computer and network selections.
· The addition of T.120 data conferencing support to the H.323 specification means that
products developed under H.323 can offer a full range of multimedia functions, with both
data and audiovisual conferencing support.
RTP
The Real-Time Transport Protocol (RTP) is an Internet protocol standard that specifies a way for
programs to manage the real time transmission of multimedia data over either unicast or
multicast network services. Originally speficified in Internet Engineering Task Force (IETF)
Request for Comments (RFC) 1889, RTP was designed by the EITF’s Audio-Video Transport
Working Group to support video conferences with multiple, geographically dispersed
participants. RTP is commonly used in Internet telephony applications. RTP does not in itself
guarantee real-time delivery of multimedia data (since this is dependent on network
characteristics); it does, however, provide the wherewithal to manage the data as it arrives to
best effect.
RTP combines its data transport with a control protocol (RTCP), which makes possible to monitor
data delivery for large multicast networks. Monitoring allows the receiver to detect if there is any
packet loss and to compensate for any delay jitter. Both protocols work independently of the
underlying Transport Layer and Network Layer protocols. Information in the RTP header tells the
receiver how to reconstruct the data and describes how the code bit streams are packetized. As
a rule, RTP runs on top of the User Datagram Protocol (UDP), although it can use other
transport protocols. Both the Session Initiation Protocol (SIP) and H.323 use RTP.
RTPC components include: quality of service (Qos) feedback, which includes the numbers of lost
packets, round packets, round-trip time, and jitter, so that the sources can adjust their data
rates accordingly; session control, which uses the RTCP BYE packet to allow participants to
indicate that they are leaving a session; identification, which includes a participants name, email
address, and telephone number for the information of other participants; and intermedia
synchronization, which enables the synchronization of separately transmitted audio and video
streams.
Compressed RTP (CRTP), specified in RFC 2509, was

developed to decrease the size of the IP, UDNP, and RTP
headers. However, it was designed to work with reliable and
fast point-to-point links. In less than optimal circumstances,
where there may be long delays, packets loss, and
out-of-sequence packets, CRTP doesn’t function well for Voice
Over IP (VoIP) applications. Another adaptation. Enhanced
CRPT (ECRPT), was defined in a subsequent Internet Draft
178
Tel. #: (034) 312-6189 / (034) 729-4327
document to overcome that problem.
RSVP
A host uses RSVP to request a specific Quality of Service (QoS) from the network, on behalf of
an application data stream. RSVP carries the request through the network, visiting each node
the network uses to carry the stream. At each node, RSVP attempts to make a resource
reservation for the stream.
To make a resource reservation at a node, the RSVP daemon communicates with two local
decision modules, admission control and policy control. Admission control determines whether
the node has sufficient available resources to supply the requested QoS. Policy control
determines whether the user has administrative permission to make the reservation. If either
check fails, the RSVP program returns an error notification to the application process that
originated the request. If both checks succeed, the RSVP daemon sets parameters in a packet
classifier and packet scheduler to obtain the desired QoS. The packet classifier determines the
QoS class for each packet and the scheduler orders packet transmission to achieve the promised
QoS for each stream.
A primary feature of RSVP is its scalability. RSVP

scales to very large multicast groups because it
uses receiver-oriented reservation requests that
merge as they progress up the multicast tree.
The reservation for a single receiver does not
need to travel to the source of a multicast tree;
rather it travels only until it reaches a reserved
branch of the tree. While the RSVP protocol is
designed specifically for multicast applications, it
may also make unicast reservations.
RSVP is also designed to utilize the robustness

of current Internet routing algorithms. RSVP
does not perform its own routing; instead it uses underlying routing protocols to determine
where it should carry reservation requests. As routing changes paths to adapt to topology
changes, RSVP adapts its reservation to the new paths wherever reservations are in place. This
modularity does not rule out RSVP from using other routing services. Current research within the
RSVP project is focusing on designing RSVP to use routing services that provide alternate paths
and fixed paths.
RSVP runs over IP, both IPv4 and IPv6. Among RSVP's other features, it provides opaque
transport of traffic control and policy control messages, and provides transparent operation
through non-supporting regions.
179
Tel. #: (034) 312-6189 / (034) 729-4327
SIP
Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for
creating, modifying, and terminating sessions with one or more participants. These sessions
include Internet telephone calls, multimedia distribution, and multimedia conferences." (cit. RFC
3261). It was originally designed by Henning Schulzrinne (Columbia University) and Mark
Handley (UCL) starting in 1996. The latest version of the specification is RFC 3261 from the IETF
SIP Working Group. In November 2000, SIP was accepted as a 3GPP signaling protocol and
permanent element of the IMS architecture. It is widely used as a signaling protocol for Voice
over IP, along with H.323 and others.
SIP has the following features:
· Lightweight, in that SIP has only six methods, reducing complexity.
· Transport-independent, because SIP can be used with UDP, TCP, ATM & so on.
· Text-based, allowing for humans to read SIP messages.
Protocol design
SIP clients use TCP or UDP typically using port 5060 to connect to SIP servers and other SIP
endpoints. SIP is primarily used in setting up and tearing down voice or video calls. However, it
can be used in any application where session initiation is a requirement. These include Event
Subscription and Notification, Terminal mobility and so on. There are a large number of
SIP-related RFCs that define behavior for such applications. All voice/video communications are
done over separate session protocols, typically RTP.
A motivating goal for SIP was to provide a signaling and call setup protocol for IP-based
communications that can support a superset of the call processing functions and features
present in the public switched telephone network (PSTN). SIP by itself does not define these
features; rather, its focus is call-setup and signaling. However, it has been designed to enable
the building of such features in network elements known as Proxy Servers and User Agents.
These are features that permit familiar telephone-like operations: dialing a number, causing a
phone to ring, hearing ring back tones or a busy signal. Implementation and terminology are
different in the SIP world but to the end-user, the behavior is similar.
SIP-enabled telephony networks can also implement many of the more advanced call processing
features present in Signaling System 7 (SS7), though the two protocols themselves are very
different. SS7 is a highly centralized protocol, characterized by highly complex central network
architecture and dumb endpoints (traditional telephone handsets). SIP is a peer-to-peer
protocol. As such it requires only a very simple (and thus highly scalable) core network with
intelligence distributed to the network edge, embedded in endpoints (terminating devices built in
either hardware or software). SIP features are implemented in the communicating endpoints
(i.e. at the edge of the network) as opposed to traditional SS7 features, which are implemented
in the network.
180
Tel. #: (034) 312-6189 / (034) 729-4327
Although many other VoIP signaling protocols exist, SIP is characterized by its proponents as
having roots in the IP community rather than the telecom industry. SIP has been standardized
and governed primarily by the IETF while the H.323 VoIP protocol has been traditionally more
associated with the ITU. However, the two organizations have endorsed both protocols in some
fashion.
SIP works in concert with several other protocols and is only involved in the signaling portion of
a communication session. SIP acts as a carrier for the Session Description Protocol (SDP), which
describes the media content of the session, e.g. what IP ports to use, the codec being used etc.
In typical use, SIP "sessions" are simply packet streams of the Real-time Transport Protocol
(RTP). RTP is the carrier for the actual voice or video content itself.
The first proposed standard version (SIP 2.0) was defined in RFC 2543. The protocol was further
clarified in RFC 3261, although many implementations are still using interim draft versions. Note
that the version number remains 2.0.
SIP is similar to HTTP and shares some of its design principles: It is human readable and
request-response structured. SIP shares many HTTP status codes, such as the familiar '404 not
found'. SIP proponents also claim it to be simpler than H.323. However, some would counter
that while SIP originally had a goal of simplicity, in its current state it has become as complex as
H.323. Others would argue that SIP is a stateless protocol, hence making it possible to easily
implement failover and other features that are difficult in stateful protocols such as H.323. SIP
and H.323 are not limited to voice communication but can mediate any kind of communication
session from voice to video or future, unrealized applications.
SIP network elements

Hardware endpoints — devices with the look, feel, and shape of a traditional telephone, but that
use SIP and RTP for communication — are commercially available from several vendors. Some of
these can use Electronic Numbering (ENUM) or DUNDi to translate existing phone numbers to
SIP addresses using DNS, so calls to other SIP users can bypass the telephone network, even
though your service provider might normally act as a gateway to the PSTN network for
traditional phone numbers (and charge you for it.)
Today, software SIP endpoints are common. Microsoft Windows Messenger uses SIP. iChat AV,
Apple Computer's AIM-compatible client, has supported audio and video chat through SIP, first
in the 2003 public beta and now in the production version. On Linux, Ekiga supports SIP.
SIP also requires proxy and registrar network elements to work as a practical service. Although
two SIP endpoints can communicate without any intervening SIP infrastructure, which is why the
protocol is described as peer-to-peer, this approach is impractical for a public service. There are
various soft switch implementations (by 3Com, Nortel, Sonus and many more) that can act as
proxy and registrar. Other companies, led by Ubiquity Software (acquired by Avaya in February
2007[1]) and Dynamic soft (acquired by Cisco in 2004[2]) have implemented products based on
the proposed standards, building on the Java JAIN specification. These follow the SIP Servlet
API, JSR 116. These products allow deploying applications of arbitrary complexity onto a
181
Tel. #: (034) 312-6189 / (034) 729-4327
telephony network. In particular, they play the role of Application Servers in the IMS
architecture.
From the RFCs:

"SIP makes use of elements called proxy servers to help route requests to the user's
current location, authenticate and authorize users for services, implement provider
call-routing policies, and provide features to users."
"SIP also provides a registration function that allows users to upload their current
locations for use by proxy servers. "
"Since registrations play an important role in SIP, a User Agent Server that handles a
REGISTER is given the special name registrar."
"It is an important concept that the distinction between types of SIP servers is logical, not
physical."
182
Tel. #: (034) 312-6189 / (034) 729-4327
Instant messaging (IM) and presence
A standard instant messaging protocol based on SIP, called SIMPLE, has been proposed and is
under development. SIMPLE can also carry presence information, conveying a person's
willingness and ability to engage in communications. Presence information is most recognizable
today as buddy status in IM clients such as Yahoo! Messenger, AIM, Skype, or the open standard
Jabber.
Some efforts have been made to integrate SIP-based VoIP with the XMPP specification used by
Jabber. Most notably Google Talk, which extends XMPP to support voice, plans to integrate SIP.
Google's XMPP extension is called Jingle and, like SIP, it acts as a Session Description Protocol
carrier.
The free OpenWengo softphone and the proprietary Gizmo Project have implemented SIP in their
clients and services. As both software use SIP they can accept calls from each other.
SIP itself defines a method of passing instant messages between endpoints, similar to SMS
messages. This is not generally supported by commercial operators, but UK-based VoIP provider
AQL supports this method of communication, including the sending of such messages to ordinary
GSM mobile telephones.
183
Tel. #: (034) 312-6189 / (034) 729-4327
Lesson XIV:
How VoIP Impacts IP Data
QoS (Quality of Service)
Nowadays, fundamentally different networks are merging into one IP network. For example,
telephone and video (CCTV) networks are migrating towards IP. In these networks, you will need
to control the way to share network resources to fulfill the requirements of each service. One
solution is to let the network routers and switches behave differently on different kinds of
services (voice, data, video) as the traffic passes through the network. This technique is called
Differentiated Services (DiffServ). By using QoS, different network applications can co-exist on
the same network, without consuming each other’s bandwidth.
Definition
The term Quality of Service refers to a number of technologies to guarantee a certain quality
to different services on the network. Quality can be, for instance, a maintained level of
bandwidth, low latency, no packet losses, etc. The main benefits of a QoS-aware network can be
summarized as:
· The ability to prioritize traffic and thus allow critical flows to be served before flows with
lesser priority.
· Greater reliability in the network, thanks to the control of the amount of bandwidth an
application may use, and thus control over bandwidth races between applications.
QoS and network video: Requirements
To use QoS in a network with network video products, the following requirements must be met:
· All network switches and routers must include support for QoS. This is important to
achieve end-to-end QoS functionality.
· The network video products used must be QoS-enabled.
QoS scenarios
184
Tel. #: (034) 312-6189 / (034) 729-4327
Ordinary (non-QoS aware) network
In this example, PC1 is watching two video streams from cameras Cam1 and Cam2, with each
camera streaming at 2.5 Mbps. Suddenly, PC2 starts a file transfer from PC3. In this scenario,
the file transfer will try to use the full 10 Mbps capacity between the routers R1 and R 2, whilst
the video streams will try to maintain their total of 5 Mbps. The amount of bandwidth given to
the surveillance system can no longer be guaranteed and the video frame rate will probably be
reduced. At worst, the FTP traffic will consume all the available bandwidth.
QoS aware network
The router R1 has been configured to devote up to 5 Mbps of the available 10 Mbps for
streaming video. FTP traffic is allowed to use 2 Mbps, and HTTP and all other traffic can use a
maximum of 3 Mbps. Using this division, video streams will always have the necessary
bandwidth available. File transfers are considered less important and get less bandwidth, but
there will still be bandwidth available for web browsing and other traffic. Note that these
maximums only apply when there is congestion on the network. If there is unused bandwidth
available, this can be used by any type of traffic.
About Pan Tilt Zoom (PTZ) traffic
PTZ traffic is often regarded as critical and requires low latency to guarantee fast responses to
movement requests. This is a typical case in which QoS can be used to provide the necessary
guarantees. The QoS control of PTZ traffic in Axis network video products is handled by the
ActiveX viewer AXIS Media Control (AMC), which is automatically installed the first time the Axis
product is accessed from Microsoft Internet Explorer.
185
Tel. #: (034) 312-6189 / (034) 729-4327
Understanding Delay in Packet Voice Networks
Introduction
When you design networks that transport voice over packet, frame, or cell infrastructures, it is
important to understand and account for the delay components in the network. If you account
correctly for all potential delays, it ensures that overall network performance is acceptable.
Overall voice quality is a function of many factors that include the compression algorithm, errors
and frame loss, echo cancellation, and delay. This paper explains the sources of delay when you
use Cisco router/gateways over packet networks. Though the examples are geared to Frame
Relay, the concepts are applicable to Voice over IP (VoIP) and Voice over ATM (VoATM) networks
as well.
Basic Voice Flow

The flow of a compressed voice circuit is shown in this diagram. The analog signal from the
telephone is digitized into pulse code modulation (PCM) signals by the voice coder-decoder
(codec). The PCM samples are then passed to the compression algorithm which compresses the
voice into a packet format for transmission across the WAN. On the far side of the cloud the
exact same functions are performed in reverse order. The entire flow is shown in Figure 2-1.
Figure 2-1 End-to-End Voice Flow
Based on how the network is configured, the router/gateway can perform both the codec and
compression functions or only one of them. For example, if an analog voice system is used, then
the router/gateway performs the CODEC function and the compression function as shown in
Figure 2-2.
Figure 2-2 Codec Function in Router/Gateway
186
Tel. #: (034) 312-6189 / (034) 729-4327
If a digital PBX is used, the PBX performs the codec function and the Router processes the PCM
samples passed to it by the PBX. An example is shown in Figure 2-3.
Figure 2-3 Codec Function in PBX
How Voice Compression Works

The high complexity compression algorithms used in Cisco router/gateways analyze a block of
PCM samples delivered by the Voice codec. These blocks vary in length based on the coder. For
example, the basic block size used by a G.729 algorithm is 10 ms whereas the basic block size
used by the G.723.1 algorithms is 30ms. An example of how a G.729 compression system works
is shown in Figure 3-1.
Figure 3-1 Voice Compression
187
Tel. #: (034) 312-6189 / (034) 729-4327
The analog voice stream is digitized into PCM samples and delivered to the compression
algorithm in 10 ms increments. The look ahead is discussed in Algorithmic Delay.
Standards for Delay Limits

The International Telecommunication Union (ITU) considers network delay for voice applications
in Recommendation G.114. This recommendation defines three bands of one-way delay as
shown in Table 4.1.
Table 4.1 Delay Specifications
Range in Milliseconds Description
Acceptable for most user

0-150
applications.
Acceptable provided that

administrators are aware of
the transmission time and
150-400
the impact it has on the
transmission quality of user
applications.
Above 400 Unacceptable for general

network planning purposes.
188
Tel. #: (034) 312-6189 / (034) 729-4327
However, it is recognized
that in some exceptional
cases this limit is exceeded.
Note: These recommendations are for connections with echo adequately controlled. This implies
that echo cancellers are used. Echo cancellers are required when one-way delay exceeds 25 ms
(G.131).
These recommendations are oriented for national telecom administrations. Therefore, these are
more stringent than when normally applied in private voice networks. When the location and
business needs of end users are well-known to the network designer, more delay can prove
acceptable. For private networks 200 ms of delay is a reasonable goal and 250 ms a limit. All
networks need to be engineered such that the maximum expected voice connection delay is
known and minimized.
Sources of Delay
There are two distinct types of delay called fixed and variable.
· Fixed delay components add directly to the overall delay on the connection.
· Variable delays arise from queuing delays in the egress trunk buffers on the serial port
connected to the WAN. These buffers create variable delays, called jitter, across the
network. Variable delays are handled through the de-jitter buffer at the receiving
router/gateway. The de-jitter buffer is described in the De-jitter Delay (Δn) section of this
document.
Figure 5-1 identifies all the fixed and variable delay sources in the network. Each source is
described in detail in this document.
Figure 5-1: Delay Sources
189
Tel. #: (034) 312-6189 / (034) 729-4327
Coder (Processing) Delay
Coder delay is the time taken by the digital signal processor (DSP) to compress a block of PCM
samples. This is also called processing delay (χn). This delay varies with the voice coder used
and processor speed. For example, algebraic code excited linear prediction (ACELP) algorithms
analyze a 10 ms block of PCM samples, and then compress them.
The compression time for a Conjugate Structure Algebraic Code Excited Linear Prediction
(CS-ACELP) process ranges from 2.5 ms to 10 ms based on the loading of the DSP processor. If
the DSP is fully loaded with four voice channels, the Coder delay is 10 ms. If the DSP is loaded
with only one voice channel the Coder delay is 2.5 ms. For design purposes use the worst case
time of 10 ms.
Decompression time is roughly ten percent of the compression time for each block. However, the
decompression time is proportional to the number of samples per frame because of the presence
of multiple samples. Consequently, the worst case decompression time for a frame with three
samples is 3 x 1 ms or 3 ms. Usually, two or three blocks of compressed G.729 output are put in
one frame while one sample of compressed G.723.1 output is sent in a single frame.
Best and worst case coder delays are shown in Table 5.1.
Table 5 .1 Best and Worst Case Processing Delay
B e s t W o r s t
Required
C a s e C a s e
Coder Rate S a m p l e
C o d e r C o d e r
Block
Delay Delay
A D P C M , 3 2
10 ms 2.5 ms 10 ms
G.726 Kbps
C S-ACELP , 8 . 0
10 ms 2.5 ms 10 ms
G.729A Kbps
MP-MLQ, 6 . 3
30 ms 5 ms 20 ms
G.723.1 Kbps
MP-ACEL P, 5 . 3
30 ms 5 ms 20 ms
G.723.1 Kbps
190
Tel. #: (034) 312-6189 / (034) 729-4327
Algorithmic Delay
The compression algorithm relies on known voice characteristics to correctly process sample
block N. The algorithm must have some knowledge of what is in block N+1 in order to accurately
reproduce sample block N. This look ahead, which is really an additional delay, is called
algorithmic delay. This effectively increases the length of the compression block.
This happens repeatedly, such that block N+1 looks into block N+2, and so forth and so on. The
net effect is a 5 ms addition to the overall delay on the link. This means that the total time
required to process a block of information is 10 m with a 5 ms constant overhead factor. See
Figure 3-1: Voice Compression.
· Algorithmic Delay for G.726 coders is 0 ms
· Algorithmic Delay for G.729 coders is 5 ms.
· Algorithmic Delay for G.723.1 coders is 7.5 ms
For the examples in the remainder of this document, assume G.729 compression with a 30
ms/30 byte payload. In order to facilitate design, and take a conservative approach, the tables
given in the remainder of this document assume the worst case coder delay. The coder delay,
decompression delay, and algorithmic delay is lumped into one factor which is called the coder
delay.
The equation used to generate the lumped Coder Delay Parameter is:
Equation 1 : Lumped Coder Delay Parameter
The lumped Coder delay for G.729 that is used for the remainder of this document is:
Worst Case Compression Time Per Block: 10 ms
Decompression Time Per Block x 3 Blocks 3 ms
Algorithmic Delay 5 ms ---------------------------
191
Tel. #: (034) 312-6189 / (034) 729-4327
Total (χ) 18 ms
Packetization Delay
Packetization delay (πn) is the time taken to fill a packet payload with encoded/compressed
speech. This delay is a function of the sample block size required by the vocoder and the number
of blocks placed in a single frame. Packetization delay can also be called Accumulation delay, as
the voice samples accumulate in a buffer before they are released.
As a general rule you need to strive for a packetization delay of no more than 30 ms. In the
Cisco router/gateways you need to use these figures from Table 5.2 based on configured
payload size:
Table 5 .2: Common Packetization
Payload Payload
Packetization Packetization
Coder S i z e S i z e
Delay (ms) Delay (ms)
(Bytes) (Bytes)
P C M , 6 4
160 20 240 30
G.711 Kbps
3 2
ADPCM,
Kbps 80 20 120 30
G.726
C S-ACE
8 . 0
L P , 20 20 30 30
Kbps
G.729
MP-MLQ 6 . 3
, Kbps 24 24 60 48
G.723.1
MP-ACE
5 . 3
L P ,
Kbps 20 30 60 60
G.723.1
You have to balance the Packetization delay against the CPU load. The lower the delay, the
higher the frame rate, and the higher the load on the CPU. On some older platforms, 20 ms
payloads can potentially strain the main CPU.
192
Tel. #: (034) 312-6189 / (034) 729-4327
Pipeline Delay in the Packetization Process
Though each voice sample experiences both algorithmic delay and packetization delay, in reality,
the processes overlap and there is a net benefit effect from this pipelining. Consider the example
shown in Figure 2-1.
Figure 5-2 : Pipelining and Packetization
The top line of the figure depicts a sample voice wave form. The second line is a time scale in 10
ms increments. At T0, the CS-ACELP algorithm begins to collect PCM samples from the codec. At
T1, the algorithm has collected its first 10 ms block of samples and begins to compress it. At T2,
the first block of samples has been compressed. In this example the compression time is 2.5 ms,
as indicated by T2-T1.
The second and third blocks are collected at T3 and T4. The third block is compressed at T5. The
packet is assembled and sent (assumed to be instantaneous) at T6. Due to the pipelined nature
193
Tel. #: (034) 312-6189 / (034) 729-4327
of the Compression and Packetization processes, the delay from when the process begins to
when the voice frame is sent is T6-T0, or approximately 32.5 ms.
For illustration, this example is based on best case delay. If the worst case delay is used, the
figure is 40 ms, 10 ms for Coder delay and 30 ms for Packetization delay.
Note that these examples neglect to include algorithmic delay.
Serialization Delay
Serialization delay (σn) is the fixed delay required to clock a voice or data frame onto the
network interface. It is directly related to the clock rate on the trunk. At low clock speeds and
small frame sizes, the extra flag needed to separate frames is significant.
Table 5.3 shows the serialization delay required for different frame sizes at different line speeds.
This table uses total frame size, not payload size, for computation.
Table 5.3: Serialization Delay in Milliseconds for Different Frame Sizes
F r a m e Line Speed (Kbps)

S i z e
(bytes) 19.2 56 64 128 256 384 512 768 1024 1544 2048
38 15.83 5.43 4.75 2.38 1.19 0.79 0.59 0.40 0.30 0.20 0.15
48 20.00 6.86 6.00 3.00 1.50 1.00 0.75 0.50 0.38 0.25 0.19
64 26.67 9.14 8.00 4.00 2.00 1.33 1.00 0.67 0.50 0.33 0.25
128 53.33 18.29 16.00 8.00 4.00 2.67 2.00 1.33 1.00 0.66 0.50
256 106.67 36.57 32.00 16.00 8.00 5.33 4.00 2.67 2.00 1.33 1.00
512 213.33 73.14 64.00 32.00 16.00 10.67 8.00 5.33 4.00 2.65 2.00
1024 426.67 149.29 128.00 64.00 32.00 21.33 16.00 10.67 8.00 5.31 4.00
1500 625.00 214.29 187.50 93.75 46.88 31.25 23.44 15.63 11.72 7.77 5.86
2048 853.33 292.57 256.00 128.00 64.00 42.67 32.00 21.33 16.00 10.61 8.00
In the table, on a 64 Kbps line, a CS-ACELP voice frame with a length of 38 bytes (37+1 flag)
has a serialization delay of 4.75 ms.
194
Tel. #: (034) 312-6189 / (034) 729-4327
Note: The serialization delay for a 53 byte ATM cell (T1: 0.275ms, E1: 0.207ms) is negligible
due to the high line speed and small cell size.
Queuing/Buffering Delay
After the compressed voice payload is built, a header is added and the frame is queued for
transmission on the network connection. Voice needs to have absolute priority in the
router/gateway. Therefore, a voice frame must only wait for either a data frame that already
plays out, or for other voice frames ahead of it. Essentially the voice frame waits for the
serialization delay of any preceding frames in the output queue. Queuing delay (ßn) is a variable
delay and is dependent on the trunk speed and the state of the queue. There are random
elements associated with the queuing delay.
For example, assume that you are on a 64 Kbps line, and that you are queued behind one data
frame (48 bytes) and one voice frame (42 bytes). Because there is a random nature as to how
much of the 48 byte frame has played out, you can safely assume, on average, that half the
data frame has been played out. Based on the data from the serialization table, your data frame
component is 6 ms * 0.5 = 3 ms. When you add the time for another voice frame ahead in the
queue (5.25 ms), it gives a total time of 8.25 ms queuing delay.
How one characterizes the queuing delay is up to the network engineer. Generally, one needs to
design for the worst case scenario and then tune performance after the network is installed. The
more voice lines available to the users, the higher the probability that the average voice packet
waits in the queue. The voice frame, because of the priority structure, never waits behind more
than one data frame.
Network Switching Delay

The public frame relay or ATM network that interconnects the endpoint locations is the source of
the largest delays for voice connections. Network Switching Delays (ωn) are also the most
difficult to quantify.
If wide-area connectivity is provided by Cisco equipment, or some other private network, it is

possible to identify the individual components of delay. In general, the fixed components are
from propagation delays on the trunks within the network, and variable delays are from queuing
delays clocking frames into and out of intermediate switches. In order to estimate propagation
delay, a popular estimate of 10 microseconds/mile or 6 microseconds/km (G.114) is widely
used. However, intermediate multiplexing equipment, backhauling, microwave links, and other
factors found in carrier networks create many exceptions.
The other significant component of delay is from queuing within the wide-area network. In a
private network, it can be possible to measure existing queuing delays or to estimate a per-hop
budget within the wide-area network.
195
Tel. #: (034) 312-6189 / (034) 729-4327
Typical carrier delays for US frame relay connections are 40 ms fixed and 25 ms variable for a
total worst case delay of 65 ms. For simplicity, in examples 6-1, 6-2, and 6-3, any low speed
serialization delays in the 40 ms fixed delay are included.
These are figures published by US frame relay carriers, in order to cover anywhere to anywhere
coverage within the United States. It is to be expected that two locations which are
geographically closer than the worst case have better delay performance, but carriers normally
document just the worst case.
Frame relay carriers sometimes offer premium services. These services are usually for voice or
Systems Network Architecture (SNA) traffic, where the network delay is guaranteed and less
than the standard service level. For instance, a US carrier recently announced such a service
with an overall delay limit of 50 ms, rather than the standard service's 65 ms.
De-Jitter Delay
Because speech is a constant bit-rate service, the jitter from all the variable delays must be
removed before the signal leaves the network. In Cisco router/gateways this is accomplished
with a de-jitter (Δn) buffer at the far-end (receiving) router/gateway. The de-jitter buffer
transforms the variable delay into a fixed delay. It holds the first sample received for a period of
time before it plays it out. This holding period is known as the initial play out delay.
Figure 5- 3 : De-Jitter Buffer Operation
It is essential to handle properly the de-jitter buffer . If samples are held for too short a time,
variations in delay can potentially cause the buffer to under-run and cause gaps in the speech. If
the sample is held for too long a time, the buffer can overrun, and the dropped packets again
cause gaps in the speech. Lastly, if packets are held for too long a time, the overall delay on the
connection can rise to unacceptable levels.
The optimum initial play out delay for the de-jitter buffer is equal to the total variable delay
along the connection. This is shown in Figure 5-4.
Note: The de-jitter buffers can be adaptive, but the maximum delay is fixed. When adaptive
buffers are configured, the delay becomes a variable figure. However, the maximum delay can
be used as a worst case for design purposes.
196
Tel. #: (034) 312-6189 / (034) 729-4327
For more information on adaptive buffers, refer to Playout Delay Enhancements for Voice over
IP.
Figure 5 -4 : Variable Delay and the De-Jitter Buffer
The initial playout delay is configurable. The maximum depth of the buffer before it overflows is
normally set to 1.5 or 2.0 times this value.
If the 40 ms nominal delay setting is used, the first voice sample received when the de-jitter
buffer is empty is held for 40 ms before it is played out. This implies that a subsequent packet
received from the network can be as much as 40 ms delayed (with respect to the first packet)
without any loss of voice continuity. If it is delayed more than 40 ms, the de-jitter buffer empties
and the next packet received is held for 40 ms before play out to reset the buffer. This results in
a gap in the voice played out for about 40 ms.
The actual contribution of de-jitter buffer to delay is the initial play out delay of the de-jitter
buffer plus the actual amount the first packet was buffered in the network. The worst case is
twice the de-jitter buffer initial delay (assumption is that the first packet through the network
experienced only minimum buffering delay). In practice, over a number of network switch hops,
it is probably not necessary to assume the worst case. The calculations in the examples in the
remainder of this document increase the initial play out delay by a factor of 1.5 to allow for this
effect.
Note: In the receiving router/gateway there is delay through the decompression function.
However, this is taken into account by lumping it together with the compression processing
delay as discussed previously.
Build the Delay Budget

The generally-accepted limit for good-quality voice connection delay is 200 ms one-way (or 250
ms as a limit). As delays rise over this figure, talkers and listeners become un-synchronized, and
often they speak at the same time, or both wait for the other to speak. This condition is
197
Tel. #: (034) 312-6189 / (034) 729-4327
commonly called talker overlap. While the overall voice quality is acceptable, users sometimes
find the stilted nature of the conversation unacceptably annoying. Talker overlap can be
observed on international telephone calls which travel over satellite connections (satellite delay is
in the order of 500 ms, 250 ms up and 250 ms down).
These examples illustrate various network configurations and the delays which the network
designer needs to take into account.
Single-Hop Connection
Figure 6 - 1: Single Hop Example Connection
From this figure, a typical one-hop connection over a public frame relay connection can have the delay
budget shown Table 6.1.
Table 6 .1: Single Hop Delay Calculation
F i x e d
Delay Type Variable (ms)
(ms)
Coder Delay, χ1 18
198
Tel. #: (034) 312-6189 / (034) 729-4327
Packetization Delay, π1 30
Queuing/Buffering, ß1 8
Serialization Delay (64 kbps), σ1

5
Network Delay (Public Frame),

40 25
ω1
De-jitter Buffer Delay, Δ1 45
Totals 138 33
Note: Since queuing delay and the variable component of the Network delay is already
accounted within the de-jitter buffer calculations, the Total delay is effectively only the sum of all
the Fixed Delay. In this case the total delay is 138 ms.
Two Hops on a Public Network with a C7200 that Acts as a Tandem Switch
Figure 6 - 2: Two Hops Public Network Example with Router/Gateway Tandem
Now consider a branch-to-branch connection in a star-topology network where the C7200 in the
headquarters site tandems the call to the destination branch. In this case the signal stays in
compressed format through the central C7200. This results in considerable savings in the delay
199
Tel. #: (034) 312-6189 / (034) 729-4327
budget with respect to the next example, Two-Hop Connection Over A Public Network With A
PBX Tandem Switch.
Table 6.2: Two Hop Public Network Delay Calculation with Router/Gateway Tandem
F i x e d
(ms)
Coder Delay, χ1 18
Serialization Delay (64 kbps),

σ1 5

ω1 40 25
Tandem Delay in MC3810, τ1 1
Queuing/Buffering, ß2 0.2
Serialization Delay (2 Mbps),

σ2 0.1

ω2 40 25
Totals 209.1 58.2
the Fixed Delay. In this case the total delay is 209.1 ms.
Two-Hop Connection over a Public Network with a PBX Tandem Switch

Figure 6-3: Two Hop Public Network Example with PBX Tandem
200
Tel. #: (034) 312-6189 / (034) 729-4327
Consider a branch-to-branch connection in a branch-to-headquarters network where the C7200
at the headquarters site passes the connection through to the headquarters PBX for switching.
Here the voice signal has to be decompressed and de-jittered and then re-compressed and
de-jittered a second time. This results in extra delays relative to the previous example.
Additionally, the two CS-ACELP compression cycles reduce voice quality (see Effects Of Multiple
Compression Cycles).
Table 6.3: Two Hop Public Network Delay Calculation with PBX Tandem
F i x e d
(ms)
Coder Delay, χ1 18

σ1 5

ω1 40 25
Coder Delay, χ2 15
201
Tel. #: (034) 312-6189 / (034) 729-4327
Serialization Delay (2 Mbps),

σ2 0.1

ω2 40 25
Totals 258.1 58.1
the Fixed Delay plus the de-jitter buffer delay. In this case the total delay is 258.1 ms.
If you use the PBX at the central site as a switch, it increases the one-way connection delay from
206 ms to 255 ms. This is close to the ITU limits for one-way delay. This type of network
configuration requires the engineer to pay close attention to design for minimum delay.
The worst case is assumed for variable delay (although both legs on the public network do not
see maximum delays simultaneously). If you make more optimistic assumptions for the variable
delays, it only minimally improves the situation. However, with better information about the
fixed and variable delays in the frame relay network of the carrier, the calculated delay can be
reduced. Local connections (for instance intra-State) can be expected to have much better delay
characteristics, but carriers are often reluctant to give delay limits.
Two-Hop Connection over a Private Network with a PBX Tandem Switch

Figure 6-4: Two Hop Private Network Example with PBX Tandem
202
Tel. #: (034) 312-6189 / (034) 729-4327
Example 4.3 shows that, with the assumption of worst case delays, it is very difficult to keep the
calculated delay under 200 ms when a branch-to-branch connection includes a PBX tandem hop
at the central site with public frame-relay network connections on either side. However, if the
network topology and traffic is known, it is possible to substantially reduce the calculated figure.
This is because the figures generally given by carriers are limited by the worst case transmission
and queuing delay over a wide area. It is much easier to establish more reasonable limits in a
private network.
The generally accepted figure for transmission delay between switches is of the order of 10
microseconds/mile. Based on the equipment, the trans-switch delay in a frame relay network
needs to be in the order of 1 ms fixed and 5 ms variable for queuing. These figures are
equipment and traffic dependent. The delay figures for the Cisco MGX WAN Switches is less than
1 ms per switch total if E1/T1 trunks are used. With the assumption of 500 miles of distance,
with 1 ms fixed and 5 ms variable for each hop, the delay calculation becomes:
Table 6 .4: Two Hop Private Network Delay Calculation with PBX Tandem
F i x e d Variable
Delay Type
(ms) (ms)
Coder Delay, χ1 18
Serialization Delay (64 kbps), σ1 5
203
Tel. #: (034) 312-6189 / (034) 729-4327
Network Delay (Private Frame),
ωS1 + ßS1+ ωS2 + ßS2 2 10
Coder Delay, χ2 15
Serialization Delay (2 Mbps), σ2 0.1
Network Delay (Private Frame),

ωS3 + ßS3 1 8

σS3 5
Transmission/distance delay
5
(not broken down)
Totals 191.1 26.1
accounted within the de-jitter buffer calculations, the Total delay is only the sum of all the Fixed
Delay. In this case the total delay is 191.1 ms.
When you run over a private frame relay network, it is possible to make a spoke-to-spoke
connection through the PBX at the hub site and stay within the 200 ms figure.
Effects of Multiple Compression Cycles

The CS-ACELP compression algorithms are not deterministic. This means that the input data
stream is not exactly the same as the output data stream. A small amount of distortion is
introduced with each compression cycle as shown in Figure 7-1.
Figure 7-1: Compression Effects
204
Tel. #: (034) 312-6189 / (034) 729-4327
Consequently, multiple CS-ACELP compression cycles quickly introduce significant levels of
distortion. This additive distortion effect is not as pronounced with adaptive differential pulse
code modulation (ADPCM) algorithms.
The impact of this characteristic is that in addition to the effects of delay, the network designer
must consider the number of CS-ACELP compression cycles in the path.
Voice quality is subjective. Most users find that two compression cycles still provide adequate
voice quality. A third compression cycle usually results in noticeable degradation, which can be
unacceptable to some users. As a rule, the network designer needs to limit the number of
CS-ACELP compression cycles in a path to two. If more cycles must be used, let the customer
hear it first.
In the previous examples , it is shown that when a branch-to-branch connection is tandem

switched through the PBX (in PCM form) at the headquarters site, it experiences significantly
more delay than if it were tandem-switched in the headquarters C7200. It is clear that when the
PBX is used to switch, there are two CS-ACELP compression cycles in the path, instead of the
one cycle when the framed voice is switched by the central C7200. The voice quality is better
with the C7200-switched example (4.2), although there can be other reasons, such as calling
plan management, that can require the PBX to be included in the path.
If a branch-to-branch connection is made through a central PBX, and from the second branch
the call is extended over the public voice network and then terminates on a cellular telephone
network, there are three CS-ACELP compression cycles in the path, as well as significantly
higher delay. In this scenario, quality is noticeably affected. Again, the network designer must
consider the worst-case call path and decide whether it is acceptable given the users network,
expectations, and business requirements.
Considerations for High-Delay Connections

It is relatively easy to design packet voice networks which exceed the ITU generally accepted
150 ms one-way delay limit.
When you design packet voice networks, the engineer needs to consider how often such a
connection is used, what the user demands, and what type of business activity is involved. It is
not uncommon for such connections to be acceptable in particular circumstances.
205
Tel. #: (034) 312-6189 / (034) 729-4327
If the frame relay connections do not traverse a large distance, it is quite likely that the delay
performance of the network is better than that shown in the examples.
If the total delay experienced by tandem router/gateway connections becomes too great, an
alternative is often to configure extra permanent virtual circuits (PVCs) directly between the
terminating MC3810s. This adds recurring cost to the network as carriers usually charge per
PVC, but it can be necessary in some cases.
206
Tel. #: (034) 312-6189 / (034) 729-4327

Data Communications With Voip

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Data Communications With Voip

Enviado por

Direitos autorais:

Formatos disponíveis

Data Communication w/

Encoded by: arfel c. arcabal

Prepared by: marl t. gonzalez

PHASE I: DATA COMMUNICATION

Data Communications concerns the transmission of digital messages to devices external

· ISO OSI reference model

A set of protocol is open if:

· Protocol details are publicly available

A system that implements open protocols is called an open system.

· Open system interconnect (OSI)

Figure 6: The (OSI) Seven Layer Model

Data Link Layer

Internet Protocol Suite

Internet Protocol (IP)

· IP addresses are represented by 32-bit unsigned binary values.

The Application Layer

The Transport Layer

The Internet Layer

The Network Interface Layer

Organization of the Internet

· A handful of network service provider (NSPs) (e.g. BT) maintain a series of

Figure 9: Typical Set-up of the Internet

Some are free – although many charge a monthly fee

World Wide Web

Who controls the Internet?

To have new standard approved:

· On positive conclusion by IESG:

· Final approval by IESG

Internet draft is recommended to IETF for publication as RFC

Voice Over IP (VoIP)

The following routes are possible with VoIP

Figure 10: Handset-to-Handset IP Technology

Figure 11: Computer-to-Computer IP Technology

Interoperability with PSTN

What is wrong with H.323

SIP allows multiparty calls to be setup using IP multicast capabilities.

How SIP works

ICT convergence involves the coming together of information distribution infrastructures;

The OSI Reference Model

1. A layer should be created where a different level of abstraction is needed.

2. Each layer should perform a well defined function.

THE OPEN SYSTEMS INTERCONNECTION MODEL

Presentation Layer (6) Higher

Transport Layer (4)

Network Layer (3)

FIGURE 7-1 Layers of the Open Systems Interconnection Model

DTE and DCE

(Data Terminating Equipment) A communications device that is the source or destination of

Flow control can be implemented in hardware or software, or a combination of both.

TCP manages limited network bandwidth by performing flow control.

Synchronous Communication Adapters for use on HP Alpha Systems

High –speed Synchronous WAN Communications

Intelligent Synchronous Adapters

· Asynchronous Transfer Mode

· asynchronous serial interfaces

· packet switched systems such as Ethernet or internet protocol

· asynchronous computer APIs

· Collaborative editing systems

· Asynchronous Cellular Automaton

Telecommunications - Asynchronous (stop/start) data transmission

---+ +---+ +-------+ +--------------1=mark

Stop/start is used when connecting to the Public Network pad.

line rate 110 b/s line rate > 110 b/s