draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt   draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.txt 
Network Working Group K. Shiomoto(Editor)
Network Working Group Kohei Shiomoto(Editor)
Internet Draft (NTT) Internet Draft (NTT)
Proposed Category: Informational Intended Status: Informational
Expires: February 2008 Created: September 24, 2007
August 2007 Expires: March 24, 2008
Framework for MPLS-TE to GMPLS migration Framework for MPLS-TE to GMPLS migration
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-03.txt draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04.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
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The migration from Multiprotocol Label Switching (MPLS) Traffic The migration from Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) to Generalized MPLS (GMPLS) is the process of Engineering (TE) to Generalized MPLS (GMPLS) is the process of
evolving an MPLS-TE control plane to a GMPLS control plane. An evolving an MPLS-TE control plane to a GMPLS control plane. An
appropriate migration strategy will be selected based on various appropriate migration strategy will be selected based on various
factors including the service provider's network deployment plan, factors including the service provider's network deployment plan,
customer demand, and operational policy. customer demand, and operational policy.
skipping to change at page 2, line 8 skipping to change at page 2, line 5
migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE
and GMPLS devices, or networks, may coexist which may require and GMPLS devices, or networks, may coexist which may require
interworking between MPLS-TE and GMPLS protocols. Aspects of the interworking between MPLS-TE and GMPLS protocols. Aspects of the
interworking required are discussed as it will influence the choice interworking required are discussed as it will influence the choice
of a migration strategy. This framework document provides a migration of a migration strategy. This framework document provides a migration
toolkit to aid the operator in selection of an appropriate strategy. toolkit to aid the operator in selection of an appropriate strategy.
This framework document also lists a set of solutions that may aid in This framework document also lists a set of solutions that may aid in
interworking, and highlights a set of potential issues. interworking, and highlights a set of potential issues.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
Table of Contents Table of Contents
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 Toolkit...............................8 5. Migration Strategies and Toolkit................................ 8
5.1. Migration Toolkit.........................................9 5.1. Migration Toolkit.......................................... 9
5.1.1. Layered Networks.....................................9 5.1.1. Layered Networks...................................... 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 Components. 14
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........................................20 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.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
There are several motivations for such migration, mainly the desire There are several motivations for such migration, mainly the desire
to take advantage of new features and functions added to the GMPLS to take advantage of new features and functions added to the GMPLS
protocols and which are not present in MPLS-TE for packet networks. protocols and which are not present in MPLS-TE for packet networks.
Additionally, before migrating a packet-switching network from MPLS- Additionally, before migrating a packet-switching network from MPLS-
TE to GMPLS, one may choose to first migrate a lower-layer network TE to GMPLS, one may choose to first migrate a lower-layer network
with no control plane (e.g. controlled by a management plane) to with no control plane (e.g. controlled by a management plane) to
using a GMPLS control plane, and this may lead to the desire for using a GMPLS control plane, and this may lead to the desire for
MPLS-TE/GMPLS (transport network) interworking to provide enhanced TE MPLS-TE/GMPLS (transport network) interworking to provide enhanced TE
support and facilitate the later migration of the packet-switching support and facilitate the later migration of the packet-switching
network. network.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS" switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS"
or "non-PSC GMPLS" is explicitly used. or "non-PSC GMPLS" is explicitly used.
In general, the term "MPLS" is used to indicate MPLS traffic In general, the term "MPLS" is used to indicate MPLS traffic
engineering (MPLS-TE) only ([RFC3209], [RFC3630], [RFC3784]) and engineering (MPLS-TE) only ([RFC3209], [RFC3630], [RFC3784]) and
excludes other MPLS protocols such as the Label Distribution Protocol excludes other MPLS protocols such as the Label Distribution Protocol
(LDP). TE functionalities of MPLS could be migrated to GMPLS, but (LDP). TE functionalities of MPLS could be migrated to GMPLS, but
non-TE functionalities could not. If non-TE MPLS is intended, it is non-TE functionalities could not. If non-TE MPLS is intended, it is
explicitly indicated. explicitly indicated.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
The reader is assumed to be familiar with the terminology introduced The reader is assumed to be familiar with the terminology introduced
in [RFC3945]. in [RFC3945].
3. Motivations for Migration 3. Motivations for Migration
Motivations for migration will vary for different service providers. Motivations for migration will vary for different service providers.
This section is presented to provide background so that the migration This section is presented to provide background so that the migration
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.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
situations described in this document. The interim situations may situations described in this document. The interim situations may
exist for considerable periods of time, but the ultimate objective is exist for considerable periods of time, but the ultimate objective is
not to preserve these situations. For the purposes of this document, not to preserve these situations. For the purposes of this document,
they should be considered as temporary and transitory. they should be considered as temporary and transitory.
4. MPLS to GMPLS Migration Models 4. MPLS to GMPLS Migration Models
Three reference migration models are described below. Multiple Three reference migration models are described below. Multiple
migration models may co-exist in the same network. migration models may co-exist in the same network.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
4.1. Island model 4.1. Island model
In the island model, "islands" of network nodes operating one In the island model, "islands" of network nodes operating one
protocol exist within a "sea" of nodes using the other protocol. protocol exist within a "sea" of nodes using the other protocol.
For example, consider an island of GMPLS-capable nodes (PSC) which is For example, consider an island of GMPLS-capable nodes (PSC) which is
introduced into a legacy MPLS network. Such an island might be introduced into a legacy MPLS network. Such an island might be
composed of newly added GMPLS nodes, or might arise from the upgrade composed of newly added GMPLS nodes, or might arise from the upgrade
of existing nodes that previously operated MPLS protocols. of existing nodes that previously operated MPLS protocols.
The opposite is also quite possible. That is, there is a possibility The opposite is also quite possible. That is, there is a possibility
that an island happens to be MPLS-capable within a GMPLS sea. Such a that an island happens to be MPLS-capable within a GMPLS sea. Such a
situation might arise in the later stages of migration, when all but situation might arise in the later stages of migration, when all but
a few islands of MPLS-capable nodes have been upgraded to GMPLS. a few islands of MPLS-capable nodes have been upgraded to GMPLS.
It is also possible that a lower-layer, manually-provisioned network It is also possible that a lower-layer, manually-provisioned network
(for example, a TDM network) is constructed under an MPLS PSC network. (for example, a TDM network) is constructed under an MPLS PSC
During the process of migrating both networks to GMPLS, the lower- network. During the process of migrating both networks to GMPLS, the
layer network might be migrated first. This would appear as a GMPLS lower-layer network might be migrated first. This would appear as a
island within an MPLS sea. GMPLS island within an MPLS sea.
Lastly, it is possible to consider individual nodes as islands. That Lastly, it is possible to consider individual nodes as islands. That
is, it would be possible to upgrade or insert an individual GMPLS- is, it would be possible to upgrade or insert an individual GMPLS-
capable node within an MPLS network, and to treat that GMPLS node as capable node within an MPLS network, and to treat that GMPLS node as
an island. an island.
Over time, collections of MPLS devices are replaced or upgraded to Over time, collections of MPLS devices are replaced or upgraded to
create new GMPLS islands or to extend existing ones, and distinct create new GMPLS islands or to extend existing ones, and distinct
GMPLS islands may be joined together until the whole network is GMPLS islands may be joined together until the whole network is
GMPLS-capable. GMPLS-capable.
From a migration/interworking point of view, we need to examine how From a migration/interworking point of view, we need to examine how
these islands are positioned and how LSPs connect between the islands. these islands are positioned and how LSPs connect between the
islands.
Four categories of interworking scenarios are considered: (1) MPLS- Four categories of interworking scenarios are considered: (1) MPLS-
GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS. GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS.
In case 1, the interworking behavior is examined based on whether the In case 1, the interworking behavior is examined based on whether the
GMPLS islands are PSC or non-PSC. GMPLS islands are PSC or non-PSC.
Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS
interworking. The model consists of a transit GMPLS island in an MPLS interworking. The model consists of a transit GMPLS island in an MPLS
sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and
G6) are referred to as "island border nodes". If the GMPLS island was G6) are referred to as "island border nodes". If the GMPLS island was
non-PSC, all nodes except the island border nodes in the GMPLS-based non-PSC, all nodes except the island border nodes in the GMPLS-based
transit island (G3 and G4) would be non-PSC devices, i.e., optical transit island (G3 and G4) would be non-PSC devices, i.e., optical
equipment (TDM, LSC, and FSC). equipment (TDM, LSC, and FSC).
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
................. .......................... .................. ................. .......................... ..................
: MPLS : : GMPLS : : MPLS : : MPLS : : GMPLS : : MPLS :
:+---+ +---+ +----+ +---+ +----+ +---+ +---+: :+---+ +---+ +----+ +---+ +----+ +---+ +---+:
:|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |: :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |:
:+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+:
: ________/ : : _______/ | _____ / : : ________/ : : ________/ : : _______/ | _____ / : : ________/ :
: / : : / | / : : / : : / : : / | / : : / :
:+---+ +---+ +----+ +-+-+ +----+ +---+ +---+: :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+:
:|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |: :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |:
:+---+ +---+ +----+ +---+ +----+ +---+ +---+: :+---+ +---+ +----+ +---+ +----+ +---+ +---+:
:................: :........................: :................: :................: :........................: :................:
|<-------------------------------------------------------->| |<-------------------------------------------------------->|
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 [STITCH] (the latter is for only with GMPLS- nesting or stitching [STITCH] (the latter is for only with GMPLS-
PSC) PSC)
skipping to change at page 7, line 5 skipping to change at page 7, line 5
based on a core infrastructure, but has edge nodes (ingress or based on a core infrastructure, but has edge nodes (ingress or
egress) located in islands of different capabilities. egress) located in islands of different capabilities.
In this case, an LSP starts or ends in a GMPLS (PSC) island and In this case, an LSP starts or ends in a GMPLS (PSC) island and
correspondingly ends or starts in an MPLS island. This mode of correspondingly ends or starts in an MPLS island. This mode of
operation can only be addressed using protocol interworking or operation can only be addressed using protocol interworking or
mapping. Figure 2 shows the reference model for this migration mapping. Figure 2 shows the reference model for this migration
scenario. Head-end and tail-end LSR are in distinct control plane scenario. Head-end and tail-end LSR are in distinct control plane
clouds. clouds.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
............................ ............................. ............................ .............................
: MPLS : : GMPLS (PSC) : : MPLS : : GMPLS (PSC) :
:+---+ +---+ +----+ +---+ +---+: :+---+ +---+ +----+ +---+ +---+:
:|R1 |________|R11|_______| G1 |________|G3 |________|G5 |: :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |:
:+---+ +---+ +----+ +-+-+ +---+: :+---+ +---+ +----+ +-+-+ +---+:
: ______/ | _____/ : : ______/ | ______/ : : ______/ | _____/ : : ______/ | ______/ :
: / | / : : / | / : : / | / : : / | / :
:+---+ +---+ +----+ +-+-+ +---+: :+---+ +---+ +----+ +-+-+ +---+:
:|R2 |________|R21|_______| G2 |________|G4 |________|G6 |: :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |:
:+---+ +---+ +----+ +---+ +---+: :+---+ +---+ +----+ +---+ +---+:
:..........................: :...........................: :..........................: :...........................:
|<-------------------------------------------------->| |<-------------------------------------------------->|
e2e LSP e2e LSP
Figure 2 GMPLS-MPLS interworking model. Figure 2 : GMPLS-MPLS interworking model.
It is important to underline that this scenario is also impacted by It is important to underline that this scenario is also impacted by
the directionality of the LSP, and the direction in which the LSP is the directionality of the LSP, and the direction in which the LSP is
established. established.
4.2. Integrated model 4.2. Integrated model
The second migration model involves a more integrated migration The second migration model involves a more integrated migration
strategy. New devices that are capable of operating both MPLS and strategy. New devices that are capable of operating both MPLS and
GMPLS protocols are introduced into the MPLS network. GMPLS protocols are introduced into the MPLS network.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 [TE-NODE-CAPS], it may be routed accordingly and GMPLS-capable nodes [TE-NODE-CAPS], it may be routed accordingly and
can achieve a higher level of functionality by utilizing GMPLS can achieve a higher level of functionality by utilizing GMPLS
features. features.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
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 8, line 41 skipping to change at page 8, line 43
included in the hybrid LSRs. Interworking between a hybrid LSR and an included in the hybrid LSRs. Interworking between a hybrid LSR and an
unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS
LSR as described in the previous sections and puts the unchanged LSR LSR as described in the previous sections and puts the unchanged LSR
in the role of an MPLS LSR. The potential for different hybrids in the role of an MPLS LSR. The potential for different hybrids
within the network will complicate matters considerably. within the network will complicate matters considerably.
5. Migration Strategies and Toolkit 5. Migration Strategies and Toolkit
An appropriate migration strategy is selected by a network operator An appropriate migration strategy is selected by a network operator
based on factors including the service provider's network deployment based on factors including the service provider's network deployment
plan, customer demand, existing network equipment, operational policy, plan, customer demand, existing network equipment, operational
support from its vendors, etc. policy, support from its vendors, etc.
For PSC networks, the migration strategy involves the selection For PSC networks, the migration strategy involves the selection
between the models described in the previous section. The choice will between the models described in the previous section. The choice will
depend upon the final objective (full GMPLS capability, partial depend upon the final objective (full GMPLS capability, partial
upgrade to include specific GMPLS features, or no change to existing upgrade to include specific GMPLS features, or no change to existing
IP/MPLS networks), and upon the immediate objectives (full, phased, IP/MPLS networks), and upon the immediate objectives (full, phased,
or staged upgrade). or staged upgrade).
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
For PSC networks serviced by non-PSC networks, two basic migration For PSC networks serviced by non-PSC networks, two basic migration
strategies can be considered. In the first strategy, the non-PSC strategies can be considered. In the first strategy, the non-PSC
network is made GMPLS-capable, first, and then the PSC network is network is made GMPLS-capable, first, and then the PSC network is
migrated to GMPLS. This might arise when, in order to expand the migrated to GMPLS. This might arise when, in order to expand the
network capacity, GMPLS-based non-PSC sub-networks are introduced network capacity, GMPLS-based non-PSC sub-networks are introduced
into the legacy MPLS-based networks. Subsequently, the legacy MPLS- into the legacy MPLS-based networks. Subsequently, the legacy MPLS-
based PSC network is migrated to be GMPLS-capable as described in the based PSC network is migrated to be GMPLS-capable as described in the
previous paragraph. Finally the entire network, including both PSC previous paragraph. Finally the entire network, including both PSC
and non-PSC nodes, may be controlled by GMPLS. and non-PSC nodes, may be controlled by GMPLS.
skipping to change at page 9, line 46 skipping to change at page 9, line 48
Note that it is possible to consider upgrading the routing and Note that it is possible to consider upgrading the routing and
signaling capabilities of LSRs from MPLS to GMPLS separately. signaling capabilities of LSRs from MPLS to GMPLS separately.
5.1.1. Layered Networks 5.1.1. Layered Networks
In the balanced island model, LSP tunnels [RFC4206] are a solution to In the balanced island model, LSP tunnels [RFC4206] are a solution to
carry the end-to-end LSPs across islands of incompatible nodes. carry the end-to-end LSPs across islands of incompatible nodes.
Network layering is often used to separate domains of different data Network layering is often used to separate domains of different data
plane technology. It can also be used to separate domains of plane technology. It can also be used to separate domains of
different control plane technology (such as MPLS and GMPLS protocols), different control plane technology (such as MPLS and GMPLS
and the solutions developed for multiple data plane technologies can protocols), and the solutions developed for multiple data plane
be usefully applied to this situation [RFC3945], [RFC4206], and technologies can be usefully applied to this situation [RFC3945],
[RFC4726]. [MLN-REQ] gives a discussion of the requirements for [RFC4206], and [RFC4726]. [MLN-REQ] gives a discussion of the
multi-layered networks. requirements for multi-layered networks.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
The GMPLS architecture [RFC3945] identifies three architectural The GMPLS architecture [RFC3945] identifies three architectural
models for supporting multi-layer GMPLS networks, and these models models for supporting multi-layer GMPLS networks, and these models
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
skipping to change at page 11, line 5 skipping to change at page 11, line 5
required as described for the peer model. required as described for the peer model.
- The border peer architecture model is defined in [MPLS-OVER-GMPLS]. - The border peer architecture model is defined in [MPLS-OVER-GMPLS].
This is a modification of the augmented model where the layer This is a modification of the augmented model where the layer
border routers have visibility into both layers, but no routing border routers have visibility into both layers, but no routing
information is otherwise exchanged between routing protocol information is otherwise exchanged between routing protocol
instances. This architectural model is particularly suited to the instances. This architectural model is particularly suited to the
MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands. MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands.
Signaling interworking is required as described for the peer model. Signaling interworking is required as described for the peer model.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
5.1.2. Routing Interworking 5.1.2. Routing Interworking
Migration strategies may necessitate some interworking between MPLS Migration strategies may necessitate some interworking between MPLS
and GMPLS routing protocols. GMPLS extends the TE information and GMPLS routing protocols. GMPLS extends the TE information
advertised by the IGPs to include non-PSC information and extended advertised by the IGPs to include non-PSC information and extended
PSC information. Because the GMPLS information is provided as PSC information. Because the GMPLS information is provided as
additional TLVs that are carried along with the MPLS information, additional TLVs that are carried along with the MPLS information,
MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS
PSC LSRs. They will also see other GMPLS information, but will ignore PSC LSRs. They will also see other GMPLS information, but will ignore
it, flooding it transparently across the MPLS network for use by it, flooding it transparently across the MPLS network for use by
skipping to change at page 12, line 4 skipping to change at page 12, line 4
GMPLS nodes. If this issue is addressed, then direct distribution GMPLS nodes. If this issue is addressed, then direct distribution
can be used in all migration models (except the overlay and border can be used in all migration models (except the overlay and border
peer architectural models where the problem does not arise). peer architectural models where the problem does not arise).
- Protocol mapping converts routing advertisements so that they can - Protocol mapping converts routing advertisements so that they can
be received in one protocol and transmitted in the other. For be received in one protocol and transmitted in the other. For
example, a GMPLS routing advertisement could have all of its example, a GMPLS routing advertisement could have all of its
GMPLS-specific information removed and could be flooded as an MPLS GMPLS-specific information removed and could be flooded as an MPLS
advertisement. This mode of interworking would require careful advertisement. This mode of interworking would require careful
standardization of the correct behavior especially where an MPLS standardization of the correct behavior especially where an MPLS
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
advertisement requires default values of GMPLS-specific fields to advertisement requires default values of GMPLS-specific fields to
be generated before the advertisement can be flooded further. be generated before the advertisement can be flooded further.
There is also considerable risk of confusion in closely meshed There is also considerable risk of confusion in closely meshed
networks where many LSRs have MPLS and GMPLS capable interfaces. networks where many LSRs have MPLS and GMPLS capable interfaces.
This option for routing interworking during migration is NOT This option for routing interworking during migration is NOT
RECOMMENDED for any migration model. Note that converting GMPLS- RECOMMENDED for any migration model. Note that converting GMPLS-
specific sub-TLVs to MPLS-specific ones but not stripping the specific sub-TLVs to MPLS-specific ones but not stripping the
GMPLS-specific ones is considered as a variant of the proposed GMPLS-specific ones is considered as a variant of the proposed
solution in the previous bullet (Unknown sub-TLVs should be solution in the previous bullet (Unknown sub-TLVs should be
ignored [RFC3630] but must continue to be flooded). ignored [RFC3630] but must continue to be flooded).
skipping to change at page 13, line 4 skipping to change at page 13, line 4
bidirectional 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
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
signaled in the MPLS-GMPLS direction. However, it may be more signaled in the MPLS-GMPLS direction. However, it may be more
complex for LSPs signaled in the opposite direction, and this will complex for LSPs signaled in the opposite direction, and this will
lead to considerable complications for providing GMPLS services lead to considerable complications for providing GMPLS services
over the MPLS island and for terminating those services at an over the MPLS island and for terminating those services at an
egress LSR that is not GMPLS-capable. Further, in balanced island egress LSR that is not GMPLS-capable. Further, in balanced island
models, and in particular where there are multiple small models, and in particular where there are multiple small
(individual node) islands, the repeated conversion of signaling (individual node) islands, the repeated conversion of signaling
parameters may lead to loss of information (and functionality) or parameters may lead to loss of information (and functionality) or
mis-requests. mis-requests.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
moment of changeover between different levels of protocol support. moment of changeover between different levels of protocol support.
Such a change may be made without service halt or during a period of Such a change may be made without service halt or during a period of
network maintenance. network maintenance.
Where island boundaries exist, it must be possible to manage the Where island boundaries exist, it must be possible to manage the
relationships between protocols and to indicate which interfaces relationships between protocols and to indicate which interfaces
support which protocols on a border LSR. Further, island borders are support which protocols on a border LSR. Further, island borders are
a natural place to apply policy, and management should allow a natural place to apply policy, and management should allow
configuration of such policies. configuration of such policies.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
6.2. Information and Data Models 6.2. Information and Data Models
No special information or data models are required to support No special information or data models are required to support
migration, but note that migration in the control plane implies migration, but note that migration in the control plane implies
migration from MPLS management tools to GMPLS management tools. migration from MPLS management tools to GMPLS management tools.
During migration, therefore, it may be necessary for LSRs and During migration, therefore, it may be necessary for LSRs and
management applications to support both MPLS and GMPLS management management applications to support both MPLS and GMPLS management
data. data.
The GMPLS MIB modules are designed to allow support of the MPLS The GMPLS MIB modules are designed to allow support of the MPLS
skipping to change at page 15, line 5 skipping to change at page 15, line 5
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
architecture may require the use of protocol tunnels (such as GRE) architecture may require the use of protocol tunnels (such as GRE)
between island border nodes. Such tunnels may impose additional between island border nodes. Such tunnels may impose additional
configuration requirements at the border nodes. configuration requirements at the border nodes.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
6.6. Impact on Network Operation 6.6. Impact on Network Operation
The process of migration is likely to have significant impact on The process of migration is likely to have significant impact on
network operation while migration is in progress. The main objective network operation while migration is in progress. The main objective
of migration planning should be to reduce the impact on network of migration planning should be to reduce the impact on network
operation and on the services perceived by the network users. operation and on the services perceived by the network users.
To this end, planners should consider reducing the number of To this end, planners should consider reducing the number of
migration steps that they perform, and minimizing the number of migration steps that they perform, and minimizing the number of
migration islands that are created. migration islands that are created.
skipping to change at page 16, line 4 skipping to change at page 16, line 4
even though these island boundaries might lie within an IGP area or even though these island boundaries might lie within an IGP area or
AS. AS.
No changes are proposed to the security procedures built into MPLS No changes are proposed to the security procedures built into MPLS
and GMPLS signaling and routing. GMPLS signaling and routing inherit and GMPLS signaling and routing. GMPLS signaling and routing inherit
their security mechanisms from MPLS signaling and routing without any their security mechanisms from MPLS signaling and routing without any
changes. Hence, there will be no additional issues with security in changes. Hence, there will be no additional issues with security in
interworking scenarios. Further, since the MPLS and GMPLS signaling interworking scenarios. Further, since the MPLS and GMPLS signaling
and routing security is provided on a hop-by-hop basis, and since all and routing security is provided on a hop-by-hop basis, and since all
signaling and routing exchanges described in this document for use signaling and routing exchanges described in this document for use
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
between any pair of LSRs are based on either MPLS or GMPLS, there are between any pair of LSRs are based on either MPLS or GMPLS, there are
no changes necessary to the security procedures. no changes necessary to the security procedures.
8. IANA Considerations 8. IANA Considerations
This informational framework document makes no requests for IANA This informational framework document makes no requests for IANA
action. action.
9. Acknowledgements 9. Acknowledgements
The authors are grateful to Daisaku Shimazaki for discussion during The authors are grateful to Daisaku Shimazaki for discussion during
initial work on this document. The authors are grateful to Dean Cheng initial work on this document. The authors are grateful to Dean Cheng
and Adrian Farrel for their valuable comments. and Adrian Farrel for their valuable comments.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
10. Editor's Addresses 10. Editor's Addresses
Kohei Shiomoto, Editor Kohei Shiomoto, Editor
NTT NTT
Midori 3-9-11 Midori 3-9-11
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
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
skipping to change at page 18, line 7 skipping to change at page 18, line 4
Zafar Alli Zafar Alli
Cisco Systems, Inc. Cisco Systems, Inc.
EMail: zali@cisco.com EMail: zali@cisco.com
Eiji Oki Eiji Oki
NTT NTT
Midori 3-9-11 Midori 3-9-11
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
Phone: +81 422 59 3441 Phone: +81 422 59 3441
Email: oki.eiji@lab.ntt.co.jp Email: oki.eiji@lab.ntt.co.jp
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
Ichiro Inoue Ichiro Inoue
NTT NTT
Midori 3-9-11 Midori 3-9-11
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
Phone: +81 422 59 3441 Phone: +81 422 59 3441
Email: inoue.ichiro.lab.ntt.co.jp Email: inoue.ichiro@lab.ntt.co.jp
Tomohiro Otani Tomohiro Otani
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
skipping to change at page 18, line 45 skipping to change at page 18, line 43
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630, September
2003. 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. 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 Atlas, A., "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4872] 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",
RFC4872, May 2007. RFC4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
"GMPLS Based Segment Recovery", RFC 4873, May 2007. "GMPLS Based Segment Recovery", RFC 4873, May 2007.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 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
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
skipping to change at page 20, line 13 skipping to change at page 20, line 5
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-04 September 2007
14. Intellectual Property 14. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 33 change blocks. 
59 lines changed or deleted 93 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/