Asynchronous
Transfer Mode (ATM) is an International Telecommunication Union-
Telecommunication Standardization Sector (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, services, and operation. Figure 20-1 illustrates a
private ATM network and a public ATM network carrying voice, video, and
data traffic.
Figure 20-1: A
private ATM network and a public ATM network both can carry voice,
video, and data traffic.
ATM is based on the
efforts of
the ITU-T Broadband Integrated Services Digital Network (BISDN)
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:
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
a lot of data to send, it can send only when its time slot comes up,
even if all other time slots are empty. If, however, 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 on demand with information identifying the source of the
transmission contained in the header of each ATM cell.
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 20-2 illustrates the
basic format of an ATM cell.
Figure 20-2: An
ATM network comprises ATM switches and endpoints.
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 20-3 illustrates an ATM
network made up of ATM
switches and ATM endpoints.
Figure 20-3: An
ATM network comprises ATM switches and endpoints.
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 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
Interexchange Carrier Interconnect (B-ICI), connects two public
switches from different service providers. Figure 20-4 illustrates
the ATM interface specifications for
private and public networks.
Figure 20-4: ATM
interface specifications differ for private and public networks.
An ATM
cell header can be one of two formats: UNI
or the 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 20-4 depicts
the basic ATM cell format, the ATM UNI cell-header format, and the ATM
NNI cell-header format.
Figure 20-5: An
ATM cell, 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.
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 20-5:
Three types of ATM
services exist: permanent virtual circuits (PVC),
switched virtual circuits (SVC), and connectionless service
(which is similar to SMDS).
A PVC allows direct connectivity between
sites. In this way, a PVC is similar to a leased line. Among its
advantages, a PVC guarantees availability of a connection and does not
require call setup procedures between switches. Disadvantages of PVCs
include static connectivity and manual setup.
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 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 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 on the basis of the common VPI. All
VCIs and VPIs, however, have only local significance across a particular
link and are remapped, as appropriate, at each switch.
A transmission path is a bundle of VPs. Figure
20-6 illustrates how VCs concatenate to create VPs, which,
in turn, concatenate to create a transmission path.
Figure 20-6: VC
concatenate to create VPs.
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.
The
ATM
architecture uses a logical
model to describe the functionality 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:
The ATM reference model is composed of
the following ATM
layers:
Finally, the higher layers residing above
the AAL accept user data, arrange it into packets, and hand it to the
AAL. Figure 20-7 illustrates the
ATM reference model.
Figure 20-7: The
ATM reference model relates to the lowest two layers of the OSI
reference model.
The
ATM physical
layer has four functions: bits are converted into cells, 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.
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 Optical Network/Synchronous
Digital Hierarchy (SONET/SDH), 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.
The TC sublayer has four functions: cell
dilineation, 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.
AAL1, a connection-oriented service,
is suitable for handling circuit-emulation applications, such as voice
and video conferencing. 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
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 20-8 illustrates how
AAL1 prepares a cell for transmission.
Figure 20-8: AAL1
prepares a cell for transmission so that the cells retain
their order.
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 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.
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 adding
any additional fields.
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 zero
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 one.
The ITU-T standard
is based on the use of E.164 addresses (similar to telephone numbers)
for public ATM (BISDN) 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.
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.
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 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.
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
ICD formats to form their own numbering plan.
Figure 20-9 illustrates the
three formats of ATM
addresses used for private networks.
Figure 20-9: Three
formats of ATM addresses are used for private networks.
The following
descriptions summarize the fields illustrated in Figure 20-9:
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 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 unable to
reconstruct 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
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 can get 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 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 prior
to the next being 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 would also require 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 supports QoS guarantees
composed of 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.
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.
Standards currently exist only for ATM
UNI signaling, but standardization work is continuing on NNI signaling.
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 proceeeds 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.
Routing of the connection
request is governed by an ATM routing protocol (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, in turn, affect the connection routing. Figure
20-10 highlights the one-pass method of ATM connection establishment.
Figure 20-10: ATM
devices establish connections through the one-pass method.
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 end-system
sends a setup message (including the destination end-system address 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.
LANE is a standard defined by the ATM
Forum that gives to stations attached via ATM the same capabilities 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 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 20-11 compares a physical LAN
and an ELAN.
Figure 20-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 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 able to use the vastly greater bandwidth of ATM
networks.
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 20-12 shows the LANE
protocol architecture implemented in ATM network devices.:
Figure 20-12: LANE
protocol architecture can be implemented in ATM network devices.
Note The
LANE protocol does not directly affect ATM switches. LANE, as with most
of the other ATM internetworking protocols, builds on the overlay model.
As such, the LANE protocols operate transparently over and through ATM
switches, using only standard ATM signaling procedures.
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:
Figure 20-13 illustrates the
components of an ELAN.:
Figure 20-13: An
ELAN consists of clients, servers, and various intermediate nodes.
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 20-14 shows the LANE data
connections.
Figure 20-14: LANE
data connections use a series of VCLs to link a LAN switch and ATM
hosts.
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
20-15 illustrates LANE control connections.
Figure 20-15: LANE
control connections link the LES, LECS, LAN switch, and ATM host.
The operation of a LANE
system and components is best understood by examining these stages of
LEC operation: intialization and configuration, ; joining and
registering with the LES, ; finding and joining the BUS, ; and data
transfer.
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).
When the LECS is found, the LEC sets up a
configuration-direct VCC to the LECS and sends a LE_CONFIGURE_REQUEST.
If a matching entry is found, the LECS returns a LE_CONFIGURE_RESPONSE
to the LEC with the configuration information 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).
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 connection to the LECS, sets up
the control-direct VCC to the LES, and sends an LE_JOIN_REQUEST 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, 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 that contains a unique LAN Emulation Client ID
(LECID). The LECID is used by the LEC to filter its own broadcasts
from 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
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.
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 translate and forward the ARP on their LAN interfaces.
In the case of actual data transfer, if
an LE_ARP is received, the LEC sets up a data-direct VCC to the
destination node 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 cell 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.
Get
this document in PDF form
|
