GMPLS Inter-domain Traffic Engineering Requirements draft-otani-ccamp-interas-gmpls-te-04.txt Tomohiro Otani otani@kddilabs.jp Kenji Kumaki ke-kumaki@kddi.com Satoru Okamoto okamoto.satoru@lab.ntt.co.jp Wataru Imajuku imajuku.wataru@lab.ntt.co.jp 66th IETF Montreal, July 2006

Background of this draft was created by solving GMPLS inter-domain routing issues and proposed in CCAMP WG. has not yet be adopted so far as a WG document. was asked to include the consideration of L1-VPN support. This draft may fit the charter items. “At this point the WG will address the single-AS scenario only. The multi-AS/provider scenario may be considered in future.” 66th IETF Montreal, July 2006

GMPLS inter-domain TE requirement overview GMPLS domain 1 GMPLS domain 2 Based on GMPLS constrains LSC LSC LSC LSC LSC/SONET/2.5G LSC LSC LSC LSC domain 1’s view LSC/SONET/10G LSC LSC LSC LSC Shortest path Ingress (2.5G SONET LSP) Egress AS boarder nodes Comparing from the MPLS inter-domain network model, the GMPLS inter-domain network model should consider below constrains: Switching capability of nodes: TDM-SC, LSC, FSC Encoding type of TE links: Ethernet, SONET, Lambda, etc. Bandwidth of TE links: 1G, 2.4G, 10G, 40G, etc. SRLG of TE links as well as nodes so as to appropriately establish a GMPLS LSP across multiple domains, while keeping the topology information concealing. Applicable and beneficial to L1-VPN operation determined by SPs’ business strategy 66th IETF Montreal, July 2006

Brief overview of this draft General requirements for GMPLS inter-domain TE signaling, routing and management EGP extensions for GMPLS Requirements for TE parameters in EGP and EGP redistribution GMPLS inter-domain signaling for the support of TE GMPLS per-domain basis/end-to-end path calculation support Fast Recovery support GMPLS inter-domain TE Management Requirements for fault management and TE MIB 66th IETF Montreal, July 2006

TE parameters for GMPLS EGP GMPLS boarder nodes are required to announce an end-point (reachability) list consisting node IDs, interface addresses and interface IDs per below parameters; (1) Interface Switching capability (2) Bandwidth Encoding (3) SRLG (global view) (4) Protection type VPN-associated information may be optionally included as follows (1) VPN identifier (such as VPN IP as specified in RFC2685, or route target) (2) Scope of reachability information exchanged (3) VPN membership information (4) CP-CP arbitrary control plane communication (5) VPN performance related information 66th IETF Montreal, July 2006

Next Steps This draft clearly states the requirements and is stable so far. L1VPN WG started to consider the routing solution to support L1-VPN functionalities within a domain based on EGP (and IGP). This extension is applicable to GMPLS inter-domain TE routing extension. We would like to start TE routing extension work in whether L1VPN WG or CCAMP WG. More discussion and feedback would be greatly appreciated. 66th IETF Montreal, July 2006