Title: MPLS/GMPLS Migration and Interworking
1MPLS/GMPLS Migration and Interworking
- CCAMP, IETF 64
- Kohei Shiomoto, shiomoto.kohei_at_lab.ntt.co.jp
2Discussion hints
- Background reading
- draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.
txt - draft-oki-ccamp-gmpls-ip-interworking-06.txt
- draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt
- Discussion points
- what are we trying to achieve?
- what are the models available?
- do we want to support all of these models?
3Migration Interwork
- What is migration?
- MPLS to GMPLS migration is the process of
evolving MPLS-TE-based control plane to
GMPLS-based control plane. - What is interworking?
- Interworking is just a facilitating function for
migration, not a final objective of migration.
(Migration and interworking are separate goals.) - Interworking is an important technical driver for
a migration model. (will be discussed later)
4Migration models
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.
txt
- Island model
- Replace or upgrade MPLS island(s) to GMPLS
capable. - In between, there is translation.
- GMPLS and MPLS features are not identical, though
similar. - Need to interwork/complement different features
at the border
- Integrated model
- Upgrade MPLS device(s) to speak both MPLS and
GMPLS. - Advanced feature is only via GMPLS-capable nodes.
(No translation too) - Once all devices become GMPLS-capable, the MPLS
protocols may be turned off. - Phased model
- Add GMPLS feature and protocol element into MPLS
devices one at a time. - No GMPLS introduction
Island model
Integrated model
M1
G5
G2
M4
M3
G3
G1
G4
M2
M5
Do we have to support all three models? Any
opinion?
5MPLS-GMPLS interwork cases
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.
txt
- MPLS-GMPLS-MPLS
- GMPLS are either non-PSC or PSC
- GMPLS-MPLS and MPLS-GMPLS
- GMPLS is PSC only.
G1
G3
G1
G3
G2
G2
G5
G5
MPLS
MPLS
GMPLS
GMPLS
G6
G4
G6
G4
- GMPLS-MPLS-GMPLS
- GMPLS is PSC only.
G1
G3
G1
G3
G2
G2
G5
G5
GMPLS
GMPLS
GPLS
MPLS
MPLS
G6
G4
G6
G4
6What models are available? To address Issues in
MGM (non PSC) case
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-00.
txt
- Issues
- Lack of routing and signaling adjacencies
- Control plane resource exhaustion
- TE path computation between MPLS and GMPLS
domains - Models
- Peer, Overlay, Augmented
Overlay/Augmented
Peer
MPLS
Model Visibility of optical domain
Peer Full
Overlay None
Augmented Partial
D-plane
GMPLS
Do we have to support all three models? Any
opinion?
7Protocol interwork issues
- (1) RSVP Objects
- (Generalized) Label Request object (new C-Type
- IF_ID.
- Suggested Label Object
- Label Set Object
- Upstream Label Object
- Restart Cap object
- Admin Status object
- Recovery Label object
- Notify Request object
- (2) Bidirectional LSP setup
- (3) Failure recovery
- (4) Bundling FA-LSP
- (5) Resource affinity mapping
- (6) MPLS/GMPLS LSP Priority Mapping
- (7) Signaling Protected MPLS LSPs
Be selective (is it realistic) or exhaustive (is
it feasible) ? ... any feedback/input ?
8What's next step?
- Framework/Strategy i-d
- Revise draft-shiomoto-ccamp-mpls-gmpls-interwork-f
mwk-00.txt - By merging protocol interworking items etc.(see
page 7) in draft-kumaki-ccamp-mpls-gmpls-interwork
ing-01.txt - Accepted as WG document?
- Evaluation/Applicability i-d
- WG Milestone (CCAMP) February 2006
- Solution i-d
- WG Milestone (CCAMP) February 2006