Migration Considerations and Techniques for Multiprotocol Label Switching Transport Profile based Networks and Services
draft-sprecher-mpls-tp-migration-03.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, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

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
    1.1.  Overview of MPLS-TP
    1.2.  Motivations for Upgrading Networks
2.  Terminology and References
    2.1.  Acronyms
3.  General Migration Strategies
    3.1.  Island model
    3.2.  Phased model
    3.3.  Integrated model
4.  Migrating from TDM
    4.1.  Main motivation
    4.2.  Migration Activities and Techniques
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
7.  Migrating from MPLS
    7.1.  MPLS-TE
        7.1.1.  Main motivation
        7.1.2.  Migration activities and Techniques
    7.2.  IP/MPLS
        7.2.1.  Main motivation
        7.2.2.  Migration activities and Techniques
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
12.  Acknowledgments
13.  References
    13.1.  Normative References
    13.2.  Informative References
§  Authors' Addresses

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] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” January 2001.), [RFC3985] (Bryant, S. and P. Pate, “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” March 2005.), and [RFC5659] (Bocci, M. and S. Bryant, “An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge,” October 2009.).

The requirements for MPLS-TP are detailed in [RFC5654] (Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” February 2009.). 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] (Busi, I., Ed. and B. Niven-Jenkins, Ed., “Requirements for OAM in MPLS Transport Networks,” .), providing the list of OAM procedures to be supported by MPLS-TP.

The architecture for MPLS-TP is defined in [RFC5921] (Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., Ed., and L. Berger, Ed., “A Framework for MPLS in Transport Networks,” .) 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] (Busi, I., Ed. and B. Niven-Jenkins, Ed., “A Framework for MPLS in Transport Networks,” .). 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] (Sprecher, N. and A. Farrel, “Multiprotocol Label Switching Transport Profile Survivability Framework,” .) 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:

3.  General Migration Strategies

A migration strategy is necessary for service providers to maintain their installed base and minimize the investment in new equipment. 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:

• Cost-effective – Minimize the number of migration steps, stay within budget for both operating (OPEX) and capital (CAPEX) expenses.
• Service continuity – perform the switchover without a service break to existing customers and their services.
• 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.
• 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.
• Aspects of data-plane, OAM and recovery mechanisms, control plane and management-plane

Different migration models have been discussed in the literature. 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 the following descriptions we concentrate on the following models:

• 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 by gateways. See section 3.1 for more details.
• Phased model – where the existing equipment is slowly upgraded with new MPLS-TP capabilities as needed. For more details see section 3.2.
• 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.  Island model

In this migration model presented previously in [RFC5145] (Shiomoto, K., “Framework for MPLS-TE to GMPLS Migration,” March 2008.) 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.

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 (Balanced island path). 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 (Balanced island path).

     +----+   +--+   +----+   +--+   +----+  +--+   +----+
     |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

         +----+   +--+   +----+   +--+   +----+
         |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

The tools that may be used at the border, 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 layered network solution through the use of an LSP between TE-links to carry legacy traffic, when possible.

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.  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 to support the new functionality and the support of all the vendors to implement the same functionality.

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.  Integrated model

This model allows the operator to run services over two clouds of the 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 new "dual-mode" nodes that would support an integrated MPLS-TP and legacy functionality, see Figure 3 (Integrated model network). These dual-mode nodes would route the different services to the paths in the different technology clouds. This avoids the need for interworking that is required in the island model described in section 3.1.

                  ______________________________________
                _/    Service Provider's Network        \
               /             ____     ___       ____     \___
             _/            _/    \___/   \    _/    \__      \
            /             /               \__/ ...     \_     \___
           /             /              .......   ...    \        \
          |    +--------|   ...Legacy Logical Network ..  |---+    |
          |    |.........\..   ..    ..                ../....|    |
          |    |.         \   ___....  ___     __      _/    .|    |
          |  +----+        \_/   \____/   \___/  \____/     +----+ |
         ....|Dual|                                         |Dual|...
          |  |    |                                         |    | |
         ****|Mode|          ____     ___       ____        |Mode|***
          |  +----+        _/    \___/   \    _/    \__     +----+ |
           \   | *        /               \__/         \_    *|    |
            \  | ******* /***                          **\****|   /
             \ +--------|    ***MPLS-TP Logical Ntwrk***  |---+  /
              \____      \      ***    *****   *****     /      |
                   \      \   ___  ****___  ***__      _/      /
                    \      \_/   \____/   \___/  \____/    ___/
                     \____________________________________/

                  .... - Legacy service path
                  **** - MPLS-TP service path

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.

4.  Migrating from TDM

4.1.  Main motivation

4.2.  Migration Activities and Techniques

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

7.  Migrating from MPLS

7.1.  MPLS-TE

7.1.1.  Main motivation

7.1.2.  Migration activities and Techniques

7.2.  IP/MPLS

7.2.1.  Main motivation

7.2.2.  Migration activities and Techniques

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

13.2. Informative References

Authors' Addresses