1. GMPLS Inter-domain Traffic Engineering Requirements draft-otani-ccamp-interas-gmpls-te-04.txt
Tomohiro Otani
Kenji Kumaki
Satoru Okamoto
Wataru Imajuku
66th IETF Montreal, July 2006

2. 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

3. 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

4. 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

5. 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

6. 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