60 likes | 221 Views
Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt. CCAMP WG, IETF 66 July 9-14, 2006 Kohei Shiomoto (NTT) Dimitri Papadimitriou (Alcatel) Jean-Louis Le Roux (France Telecom) Deborah Brungard (AT&T)
E N D
Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migrationdraft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt CCAMP WG, IETF 66 July 9-14, 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) 66th IETF Montreal July 2006
Scope of this document • Framework for MPLS and GMPLS interworking in support of migration from MPLS to GMPLS. • Issues, models, migration scenarios, operation and requirements. • Interworking scenarios that arise during migration. • Implications for network deployments and for protocol usage. 66th IETF Montreal July 2006
Status • Became WG document • Covered • Framework for MPLS and GMPLS interworking in support of migration from MPLS to GMPLS. • Issues, models, migration scenarios, operation and requirements. • Interworking scenarios that arise during migration. • Implications for network deployments and for protocol usage. (More work need to be done) 66th IETF Montreal July 2006
Work plan • Ensure that it covers all necessary models. • Elaborate how to handle signaling objects and routing TLVs. 66th IETF Montreal July 2006
New Objects Generalized Label object Upstream Label object Restart Cap object Admin Status object Recovery Label object Notify Request object IF_ID object Suggested Label object Label Set object Others (ex. P&R) Fundamental issue LABEL and GENERALIZED_LABEL Upstream_Label for bi-directionality Some objects may be useful to add advanced features in MPLS. Some objects may be unnecessary in MPLS. Some MPLS mechanisms may be useful in GMPLS (ex. p2mp) Signaling issues 66th IETF Montreal July 2006
New sub-TLVs Link Local/Remote Identifiers Link Protection Type Interface Switching Capability Descriptor Shared Risk Link Group Unknown TLVs can be ignored by a router, but must be forwarded when the LSA is flooded. MPLS LSRs may use the MPLS part of the LSA but will not understand the GMPLS part (e.g., ISCD) to compute a path. MPLS LSRs may treat GMPLS non-PSC LSRs as though they were PSC LSRs, which may result in an incorrect path computation. GMPLS non-PSC LSR should populate adequate MPLS part of the LSA, which it originates, to avoid such mis-compuration. Routing issues 66th IETF Montreal July 2006