Transcript PPT Version

GMPLS Inter-domain Traffic
Engineering Requirements
draft-otani-ccamp-interas-gmpls-te-04.txt
Tomohiro Otani [email protected]
Kenji Kumaki [email protected]
Satoru Okamoto [email protected]
Wataru Imajuku [email protected]
66th IETF Montreal, July 2006
Background of this draft
• 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
Based on GMPLS constrains
LSC
LSC
LSC
GMPLS domain 2
LSC
LSC/SONET/2.5G
LSC
LSC
LSC
LSC
LSC
LSC
LSC
LSC
Ingress
(2.5G SONET LSP)
domain 1’s view
LSC/SONET/10G
Shortest path
AS boarder nodes
Egress
• 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
determined by
SPs’ business
strategy
so as to appropriately establish a GMPLS LSP across multiple domains,
while keeping the topology information concealing.
– Applicable and beneficial to L1-VPN operation
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 endpoint (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