Network Working Group N. Sprecher
Internet-Draft Y. Weingarten
Intended status: Informational Nokia Siemens Networks
Expires: January 13, 2011 K. Hong
L. Fang
Cisco Systems, Inc.
July 12, 2010
Migration Considerations and Techniques to Multiprotocol Label Switching
Transport Profile based Networks and Services
draft-sprecher-mpls-tp-migration-02.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 MPLS-TP based network in an economic way, enables
service providers to increase their revenue while remaining
competitive.
This document presents the motivations for migrating from different
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 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 January 13, 2011.
Sprecher, et al. Expires January 13, 2011 [Page 1]
Internet-Draft MPLS-TP migration July 2010
Copyright Notice
Copyright (c) 2010 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.
Sprecher, et al. Expires January 13, 2011 [Page 2]
Internet-Draft MPLS-TP migration July 2010
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 Strategies . . . . . . . . . . . . . . . . . 7
4. Migrating from TDM . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Main motivation . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Migration Activities and Techniques . . . . . . . . . . . . 7
5. Migrating from ATM . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Main motivation . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Migration activities and Techniques . . . . . . . . . . . . 7
6. Migrating from Ethernet . . . . . . . . . . . . . . . . . . . . 7
6.1. Main motivation . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Migration activities and Techniques . . . . . . . . . . . . 8
7. Migrating from MPLS . . . . . . . . . . . . . . . . . . . . . . 8
7.1. MPLS-TE . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1.1. Main motivation . . . . . . . . . . . . . . . . . . . . 8
7.1.2. Migration activities and Techniques . . . . . . . . . . 8
7.2. IP/MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2.1. Main motivation . . . . . . . . . . . . . . . . . . . . 8
7.2.2. Migration activities and Techniques . . . . . . . . . . 8
8. Migrating from pre-release MPLS-TP (T-MPLS) . . . . . . . . . . 8
8.1. Main motivation . . . . . . . . . . . . . . . . . . . . . . 8
8.2. Migration activities and Techniques . . . . . . . . . . . . 8
9. Manageability Considerations . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Sprecher, et al. Expires January 13, 2011 [Page 3]
Internet-Draft MPLS-TP migration July 2010
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 on
the experience of the MPLS architecture. The architecture is defined
to allow MPLS-TP networks to operate whether the configuration was
implemented by use of control-plane signaling or through use of 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
Sprecher, et al. Expires January 13, 2011 [Page 4]
Internet-Draft MPLS-TP migration July 2010
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 conformant 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 being expected to continue to increase. With the
movement towards 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
Sprecher, et al. Expires January 13, 2011 [Page 5]
Internet-Draft MPLS-TP migration July 2010
(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 towards
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
Sprecher, et al. Expires January 13, 2011 [Page 6]
Internet-Draft MPLS-TP migration July 2010
3. General Migration Strategies
Smooth migration paths are required when migrating from various
transport networks and services towards the MPLS-TP-based packet-
centric architecture, and it should be done in a cost- efficient and
scalabel way. 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 seamless
interworking between the installed networks and the MPLS-TP based
network, also eliminate the risks associated with fork-lifting
upgrade on the whole network on one day with a new technology or
implementation. This approach allows service providers to ensure
that the new implementations work as expected in live networks and
that the customers' quality of experience is maintained and not
affected.
The seamless interworking between the installed network and te
MPLS-TP network networks should consider aspects of data-plane, OAM
and recovery mechanisms, control plane and management-plane
The migration process must obviously be performed without a service
break. Existing connections must not be disrupted and service
performance, availability, and subscriber experience must remain
unaffected.
When the upgrade process is completed, new connections can ne setup
using MPLS-TP.
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
Sprecher, et al. Expires January 13, 2011 [Page 7]
Internet-Draft MPLS-TP migration July 2010
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-release 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.
Sprecher, et al. Expires January 13, 2011 [Page 8]
Internet-Draft MPLS-TP migration July 2010
[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 Survivabiliry 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.
[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
Sprecher, et al. Expires January 13, 2011 [Page 9]
Internet-Draft MPLS-TP migration July 2010
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
Sprecher, et al. Expires January 13, 2011 [Page 10]