1 / 22

NIG-G3 : IP and ATM Coexistence Guideline Version 2.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 Triomphe 1050 Brussels, Belgium e-mail: mannie@helios.iihe.ac.be tel: +32-2-650.57.17. NIG-G3 mainly produced by (1) :.

hinda
Télécharger la présentation

NIG-G3 : IP and ATM Coexistence Guideline Version 2.1.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Triomphe 1050 Brussels, Belgium e-mail: mannie@helios.iihe.ac.be tel: +32-2-650.57.17

  2. NIG-G3 mainly produced by (1) : MULTICUBE (AC012) Efficient MULTIpoint to MULTIpoint broadband switched network services for distributed MULTImedia applications EXPERT (AC094) Platform for Engineering Research and Trials DIANA (AC319) Demonstration of IP and ATM Networking for real time Applications

  3. NIG-G3 mainly produced by (2) : PETERPAN (AC307) Provision of an Enhanced Transport By Exploiting Reservation in IP and ATM Networks IthACI (AC337) Internet and the ATM : Experiments and Enhancements For Convergence and Integration GINA (AC220) Guidelines for Interoperability in Networks and ATM deployment (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: Very simplified views. Application Application Application TCP/IP Transport Transport Transport 2D-Model IP IP IP well- know LANE MPLS Emulation MARS, NHRP,... AAL AAL AAL MPLS ATM 3D-Model ATM ATM ATM physical physical physical Level 1 Level 2 Level 3

  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 : Root Source Version Date Status LANE 1.0 ATMF 1.0 Jan, 1995 af-lane-0021 LANE 2.0 ATMF 2.0 July, 1997 al-lane-0084 Classical 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-0087 MPLS IETF - Aug, 1997 internet drafts RSVP 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

  12. Short statistics (29/3/99) : Drafts (±) Publ. (±) WG ION 17 23 MPLS 59 7 DiffServ 23 3 IntServ 5 (7) ISSLL 9 4 RSVP 18 5 LANE 3 6 MPOA 3 2 Total 137 57

  13. Example: LAN Emulation : 1 LECS 2 LES 3 LEC (ES) LEC (bridge) 5 BUS legacy LAN 6 4 LUNI LUNI 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 : Model Unicasting Multicasting Broadcasting LANE yes yes yes Classical yes - - MARS could yes yes NHRP yes - - MPOA yes - - MPLS yes yes - Model Service provided Service required Runs over LANE 802.3/5 services ATM only AAL5 Classical IP only but... ATM only but… AAL5 MARS focus on IP ATM only but… AAL5 NHRP focus on IP NBMA networks AAL5 MPOA internetwork layer ATM only (< LANE) AAL5 MPLS internetwork layer over everything AAL5

  15. Level 1 & 2 : Emulation : Client Server Model Scope LANE ELAN LEC LECS, LES, BUS Classical LIS ATMARP client ATMARP server MARS Cluster MARS client MARS, MCS NHRP LAG NHC NHS MPOA Subnet MPC MPS

  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 existing equipment ? 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. Q.6 Should I use another scenario ? B.1 IP/LANE more powerful IP + LANE B.6 MPOA traffic IP based only more powerful if IP only replace CLIP by NHRP to shortcut B.5 NHRP B.2 Trunking dynamic adr resolution B.3 CLIP to add QOS to add QOS to add multicasting and broadcasting C.3 Trunking + RSVP C.4 Trunking + DiffServ C.1 CLIP+MARS Possible futur replace CLIP by NHRP to shortcut C.2 MARS+NHRP Multicast shortcutting IP only & complete ATM deployment not needed B.9 MPLS

  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 Editor : Piergiorgio Cremonese (p.cremonese@finsiel.it) • 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.

More Related