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

other subnet?

Answer: RFC1577 is the document which defines LIS, but it doesn't make the
concept as obvious as one might wish, although the info is in there in
section 3.

The short answer is that Logical IP subnets are identical, in all
"protocol" aspects, to conventional LAN etc media subnets. The key aspects
that matter in this context are that ATM-attached systems in the same LIS
have the same network numbers and subnet masks, just as on an Ethernet or
other conventional media. Also, two ATM-attached systems not in the same
LIS cannot communicate via RFC1577 except through a router, even though
they are both attached to the same ATM physical network, with ATM-level
connectivity available (PVC or SVC) between them.

This second limitation was a significant factor in the creation of RFC1577.
The issues of "cut-through routing", or communications between two systems
in different IP subnets on a common ATM network (as well as other
connection-oriented networks) were found to be complex, and there was a
desire to define at least the standard or "Classical" means of running IP
over ATM before all those issues were resolved.

RFC 1932, the IP over ATM: A Framework Document, has more overview info on
these basic issues.

---------------------------------------------------------------------------
SUBJECT D14)

          What is the difference between a PVC, Soft PVC, and SVC?

First lets define the three terms, PVC, Soft PVC, and SVC.

A PVC in the usual meaning is a VC that is not signaled by the end points.
Both of the endpoint (user) VC values are manually provisioned. The
link-by-link route through the network is also manually provisioned. If any
equipment fails, the PVC is down, unless the underlying physical network
(sonet, for example) can re-route below ATM. So a PVC is a VC which is
statically mapped at every point in the ATM network. A failure of any link
that a PVC crosses results in the failure of the PVC.

A Soft PVC also has manually provisioned endpoint (user) VC values (which
as defined above do not change), but the route through the network can be
automatically revised if there is a failure. Historically this feature
pretty much required a single-vendor network. A vendor may employ signaling
(invisibly to the endpoints) within the network, or may just have a
workstation somewhere sending proprietary configuration commands when it
detects a failure. However, the PNNI 1.0 spec defines a standard way of
doing this which does not require a vendor proprietary solution. So a Soft
PVC is a VC that is programmed to be present at all times (like a PVC), but
does not use static routes to determine its path through the ATM network.
Failure of a link causes a Soft PVC to route around the outage and remain
available.

A SVC is established by UNI signalling methods. So an SVC is a demand
connection initiated by the user. If a switch in the path fails, the SVC is
broken and would have to be reconnected.

Summarizing, the difference between a PVC and a Soft PVC is that a Soft PVC
will be automatically rerouted if a switch or link in the path fails. From
that perspective a Soft PVC is considered more robust that a simple PVC.

The difference between a SVC and a Soft PVC is that a SVC is established on
an "as needed" basis through user signalling. With a Soft PVC the called
party cannot drop the connection.

---------------------------------------------------------------------------
SUBJECT D15)

                       ATM Physical Level Questions.

Question:Whats the difference between SONET and SDH?

Answer:SONET and SDH are very close, but with just enough differences that
they don't really interoperate. Probably the major difference between them
is that SONET is based on the STS-1 at 51.84 Mb/s (for efficient carrying
of T3 signals), and SDH is based on the STM-1 at 155.52 Mb/s (for efficient
carrying of E4 signals). As such, the way payloads are mapped into these
respective building blocks differ (which makes sense, given how the
European and North American PDHs differ). Check the September 1993 issue of
IEEE Communications Magazine for an overview article on SONET/SDH.

The following table shows how the US STS and the European STM levels
compare:

US        Europe       Bit Rate (total)

STS-1      --            51.84 Mb/s
STS-3     STM-1         155.52 Mb/s
STS-12    STM-4         622.08 Mb/s
STS-24    STM-8        1244.16 Mb/s
STS-48    STM-16       2488.32 Mb/s
STS-192   STM-64       9953.28 Mb/s

From=20a formatting perspective, however, OC-3/STS-3 !=3D STM-1 even though=
 the
rate is the same. SONET STS-3c (i.e., STS-3 concatenated) is the same as
SDH STM-1, followed by STS-9c =3D STM-3c, etc.

There are other minor differences in overhead bytes (different places,
slightly different functionality, etc), but these shouldn't provide many
problems. By the way, most physical interface chips that support SONET also
include a STM operation mode. Switch vendors which use these devices could
then potentially support STS-3 and STM-1 for example. For anyone
interested, there is an ANSI T1 document which reports on all the
differences between SONET and SDH, and proposals to overcome them.
(Document T1X1.2/93-024R2). It's available at ftp.tele.fi in the directory
/atm/ansi, files sonet-sdh-1.ps and sonet-sdh-2.ps

Question:How does a receiver know where the boundaries between cells are?

Answer: On finding boundaries between cells, called "cell delineation" in
the stds docs: in addition to a Header Error Check scan to search for valid
CRCs, some physical layers cells have a known relationship to the PHY
structure. With some PHY's, the cell's are byte-aligned with the underlying
structure, with others, the alignment may be nibble or even bit (i.e., no
alignment at all). The so-called TAXI phy, now fading towards the sunset,
does use special codes in a 4B/5B encoding to mark beginning of cell, etc,
but it's the exception.

In any case, since with most PHY's, cells are continuously arriving back to
back (idle or unassigned cells are filled in by the transmitter if there is
no data-carrying cell in the slot), it only takes a few cell times to sync
up, and it's not too hard to maintain "cell sync" at the receiver.

Most of the PHY specs are online at the ATM Forum's web site. The first few
PHY (SONET/SDH, DS-3, TAXI) specs were included in the UNI 3.0/3.1 spec;
later ones (and there's a lot of them!) are in their own docs.

---------------------------------------------------------------------------
SUBJECT D16)

                                What is ABR?

The ATM Forum Traffic Management (TM) subworking group has defined an ATM
service type called ABR which stands for Available Bit Rate. Using ABR
traffic is not characterized using peak cell rate, burst tolerance, et.al.,
and bandwidth reseverations are not made. Instead traffic is allowed into
the network throttled by a flow control type mechanism. The idea is to
provide fair sharing of network bandwidth resources.

Competing approaches were intensely studied for quite some time. The debate
included many top folks from industry. Extensive simulation work was done
by (among others) Bellcore, Sandia Labs, NIST and Hughes Network Systems.
Some simulations were done explicitly with TCP/IP traffic sources, although
most used a more generic stochastic model.

The result of all this was the adoption in principle of a "rate-based"
approach known as Enhanced Proportional Rate Control Algorithm (EPRCA). The
term "rate based" means that the paradigm used involves adjustment by the
network of the 'sending rate' of each VC. This is as opposed to a "credit
based" or "windowing" approach, where the network communicates to each
source (VC) the amount of buffer-space available for its use, and the
source refrains from sending unless it knows in advance that the network
has room to buffer the data.

ABR has a Peak Cell Rate, a guaranteed Minimum Cell Rate (per VC), and will
do a fair share of the remaining available bandwidth (the specific
mechanism for determining fair share is left for vendor latitude and
experimentation). So you don't have explicit leaky bucket parameters for
ABR.

Check the ATM Forum "Traffic Management 4.0" specification as well as the
"ABR Addendum" for the complete specification of the ABR service type. The
ATM Forum also had a high level discussion on ABR in the October 1995 issue
of their 53 Bytes publication. Surf their WEB site at:
http://www.atmforum.com/ to access these publications.

There are also several rate-control and flow-control papers in the
March-April 1995 issue of IEEE Network, and in the May 1995 issue of IEEE
Journal on Selected Areas in Communication. Most of the issues were covered
very well.

The essential {CBR, VBR, ABR, UBR} service model itself dates back to Sept
1993 (although those names were not yet attached to the categories, and the
definitions were not explicit):

        Natalie Giroux,
        "Categorization of the ATM Layer QoS and Structure of
        the Traffic Management Work"
        ATM Forum contribution 93-0837, Sept 1993.

Another source of compare/contrast information on ABR and the rate-based
vs. credit-based debate is in IEEE Networks vol. 9 of March/April 1995.
There are three articles concerning The rate-based approach, the
credit-based approach and finally a merge of both of them.

There was also a special issue of Computer Communications Review (April
1995) that covered a lot of the ATM forum work. It contained an excellent
description of the various ABR services as well as an analysis of the ABR
rates at steady state.

---------------------------------------------------------------------------
SUBJECT D17)

                    Questions about VPI/VCI assignment?

Question: With respect to the assignment of VPI/VCIs for an ATM Forum 3.1
or Q.2931 SVC service request, consider two users A and B which will
communicate across a network. Are there really four VPI/VCIs that must be
assigned by the call setup process:

  1. The VPI/VCI A uses to send to B
  2. The VPI/VCI that B will receive from A
  3. The VPI/VCI B uses to send to A
  4. The VPI/VCI that A will receive from B?

Answer: According to the ATM Forum UNI 3.1 specification, User A will
request a VCC via a SETUP message. The Network will either respond with (if
there are no problems) a CALL PROCEEDING message or a CONNECT message. In
either case, it must respond with a Connection Identifier (VPI/VCI) in the
first response to the User (see the section labeled "Connection Identifier
Allocation/Selection -Origination in the ATM Forum UNI specification).

At the Called User side (B), the Network will allocate a Connection
Identifier (VPI/VCI) for the Called user and will be SETUP message sent to
the Called User.

In both cases (according to UNI 3.0/3.1) the Network allocates the VPI/VCI.
Also, the VCC can be bidirectional or unidirectional based on how the VCC
was established.

The rationale is simple: it is always the "network" side of the UNI that
allocates all VCCs for communication on that UNI. It is the master and the
"user" is the slave. Hence, the switch always knows which VCCs are
available for use at the UNI. The range of valid VCCs is setup using ILMI.

Q.2931 allows more flexibility. The initiator of the connection over a UNI
(be it "user" or "network") can effectively specify one of the following:

  1. exclusive VPI, exclusive VCI
  2. exclusive VPI, any VCI
  3. any VPI, any VCI

The other side of the UNI must satisfy the desired choice i.e. if choice A,
it must use the specified VPI/VCI; if choice B, it may use any VCI within
the specified VPI; if choice C, it may use any VPI/VCI.

Due to this flexibility, there is the possibility that the initiator of the
conenction over a UNI chooses a VPI/VCI value that is not available at the
other side. Q.2931 does not allow negotiation so the other side has no
choice but to release the VCC.

---------------------------------------------------------------------------
SUBJECT D18)

         Specs on how Frame Relay frames gets mapped to ATM cells.

There are at least four. One is the mapping defined for Frame Relay/ATM
network interworking as defined in Version 1.1 of the ATM Forum's B-ICI
spec (network interworking allows Frame Relay end users to communicate with
each other over an ATM network). In this case frames are mapped using AAL 5
and the FR-SSCS (Frame Relay specific service-specific convergence
sublayer). Despite the long-winded name, the essentials of the mapping are
quite simple to describe: remove the flags and FCS from a Frame Relay
frame, add the AAL-5 CPCS trailer, and segment the result into ATM cells
using AAL 5 SAR rules. The spec defines additional details such as the
mapping between FECN/BECN/DE in the Frame Relay header and EFCI/CLP bits in
the ATM cell headers.

A second mapping is ATM DXI (data exchange interface) mode 1a. This is not
strictly a Frame Relay to ATM mapping but rather uses an HDLC frame
structure identical to that of Frame Relay frames with a two-byte address
field (i.e. a 10-bit DLCI). The HDLC DXI frame address (called DFA in the
spec) gets stripped off and the 10 bits of the "DLCI" get mapped in a funny
way to the VPI and VCI of the ATM cells. The remainder of the DXI frame
gets an AAL 5 CPCS trailer and is chopped up into cells by standard AAL 5
rules.

A third mapping is used for ATM/Frame Relay service interworking. This
version allows for conversion between the RFC 1490 multiprotocol
encapsulation and the RFC 1483 multiprotocol encapsulation. It uses AAL5
with the RFC 1483 encapsulation within the network. It allows a Frame Relay
user to communicate with a user of a different service (e.g. SMDS/CBDS)
across the ATM network.

A fourth mapping is the FUNI which is completely separate standard ratified
by the ATM Forum. It is an extension of the ATM-DXI standard. However
instead of being a local serial interface, it is extended across the wide
area. For more information reference "From Frames to Cells: Low Speed
Access to ATM" in the May 1995 issue of Data Communications.

---------------------------------------------------------------------------
SUBJECT D19)

                What are the meaning of CBR, VBR, ABR, UBR?

They are service classes defined by ATM forum traffic management group.
Each class is defined as follows:

  1. CBR (constant bit rate)
     The CBR service classs is intended for real-time applications, i.e.
     those requring tightly constrained delay and delay variation, as would
     be appropriate for voice and video applications. The consistent
     availability of a fixed quantity of bandwidth is considered
     appropriate for CBR service. Cells which are delayed beyond the value
     specified by CTD(cell transfer delay) are assumed to be significantly
     less value to the application.

     For CBR, the following ATM attributes are specified:
          PCR/CDVT(peak cell rate/cell delay variation tolerance)
          Cell Loss Rate
          CTD/CDV
          CLR may be unspecified for CLP=3D1.

  2. Real time VBR
     The real time VBR service class is intended for real-time
     applications,i.e., those requring tightly constrained delay and delay
     variation, as would be appropriate for voice and video applications.
     Sources are expected to transmit at a rate which varies with time.
     Equivalently the source can be described "bursty". Cells which are
     delayed beyond the value specified by CTD are assumed to be of
     significantly less value to the application. Real-time VBR service may
     support statistical multiplexing of real-time sources, or may provide
     a consistently guaranteed QoS.

     For real time VBR, the following ATM attributes are specified:
          PCR/CDVT
          CLR
          CTD/CDV
          SCR and BT(sustainable cell rate and burst tolerance)

  3. Non-real time VBR
     The non-real time VBR service class is intended for non-real time
     applications which have 'bursty' traffic characteristics and which can
     be characterized in terms of a GCRA. For those cells which are
     transfered, it expects a bound on the cell transfer delay. Non-real
     time VBR service supports statistical multiplexing of connections.

     For non-real time VBR, the following attributes are supported:
          PCR/CDVT
          CLR
          CTD
          SCR and BT

  4. UBR (unspecified bit rate)
     The UBR service class is intended for delay-tolerant or non-real-time
     applications, i.e., those which do not require tightly constrained
     delay and delay variation, such as traditional computer communications
     applications. Sources are expected to transmit non-continuous bursts
     of cells. UBR service supports a high degree of statistical
     multiplexing among sources. UBR service includes no notion of a per-VC
     allocated bandwidth resource. Transport of cells in UBR service is not
     necessarily guaranteed by mechanisms operating at the cell level.
     However it is expected that resources will be provisioned for UBR
     service in such a way as to make it usable for some set of
     applications. UBR service may be considered as interpretation of the
     common term "best effort service".

     For UBR, the following ATM attributes are specified:
          PCR/CDVT

  5. ABR (available bit rate)
     Many applications have the ability to reduce their information
     transfer rate if the network requires them to do so. Likewise, they
     may wish to increase their information transfer rate if there is extra
     bandwidth available within the network. There may not be deterministic
     parameters because the users are willing to live with unreserved
     bandwidth. To support traffic from such sources in an ATM network will
     require facilities different from those for Peak Cell Rate of
     Sustainable Cell Rate traffic. The ABR service is designed to fill
     this need. See section D16 for more ABR information.

See also ATM and Related Acronyms.

Note that the ITU specs have a different names for similar services
classes. Here is a mapping as I understand them:

   * Class A is CBR with accurate timing (eg phone calls)
   * Class B is VBR with timing (eg packetised phone calls)
   * Class C is VBR without accurate timing
   * Class D is connectionless VBR without accurate timing
   * Class X is UBR
   * Class Y is ABR

---------------------------------------------------------------------------
SUBJECT D20)

                       Are VP and VC unidirectional?

This question has been discussed at some length in the past in this group.
Here is one way to look at the situation: each link in the ATM network can
be split into two parts, one in each direction. Each directional sub link
has the entire range of VCCs (pt-pt links can distinguish between
directional data streams). In this context, VCs and VPs can be considered
unidirectional.

However, one always allocates the same VPI/VCI in both directions for a
connection. This may be considered a limitation of the signalling spec or a
simplification.

Nevertheless, there is no constraint that the same bandwidth must be
allocated in both directions. In fact, each direction is an indepndent
traffic stream and has its own traffic parameters and qos. Some connections
may assign the same parameters to both directions if the traffic flows are
symmetrical but this is certainly no requirement.

Irrespective of all the above, implementation wise, VPs and VCs must be
bidirectional and some bandwidth must be allocated in both directions to
order to support OAM flows. Maybe this is hidden from a user but it needs
to be done just the same.

---------------------------------------------------------------------------
SUBJECT D21)

                      M4 ATM Mgmt Interface Questions?

Question: With regard to a carrier ATM network, I recently heard the topic
of an "M4" management interface.

Answer: The ATM Forum Management WG defines "management information flows"
M1 to M5. A management information flow exchanges information between an
ATM management system and a part of a prototypical ATM network. For
instance, the M2 interface defines the information flow between a private
ATM switch and the local private network management system. The management
information flow includes a conceptual view (requirements) and a MIB.
Ideally the MIB can be used by SNMP or CMIP.

The protypical ATM network looks something like this:

ATM Device----Private ATM Net----Public ATM Net----Public ATM Net

Note: it may be more clear to mentally replace the word "public" with
"carrier" in all of this discussion.

The prototypical ATM management system is made up of local private
management systems and public management systems. This combination of
management systems, management flows and MIB's is the start of end to end
ATM network management.

                              M3                M5
            _ Private Mgt Sys<-->Public Mgt Sys<-->Public Mgt Sys
           /          ^                ^                 ^
        M1/         M2|              M4|               M4|
         /            v                v                 v
ATM Device----Private ATM Net----Public ATM Net----Public ATM Net

The management information flows relate to the above network:
     M1 =3D flow between the private management system and the end ATM devi=
ce
     M2 =3D flow between the private management system and the switches
making up the local private ATM net
     M3 =3D the flow between the private management system and the public
management system
     M4 =3D the flow between the switches in the public ATM network and the
public management system
     M5 =3D the flow between two public management systems

So the MIB's and information flows of M4 allow a management system within
your ATM carrier to manage the central office and other carrier ATM
switches of their ATM network.

If you are using their services, you wouldn't have direct access to this
informtion. You would have indirect access to parts of it (read only) via
the M3 interface. For instance, your private management system could query
their public management system to read circuit/path status or counters for
your paths traversing their public network service.

If you were a developer of public-type ATM switches, you would implement
the MIB's associated with M4; plus private MIB extensions. If you were a
management system vendor you might implement M1-3 if you were only interest
ed in private network management; M3-5 if you were interested in the
management of public networks; M1-5 if you managed both.

---------------------------------------------------------------------------
SUBJECT D22)

                            Questions about QOS.

Question: BISUP does not define a corresponding IE or parameter for QoS IE.
For systems adopting only ITU-T series standards there is no problem.
However, for systems adopting other implementation specs., like ATM Forum
UNI v3.1, problems can arise. ATM Forum UNI v3.1 defines 5 kinds of QoS
classes (0~4). When SETUP messages (UNI) are translated into IAM messages
(NNI), the information will be lost.

Answer: When interworking between two types of networks (ATM Forum UNI 3.x
based and ITU based), some information is usually lost. In this case, the
loss is not as significant because there are no universal semantics to QoS
class 1-4. Only QoS class 0 is universally defined as "unspecified" which
basically implies that no qos is associated with the connection. The
specified qos classes 1-4 are network specified i.e. each network provider
can assign his own semantics to each class. In this situation, interworking
even between two ATMF UNI 3.x networks that use different semantics for
specified qos classes, will require proprietary translation techniques.
Therefore, the use of qos classes 1-4 is not widespread.

Question: Different sources of the same type like VBR may have distinct
QoS. Is 5 kinds of QoS class enough to calssify all QoS?

Answer: The use of qos classes is being deprecated. Unfortunately, the
parameterized qos did not make it to UNI 4.0, but it will appear in an
addendum soon.

Question: If a user claims the QoS class is one of VBR services but it
provides the PCR parameter only, does CAC treat it as a CBR service or not?

Answer: Currently, qos classes 1-4 are not specified. Not only that, but
the bearer capability is seldom used to determine traffic type. It is the
ATM traffic descriptor IE that generally determines traffic type.
Nevertheless, the UNI spec specifies some allowable combinations of bearer
capability and traffic descriptor (see table F-1, UNI 3.1). For example,
the user may specify bearer class X with traffic type VBR and timing
indication set to none (this would specify non-real time VBR) and may only
specify PCR for CLP=3D0 and CLP=3D0+1. This is a legal combination. How the
switch CAC allocates resources for such a connection is not specified.

Question: Do we need fairness between CBR/VBR and the ABR service classes?
I've grasped the feeling that first the guaranteed QoS traffic class i.e.
CBRs and VBRs are to be serviced and iff no cells are found belonging to
these classes, ABR class traffic is to be serviced. But if this is the
case, then ABR class may feel starved of servicing and hence lead to
excessive delays, degradation in QoS and can lead to excessive traffic
submission because of retransmission of packets at higher layers. I don't
know whether my assumptions are right or wrong, please clarify.

Answer: There are in fact two assumptions that relate to this scenario,
they are the Call Admission Control (CAC) policy that established the
connections, be they CBR, VBR, whatever, in the first place, and the
policing algorithm at the network (or switch ingress).

The cells traveling in the CBR QoS class were designated as CBR at
connection setup time because either the application would not operate
satisfactorily otherwise (e.g., high quality voice traffic, circuit
emulation, ...) or because the user is willing to pay for the consistently
low latency and low cell loss, even for his IP traffic. The resources
(bandwidth, or link cell slots, if you like) are allocated at call setup.
The "owner" of the link has the responsibility to ensure that new CBR calls
are not setup if they would impact the performance of other equally high
priority calls. To make this work, CBR calls must always run at the
designated, agreed-upon rate, otherwise, they are not CBR! The second
assumption, policing, may be used to check that no source is exceeding its
contract, although within a given network this may not be necessary,
practically speaking.

VBR calls are set up about the same way, with the same CAC policies
governing whether to accept new calls, except that a certain tolerance
around the nominal cell rate is accepted to accomodate somewhat bursty
sources. Again, either the application won't work if the bandwidth contract
is not met, or the user will not be getting the service he paid for.

So, the answer is no, we don't really want to promote ABR cells up into the
CBR/VBR queues, because the goal cannot be fairness across traffic classes
if anyone is to get what they paid for in the higher classes. Consider a
sort-of real-world example: if you are using voice-over-ATM across some
future carrier ATM network, and you actually paid a premium (the usual
voice rates) for the call, you don't really care how many people on the
carrier's Internet service (which by the way runs over the same ATM
switches) are trying to reach the WWW hot site of the week, or how much
delay they suffer. If we used this "promote delayed ABR cells to higher
queues" scheme, then the quality of the voice call goes south in proportion
to the popularity of that hot site. [Check out Peter Newman's paper on
Capitalist and Socialist switching (
http://www.ipsilon.com/~pn/papers/datacomm94.html) for a fun treatment of
this concept.]

The key concept is that trying to deal with fairness only at the cell
scheduling level, without considering CAC and policing, leads to
undesireable network behaviours.

Note, however, that fairness amoung multiple VC's running ABR is of
considerable interest. Weighted Fair Queuing is one scheme proposed to
offer some minimum level of service even to lower priorities among a group
of different traffic classes, but the weights are likely to be still a
function of CAC so that the service levels can be guranteed to the top
priorities.

---------------------------------------------------------------------------
SUBJECT D23)

                     Questions about ATM Cell Headers.

Question: Where in the world is the EFCI bit?

Answer: The EFCI bit is in the cell header. Check out the definition of the
PTI field. In essence, the 2nd bit of the PTI is the EFCI bit when the 1st
bit indicates that this is a user cell. PTI mappings:


     PTI                     Meaning

     000  User cell, no congestion encountered, user-to-user indication =3D=
 0
     001  User cell, no congestion encountered, user-to-user indication =3D=
 1
     010  User cell, congestion encountered, user-to-user indication =3D 0
     011  User cell, congestion encountered, user-to-user indication =3D 1
     100  OAM segment associated cell
     101  OAM end-to-end associated cell
     110  Resource management cell
     111  Reserved for future use

---------------------------------------------------------------------------
SUBJECT D24)

                               What is MPOA?

The ATM Forum's Multiprotocol Over ATM (MPOA) subworking group is
developing an approach to support seamless transport of layer 3 protocols
across ATM networks. Layer 3 protocols meaning things like IP and IPX.
MPOA, operating at layer 2 and 3, will use the ATM Forum LAN Emulation
(LANE) for its layer 2 forwarding. As such, MPOA can be seen as an
evolution beyond LANE.

LANE basically connects together a single legacy LAN subnet across ATM.
MPOA will take this further by allowing direct ATM connectivity between
hosts in different subnets.

The proposed architecture consists of edge devices and route servers. An
edge device (not necessarily user equipment) would forward packets between
the LAN and ATM networks, establishing ATM connections when needed, but
would not be involved directly in routing. Edge devices would query a Route
Server when an unknown host address is encountered. Route Servers would be
able to map a host address into the information needed by the edge device
to establish a connection across the ATM network. That would be the layer 3
address of the optimal exit point from the ATM network as well as the ATM
address of that exit point. Route servers would also be able to forward
packets on to the exit point on behalf of the edge device while they are
establishing their own ATM virtual circuits. (This last part is LANE.)

Some folks will notice that the Route Server address mapping function is
basically the same problem that the Next Hop Resolution Protocol (NHRP) is
addressing.

---------------------------------------------------------------------------
SUBJECT D25)

              Partial/Early Packet Discard (PPD/EPD) Questions

Question: What is PPD and EPD?

Answer: PPD stands for Partial Packet Discard and EPD stands for Early
Packet Discard. These two are actually ATM cell discard techniques which
maximize "goodput" by taking advantage of the notion that some types of ATM
traffic are made up of large packets that are segmented into a series (or
burst) of ATM/AAL5 cells. This notion holds true for classic IP over ATM
and for LAN emulation (LANE).

These mechanisms work in concert with traffic policing. In a way they are
cleaning up after QoS decisions have been made. If some cells which are
part of a larger packet, are dropped for some reason, then why bother
sending the other cells that were a part of the same fragmented packet
since that entire packet will have to be retransmitted anyway. The act of

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

© allanswers.org | Terms of use