Section 1 of 3 - Prev - Next
All sections - 1 - 2 - 3

Archive-name: cell-relay-faq/part4
Last-modified: 1997/10/06
URL: http://cell-relay.indiana.edu/cell-relay/FAQ/ATM-FAQ/FAQ.html

NOTE!!!! If you are reading this FAQ as stored on some automated FAQ
archive site you would be better off to follow the above http link to
the most recent official version of this FAQ.  Not only may it be more
current but it will be better formatted than what you are viewing now!

-----------------------------------------------------------------------
comp.dcom.cell-relay FAQ: ATM and related technologies (Rev 1997/10/06)
Part 4 - Introduction and Topic D of FAQ
-----------------------------------------------------------------------
Copyright =A9 1992, 1993, 1994, 1995, 1996, 1997 Carl Symborski

Cell Relay FAQ - Introduction

The Cell Relay FAQ is posted periodically in multiple parts as a Usenet
News FAQ under the title comp.dcom.cell-relay FAQ: ATM, SMDS, and related
technologies. This FAQ is also maintained as a collection of WEB pages
(http://cell-relay.indiana.edu/cell-relay/FAQ/ATM-FAQ/FAQ.html). The WEB
pages will generally be more current than the posted FAQ. In fact this
FAQ is maintained as WEB pages then posted as a traditional Usenet News
FAQ every few months.

This article is the fourth of eight articles which contain general
information and also answers to some Frequently Asked Questions (FAQ)
which are related to or have been seen in comp.dcom.cell-relay. This FAQ
provides information of general interest to both new and experienced
readers. It is posted to the Usenet comp.dcom.cell-relay, comp.answers,
and news.answers news groups every few months.

This FAQ reflects cell-relay traffic through August 1997.

If you have any additions, corrections, or suggestions for improvement to
this FAQ, please send them to carl@umd5.umd.edu.

I will accept suggestions for questions to be added to the FAQ, but please
be aware that I will be more receptive to questions that are accompanied by
answers. :-)

Enjoy!

Carl Symborski
Vice President - Engineering
SALIX Technology, Inc.

carl@umd5.umd.edu
cws@salix.com

Carl's home page is at
http://cell-relay.indiana.edu/cell-relay/FAQ/ATM-FAQ/carl/home.html

---------------------------------------------------------------------------

Cell Relay FAQ - Copyright Notice and Disclaimer

The Cell Relay FAQ is posted periodically in multiple parts as a Usenet
News FAQ under the title comp.dcom.cell-relay FAQ: ATM, SMDS, and related
technologies. This FAQ is also maintained as a collection of WEB pages.

Both versions are Copyright =A9 1992-1997 Carl Symborski and may be freely
redistributed in their entirety provided that this copyright notice is not
removed. They may not be sold for profit or incorporated in commercial
documents or CD-ROMs without the written permission of Carl Symborski.
Permission is expressly granted for this document to be made available for
file transfer from installations offering unrestricted anonymous file
transfer on the Internet. This article is provided as is without any
express or implied warranty. Nothing in this article represents the views
of the University Of Maryland.

---------------------------------------------------------------------------

TOPIC D

ATM TECHNOLOGY QUESTIONS

---------------------------------------------------------------------------

  D1.  What are the various ATM Adaptation layers?
  D2.  Are ATM cells delivered in order?
  D3.  What do people mean by the term "traffic shaping"?
  D4.  What is happening with and Questions about signalling standards for
       ATM?
  D5.  What is VPI and VCI?
  D6.  Why both VPI *and* VCI?
  D7.  How come an ATM cell is 53 bytes anyway?
  D8.  How does AAL5 work?
  D9.  What are the diffferences between Q.93B, Q.931, and Q.2931?
  D10. What is a DXI?
  D11. What is Goodput?
  D12. Questions about LAN Emulation (LANE).
  D13. Questions about the Classsical IP over ATM approach.
  D14. What is the difference between a PVC, Soft PVC, and SVC?
  D15. ATM Physical Level Questions.
  D16. What is ABR?
  D17. Questions about VPI/VCI assignment?
  D18. Specs on how Frame Relay frames gets mapped to ATM cells.
  D19. What are the meaning of CBR, VBR, ABR, UBR?
  D20. Are VP and VC unidirectional?
  D21. M4 ATM Mgmt Interface Questions?
  D22. Questions about QOS.
  D23. Questions about ATM Cell Headers.
  D24. What is MPOA?
  D25. Partial/Early Packet Discard (PPD/EPD) Questions
  D26. Questions about ATM addressing schemes
  D27. What are DBR and SBR?
  D28. What is CLP=3D0+1 all about?
  D29. Connection establishing in the ATM layer
  D30. Information about about B-ISDN and B-ICI

---------------------------------------------------------------------------
SUBJECT D1)

                What are the various ATM Adaptation layers?

In order for ATM to support many kinds of services with different traffic
characteristics and system requirements, it is necessary to adapt the
different classes of applications to the ATM layer. This function is
performed by the AAL, which is service-dependent. Four types of AAL were
originally recommended by CCITT. Two of these have now been merged into
one.

Briefly the four ATM adaptation layers (AAL) have been defined:

   * AAL1 - Supports connection-oriented services that require constant bit
     rates and have specific timing and delay requirements. Example are
     constant bit rate services like DS1 or DS3 transport.
   * AAL2 - This adaptation is a method for carrying voice over ATM. It
     consists of variable size packets (max : 64 bytes) encapsulated within
     the ATM payload. This was previously known as Composite ATM or AAL-CU.
     The ITU spec which describes this is called ITU-T I.363.2.
   * AAL3/4 - This AAL is intended for both connectionless and connection
     oriented variable bit rate services. Originally two distinct
     adaptation layers AAL3 and 4, they have been merged into a single AAL
     which name is AAL3/4 for historical reasons.
   * AAL5 - Supports connection-oriented variable bit rate data services.
     It is a substantially lean AAL compaired with AAL3/4 at the expense of
     error recovery and built in retransmission. This tradeoff provides a
     smaller bandwidth overhead, simpler processing requirements, and
     reduced implementation complexity. Some organizations have proposed
     AAL5 for use with both connection-oriented and connectionless
     services.

Note that some folks talk about an "AAL0" which normally refers to a 'null'
AAL, i.e the case where the payload is directly inserted into a cell. This
typically requires that the payload can always be fitted into a single cell
so that the AAL is not needed for upper layer PDU delineation when the
upper layer PDU bridges several cells.

---------------------------------------------------------------------------
SUBJECT D2)

                     Are ATM cells delivered in order?

Yes. The ATM standards specify that all ATM cells will be delivered in
order. Any switch and adaptation equipment design must take this into
consideration.

---------------------------------------------------------------------------
SUBJECT D3)

             What do people mean by the term "traffic shaping"?

Here is an explicit definition of traffic shaping followed by brief
tutorial. Note that a variety of techniques have been investigated to
implement traffic shaping. Reference the literature for keywords such as
"leaky bucket", "congestion", "rate control", and "policing".

Definition:
     Traffic shaping is forcing your traffic to conform to a certain
     specified behavior. Usually the specified behavior is a worst case or
     a worst case plus average case (i.e., at worst, this application will
     generate 100 Mbits/s of data for a maximum burst of 2 seconds and its
     average over any 10 second interval will be no more than 50 Mbit/s).

Of course, understand that the specified behavior may closely match the way
the traffic was going to behave anyway. But by knowing precisely how the
traffic is going to behave, it is possible to allocate resources inside the
network such that guarantees about availability of bandwidth and maximum
delays can be given.

Brief Tutorial

Assume some switches connected together which are carrying traffic. The
problem to actually deliver the grade of service that has been promised,
and that people are paying good money for. This requires some kind of
resource management strategy, since congestion will be by far the greatest
factor in data loss. You also need to charge enough to cover you costs and
make a profit, but in such a way that you attract customers. There are a
number of parameters and functions that need to be considered:

PARAMETERS

There are lots of traffic parameters that have been proposed for resource
management. The more important ones are:

   * mean bitrate
   * peak bitrate
   * variance of bitrate
   * burst length
   * burst frequency
   * cell-loss rate
   * cell-loss priority
   * etc. etc.

These parameters exist in three forms:

   * actual
   * measured, or estimated
   * declared (by the customer)

FUNCTIONS

(a) Acceptance Function
     Each switch has the option of accepting a virtual circuit request
     based on the declared traffic parameters as given by the customer.
     Acceptance is given if the resulting traffic mix will not cause the
     switch to not achieve its quality of service goals.

     The acceptance process is gone through by every switch in a virtual
     circuit. If a downstream switch refuses to accept a connection, an
     alternate route might be tried.

(b) Policing Function
     Given that a switch at the edge of the network has accepted a virtual
     circuit request, it has to make sure the customer equipment keeps its
     promises. The policing function in some way estimates the the
     parameters of the incoming traffic and takes some action if they
     measure traffic exceeding agreed parameters. This action could be to
     drop the cells, mark them as being low cell-loss priority, etc.

(c) Charging Function
     The function most ignored by traffic researchers, but perhaps the most
     important for the success of any service! Basically, this function
     computes a charge from the estimated and agreed traffic parameters.

(d) Traffic Shaping Function
     Traffic shaping is something that happens in the customer premise
     equipment. If the Policing function is the policeman, and the charging
     function is the judge, then the traffic shaper is the lawyer. The
     traffic shaper uses information about the policing and charging
     functions in order to change the traffic characteristics of the
     customer's stream to get the lowest charge or the smallest cell-loss,
     etc.

     For example, an IP router attached to an ATM network might delay some
     cells slightly in order to reduce the peak rate and rate variance
     without affecting throughput. An MPEG codec that was operating in a
     situation where delay wasn't a problem might operate in a CBR mode.

---------------------------------------------------------------------------
SUBJECT D4)

  What is happening with and Questions about signalling standards for ATM?

NOTE: An authoritative account of the ATM Forum's work on signalling and
other implementation agreements can be found by surfing their WEB site at
http://www.atmforum.com/. Check in their library for back issues of their
"53 Bytes" newsletter (September 1994 for starters). Also check their
approved recommendations.

From=20a historical perspective, some of the ATM Forum's work in this area =
is
as follows.

The Signaling Sub-Working Group (SWG) of the ATM Forum's Technical
Committee completed its implementation agreement on signaling at the ATM
UNI during the summer of 1993. The protocol is based on Q93B with
extensions to support point-to-multipoint connections. Agreements on
addressing specify the use of GOSIP-style NSAPs for the (SNPA) address of
an ATM end-point at the Private UNI, and the use of either or both
GOSIP-style NSAPs and/or E.164 addresses at the Public UNI. The agreements
have been documented as part of the UNI 3.0 specification.

Additionally, the ANSI T1S1 as well as the ITU-T studygroup XI are
concerned with ATM signalling. In the latter half of 1993 a couple of
things happened:

  1. The ITU finally agreed to modify its version of Q93B to more closely
     to align it with that specified in the ATM Forum's UNI 3.0
     specification. The remaining variations included some typos which the
     ITU Study Group found in the Forum's specification. Also, some
     problems were solved differently. Aligned yes, but the changes could
     still cause incompatibilities with UNI 3.0.

  2. Given the above, the ATM Forum's signalling SWG decided to modify the
     Forum's specification to close the remaining gap and align it with the
     ITU.

The biggest change was with SSCOP. UNI 3.0 references the draft ITU-T SSCOP
documents (Q.SAAL). However UNI 3.1 references the final ITU Q.21X0
specifications. These two secifications are not interoperable so there is
no backwards compatibility between UNI 3.0 and UNI 3.1. The ATM Forum UNI
3.1 specification was approved in Fall 1994 and has been distributed to ATM
Forum members and is also available online. See section C4.

UNI 4.0 was next which included not only switched VPs but also many
advances in QOS from the Traffic Management sub-working group.

Question: Signalling messages defined in Q.2931 and ATM Forum UNI v3.1
seems to establish VCCs only. How to establish VPCs by signalling?

Answer: ATM Forum UNI 4.0 provides for switched VPs. This is done by:

   * adding a new bearer class codepoint in bearCap IE for "VP service",
     and
   * adding a new pref/exc codepoint in connId IE for "exclusive VPCI, no
     VCI"

The ATM Forum also has a Private-NNI SWG. Currently they have worked on a
protocol (called PNNI) for distributing link and node state information,
and a call setup procedure, to support intra-network routing and switching.
The spec itself was completed in 1996.

Overall, the protocol is designed for source routing, where the first
switch in the network has enough information about the topology of the
network to determine a route, and then the path information is added to the
signaling message (SETUP) and routed along the path. The overall protocol
is considerably more complex than this, as its necessary to minimise the
view of the topology of a network from the sources point of view (a
topological hierarchy is used, among other things), but thats basically the
approach.

---------------------------------------------------------------------------
SUBJECT D5)

                            What is VPI and VCI?

ATM is a connection orientated protocol and as such there is a connection
identifier in every cell header which explicitly associates a cell with a
given virtual channel on a physical link. The connection identifier
consists of two sub-fields, the Virtual Channel Identifier (VCI) and the
Virtual Path Identifier (VPI). Together they are used in multiplexing,
demultiplexing and switching a cell through the network. VCIs and VPIs are
not addresses. They are explicitly assigned at each segment (link between
ATM nodes) of a connection when a connection is established, and remain for
the duration of the connection. Using the VCI/VPI the ATM layer can
asynchronously interleave (multiplex) cells from multiple connections.

---------------------------------------------------------------------------
SUBJECT D6)

                          Why both VPI *and* VCI?

The Virtual Path concept originated with concerns over the cost of
controlling BISDN networks. The idea was to group connections sharing
common paths through the network into identifiable units (the Paths).
Network management actions would then be applied to the smaller number of
groups of connections (paths) instead of a larger number of individual
connections (VCI). Management here including call setup, routing, failure
management, bandwidth allocation etc. For example, use of Virtual Paths in
an ATM network reduces the load on the control mechanisms because the
function needed to set up a path through the network are performed only
once for all subsequent Virtual Channels using that path. Changing the
trunk mapping of a single Virtual Path can effect a route change for every
Virtual Channel using that path.

Now the basic operation of an ATM switch will be the same, no matter if it
is handling a virtual path or virtual circuit. The switch must identify on
the basis of the incomming cell's VPI, VCI, or both, which output port to
forward a cell received on a given input port. It must also determine what
the new values the VPI/VCI are on this output link, substituting these new
values in the cell.

The algorithms for selecting which switch output port a given input VPI/VCI
should be mapped to is done at the time the call is set up, and is part of
the overall call routing algorithm. The port to be used depends on what
other switches that port is connected to. Call routing is addressed by
protocols like P-NNI (private network-network interface), just being
completed by the ATM forum.

The choice of an outbound VPI/VCI value, on the other hand, is partially a
function of the switch architecture, and partially a function of the
interface. The UNI spec dictates which side of a link, user or network,
selects values. The PNNI spec also has rules for this. Within the switch
designated as the one selecting the values, the choice depends on switch
internals (what space does it support, are VPI/VCI spaces on all ports
fully independent, what is the switch software's policy for value resue,
etc).

---------------------------------------------------------------------------
SUBJECT D7)

                  How come an ATM cell is 53 bytes anyway?

ATM cells are standardized at 53 bytes because it seemed like a good idea
at the time! As it turns out, during the standardization process a conflict
arose within the CCITT as to the payload size within an ATM cell. The US
wanted 64 byte payloads because it was felt optimal for US networks. The
Europeans and Japanese wanted 32 payloads because it was optimal for them.
In the end 48 bytes was chosen as a compromise. So 48 bytes payload plus 5
bytes header is 53 bytes total.

The two positions were not chosen for similar applications however. US
proposed 64 bytes taking into consideration bandwidth utilization for data
networks and efficient memory transfer (length of payload should be a power
of 2 or at least a multiple of 4). 64 bytes fit both requirements.

Europe proposed 32 bytes taking voice applications into consideration. At
cell sizes >=3D 152, there is a talker echo problem. Cell sizes between
32-152 result in listener echo. Cell sizes <=3D 32 overcome both problems,
under ideal conditions.

For several years the *near* consensus was 64 octets. France wanted 32
because they figured with 4 ms. cell fill time, they could *just* scrape by
from one end of the country to the other without echo cancellers, while in
the US we need em 'anyway. So France held its breath, took a few smaller
European countries with them, and demanded that 64 be lowered. Hence the
"split the difference" 48 size. This was at a CCITT SG XVIII meeting ca.
1989.

CCITT chose 48 bytes as a compromise. As far as the header goes, 10% of
payload was perceived as an upper bound on the acceptable overhead, so 5
bytes was chosen.

---------------------------------------------------------------------------
SUBJECT D8)

                            How does AAL5 work?

Here is is a very simplified view of AAL5 and AALs in general. AAL5 is a
mechanism for segmentation and reassembly of packets. That is, it is a
rulebook which sender and receiver agree upon for taking a long packet and
dividing it up into cells. The sender's job is to segment the packet and
build the set of cells to be sent. The receiver's job is to verify that the
packet has been received intact without errors and to put it back together
again.

AAL5 (like any other AAL) is composed of a common part (CPCS) and a service
specific part (SSCS). The common part is further composed of a convergence
sublayer (CS) and a segmentation and reassembly (SAR) sublayer.

+--------------------+
|                    | SSCS
+--------------------+
|        CS          |
| ------------------ | CPCS
|       SAR          |
+--------------------+

SAR segments higher a layer PDU into 48 byte chunks that are fed into the
ATM layer to generate 53 byte cells (carried on the same VCI). The payload
type in the last cell (i.e., wherever the AAL5 trailer is) is marked to
indicate that this is the last cell in a packet. (The receiver may assume
that the next cell received on that VCI is the beginning of a new packet.)

CS provides services such as padding and CRC checking. It takes an SSCS
PDU, adds padding if needed, and then adds an 8-byte trailer such that the
total length of the resultant PDU is a multiple of 48. The trailer consist
of a 2 bytes reserved, 2 bytes of packet length, and 4 bytes of CRC.

SSCS is service dependent and may provide services such as assured data
transmission based on retransmissions. One example is the SAAL developed
for signalling. This consists of the following:

+--------------------+
|       SSCF         |
| ------------------ | SSCS
|       SSCOP        |
+--------------------+
|        CS          |
| ------------------ | CPCS
|       SAR          |
+--------------------+

SSCOP is a general purpose data transfer layer providing, among other
things, assured data transfer.

SSCF is a coordination function that maps SSCOP services into those
primitives needed specifically for signalling (by Q.2931). Different SSCFs
may be prescribed for different services using the same SSCOP.

The SSCS may be null as well (e.g. IP-over-ATM or LAN Emulation).

There are two problems that can happen during transit. First, a cell could
be lost. In that case, the receiver can detect the problem either because
the length does not correspond with the number of cells received, or
because the CRC does not match what is calculated. Second, a bit error can
occur within the payload. Since cells do not have any explicit error
correction/detection mechanism, this cannot be detected except through the
CRC mismatch.

Note that it is up to higher layer protocols to deal with lost and
corrupted packets. This can be done by using a SSCS which supports assured
data transfer, as discussed above.

---------------------------------------------------------------------------
SUBJECT D9)

         What are the differences between Q.93B, Q.931, and Q.2931?

Essentially, Q.93B is an enhanced signalling protocol for call control at
the Broadband-ISDN user-network interface, using the ATM transfer mode. The
most important difference is that unlike Q.931 which manages fixed
bandwidth circuit switched channels, Q.93B has to manage variable bandwidth
virtual channels. So, it has to deal with new parameters such as ATM cell
rate, AAL parameters (for layer 2), broadband bearer capability, etc. In
addition, the ATM Forum has defined new functionality such as
point-to-multipoint calls. The ITU-T Recommendation will specify
interworking procedures for narrowband ISDN.

Note that as of Spring 1994, Q.93B has reached a state of maturity
sufficient to justify a new name, Q.2931 for its published official
designation.

---------------------------------------------------------------------------
SUBJECT D10)

                               What is a DXI?

The ATM DXI (Data Exchange Interface)is basically the functional equivalent
of the SMDS DXI. Routers will handle frames and packets but not typically
fragment them into cells; DSUs will fragment frames into cells as the
information is mapped to the digital transmission facility.

The DXI, then, provides the standard interface between routers and DSUs
without requiring a bunch of proprietary agreements. The SMDS DXI is simple
because the router does the frame (SMDS level 3) and the DSU does the cells
(SMDS level 2). The ATM DXI is a little more complicated since it has to
accomomodate AAL3/4 and/or AAL5 (possibly concurrently).

---------------------------------------------------------------------------
SUBJECT D11)

                              What is Goodput?

When ATM is used to transport cells originating from higher-level protocols
(HLP), an important consideration is the impact of ATM cell loss on that
protocol or at least the segmentation process. ATM cell loss can cause the
effective throughput of some HLPs to be arbitrarily poor depending on ATM
switch buffer size, HLP congestion control mechanisms, and packet size.

This occurs because during congestion for example, and ATM switch buffer
can overflow which will cause cells to be dropped from multiple packets,
ruining each such packet. The preceding and the remaining cells from such
packets, which are ultimately discarded by the frame reassembly process in
the receiver, are nevertheless transmitted on an already congested link,
thus wasting valuable link bandwidth.

The traffic represented by these "bad" cells may be termed as BADPUT.
Correspondingly, the effective throughput, as determined by those cells
which are successfully recombined at the receiver, can be termed as
GOODPUT.

One method of increasing the efficiency of ATM over AAL5 is to drop all
remaining cells for a given packet if one of the cells is lost. This
functionality is sometimes referred to as "early packet drop."

---------------------------------------------------------------------------
SUBJECT D12)

                       Questions about LAN Emulation

Question: What is the ATM Forum's LAN Emulation all about?

Answer: The ATM Forum has published their LAN Emulation (LANE) V1.0
specification. Reference that spec for complete details. Here's the basics
on the requirements and general approach.

The organizations who worked on it thought LANE would be needed for two key
reasons

  1. Allow an ATM network to be used as a LAN backbone for hubs, bridges,
     switching hubs (also sometimes called Ethernet switches or Token Ring
     switches) and the bridging feature in routers.

  2. Allow endstations connected to "legacy" LANs to communicate though a
     LAN-to-ATM hub/bridge/switch with an ATM-attached device (a file
     server, for example) without requiring the traffic to pass through a
     more complex device such as a router. Note that the LAN-attached
     device has a conventional, unchanged protocol stack, complete with MAC
     address, etc.

LANE does not replace routers or routing, but provides a complementary
MAC-level service which matches the trend to MAC-layer switching in the
hubs and wire closets of large LANs.

LANE defines the three main areas required to emulate 802 LANs
(connectionless, broadcast/multicast, 802 hardwired MAC addresses) over ATM
networks (connection-oriented, point-to-point, network-defined
telephone-like addresses).

LANE specifies:

  1. The address resolution procedures and protocols used to first discover
     the ATM address that corresponds to a given MAC station address
     (whether the station is directly ATM-attached, or sitting behind an
     Ethernet/ATM device) and then to set up a virtual circuit between the
     end points (or to the Ethernet/ATM device in front of the Ethernet end
     station).
  2. The protocols and procedures to send broadcast and multicast 802
     packets over the network, using a LANE server with point-to-point
     circuits inbound and point-to-multipoint circuits back out to the
     clients.
  3. Same for how to "flood" (bridging term) packets across ATM, through
     Ethernet/ATM devices to reach Ethernet end stations, even those which
     have not sent a packet yet (thus making the Ethernet switch aware of
     them).
  4. The packet formats/encapsulations.

LANE also works for Token Ring so substitute Token Ring for Ethernet in the
above.

LANE also defines how an ATM adapter in a host can present an Ethernet or
Token Ring logical interface to the protocol stack above. This enables
applications and LAN protocols which were implemented to run above the
aforesaid Ethernet or TR LANs to operate without change over an ATM
network.

Surf the ATM Forum's WEB site http://www.atmforum.com for the January 1995
back issue of their "53 Bytes" publication. That issue contains a helpful
LANE tutorial.

Question: How does LANE work?

Answer: Here is a brief spew on how LANE works with ATM:

   * LANE Client (LEC) Software resides on End System
   * LANE Server (LES) Software resides on the Switch

On boot the ATM adapter registers with the local switch and exchanges
management information. Switch provides a prefix to the ATM adapter which
in combination with the MAC address of the adapter becomes the ATM address
of the adapter. Switch also provides its ATM address.

At this point the 2 ATM adresses are known so the LEC establishes a virtual
circuit connection (VCC) with the LES.

The LEC Registers its ATM/IP/MAC Address with the LES and joins the
Emulated Lan. The LES adds the new LEC to the ARP distribution tree.

The LEC now queries the LES for the Broadcast/Unknown Server (BUS) for
multi- cast. LES provides BUS address. LEC establishes VCC with BUS and
registers its ATM/IP/MAC Address to mcast distribution tree.

Now we can talk to other end systems by arping for the ATM address to the
LES. LES does a lookup and upon hit returns the address. On a miss the LES
broadcasts the ARP in hopes that some LEC will answer. The response is
returned by the LES to the orignating LEC.

A VCC can now be established between the two LEC's and Data is moved.

---------------------------------------------------------------------------
SUBJECT D13)

            Questions about the Classical IP over ATM approach.

Question: Where can I find out about Classical IP over ATM?

Answer: RFC1483 defines the encapsulation of IP datagrams (or other
protocols) directly in AAL5.

Classical IP and ARP over ATM, defined in RFC1577, is targetted towards
making IP run over ATM in the most efficient manner utilizing as many of
the facilities of ATM as possible. It considers the application of ATM as a
direct replacement for the "wires" and local LAN segments connection IP
end-stations and routers operating in the "classical" LAN-based paradigm. A
comprehensive document, RFC1577 defines the ATMARP protocol for logical IP
subnets (LISs). Within an LIS, IP addresses map directly into ATM Forum UNI
3.0 addresses. For communicating out a LIS, an IP router must be used -
following the classical IP routing mode. Reference RFC1577 for a full
description of this approach.

For a tutorial/reference, a set of slides by Grenville Armitage presented
at Interop 95 on the rfc1577 model is available online. The URL is:
HTTP://gump.bellcore.com:8000/~gja/interop95/interop95.html

Question: What is a Logical IP Subnet (LIS) and how does it differ from any

Section 1 of 3 - Prev - Next
All sections - 1 - 2 - 3

© allanswers.org | Terms of use