wdiff draft-sprecher-mpls-tp-migration-03.txt draft-sprecher-mpls-tp-migration-04.txt

Network Working Group N. Sprecher
Internet-Draft Y. Weingarten
Intended status: Informational Nokia Siemens Networks
Expires: July 8, December 25, 2011 K. Hong
L. Fang
Cisco Systems, Inc.
January 4,
June 23, 2011

Migration Considerations and Techniques for Multiprotocol Label
Switching Transport Profile based Networks and Services
draft-sprecher-mpls-tp-migration-03.txt
draft-sprecher-mpls-tp-migration-04.txt

Abstract

MPLS-TP defines a packet-based network architecture and a
comprehensive set of tools that allow service providers to reliably
deliver next generation services and applications, in a simple,
scalable, and cost-effective way. Such services are BW-hungry based
and require strict guaranteed SLA. Delivering next generation
services over an MPLS-TP based network in an economic way, enables
service providers to remain competitive while increasing their
revenues.

This document presents the motivations for migrating from different
legacy transport networks and services to MPLS-TP, and discusses the
considerations and strategies for the migration.

The document also proposes specific activities and techniques needed
to ensure a smooth migration path from the different transport
networks and services to MPLS-TP.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 8, December 25, 2011.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview of MPLS-TP . . . . . . . . . . . . . . . . . . . 4
1.2. Motivations for Upgrading Networks . . . . . . . . . . . . 5
2. Terminology and References . . . . . . . . . . . . . . . . . . 6
2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. General Migration Considerations and Strategies . . . . . . . . . . . . 7
3.1. Migration models . . . . . . . . . 7
3.1. Island model . . . . . . . . . . . . 8
3.1.1. Island model . . . . . . . . . . . . . . . . . . . . . 8
3.2.
3.1.2. Phased model . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. 10
3.1.3. Integrated model . . . . . . . . . . . . . . . . . . . 11
3.2. Migration strategies . . 10 . . . . . . . . . . . . . . . . . 13
4. Migrating from TDM . . . . . . . . . . . . . . . . . . . . . . 11 13
4.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 11 13
4.2. Migration Activities and Techniques . . . . . . . . . . . 11 13
5. Migrating from ATM . . . . . . . . . . . . . . . . . . . . . . 11 14
5.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 11 14
5.2. Migration activities and Techniques . . . . . . . . . . . 11 14
6. Migrating from Ethernet . . . . . . . . . . . . . . . . . . . 11 14
6.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 11 14
6.2. Migration activities and Techniques . . . . . . . . . . . 11 14
7. Migrating from MPLS . . . . . . . . . . . . . . . . . . . . . 11 15
7.1. General note on migrating MPLS . . . . . . . . . . . . . . 15
7.2. MPLS-TE . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. 15
7.2.1. Main motivation . . . . . . . . . . . . . . . . . . . 11
7.1.2. 15
7.2.2. Migration activities and Techniques . . . . . . . . . 11
7.2. 15
7.3. IP/MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2.1. 15
7.3.1. Main motivation . . . . . . . . . . . . . . . . . . . 11
7.2.2. 15
7.3.2. Migration activities and Techniques . . . . . . . . . 11 15
8. Migrating from pre-standard MPLS-TP (T-MPLS) . . . . . . . . . 11 16
8.1. Main motivation . . . . . . . . . . . . . . . . . . . . . 11 16
8.2. Migration activities and Techniques . . . . . . . . . . . 11 16
9. Manageability Considerations . . . . . . . . . . . . . . . . . 12 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 16
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 12 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 17

Editors' Note:

This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF
Last Call.

[RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published
RFC has IETF Consensus.]

1. Introduction

1.1. Overview of MPLS-TP

The Transport Profile for MPLS (MPLS-TP) is being specified in the
IETF as part of a joint effort with the ITU-T to develop a definition
of the MPLS network that will fulfill the strict requirements for
transport networks that are accepted by the ITU-T. This profile will
be based on the definitions of the MPLS, MPLS Traffic Engineering,
and Multi-Segment Pseudo-Wire architectures defined in [RFC3031],
[RFC3985], and [RFC5659].

The requirements for MPLS-TP are detailed in [RFC5654]. These
requirements were developed in full cooperation between the IETF and
ITU-T, and reflect the needs to adhere to the architecture of MPLS
while including the enhanced level of service transparency, and
Operations, Administration, and Maintenance (OAM) functionality
required for stable transport networks. The requirements for the OAM
functionality are further developed and defined in [MPLS-TP-OAM],
providing the list of OAM procedures to be supported by MPLS-TP.

The architecture for MPLS-TP is defined in [RFC5921] and builds upon
the experience of the MPLS architecture. The architecture is
designed to allow MPLS-TP networks to operate whether the
configuration was implemented by use of control-plane signaling or a
management application. In addition, the MPLS-TP architecture is
designed to support networks that may not be using IP forwarding and
addressing. The framework defines the different service structures
supported by MPLS-TP and the interworking between these service
structures and existing MPLS services. Also defined are the
characteristics of the profile that defines MPLS-TP. This synergy of
architectures guarantees the service provider the ability to provide
services with guaranteed and strict Service Level Agreements in a
highly scalable robust network while reducing operational costs.

A main focus of MPLS-TP is the definition of OAM functionality for
MPLS data paths that support the transport services. MPLS-TP
provides a comprehensive set of OAM tools for fault management and
performance monitoring, supporting the network and the services at
different nested levels (i.e. at the end-to-end level, a segment of a
path, and link level). The OAM tools may be used to monitor the
network infrastructure, to enhance the general behavior, and
performance level of the network. The tools may also be used to
monitor the service level offered to the end customer, allowing
verification of the SLA parameters, and enabling rapid response in
the event of a failure or service degradation. The OAM tools help
reduce OPEX, minimizing the overhead of trouble shooting, and
enhancing customer satisfaction which, in turn, helps to enable the
delivery of high-margin premium services.

The architectural constructs and the methodology of the OAM
functionality is defined by [MPLS-TP-OAM-Fwk]. This includes the
definition of the transport entities that are monitored by the OAM
procedures and detailed description of how the OAM procedures are
applied to these transport entities. A central issue in MPLS-TP OAM
is the independence of the OAM from the existence of an operational
control plane in the network. This feature is supported by the
creation of an in-band control channel that is used to transmit the
OAM procedures across the transport paths. A cornerstone of the
definition of the OAM procedures is to use existing IETF OAM tools as
the basis of the MPLS-TP OAM procedures wherever possible, this
principle is used as the underlying foundation for the definition of
the OAM tools defined for MPLS-TP.

Protection mechanisms for the MPLS-TP transport paths are described
in [MPLS-TP-Surviv] and are conformed with different topological
configurations of the network.

1.2. Motivations for Upgrading Networks

The growth of packet traffic has significantly increased, driven by
the high demand and penetration of new packet-based services and
multimedia applications, across the access, aggregation and core
networks and is expected to continue to increase. With the movement
toward packet-based services, the transport network has to evolve to
encompass the provision of packet-aware capabilities while enabling
carriers to leverage their installed, as well as planned, transport
infrastructure investments.

Carriers are in need of technologies capable of efficiently
supporting packet-based services and applications on their transport
networks with guaranteed Service Level Agreements (SLAs). The need
to increase their revenue while remaining competitive forces
operators to look for the lowest network Total Cost of Ownership
(TCO), and as such requires investment in equipment and facilities
(Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX) be
minimized.

There are a number of technology options for carriers to meet the
challenge of increased service sophistication and transport
efficiency, with increasing usage of hybrid packet-transport and
circuit-transport technology solutions. To address this challenge,
it is essential that packet-transport technology be available that
can provide reliability, operational simplicity - preserving the look
and feel to which service providers have accustomed, multi-layer
operations, resiliency, control, and multi-technology management.

Transport carriers require control and deterministic usage of network
resources. They need end-to-end control to engineer network paths
and to efficiently utilize network resources. They require
capabilities to support static (management-plane-based) or dynamic
(control-plane-based) provisioning of deterministic, protected, and
secured services and their associated resources. For transport
carriers, it is also important to ensure smooth interworking of the
packet transport network with other existing/legacy packet networks,
and provide mappings to enable packet transport carriage over a
variety of transport network infrastructures.

MPLS is a maturing packet technology and it is already playing an
important role in transport networks and services. The development
of MPLS-TP has proposed a set of compatible technology enhancements
to existing MPLS standards to extent the definition of MPLS toward
supporting traditional transport operational models. These
enhancements inherit all the supporting QoS, recovery, control and
data plane mechanisms already defined within standards. MPLS-TP will
enable the deployment of packet-based transport networks that will
efficiently scale to support packet services in a simple and cost-
effective way.

2. Terminology and References

2.1. Acronyms

This draft uses the following acronyms:

MPLS-TP Multiprotocol Label Switching - Transport Protocol
OAM Operations, Administration, and Maintenance

3. General Migration Considerations and Strategies

A migration strategy is necessary for service providers to ensure the
smooth migration process in a cost-efficient and scalable way.
Smooth migration is required to enable service providers to maintain
their existing investments in the installed base for as long as
economically justifiable.

Smooth migration is required to enable service providers to maintain
their existing investments in the installed base for as long as
economically justifiable.

For service providers, smooth migration path and minimize seamless
interworking between the investment installed networks and the MPLS-TP based
network, also eliminates the risks associated with fork-lifting a
new-technology or implementation upgrade onto the whole network in
one day. Such an approach allows service providers to ensure that
the new equipment. implementations work as expected in live networks and that
the customers' quality of experience is maintained and not affected.

The migration should be a smooth and seamless transfer of technology
while continuing to support the services that generate the revenues.
This means that the migration strategy should address the following
considerations:

o Cost-effective - Minimize the number of migration steps, stay
within budget for both operating (OPEX) and capital (CAPEX)
expenses.

o Service continuity - perform the switchover without a service
break to existing customers and their services. Service
performance, availability and subscriber experience should
reaminremain unaffected.

o Provide a reliable fall-back - don't burn your bridges until the
new connections are secure and robust enough to maintain the
service-level agreements.

o Minimum switchover time - when everything is in place need to
minimize the side-effects by minimizing the time needed to have
the new service platform performing.

o Aspects of data-plane, OAM and recovery mechanisms, control plane
and management-plane

Different migration models have been discussed in the literature. literature,
each with distinct advantages and disadvantages. The most basic
model, forklifting the new technology, in our case MPLS-TP, onto the
network involves simultaneously upgrading the entire network to work
with the new technology. This type of migration is very risky if the
new technology does not work as expected in the live network after
disabling the legacy technology. In order to minimize the risk, it
could be possible to install an entire parallel network based on
MPLS-TP and then switch over from the legacy network to the MPLS-TP
network. However, this would be very costly, i.e. purchasing
equipment for two parallel networks, and again could not guarantee
that the new technology network would work as planned. This, in
turn, would cause a major disruption of services. Therefore, in

Note that, theoretically, one could build an entire parallel network,
switch the traffic over to the new network and then pull down the old
network. It is complicated or even impossible to coordinate such an
upgrade across the entire network.

The forklift migration is neither practical nor recommended.
However, it can be performed locally across a section of the network.

In the following descriptions we concentrate on the following models:

o Island model - introducing the MPLS-TP in separate sub-domains of
the network. The transport paths may cross the different
technology domains that are connected interconnected by gateways. See
section 3.1 for more details.

o Phased model - where the existing equipment is slowly upgraded
with new MPLS-TP capabilities as needed. For more details see
section 3.2.

o Integrated model - network nodes are either legacy nodes or dual-
mode nodes supporting both legacy and MPLS-TP capabilities. See
section 3.3 for more details.

It should be noted that not all of these models are relevant to
migration from specific legacy technologies. The relevance for each
technology of the particular migration model will be discussed in the
sections below that discuss the specific technologies.

3.1. Migration models

3.1.1. Island model

In this migration model presented previously in [RFC5145] the service
provider introduces clusters of MPLS-TP nodes that are interconnected
with the legacy clusters through border nodes. The border nodes act
as gateways, that are responsible for the mapping or adaptation of
protocol elements that may be transmitted between legacy and MPLS-TP
nodes.

The island model is applicable when new pieces of network are
introduced, or when a localized forklift is performed.

End-to-end services may traverse between the islands. The
configuration of the transport paths may be "balanced" or
"unbalanced". In a balanced path configuration both endpoints of the
path are nodes of the same technology, but the path may have crossed
islands of the other technology in the middle of the path, see
Figure 1. An unbalanced path configuration would be if the path
starts at a node of one technology and ends at a node supporting the
second technology, see Figure 1.

+----+ +--+ +----+ +--+ +----+ +--+ +----+
|Lgcy| |LN| |Brdr| |TP| |Brdr| |LN| |Lgcy|
| |==========| |==========| |=========| |
..|........Service...Transport...Path.................|...
| |==========| |==========| |=========| |
|Conn| | | |Gtwy| | | |Gtwy| | | |Conn|
+----+ +--+ +----+ +--+ +----+ +--+ +----+
. . . . . .
| Legacy | | MPLS-TP | | Legacy |
|<----Island---->| |<---Island--->| |<---Island--->|

LN - one or more Legacy Nodes
TP - one or more MPLS-TP LSR
Brdr Gtwy - Border node that acts as gateway
Lgcy Conn - Legacy node that where service connects

Figure 1: Balanced island path

+----+ +--+ +----+ +--+ +----+
|Lgcy| |LN| |Brdr| |TP| | TP |
| |==========| |==========| |
....|...Service...Transport...Path.......|...
| |==========| |==========| |
|Conn| | | |Gtwy| | | |Conn|
+----+ +--+ +----+ +--+ +----+
. . . .
| Legacy | | MPLS-TP |
|<----Island---->| |<---Island--->|

LN - one or more Legacy Nodes
TP - one or more MPLS-TP LSR
Brdr Gtwy - Border node that acts as gateway
Lgcy Conn - Legacy node that where service connects
TP Conn - MPLS-TP LER

Figure 2: Unbalanced island path

The tools that may be used at the border, gateway, gateway nodes may be based
on either layered networks - only when using balanced islands, or on an interworking or mapping function between
protocols. An MPLS-TP
island would provide the The layered network solution through (which may be seen also as an overlay
network) tools are applicable only in the use case of
an LSP between Layered networks
are used to separate the domains belonging to different technologies.
MPLS-TP LSPs provide TE-links to carry legacy traffic, when possible. traffic. The gateways
adapt the legacy traffic and multiplex it over the TE-links. When
interconnection is based on interworking or mapping tools, service or
network interworking is used between the islands through gateways
which are responsible for mapping protocols&apos elements.

This model is very useful when upgrading the network in stages, where
new MPLS-TP equipment is upgraded in clusters that form an island.
These islands can be slowly expanded and merged until they create a
single MPLS-TP network. Whenever the islands are expanded or merged
make-before-break procedures should be employed in order to keep
services running.

3.2.

3.1.2. Phased model

In this model the existing equipment is upgraded with the features
and functionality of the new technology. The new functionality is
introduced as needed, while ensuring interoperability with the legacy
technology. This is highly dependent upon the equipment possibility to upgrade
the equipment, either software or firmware, to support the new
functionality and upon the support of all the equipment from different
vendors to implement for the same functionality. set of capabilities.

The advantage of this model is that it allows the service provider to
quickly support enhanced capabilities on his existing equipment.
However, this model is not applicable to all legacy technologies.
For this to work the new capabilities need to be backward compatible
with the legacy technology, and all of the vendors, involved in the
migration, need to implement the new capabilities specified by the
service provider.

3.3.

3.1.3. Integrated model

This model allows the operator to run services over two clouds of the a network simultaneously. One cloud would continue to support the
legacy technology, while the second cloud would support the new
MPLS-TP services. The services would be routed to the proper cloud
by have new "dual-mode" nodes that would nodes, which
support an integrated MPLS-TP and legacy functionality, see in the legacy
networks, as is depicted in Figure 3. These dual-mode nodes would
route

A mandatory requirement in this model is that the different services to MPLS-TP and the paths
legacy technologies can co-exist in the different technology
clouds. This avoids the need for interworking that same network. There is required in no
requirement for interworking.

Existing services would be routed either through legacy nodes or
through the island model described in section 3.1.

______________________________________
_/ Service Provider's Network new dual-mode nodes. New services would be routed
through new dual-mode nodes.

-----------------------------------------
| --- --- --- --- |
| | L |---| L |---| L |---| L | |
| --- --- --- --- |
| \ / ____ ___ ____ \___
_/ _/ \___/ |
| \ _/ \__ / |
| \ / |
| \ --- / \__/ ... \_ \___ --- --- |
| | L |---| L |---| L | |
| /| T |...| T |...| T | |
| / --- --- --- |
| / ....... ... \ \ : : | +--------| ...Legacy Logical Network .. |---+
| --- / : : | |.........\.. .. .. ../....|
| | |. \ ___.... ___ __ _/ .| L |/ --- --- |
| +----+ \_/ \____/ \___/ \____/ +----+ |
....|Dual| |Dual|... T |.....| T |...........| T | |
| --- --- --- |
| : : |
****|Mode| ____ ___ ____ |Mode|***
| +----+ _/ \___/ \ _/ \__ +----+ : : |
\
| * / \__/ \_ *| --- --- --- --- |
\
| ******* /*** **\****| /
\ +--------| ***MPLS-TP Logical Ntwrk*** |---+ /
\____ \ *** ***** ***** / |
\ \ ___ ****___ ***__ _/ /
\ \_/ \____/ \___/ \____/ ___/
\____________________________________/

.... - T |....| T |....| T |...| T | |
| --- --- --- --- |
| |
-----------------------------------------

Key:

---
| L | Legacy service path
**** - Node
---

---
| D | Dual-Stack Node
---

---
| T | MPLS-TP service path Node
---

--- Legacy MPLS LSP

... MPLS-TP OAM-capable LSP

Figure 3: Integrated model network

Gradual migration is supported by this model. The dual-mode nodes
are either legacy nodes that are upgraded to support MPLS-TP
functionality. Services can be switched gradually from the legacy
transport paths to the MPLS-TP paths as they become available, using
make-before-break procedures. Eventually, as all the service paths
are transferred to MPLS-TP the legacy technology cloud can be taken
off-line.
switched off. New devices will support MPLS-TP functionality only.

3.2. Migration strategies

The migration process will be a gradual process and it should be
tailored for each service provider&aposs network. Minimizing risks,
controlling costs, and recognizing the impact on the end-customer are
complicating factors that create a myriad of challenges to be
addressed, monitored, measured and managed throughout the entire
migration process.

The network migration process, as well as the operation and
management, and policy during the migration process needs to be
planned.

When selecting a migration model and defining the migration steps,
issues such as the following need to be considered and evaluated:

o Existing deployed networks and services.

o Service provider&aposs network deployment plans and objectives
(including the need for investment protection, window for the
migration time, etc.).

o Effects on the network operation, management costs.

o Risks and reliable fallback.

o End-customers&apos demand.

o Security and operational policy

4. Migrating from TDM

4.1. Main motivation

4.2. Migration Activities and Techniques

When considering the different strategies outlined in section 3 in
relationship to migration from TDM-based networks, the service
provider will need to realize that this type of migration involves a
hardware upgrade for the network equipment. This indicates that it
is not practical to plan a phased migration, that is based on
upgrading the existing network elements.

An integrated model migration would be a good candidate for this type
of migration. The plan would involve installing dual-mode TDM/MPLS
nodes into the network. Continuing the support of voice and control
(e.g. timing information) traffic over the TDM sub-network, while
simultaneously using the MPLS-TP capabilities to support existing and
new data services. Transferring the existing data services would use
make-before-break procedures defined by MPLS. As more and more
services are transferred to the MPLS-TP environment native MPLS-TP
nodes can be supported

Another candidate for implementing a graduated migration strategy
would be based on the Island model. The service provider would
install new MPLS-TP nodes in well defined clusters within the
network. Dual-mode border nodes would be used to interconnect
between the native TDM islands that would support existing services
and the MPLS-TP islands.

5. Migrating from ATM

5.1. Main motivation

5.2. Migration activities and Techniques

6. Migrating from Ethernet

6.1. Main motivation

6.2. Migration activities and Techniques

When considering the different strategies outlined in section 3 in
relationship to migration from Ethernet-based networks, the service
provider will need to realize that this type of migration involves a
hardware upgrade for the network equipment. This indicates that it
is not practical to plan a phased migration, that is based on
upgrading the existing network elements.

An integrated model migration would be a good candidate for this type
of migration. Both Ethernet and MPLS-TP can exist side-by-side
within the network. In addition, it is possible to install dual-mode
nodes that can support both Ethernet services and MPLS over Ethernet
services. Continuing the support of legacy services over the
Ethernet sub-network, while simultaneously using the MPLS-TP
capabilities to slowly encapsulate some of these existing legacy
(over either PWs or L2VPN structures) and support new data services.
Transferring the existing data services would use make-before-break
procedures defined by MPLS. As more and more services are
transferred to the MPLS-TP environment native MPLS-TP nodes can be
supported

7. Migrating from MPLS

7.1. General note on migrating MPLS

MPLS-TP is a profile of the general MPLS toolkit which supports all
of the tools required to ensure scalable, quality transport. Data
services in MPLS-TP use the same forwarding mechanisms supported by
standard MPLS. Many of the capabilities provided by MPLS-TP are
already provided by MPLS and GMPLS, and there is no preclusion of
using any of these capabilities in an MPLS-TP network.

7.2. MPLS-TE

7.1.1.

7.2.1. Main motivation

7.1.2.

7.2.2. Migration activities and Techniques

7.2.

7.3. IP/MPLS

7.2.1.

7.3.1. Main motivation

7.2.2.

7.3.2. Migration activities and Techniques

As pointed out in the general note, MPLS-TP is a particular profile
of the tools already supported by IP/MPLS. Therefore, for the most
part, this migration is essentially a software upgrade of both the
network equipment and possibly the management system. Any of the
migration models presented in Section 3 are relevant candidates for
implementing the migration plan from IP/MPLS to MPLS-TP.

Gradually upgrading the MPLS network elements with the new MPLS-TP
tools, by employing a phased migration plan, would enhance the
general behavior of the network. This provides a very cost-effective
switchover to the high-quality network service layer that is
supported by the improved OAM tools of MPLS-TP.

It is also possible to create islands of MPLS-TP nodes in order to
offload services from the current IP routers while continuing to
provide high-quality service by managing the transport paths using
the advanced OAM tools. The two systems can work side-by-side.
However, it is important to realize that the new MPLS-TP
capabailities are only available, for a transport path, if supported
by all hops that the path traverses.

8. Migrating from pre-standard MPLS-TP (T-MPLS)

8.1. Main motivation

8.2. Migration activities and Techniques

9. Manageability Considerations

10. Security Considerations

11. IANA Considerations

This informational document makes no requests for IANA action.

12. Acknowledgments

13. References

13.1. Normative References

[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5317, February 2009.

[MPLS-TP-OAM]
Busi, I., Ed. and B. Niven-Jenkins, Ed., "Requirements for
OAM in MPLS Transport Networks",
draft-ietf-mpls-tp-oam-requirements, Work in Progress.

[MPLS-TP-OAM-Fwk]
Busi, I., Ed. and B. Niven-Jenkins, Ed., "A Framework for
MPLS in Transport Networks",
draft-ietf-mpls-tp-oam-framework, Work in Progress.

[MPLS-TP-Surviv]
Sprecher, N. and A. Farrel, "Multiprotocol Label Switching
Transport Profile Survivability Framework",
draft-ietf-mpls-tp-survive-fwk, Work in Progress.

13.2. Informative References

[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.

[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudo Wire Emulation Edge-to-Edge", RFC 5659,
October 2009.

[RFC5145] Shiomoto, K., "Framework for MPLS-TE to GMPLS Migration",
RFC 5145, March 2008.

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., Ed., and L. Berger, Ed., "A Framework for MPLS in
Transport Networks", RFC 5921.

[RFC5920] Levrau, L., Ed., "A Framework for MPLS in Transport
Networks", RFC 5920.

Authors' Addresses

Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel

Email: nurit.sprecher@nsn.com

Yaacov Weingarten
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel

Email: yaacov.weingarten@nsn.com
Kyung-Yeop Hong
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, Massachusetts 01719
USA

Email: hongk@cisco.com

Luyuan Fang
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA

Email: lufang@cisco.com