1

NIG-G3 :IP and ATM Coexistence

Guideline Version 2.1.

Eric Mannie (Editor)

Service Télématique et Communication.Universtité Libre de Bruxelles.

CP 230 Boulevard du Triomphe1050 Brussels, Belgium

e-mail: mannie@helios.iihe.ac.betel: +32-2-650.57.17

2

NIG-G3 mainly produced by (1) :

EXPERT (AC094)Platform for EngineeringResearch and Trials

MULTICUBE (AC012)Efficient MULTIpoint toMULTIpoint broadband switchednetwork services for distributedMULTImedia applications

DIANA (AC319)Demonstration of IP and ATMNetworking for real time Applications

3

NIG-G3 mainly produced by (2) :

IthACI (AC337)Internet and the ATM :Experiments and EnhancementsFor Convergence and Integration

PETERPAN (AC307)Provision of an Enhanced TransportBy Exploiting Reservation in IP andATM Networks

GINA (AC220)Guidelines for Interoperabilityin Networks and ATMdeployment (NIG-G3 editor)

4

Why IP and ATM should coexist?

IP is the network protocol for most applications. The IP technology is leading towards an integrated and/or

differentiated services network supporting realtime multimedia applications.

BUT The IP technology has performance limits and... They are needs for high bandwidth and quality of service.

ATM can be the right solution !

5

IP and ATM Coexistence :

Coexistence is either :• Interworking : interoperation between applications, vertically.

• Integration : support of IP over (within) ATM.

We are not dealing with interworking :• Very difficult, because case by case problem (e.g. SIP - H.310).

• Do not happen very often.

IP and ATM integration :• Level 1 : IP over intermediate layer over ATM (e.g. IP over LANE).

• Level 2 : IP over ATM (e.g. Classical IP, MARS, NHRP, MPOA).

• Level 3 : IP merged with ATM (e.g. MPLS).

6

IP and ATM Integration:

physical

ATM

AAL

LANE

IP

Transport

Application

physical

ATM

AAL

IP

Transport

Application

physical

ATM

IP

Transport

Application

MPLS AAL

Level 1 Level 2 Level 3

MARS, NHRP,...

Very simplified views.

2D-M

odel3D

-Model

AT

MT

CP/

IP

well-know

Em

ulat

ion

MPLS

7

Guideline current objectives :

Simple, free of jargon, short document. Clarify IP and ATM integration. Consider both IPv4 and IPv6 (IPng). One specific target: Technology Strategists. Thirteen scenarios considered. Try to answer to ten basic questions :

= 130 key messages or impacts.

8

Guideline target :Technology Strategists

« They use their understanding of the capabilities of the various technologies available to help business strategists and end-users come to a commercial decision. »

Business Strategists :These are commercial management and marketing decision makers within equipment and software manufacturers and suppliers, network and service providers, and large end-users.

End Users :These include both purchasing decision makers within large companies as well as SMEs and individual residential users.

represent horizontal field of expertise or competence.

9

Thirteen scenarios (1) :

Basic scenarios or technologies: Level 1 : IP over an intermediate layer over ATM :

B.1. Use of IP over LAN Emulation (over ATM). Level 2 : IP “directly” over ATM :

B.2. Trunking of IP systems over ATM. B.3. Use of Classical IP. B.4. Use of MARS. B.5. Use of NHRP. B.6. Use of MPOA. B.7. Use of RSVP over ATM. B.8. Use of Differential Services over ATM.

Level 3: IP merged with ATM : B.9. Use of MPLS.

buidling blocks

10

Thirteen scenarios (2) :

Combination scenarios :

C.1. Use of classical IP with MARS : B.3 + B.4. C.2. Use of NHRP with MARS : B.4 + B.5. C.3. Use of trunking with RSVP : B.2 + B.7. C.4. Use of trunking with Differential Services : B.2 + B.8.

( others are possible)

11

Basic technologies :

LANE 1.0 ATMF 1.0 Jan, 1995 af-lane-0021LANE 2.0 ATMF 2.0 July, 1997 al-lane-0084Classical IP v1 IETF 1 Jan, 1994 rfc1577 (PS)Classical IP v2 IETF 2 April, 1998 rfc2225 (PS)MARS IETF 0 Nov, 1996 rfc2022 (PS)NHRP IETF 1 April, 1998 rfc2332 (PS)MPOA ATMF 1.0 July, 1997 af-lane-0087MPLS IETF - Aug, 1997 internet draftsRSVP IETF 1 Sept, 1997 rfc2205 (PS)IntServ IETF - June, 1994 rfc1633 (info)DiffServ IETF - Dec, 1998 rfc2474,2475,...Trunking IETF - 93-98 rfc1483,1755,2331

Root Source Version Date Status

12

Short statistics (29/3/99) :

ION 17 23MPLS 59 7DiffServ 23 3IntServ 5 (7)ISSLL 9 4RSVP 18 5LANE 3 6MPOA 3 2Total 137 57

WG Drafts (±) Publ. (±)

13

Example: LAN Emulation :

LECS

LES

BUS

LEC(ES)

LEC(bridge)

LUNI LUNI

1

2

3

4

5

6legacyLAN

1. Configuration Direct VCC.2. Control Direct VCC.3. Control Distribute VCC.

4. Data Direct VCC.5. Multicast Send VCC.6. Multicast Forward VCC.

14

Technology comparison :

LANE yes yes yesClassical yes - -MARS could yes yesNHRP yes - -MPOA yes - -MPLS yes yes -

Model Unicasting Multicasting Broadcasting

LANE 802.3/5 services ATM only AAL5Classical IP only but... ATM only but… AAL5MARS focus on IP ATM only but… AAL5NHRP focus on IP NBMA networks AAL5MPOA internetwork layer ATM only (< LANE) AAL5MPLS internetwork layer over everything AAL5

Model Service provided Service required Runs over

15

Level 1 & 2 : Emulation :

LANE ELAN LEC LECS, LES, BUSClassical LIS ATMARP client ATMARP serverMARS Cluster MARS client MARS, MCSNHRP LAG NHC NHSMPOA Subnet MPC MPS

Model Scope Client Server

16

Ten basic questions :Q.1 What is the state of the art in this scenario ?Q.2 What opportunities/threats are there for my business using this

scenario ?Q.3 Will this scenario allow my company to best progress our business ?Q.4 What are the cost/benefits of this scenario ?Q.5 When should I use this scenario ?Q.6 Should I use another scenario ?Q.7 Will the next generation be compatible/interwork with my existing

equipment ?Q.8 What impact (if any) would the next generation Internet Protocol

(IPv6) have on this scenario ?Q.9 Is this technology applicable to support VPNs (Virtual Private

Networks) ?Q.10 What is the scalability of this technology ?

2 NEW questions

17

Example :Scenario B.3 (1).Use of Classical IP over ATM.

Q.1: "What is the state of the art in this scenario?"

This is the first and oldest approach for IP emulation over ATM. Two versions have been defined, [Classical1] and [Classical2]. It is restricted to unicasting and supports neither multicasting, nor broadcasting. It is a signaling protocol, independent of any QOS concerns.

Q.2: "What opportunities/threats are there for my business using this scenario?"

This scenario allows to simply take advantage of ATM capabilities for IP forwarding, in a multiprotocol environment, while maintaining the usual way of configuring IP networks.

Q.3: "Will this scenario allow my company to best progress our business?"

This scenario should only be considered if no multicast and broadcast facilities have to be provided at the IP level. In that case, this is a very light way to emulate an IP subnet over ATM. It is easily and quickly implemented and may be useful in environments where the computing resources dedicated to network level support are limited.

18

Example :Scenario B.3 (2).Use of Clasical IP over ATM.

Q.4: What are the cost/benefits of this scenario ?

A direct benefit comes from the ability to dynamically configure and manage LIS ’s made of devices located potentially anywhere over an ATM network. Closed user groups may be easily achieved in that way. In a WAN environment, the cost of communication between clients and servers may be a concern, but is reduced in comparison with LANE or MARS.

Q.5: When should I use this scenario ?

To simply emulate a virtual IP subnet over ATM, also known as a Logical IP Subnet (LIS). It supports unicast communication inside a LIS, by allowing two members to establish a direct ATM SVC with any QOS. Intra-LIS multicasting and broadcasting communications are not supported by this scenario.

Q.6: Should I use another scenario ?

Yes, scenario C.1 which uses MARS to support intra-LIS multicasting and broadcasting, in addition to unicasting. Scenario B.5 (NHRP) in order to establish shortcuts between LIS ’s as a total replacement of this scenario.

Q.7: Will the next generation be compatible/interwork with my existingequipment ?

Version 2 is backward compatible with version 1, except that a version 1 client should not wait for a server query to register. Version 2 allows in addition to support redundant servers.

19

Example :Scenario B.3 (3).Use of Clasical IP over ATM.

Q.8: What impact (if any) would the next generation Internet Protocol (IPv6) have on this scenario ?

Under IPv4, an approach was taken to address resolution that depended on the operation of an auxiliary protocol operating at the ‘link layer’ – this began with Ethernet ARP. The ARP protocol was then applied to IPv4 over ATM (Classical IP). However, IPv6 developers opted to migrate away from a link layer specific approach, choosing to combine a number of tasks into a protocol known as Neighbour Discovery. Whilst Neighbour Discovery is intended to be non-specific across a number of link layer technologies, a key assumption made by the protocol is that the link technology underlying a given IP interface is capable of native multicasting. Clearly, without the facilities of a MARS, the Classical IP approach is not capable of supporting IPv6.

Q.9: “Is this technology applicable to support VPNs (Virtual Private Networks)?”

It allows to build VPNs in the same way as LANE does, except that this is restrained to the IP traffic.

Q.10: “What is the scalability of this technology?”

Scalability problems are similar to those encountered with LANE, the number of clients and redundant servers per LIS are determinant. In any case, less ATM SVCs are needed to support the service than with the LANE scenario.

20

more powerful IP+ LANE

Q.6 Should I use another scenario ?

B.1IP/LANE

B.6MPOA

B.5NHRPB.3

CLIP

C.1CLIP+MARS

B.9MPLS

C.3Trunking + RSVP

C.4Trunking + DiffServ

C.2MARS+NHRP

B.2Trunking

more powerfulif IP only replace CLIP by NHRP

to shortcut

dynamic adrresolution

traffic IPbased only

to add multicastingand broadcasting

IP only & completeATM deployment

not needed

to addQOSto add

QOS

replace CLIP by NHRPto shortcut

Multicastshortcutting

Possiblefutur

21

NIG-G3 Final Action Plan :

• Being reviewed (internally and externally).• Final version will be published in May.

Contributions urgently needed :

- TO REVIEW THE GUIDELINE.- to fill questions 9 and 10.

22

Future : NIG-G12Internet and ATM Co-existence Trials

• Start Date : 3/3/99.• Identify sample target recipient : 3/3/99.• First draft : 19/5/99.• First review : 10-21/5/99• First public version : 31/8/99.• Review : 23/9/99 (IDC’99).• Second version : 31/10/99.• Endorsement : Globecom (November ‘ 99).• Final Review : December ‘ 99.

Editor : Piergiorgio Cremonese (p.cremonese@finsiel.it)