draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt   draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt 
Network Working Group Kohei Shiomoto(NTT) Network Working Group Kohei Shiomoto(NTT)
Internet Draft Dimitri Papadimitriou(Alcatel) Internet Draft Dimitri Papadimitriou(Alcatel)
Proposed Category: Informational Jean-Louis Le Roux(France Telecom) Proposed Category: Informational Jean-Louis Le Roux(France Telecom)
Expires: October 2006 Deborah Brungard (AT&T) Expires: October 2006 Deborah Brungard (AT&T)
Kenji Kumaki (KDDI) Kenji Kumaki (KDDI)
Zafar Ali (Cisco)
Eiji Oki(NTT) Eiji Oki(NTT)
Ichiro Inoue(NTT) Ichiro Inoue(NTT)
Tomohiro Otani (KDDI) Tomohiro Otani (KDDI)
Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to Framework for MPLS-TE to GMPLS migration
GMPLS migration draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.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 1, line 41 skipping to change at page 1, line 41
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) to The migration from Multiprotocol Label Switching (MPLS) Traffic
Generalized MPLS (GMPLS) is the process of evolving an MPLS traffic Engineering (TE) to Generalized MPLS (GMPLS) is the process of
engineered (TE) control plane to a GMPLS control plane. An evolving an MPLS-TE control plane to a GMPLS control plane. An
appropriate migration strategy can be selected based on various appropriate migration strategy can 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, available network equipment implementation, customer demand, and operational policy.
operational policy, etc.
In the course of migration, several interworking cases may exist
where MPLS and GMPLS devices or networks must coexist. During the
migration process, standard interworking functions are needed to
allow graceful deployment of GMPLS technologies while keeping
existing IP/MPLS networks unaffected.
Since GMPLS signaling and routing protocols are different from the This document presents several migration models and strategies for
MPLS control protocols, in order for MPLS and GMPLS to interwork, we migrating from MPLS-TE to GMPLS and notes that in the course of
need mechanisms to compensate for the differences between MPLS and migration MPLS-TE and GMPLS devices or networks may coexist which may
GMPLS. This document provides a landscape of techniques, practices require interworking between MPLS-TE and GMPLS protocols. The
and an overview of interworking between MPLS and GMPLS in support of applicability? of the interworking that is required is discussed as
IP/MPLS to GMPLS migration, which is also beneficial for graceful it appears to influence the choice of a migration strategy.
deployment of GMPLS technologies into existing IP/MPLS networks. We
discuss issues, models, migration scenarios, operation, and
requirements.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions Used in This Document..............................4 2. Conventions Used in This Document..............................3
3. Motivations for Migration......................................4 3. Motivations for Migration......................................4
4. MPLS to GMPLS migration........................................5 4. MPLS to GMPLS Migration Models.................................5
4.1. Migration models..........................................5 4.1. Island model..............................................5
4.1.1. Island model.........................................5 4.1.1. Balanced Islands.....................................6
4.1.2. Integrated model.....................................6 4.1.2. Unbalanced Islands...................................6
4.1.3. Phased model.........................................7 4.2. Integrated model..........................................7
4.2. Migration strategies......................................8 4.3. Phased model..............................................8
5. Island model interworking cases................................9 5. Migration Strategies and Solutions.............................9
5.1. MPLS-GMPLS(PSC)-MPLS Islands..............................9 5.1. Solutions Toolkit.........................................9
5.2. MPLS-GMPLS(non-PSC)-MPLS Islands..........................9 5.1.1. Layered Networks....................................10
5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands........................9 - The overlay model preserves strict separation of routing
5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands................9 information between network layers. This is suitable for the
5.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands...............9 balanced island model and there is no requirement to handle
6. Interworking issues between MPLS and GMPLS....................10 routing interworking. Signaling interworking is still required
6.1. Signaling................................................11 as described for the peer model. The overlay model requires
6.1.1. GMPLS specific RSVP objects and Messages............11 the establishment of control plane connectivity for the higher
6.1.1.1. Direct interworking............................12 layer across the lower layer...............................10
6.1.1.2. Mapping........................................13 5.1.2. Routing Interworking................................11
6.1.1.3. Transfer.......................................13 5.1.3. Signaling Interworking..............................12
6.1.2. Bidirectional LSP...................................13 6. Manageability Considerations..................................13
6.1.3. Failure recovery....................................14 6.1. Control of Function and Policy...........................13
6.2. Routing..................................................14 6.2. Information and Data Models..............................14
6.2.1. Interworking of Routing Protocols...................15 6.3. Liveness Detection and Monitoring........................14
6.2.2. Mapping of Routing Protocols........................15 6.4. Verifying Correct Operation..............................14
6.3. Layered Networks.........................................15 6.5. Requirements on Other Protocols and Functional Components14
6.3.1. Peer Model..........................................17 6.6. Impact on Network Operation..............................15
6.3.2. Overlay Model.......................................18 6.7. Other Considerations.....................................15
6.3.3. Augmented Model.....................................18 7. Security Considerations.......................................15
7. Manageability Considerations..................................18 8. Recommendations for Migration.................................16
7.1. Control of Function and Policy...........................19 9. IANA Considerations...........................................16
7.2. Information and Data Models..............................19 10. Full Copyright Statement.....................................16
7.3. Liveness Detection and Monitoring........................19 11. Intellectual Property........................................16
7.4. Verifying Correct Operation..............................20 12. Acknowledgements.............................................17
7.5. Requirements on Other Protocols and Functional Components20 13. Authors' Addresses...........................................18
7.6. Impact on Network Operation..............................20 14. References...................................................19
7.7. Other Considerations.....................................20 14.1. Normative References....................................19
8. Security Considerations.......................................20 14.2. Informative References..................................20
9. IANA Considerations...........................................21
10. Full Copyright Statement.....................................21
11. Intellectual Property........................................21
12. Acknowledgements.............................................22
13. Authors' Addresses...........................................23
14. References...................................................24
14.1. Normative References....................................24
14.2. Informative References..................................24
1. Introduction 1. Introduction
MPLS to GMPLS migration is the process of evolving an MPLS-TE-based Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to
control plane to a GMPLS-based control plane. 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 is, therefore, a packet-switching network.
There are several motivations for such migration and they focus There are several motivations for such migration and they focus
mainly on the desire to take advantage of new features and functions mainly on the desire to take advantage of new features and functions
that have been added to the GMPLS protocols but which are not present that have been added to the GMPLS protocols but which are not present
in MPLS. in MPLS-TE.
Although an appropriate migration strategy can be selected based on Although an appropriate migration strategy can be selected based on
various factors including the service provider's network deployment various factors including the service provider's network deployment
plan, customer demand, available network equipment implementation, plan, customer demand, deployed network equipments, operational
operational policy, etc, the smooth transition mechanism should be policy, etc., the transition mechanisms used should also provide
investigated from the consistent operation of GMPLS networks, while consistent operation of GMPLS networks while minimizing the impact on
less impacting the operation of existing MPLS networks. the operation of existing MPLS-TE networks.
In the course of migration, several interworking cases may arise In the course of migration MPLS-TE and GMPLS devices or networks may
where MPLS and GMPLS devices or networks must coexist. Such cases may need to coexist. Such cases may occur as parts of the network are
occur as parts of the network are converted from MPLS protocols to migrated from MPLS-TE protocols to GMPLS protocols. Additionally, as
GMPLS protocols, or may arise if a lower layer network is made GMPLS- part of the preparation for migrating a packet-switching network from
capable (from having no MPLS or GMPLS control plane) in advance of MPLS-TE to GMPLS, it may be desirable to first migrate a lower-layer
the migration of the higher layer network. network from having control plane to using a GMPLS control plane, and
this can also lead to the need for MPLS-TE/GMPLS interworking.
This document examines the interworking scenarios that arise during This document describes several migration strategies and shows the
migration, and examines the implications for network deployments and interworking scenarios that arise during migration, and examines the
for protocol usage. Since GMPLS signaling and routing protocols are implications for network deployments and for protocol usage. Since
different from the MPLS control protocols, interworking between MPLS GMPLS signaling and routing protocols are different from the MPLS-TE
and GMPLS networks or network elements needs mechanisms to compensate control protocols, interworking between MPLS-TE and GMPLS networks or
for the differences. This document provides a framework for MPLS and network elements needs mechanisms to compensate for the differences.
GMPLS interworking in support of migration from IP/MPLS to GMPLS by
discussing issues, models, migration scenarios, operation and
requirements. Solutions for interworking MPLS and GMPLS will be
developed in companion documents.
Note that both MPLS and GMPLS protocols can co-exist as "ships in the Note that MPLS-TE and GMPLS protocols can co-exist as "ships in the
night" without any interworking issue. This document addresses night" without any interworking issue.
interworking to allow migration from MPLS to GMPLS. We should also
note that, in this document, a MPLS control plane means a MPLS-TE Also note that, in this document, the term "MPLS" is used to refer to
control plane (RSVP-TE [RFC3209], IGP-TE [RFC3630] [RFC3784]), and MPLS-TE protocols only ([RFC3209], [RFC3630], [RFC3473]) and excludes
not a LDP-based control plane [RFC3036]. This document does not other MPLS protocols such as the Label Distribution Protocol (LDP).TE
address the migration from LDP controlled MPLS networks to G/MPLS functionalities of MPLS could be migrated to GMPLS-TE, but non-TE
RSVP-TE at this moment, but may consider it in the future version. functionalities could not.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This is not a requirements document, nevertheless the key words
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
document are to be interpreted as described in RFC 2119 [RFC2119]. "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 In the rest of this document, the term "GMPLS" includes both packet
switch capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS" or switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS"
"non-PSC GMPLS" is explicitly used. or "non-PSC GMPLS" is explicitly used.
In general, the term "MPLS" is used to indicate MPLS traffic
engineering (MPLS-TE). If non-TE MPLS is intended, it is explicitly
indicated.
The reader is assumed to be familiar with the terminology introduced The reader is assumed to be familiar with the terminology introduced
in [RFC3495]. 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 only presented to provide background so that the This section is only presented to provide background so that the
migration discussions may be seen in the context. Sections 4 and 5 migration discussions may be seen in the context. Sections 4 and 5
illustrate the migration models and processes with possible examples. illustrate the migration models and processes with possible examples.
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: performed for one or more reasons, including, no exhaustively:
o To add all GMPLS capabilities to an existing MPLS PSC network. o To add all GMPLS capabilities to an existing MPLS network.
o To add a GMPLS network without sacrificing the existing MPLS PSC o To add a GMPLS network without upgrading existing MPLS PSC LSRs.
LSR implementation.
o To pick up specific GMPLS features and operate them within an MPLS o To pick up specific GMPLS features and operate them within an MPLS
PSC network. PSC network.
o To allow MPLS capable LSRs to interoperate with new LSRs that only o To allow existing MPLS-capable LSRs to interoperate with new LSRs
support GMPLS. that only support GMPLS.
o To integrate multiple networks managed by separate administrative o To integrate multiple networks managed by separate administrative
organizations, which independently utilize MPLS or GMPLS. organizations, which independently utilize MPLS or GMPLS.
o To build integrated PSC and non-PSC networks where the non-PSC o To build integrated PSC and non-PSC networks where the non-PSC
networks can only be controlled by GMPLS since MPLS does not networks can only be controlled by GMPLS since MPLS does not
operate in non-PSC networks. operate in non-PSC networks.
4. MPLS to GMPLS migration It must be understood that the ultimate objective of migration from
MPLS to GMPLS is that all LSRs and the entire network end up running
GMPLS protocols. During this process various interim situations may
exist giving rise to the interworking situations described in this
document. Those interim situations may persist for considerable
periods of time, but the ultimate objective is not to preserve these
situations, and for the purpose of this document, they should be
considered as temporary.
4.1. Migration models 4. MPLS to GMPLS Migration Models
MPLS to GMPLS migration is a process of evolving an MPLS-TE-based Three migration models are described below. Multiple migration models
control plane to a GMPLS-based control plane. Three migration models may co-exists in the same network.
are considered as described below. Practically speaking, multiple
migration models may be deployed at the same time.
4.1.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.
The most obvious example is to consider an island of GMPLS-capable The most obvious example is to consider an island of GMPLS-capable
nodes which is introduced into a legacy MPLS network. Such an island nodes which is introduced into a legacy MPLS network. Such an island
might be composed of newly added GMPLS network nodes, or might arise might be composed of newly added GMPLS network nodes, or might arise
from the upgrade of existing nodes that previously operated MPLS from the upgrade of existing nodes that previously operated MPLS
protocols. The opposite is also quite possible. That is, there is a protocols. The opposite is also quite possible. That is, there is a
possibility that an island happens to be MPLS-capable within a GMPLS possibility that an island happens to be MPLS-capable within a GMPLS
sea. Such a situation might arise in the later stages of migration, 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 when all but a few islands of MPLS-capable nodes have been upgraded
to GMPLS. 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) supports an MPLS PSC network. During the (for example, a TDM network) supports an MPLS PSC network. During the
process of migrating from both networks to GMPLS, the situation might process of migrating both networks to GMPLS, the lower-layer network
arise where the lower-layer network has been migrated and operates might be migrated first. This would appear as a GMPLS island within
GMPLS, but the packet network still operates MPLS. This would appear an MPLS sea.
as a 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.
skipping to change at page 6, line 12 skipping to change at page 6, line 4
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 run between the islands. these islands are positioned and how LSPs run 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 each case, the interworking behavior is examined based on whether In case 1 the interworking behavior is examined based on whether the
the GMPLS islands are PSC or non-PSC. These scenarios are considered GMPLS islands are PSC or non-PSC.
further in section 5.
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).
................. .............................. .................. ................. .......................... ..................
: 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.2. Integrated model 4.1.1. Balanced Islands
The second model involves a more integrated migration strategy. New In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end
devices that are capable of operating both MPLS and GMPLS protocols using the same protocols. Available strategies include:
are introduced into the MPLS network. We should note that the GMPLS-
capable device may not support a full set of MPLS functionalities.
For example, a GMPLS-capable device may support protection and
restoration mechanisms in [E2E-recovery, SEGMENT-recovery] but may
not support the fast reroute mechanism defined in [RFC4090]. This
fact highlights the difference between the island and the integrated
models. That is to say, in the island model, a GMPLS node does not
support MPLS features (signaling code points, FRR, etc), while in the
integrated model, the new device supports both MPLS and GMPLS
features.
Further, existing MPLS devices will be upgraded to support both MPLS - tunneling the signaling across the island network using LSP
and GMPLS. The network continues to operate providing MPLS services, nesting or stitching (only with GMPLS-PSC)
but where the service can be provided using only GMPLS functionality,
it may be routed accordingly over only such MPLS-GMPLS-capable
devices and achieve a higher level of functionality by utilizing
GMPLS features. Once all devices in the network are GMPLS-capable,
the MPLS specific protocol elements (signaling code points, FRR, etc)
may be turned off, and no new devices need to support these elements.
In this second model, the questions to be addressed concern the co- - protocol interworking or mapping (only with GMPLS-PSC)
existence of the two protocol sets within the network. Actual
interworking is not a concern.
The integrated migration model results in a single network in which 4.1.2. Unbalanced Islands
both MPLS-capable and MPLS-GMPLS-capable LSRs co-exist. Some LSRs
will be capable of only MPLS, and some of both MPLS and GMPLS. The
migration strategy here involves introducing MPLS-GMPLS-capable LSRs
into an existing MPLS-capable network (i.e. upgrading MPLS LSRS)
until all LSRs are MPLS-GMPLS-capable at which time all MPLS
functionalities can be disabled, and there are no interworking issues
in the data plane. In the control plane, the migration issues concern
the separation of MPLS and GMPLS protocols, and the choice of routes
that may be signaled with only one protocol.
4.1.3. Phased model As just mentioned, there are two island interworking models
consisting of abutting islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC)
islands 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
mapping. Figure 2 shows the reference model for this migration
scenario. Head-end and tail-end LSR 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 island model, a GMPLS-capable device does not support the MPLS
protocols except border nodes , while in the integrated model there
are two types of node present during migration:
- those that support MPLS only (legacy nodes)
- those that support MPLS and GMPLS.
In the island model only island border nodes may support both MPLS
and GMPLS while in the integrated model all GMPLS LSRs also support
MPLS.
That is, in integrated model, existing MPLS devices are upgraded to
support both MPLS and GMPLS. The network continues to provide MPLS
services, and also offers GMPLS services. So, where one end point of
a service is a legacy MPLS node, the service is supported using MPLS
protocols. Similarly, where the selected path between end points
traverses a legacy node that is not GMPLS-capable, MPLS protocols are
used. But where the service can be provided using only GMPLS-capable
nodes, it may be routed accordingly and can achieve a higher level of
functionality by utilizing GMPLS features.
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 elements.
In this model, the questions to be addressed concern the co-existence
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 The phased model introduces GMPLS features and protocol elements into
an MPLS network one by one. For example, some object or sub-object an MPLS network one by one. For example, some object or sub-object
(such as the ERO label sub-object, [RFC3473]) might be introduced (such as the ERO label sub-object, [RFC3473]) might be introduced
into the signaling used by LSRs that are otherwise MPLS-capable. This into the signaling used by LSRs that are otherwise MPLS-capable. This
would produce a kind of hybrid LSR. would produce a kind of hybrid LSR.
This approach may appear simpler to implement as one is able to This approach may appear simpler to implement as one is able to
quickly and easily pick up key new functions without needing to quickly and easily pick up key new functions without needing to
upgrade the whole protocol implementation. upgrade the whole protocol implementation. It is most likely to be
used where there is a desire to rapidly implement a particular
The interoperability concerns (e.g. LABEL REQUEST object [RFC3473] function within a network without the necessity to install and test
and LABEL object [RFC3209], for RSVP-TE signaling) though are the full GMPLS function.
exacerbated by this migration model, unless all LSRs in the network
are updated simultaneously.
Interworking between a hybrid LSR and an unchanged MPLS LSR would put Interoperability concerns are exacerbated by this migration model,
the hybrid in the role of a GMPLS LSR as described in the previous unless all LSRs in the network are updated simultaneously and there
sections, while interworking between a hybrid LSR and a GMPLS LSR is a clear understanding of which subset of features are to be
puts the hybrid in the role of an MPLS LSR. The potential for included in the hybrid LSRs. Interworking between a hybrid LSR and an
different hybrids within the network will complicate matters unchanged MPLS LSR would put the hybrid in the role of a GMPLS LSR as
considerably. Thus, this piecemeal migration from MPLS to GMPLS is described in the previous sections and puts the hybrid in the role of
NOT RECOMMENDED. an MPLS LSR. The potential for different hybrids within the network
will complicate matters considerably.
4.2. Migration strategies 5. Migration Strategies and Solutions
An appropriate migration strategy is selected based on various An appropriate migration strategy is selected by a network operator
factors including the service provider's network deployment plan, based on factors including the service provider's network deployment
customer demand, available network equipment, operational policy, etc. plan, customer demand, existing network equipment, operational 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 or partial depend upon the final objective (full GMPLS capability, partial
upgrade to include specific GMPLS features or no change of 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).
For PSC networks supported 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 or underneath the legacy MPLS-based networks. Subsequently, the into or underneath the legacy MPLS-based networks. Subsequently, the
legacy MPLS-based PSC network is migrated to be GMPLS-capable as legacy MPLS-based PSC network is migrated to be GMPLS-capable as
described in the previous paragraph. Finally the entire network, described in the previous paragraph. Finally the entire network,
including both PSC and non-PSC nodes, may be controlled by GMPLS. including both PSC and non-PSC nodes, may be controlled by GMPLS.
The second strategy for PSC and non-PSC networks is to migrate from The second strategy for PSC and non-PSC networks is to migrate from
skipping to change at page 9, line 5 skipping to change at page 9, line 42
when the entire PSC network is completely converted to GMPLS, GMPLS- when the entire PSC network is completely converted to GMPLS, GMPLS-
based non-PSC devices and networks may be introduced without any based non-PSC devices and networks may be introduced without any
issues of interworking between MPLS and GMPLS. issues of interworking between MPLS and GMPLS.
These migration strategies and the migration models described in the These migration strategies and the migration models described in the
previous section are not necessarily mutually exclusive. Mixtures of previous section are not necessarily mutually exclusive. Mixtures of
all strategies and models could be applied. The migration models and all strategies and models could be applied. The migration models and
strategies selected will give rise to one or more of the interworking strategies selected will give rise to one or more of the interworking
cases described in the following section. cases described in the following section.
5. Island model interworking cases 5.1. Solutions Toolkit
5.1. MPLS-GMPLS(PSC)-MPLS Islands
The migration of an MPLS-based packet network to become a GMPLS
(PSC)-based network may be performed to provide GMPLS-based advanced
features in the network, or to facilitate interworking with a GMPLS-
based optical core network.
The migration may give rise to islands of GMPLS support within a sea
of MPLS nodes such that an end-to-end LSP begins and ends on MPLS-
capable LSRs. The GMPLS PSC island may be used to "hide" islands of
GMPLS non-PSC functionality that are completely contained within the
GMPLS PSC islands. This would protect the MPLS LSRs from having to be
aware of non-PSC technologies.
5.2. MPLS-GMPLS(non-PSC)-MPLS Islands
The introduction of a GMPLS-based controlled optical core network to
increase the capacity of a MPLS packet network is an example that may
give rise to this scenario. Until the MPLS network is upgraded to be
GMPLS-capable, the MPLS and GMPLS networks must interwork. The
interworking challenges may be reduced by wrapping the non-PSC GMPLS
island entirely within a GMPLS PSC island as described in the
previous section.
5.3. GMPLS(PSC)-MPLS-GMPLS(PSC) Islands
This case might arise as the result of installing new GMPLS-capable
islands around a legacy MPLS network, or as the result of controlled
migration of some islands to become GMPLS-capable.
5.4. GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) Islands
This case is out of scope for this document. Since the MPLS island is
necessarily packet capable (i.e. PSC), this scenario requires that
non-PSC LSPs are carried across a PSC network. Such a situation does
not arise through simple control plane migration, although the
interworking scenario might occur for other reasons, and be supported,
for example, by pseudo wires.
5.5. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) Islands
These 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. Some signaling and
routing conversion is required on island border LSRs. Figure 2 shows
the reference model for this migration scenario. Head-end and tail-
end LSR are in distinct control plane clouds.
Since both islands are PSC there is no data plane conversion at the
island boundaries. However, from a control plane point of view this
model may prove challenging because the protocols must share or
convert information between the islands rather than tunnel it across
an island.
............................. .............................
: MPLS : : GMPLS (PSC) :
:+---+ +---+ +---+ +---+ +---+:
:|R1 |________|R11|________|G1 |________|G3 |________|G5 |:
:+---+ +---+ +---+ +-+-+ +---+:
: ______/ | ______/ : : ______/ | ______/ :
: / | / : : / | / :
:+---+ +---+ +---+ +-+-+ +---+:
:|R2 |________|R21|________|G2 |________|G4 |________|G6 |:
:+---+ +---+ +---+ +---+ +---+:
:...........................: :...........................:
|<-------------------------------------------------->|
e2e LSP
Figure 2 GMPLS-MPLS interworking model.
It is also important to underline that this scenario is also impacted
by the directionality of the LSP, and the direction in which the LSP
is established. Indeed, a unidirectional packet LSP from R1 to G5 is
more easily accommodated at G1 than a bidirectional PSC LSP from G5
to R1.
6. Interworking issues between MPLS and GMPLS
As described in the previous sections, interworking between MPLS and As described in the previous sections, an essential part of a
GMPLS may form an essential part of a migration and deployment migration and deployment strategy is how the MPLS and GMPLS or hybrid
strategy. This section sets out some of the alternatives for LSRs interwork. This section sets out some of the alternatives for
achieving interworking between MPLS and GMPLS, and points out some of achieving interworking between MPLS and GMPLS, and points out some of
the issues that need to be addressed if the alternatives are adopted. the issues that need to be addressed if the alternatives are adopted.
This document does not describe solutions to these issues. This document does not describe solutions to these issues.
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.
6.1. Signaling 5.1.1. Layered Networks
Signaling protocols are used to establish LSPs and are the principal
concern for interworking. This section outlines some of the issues
that may arise when MPLS and GMPLS signaling interworking is
attempted. Solutions to these issues will be described in separate
documents, but possibly rely on tunneling techniques (as described
above) or message mapping.
6.1.1. GMPLS specific RSVP objects and Messages
GMPLS RSVP-TE signaling ([RFC3473]) introduces new RSVP-TE objects,
and their associated procedures, that are not processed/generated by
MPLS LSRs. Clearly an MPLS LSR cannot be expected to originate LSPs
that use these objects and will, therefore, not have access to the
additional GMPLS functions. However, the new RSVP-TE objects listed
below need to be handled in interworking scenarios where the LSP
ingress and/or egress is GMPLS-capable, and MPLS LSRs are required to
process the signaling messages:
o The (Generalized) Label Request object (new C-Type), used to
identify the LSP encoding type, the switching type and the
generalized protocol ID (G-PID) associated with the LSP.
o The (Generalized) Label object (new C-Type)
o The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID
ERO/RRO sub objects that handle the Control plane/Data plane
separation in GMPLS network.
o The Suggested Label Object, used to reduce LSP setup delays.
o The Label Set Object, used to restrict label allocation to a set
of labels, (particularly useful for wavelength conversion
incapable nodes)
o The Upstream Label Object, used for bidirectional LSP setup
o The Restart Cap object, used for graceful restart.
o The Admin Status object, used for LSP administration, and
particularly for graceful LSP teardown.
o The Recovery Label object used for Graceful Restart
o The Notify Request object used to solicit notification of errors
and events.
o The Protection and Association objects used for LSP recovery
Future GMPLS extensions are likely to add further new objects.
Some of these objects can be passed transparently by MPLS LSRs to
carry them across MPLS islands because their C-Nums are of the form
11bbbbbb, but others would cause an MPLS LSR to reject the message
that carries them because their C-Nums are of the form 0bbbbbbb.
Even when objects are inherited from MPLS by GMPLS they can be
expected to cause problems. For example, the Label object in GMPLS
uses a new C-Type to indicate 'Generalized Label'. This C-Type is
unknown to MPLS LSRs that will reject any message carrying it.
GMPLS also introduces new message flags and fields (including new
sub-objects and TLVs) that will have no meaning to MPLS LSRs. This
data will normally be forwarded untouched by transit MPLS LSRs, but
they cannot be expected to act on it.
Also GMPLS introduces two new messages, the Notify message, and the
Recovery Path message that are not supported by MPLS nodes.
6.1.1.1. Direct interworking
A possible solution is to allow direct signaling between MPLS and
GMPLS LSRs. However, a fundamental issue is that MPLS and GMPLS use
incompatible code points (C-Types) to request labels (LABEL_REQUEST
and GENERALIZED_LABEL_REQUEST) and to signal labels (LABEL and
GENERALIZED LABEL).
Note, however, that the Phased Model may offer a solution that
resembles signaling interworking. In this approach LSRs are upgraded
to support some GMPLS features but continue to use MPLS code points.
MPLS LSPs may be established across an island of enhanced signaling
capabilities, where some GMPLS features have been added to MPLS LSRs.
This may be relatively simple, and indeed may also be compatible with
the Integrated Model.
On the other hand, enhanced MPLS LSPs (i.e. LSPs signaled using some
GMPLS features) may be carried across an MPLS island. Success in this
case will depend on the particular GMPLS features in use (some
features, such as bi-directionality, cannot be achieved by a native
MPLS network without additional assistance) and the code points that
are used to signal the features (some objects can be carried
transparently across an MPLS network by virtue of their Class Number
encoding, but others will be silently dropped or will cause the
message to be rejected).
6.1.1.2. Mapping
An alternative to interworking signaling protocols is to map each
other between MPLS and GMPLS. That is, to convert the objects carried
in one message to different objects carried in the message that is
actually sent. This mapping would be performed in an upgraded LSR at
island borders since existing LSRs would not be aware of the required
mappings. This mapping is local decision and should be pre-configured
or dynamically done at border nodes.
It would be relatively simple to map signaling messages for LSPs
initiated on MPLS LSRs (MPLS-GMPLS-MPLS and MPLS-GMPLS) since the
LSPs will not need to implement advanced GMPLS features. On the other
hand, however, mapping signaling messages for LSPs initiated by a
GMPLS LSR (GMPLS-MPLS-GMPLS and GMPLS-MPLS) may be considerably
harder depending on the GMPLS features demanded by the LSP. For
example, if the GMPLS LSP is bidirectional, additional function will
be needed at the border LSR that maps the signaling messages in order
to create a pair of unidirectional MPLS LSPs to carry the
bidirectional service across the MPLS network that does not have
native support for bidirectionality. Indeed, in the GMPLS-MPLS case,
a bidirectional service would not be possible unless the egress MPLS
LSR was also upgraded to provide this function.
6.1.1.3. Transfer
A migration strategy may also imply moving an MPLS state to a GMPLS
state. For instance, a LSR hosting MPLS states is upgraded such that
its controller can run both MPLS and GMPLS. In this case, a signaling
mechanism is needed to migrate from the MPLS LSP state to the GMPLS
state.
6.1.2. Bidirectional LSP
GMPLS provides bidirectional LSP setup - a single signaling message
exchange manages the bidirectional LSP, and forward and reverse data
paths follow the same route in the GMPLS network. There is no
equivalent in MPLS networks: forward and backward LSPs must be
created in different signaling sessions - the route taken by those
LSPs may be different from each other, and their sessions are treated
separately. Common routes and fate sharing require additional,
higher-level coordination in MPLS.
If MPLS and GMPLS networks are inter-connected, bidirectional LSPs
from the GMPLS network need to be carried in the MPLS network.
Note that this issue arises only in the cases where an LSP is
originated by GMPLS-capable LSRs. In other words, it applies only to
the GMPLS-MPLS-GMPLS and GMPLS-MPLS island model.
Note that the island border LSRs will bear the responsibility for
achieving the bidirectional service across the central MPLS island.
In the MPLS-GMPLS-MPLS and MPLS-GMPLS models, the ingress LSR is
unaware of the concept of a bidirectional LSP and cannot attempt the
service even if it could find some way to request it through the
network. In the case of GMPLS-MPLS, a similar issue exists because
the egress MPLS-capable LSR is unaware of the concept of
bidirectional LSPs.
6.1.3. Failure recovery
Failure recovery mechanism is provided using different mechanisms in
MPLS (see [RFC4090]) and GMPLS (see [E2E-RECOVERY, SEGMENT-RECOVERY]).
Local protection of island border nodes may be a particular problem.
6.2. Routing
Some attention should also be given to the use of routing protocols
in interworking scenarios since this may allow routing information
from islands to be visible within the surrounding seas.
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" GMPLS LSRs as
though they were PSC LSRs. They will also see other GMPLS information,
but will ignore it, passing it transparently across the MPLS network
for use by other GMPLS LSRs.
This means that MPLS LSRs may use the MPLS information advertised by
MPLS LSRs and GMPLS LSRs to compute a traffic-engineered explicit
route across a mixed network. However, it is likely that a path
computation component in an MPLS network will only be aware of MPLS
TE information and will not understand concepts such as switching
capability type. This may result in that an incorrect path will be
computed for an e2e LSP from one MPLS island to another across a
GMPLS island if different switching capabilities exist.
6.2.1. Interworking of Routing Protocols
GMPLS TE advertisements are based on MPLS TE advertisements with the
addition of extra sub-TLVs. The processing rules for unknown TLVs
mean that they can be ignored by a router, but must be forwarded when
the Link State Advertisement (OSPF LSA or IS-IS LSP) is flooded.
This means that MPLS and GMPLS LSRs may operate as routing peers, and
will redistribute each other's TE information. MPLS LSRs will be
granted full TE visibility at an MPLS level into GMPLS islands, while
GMPLS LSRs will have limited (i.e. MPLS-level) TE visibility into
MPLS islands.
This type of routing exchange may be very useful in particular for
MPLS-GMPLS-MPLS PSC networks. GMPLS LSRs, however, must either modify
their computation algorithms or must generate appropriate defaults
for GMPLS TE parameters that are not advertised by MPLS LSRs.
6.2.2. Mapping of Routing Protocols
The alternatives to interworking routing protocols are to impose
protocol boundaries (such as routing area, AS boundaries) or to
attempt to map the protocol advertisements as they cross island
borders. This latter option is simple for advertisements coming from
GMPLS islands since the GMPLS sub-TLVs may be discarded, but is
pointless because those sub-TLVs are benign within the MPLS network
and are impossible to accurately recreate on re-entry into a GMPLS
network. On the other hand, advertisements initiated by MPLS LSRs
could have default GMPLS sub-TLVs added when they are flooded into a
GMPLS network. These defaults would be similar to those described in
the previous section, and would have the advantage that GMPLS LSRs
within the network (i.e. not border nodes) would not need to apply
the defaults. Care is needed to ensure that the mechanism for
applying defaults is identical on all border nodes.
Note that any alternative using routing protocol mapping relies on
each border LSR knowing which neighbors are MPLS or GMPLS capable.
6.3. Layered Networks
In addition to the difference between MPLS and GMPLS protocols,
control and data plane separation needs to be considered at the
boundary of PSC and non-PSC domains.
Note that the boundary of PSC and non-PSC domains may or may not be
coincident with the boundary of MPLS and GMPLS domains. In the case
where the boundaries are not coincident, the boundary between the PSC
and non-PSC domains must exist in the GMPLS domain because the MPLS
domain cannot support a non-PSC data plane. Here we distinguish two
cases: interworking between PSC and non-PSC networks, and
interworking between MPLS and GMPLS networks.
Figure 3 shows the network model, where the ingress PSC domain and In the balanced island model, LSP tunnels [RFC4206] is a solution to
the egress PSC domains are interconnected via the transit non-PSC carry the end-to-end LSPs across islands of incompatible nodes.
domain. 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 technologies can
be usefully applied to this situation [RFC3945], [RFC4206], and
[INTER-DOM]. [MLN-REQ] gives a discussion of the requirements for
multi-layered networks.
................. .............................. .................. The GMPLS architecture [RFC3945] identifies three architectural
: Ingress PSC : : Transit non-PSC : : Egress PSC : models for supporting multi-layer GMPLS networks, and these models
:+---+ +---+ +---+ +---+ +---+ +---+ +---+: may be applied to the separation of MPLS and GMPLS control plane
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |: islands.
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
: / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
Figure 3 Interworking of PSC and non-PSC domains. - 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.
In the PSC domain, the control plane traffic (signaling and routing) Signaling in the peer model may result in contiguous LSPs,
is carried in-band with data. This means that there is fate sharing stitched LSPs (only for GMPLS PSC), or nested LSPs. If the network
between a data link and the control traffic on the link. On the other islands are non-PSC then the techniques of [MLN] may be applied,
hand, in the non-PSC domain (TDM, LSC, and FSC domains), where packet and these techniques may be extrapolated to networks where all
delineation is not recognized, and in-band control channels cannot be nodes are PSC, but where there is a difference in signaling
terminated, dedicated control channels (separated from the data protocols.
channels) are used. In the non-PSC domain, the control channel can be
logically or physically separated (i.e., in-fiber out-of-band or out-
of-fiber out-of-bound) from the data channel depending on the
capabilities of the network devices and the operational requirements.
A dedicated control channel must not be used to carry user data - The overlay model preserves strict separation of routing
traffic. This is particularly important when the control channels are information between network layers. This is suitable for the
of low capacity and are not designed to carry user traffic. 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.
A possible method to protect the control plane channel of a non-PSC The overlay model requires the establishment of control plane
domain is that packets coming from PSC domains are not allowed to use connectivity for the higher layer across the lower layer.
the control plane channel. The method, however, causes another
problem: lack of signaling and routing adjacencies across the non-PSC
domain.
This problem is explained using Fig. 3. LSAs in the egress PSC domain - The augmented model allows limited routing exchange from the lower
are not advertised in the ingress PSC domain unless routing layer network to the higher layer network. Generally speaking,
adjacencies are established between the PSC domain and non-PSC domain this assumes that the border nodes provide some form of filtering,
or unless routing adjacencies are established directly between PSC mapping or aggregation of routing information advertised from the
domains. Therefore the ingress LSR in the ingress PSC domain is not lower layer network. This architectural model can also be used for
able to find the egress LSR in the egress PSC domain unless these balanced island model migrations. Signaling interworking is
adjacencies are formed. The signaling messages are not passed across required as described for the peer model.
the non-PSC domain between the ingress and the egress PSC domains
unless the signaling adjacencies are established between the PSC
domain and the non-PSC domain or directly between PSC domains.
Interworking between PSC and non-PSC networks can be regarded as a - The border peer architecture model is defined in [MPLS-OVER-GMPLS].
layered network. Layered networks are described in many places This is a modification of the augmented model where the layer
including [RFC3945] and [RFC4206]. [MRN-REQ] gives a good background border routers have visibility into both layers, but no routing
and discusses some of the requirements for multi-layered networks. information is otherwise exchanged between models. 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.
Network layering is often used to separate domains of different data 5.1.2. Routing Interworking
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 technologies can
be usefully applied to this situation.
The GMPLS architecture [RFC3945] identifies three architectural Migration strategies may necessitate some interworking between MPLS
models for supporting multi-layer GMPLS networks, and these models and GMPLS routing protocols. GMPLS extends the TE information
may be applied to the separation of MPLS and GMPLS control plane advertised by the IGPs to include non-PSC information and extended
islands. The applicability of the different migration models to the PSC information. Because the GMPLS information is provided as
three architectural models may provide additional input to the choice additional TLVs that are carried along with the MPLS information,
of an architectural model. 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.
6.3.1. Peer Model - 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.
In the peer model, both MPLS and GMPLS nodes run the same routing - Direct distribution involves the flooding of MPLS routing
instance and routing advertisements, from within islands of one level information into a GMPLS network, and GMPLS routing information
of protocol support are distributed to the whole network. This is into an MPLS network. The border nodes make no attempt to filter
achievable as described in section 6.2 either by direct distribution the information. This mode of operation relies on the fact that
or by mapping of parameters. 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, and 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.
If the entire network (MPLS and GMPLS capable LSRs) is PSC, signaling GMPLS LSRs might be impacted by the absence of GMPLS-specific
may establish end-to-end LSPs using the techniques described in information in advertisements initiated by MPLS LSRs. Specific
section 6.1. On the other hand, if the GMPLS network is of some other procedures might be required to ensure consistent behavior by
switching type, or if the protocol islands are managed as separate GMPLS nodes. If this issue is addressed, then direct distribution
network layers, the signaling request can give rise to the creation can be used in all migration models (except the overlay and border
of a hierarchical LSP [RFC4206] or stitching segment [STITCH] that peer architectural models where the problem does not arise).
spans an island and is triggered when the LSP request reaches the
island border. The end-to-end LSP from the higher layer network (the
protocol sea) is carried across the lower layer network (the protocol
island) by the tunnel or stitching segment.
Note that an MPLS sea is not capable of determining whether the - Protocol mapping converts routing advertisements so that they can
entire network is of the same switching type and will consequently be received in one protocol and transmitted in the other. For
attempt to signal end-to-end LSPs assuming them to be PSC all the way. example, a GMPLS routing advertisement could have all of its
This requires that the island border take the appropriate action to GMPLS-specific information removed and could be flooded as an MPLS
set up tunnels across islands of different switching capabilities. 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
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.
6.3.2. Overlay Model - 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.
The overlay model preserves strict separation of routing information 5.1.3. Signaling Interworking
between network layers. Thus, in the interworking case, there is no
requirement to handle routing interworking. Signaling interworking is
still required as described in section 6.1.
Note, however, that there is a requirement to create signaling higher Signaling protocols are used to establish LSPs and are the principal
layer adjacencies between island border nodes, and that it is highly concern for interworking during migration. Issues of compatibility
desirable to create routing adjacencies in the same way. Such arise because of simple changes in the encodings and codepoints used
adjacencies may use the control plane of the lower layer network and by MPLS and GMPLS signaling, but also because of changes in function
be independent of the existence of data plane connectivity across the levels provided by MPLS and GMPLS.
lower layer network. Care may be required to prevent the swamping of
the lower layer control plane when it has limited capacity.
Alternatively, such adjacencies may rely on the existence of data
plane connectivity across the lower layer network.
6.3.3. Augmented Model - Tunneling and stitching (GMPLS-PSC case) mechanisms are a good way
to avoid any requirement for 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 must
be carried 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.
The augmented model allows limited routing exchange from the lower Note that tunneling and stitching are not available in unbalanced
layer network to the higher layer network. Generally speaking, this island models because in these cases the LSP end points use
assumes that the border nodes provide some form of filtering, mapping different protocol variants.
or aggregation of routing information advertised from the lower layer
network, and this is compatible with the mechanisms described in
section 6.2.2.
Note however, that part of this assumption allows the border nodes to - Protocol mapping is the conversion of signaling messages between
have full visibility into both the higher and lower layer networks MPLS and GMPLS variants. This mechanism requires careful
without further advertising the information from the lower layer documentation of the protocol fields and how they are mapped, but
network to the higher layer network meaning that no mapping or is relatively simple in the MPLS-GMPLS unbalanced island model.
interworking of routing protocols is required. Particularly, this However, the MPLS-GMPLS island model may manifest as the GMPLS-
includes the case where MPLS and GMPLS clouds run distinct routing MPLS model for LSPs signaled in the opposite direction and this
instances, and the border nodes run both routing instances. will 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 or mis-requests.
Note that the same observations about routing and signaling - Ships in the night could be used in the integrated migration model
adjacencies apply as for the overlay 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 play
a part in either case, but no conversion of protocols would be
applied.
7. Manageability Considerations 6. Manageability Considerations
Some attention should be given during migration planning to how the Attention should be given during migration planning to how the
network will be managed during and after migration. For example, will network will be managed during and after migration. For example, will
the LSRs of different protocol capabilities be managed separately or the LSRs of different protocol capabilities be managed separately or
as a whole. This is most clear in the Island Model where it is as a whole. This is most clear in the Island Model where it is
possible to consider managing islands of one capability separately possible to consider managing islands of one capability separately
from the surrounding sea. In the case of islands that have different from the surrounding sea. In the case of islands that have different
switching capabilities, it is possible that the islands already had switching capabilities, it is possible that the islands already had
different management in place before the migration: the resultant different management in place before the migration: the resultant
migrated network may seek to merge the management or to preserve it. migrated network may seek to merge the management or to preserve it.
7.1. Control of Function and Policy 6.1. Control of Function and Policy
The most important control to be applied is at the moment of The most important control to be applied is at the moment of
changeover between different levels of protocol support. Such a changeover between different levels of protocol support. Such a
change may be made dynamically or during a period of network change may be made dynamically or during a period of network
maintenance. 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.
7.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 variants of management applications to support both MPLS and GMPLS variants of
management data. management 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
protocols and build on the MPLS MIB modules through extensions and protocols and build on the MPLS MIB modules through extensions and
augmentations. This may make it possible to migrate management augmentations. This may make it possible to migrate management
applications ahead of the LSRs that they manage. applications ahead of the LSRs that they manage.
7.3. Liveness Detection and Monitoring 6.3. Liveness Detection and Monitoring
Migration will not imposes additional issues for OAM above those that Migration will not imposes additional issues for OAM above those that
already exist for inter-domain OAM and for OAM across multiple already exist for inter-domain OAM and for OAM across multiple
switching capabilities. switching capabilities.
Note, however, that if a flat PSC MPLS network is migrated using the 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 island model, and is treated as a layered network using tunnels to
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
may be described in more detail in a later version. may be described in more detail in a later version.
7.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. Principally, the process of migration may introduce monitoring. Principally, the process of migration may introduce
tunneling or stitching into what was previously a flat network. tunneling or stitching into what was previously a flat network.
7.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
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.
7.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.
A network manager may prefer the island model especially when A network manager may prefer the island model especially when
migration will extend over a significant operational period because migration will extend over a significant operational period because
it allows the different network islands to be administered as it allows the different network islands to be administered as
separate management domains. This is particularly the case in the separate management domains. This is particularly the case in the
overlay and augmented network models where the details of the overlay and augmented network models where the details of the
protocol islands remain hidden from the surrounding LSRs. protocol islands remain hidden from the surrounding LSRs.
7.7. Other Considerations 6.7. Other Considerations
No other management considerations arise. 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.
8. Security Considerations 7. Security Considerations
Security and confidentiality is often applied (and attacked) at Security and confidentiality is often applied (and attacked) at
administrative boundaries. Some of the models described in this administrative boundaries. Some of the models described in this
document introduce such boundaries, for example between MPLS and document introduce such boundaries, for example between MPLS and
GMPLS islands. These boundaries offer the possibility of applying or GMPLS islands. These boundaries offer the possibility of applying or
modifying the security as one might when crossing an IGP area or AS modifying the security as one might when crossing an IGP area or AS
boundary, even though these island boundaries might lie within an IGP boundary, even though these island boundaries might lie within an IGP
area or AS. area or 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 issues with security in interworking changes. Hence, there will be no issues with security in interworking
scenarios. Further, since the MPLS and GMPLS signaling and routing scenarios. Further, since the MPLS and GMPLS signaling and routing
security is provided on a hop-by-hop basis, and since all signaling security is provided on a hop-by-hop basis, and since all signaling
and routing exchanges described in this document for use between any 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 pair of LSRs are based on either MPLS or GMPLS, there are no changes
necessary to the security procedures. necessary to the security procedures.
9. IANA Considerations 8. IANA Considerations
This information framework document makes no requests for IANA action. This informational framework document makes no requests for IANA
action.
10. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
"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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
11. Intellectual Property 10. 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.
skipping to change at page 22, line 18 skipping to change at page 17, line 13
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
12. Acknowledgements 11. 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. initial work on this document. The authors are grateful to Dean Cheng
for his valuable comments.
13. Authors' Addresses 12. Authors' Addresses
Kohei Shiomoto 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
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
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.be
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom R&D 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@francetelecom.com Email: jeanlouis.leroux@orange-ft.com
Deborah Brungard Deborah Brungard
AT&T AT&T
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1 732 420 1573 Phone: +1 732 420 1573
Email: dbrungard@att.com Email: dbrungard@att.com
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Garden Air Tower Garden Air Tower
Iidabashi, Chiyoda-ku, Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN Tokyo 102-8460, JAPAN
Phone: +81-3-6678-3103 Phone: +81-3-6678-3103
Email: ke-kumaki@kddi.com Email: ke-kumaki@kddi.com
14. References Zafar Alli
Cisco Systems, Inc.
EMail: zali@cisco.com
14.1. Normative References 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
13. References
13.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.
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions
to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[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.
skipping to change at page 24, line 35 skipping to change at page 19, line 43
[E2E-RECOVERY] Lang, J. P., Rekhter, Y., Papadimitriou, D. (Editors), [E2E-RECOVERY] 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 draft-ietf-ccamp-gmpls-recovery-e2e-signaling, work in
progress. progress.
[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.
14.2. Informative References [TE-NODE-CAPS] Vasseur, Le Roux, editors " IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node Capabilities",
draft-ietf-ccamp-te-node-cap, work in progress.
[MRN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, 13.2. Informative References
[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.
[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.
[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-
 End of changes. 93 change blocks. 
664 lines changed or deleted 427 lines changed or added

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