summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5145.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5145.txt')
-rw-r--r--doc/rfc/rfc5145.txt1067
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5145.txt b/doc/rfc/rfc5145.txt
new file mode 100644
index 0000000..a0f6be2
--- /dev/null
+++ b/doc/rfc/rfc5145.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group K. Shiomoto, Ed.
+Request for Comments: 5145 NTT
+Category: Informational March 2008
+
+
+ Framework for MPLS-TE to GMPLS Migration
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Abstract
+
+ The migration from Multiprotocol Label Switching (MPLS) Traffic
+ Engineering (TE) to Generalized MPLS (GMPLS) is the process of
+ evolving an MPLS-TE control plane to a GMPLS control plane. An
+ appropriate migration strategy will be selected based on various
+ factors including the service provider's network deployment plan,
+ customer demand, and operational policy.
+
+ This document presents several migration models and strategies for
+ migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE
+ and GMPLS devices, or networks, may coexist that may require
+ interworking between MPLS-TE and GMPLS protocols. Aspects of the
+ required interworking are discussed as it will influence the choice
+ of a migration strategy. This framework document provides a
+ migration toolkit to aid the operator in selection of an appropriate
+ strategy.
+
+ This framework document also lists a set of solutions that may aid in
+ interworking, and highlights a set of potential issues.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shiomoto Informational [Page 1]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Conventions Used in This Document ...............................3
+ 3. Motivations for Migration .......................................4
+ 4. MPLS to GMPLS Migration Models ..................................5
+ 4.1. Island Model ...............................................5
+ 4.1.1. Balanced Islands ....................................6
+ 4.1.2. Unbalanced Islands ..................................6
+ 4.2. Integrated Model ...........................................7
+ 4.3. Phased Model ...............................................8
+ 5. Migration Strategies and Toolkit ................................8
+ 5.1. Migration Toolkit ..........................................9
+ 5.1.1. Layered Networks ....................................9
+ 5.1.2. Routing Interworking ...............................11
+ 5.1.3. Signaling Interworking .............................12
+ 5.1.4. Path Computation Element ...........................13
+ 6. Manageability Considerations ...................................13
+ 6.1. Control of Function and Policy ............................13
+ 6.2. Information and Data Models ...............................14
+ 6.3. Liveness Detection and Monitoring .........................14
+ 6.4. Verifying Correct Operation ...............................14
+ 6.5. Requirements on Other Protocols and Functional
+ Components ................................................14
+ 6.6. Impact on Network Operation ...............................15
+ 6.7. Other Considerations ......................................15
+ 7. Security Considerations ........................................15
+ 8. Acknowledgements ...............................................16
+ 9. References .....................................................16
+ 9.1. Normative References ......................................16
+ 9.2. Informative References ....................................17
+ 10. Contributors' Addresses .......................................17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shiomoto Informational [Page 2]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+1. Introduction
+
+ Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to
+ Generalized MPLS (GMPLS) migration is the process of evolving an
+ MPLS-TE-based control plane to a GMPLS-based control plane. The
+ network under consideration for migration is, therefore, a
+ packet-switching network.
+
+ There are several motivations for such migration, mainly the desire
+ to take advantage of new features and functions added to the GMPLS
+ protocols, which are not present in MPLS-TE for packet networks.
+ Additionally, before migrating a packet-switching network from
+ MPLS-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 using a GMPLS control plane. This may lead to the desire
+ for MPLS-TE/GMPLS (transport network) interworking to provide
+ enhanced TE support and facilitate the later migration of the
+ packet-switching network.
+
+ Although an appropriate migration strategy will be selected based on
+ various factors including the service provider's network deployment
+ plan, customer demand, deployed network equipments, operational
+ policy, etc., the transition mechanisms used should also provide
+ consistent operation of newly introduced GMPLS networks, while
+ minimizing the impact on the operation of existing MPLS-TE networks.
+
+ This document describes several migration strategies and the
+ interworking scenarios that arise during migration. It also examines
+ the implications for network deployments and for protocol usage. As
+ the GMPLS signaling and routing protocols are different from the
+ MPLS-TE control protocols, interworking mechanisms between MPLS-TE
+ and GMPLS networks, or network elements, may be needed to compensate
+ for the differences.
+
+ Note that MPLS-TE and GMPLS protocols can coexist as "ships in the
+ night" without any interworking issues.
+
+2. Conventions Used in This Document
+
+ This is not a requirements document, nevertheless the key words
+ "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+ "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
+ are to be interpreted as described in RFC 2119 [RFC2119] in order to
+ clarify the recommendations that are made.
+
+ In the rest of this document, the term "GMPLS" includes both packet
+ switching capable (PSC) and non-PSC. Otherwise, the term "PSC GMPLS"
+ or "non-PSC GMPLS" is used explicitly.
+
+
+
+Shiomoto Informational [Page 3]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ In general, the term "MPLS" is used to indicate MPLS traffic
+ engineering (MPLS-TE) only ([RFC3209], [RFC3630], and [RFC3784]) and
+ excludes other MPLS protocols, such as the Label Distribution
+ Protocol (LDP). TE functionalities of MPLS could be migrated to
+ GMPLS, but non-TE functionalities could not. If non-TE MPLS is
+ intended, it is indicated explicitly.
+
+ The reader is assumed to be familiar with the terminology introduced
+ in [RFC3945].
+
+3. Motivations for Migration
+
+ Motivations for migration will vary for different service providers.
+ This section is presented to provide background so that the migration
+ discussions may be seen in context. Sections 4 and 5 provide
+ examples to illustrate the migration models and processes.
+
+ Migration of an MPLS-capable Label Switching Router (LSR) to include
+ GMPLS capabilities may be performed for one or more reasons,
+ including, not exhaustively:
+
+ o To add all GMPLS PSC features to an existing MPLS network (upgrade
+ MPLS LSRs).
+
+ o To add specific GMPLS PSC features and operate them within an MPLS
+ network (e.g., [RFC4872] and [RFC4873]).
+
+ o To integrate a new GMPLS PSC network with an existing MPLS network
+ (without upgrading any of the MPLS LSRs).
+
+ o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs
+ supporting only GMPLS PSC and/or non-PSC features.
+
+ o To integrate multiple control networks, e.g., managed by separate
+ administrative organizations, and which independently utilize MPLS
+ or GMPLS.
+
+ o To build integrated PSC and non-PSC networks. The non-PSC
+ networks are controlled by GMPLS.
+
+ The objective of migration from MPLS to GMPLS is that all LSRs, and
+ the entire network, support GMPLS protocols. During this process,
+ various interim situations may exist, giving rise to the interworking
+ situations described in this document. The interim situations may
+ exist for considerable periods of time, but the ultimate objective is
+ not to preserve these situations. For the purposes of this document,
+ they should be considered as temporary and transitory.
+
+
+
+
+Shiomoto Informational [Page 4]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+4. MPLS to GMPLS Migration Models
+
+ Three reference migration models are described below. Multiple
+ migration models may coexist in the same network.
+
+4.1. Island Model
+
+ In the island model, "islands" of network nodes operating one
+ protocol exist within a "sea" of nodes using the other protocol.
+
+ For example, consider an island of GMPLS-capable nodes (PSC) that is
+ introduced into a legacy MPLS network. Such an island might be
+ composed of newly added GMPLS nodes, or it might arise from the
+ upgrade of existing nodes that previously operated MPLS protocols.
+
+ 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
+ situation might arise in the later stages of migration, when all but
+ a few islands of MPLS-capable nodes have been upgraded to GMPLS.
+
+ It is also possible that a lower-layer, manually-provisioned network
+ (for example, a Time Division Multiplexing (TDM) network) is
+ constructed under an MPLS PSC network. During the process of
+ migrating both networks to GMPLS, the lower-layer network might be
+ migrated first. This would appear as a GMPLS island within an MPLS
+ sea.
+
+ Lastly, it is possible to consider individual nodes as islands. That
+ 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 an island.
+
+ Over time, collections of MPLS devices are replaced or upgraded to
+ create new GMPLS islands or to extend existing ones, and distinct
+ GMPLS islands may be joined together until the whole network is
+ GMPLS-capable.
+
+ From a migration/interworking point of view, we need to examine how
+ these islands are positioned and how Label Switched Paths (LSPs)
+ connect between the islands.
+
+ Four categories of interworking scenarios are considered: (1)
+ 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 GMPLS islands are PSC or non-PSC.
+
+
+
+
+
+
+Shiomoto Informational [Page 5]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ 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 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 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 equipment (TDM, Lambda Switch Capable (LSC), and Fiber
+ Switch Capable (FSC)).
+
+ ................. .......................... ..................
+ : MPLS : : GMPLS : : MPLS :
+ :+---+ +---+ +----+ +---+ +----+ +---+ +---+:
+ :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |:
+ :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+:
+ : ________/ : : _______/ | _____ / : : ________/ :
+ : / : : / | / : : / :
+ :+---+ +---+ +----+ +-+-+ +----+ +---+ +---+:
+ :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |:
+ :+---+ +---+ +----+ +---+ +----+ +---+ +---+:
+ :................: :........................: :................:
+
+ |<-------------------------------------------------------->|
+ e2e LSP
+
+ Figure 1: Example of the island model
+ for MPLS-GMPLS-MPLS interworking
+
+4.1.1. Balanced Islands
+
+ In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end
+ using the same protocols. Possible strategies include:
+
+ - tunneling the signaling across the island network using LSP nesting
+ or stitching [RFC5150] (the latter is only for GMPLS-PSC)
+
+ - protocol interworking or mapping (both are only for GMPLS-PSC)
+
+4.1.2. Unbalanced Islands
+
+ As previously discussed, there are two island interworking models
+ that support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC)
+ island cases are likely to arise where the migration strategy is not
+ based on a core infrastructure, but has edge nodes (ingress or
+ egress) located in islands of different capabilities.
+
+ 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
+ operation can only be addressed using protocol interworking or
+
+
+
+Shiomoto Informational [Page 6]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ mapping. Figure 2 shows the reference model for this migration
+ scenario. Head-end and tail-end LSRs are in distinct control plane
+ clouds.
+
+ ............................ .............................
+ : MPLS : : GMPLS (PSC) :
+ :+---+ +---+ +----+ +---+ +---+:
+ :|R1 |________|R11|_______| G1 |________|G3 |________|G5 |:
+ :+---+ +---+ +----+ +-+-+ +---+:
+ : ______/ | _____/ : : ______/ | ______/ :
+ : / | / : : / | / :
+ :+---+ +---+ +----+ +-+-+ +---+:
+ :|R2 |________|R21|_______| G2 |________|G4 |________|G6 |:
+ :+---+ +---+ +----+ +---+ +---+:
+ :..........................: :...........................:
+
+ |<-------------------------------------------------->|
+ e2e LSP
+
+ Figure 2: GMPLS-MPLS interworking model
+
+ 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
+ established.
+
+4.2. Integrated Model
+
+ The second migration model involves a more integrated migration
+ strategy. New devices that are capable of operating both MPLS and
+ GMPLS protocols are introduced into the MPLS network.
+
+ In the integrated model, there are two types of nodes present during
+ migration:
+
+ - those that support MPLS only (legacy nodes); and
+
+ - those that support MPLS and GMPLS.
+
+ In this model, as existing MPLS devices are upgraded to support both
+ MPLS and GMPLS, the network continues to operate with an MPLS control
+ plane, but some LSRs are also capable of operating with a GMPLS
+ 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
+ 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 nodes [RFC5073], it may be routed accordingly and can
+ achieve a higher level of functionality by utilizing GMPLS features.
+
+
+
+
+Shiomoto Informational [Page 7]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ Once all devices in the network are GMPLS-capable, the MPLS-specific
+ protocol elements may be turned off, and no new devices need to
+ support these protocol elements.
+
+ In this model, the questions to be addressed concern the coexistence
+ of the two protocol sets within the network. Actual interworking is
+ not a concern.
+
+4.3. Phased Model
+
+ The phased model introduces GMPLS features and protocol elements into
+ an MPLS network one by one. For example, some objects or sub-objects
+ (such as the Explicit Route Object (ERO) label sub-object, [RFC3473])
+ might be introduced into the signaling used by LSRs that are
+ otherwise MPLS-capable. This would produce a kind of hybrid LSR.
+
+ This approach may appear simpler to implement as one is able to
+ quickly and easily pick up new key functions without needing to
+ upgrade the whole protocol implementation. It is most likely to be
+ used where there is a desire to rapidly implement a particular
+ function within a network without the necessity to install and test
+ the full GMPLS function.
+
+ Interoperability concerns though are exacerbated by this migration
+ model, unless all LSRs in the network are updated simultaneously and
+ there is a clear understanding of which subset of features are to be
+ 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
+ LSR, as described in the previous sections, and puts the unchanged
+ LSR in the role of an MPLS LSR. The potential for different hybrids
+ within the network will complicate matters considerably. This model
+ is, therefore, only appropriate for use when the set of new features
+ to be deployed is well known and limited, and where there is a clear
+ understanding of and agreement on this set of features by the network
+ operators of the ISP(s) involved as well as all vendors whose
+ equipment will be involved in the migration.
+
+5. Migration Strategies and Toolkit
+
+ An appropriate migration strategy is selected by a network operator
+ based on factors including the service provider's network deployment
+ plan, customer demand, existing network equipment, operational
+ policy, support from its vendors, etc.
+
+ For PSC networks, the migration strategy involves the selection
+ between the models described in the previous section. The choice
+ will depend upon the final objective (full GMPLS capability, partial
+
+
+
+
+Shiomoto Informational [Page 8]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ upgrade to include specific GMPLS features, or no change to existing
+ IP/MPLS networks), and upon the immediate objectives (full, phased,
+ or staged upgrade).
+
+ For PSC networks serviced by non-PSC networks, two basic migration
+ strategies can be considered. In the first strategy, the non-PSC
+ network is made GMPLS-capable, first, and then the PSC network is
+ migrated to GMPLS. This might arise when, in order to expand the
+ network capacity, GMPLS-based non-PSC sub-networks are introduced
+ into the legacy MPLS-based networks. Subsequently, the legacy
+ MPLS-based PSC network is migrated to be GMPLS-capable, as described
+ in the previous paragraph. Finally, the entire network, including
+ both PSC and non-PSC nodes, may be controlled by GMPLS.
+
+ The second strategy is to migrate the PSC network to GMPLS first, and
+ then enable GMPLS within the non-PSC network. The PSC network is
+ migrated as described before, and when the entire PSC network is
+ completely converted to GMPLS, GMPLS-based non-PSC devices and
+ networks may be introduced without any issues of interworking between
+ MPLS and GMPLS.
+
+ These migration strategies and the migration models described in the
+ previous section are not necessarily mutually exclusive. Mixtures of
+ all strategies and models could be applied. The migration models and
+ strategies selected will give rise to one or more of the interworking
+ cases described in the following section.
+
+5.1. Migration Toolkit
+
+ As described in the previous sections, an essential part of a
+ migration and deployment strategy is how the MPLS and GMPLS or hybrid
+ LSRs interwork. This section sets out some of the alternatives for
+ achieving interworking between MPLS and GMPLS, and it identifies some
+ of the issues that need to be addressed. This document does not
+ describe solutions to these issues.
+
+ Note that it is possible to consider upgrading the routing and
+ signaling capabilities of LSRs from MPLS to GMPLS separately.
+
+5.1.1. Layered Networks
+
+ In the balanced island model, LSP tunnels [RFC4206] are a solution to
+ carry the end-to-end LSPs across islands of incompatible nodes.
+ Network layering is often used to separate domains of different data
+ plane technology. It can also be used to separate domains of
+ different control plane technology (such as MPLS and GMPLS
+ protocols), and the solutions developed for multiple data plane
+
+
+
+
+Shiomoto Informational [Page 9]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ technologies can be usefully applied to this situation [RFC3945],
+ [RFC4206], and [RFC4726]. [MLN-REQ] gives a discussion of the
+ requirements for multi-layered networks.
+
+ The GMPLS architecture [RFC3945] identifies three architectural
+ models for supporting multi-layer GMPLS networks, and these models
+ may be applied to the separation of MPLS and GMPLS control plane
+ islands.
+
+ - In the peer model, both MPLS and GMPLS nodes run the same routing
+ instance, and routing advertisements from within islands of one
+ level of protocol support are distributed to the whole network.
+ This is achievable only, as described in Section 5.1.2, either by
+ direct distribution or by mapping of parameters.
+
+ Signaling in the peer model may result in contiguous LSPs, stitched
+ LSPs [RFC5150] (only for GMPLS PSC), or nested LSPs. If the
+ network islands are non-PSC, then the techniques of [MLN-REQ] may
+ be applied, and these techniques may be extrapolated to networks
+ where all nodes are PSC, but where there is a difference in
+ signaling protocols.
+
+ - The overlay model preserves strict separation of routing
+ information between network layers. This is suitable for the
+ balanced island model, and there is no requirement to handle
+ routing interworking. Even though the overlay model preserves
+ separation of signaling information between network layers, there
+ may be some interaction in signaling between network layers.
+
+ The overlay model requires the establishment of control plane
+ connectivity for the higher layer across the lower layer.
+
+ - The augmented model allows limited routing exchange from the
+ lower-layer network to the higher-layer network. Generally
+ speaking, this assumes that the border nodes provide some form of
+ filtering, mapping, or aggregation of routing information
+ advertised from the lower-layer network. This architectural model
+ can also be used for balanced island model migrations. Signaling
+ interworking is required as described for the peer model.
+
+ - The border peer architecture model is defined in [RFC5146]. This
+ is a modification of the augmented model where the layer border
+ routers have visibility into both layers, but no routing
+ information is otherwise exchanged between routing protocol
+ instances. This architectural model is particularly suited to the
+ MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands.
+ Signaling interworking is required as described for the peer model.
+
+
+
+
+Shiomoto Informational [Page 10]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+5.1.2. Routing Interworking
+
+ Migration strategies may necessitate some interworking between MPLS
+ and GMPLS routing protocols. GMPLS extends the TE information
+ advertised by the IGPs to include non-PSC information and extended
+ PSC information. Because the GMPLS information is provided as
+ additional TLVs that are carried along with the MPLS information,
+ 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 it, flooding it transparently across the MPLS network for use
+ by other GMPLS LSRs.
+
+ - Routing separation is achieved in the overlay and border peer
+ models. This is convenient since only the border nodes need to be
+ aware of the different protocol variants, and no mapping is
+ required. It is suitable to the MPLS-GMPLS-MPLS and
+ GMPLS-MPLS-GMPLS island migration models.
+
+ - Direct distribution involves the flooding of MPLS routing
+ information into a GMPLS network, and GMPLS routing information
+ into an MPLS network. The border nodes make no attempt to filter
+ the information. This mode of operation relies on the fact that
+ MPLS routers will ignore, but continue to flood, GMPLS routing
+ information that they do not understand. The presence of
+ additional GMPLS routing information will not interfere with the
+ way that MPLS LSRs select routes. Although this is not a problem
+ in a PSC-only network, it could cause problems in a peer
+ architecture network that includes non-PSC nodes, as the MPLS nodes
+ are not capable of determining the switching types of the other
+ LSRs and will attempt to signal end-to-end LSPs assuming all LSRs
+ to be PSC. This fact would require island border nodes to take
+ triggered action to set up tunnels across islands of different
+ switching capabilities.
+
+ GMPLS LSRs might be impacted by the absence of GMPLS-specific
+ information in advertisements initiated by MPLS LSRs. Specific
+ procedures might be required to ensure consistent behavior by GMPLS
+ nodes. If this issue is addressed, then direct distribution can be
+ used in all migration models (except the overlay and border peer
+ architectural models where the problem does not arise).
+
+ - Protocol mapping converts routing advertisements so that they can
+ be received in one protocol and transmitted in the other. For
+ example, a GMPLS routing advertisement could have all of its
+ GMPLS-specific information removed and could be flooded as an MPLS
+ advertisement. This mode of interworking would require careful
+ standardization of the correct behavior especially where an MPLS
+ advertisement requires default values of GMPLS-specific fields to
+
+
+
+Shiomoto Informational [Page 11]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ be generated before the advertisement can be flooded further.
+ There is also considerable risk of confusion in closely meshed
+ networks where many LSRs have MPLS- and GMPLS-capable interfaces.
+ This option for routing interworking during migration is NOT
+ RECOMMENDED for any migration model. Note that converting
+ GMPLS-specific sub-TLVs to MPLS-specific ones but not stripping the
+ GMPLS-specific ones is considered a variant of the proposed
+ solution in the previous bullet (unknown sub-TLVs should be ignored
+ [RFC3630] but must continue to be flooded).
+
+ - Ships in the night refers to a mode of operation where both MPLS
+ and GMPLS routing protocol variants are operated in the same
+ network at the same time as separate routing protocol instances.
+ The two instances are independent and are used to create routing
+ adjacencies between LSRs of the same type. This mode of operation
+ may be appropriate to the integrated migration model.
+
+5.1.3. Signaling Interworking
+
+ Signaling protocols are used to establish LSPs and are the principal
+ concern for interworking during migration. Issues of compatibility
+ arise because of differences in the encodings and codepoints used by
+ MPLS and GMPLS signaling, but also because of differences in
+ functionality provided by MPLS and GMPLS.
+
+ - Tunneling and stitching [RFC5150] (GMPLS-PSC case) mechanisms
+ provide the potential to avoid direct protocol interworking during
+ migration in the island model because protocol elements are
+ transported transparently across migration islands without being
+ inspected. However, care may be needed to achieve functional
+ mapping in these modes of operation since one set of features may
+ need to be supported across a network designed to support a
+ different set of features. In general, this is easily achieved for
+ the MPLS-GMPLS-MPLS model, but may be hard to achieve in the
+ GMPLS-MPLS-GMPLS model, for example, when end-to-end bidirectional
+ LSPs are requested, since the MPLS island does not support
+ bidirectional LSPs.
+
+ Note that tunneling and stitching are not available in unbalanced
+ island models because in these cases, the LSP end points use
+ different protocols.
+
+ - Protocol mapping is the conversion of signaling messages between
+ MPLS and GMPLS. This mechanism requires careful documentation of
+ the protocol fields and how they are mapped. This is relatively
+ straightforward in the MPLS-GMPLS unbalanced island model for LSPs
+ signaled in the MPLS-GMPLS direction. However, it may be more
+ complex for LSPs signaled in the opposite direction, and this will
+
+
+
+Shiomoto Informational [Page 12]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ lead to considerable complications for providing GMPLS services
+ over the MPLS island and for terminating those services at an
+ egress LSR that is not GMPLS-capable. Further, in balanced island
+ models, and in particular where there are multiple small
+ (individual node) islands, the repeated conversion of signaling
+ parameters may lead to loss of information (and functionality) or
+ mis-requests.
+
+ - Ships in the night could be used in the integrated migration model
+ to allow MPLS-capable LSRs to establish LSPs using MPLS signaling
+ protocols and GMPLS LSRs to establish LSPs using GMPLS signaling
+ protocols. LSRs that can handle both sets of protocols could work
+ with both types of LSRs, and no conversion of protocols would be
+ needed.
+
+5.1.4. Path Computation Element
+
+ The Path Computation Element (PCE) [RFC4655] may provide an
+ additional tool to aid MPLS to GMPLS migration. If a layered network
+ approach (Section 5.1.1) is used, PCEs may be used to facilitate the
+ computation of paths for LSPs in the different layers [PCE-INT].
+
+6. Manageability Considerations
+
+ Attention should be given during migration planning to how the
+ network will be managed during and after migration. For example,
+ will the LSRs of different protocol capabilities be managed
+ separately or as one management domain? For example, in the Island
+ Model, it is possible to consider managing islands of one capability
+ separately from the surrounding sea. In the case of islands that
+ have different switching capabilities, it is possible that the
+ islands already have separate management in place before the
+ migration: the resultant migrated network may seek to merge the
+ management or to preserve the separation.
+
+6.1. Control of Function and Policy
+
+ The most critical control functionality to be applied is at the
+ moment of changeover between different levels of protocol support.
+ Such a change may be made without service halt or during a period of
+ network maintenance.
+
+ Where island boundaries exist, it must be possible to manage the
+ relationships between protocols and to indicate which interfaces
+ support which protocols on a border LSR. Further, island borders are
+ a natural place to apply policy, and management should allow
+ configuration of such policies.
+
+
+
+
+Shiomoto Informational [Page 13]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+6.2. Information and Data Models
+
+ No special information or data models are required to support
+ migration, but note that migration in the control plane implies
+ migration from MPLS management tools to GMPLS management tools.
+ During migration, therefore, it may be necessary for LSRs and
+ management applications to support both MPLS and GMPLS management
+ data.
+
+ The GMPLS MIB modules are designed to allow support of the MPLS
+ protocols, and they are built on the MPLS MIB modules through
+ extensions and augmentations. This may make it possible to migrate
+ management applications ahead of the LSRs that they manage.
+
+6.3. Liveness Detection and Monitoring
+
+ Migration will not impose additional issues for Operations,
+ Administration, and Management (OAM) above those that already exist
+ for inter-domain OAM and for OAM across multiple switching
+ capabilities.
+
+ Note, however, that if a flat PSC MPLS network is migrated using the
+ island model, and is treated as a layered network using tunnels to
+ connect across GMPLS islands, then requirements for a multi-layer OAM
+ technique may be introduced into what was previously defined in the
+ flat OAM problem-space. The OAM framework of MPLS/GMPLS interworking
+ will need further consideration.
+
+6.4. Verifying Correct Operation
+
+ The concerns for verifying correct operation (and in particular,
+ correct connectivity) are the same as for liveness detection and
+ monitoring. Specifically, the process of migration may introduce
+ tunneling or stitching [RFC5150] into what was previously a flat
+ network.
+
+6.5. Requirements on Other Protocols and Functional Components
+
+ No particular requirements are introduced on other protocols. As it
+ has been observed, the management components may need to migrate in
+ step with the control plane components, but this does not impact the
+ management protocols, just the data that they carry.
+
+ It should also be observed that providing signaling and routing
+ connectivity across a migration island in support of a layered
+ architecture may require the use of protocol tunnels (such as Generic
+
+
+
+
+
+Shiomoto Informational [Page 14]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ Routing Encapsulation (GRE)) between island border nodes. Such
+ tunnels may impose additional configuration requirements at the
+ border nodes.
+
+6.6. Impact on Network Operation
+
+ The process of migration is likely to have significant impact on
+ network operation while migration is in progress. The main objective
+ of migration planning should be to reduce the impact on network
+ operation and on the services perceived by the network users.
+
+ To this end, planners should consider reducing the number of
+ migration steps that they perform and minimizing the number of
+ migration islands that are created.
+
+ A network manager may prefer the island model especially when
+ migration will extend over a significant operational period because
+ it allows the different network islands to be administered as
+ separate management domains. This is particularly the case in the
+ overlay, augmented network and border peer models where the details
+ of the protocol islands remain hidden from the surrounding LSRs.
+
+6.7. Other Considerations
+
+ A migration strategy may also imply moving an MPLS state to a GMPLS
+ state for an in-service LSP. This may arise once all of the LSRs
+ along the path of the LSP have been updated to be both MPLS- and
+ GMPLS-capable. Signaling mechanisms to achieve the replacement of an
+ MPLS LSP with a GMPLS LSP without disrupting traffic exist through
+ make-before-break procedures [RFC3209] and [RFC3473], and should be
+ carefully managed under operator control.
+
+7. Security Considerations
+
+ Security and confidentiality is often applied (and attacked) at
+ administrative boundaries. Some of the models described in this
+ document introduce such boundaries, for example, between MPLS and
+ GMPLS islands. These boundaries offer the possibility of applying or
+ modifying the security as when crossing an IGP area or Autonomous
+ System (AS) boundary, even though these island boundaries might lie
+ within an IGP area or AS.
+
+ No changes are proposed to the security procedures built into MPLS
+ and GMPLS signaling and routing. GMPLS signaling and routing inherit
+ their security mechanisms from MPLS signaling and routing without any
+ changes. Hence, there will be no additional issues with security in
+ interworking scenarios. Further, since the MPLS and GMPLS signaling
+ and routing security is provided on a hop-by-hop basis, and since all
+
+
+
+Shiomoto Informational [Page 15]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ signaling and routing exchanges described in this document for use
+ between any pair of LSRs are based on either MPLS or GMPLS, there are
+ no changes necessary to the security procedures.
+
+8. Acknowledgements
+
+ The authors are grateful to Daisaku Shimazaki for discussion during
+ the initial work on this document. The authors are grateful to Dean
+ Cheng and Adrian Farrel for their valuable comments.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, 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., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Resource ReserVation Protocol-
+ Traffic 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., Ed., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Architecture", RFC 3945, October 2004.
+
+ [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed.,
+ "RSVP-TE Extensions in Support of End-to-End Generalized
+ Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872,
+ May 2007.
+
+ [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
+ "GMPLS Segment Recovery", RFC 4873, May 2007.
+
+ [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing
+ Protocol Extensions for Discovery of Traffic Engineering
+ Node Capabilities", RFC 5073, December 2007.
+
+
+
+Shiomoto Informational [Page 16]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+9.2. Informative References
+
+ [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+ Hierarchy with Generalized Multi-Protocol Label Switching
+ (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
+
+ [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation
+ Element (PCE)-Based Architecture", RFC 4655, August 2006.
+
+ [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
+ for Inter-Domain Multiprotocol Label Switching Traffic
+ Engineering", RFC 4726, November 2006.
+
+ [RFC5150] Ayyangar, A., Kompella, A., Vasseur, JP., and A. Farrel,
+ "Label Switched Path Stitching with Generalized
+ Multiprotocol Label Switching Traffic Engineering", RFC
+ 5150, February 2008.
+
+ [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support
+ Operation of MPLS-TE over GMPLS Networks", RFC 5146, March
+ 2008.
+
+ [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,
+ M., and D. Brungard, "Requirements for GMPLS-Based Multi-
+ Region and Multi-Layer Networks (MRN/MLN)", Work in
+ Progress, January 2008.
+
+ [PCE-INT] Oki, E., Le Roux , J-L., and A. Farrel, "Framework for
+ PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering,"
+ Work in Progress, January 2008.
+
+10. Contributors' Addresses
+
+ Dimitri Papadimitriou
+ Alcatel
+ Francis Wellensplein 1,
+ B-2018 Antwerpen, Belgium
+ Phone: +32 3 240 8491
+ EMail: dimitri.papadimitriou@alcatel-lucent.be
+
+ Jean-Louis Le Roux
+ France Telecom
+ av Pierre Marzin 22300
+ Lannion, France
+ Phone: +33 2 96 05 30 20
+ EMail: jeanlouis.leroux@orange-ftgroup.com
+
+
+
+
+
+Shiomoto Informational [Page 17]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+ Deborah Brungard
+ AT&T
+ Rm. D1-3C22 - 200 S. Laurel Ave.
+ Middletown, NJ 07748, USA
+ Phone: +1 732 420 1573
+ EMail: dbrungard@att.com
+
+ Zafar Ali
+ Cisco Systems, Inc.
+ EMail: zali@cisco.com
+
+ Kenji Kumaki
+ KDDI Corporation
+ Garden Air Tower
+ Iidabashi, Chiyoda-ku,
+ Tokyo 102-8460, JAPAN
+ Phone: +81-3-6678-3103
+ EMail: ke-kumaki@kddi.com
+
+ Eiji Oki
+ NTT
+ Midori 3-9-11
+ Musashino, Tokyo 180-8585, Japan
+ Phone: +81 422 59 3441
+ EMail: oki.eiji@lab.ntt.co.jp
+
+ Ichiro Inoue
+ NTT
+ Midori 3-9-11
+ Musashino, Tokyo 180-8585, Japan
+ Phone: +81 422 59 3441
+ EMail: inoue.ichiro@lab.ntt.co.jp
+
+ Tomohiro Otani
+ KDDI Laboratories
+ EMail: otani@kddilabs.jp
+
+Editor's Address
+
+ Kohei Shiomoto
+ NTT
+ Midori 3-9-11
+ Musashino, Tokyo 180-8585, Japan
+ Phone: +81 422 59 4402
+ EMail: shiomoto.kohei@lab.ntt.co.jp
+
+
+
+
+
+
+Shiomoto Informational [Page 18]
+
+RFC 5145 Framework for MPLS-TE to GMPLS Migration March 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ 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
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Shiomoto Informational [Page 19]
+