draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02.txt   draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt 
Network Working Group Kohei Shiomoto(Editor) Network Working Group Kohei Shiomoto(Editor)
Internet Draft (NTT) Internet Draft (NTT)
Proposed Category: Informational Proposed Category: Informational
January 2007 Expires: February 2008
August 2007
Framework for MPLS-TE to GMPLS migration Framework for MPLS-TE to GMPLS migration
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02.txt draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction...................................................2 1. Introduction...................................................2
2. Conventions Used in This Document..............................3 2. Conventions Used in This Document..............................3
3. Motivations for Migration......................................4 3. Motivations for Migration......................................4
4. MPLS to GMPLS Migration Models.................................4 4. MPLS to GMPLS Migration Models.................................4
4.1. Island model..............................................5 4.1. Island model..............................................5
4.1.1. Balanced Islands.....................................6 4.1.1. Balanced Islands.....................................6
4.1.2. Unbalanced Islands...................................6 4.1.2. Unbalanced Islands...................................6
4.2. Integrated model..........................................7 4.2. Integrated model..........................................7
4.3. Phased model..............................................8 4.3. Phased model..............................................8
5. Migration Strategies and Solutions.............................8 5. Migration Strategies and Toolkit...............................8
5.1. Solutions Toolkit.........! ................. 5.1. Migration Toolkit.........................................9
Layered Networks...........................................9 5.1.1. Layered Networks.....................................9
5.1.1.......................................................9
5.1.2. Routing Interworking................................11 5.1.2. Routing Interworking................................11
5.1.3. Signaling Interworking..............................12 5.1.3. Signaling Interworking..............................12
6. Manageability Considerations..................................13 6. Manageability Considerations..................................13
6.1. Control of Function and Policy...........................13 6.1. Control of Function and Policy...........................13
6.2. Information and Data Models..............................14 6.2. Information and Data Models..............................14
6.3. Liveness Detection and Monitoring........................14 6.3. Liveness Detection and Monitoring........................14
6.4. Verifying Correct Operation..............................14 6.4. Verifying Correct Operation..............................14
6.5. Requirements on Other Protocols and Functional Components14 6.5. Requirements on Other Protocols and Functional Components14
6.6. Impact on Network Operation..............................15 6.6. Impact on Network Operation..............................15
6.7. Other Considerations.....................................15 6.7. Other Considerations.....................................15
7. Security Considerations.......................................15 7. Security Considerations.......................................15
8. IANA Considerations...........................................16 8. IANA Considerations...........................................16
9. Acknowledgements..............................................16 9. Acknowledgements..............................................16
10. Editor's Addresses...........................................17 10. Editor's Addresses...........................................17
11. Authors' Addresses...........................................17 11. Authors' Addresses...........................................17
12. References...................................................18 12. References...................................................18
12.1. Normative References....................................18 12.1. Normative References....................................18
12.2. Informative References..................................19 12.2. Informative References..................................19
13. Full Copyright Statement.....................................19 13. Full Copyright Statement.....................................19
14. Intellectual Property........................................19 14. Intellectual Property........................................20
1. Introduction 1. Introduction
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to
Generalized MPLS (GMPLS) migration is the process of evolving an Generalized MPLS (GMPLS) migration is the process of evolving an
MPLS-TE-based control plane to a GMPLS-based control plane. The MPLS-TE-based control plane to a GMPLS-based control plane. The
network under consideration for migration is, therefore, a packet- network under consideration for migration is, therefore, a packet-
switching network. switching network.
There are several motivations for such migration, mainly the desire There are several motivations for such migration, mainly the desire
skipping to change at page 4, line 22 skipping to change at page 4, line 22
discussions may be seen in context. Sections 4 and 5 provide examples discussions may be seen in context. Sections 4 and 5 provide examples
to illustrate the migration models and processes. to illustrate the migration models and processes.
Migration of an MPLS-capable LSR to include GMPLS capabilities may be Migration of an MPLS-capable LSR to include GMPLS capabilities may be
performed for one or more reasons, including, not exhaustively: performed for one or more reasons, including, not exhaustively:
o To add all GMPLS PSC features to an existing MPLS network (upgrade o To add all GMPLS PSC features to an existing MPLS network (upgrade
MPLS LSRs). MPLS LSRs).
o To add specific GMPLS PSC features and operate them within an MPLS o To add specific GMPLS PSC features and operate them within an MPLS
network. network (ex. [RFC4872] [RFC4873]).
o To integrate a new GMPLS PSC network with an existing MPLS network o To integrate a new GMPLS PSC network with an existing MPLS network
(without upgrading any of the MPLS LSRs). (without upgrading any of the MPLS LSRs).
o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs
supporting only GMPLS PSC and/or non-PSC features. supporting only GMPLS PSC and/or non-PSC features.
o To integrate multiple control networks, e.g. managed by separate o To integrate multiple control networks, e.g. managed by separate
administrative organizations, and which independently utilize MPLS administrative organizations, and which independently utilize MPLS
or GMPLS. or GMPLS.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
e2e LSP e2e LSP
Figure 1 Example of the island model for MPLS-GMPLS-MPLS interworking. Figure 1 Example of the island model for MPLS-GMPLS-MPLS interworking.
4.1.1. Balanced Islands 4.1.1. Balanced Islands
In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end
using the same protocols. Possible strategies include: using the same protocols. Possible strategies include:
- tunneling the signaling across the island network using LSP - tunneling the signaling across the island network using LSP
nesting or stitching (the latter is for only with GMPLS-PSC) nesting or stitching [STITCH] (the latter is for only with GMPLS-
PSC)
- protocol interworking or mapping (both are for only with GMPLS- - protocol interworking or mapping (both are for only with GMPLS-
PSC) PSC)
4.1.2. Unbalanced Islands 4.1.2. Unbalanced Islands
As previously discussed, there are two island interworking models As previously discussed, there are two island interworking models
which support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) which support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC)
island cases are likely to arise where the migration strategy is not island cases are likely to arise where the migration strategy is not
based on a core infrastructure, but has edge nodes (ingress or based on a core infrastructure, but has edge nodes (ingress or
skipping to change at page 7, line 46 skipping to change at page 7, line 46
- support MPLS and GMPLS. - support MPLS and GMPLS.
In this model, as existing MPLS devices are upgraded to support both In this model, as existing MPLS devices are upgraded to support both
MPLS and GMPLS, the network continues to operate with a MPLS control MPLS and GMPLS, the network continues to operate with a MPLS control
plane, but some LSRs are also capable of operating with a GMPLS plane, but some LSRs are also capable of operating with a GMPLS
control plane. So, LSPs are provisioned using MPLS protocols where control plane. So, LSPs are provisioned using MPLS protocols where
one end point of a service is a legacy MPLS node and/or where the one end point of a service is a legacy MPLS node and/or where the
selected path between end points traverses a legacy node that is not selected path between end points traverses a legacy node that is not
GMPLS-capable. But where the service can be provided using only GMPLS-capable. But where the service can be provided using only
GMPLS-capable nodes, it may be routed accordingly and can achieve a GMPLS-capable nodes [TE-NODE-CAPS], it may be routed accordingly and
higher level of functionality by utilizing GMPLS features. can achieve a higher level of functionality by utilizing GMPLS
features.
Once all devices in the network are GMPLS-capable, the MPLS specific Once all devices in the network are GMPLS-capable, the MPLS specific
protocol elements may be turned off, and no new devices need to protocol elements may be turned off, and no new devices need to
support these protocol elements. support these protocol elements.
In this model, the questions to be addressed concern the co-existence In this model, the questions to be addressed concern the co-existence
of the two protocol sets within the network. Actual interworking is of the two protocol sets within the network. Actual interworking is
not a concern. not a concern.
4.3. Phased model 4.3. Phased model
skipping to change at page 10, line 17 skipping to change at page 10, line 17
may be applied to the separation of MPLS and GMPLS control plane may be applied to the separation of MPLS and GMPLS control plane
islands. islands.
- In the peer model, both MPLS and GMPLS nodes run the same routing - In the peer model, both MPLS and GMPLS nodes run the same routing
instance, and routing advertisements from within islands of one instance, and routing advertisements from within islands of one
level of protocol support are distributed to the whole network. level of protocol support are distributed to the whole network.
This is achievable only as described in section 5.1.2 either by This is achievable only as described in section 5.1.2 either by
direct distribution or by mapping of parameters. direct distribution or by mapping of parameters.
Signaling in the peer model may result in contiguous LSPs, Signaling in the peer model may result in contiguous LSPs,
stitched LSPs (only for GMPLS PSC), or nested LSPs. If the network stitched LSPs [STITCH] (only for GMPLS PSC), or nested LSPs. If
islands are non-PSC then the techniques of [MLN] may be applied, the network islands are non-PSC then the techniques of [MLN-REQ]
and these techniques may be extrapolated to networks where all may be applied, and these techniques may be extrapolated to
nodes are PSC, but where there is a difference in signaling networks where all nodes are PSC, but where there is a difference
protocols. in signaling protocols.
- The overlay model preserves strict separation of routing - The overlay model preserves strict separation of routing
information between network layers. This is suitable for the information between network layers. This is suitable for the
balanced island model and there is no requirement to handle balanced island model and there is no requirement to handle
routing interworking. Even though the overlay model preserves routing interworking. Even though the overlay model preserves
separation of signaling information between network layers, there separation of signaling information between network layers, there
may be some interaction in signaling between network layers. may be some interaction in signaling between network layers.
The overlay model requires the establishment of control plane The overlay model requires the establishment of control plane
connectivity for the higher layer across the lower layer. connectivity for the higher layer across the lower layer.
skipping to change at page 12, line 30 skipping to change at page 12, line 30
may be appropriate to the integrated migration model. may be appropriate to the integrated migration model.
5.1.3. Signaling Interworking 5.1.3. Signaling Interworking
Signaling protocols are used to establish LSPs and are the principal Signaling protocols are used to establish LSPs and are the principal
concern for interworking during migration. Issues of compatibility concern for interworking during migration. Issues of compatibility
arise because of differences in the encodings and codepoints used by arise because of differences in the encodings and codepoints used by
MPLS and GMPLS signaling, but also because of differences in MPLS and GMPLS signaling, but also because of differences in
functionality provided by MPLS and GMPLS. functionality provided by MPLS and GMPLS.
- Tunneling and stitching (GMPLS-PSC case) mechanisms provide the - Tunneling and stitching [STITCH](GMPLS-PSC case) mechanisms
potential to avoid direct protocol interworking during migration provide the potential to avoid direct protocol interworking during
in the island model, because protocol elements are transported migration in the island model, because protocol elements are
transparently across migration islands without being inspected. transported transparently across migration islands without being
However, care may be needed to achieve functional mapping in these inspected. However, care may be needed to achieve functional
modes of operation since one set of features may need to be mapping in these modes of operation since one set of features may
supported across a network designed to support a different set of need to be supported across a network designed to support a
features. In general, this is easily achieved for the MPLS-GMPLS- different set of features. In general, this is easily achieved for
MPLS model, but may be hard to achieve in the GMPLS-MPLS-GMPLS the MPLS-GMPLS-MPLS model, but may be hard to achieve in the
model. For example, when end-to-end bidirectional LSPs are GMPLS-MPLS-GMPLS model. For example, when end-to-end bidirectional
requested, since the MPLS island does not support bidirectional LSPs are requested, since the MPLS island does not support
LSPs. bidirectional LSPs.
Note that tunneling and stitching are not available in unbalanced Note that tunneling and stitching are not available in unbalanced
island models because in these cases the LSP end points use island models because in these cases the LSP end points use
different protocols. different protocols.
- Protocol mapping is the conversion of signaling messages between - Protocol mapping is the conversion of signaling messages between
MPLS and GMPLS. This mechanism requires careful documentation of MPLS and GMPLS. This mechanism requires careful documentation of
the protocol fields and how they are mapped. This is relatively the protocol fields and how they are mapped. This is relatively
straightforward in the MPLS-GMPLS unbalanced island model for LSPs straightforward in the MPLS-GMPLS unbalanced island model for LSPs
signaled in the MPLS-GMPLS direction. However, it may be more signaled in the MPLS-GMPLS direction. However, it may be more
skipping to change at page 14, line 37 skipping to change at page 14, line 37
connect across GMPLS islands, then requirements for a multi-layer OAM connect across GMPLS islands, then requirements for a multi-layer OAM
technique may be introduced into what was previously defined in the technique may be introduced into what was previously defined in the
flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking
will need further consideration. will need further consideration.
6.4. Verifying Correct Operation 6.4. Verifying Correct Operation
The concerns for verifying correct operation (and in particular The concerns for verifying correct operation (and in particular
correct connectivity) are the same as for liveness detection and correct connectivity) are the same as for liveness detection and
monitoring. Specifically, the process of migration may introduce monitoring. Specifically, the process of migration may introduce
tunneling or stitching into what was previously a flat network. tunneling or stitching [STITCH] into what was previously a flat
network.
6.5. Requirements on Other Protocols and Functional Components 6.5. Requirements on Other Protocols and Functional Components
No particular requirements are introduced on other protocols. As it No particular requirements are introduced on other protocols. As it
has been observed, the management components may need to migrate in has been observed, the management components may need to migrate in
step with the control plane components, but this does not impact the step with the control plane components, but this does not impact the
management protocols, just the data that they carry. management protocols, just the data that they carry.
It should also be observed that providing signaling and routing It should also be observed that providing signaling and routing
connectivity across a migration island in support of a layered connectivity across a migration island in support of a layered
skipping to change at page 17, line 21 skipping to change at page 17, line 21
Phone: +81 422 59 4402 Phone: +81 422 59 4402
Email: shiomoto.kohei@lab.ntt.co.jp Email: shiomoto.kohei@lab.ntt.co.jp
11. Authors' Addresses 11. Authors' Addresses
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellensplein 1, Francis Wellensplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240 8491 Phone: +32 3 240 8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel-lucent.be
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
av Pierre Marzin 22300 av Pierre Marzin 22300
Lannion, France Lannion, France
Phone: +33 2 96 05 30 20 Phone: +33 2 96 05 30 20
Email: jeanlouis.leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Deborah Brungard Deborah Brungard
AT&T AT&T
skipping to change at page 18, line 26 skipping to change at page 18, line 26
KDDI Laboratories KDDI Laboratories
Email: otani@kddilabs.jp Email: otani@kddilabs.jp
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, IETF RFC 2119, March 1997. Requirement Levels," BCP 14, IETF RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
Architecture", RFC 3945, October 2004. Architecture", RFC 3945, October 2004.
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions [RFC4090] Pan, P., Swallow, G. and Atlas, A., "Fast Reroute
to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[E2E-RECOVERY]Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors), [RFC4872] Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors), "
" RSVP-TE Extensions in support of End-to-End Generalized RSVP-TE Extensions in support of End-to-End Generalized
Multi-Protocol Label Switching (GMPLS)-based Recovery", Multi-Protocol Label Switching (GMPLS)-based Recovery",
draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in RFC4872, May 2007.
progress.
[SEGMENT-RECOVERY]Berger, L., "GMPLS Based Segment Recovery", draft- [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
ietf-ccamp-gmpls-segment-recovery, work in progress. "GMPLS Based Segment Recovery", RFC 4873, May 2007.
[TE-NODE-CAPS] Vasseur, Le Roux, editors " IGP Routing Protocol [TE-NODE-CAPS] Vasseur, Le Roux, editors " IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node Extensions for Discovery of Traffic Engineering Node
Capabilities", draft-ietf-ccamp-te-node-cap, work in Capabilities", draft-ietf-ccamp-te-node-cap, work in
progress. progress.
12.2. Informative References 12.2. Informative References
[RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP) [RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
skipping to change at page 19, line 21 skipping to change at page 19, line 34
[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,
M., Brungard, D., "Requirements for GMPLS-based multi- M., Brungard, D., "Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN)", draft-ietf- region and multi-layer networks (MRN/MLN)", draft-ietf-
ccamp-gmpls-mln-reqs, work in progress. ccamp-gmpls-mln-reqs, work in progress.
[STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching [STITCH] Ayyangar, A., Vasseur, JP. "Label Switched Path Stitching
with Generalized MPLS Traffic Engineering", draft-ietf- with Generalized MPLS Traffic Engineering", draft-ietf-
ccamp-lsp-stitching, work in progress. ccamp-lsp-stitching, work in progress.
[RFC4726] Farrel, A., Vasseur, J.P., Ayyangar, A., " A Framework for [RFC4726] Farrel, A., Vasseur, J.P., Ayyangar, A., " A Framework for
Inter-Domain Multiprotocol Label Switching Traffic Engineering", Inter-Domain Multiprotocol Label Switching Traffic
RFC4726, November 2006. Engineering", RFC4726, November 2006.
[MPLS-OVER-GMPLS] Kumaki, K., et al., " Interworking Requirements to [MPLS-OVER-GMPLS] Kumaki, K., et al., " Interworking Requirements to
Support operation of MPLS-TE over GMPLS networks", draft-ietf-ccamp- Support operation of MPLS-TE over GMPLS networks", draft-
mpls-gmpls-interwork-reqts, work in progress. ietf-ccamp-mpls-gmpls-interwork-reqts, work in progress.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 19 change blocks. 
42 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/