ATM BASICS - Chapter 7 doc

According to this model, ATM can be used at the following interfaces: •The V interface that connects the Core Network and Access NodeAN.. The Access Node serves as an ATM layer multiplex

Chapter 7

How is ATM Changing

This chapter discusses the evolution of ATM concepts A special notice is

given to physical interfaces, QoS categories and evolution of methods for

ATM and IP interworking The chapter helps to understand the implications

of radical changes that take place at the global market nowadays Some

future trends for ATM evolution are also presented

ATM has evolved over a number of years reflecting the changes in

technolo-gies and customer demands This evolution involved the development of new

concepts but it also complemented initial ideas It is very difficult to briefly

present all the changes that ATM observed within last 13 years However,

it is possible to identify major categories in which the changes were the most

significant:

•Physical interfaces With the time passing by, a number of new

interfaces have been standardized The key factor was obviously the need

for ensuring high scalability and flexibility of ATM solutions The new

inter-faces were introduced along with technological achievements, especially in

the domain of optical transmission Hence, the transmission speed has

evolved from 155,52 Mbps initially up to 1Gbps At the same time, with

regards to market needs a number of low speed interface specifications were

released They include for instance: transmission with the speed of 25,6

Mbps over UTP, ATM over Fractional Links, Inverse Multiplexing For ATM,

Frame-based ATM Interface

•Signaling and routing protocols Initially, ATM allowed only for

the use of permanent virtual connections (PVCs) With the introduction ofUNI 3.0 it became possible to establish switched connections (VCs) Thisimplied the need to define signaling protocols for the use within ATM net-works Hence, the protocols such as IISP and next PNNI were designed.Finally, to allow for network interworking there was a need for appropriateprotocols such as BICI and AINI

•Traffic management This category covers all the QoS related

issues With the time passing by and changing requirements a few new QoScategories (service classes) have added Additionally, some TM mechanismshave been revised and updated

•Interworking with other technologies It has to be noted that

has clearly defined rules for interworking with almost any other sion and networking state-of-the-art technologies One can enumerate hereconcepts such as ATM and IP interworking, LAN Emulation, ATM and FRinterworking

transmis-•ATM applications and services Although ATM has been

designed to serve for data, voice and video applications, initially data mission was the application of highest interest, mostly due to the techno-logical and marketing issues A few years’ later standards describing bothvoice (e.g Circuit Emulation Services) and video (Video on Demand) werecompleted and released Today the work in this area is concentrated on thevoice transmission with the use of AAL2

trans-Some developments in the three of those areas will be discussed in moredetails The strength of ATM is related to its flexibility and scalability Andthis is why, that even today, there are still ongoing efforts to make ATMtechnology ‘friendly’ and open to new and innovative concepts This processcan clearly noticed with regards to ATM and MPLS interworking

7.1 Inverse Multiplexing for ATM

As it was stated earlier, ATM has become today an important technology in

some access networks, especially where bandwidth and QOS are the critical

factors The variety of interfaces has been actually limited to the E1/DS1

and E3/DS3 The similar situation was relevant to Frame Relay users for

frame relay users who wanted bandwidth between T1 and T3 In addition to

that a rapid growth of mobile telephony networks stimulated the market

need for solutions capable of provisioning bandwidth at the level of several

Mbps in a cost efficient way

In order to face these challenge, a new concept called Inverse Multiplexing

for ATM has been invented The idea of IMA actually goes far beyond the

definition of the physical interface The major purpose of IMA is to provide

inverse multiplexing of an ATM cell stream over multiple physical links so

that the effective capacity observed by the ATM layer is the multiplication

of the single link capacity At the far end of these physical links IMA

retrieves the original stream without breaking the sequencing of cells The

IMA model is given in Fig 7-1

Chapter 7

This specification is offered for private and public interfaces IMA defines anew sublayer located between the TC sublayer and the ATM layer: the IMAsublayer This specification also defines some modifications to the TC sub-layer on which the IMA sublayer is implemented What are the key benefits

of implementing IMA? First of all, the ability to ‘construct ’ a physical link

of desired capacity out of low speed links This allows for filling the gapbetween E1/DS1 and E3/DS3 interfaces

IMA involves inverse multiplexing and de-multiplexing of ATM cells in acyclical fashion among links grouped to form a higher bandwidth logical linkwhose rate is approximately the sum of the link rates This entity is referred

to as an IMA group IMA groups terminate at each end of the IMA virtuallink In the transmit direction, the ATM cell stream At the transmittingside, incoming cells are distributed on cell by cell basis over a number oflinks within the IMA group At the receiving side, the IMA software recon-structs the cell order and passes cells to the ATM layer IMA uses the con-cept of IMA frames, which are signaled with the help of control cells calledICP (IMA Control Protocol) cells

Needless to say, IMA ahs attracted the attention of many operators Thissolution has been widely implemented in ATM devices in recent years

7.2 ATM over ADSL

ATM has been widely implemented in the access networks that use ADSLtechnology The exact model for the use of ATM in ADSL network architec-tures is described in the ‘ATM over ADSL Recommendation’ issued by theAsymmetric Digital Subscriber Line Forum in 1999 The reference model forATM over ADSL is given in the Fig 7-2 According to this model, ATM can

be used at the following interfaces:

•The V interface that connects the Core Network and Access Node(AN) The Access Node serves as an ATM layer multiplexer/concentratorbetween the Core Network and the Access Network In the downstreamdirection it may perform routing and demultiplexing, while in the upstreamdirection it may perform multiplexing and concentration and higher layerfunctions

•The U interface that connects individual interfaces in the remote

Broadband Network Termination (B-NT) T to the corresponding interfaces

in the Access Node The B-NT is a functional block that performs the

func-tions of terminating the ADSL signal which enters the user’s premises via

the twisted pair cable and providing either the T, S, or R interface towards

the Terminal Equipment (TE)

Chapter 7

Fig 7-2, The reference model for ATM over ADSL

For the transport of ATM on modems compliant with the ADSL PHYRecommendations, channels, which are in fact Virtual Paths and/or VirtualChannels, shall be independently set to any bit rate that is an integer mul-tiple of 32 kbps The upper limit, a maximum aggregate capacity, can bedetermined at the start-up phase The bit rates for each channel can be setindependently for the upstream and downstream direction

7.2 Evolution of QoS service classes

7.2.1 GFR

Originally all the best-effort traffic, including transmission of IP packets,has been assigned to the UBR QoS category However, the handling of UBRtraffic in ATM networks imposes certain disadvantages for some applica-tions To overcome these limitations ATM Forum defined the GuaranteedFrame Rate (GFR) QoS category The GFR service category is intended tosupport non-real-time applications generating large portions of data andmay require better than best effort It is designed for applications that mayrequire a minimum rate guarantee and can benefit from accessing addition-

al bandwidth dynamically available in the network From this point of view,GFR is similar to the ABR concept but it does not require adherence to aflow control protocol The service guarantee is based on AAL-5 PDUs, herereferred to as frames to and, under congestion conditions, the networkattempts to discard complete frames instead of discarding cells without ref-erence to frame boundaries This approach may increasingly improve theperformance observed by some of the ATM applications The GFR categoryprovides the user with a Minimum Cell Rate (MCR) guarantee under theassumption of a given maximum frame size (MFS) and a given MaximumBurst Size (MBS) The user may always send cells at a rate up to PCR, butthe network only promises to carry cells in complete frames at MCR (simi-larly to cells in ABR service category) Traffic in excess of MCR and MBSwill be The user can send frames either unmarked or marked by setting upthe CLP bit An unmarked frame is one in which all cells have CLP=0 Amarked frame is one in which all cells have CLP = 1 Such a frame has lowerpriority The CLP must be the same for all cells in a frame By sending a

frame marked, the user indicates to the network that such a frame is of

less-er importance than an unmarked frame As oppose to the ABR model, the

GFR service category does not give to the users explicit feedback regarding

the current level of network congestion Note that GFR service category

only applies to virtual channel connections, because frame delineation is not

generally visible in a virtual path connection

The GFR mechanisms allow users to expect a minimum service rate when

the network is congested, while being able to send at a higher rate when

additional resources are available However, this can be achieved without he

complex rate-based congestion control deployed in case of the ABR service

category

7.2.2 Differentiated-UBR

QoS has become in recent years an important issue not only within ATM

networks It has become increasingly common for technologies that

tradi-tionally offered only best effort service (e.g., Ethernet, IP) to incorporate

ser-vice differentiation mechanisms In fact, two different models for

provision-ing of QoS at the IP level were designed and tested The first model is called

the IntServ (Integrated Services) assumes identification of single flows and

separate reservation of network resources for every flow The model has

been in use several years but its deployment is constrained due to the

sig-naling load it can introduce in certain parts of an IP network The second

model is called DiffServ and is based on the opposite approach DiffServ

classifies the traffic at the edge of an IP network, according to the SLA

con-ditions and applies adequate treatment to every IP packet transported

with-in an IP network The packets are assigned to a number of specific classes

called Behavior Aggregates, which implies the way they are handled within

the network The QoS is provided by means of appropriate queuing

tech-niques DiffServ is growing in popularity as it also complements

mecha-nisms provided by MPLS Therefore, there is a need to transport IP traffic,

which is already assigned to classes defined by DiffServ What is more

important, the traffic should observe adequate treatment in an ATM

net-work

Chapter 7

In order to optimize the support of differentiated services over ATM, it isdesirable that the UBR service category be extended with similar capabili-ties The Addendum to TM 4.1, issued by ATM Forum defines a mechanism

by which a UBR connection may be associated with one of a set of network

specific Behavior Classes When this mechanism is used, the adaptation

function may assign traffic to a UBR connection, based in part on a mapping

of the higher-layer service classification to the Behavior Class with whichthat UBR connection is associated In result the ATM network is able to dif-ferentiate the treatment of UBR connections based on the Behavior Classwith which each such connection is associated (e.g as the result of DiffServclassification process), for example by governing access to queuing andscheduling resources By coordinating the adaptation function at the edge ofthe ATM network with the behaviors implemented within the network, anoperator can enable consistent service differentiation on end- to-end basis,thus ensuring QoS for the transmitted traffic

7.3 The evolution of methods IP and ATM interworking

Transmission of network layer packets, and especially IP packets, was themost important application in early years of ATM In fact it stimulated thedevelopment of the ATM technology in terms of standards and switchingdevices The combination of high speed offered by ATM switches with traf-fic engineering capabilities were the key factors attracting ISPs and carri-ers

The large number of fundamental differences between ATM and IP makesthe interworking between these two technologies a challenging task Overlast ten years several methods have been proposed and implemented Theevolution path for these methods is given in the Fig 7.3

The first standard, which preserved the classical model of routing, was

introduced by the IETF in 1993 as Classical IP over ATM As a part of this

standard, the LLC Encapsulation technique was proposed to facilitate

transmission of IP packets using AAL 5 and ATM Limitations of the CLIP

model, mostly related to the lack of support for QoS, led to the development

of another standard prepared this time under auspicious of the ATM Forum

LAN Emulation was much better suited for the use in LAN environment

and was designed to enable smooth migration from legacy LANs to

ATM-based architecture For the price of complexity (a few servers needed per

each Emulated LAN) and some configuration effort the end users were given

the ability to built large and flexible VLANs (Virtual LANs) over ATM

infra-structure and benefit from QoS

Chapter 7

Fig 7-3, The evolution path for methods for IP and ATM interworking

Unfortunately, both models preserved the classical model of routing, whichhighly constrained the benefits coming from the use of ATM as the underly-ing technology Hence, further improvements were proposed, namely NextHop Resolution Protocol (NHRP) that was defined by the IETF With theNHRP, directly connected hosts and routers received the ability to resolve

IP addresses of the devices located in other subnetworks In result directVCCs, often called ‘shortcut’ connections, could be established on end-to-endbasis Finally, the Multi Protocol Over ATM (MPOA) combined LANE,NHRP and the concept of a Virtual Router However, the complexity ofMPOA implementations caused that this solution was installed at a rela-tively small scale At the same time, when MPOA was being standardized,

a number of vendors accomplished their works on proprietary solutions.These solutions instead of defining new protocols and implementing moreservers were focused on the hardware aspects of ATM and IP interworking.Four of those solutions laid the basis for the definition of MultiProtocolLabel Switching (MPLS) The development of MPLS standards started in

1997 at the IETF and has not been completely accomplished yet MPLS resents a totally different idea for using ATM equipment as the underlyingtechnology for IP transmission It is important to note that once ATMequipment is used in MPLS network, it doesn’t need to use any ATMaddresses or any ATM signaling MPLS can benefit from the switching capa-bilities of ATM equipment

[3] af-ilmi-0065.000 ILMI 4.0 (ATM Forum, 09/1996)

[4] af-lane-0021.000 LAN Emulation over ATM 1.0 (ATM Forum, 01/95)

[5] af-lane-0084.000 LANE v2.0 LUNI Interface (ATM Forum, 07/97)

[6] af-mpoa-0114.000 Multi-protocol Over ATM Specification, Version 1.1

(ATM Forum, 05/99)

[7] af-pnni-0055.001 Private Network-Network Interface Specification v.1.1

(ATM Forum, 04/2002)

[8] af-sig-0061.001 ATM User Network Interface (UNI) Signalling

Specification version 4.1 (ATM Forum, 04/2002)

[9] af-tm-0121.000 Traffic Management Specification v 4.1 (ATM Forum,

[13] af-vtoa-0078.000 Circuit Emulation Service 2.0 (ATM Forum 01/1997)

[14] af-vtoa-0085.000 rum (DBCES) Dynamic Bandwith Utilization in 64

KBPS Time Slot Trunking Over ATM - Using CES (ATM Forum, 08/1997)

[15] af-vtoa-0113.000 ATM Trunking Using AAL2 for Narrowband Services

[16] af-ra-0104.000 PNNI Augmented Routing (PAR) 1.0 (ATM Forum,01/1999)

[17] af-ra-0105.000 Addressing: User Guide Version 1.0 (ATM Forum,01/1999)

[18] af-ra-0106.000 Addressing: Reference Guide Feb, (ATM Forum,02/1999)

[19] ITU-T G.804 ATM cell mapping into Plesiochronous Digital Hierarchy(PDH)

[20] ITU-T I.357 B-ISDN Semi-Permanent Connection Availability (08/96)[21] ITU-T I.361 B-ISDN ATM layer specification (02/99)

[22] ITU-T I.363.1 B-ISDN ATM Adaptation Layer specification: Type 1AAL (08/96)

[23] ITU-T I.363.2 B-ISDN ATM Adaptation Layer (AAL) type 2 tion (11/2000)

specifica-[24] ITU-T I.363.5 B-ISDN ATM Adaptation Layer specification: Type 5AAL (08/96)

[25] ITU-T I.365.2 B-ISDN ATM Adaptation Layer Sublayers (11/95)[26] ITU-T I.371 Traffic Control and Congestion Control in B-ISDN (08/96)[27] ITU-T I.432 B-ISDN User-Network Interface – Physical LayerSpecification (03/93)

[28] ITU-T I.432.1 B-ISDN user-network interface – physical layer cation: General Characteristics (02/99)

[29] ITU-T I.432.2 B-ISDN user-network interface – physical layer cation: 155 520 kbit/s and 622 080 kbit/s operation (02/99)

[30] ITU-T I.432.3 B-ISDN user-network interface – physical layer cation: 1544 kbit/s and 2048

specifi-[31] ITU-T I.761 Inverse Multiplexing for ATM (IMA) (03/2000)

[32] ITU-T Q.2931 B-ISDN – Digital subscriber signalling system no 2(DSS-2) – User-Network Interface (UNI) Layer 3 specification for basiccall/connection control

[33] D O’Leary, FRF 5 Frame Relay/ATM PVC Network InterworkingImplementation Agreement (Frame Relay Forum, December 1994)

[34] D O’Leary, FRF 8.1 Frame Relay/ATM PVC Service InterworkingImplementation Agreement (Frame Relay Forum, February 2000)

[35] B Coutts, FRF 18 Network-to-Network FR/ATM SVC ServiceInterworking Implementation Agreement (Frame Relay Forum, April 2000)[36] Technical Report TR-017, ATM Over ADSL Recommendation (ADSLForum, March 1999)

[37] M Laubach, ‘IETF RFC 2225 Classical IP and ARP over ATM’, April

1998

[38] D Grossman , ‘IETF RFC 2684 Multiprotocol Encapsulation over ATM

Adaptation Layer 5’, September 1999

[39] RFC 2331 ATM Signalling Support for IP over ATM - UNI Signalling