draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt   draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02.txt 
Network Working Group Kohei Shiomoto(NTT) Network Working Group Kohei Shiomoto(Editor)
Internet Draft Dimitri Papadimitriou(Alcatel) Internet Draft (NTT)
Proposed Category: Informational Jean-Louis Le Roux(France Telecom) Proposed Category: Informational
Expires: October 2006 Deborah Brungard (AT&T) January 2007
Kenji Kumaki (KDDI)
Zafar Ali (Cisco)
Eiji Oki(NTT)
Ichiro Inoue(NTT)
Tomohiro Otani (KDDI)
Framework for MPLS-TE to GMPLS migration Framework for MPLS-TE to GMPLS migration
draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-01.txt draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-02.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 44 skipping to change at page 1, line 40
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
The migration from Multiprotocol Label Switching (MPLS) Traffic The migration from Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) to Generalized MPLS (GMPLS) is the process of Engineering (TE) to Generalized MPLS (GMPLS) is the process of
evolving an MPLS-TE control plane to a GMPLS control plane. An evolving an MPLS-TE control plane to a GMPLS control plane. An
appropriate migration strategy can be selected based on various appropriate migration strategy will be selected based on various
factors including the service provider's network deployment plan, factors including the service provider's network deployment plan,
customer demand, and operational policy. customer demand, and operational policy.
This document presents several migration models and strategies for This document presents several migration models and strategies for
migrating from MPLS-TE to GMPLS and notes that in the course of migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE
migration MPLS-TE and GMPLS devices or networks may coexist which may and GMPLS devices, or networks, may coexist which may require
require interworking between MPLS-TE and GMPLS protocols. The interworking between MPLS-TE and GMPLS protocols. Aspects of the
applicability? of the interworking that is required is discussed as interworking required are discussed as it will influence the choice
it appears to influence the choice of a migration strategy. 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.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................2
2. Conventions Used in This Document..............................3 2. Conventions Used in This Document..............................3
3. Motivations for Migration......................................4 3. Motivations for Migration......................................4
4. MPLS to GMPLS Migration Models.................................5 4. MPLS to GMPLS Migration Models.................................4
4.1. Island model..............................................5 4.1. Island model..............................................5
4.1.1. Balanced Islands.....................................6 4.1.1. Balanced Islands.....................................6
4.1.2. Unbalanced Islands...................................6 4.1.2. Unbalanced Islands...................................6
4.2. Integrated model..........................................7 4.2. Integrated model..........................................7
4.3. Phased model..............................................8 4.3. Phased model..............................................8
5. Migration Strategies and Solutions.............................9 5. Migration Strategies and Solutions.............................8
5.1. Solutions Toolkit.........................................9 5.1. Solutions Toolkit.........! .................
5.1.1. Layered Networks....................................10 Layered Networks...........................................9
- The overlay model preserves strict separation of routing 5.1.1.......................................................9
information between network layers. This is suitable for the
balanced island model and there is no requirement to handle
routing interworking. Signaling interworking is still required
as described for the peer model. The overlay model requires
the establishment of control plane connectivity for the higher
layer across the lower layer...............................10
5.1.2. Routing Interworking................................11 5.1.2. Routing Interworking................................11
5.1.3. Signaling Interworking..............................12 5.1.3. Signaling Interworking..............................12
6. Manageability Considerations..................................13 6. Manageability Considerations..................................13
6.1. Control of Function and Policy...........................13 6.1. Control of Function and Policy...........................13
6.2. Information and Data Models..............................14 6.2. Information and Data Models..............................14
6.3. Liveness Detection and Monitoring........................14 6.3. Liveness Detection and Monitoring........................14
6.4. Verifying Correct Operation..............................14 6.4. Verifying Correct Operation..............................14
6.5. Requirements on Other Protocols and Functional Components14 6.5. Requirements on Other Protocols and Functional Components14
6.6. Impact on Network Operation..............................15 6.6. Impact on Network Operation..............................15
6.7. Other Considerations.....................................15 6.7. Other Considerations.....................................15
7. Security Considerations.......................................15 7. Security Considerations.......................................15
8. Recommendations for Migration.................................16 8. IANA Considerations...........................................16
9. IANA Considerations...........................................16 9. Acknowledgements..............................................16
10. Full Copyright Statement.....................................16 10. Editor's Addresses...........................................17
11. Intellectual Property........................................16 11. Authors' Addresses...........................................17
12. Acknowledgements.............................................17 12. References...................................................18
13. Authors' Addresses...........................................18 12.1. Normative References....................................18
14. References...................................................19 12.2. Informative References..................................19
14.1. Normative References....................................19 13. Full Copyright Statement.....................................19
14.2. Informative References..................................20 14. Intellectual Property........................................19
1. Introduction 1. Introduction
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to
Generalized MPLS (GMPLS) migration is the process of evolving an Generalized MPLS (GMPLS) migration is the process of evolving an
MPLS-TE-based control plane to a GMPLS-based control plane. The MPLS-TE-based control plane to a GMPLS-based control plane. The
network under consideration is, therefore, a packet-switching network. network under consideration for migration is, therefore, a packet-
switching network.
There are several motivations for such migration and they focus There are several motivations for such migration, mainly the desire
mainly on the desire to take advantage of new features and functions to take advantage of new features and functions added to the GMPLS
that have been added to the GMPLS protocols but which are not present protocols and which are not present in MPLS-TE for packet networks.
in MPLS-TE. 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, and 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 can be selected based on Although an appropriate migration strategy will 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, deployed network equipments, operational plan, customer demand, deployed network equipments, operational
policy, etc., the transition mechanisms used should also provide policy, etc., the transition mechanisms used should also provide
consistent operation of GMPLS networks while minimizing the impact on consistent operation of newly introduced GMPLS networks, while
the operation of existing MPLS-TE networks. minimizing the impact on the operation of existing MPLS-TE networks.
In the course of migration MPLS-TE and GMPLS devices or networks may
need to coexist. Such cases may occur as parts of the network are
migrated from MPLS-TE protocols to GMPLS protocols. Additionally, as
part of the preparation for migrating a packet-switching network from
MPLS-TE to GMPLS, it may be desirable to first migrate a lower-layer
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 describes several migration strategies and shows the This document describes several migration strategies and the
interworking scenarios that arise during migration, and examines the interworking scenarios that arise during migration. It also examines
implications for network deployments and for protocol usage. Since the implications for network deployments and for protocol usage. As
GMPLS signaling and routing protocols are different from the MPLS-TE the GMPLS signaling and routing protocols are different from the
control protocols, interworking between MPLS-TE and GMPLS networks or MPLS-TE control protocols, interworking mechanisms between MPLS-TE
network elements needs mechanisms to compensate for the differences. and GMPLS networks, or network elements, may be needed to compensate
for the differences.
Note that MPLS-TE 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. night" without any interworking issue.
Also note that, in this document, the term "MPLS" is used to refer to
MPLS-TE protocols only ([RFC3209], [RFC3630], [RFC3473]) and excludes
other MPLS protocols such as the Label Distribution Protocol (LDP).TE
functionalities of MPLS could be migrated to GMPLS-TE, but non-TE
functionalities could not.
2. Conventions Used in This Document 2. Conventions Used in This Document
This is not a requirements document, nevertheless the key words This is not a requirements document, nevertheless the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC 2119 [RFC2119] in order to are to be interpreted as described in RFC 2119 [RFC2119] in order to
clarify the recommendations that are made. 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
switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS" switching capable (PSC) and non-PSC. Otherwise the term "PSC GMPLS"
or "non-PSC GMPLS" is explicitly used. or "non-PSC GMPLS" is explicitly used.
In general, the term "MPLS" is used to indicate MPLS traffic In general, the term "MPLS" is used to indicate MPLS traffic
engineering (MPLS-TE). If non-TE MPLS is intended, it is explicitly engineering (MPLS-TE) only ([RFC3209], [RFC3630], [RFC3784]) and
indicated. 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
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 [RFC3945]. in [RFC3945].
3. Motivations for Migration 3. Motivations for Migration
Motivations for migration will vary for different service providers. Motivations for migration will vary for different service providers.
This section is only presented to provide background so that the This section is presented to provide background so that the migration
migration discussions may be seen in the context. Sections 4 and 5 discussions may be seen in context. Sections 4 and 5 provide examples
illustrate the migration models and processes with possible examples. to illustrate the migration models and processes.
Migration of an MPLS-capable LSR to include GMPLS capabilities may be Migration of an MPLS-capable LSR to include GMPLS capabilities may be
performed for one or more reasons, including, no exhaustively: performed for one or more reasons, including, not exhaustively:
o To add all GMPLS capabilities to an existing MPLS network. o To add all GMPLS PSC features to an existing MPLS network (upgrade
MPLS LSRs).
o To add a GMPLS network without upgrading existing MPLS PSC LSRs. o To add specific GMPLS PSC features and operate them within an MPLS
network.
o To pick up specific GMPLS features and operate them within an MPLS o To integrate a new GMPLS PSC network with an existing MPLS network
PSC network. (without upgrading any of the MPLS LSRs).
o To allow existing MPLS-capable LSRs to interoperate with new LSRs o To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs
that only support GMPLS. supporting only GMPLS PSC and/or non-PSC features.
o To integrate multiple networks managed by separate administrative o To integrate multiple control networks, e.g. managed by separate
organizations, which independently utilize MPLS or GMPLS. administrative organizations, and 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. The non-PSC networks
networks can only be controlled by GMPLS since MPLS does not are controlled by GMPLS.
operate in non-PSC networks.
It must be understood that the ultimate objective of migration from The objective of migration from MPLS to GMPLS is that all LSRs, and
MPLS to GMPLS is that all LSRs and the entire network end up running the entire network, support GMPLS protocols. During this process,
GMPLS protocols. During this process various interim situations may various interim situations may exist, giving rise to the interworking
exist giving rise to the interworking situations described in this situations described in this document. The interim situations may
document. Those interim situations may persist for considerable exist for considerable periods of time, but the ultimate objective is
periods of time, but the ultimate objective is not to preserve these not to preserve these situations. For the purposes of this document,
situations, and for the purpose of this document, they should be they should be considered as temporary and transitory.
considered as temporary.
4. MPLS to GMPLS Migration Models 4. MPLS to GMPLS Migration Models
Three migration models are described below. Multiple migration models Three reference migration models are described below. Multiple
may co-exists in the same network. migration models may co-exist in the same network.
4.1. Island model 4.1. Island model
In the island model, "islands" of network nodes operating one In the island model, "islands" of network nodes operating one
protocol exist within a "sea" of nodes using the other protocol. protocol exist within a "sea" of nodes using the other protocol.
The most obvious example is to consider an island of GMPLS-capable For example, consider an island of GMPLS-capable nodes (PSC) which is
nodes which is introduced into a legacy MPLS network. Such an island introduced into a legacy MPLS network. Such an island might be
might be composed of newly added GMPLS network nodes, or might arise composed of newly added GMPLS nodes, or might arise from the upgrade
from the upgrade of existing nodes that previously operated MPLS of existing nodes that previously operated MPLS protocols.
protocols. The opposite is also quite possible. That is, there is a
possibility that an island happens to be MPLS-capable within a GMPLS The opposite is also quite possible. That is, there is a possibility
sea. Such a situation might arise in the later stages of migration, that an island happens to be MPLS-capable within a GMPLS sea. Such a
when all but a few islands of MPLS-capable nodes have been upgraded situation might arise in the later stages of migration, when all but
to GMPLS. a few islands of MPLS-capable nodes have been upgraded to GMPLS.
It is also possible that a lower-layer, manually-provisioned network It is also possible that a lower-layer, manually-provisioned network
(for example, a TDM network) supports an MPLS PSC network. During the (for example, a TDM network) is constructed under an MPLS PSC network.
process of migrating both networks to GMPLS, the lower-layer network During the process of migrating both networks to GMPLS, the lower-
might be migrated first. This would appear as a GMPLS island within layer network might be migrated first. This would appear as a GMPLS
an MPLS sea. island within an MPLS sea.
Lastly, it is possible to consider individual nodes as islands. That Lastly, it is possible to consider individual nodes as islands. That
is, it would be possible to upgrade or insert an individual GMPLS- is, it would be possible to upgrade or insert an individual GMPLS-
capable node within an MPLS network, and to treat that GMPLS node as capable node within an MPLS network, and to treat that GMPLS node as
an island. an island.
Over time, collections of MPLS devices are replaced or upgraded to Over time, collections of MPLS devices are replaced or upgraded to
create new GMPLS islands or to extend existing ones, and distinct create new GMPLS islands or to extend existing ones, and distinct
GMPLS islands may be joined together until the whole network is GMPLS islands may be joined together until the whole network is
GMPLS-capable. GMPLS-capable.
From a migration/interworking point of view, we need to examine how From a migration/interworking point of view, we need to examine how
these islands are positioned and how LSPs run between the islands. these islands are positioned and how LSPs connect between the islands.
Four categories of interworking scenarios are considered: (1) MPLS- Four categories of interworking scenarios are considered: (1) MPLS-
GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS. GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS and (4) GMPLS-MPLS.
In case 1 the interworking behavior is examined based on whether the In case 1, the interworking behavior is examined based on whether the
GMPLS islands are PSC or non-PSC. GMPLS islands are PSC or non-PSC.
Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS
interworking. The model consists of a transit GMPLS island in an MPLS interworking. The model consists of a transit GMPLS island in an MPLS
sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and sea. The nodes at the boundary of the GMPLS island (G1, G2, G5, and
G6) are referred to as "island border nodes". If the GMPLS island was G6) are referred to as "island border nodes". If the GMPLS island was
non-PSC, all nodes except the island border nodes in the GMPLS-based non-PSC, all nodes except the island border nodes in the GMPLS-based
transit island (G3 and G4) would be non-PSC devices, i.e., optical transit island (G3 and G4) would be non-PSC devices, i.e., optical
equipment (TDM, LSC, and FSC). equipment (TDM, LSC, and FSC).
skipping to change at page 6, line 38 skipping to change at page 6, line 25
:................: :........................: :................: :................: :........................: :................:
|<-------------------------------------------------------->| |<-------------------------------------------------------->|
e2e LSP e2e LSP
Figure 1 Example of the island model for MPLS-GMPLS-MPLS interworking. Figure 1 Example of the island model for MPLS-GMPLS-MPLS interworking.
4.1.1. Balanced Islands 4.1.1. Balanced Islands
In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end In the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end
using the same protocols. Available strategies include: using the same protocols. Possible strategies include:
- tunneling the signaling across the island network using LSP - tunneling the signaling across the island network using LSP
nesting or stitching (only with GMPLS-PSC) nesting or stitching (the latter is for only with GMPLS-PSC)
- protocol interworking or mapping (only with GMPLS-PSC) - protocol interworking or mapping (both are for only with GMPLS-
PSC)
4.1.2. Unbalanced Islands 4.1.2. Unbalanced Islands
As just mentioned, there are two island interworking models As previously discussed, there are two island interworking models
consisting of abutting islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) which support bordering islands. GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC)
islands cases are likely to arise where the migration strategy is not island cases are likely to arise where the migration strategy is not
based on a core infrastructure, but has edge nodes (ingress or based on a core infrastructure, but has edge nodes (ingress or
egress) located in islands of different capabilities. egress) located in islands of different capabilities.
In this case, an LSP starts or ends in a GMPLS (PSC) island and In this case, an LSP starts or ends in a GMPLS (PSC) island and
correspondingly ends or starts in an MPLS island. This mode of correspondingly ends or starts in an MPLS island. This mode of
operation can only be addressed using protocol interworking or operation can only be addressed using protocol interworking or
mapping. Figure 2 shows the reference model for this migration mapping. Figure 2 shows the reference model for this migration
scenario. Head-end and tail-end LSR are in distinct control plane scenario. Head-end and tail-end LSR are in distinct control plane
clouds. clouds.
skipping to change at page 7, line 41 skipping to change at page 7, line 32
It is important to underline that this scenario is also impacted by It is important to underline that this scenario is also impacted by
the directionality of the LSP, and the direction in which the LSP is the directionality of the LSP, and the direction in which the LSP is
established. established.
4.2. Integrated model 4.2. Integrated model
The second migration model involves a more integrated migration The second migration model involves a more integrated migration
strategy. New devices that are capable of operating both MPLS and strategy. New devices that are capable of operating both MPLS and
GMPLS protocols are introduced into the MPLS network. GMPLS protocols are introduced into the MPLS network.
In the island model, a GMPLS-capable device does not support the MPLS In the integrated model there are two types of nodes present during
protocols except border nodes , while in the integrated model there migration:
are two types of node present during migration:
- those that support MPLS only (legacy nodes)
- those that support MPLS and GMPLS. - support MPLS only (legacy nodes)
In the island model only island border nodes may support both MPLS - support MPLS and GMPLS.
and GMPLS while in the integrated model all GMPLS LSRs also support
MPLS.
That is, in integrated model, existing MPLS devices are upgraded to In this model, as existing MPLS devices are upgraded to support both
support both MPLS and GMPLS. The network continues to provide MPLS MPLS and GMPLS, the network continues to operate with a MPLS control
services, and also offers GMPLS services. So, where one end point of plane, but some LSRs are also capable of operating with a GMPLS
a service is a legacy MPLS node, the service is supported using MPLS control plane. So, LSPs are provisioned using MPLS protocols where
protocols. Similarly, where the selected path between end points one end point of a service is a legacy MPLS node and/or where the
traverses a legacy node that is not GMPLS-capable, MPLS protocols are selected path between end points traverses a legacy node that is not
used. But where the service can be provided using only GMPLS-capable GMPLS-capable. But where the service can be provided using only
nodes, it may be routed accordingly and can achieve a higher level of GMPLS-capable nodes, it may be routed accordingly and can achieve a
functionality by utilizing GMPLS features. higher level of functionality by utilizing GMPLS features.
Once all devices in the network are GMPLS-capable, the MPLS specific Once all devices in the network are GMPLS-capable, the MPLS specific
protocol elements may be turned off, and no new devices need to protocol elements may be turned off, and no new devices need to
support these elements. support these protocol elements.
In this model, the questions to be addressed concern the co-existence In this model, the questions to be addressed concern the co-existence
of the two protocol sets within the network. Actual interworking is of the two protocol sets within the network. Actual interworking is
not a concern. not a concern.
4.3. Phased model 4.3. Phased model
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 objects or sub-objects
(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. It is most likely to be upgrade the whole protocol implementation. It is most likely to be
used where there is a desire to rapidly implement a particular used where there is a desire to rapidly implement a particular
function within a network without the necessity to install and test function within a network without the necessity to install and test
the full GMPLS function. the full GMPLS function.
Interoperability concerns are exacerbated by this migration model, Interoperability concerns though are exacerbated by this migration
unless all LSRs in the network are updated simultaneously and there model, unless all LSRs in the network are updated simultaneously and
is a clear understanding of which subset of features are to be 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 included in the hybrid LSRs. Interworking between a hybrid LSR and an
unchanged MPLS LSR would put the hybrid in the role of a GMPLS LSR as unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS
described in the previous sections and puts the hybrid in the role of LSR as described in the previous sections and puts the unchanged LSR
an MPLS LSR. The potential for different hybrids within the network in the role of an MPLS LSR. The potential for different hybrids
will complicate matters considerably. within the network will complicate matters considerably.
5. Migration Strategies and Solutions 5. Migration Strategies and Toolkit
An appropriate migration strategy is selected by a network operator An appropriate migration strategy is selected by a network operator
based on factors including the service provider's network deployment based on factors including the service provider's network deployment
plan, customer demand, existing network equipment, operational policy, plan, customer demand, existing network equipment, operational policy,
support from its vendors, etc. support from its vendors, etc.
For PSC networks, the migration strategy involves the selection For PSC networks, the migration strategy involves the selection
between the models described in the previous section. The choice will between the models described in the previous section. The choice will
depend upon the final objective (full GMPLS capability, partial depend upon the final objective (full GMPLS capability, partial
upgrade to include specific GMPLS features, or no change to existing upgrade to include specific GMPLS features, or no change to existing
IP/MPLS networks), and upon the immediate objectives (full, phased, IP/MPLS networks), and upon the immediate objectives (full, phased,
or staged upgrade). or staged upgrade).
For PSC networks serviced by non-PSC networks, two basic migration For PSC networks serviced by non-PSC networks, two basic migration
strategies can be considered. In the first strategy, the non-PSC strategies can be considered. In the first strategy, the non-PSC
network is made GMPLS-capable first and then the PSC network is network is made GMPLS-capable, first, and then the PSC network is
migrated to GMPLS. This might arise when, in order to expand the migrated to GMPLS. This might arise when, in order to expand the
network capacity, GMPLS-based non-PSC sub-networks are introduced network capacity, GMPLS-based non-PSC sub-networks are introduced
into or underneath the legacy MPLS-based networks. Subsequently, the into the legacy MPLS-based networks. Subsequently, the legacy MPLS-
legacy MPLS-based PSC network is migrated to be GMPLS-capable as based PSC network is migrated to be GMPLS-capable as described in the
described in the previous paragraph. Finally the entire network, previous paragraph. Finally the entire network, including both PSC
including both PSC and non-PSC nodes, may be controlled by GMPLS. 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
the PSC network to GMPLS first and then enable GMPLS within the non- the PSC network to GMPLS, first, and then enable GMPLS within the
PSC network. The PSC network is migrated as described before, and non-PSC network. The PSC network is migrated as described before, and
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.1. Solutions Toolkit 5.1. Migration Toolkit
As described in the previous sections, an essential part of a As described in the previous sections, an essential part of a
migration and deployment strategy is how the MPLS and GMPLS or hybrid migration and deployment strategy is how the MPLS and GMPLS or hybrid
LSRs interwork. 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 identifies some of
the issues that need to be addressed if the alternatives are adopted. the issues that need to be addressed. This document does not describe
This document does not describe solutions to these issues. 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.
5.1.1. Layered Networks 5.1.1. Layered Networks
In the balanced island model, LSP tunnels [RFC4206] is a solution to In the balanced island model, LSP tunnels [RFC4206] are a solution to
carry the end-to-end LSPs across islands of incompatible nodes. carry the end-to-end LSPs across islands of incompatible nodes.
Network layering is often used to separate domains of different data Network layering is often used to separate domains of different data
plane technology. It can also be used to separate domains of plane technology. It can also be used to separate domains of
different control plane technology (such as MPLS and GMPLS protocols), different control plane technology (such as MPLS and GMPLS protocols),
and the solutions developed for multiple data plane technologies can and the solutions developed for multiple data plane technologies can
be usefully applied to this situation [RFC3945], [RFC4206], and be usefully applied to this situation [RFC3945], [RFC4206], and
[INTER-DOM]. [MLN-REQ] gives a discussion of the requirements for [RFC4726]. [MLN-REQ] gives a discussion of the requirements for
multi-layered networks. multi-layered networks.
The GMPLS architecture [RFC3945] identifies three architectural The GMPLS architecture [RFC3945] identifies three architectural
models for supporting multi-layer GMPLS networks, and these models models for supporting multi-layer GMPLS networks, and these models
may be applied to the separation of MPLS and GMPLS control plane may be applied to the separation of MPLS and GMPLS control plane
islands. islands.
- In the peer model, both MPLS and GMPLS nodes run the same routing - In the peer model, both MPLS and GMPLS nodes run the same routing
instance, and routing advertisements from within islands of one instance, and routing advertisements from within islands of one
level of protocol support are distributed to the whole network. level of protocol support are distributed to the whole network.
skipping to change at page 11, line 11 skipping to change at page 10, line 44
layer network to the higher layer network. Generally speaking, layer network to the higher layer network. Generally speaking,
this assumes that the border nodes provide some form of filtering, this assumes that the border nodes provide some form of filtering,
mapping or aggregation of routing information advertised from the mapping or aggregation of routing information advertised from the
lower layer network. This architectural model can also be used for lower layer network. This architectural model can also be used for
balanced island model migrations. Signaling interworking is balanced island model migrations. Signaling interworking is
required as described for the peer model. required as described for the peer model.
- The border peer architecture model is defined in [MPLS-OVER-GMPLS]. - The border peer architecture model is defined in [MPLS-OVER-GMPLS].
This is a modification of the augmented model where the layer This is a modification of the augmented model where the layer
border routers have visibility into both layers, but no routing border routers have visibility into both layers, but no routing
information is otherwise exchanged between models. This information is otherwise exchanged between routing protocol
architectural model is particularly suited to the MPLS-GMPLS-MPLS instances. This architectural model is particularly suited to the
island model for PSC and non-PSC GMPLS islands. Signaling MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands.
interworking is required as described for the peer model. Signaling interworking is required as described for the peer model.
5.1.2. Routing Interworking 5.1.2. Routing Interworking
Migration strategies may necessitate some interworking between MPLS Migration strategies may necessitate some interworking between MPLS
and GMPLS routing protocols. GMPLS extends the TE information and GMPLS routing protocols. GMPLS extends the TE information
advertised by the IGPs to include non-PSC information and extended advertised by the IGPs to include non-PSC information and extended
PSC information. Because the GMPLS information is provided as PSC information. Because the GMPLS information is provided as
additional TLVs that are carried along with the MPLS information, additional TLVs that are carried along with the MPLS information,
MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS MPLS LSRs are able to "see" all GMPLS LSRs as though they were MPLS
PSC LSRs. They will also see other GMPLS information, but will ignore PSC LSRs. They will also see other GMPLS information, but will ignore
it, flooding it transparently across the MPLS network for use by it, flooding it transparently across the MPLS network for use by
other GMPLS LSRs. other GMPLS LSRs.
- Routing separation is achieved in the overlay, and border peer - Routing separation is achieved in the overlay and border peer
models. This is convenient since only the border nodes need to be models. This is convenient since only the border nodes need to be
aware of the different protocol variants, and no mapping is aware of the different protocol variants, and no mapping is
required. It is suitable to the MPLS-GMPLS-MPLS and GMPLS-MPLS- required. It is suitable to the MPLS-GMPLS-MPLS and GMPLS-MPLS-
GMPLS island migration models. GMPLS island migration models.
- Direct distribution involves the flooding of MPLS routing - Direct distribution involves the flooding of MPLS routing
information into a GMPLS network, and GMPLS routing information information into a GMPLS network, and GMPLS routing information
into an MPLS network. The border nodes make no attempt to filter into an MPLS network. The border nodes make no attempt to filter
the information. This mode of operation relies on the fact that the information. This mode of operation relies on the fact that
MPLS routers will ignore, but continue to flood, GMPLS routing MPLS routers will ignore, but continue to flood, GMPLS routing
skipping to change at page 12, line 23 skipping to change at page 12, line 9
be received in one protocol and transmitted in the other. For be received in one protocol and transmitted in the other. For
example, a GMPLS routing advertisement could have all of its example, a GMPLS routing advertisement could have all of its
GMPLS-specific information removed and could be flooded as an MPLS GMPLS-specific information removed and could be flooded as an MPLS
advertisement. This mode of interworking would require careful advertisement. This mode of interworking would require careful
standardization of the correct behavior especially where an MPLS standardization of the correct behavior especially where an MPLS
advertisement requires default values of GMPLS-specific fields to advertisement requires default values of GMPLS-specific fields to
be generated before the advertisement can be flooded further. be generated before the advertisement can be flooded further.
There is also considerable risk of confusion in closely meshed There is also considerable risk of confusion in closely meshed
networks where many LSRs have MPLS and GMPLS capable interfaces. networks where many LSRs have MPLS and GMPLS capable interfaces.
This option for routing interworking during migration is NOT This option for routing interworking during migration is NOT
RECOMMENDED for any migration model. 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 as 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 - Ships in the night refers to a mode of operation where both MPLS
and GMPLS routing protocol variants are operated in the same and GMPLS routing protocol variants are operated in the same
network at the same time as separate routing protocol instances. network at the same time as separate routing protocol instances.
The two instances are independent and are used to create routing The two instances are independent and are used to create routing
adjacencies between LSRs of the same type. This mode of operation adjacencies between LSRs of the same type. This mode of operation
may be appropriate to the integrated migration model. may be appropriate to the integrated migration model.
5.1.3. Signaling Interworking 5.1.3. Signaling Interworking
Signaling protocols are used to establish LSPs and are the principal Signaling protocols are used to establish LSPs and are the principal
concern for interworking during migration. Issues of compatibility concern for interworking during migration. Issues of compatibility
arise because of simple changes in the encodings and codepoints used arise because of differences in the encodings and codepoints used by
by MPLS and GMPLS signaling, but also because of changes in function MPLS and GMPLS signaling, but also because of differences in
levels provided by MPLS and GMPLS. functionality provided by MPLS and GMPLS.
- Tunneling and stitching (GMPLS-PSC case) mechanisms are a good way - Tunneling and stitching (GMPLS-PSC case) mechanisms provide the
to avoid any requirement for direct protocol interworking during potential to avoid direct protocol interworking during migration
migration in the island model because protocol elements are in the island model, because protocol elements are transported
transported transparently across migration islands without being transparently across migration islands without being inspected.
inspected. However, care may be needed to achieve functional However, care may be needed to achieve functional mapping in these
mapping in these modes of operation since one set of features must modes of operation since one set of features may need to be
be carried across a network designed to support a different set of supported across a network designed to support a different set of
features. In general, this is easily achieved for the MPLS-GMPLS- features. In general, this is easily achieved for the MPLS-GMPLS-
MPLS model, but may be hard to achieve in the GMPLS-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 model. For example, when end-to-end bidirectional LSPs are
requested since the MPLS island does not support bidirectional requested, since the MPLS island does not support bidirectional
LSPs. LSPs.
Note that tunneling and stitching are not available in unbalanced Note that tunneling and stitching are not available in unbalanced
island models because in these cases the LSP end points use island models because in these cases the LSP end points use
different protocol variants. different protocols.
- Protocol mapping is the conversion of signaling messages between - Protocol mapping is the conversion of signaling messages between
MPLS and GMPLS variants. This mechanism requires careful MPLS and GMPLS. This mechanism requires careful documentation of
documentation of the protocol fields and how they are mapped, but the protocol fields and how they are mapped. This is relatively
is relatively simple in the MPLS-GMPLS unbalanced island model. straightforward in the MPLS-GMPLS unbalanced island model for LSPs
However, the MPLS-GMPLS island model may manifest as the GMPLS- signaled in the MPLS-GMPLS direction. However, it may be more
MPLS model for LSPs signaled in the opposite direction and this complex for LSPs signaled in the opposite direction, and this will
will lead to considerable complications for providing GMPLS lead to considerable complications for providing GMPLS services
services over the MPLS island and for terminating those services over the MPLS island and for terminating those services at an
at an egress LSR that is not GMPLS-capable. Further, in balanced egress LSR that is not GMPLS-capable. Further, in balanced island
island models, and in particular where there are multiple small models, and in particular where there are multiple small
(individual node) islands, the repeated conversion of signaling (individual node) islands, the repeated conversion of signaling
parameters may lead to loss of information or mis-requests. parameters may lead to loss of information (and functionality) or
mis-requests.
- Ships in the night could be used in the integrated migration model - Ships in the night could be used in the integrated migration model
to allow MPLS-capable LSRs to establish LSPs using MPLS signaling to allow MPLS-capable LSRs to establish LSPs using MPLS signaling
protocols and GMPLS LSRs to establish LSPs using GMPLS signaling protocols and GMPLS LSRs to establish LSPs using GMPLS signaling
protocols. LSRs that can handle both sets of protocols could play protocols. LSRs that can handle both sets of protocols could work
a part in either case, but no conversion of protocols would be with both types of LSRs, and no conversion of protocols would be
applied. needed.
6. Manageability Considerations 6. Manageability Considerations
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 one management domain. For example, in the Island Model, 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 have
different management in place before the migration: the resultant separate 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 the
separation.
6.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 critical control functionality to be applied is at the
changeover between different levels of protocol support. Such a moment of changeover between different levels of protocol support.
change may be made dynamically or during a period of network Such a change may be made without service halt or during a period of
maintenance. network maintenance.
Where island boundaries exist, it must be possible to manage the Where island boundaries exist, it must be possible to manage the
relationships between protocols and to indicate which interfaces relationships between protocols and to indicate which interfaces
support which protocols on a border LSR. Further, island borders are support which protocols on a border LSR. Further, island borders are
a natural place to apply policy, and management should allow a natural place to apply policy, and management should allow
configuration of such policies. configuration of such policies.
6.2. Information and Data Models 6.2. Information and Data Models
No special information or data models are required to support No special information or data models are required to support
migration, but note that migration in the control plane implies migration, but note that migration in the control plane implies
migration from MPLS management tools to GMPLS management tools. migration from MPLS management tools to GMPLS management tools.
During migration, therefore, it may be necessary for LSRs and During migration, therefore, it may be necessary for LSRs and
management applications to support both MPLS and GMPLS variants of management applications to support both MPLS and GMPLS management
management data. data.
The GMPLS MIB modules are designed to allow support of the MPLS The GMPLS MIB modules are designed to allow support of the MPLS
protocols and build on the MPLS MIB modules through extensions and protocols and built 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.
6.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 impose 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. will need further consideration.
6.4. Verifying Correct Operation 6.4. Verifying Correct Operation
The concerns for verifying correct operation (and in particular The concerns for verifying correct operation (and in particular
correct connectivity) are the same as for liveness detection and correct connectivity) are the same as for liveness detection and
monitoring. Principally, the process of migration may introduce monitoring. Specifically, the process of migration may introduce
tunneling or stitching into what was previously a flat network. tunneling or stitching into what was previously a flat network.
6.5. Requirements on Other Protocols and Functional Components 6.5. Requirements on Other Protocols and Functional Components
No particular requirements are introduced on other protocols. As it No particular requirements are introduced on other protocols. As it
has been observed, the management components may need to migrate in has been observed, the management components may need to migrate in
step with the control plane components, but this does not impact the step with the control plane components, but this does not impact the
management protocols, just the data that they carry. management protocols, just the data that they carry.
It should also be observed that providing signaling and routing It should also be observed that providing signaling and routing
skipping to change at page 15, line 26 skipping to change at page 15, line 20
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, augmented network and border peer models where the details
protocol islands remain hidden from the surrounding LSRs. of the protocol islands remain hidden from the surrounding LSRs.
6.7. Other Considerations 6.7. Other Considerations
A migration strategy may also imply moving an MPLS state to a GMPLS 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 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 along the path of the LSP have been updated to be both MPLS and
GMPLS-capable. Signaling mechanisms to achieve the replacement of an GMPLS-capable. Signaling mechanisms to achieve the replacement of an
MPLS LSP with a GMPLS LSP without disrupting traffic exist through MPLS LSP with a GMPLS LSP without disrupting traffic exist through
make-before-break procedures [RFC3209] and [RFC3473], and should be make-before-break procedures [RFC3209] and [RFC3473], and should be
carefully managed under operator control. carefully managed under operator control.
7. 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 when crossing an IGP area or AS boundary,
boundary, even though these island boundaries might lie within an IGP even though these island boundaries might lie within an IGP area or
area or AS. AS.
No changes are proposed to the security procedures built into MPLS No changes are proposed to the security procedures built into MPLS
and GMPLS signaling and routing. GMPLS signaling and routing inherit and GMPLS signaling and routing. GMPLS signaling and routing inherit
their security mechanisms from MPLS signaling and routing without any their security mechanisms from MPLS signaling and routing without any
changes. Hence, there will be no issues with security in interworking changes. Hence, there will be no additional issues with security in
scenarios. Further, since the MPLS and GMPLS signaling and routing interworking scenarios. Further, since the MPLS and GMPLS signaling
security is provided on a hop-by-hop basis, and since all signaling and routing security is provided on a hop-by-hop basis, and since all
and routing exchanges described in this document for use between any signaling and routing exchanges described in this document for use
pair of LSRs are based on either MPLS or GMPLS, there are no changes between any pair of LSRs are based on either MPLS or GMPLS, there are
necessary to the security procedures. no changes necessary to the security procedures.
8. IANA Considerations 8. IANA Considerations
This informational framework document makes no requests for IANA This informational framework document makes no requests for IANA
action. action.
9. Full Copyright Statement 9. Acknowledgements
Copyright (C) The Internet Society (2006).
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 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.
10. 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.
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. The authors are grateful to Dean Cheng initial work on this document. The authors are grateful to Dean Cheng
for his valuable comments. and Adrian Farrel for their valuable comments.
12. Authors' Addresses 10. Editor's Addresses
Kohei Shiomoto, Editor Kohei Shiomoto, Editor
NTT NTT
Midori 3-9-11 Midori 3-9-11
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
Phone: +81 422 59 4402 Phone: +81 422 59 4402
Email: shiomoto.kohei@lab.ntt.co.jp Email: shiomoto.kohei@lab.ntt.co.jp
11. Authors' Addresses
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 France Telecom
av Pierre Marzin 22300 av Pierre Marzin 22300
Lannion, France Lannion, France
Phone: +33 2 96 05 30 20 Phone: +33 2 96 05 30 20
Email: jeanlouis.leroux@orange-ft.com Email: jeanlouis.leroux@orange-ftgroup.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
skipping to change at page 19, line 17 skipping to change at page 18, line 19
NTT NTT
Midori 3-9-11 Midori 3-9-11
Musashino, Tokyo 180-8585, Japan Musashino, Tokyo 180-8585, Japan
Phone: +81 422 59 3441 Phone: +81 422 59 3441
Email: inoue.ichiro.lab.ntt.co.jp Email: inoue.ichiro.lab.ntt.co.jp
Tomohiro Otani Tomohiro Otani
KDDI Laboratories KDDI Laboratories
Email: otani@kddilabs.jp Email: otani@kddilabs.jp
13. References 12. References
13.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, IETF RFC 2119, March 1997. Requirement Levels," BCP 14, IETF RFC 2119, March 1997.
[RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003.
[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.
[SEGMENT-RECOVERY]Berger, L., "GMPLS Based Segment Recovery", draft- [RFC4090] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions
ietf-ccamp-gmpls-segment-recovery, work in progress. to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[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 [SEGMENT-RECOVERY]Berger, L., "GMPLS Based Segment Recovery", draft-
(GMPLS) Signaling Resource ReserVation Protocol-Traffic ietf-ccamp-gmpls-segment-recovery, work in progress.
Engineering (RSVP-TE) Extensions ", RFC 3473, January 2003.
[TE-NODE-CAPS] Vasseur, Le Roux, editors " IGP Routing Protocol [TE-NODE-CAPS] Vasseur, Le Roux, editors " IGP Routing Protocol
Extensions for Discovery of Traffic Engineering Node Capabilities", Extensions for Discovery of Traffic Engineering Node
draft-ietf-ccamp-te-node-cap, work in progress. Capabilities", draft-ietf-ccamp-te-node-cap, work in
progress.
13.2. Informative References 12.2. Informative References
[RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux,
M., Brungard, D., "Requirements for GMPLS-based multi- M., Brungard, D., "Requirements for GMPLS-based multi-
region and multi-layer networks (MRN/MLN)", draft-ietf- region and multi-layer networks (MRN/MLN)", draft-ietf-
ccamp-gmpls-mln-reqs, work in progress. ccamp-gmpls-mln-reqs, work in progress.
[RFC4206] Kompella, K., and Rekhter, Y., "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(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-
ccamp-lsp-stitching, work in progress. ccamp-lsp-stitching, work in progress.
[RFC4726] Farrel, A., Vasseur, J.P., Ayyangar, A., " A Framework for
Inter-Domain Multiprotocol Label Switching Traffic Engineering",
RFC4726, November 2006.
[MPLS-OVER-GMPLS] Kumaki, K., et al., " Interworking Requirements to
Support operation of MPLS-TE over GMPLS networks", draft-ietf-ccamp-
mpls-gmpls-interwork-reqts, work in progress.
13. Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
14. 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.
 End of changes. 84 change blocks. 
271 lines changed or deleted 229 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/