1 / 12

Framework for IP/MPLS-GMPLS Interworking

This document outlines a framework to support the migration from IP/MPLS to GMPLS, detailing signaling and routing considerations, as well as interworking issues and potential solutions. It covers new objects, bi-directional LSPs, failure recovery, and layered networks.

teresarutherford
Download Presentation

Framework for IP/MPLS-GMPLS Interworking

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. Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migrationdraft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt CCAMP WG, IETF 65 Mar. 24, 2006 Kohei Shiomoto (NTT) Dimitri Papadimitriou (Alcatel) Jean-Louis Le Roux (France Telecom) Deborah Brungard (AT&T) Kenji Kumaki (KDDI) Eiji Oki (NTT) Ichiro Inoue (NTT) Tomohiro Otani (KDDI) 65th IETF Dallas March 2006

  2. 6.1. Signaling 6.1.1. New RSVP objects 6.1.2. Bidirectional LSP 6.1.3. Failure recovery 6.2. Routing 6.2.1. Interworking 6.2.2. Mapping 6.3. Layered Networks 6.3.1. Peer Model 6.3.2. Overlay Model 6.3.3. Augmented Model Changes since Vancouver • Merged draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt • Re-organize “6. Interworking issues between MPLS and GMPLS” 65th IETF Dallas March 2006

  3. Signaling New objects Bi-directionality Failure recovery Routing New sub-TLVs Layered Networks Borders MPLS-GMPLS Packet-Optical TED & CSPF Interworking issues 65th IETF Dallas March 2006

  4. Generalized Label object IF_ID object Suggested Label object Label Set object Upstream Label object Restart Cap object Admin Status object Recovery Label object Notify Request object (same as 00version) Signaling interwork issues: New objects 65th IETF Dallas March 2006

  5. (Added to 01version) Potential solutions for signaling issues • Direct interworking • Incompatible code points (C-Types) for labels (LABEL_REQUEST and GENERALIZED_LABEL_REQUEST) is a fundamental issue. LSRs can be upgraded to support some GMPLS features but continue to use MPLS code points. • Some features cannot be achieved by a native MPLS network without additional assistance (e.g., bi-directionality). • Some objects can be carried transparently across an MPLS network (11bbbbbb C-Num) but others will be silently dropped or rejected. • Mapping • Mapping for LSPs initiated on MPLS LSRs will be relatively simple (MPLS-GMPLS-MPLS and MPLS-GMPLS). • Mapping for LSPs initiated by a GMPLS LSRs may be relatively hard (GMPLS-MPLS-GMPLS and GMPLS-MPLS). For example bi-directionality. 65th IETF Dallas March 2006

  6. (same as 00version) Signaling interwork issues: Bi-directionality • In GMPLS, the bidirectional LSP can be created: forward and reverse data paths follow the same route. • In MPLS, forward and backward LSPs must be created in different signaling sessions – Coordination between them is required. • GMPLS-MPLS • GMPLS-MPLS-GMPLS G1 G1 G3 G3 G2 G2 G5 G5 GPLS MPLS G6 GMPLS GMPLS MPLS G4 G6 G4 65th IETF Dallas March 2006

  7. (Added to 01version) Routing interwork issue • New sub-TLVs are introduced. • Sub-TLV Type Length Name • 11 8 Link Local/Remote Identifiers • 14 4 Link Protection Type • 15 variable Interface Switching Capability Descriptor • 16 variable Shared Risk Link Group • New sub-TLVs are provided as additional sub-TLVs to the MPLS ones. • MPLS LSRs may use the MPLS part of the LSA to compute a path but will not understand the GMPLS part, ISCD for instance. • MPLS LSRs may treat GMPLS LSRs as though they were PSC LSRs, which may result in an incorrect path computation. 65th IETF Dallas March 2006

  8. (Added to 01version) Potential solutions for routing issues • Routing protocol interwork • Unknown TLVs can be ignored by a router, but must be forwarded when the LSA is flooded. MPLS and GMPLS LSRs may operate as routing peers, and will redistribute each other's TE information. • This is useful for PSC networks. GMPLS LSRs, however, must either modify their computation algorithms or must generate appropriate defaults for GMPLS TE parameters that are not advertised by MPLS LSRs. • Map the LSAs as they cross island borders. • For LSAs coming from GMPLS islands, GMPLS sub-TLVs may be simply discarded, • LSAs by MPLS LSRs could have default GMPLS sub-TLVs added when they are flooded into a GMPLS network. 65th IETF Dallas March 2006

  9. (Clarification) Layered network • Interworking between PSC and non-PSC networks can be regarded as a layered network. A good background and discusses some of the requirements can be found in [MLN-REQ]. • Network layering is often used to separate domains of different data plane technology. It can be used to separate domains of different control plane technology. 65th IETF Dallas March 2006

  10. (Added to 01version) Layered network • Borders • Packet-Optical border: overlay, peer, augmented • MPLS-GMPLS border cf. GMPLS-UNI Packet sub-domain Optical sub-domain GMPLS OXC MG-Border LSR MPLS LSR GMPLS domain Packet-Optical Border MPLS-GMPLS Border 65th IETF Dallas March 2006

  11. (same as 00version) Layered network model • Overlay • Packet and optical are in the separate TED. • Packet and optical are under the separate CSPF engines. • Peer • Packet and optical are in the same TED. • Packet and optical are under the same CSPF in full detail. • Augmented (Border peer) • Packet and optical are in the separate TEDs. • Packet and optical are under the same CSPF in full detail. 65th IETF Dallas March 2006

  12. Next step • Ask for WG document 65th IETF Dallas March 2006

More Related