Transcript RSVP Path computation request and reply messages

Framework for IP/MPLS-GMPLS interworking in
support of IP/MPLS to GMPLS migration
draft-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
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
1
Changes since Vancouver
• Merged draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt
• Re-organize “6. Interworking issues between MPLS and GMPLS”
6.1. Signaling
6.1.1. New RSVP objects
6.1.2. Bidirectional LSP
6.1.3. Failure recovery
6.3. Layered Networks
6.3.1. Peer Model
6.3.2. Overlay Model
6.3.3. Augmented Model
6.2. Routing
6.2.1. Interworking
6.2.2. Mapping
65th IETF Dallas March 2006
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
2
Interworking issues
• Signaling
• Layered Networks
– New objects
– Bi-directionality
– Failure recovery
• Routing
– Borders
• MPLS-GMPLS
• Packet-Optical
– TED & CSPF
– New sub-TLVs
65th IETF Dallas March 2006
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
3
(same as 00version)
Signaling interwork issues: New objects
• 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
65th IETF Dallas March 2006
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
4
(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
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
5
(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
G1
GMPLS-MPLS
G1
G3
G2
G2
GMPLS
G4 MPLS
G5
G6
G3
GMPLS
GPLS
G4
MPLS
65th IETF Dallas March 2006
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
G5
G6
6
(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
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
7
(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
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
8
(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
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
9
(Added to 01version)
Layered network
• Borders
– Packet-Optical border: overlay, peer, augmented
– MPLS-GMPLS border
cf. GMPLS-UNI
Packet sub-domain
Optical sub-domain
MPLS
LSR
MG-Border
LSR
GMPLS
OXC
GMPLS domain
Packet-Optical Border
MPLS-GMPLS Border
65th IETF Dallas March 2006
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
10
(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
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
11
Next step
• Ask for WG document
65th IETF Dallas March 2006
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
12