draft-ietf-mpls-tp-requirements-10.txt   rfc5654.txt 
MPLS Working Group B. Niven-Jenkins, Ed. Network Working Group B. Niven-Jenkins, Ed.
Internet-Draft BT Request for Comments: 5654 BT
Intended status: Standards Track D. Brungard, Ed. Category: Standards Track D. Brungard, Ed.
Expires: February 17, 2010 AT&T AT&T
M. Betts, Ed. M. Betts, Ed.
Huawei Technologies Huawei Technologies
N. Sprecher N. Sprecher
Nokia Siemens Networks Nokia Siemens Networks
S. Ueno S. Ueno
NTT NTT Communications
August 16, 2009 September 2009
MPLS-TP Requirements
draft-ietf-mpls-tp-requirements-10
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 17, 2010.
Copyright Notice
Copyright (c) 2009 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 Requirements of an MPLS Transport Profile
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document specifies the requirements of an MPLS Transport Profile This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). This document is a product of a joint International (MPLS-TP). This document is a product of a joint effort of the
Telecommunications Union (ITU)-IETF effort to include an MPLS International Telecommunications Union (ITU) and IETF to include an
Transport Profile within the IETF MPLS and PWE3 architectures to MPLS Transport Profile within the IETF MPLS and PWE3 architectures to
support the capabilities and functionalities of a packet transport support the capabilities and functionalities of a packet transport
network as defined by International Telecommunications Union - network as defined by International Telecommunications Union -
Telecommunications Standardization Sector (ITU-T). Telecommunications Standardization Sector (ITU-T).
This work is based on two sources of requirements; MPLS and PWE3 This work is based on two sources of requirements: MPLS and PWE3
architectures as defined by IETF, and packet transport networks as architectures as defined by IETF, and packet transport networks as
defined by ITU-T. defined by ITU-T.
The requirements expressed in this document are for the behavior of The requirements expressed in this document are for the behavior of
the protocol mechanisms and procedures that constitute building the protocol mechanisms and procedures that constitute building
blocks out of which the MPLS transport profile is constructed. The blocks out of which the MPLS Transport Profile is constructed. The
requirements are not implementation requirements. requirements are not implementation requirements.
Requirements Language Status of This Memo
Although this document is not a protocol specification, the key words This document specifies an Internet standards track protocol for the
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", Internet community, and requests discussion and suggestions for
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be improvements. Please refer to the current edition of the "Internet
interpreted as described in RFC 2119 [RFC2119] and are to be Official Protocol Standards" (STD 1) for the standardization state
interpreted as instructions to the protocol designers producing and status of this protocol. Distribution of this memo is unlimited.
solutions that satisfy the requirements set out in this document.
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
RFC 5654 MPLS-TP Requirements September 2009
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 BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8 1.2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6
1.2. Transport network overview . . . . . . . . . . . . . . . . 11 1.2.2. Definitions . . . . . . . . . . . . . . . . . . . . . 7
1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12 1.3. Transport Network Overview . . . . . . . . . . . . . . . . 10
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13 1.4. Layer Network Overview . . . . . . . . . . . . . . . . . . 11
2.1. General requirements . . . . . . . . . . . . . . . . . . . 13 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 12
2.2. Layering requirements . . . . . . . . . . . . . . . . . . 16 2.1. General Requirements . . . . . . . . . . . . . . . . . . . 13
2.3. Data plane requirements . . . . . . . . . . . . . . . . . 17 2.2. Layering Requirements . . . . . . . . . . . . . . . . . . 16
2.4. Control plane requirements . . . . . . . . . . . . . . . . 18 2.3. Data Plane Requirements . . . . . . . . . . . . . . . . . 17
2.5. Recovery requirements . . . . . . . . . . . . . . . . . . 19 2.4. Control Plane Requirements . . . . . . . . . . . . . . . . 18
2.5.1. Data plane behavior requirements . . . . . . . . . . . 20 2.5. Recovery Requirements . . . . . . . . . . . . . . . . . . 19
2.5.1.1. Protection . . . . . . . . . . . . . . . . . . . . 21 2.5.1. Data-Plane Behavior Requirements . . . . . . . . . . . 20
2.5.1.2. Sharing of protection resources . . . . . . . . . 22 2.5.1.1. Protection . . . . . . . . . . . . . . . . . . . . 20
2.5.2. Restoration . . . . . . . . . . . . . . . . . . . . . 22 2.5.1.2. Sharing of Protection Resources . . . . . . . . . 21
2.5.3. Triggers for protection, restoration, and reversion . 22 2.5.2. Restoration . . . . . . . . . . . . . . . . . . . . . 21
2.5.4. Management plane operation of protection and 2.5.3. Triggers for Protection, Restoration, and Reversion . 22
restoration . . . . . . . . . . . . . . . . . . . . . 23 2.5.4. Management-Plane Operation of Protection and
2.5.5. Control plane and in-band OAM operation of recovery . 24 Restoration . . . . . . . . . . . . . . . . . . . . . 22
2.5.6. Topology-specific recovery mechanisms . . . . . . . . 24 2.5.5. Control Plane and In-Band OAM Operation of Recovery . 23
2.5.6.1. Ring protection . . . . . . . . . . . . . . . . . 24 2.5.6. Topology-Specific Recovery Mechanisms . . . . . . . . 24
2.6. QoS requirements . . . . . . . . . . . . . . . . . . . . . 27 2.5.6.1. Ring Protection . . . . . . . . . . . . . . . . . 24
3. Requirements Discussed in Other Documents . . . . . . . . . . 28 2.6. QoS Requirements . . . . . . . . . . . . . . . . . . . . . 27
3.1. Network Management requirements . . . . . . . . . . . . . 28 3. Requirements Discussed in Other Documents . . . . . . . . . . 27
3.2. Operation, Administration and Maintenance (OAM) 3.1. Network Management Requirements . . . . . . . . . . . . . 27
requirements . . . . . . . . . . . . . . . . . . . . . . . 28 3.2. Operation, Administration, and Maintenance (OAM)
3.3. Network performance monitoring requirements . . . . . . . 28 Requirements . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Security requirements . . . . . . . . . . . . . . . . . . 28 3.3. Network Performance-Monitoring Requirements . . . . . . . 28
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 3.4. Security Requirements . . . . . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 4. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 6.1. Normative References . . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . . 30 6.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
RFC 5654 MPLS-TP Requirements September 2009
1. Introduction 1. Introduction
Bandwidth demand continues to grow worldwide, stimulated by the Bandwidth demand continues to grow worldwide, stimulated by the
accelerating growth and penetration of new packet based services and accelerating growth and penetration of new packet-based services and
multimedia applications: multimedia applications:
o Packet-based services such as Ethernet, Voice over IP (VoIP), o Packet-based services such as Ethernet, Voice over IP (VoIP),
Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP Layer 2 (L2) / Layer 3 (L3) Virtual Private Networks (VPNs), IP
Television (IPTV), Radio Access Network (RAN) backhauling, etc., television (IPTV), Radio Access Network (RAN) backhauling, etc.
o Applications with various bandwidth and Quality of Service (QoS) o Applications with various bandwidth and Quality of Service (QoS)
requirements. requirements.
This growth in demand has resulted in dramatic increases in access This growth in demand has resulted in dramatic increases in access
rates that are, in turn, driving dramatic increases in metro and core rates that are, in turn, driving dramatic increases in metro and core
network bandwidth requirements. network bandwidth requirements.
Over the past two decades, the evolving optical transport Over the past two decades, the evolving optical transport
infrastructure (Synchronous Optical Networking (SONET)/Synchronous infrastructure (Synchronous Optical Networking (SONET) / Synchronous
Digital Hierarchy (SDH), Optical Transport Network (OTN)) has Digital Hierarchy (SDH), Optical Transport Network (OTN)) has
provided carriers with a high benchmark for reliability and provided carriers with a high benchmark for reliability and
operational simplicity. operational simplicity.
With the movement towards packet based services, the transport With the movement towards packet-based services, the transport
network has to evolve to encompass the provision of packet aware network has to evolve to encompass the provision of packet-aware
capabilities while enabling carriers to leverage their installed, as capabilities while enabling carriers to leverage their installed, as
well as planned, transport infrastructure investments. well as planned, transport infrastructure investments.
Carriers are in need of technologies capable of efficiently Carriers are in need of technologies capable of efficiently
supporting packet based services and applications on their transport supporting packet-based services and applications on their transport
networks with guaranteed Service Level Agreements (SLAs). The need networks with guaranteed Service Level Agreements (SLAs). The need
to increase their revenue while remaining competitive forces to increase their revenue while remaining competitive forces
operators to look for the lowest network Total Cost of Ownership operators to look for the lowest network Total Cost of Ownership
(TCO). Investment in equipment and facilities (Capital Expenditure (TCO). Investment in equipment and facilities (Capital Expenditure
(CAPEX)) and Operational Expenditure (OPEX) should be minimized. (CAPEX)) and Operational Expenditure (OPEX) should be minimized.
There are a number of technology options for carriers to meet the There are a number of technology options for carriers to meet the
challenge of increased service sophistication and transport challenge of increased service sophistication and transport
efficiency, with increasing usage of hybrid packet transport and efficiency, with increasing usage of hybrid packet-transport and
circuit transport technology solutions. To realize these goals, it circuit-transport technology solutions. To realize these goals, it
is essential that packet transport technology be available that can is essential that packet-transport technology be available that can
support the same high benchmarks for reliability and operational support the same high benchmarks for reliability and operational
simplicity set by SDH/SONET and OTN technologies. simplicity set by SDH/SONET and OTN technologies.
Furthermore for carriers it is important that operation of such RFC 5654 MPLS-TP Requirements September 2009
Furthermore, for carriers it is important that operation of such
packet transport networks should preserve the look-and-feel to which packet transport networks should preserve the look-and-feel to which
carriers have become accustomed in deploying their optical transport carriers have become accustomed in deploying their optical transport
networks, while providing common, multi-layer operations, resiliency, networks, while providing common, multi-layer operations, resiliency,
control and multi-technology management. control, and multi-technology management.
Transport carriers require control and deterministic usage of network Transport carriers require control and deterministic usage of network
resources. They need end-to-end control to engineer network paths resources. They need end-to-end control to engineer network paths
and to efficiently utilize network resources. They require and to efficiently utilize network resources. They require
capabilities to support static (management plane based) or dynamic capabilities to support static (management-plane-based) or dynamic
(control plane based) provisioning of deterministic, protected and (control-plane-based) provisioning of deterministic, protected, and
secured services and their associated resources. secured services and their associated resources.
It is also important to ensure smooth interworking of the packet It is also important to ensure smooth interworking of the packet
transport network with other existing/legacy packet networks, and transport network with other existing/legacy packet networks, and
provide mappings to enable packet transport carriage over a variety provide mappings to enable packet transport carriage over a variety
of transport network infrastructures. The latter has been termed of transport network infrastructures. The latter has been termed
vertical interworking, and is also known as client/server or network vertical interworking, and is also known as client/server or network
interworking. The former has been termed horizontal interworking, interworking. The former has been termed horizontal interworking,
and is also known as peer-partition or service interworking. For and is also known as peer-partition or service interworking. For
more details on interworking and some of the issues that may arise more details on interworking and some of the issues that may arise
(especially with horizontal interworking) see G.805 [ITU.G805.2000] (especially with horizontal interworking), see G.805 [ITU.G805.2000]
and Y.1401 [ITU.Y1401.2008]. and Y.1401 [ITU.Y1401.2008].
Multi-Protocol Label Switching (MPLS) is a maturing packet technology Multi-Protocol Label Switching (MPLS) is a maturing packet technology
and it is already playing an important role in transport networks and and it is already playing an important role in transport networks and
services. However, not all of MPLS's capabilities and mechanisms are services. However, not all of MPLS's capabilities and mechanisms are
needed and/or consistent with transport network operations. There needed and/or consistent with transport network operations. There
are also transport technology characteristics that are not currently are also transport technology characteristics that are not currently
reflected in MPLS. There is therefore the need to define an MPLS reflected in MPLS. Therefore, there is the need to define an MPLS
Transport Profile (MPLS-TP) that supports the capabilities and Transport Profile (MPLS-TP) that supports the capabilities and
functionalities needed for packet transport network services and functionalities needed for packet-transport network services and
operations through combining the packet experience of MPLS with the operations through combining the packet experience of MPLS with the
operational experience and practices of existing transport networks. operational experience and practices of existing transport networks.
MPLS-TP will enable the deployment of packet based transport networks MPLS-TP will enable the deployment of packet-based transport networks
that will efficiently scale to support packet services in a simple that will efficiently scale to support packet services in a simple
and cost effective way. MPLS-TP needs to combine the necessary and cost-effective way. MPLS-TP needs to combine the necessary
existing capabilities of MPLS with additional minimal mechanisms in existing capabilities of MPLS with additional minimal mechanisms in
order that it can be used in a transport role. order that it can be used in a transport role.
This document specifies the requirements of an MPLS Transport Profile This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). The requirements are for the behavior of the protocol (MPLS-TP). The requirements are for the behavior of the protocol
mechanisms and procedures that constitute building blocks out of mechanisms and procedures that constitute building blocks out of
which the MPLS transport profile is constructed. That is, the which the MPLS Transport Profile is constructed. That is, the
requirements indicate what features are to be available in the MPLS requirements indicate what features are to be available in the MPLS
toolkit for use by MPLS-TP. The requirements in this document do not toolkit for use by MPLS-TP. The requirements in this document do not
RFC 5654 MPLS-TP Requirements September 2009
describe what functions an MPLS-TP implementation supports. The describe what functions an MPLS-TP implementation supports. The
purpose of this document is to identify the toolkit and any new purpose of this document is to identify the toolkit and any new
protocol work that is required. protocol work that is required.
This document is a product of a joint ITU-T and IETF effort to This document is a product of a joint ITU-T and IETF effort to
include an MPLS Transport Profile within the IETF MPLS and PWE3 include an MPLS Transport Profile within the IETF MPLS and PWE3
architectures to support the capabilities and functionalities of a architectures to support the capabilities and functionalities of a
packet transport network as defined by ITU-T. The document is a packet transport network as defined by ITU-T. The document is a
requirements specification, but is presented on the Standards Track requirements specification, but is presented on the Standards Track
so that it can be more easily cited as a normative reference from so that it can be more easily cited as a normative reference from
skipping to change at page 6, line 24 skipping to change at page 5, line 32
The relevant functions of MPLS and PWE3 are included in MPLS-TP, The relevant functions of MPLS and PWE3 are included in MPLS-TP,
except where explicitly excluded. Any new functionality that is except where explicitly excluded. Any new functionality that is
defined to fulfill the requirements for MPLS-TP must be agreed within defined to fulfill the requirements for MPLS-TP must be agreed within
the IETF through the IETF consensus process as per [RFC4929]. the IETF through the IETF consensus process as per [RFC4929].
MPLS-TP transport paths may be established using static or dynamic MPLS-TP transport paths may be established using static or dynamic
configuration. It should be noted that the MPLS-TP network and its configuration. It should be noted that the MPLS-TP network and its
transport paths can always be operated fully (including OAM and transport paths can always be operated fully (including OAM and
protection capabilities) in the absence of any control plane. protection capabilities) in the absence of any control plane.
1.1. Terminology 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Although this document is not a protocol specification, the use of
this language clarifies the instructions to protocol designers
producing solutions that satisfy the requirements set out in this
document.
1.2. Terminology
Note: Mapping between the terms in this section and ITU-T terminology Note: Mapping between the terms in this section and ITU-T terminology
is described in [I-D.helvoort-mpls-tp-rosetta-stone]. is described in [TP-TERMS].
The recovery requirements in this document use the recovery The recovery requirements in this document use the recovery
terminology defined in RFC 4427 [RFC4427], this is applied to both terminology defined in RFC 4427 [RFC4427]; this is applied to both
control plane and management plane based operations of MPLS-TP control-plane- and management-plane-based operations of MPLS-TP
transport paths. transport paths.
1.1.1. Abbreviations RFC 5654 MPLS-TP Requirements September 2009
1.2.1. Abbreviations
ASON: Automatically Switched Optical Network ASON: Automatically Switched Optical Network
ATM: Asynchronous Transfer Mode ATM: Asynchronous Transfer Mode
CAPEX: Capital Expenditure CAPEX: Capital Expenditure
CE: Customer Edge CE: Customer Edge
FR: Frame Relay FR: Frame Relay
GMPLS: Generalised Multi-Protocol Label Switching GMPLS: Generalized Multi-Protocol Label Switching
IGP: Interior Gateway Protocol IGP: Interior Gateway Protocol
IPTV: IP Television IPTV: IP Television
L2: Layer 2 L2: Layer 2
L3: Layer 3 L3: Layer 3
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
skipping to change at page 7, line 14 skipping to change at page 6, line 35
L2: Layer 2 L2: Layer 2
L3: Layer 3 L3: Layer 3
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
OAM: Operations, Administration and Maintenance OAM: Operations, Administration, and Maintenance
OPEX: Operational Expenditure OPEX: Operational Expenditure
OSI: Open Systems Interconnection OSI: Open Systems Interconnection
OTN: Optical Transport Network OTN: Optical Transport Network
P2MP: Point to Multi-Point P2MP: Point to Multipoint
P2P: Point to Point P2P: Point to Point
PDU: Protocol Data Unit PDU: Protocol Data Unit
PSC: Protection State Coordination PSC: Protection State Coordination
PW: Pseudowire PW: Pseudowire
QoS: Quality of Service QoS: Quality of Service
RFC 5654 MPLS-TP Requirements September 2009
SDH: Synchronous Digital Hierarchy SDH: Synchronous Digital Hierarchy
SLA: Service Level Agreement SLA: Service Level Agreement
SLS: Service Level Specification SLS: Service Level Specification
S-PE: Switching Provider Edge S-PE: Switching Provider Edge
SONET: Synchronous Optical Network SONET: Synchronous Optical Network
skipping to change at page 8, line 4 skipping to change at page 7, line 24
SONET: Synchronous Optical Network SONET: Synchronous Optical Network
SRLG: Shared Risk Link Group SRLG: Shared Risk Link Group
TCO: Total Cost of Ownership TCO: Total Cost of Ownership
T-PE: Terminating Provider Edge T-PE: Terminating Provider Edge
VoIP: Voice over IP VoIP: Voice over IP
VPN: Virtual Private Network VPN: Virtual Private Network
WDM: Wavelength Division Multiplexing WDM: Wavelength Division Multiplexing
1.1.2. Definitions 1.2.2. Definitions
Note: The definition of segment in a GMPLS/ASON context (i.e. as Note: The definition of "segment" in a GMPLS/ASON context (i.e., as
defined in RFC4397 [RFC4397]) encompasses both segment and defined in RFC4397 [RFC4397]) encompasses both "segment" and
concatenated segment as defined in this document. "concatenated segment" as defined in this document.
Associated bidirectional path: A path that supports traffic flow in Associated bidirectional path: A path that supports traffic flow in
both directions but which is constructed from a pair of both directions but that is constructed from a pair of unidirectional
unidirectional paths (one for each direction) which are associated paths (one for each direction) that are associated with one another
with one another at the path's ingress/egress points. The forward at the path's ingress/egress points. The forward and backward
and backward directions are setup, monitored and protected directions are setup, monitored, and protected independently. As a
independently. As a consequence they may or may not follow the same consequence, they may or may not follow the same route (links and
route (links and nodes) across the network. nodes) across the network.
Client layer network: In a client/server relationship (see G.805 Client layer network: In a client/server relationship (see G.805
[ITU.G805.2000]), the client layer network receives a (transport) [ITU.G805.2000]), the client layer network receives a (transport)
service from the lower server layer network (usually the layer service from the lower server layer network (usually the layer
network under consideration). network under consideration).
Concatenated Segment: A serial-compound link connection as defined in Concatenated Segment: A serial-compound link connection as defined in
G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part
of an LSP or multi-segment PW that comprises a set of segments and of an LSP or multi-segment PW that comprises a set of segments and
their interconnecting nodes in sequence. See also "Segment". their interconnecting nodes in sequence. See also "Segment".
Control Plane: Within the scope of this document the control plane RFC 5654 MPLS-TP Requirements September 2009
Control Plane: Within the scope of this document, the control plane
performs transport path control functions. Through signalling, the performs transport path control functions. Through signalling, the
control plane sets up, modifies and releases transport paths, and may control plane sets up, modifies and releases transport paths, and may
recover a transport path in case of a failure. The control plane recover a transport path in case of a failure. The control plane
also performs other functions in support of transport path control, also performs other functions in support of transport path control,
such as routing information dissemination. such as routing information dissemination.
Co-routed Bidirectional path: A path where the forward and backward Co-routed Bidirectional path: A path where the forward and backward
directions follow the same route (links and nodes) across the directions follow the same route (links and nodes) across the
network. Both directions are setup, monitored and protected as a network. Both directions are setup, monitored and protected as a
single entity. A transport network path is typically co-routed. single entity. A transport network path is typically co-routed.
skipping to change at page 9, line 7 skipping to change at page 8, line 29
Domain: A domain represents a collection of entities (for example Domain: A domain represents a collection of entities (for example
network elements) that are grouped for a particular purpose, examples network elements) that are grouped for a particular purpose, examples
of which are administrative and/or managerial responsibilities, trust of which are administrative and/or managerial responsibilities, trust
relationships, addressing schemes, infrastructure capabilities, relationships, addressing schemes, infrastructure capabilities,
aggregation, survivability techniques, distributions of control aggregation, survivability techniques, distributions of control
functionality, etc. Examples of such domains include IGP areas and functionality, etc. Examples of such domains include IGP areas and
Autonomous Systems. Autonomous Systems.
Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A
layer network provides for the transfer of client information and layer network provides for the transfer of client information and
independent operation of the client OAM. A Layer Network may be independent operation of the client OAM. A layer network may be
described in a service context as follows: one layer network may described in a service context as follows: one layer network may
provide a (transport) service to higher client layer network and may, provide a (transport) service to a higher client layer network and
in turn, be a client to a lower layer network. A layer network is a may, in turn, be a client to a lower-layer network. A layer network
logical construction somewhat independent of arrangement or is a logical construction somewhat independent of arrangement or
composition of physical network elements. A particular physical composition of physical network elements. A particular physical
network element may topologically belong to more than one layer network element may topologically belong to more than one layer
network, depending on the actions it takes on the encapsulation network, depending on the actions it takes on the encapsulation
associated with the logical layers (e.g. the label stack), and thus associated with the logical layers (e.g., the label stack), and thus
could be modeled as multiple logical elements. A layer network may could be modeled as multiple logical elements. A layer network may
consist of one or more sublayers. Section 1.3 provides a more consist of one or more sublayers. Section 1.4 provides a more
detailed overview of what constitutes a layer network. For detailed overview of what constitutes a layer network. For
additional explanation of how layer networks relate to the OSI additional explanation of how layer networks relate to the OSI
concept of layering see Appendix I of Y.2611 [ITU.Y2611.2006]. concept of layering, see Appendix I of Y.2611 [ITU.Y2611.2006].
Link: A physical or logical connection between a pair of LSRs that Link: A physical or logical connection between a pair of LSRs that
are adjacent at the (sub)layer network under consideration. A link are adjacent at the (sub)layer network under consideration. A link
may carry zero, one or more LSPs or PWs. A packet entering a link may carry zero, one, or more LSPs or PWs. A packet entering a link
will emerge with the same label stack entry values. will emerge with the same label-stack entry values.
MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from a MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from a
set of LSRs and logical data links (such as MPLS-TP LSP tunnels or set of LSRs and logical data links (such as MPLS-TP LSP tunnels or
MPLS-TP pseudowires) and physical data links that form a ring MPLS-TP pseudowires) and physical data links that form a ring
topology. topology.
Path: See Transport Path. Path: See Transport Path.
RFC 5654 MPLS-TP Requirements September 2009
MPLS-TP Physical Ring: An MPLS-TP physical ring is constructed from a MPLS-TP Physical Ring: An MPLS-TP physical ring is constructed from a
set of LSRs and physical data links that form a ring topology. set of LSRs and physical data links that form a ring topology.
MPLS-TP Ring Topology: In an MPLS-TP ring topology each LSR is MPLS-TP Ring Topology: In an MPLS-TP ring topology, each LSR is
connected to exactly two other LSRs, each via a single point-to-point connected to exactly two other LSRs, each via a single point-to-point
bidirectional MPLS-TP capable link. A ring may also be constructed bidirectional MPLS-TP capable link. A ring may also be constructed
from only two LSRs where there are also exactly two links. Rings may from only two LSRs where there are also exactly two links. Rings may
be connected to other LSRs to form a larger network. Traffic be connected to other LSRs to form a larger network. Traffic
originating or terminating outside the ring may be carried over the originating or terminating outside the ring may be carried over the
ring. Client network nodes (such as CEs) may be connected directly ring. Client network nodes (such as CEs) may be connected directly
to an LSR in the ring. to an LSR in the ring.
Section Layer Network: A section layer is a server layer (which may Section Layer Network: A section layer is a server layer (which may
be MPLS-TP or a different technology) which provides for the transfer be MPLS-TP or a different technology) that provides for the transfer
of the section layer client information between adjacent nodes in the of the section-layer client information between adjacent nodes in the
transport path layer or transport service layer. A section layer may transport-path layer or transport-service layer. A section layer may
provide for aggregation of multiple MPLS-TP clients. Note that G.805 provide for aggregation of multiple MPLS-TP clients. Note that G.805
[ITU.G805.2000] defines the section layer as one of the two layer [ITU.G805.2000] defines the section layer as one of the two layer
networks in a transmission media layer network. The other layer networks in a transmission-media layer network. The other layer
network is the physical media layer network. network is the physical-media layer network.
Segment: A link connection as defined in G.805 [ITU.G805.2000]. A Segment: A link connection as defined in G.805 [ITU.G805.2000]. A
segment is the part of an LSP that traverses a single link or the segment is the part of an LSP that traverses a single link or the
part of a PW that traverses a single link (i.e. that connects a pair part of a PW that traverses a single link (i.e., that connects a pair
of adjacent {Switching|Terminating} Provider Edges). See also of adjacent {Switching|Terminating} Provider Edges). See also
"Concatenated Segment". "Concatenated Segment".
Server Layer Network: In a client/server relationship (see G.805 Server Layer Network: In a client/server relationship (see G.805
[ITU.G805.2000]), the server layer network provides a (transport) [ITU.G805.2000]), the server layer network provides a (transport)
service to the higher client layer network (usually the layer network service to the higher client layer network (usually the layer network
under consideration). under consideration).
Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The
distinction between a layer network and a sublayer is that a sublayer distinction between a layer network and a sublayer is that a sublayer
is not directly accessible to clients outside of its encapsulating is not directly accessible to clients outside of its encapsulating
layer network and offers no direct transport service for a higher layer network and offers no direct transport service for a higher
layer (client) network. layer (client) network.
Switching Provider Edge (S-PE): See [I-D.ietf-pwe3-ms-pw-arch]. Switching Provider Edge (S-PE): See [MS-PW-ARCH].
Terminating Provider Edge (T-PE): See [I-D.ietf-pwe3-ms-pw-arch]. Terminating Provider Edge (T-PE): See [MS-PW-ARCH].
Transport Path: A network connection as defined in G.805 Transport Path: A network connection as defined in G.805
[ITU.G805.2000]. In an MPLS-TP environment a transport path [ITU.G805.2000]. In an MPLS-TP environment, a transport path
corresponds to an LSP or a PW. corresponds to an LSP or a PW.
Transport Path Layer: A (sub-)layer network that provides point-to- RFC 5654 MPLS-TP Requirements September 2009
point or point-to-multipoint transport paths. It provides
independent (of the client) OAM when transporting its clients. Transport Path Layer: A (sub)layer network that provides point-to-
point or point-to-multipoint transport paths. It provides OAM that
is independent of the clients that it is transporting.
Transport Service Layer: A layer network in which transport paths are Transport Service Layer: A layer network in which transport paths are
used to carry a customer's (individual or bundled) service (may be used to carry a customer's (individual or bundled) service (may be
point-to-point, point-to-multipoint or multipoint-to-multipoint point-to-point, point-to-multipoint, or multipoint-to-multipoint
services). services).
Transmission Media Layer: A layer network, consisting of a section Transmission Media Layer: A layer network, consisting of a section
layer network and a physical layer network as defined in G.805 layer network and a physical layer network as defined in G.805
[ITU.G805.2000], that provides sections (two-port point-to-point [ITU.G805.2000], that provides sections (two-port point-to-point
connections) to carry the aggregate of network transport path or connections) to carry the aggregate of network-transport path or
network service layers on various physical media. network-service layers on various physical media.
Unidirectional Path: A path that supports traffic flow in only one Unidirectional Path: A path that supports traffic flow in only one
direction. direction.
1.2. Transport network overview 1.3. Transport Network Overview
The connectivity service is the basic service provided by a transport The connectivity service is the basic service provided by a transport
network. The purpose of a transport network is to carry its customer network. The purpose of a transport network is to carry its customer
traffic (i.e. the stream of customer PDUs or customer bits, including traffic (i.e., the stream of customer PDUs or customer bits,
overhead) between endpoints in the transport network (typically over including overhead) between end points in the transport network
several intermediate nodes). The connectivity services offered to (typically over several intermediate nodes). The connectivity
customers are typically aggregated into large transport paths with services offered to customers are typically aggregated into large
long-holding times and independent OAM (of the client OAM), which transport paths with long holding times and OAM that is independent
contribute to enabling the efficient and reliable operation of the (of the client OAM), which contribute to enabling the efficient and
transport network. These transport paths are modified infrequently. reliable operation of the transport network. These transport paths
are modified infrequently.
Quality-of-service mechanisms are required in the packet transport Quality-of-service mechanisms are required in the packet transport
network to ensure the prioritization of critical services, to network to ensure the prioritization of critical services, to
guarantee bandwidth and to control jitter and delay. A transport guarantee bandwidth, and to control jitter and delay. A transport
network must provide the means to commit quality of service network must provide the means to meet the quality-of-service
objectives to clients. This is achieved by providing a mechanism for objectives of its clients. This is achieved by providing a mechanism
client network service demarcation for the network path together with for client network service demarcation for the network path together
an associated network resiliency mechanism. with an associated network resiliency mechanism.
Aggregation is beneficial for achieving scalability and security Aggregation is beneficial for achieving scalability and security
since: since:
1. It reduces the number of provisioning and forwarding states in 1. It reduces the number of provisioning and forwarding states in
the network core. the network core.
2. It reduces load and the cost of implementing service assurance 2. It reduces load and the cost of implementing service assurance
and fault management. and fault management.
3. Customer traffic is encapsulated and layer associated OAM RFC 5654 MPLS-TP Requirements September 2009
3. Customer traffic is encapsulated and layer-associated OAM
overhead is added. This allows complete isolation of customer overhead is added. This allows complete isolation of customer
traffic and its management from carrier operations. traffic and its management from carrier operations.
An important attribute of a transport network is that it is able to An important attribute of a transport network is that it is able to
function regardless of which clients are using its connection service function regardless of which clients are using its connection service
or over which transmission media it is running. The client, or over which transmission media it is running. From a functional
transport network and server layers are from a functional and and operational point of view, the client, transport network, and
operations point of view independent layer networks. Another key server layers are independent layer networks. Another key
characteristic of transport networks is the capability to maintain characteristic of transport networks is the capability to maintain
the integrity of the client across the transport network. A the integrity of the client across the transport network. A
transport network must also provide a method of service monitoring in transport network must also provide a method of service monitoring in
order to verify the delivery of an agreed quality of service. This order to verify the delivery of an agreed quality of service. This
is enabled by means of carrier-grade OAM tools. is enabled by means of carrier-grade OAM tools.
Customer traffic is first encapsulated within the transport service Customer traffic is first encapsulated within the transport-service
layer network. The transport service layer network signals may then layer network. The transport service layer network signals may then
be aggregated into a transport path layer network for transport be aggregated into a transport-path layer network for transport
through the network in order to optimize network management. through the network in order to optimize network management.
Transport-service layer network OAM is used to monitor the transport
Transport service layer network OAM is used to monitor the transport integrity of the customer traffic, and transport-path layer network
integrity of the customer traffic and transport path layer network
OAM is used to monitor the transport integrity of the aggregates. At OAM is used to monitor the transport integrity of the aggregates. At
any hop, the aggregated signals may be further aggregated in lower any hop, the aggregated signals may be further aggregated in lower-
layer transport network paths for transport across intermediate layer transport network paths for transport across intermediate
shared links. The transport service layer network signals are shared links. The transport service layer network signals are
extracted at the edges of aggregation domains, and are either extracted at the edges of aggregation domains, and are either
delivered to the customer or forwarded to another domain. In the delivered to the customer or forwarded to another domain. In the
core of the network, only the transport path layer network signals core of the network, only the transport path layer network signals
are monitored at intermediate points; individual transport service are monitored at intermediate points; individual transport service
layer network signals are monitored at the network boundary. layer network signals are monitored at the network boundary.
Although the connectivity of the transport service layer network may Although the connectivity of the transport-service layer network may
be point-to-point, point-to-multipoint or multipoint-to-multipoint, be point-to-point, point-to-multipoint, or multipoint-to-multipoint,
the transport path layer network only provides point-to-point or the transport-path layer network only provides point-to-point or
point-to-multipoint transport paths which are used to carry point-to-multipoint transport paths, which are used to carry
aggregates of transport service layer network traffic. aggregates of transport service layer network traffic.
1.3. Layer network overview 1.4. Layer Network Overview
A layer network provides its clients with a transport service and the A layer network provides its clients with a transport service and the
operation of the layer network is independent of whatever client operation of the layer network is independent of whatever client
happens to use the layer network. Information that passes between happens to use the layer network. Information that passes between
any client to the layer network is common to all clients and is the any client to the layer network is common to all clients and is the
minimum needed to be consistent with the definition of the transport minimum needed to be consistent with the definition of the transport
service offered. The client layer network can be connectionless, service offered. The client layer network can be connectionless,
connection oriented packet switched, or circuit switched. The connection-oriented packet switched, or circuit switched. The
transport service transfers a payload (individual packet payload for transport service transfers a payload such that the client can
connectionless networks, a sequence of packets payloads in the case populate the payload without affecting any operation within the
of connection oriented packet switched networks, and a deterministic serving layer network. Here, payload means:
schedule of payloads in the case of circuit switched networks) such
that the client can populate the payload without affecting any RFC 5654 MPLS-TP Requirements September 2009
operation within the serving layer network.
o an individual packet payload (for connectionless networks),
o a sequence of packet payloads (for connection-oriented packet-
switched networks), or
o a deterministic schedule of payloads (for circuit-switched
networks).
The operations within a layer network that are independent of its The operations within a layer network that are independent of its
clients include the control of forwarding, the control of resource clients include the control of forwarding, the control of resource
reservation, the control of traffic demerging, and the OAM and reservation, the control of traffic de-merging, and the OAM and
recovery of the transport service. All of these operations are recovery of the transport service. All of these operations are
internal to a layer network. By definition, a layer network does not internal to a layer network. By definition, a layer network does not
rely on any client information to perform these operations and rely on any client information to perform these operations, and
therefore all information required to perform these operations is therefore all information required to perform these operations is
independent of whatever client is using the layer network. independent of whatever client is using the layer network.
A layer network will have consistent features in order to support the A layer network will have consistent features in order to support the
control of forwarding, resource reservation, OAM and recovery. For control of forwarding, resource reservation, OAM, and recovery. For
example, a layer network will have a common addressing scheme for the example, a layer network will have a common addressing scheme for the
end points of the transport service and a common set of transport end points of the transport service and a common set of transport
descriptors for the transport service. However, a client may use a descriptors for the transport service. However, a client may use a
different addressing scheme or different traffic descriptors different addressing scheme or different traffic descriptors
(consistent with performance inheritance). (consistent with performance inheritance).
It is sometimes useful to independently monitor a smaller domain It is sometimes useful to independently monitor a smaller domain
within a layer network (or the transport services that traverse this within a layer network (or the transport services that traverse this
smaller domain) but the control of forwarding or the control of smaller domain), but the control of forwarding or the control of
resource reservation involved retain their common elements. These resource reservation involved retain their common elements. These
smaller monitored domains are sublayers. smaller monitored domains are sublayers.
It is sometimes useful to independently control forwarding in a It is sometimes useful to independently control forwarding in a
smaller domain within a layer network but the control of resource smaller domain within a layer network, but the control of resource
reservation and OAM retain their common elements. These smaller reservation and OAM retain their common elements. These smaller
domains are partitions of the layer network. domains are partitions of the layer network.
2. MPLS-TP Requirements 2. MPLS-TP Requirements
The MPLS-TP requirements set out in this section are for the behavior The MPLS-TP requirements set out in this section are for the behavior
of the protocol mechanisms and procedures that constitute building of the protocol mechanisms and procedures that constitute building
blocks out of which the MPLS transport profile is constructed. That blocks out of which the MPLS Transport Profile is constructed. That
is, the requirements indicate what features are to be available in is, the requirements indicate what features are to be available in
the MPLS toolkit for use by MPLS-TP. the MPLS toolkit for use by MPLS-TP.
2.1. General requirements RFC 5654 MPLS-TP Requirements September 2009
2.1. General Requirements
1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as 1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as
defined by the IETF. When MPLS offers multiple options in this defined by the IETF. When MPLS offers multiple options in this
respect, MPLS-TP SHOULD select the minimum sub-set (necessary and respect, MPLS-TP SHOULD select the minimum subset (necessary and
sufficient subset) applicable to a transport network application. sufficient subset) applicable to a transport network application.
2 The MPLS-TP design SHOULD as far as reasonably possible re-use 2 The MPLS-TP design SHOULD as far as reasonably possible reuse
existing MPLS standards. existing MPLS standards.
3 Mechanisms and capabilities MUST be able to interoperate with 3 Mechanisms and capabilities MUST be able to interoperate with
existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and
data planes where appropriate. data planes where appropriate.
A. Data plane interoperability MUST NOT require a gateway A. Data-plane interoperability MUST NOT require a gateway
function. function.
4 MPLS-TP and its interfaces, both internal and external, MUST be 4 MPLS-TP and its interfaces, both internal and external, MUST be
sufficiently well-defined that interworking equipment supplied by sufficiently well-defined that interworking equipment supplied by
multiple vendors will be possible both within a single domain, multiple vendors will be possible both within a single domain and
and between domains. between domains.
5 MPLS-TP MUST be a connection-oriented packet switching technology 5 MPLS-TP MUST be a connection-oriented packet-switching technology
with traffic engineering capabilities that allow deterministic with traffic-engineering capabilities that allow deterministic
control of the use of network resources. control of the use of network resources.
6 MPLS-TP MUST support traffic engineered point to point (P2P) and 6 MPLS-TP MUST support traffic-engineered point-to-point (P2P) and
point to multipoint (P2MP) transport paths. point-to-multipoint (P2MP) transport paths.
7 MPLS-TP MUST support unidirectional, co-routed bidirectional and 7 MPLS-TP MUST support unidirectional, co-routed bidirectional, and
associated bidirectional point-to-point transport paths. associated bidirectional point-to-point transport paths.
8 MPLS-TP MUST support unidirectional point-to-multipoint transport 8 MPLS-TP MUST support unidirectional point-to-multipoint transport
paths. paths.
9 The end points of a co-routed bidirectional transport path MUST 9 The end points of a co-routed bidirectional transport path MUST
be aware of the pairing relationship of the forward and reverse be aware of the pairing relationship of the forward and reverse
paths used to support the bidirectional service. paths used to support the bidirectional service.
10 All nodes on the path of a co-routed bidirectional transport path 10 All nodes on the path of a co-routed bidirectional transport path
in the same (sub-)layer as the path MUST be aware of the pairing in the same (sub)layer as the path MUST be aware of the pairing
relationship of the forward and the backward directions of the relationship of the forward and the backward directions of the
transport path. transport path.
11 The end points of an associated bidirectional transport path MUST 11 The end points of an associated bidirectional transport path MUST
be aware of the pairing relationship of the forward and reverse be aware of the pairing relationship of the forward and reverse
paths used to support the bidirectional service. paths used to support the bidirectional service.
RFC 5654 MPLS-TP Requirements September 2009
12 Nodes on the path of an associated bidirectional transport path 12 Nodes on the path of an associated bidirectional transport path
where both the forward and backward directions transit the same where both the forward and backward directions transit the same
node in the same (sub-)layer as the path SHOULD be aware of the node in the same (sub)layer as the path SHOULD be aware of the
pairing relationship of the forward and the backward directions pairing relationship of the forward and the backward directions
of the transport path. of the transport path.
13 MPLS-TP MUST support bidirectional transport paths with symmetric 13 MPLS-TP MUST support bidirectional transport paths with symmetric
bandwidth requirements, i.e. the amount of reserved bandwidth is bandwidth requirements, i.e., the amount of reserved bandwidth is
the same between the forward and backward directions. the same between the forward and backward directions.
14 MPLS-TP MUST support bidirectional transport paths with 14 MPLS-TP MUST support bidirectional transport paths with
asymmetric bandwidth requirements, i.e. the amount of reserved asymmetric bandwidth requirements, i.e., the amount of reserved
bandwidth differs between the forward and backward directions. bandwidth differs between the forward and backward directions.
15 MPLS-TP MUST support the logical separation of the control and 15 MPLS-TP MUST support the logical separation of the control and
management planes from the data plane. management planes from the data plane.
16 MPLS-TP MUST support the physical separation of the control and 16 MPLS-TP MUST support the physical separation of the control and
management planes from the data plane. That is, it must be management planes from the data plane. That is, it must be
possible to operate the control and management planes out-of-band possible to operate the control and management planes out-of-
and no assumptions should be made about the state of the data band, and no assumptions should be made about the state of the
plane channels from information about the control or management data-plane channels from information about the control or
plane channels when they are running out-of-band. management-plane channels when they are running out-of-band.
17 MPLS-TP MUST support static provisioning of transport paths via 17 MPLS-TP MUST support static provisioning of transport paths via
the management plane. the management plane.
18 A solution MUST be defined to support dynamic provisioning and 18 A solution MUST be defined to support dynamic provisioning and
restoration of MPLS-TP transport paths via a control plane. restoration of MPLS-TP transport paths via a control plane.
19 Static provisioning MUST NOT depend on the presence of any 19 Static provisioning MUST NOT depend on the presence of any
element of a control plane. element of a control plane.
20 MPLS-TP MUST support the co-existence of statically and 20 MPLS-TP MUST support the coexistence of statically and
dynamically provisioned/managed MPLS-TP transport paths within dynamically provisioned/managed MPLS-TP transport paths within
the same layer network or domain. the same layer network or domain.
21 Mechanisms in an MPLS-TP layer network that satisfy functional 21 Mechanisms in an MPLS-TP layer network that satisfy functional
requirements that are common to general transport layer networks requirements that are common to general transport-layer networks
(i.e., independent of technology) SHOULD be operable in a way (i.e., independent of technology) SHOULD be operable in a way
that is similar to the way the equivalent mechanisms are operated that is similar to the way the equivalent mechanisms are operated
in other transport layer technologies. in other transport-layer technologies.
22 MPLS-TP MUST support the capability for network operation via the 22 MPLS-TP MUST support the capability for network operation via the
management plane (without the use of any control plane management plane (without the use of any control-plane
protocols). This includes the configuration and control of OAM protocols). This includes the configuration and control of OAM
and recovery functions. and recovery functions.
RFC 5654 MPLS-TP Requirements September 2009
23 The MPLS-TP data plane MUST be capable of 23 The MPLS-TP data plane MUST be capable of
A. forwarding data independent of the control or management A. forwarding data independent of the control or management
plane used to configure and operate the MPLS-TP layer plane used to configure and operate the MPLS-TP layer
network. network.
B. taking recovery actions independent of the control or B. taking recovery actions independent of the control or
management plane used to configure the MPLS-TP layer network. management plane used to configure the MPLS-TP layer network.
C. operating normally (i.e. forwarding, OAM and protection MUST C. operating normally (i.e., forwarding, OAM, and protection
continue to operate) if the management plane or control plane MUST continue to operate) if the management plane or control
that configured the transport paths fails. plane that configured the transport paths fails.
24 MPLS-TP MUST support mechanisms to avoid or minimize traffic 24 MPLS-TP MUST support mechanisms to avoid or minimize traffic
impact (e.g. packet delay, reordering and loss) during network impact (e.g., packet delay, reordering, and loss) during network
reconfiguration. reconfiguration.
25 MPLS-TP MUST support transport paths through multiple homogeneous 25 MPLS-TP MUST support transport paths through multiple homogeneous
domains. domains.
26 MPLS-TP SHOULD support transport paths through multiple non- 26 MPLS-TP SHOULD support transport paths through multiple non-
homogeneous domains. homogeneous domains.
27 MPLS-TP MUST NOT dictate the deployment of any particular network 27 MPLS-TP MUST NOT dictate the deployment of any particular network
topology either physical or logical, however: topology either physical or logical, however:
A. It MUST be possible to deploy MPLS-TP in rings. A. It MUST be possible to deploy MPLS-TP in rings.
B. It MUST be possible to deploy MPLS-TP in arbitrarily B. It MUST be possible to deploy MPLS-TP in arbitrarily
interconnected rings with one or two points of interconnected rings with one or two points of
interconnection. interconnection.
C. MPLS-TP MUST support rings of at least 16 nodes in order to C. MPLS-TP MUST support rings of at least 16 nodes in order to
support the upgrade of existing TDM rings to MPLS-TP. support the upgrade of existing Time-Division Multiplexing
MPLS-TP SHOULD support rings with more than 16 nodes. (TDM) rings to MPLS-TP. MPLS-TP SHOULD support rings with
more than 16 nodes.
28 MPLS-TP MUST be able to scale at least as well as existing 28 MPLS-TP MUST be able to scale at least as well as existing
transport technologies with growing and increasingly complex transport technologies with growing and increasingly complex
network topologies as well as with increasing bandwidth demands, network topologies as well as with increasing amounts of
number of customers, and number of services. customers, services, and bandwidth demand.
29 MPLS-TP SHOULD support mechanisms to safeguard against the 29 MPLS-TP SHOULD support mechanisms to safeguard against the
provisioning of transport paths which contain forwarding loops. provisioning of transport paths which contain forwarding loops.
2.2. Layering requirements RFC 5654 MPLS-TP Requirements September 2009
2.2. Layering Requirements
30 A generic and extensible solution MUST be provided to support the 30 A generic and extensible solution MUST be provided to support the
transport of one or more client layer networks (e.g. MPLS-TP, transport of one or more client layer networks (e.g., MPLS-TP,
IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network. IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
31 A generic and extensible solution MUST be provided to support the 31 A generic and extensible solution MUST be provided to support the
transport of MPLS-TP transport paths over one or more server transport of MPLS-TP transport paths over one or more server
layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).
Requirements for bandwidth management within a server layer Requirements for bandwidth management within a server layer
network are outside the scope of this document. network are outside the scope of this document.
32 In an environment where an MPLS-TP layer network is supporting a 32 In an environment where an MPLS-TP layer network is supporting a
client layer network, and the MPLS-TP layer network is supported client layer network, and the MPLS-TP layer network is supported
by a server layer network then operation of the MPLS-TP layer by a server layer network, then operation of the MPLS-TP layer
network MUST be possible without any dependencies on the server network MUST be possible without any dependencies on the server
or client layer network. or client layer network.
A. The server layer MUST guarantee that the traffic loading A. The server layer MUST guarantee that the traffic-loading
imposed by other clients does not cause the transport service imposed by other clients does not cause the transport service
provided to the MPLS-TP layer to fall below the agreed level. provided to the MPLS-TP layer to fall below the agreed level.
Mechanisms to achieve this are outside the scope of these Mechanisms to achieve this are outside the scope of these
requirements. requirements.
B. It MUST be possible to isolate the control and management B. It MUST be possible to isolate the control and management
planes of the MPLS-TP layer network from the control and planes of the MPLS-TP layer network from the control and
management planes of the client and server layer networks. management planes of the client and server layer networks.
33 A solution MUST be provided to support the transport of a client 33 A solution MUST be provided to support the transport of a client
MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer
network. network.
A. The level of co-ordination required between the client and A. The level of coordination required between the client and
server MPLS(-TP) layer networks MUST be minimized (preferably server MPLS(-TP) layer networks MUST be minimized (preferably
no co-ordination will be required). no coordination will be required).
B. The MPLS(-TP) server layer network MUST be capable of B. The MPLS(-TP) server layer network MUST be capable of
transporting the complete set of packets generated by the transporting the complete set of packets generated by the
client MPLS(-TP) layer network, which may contain packets client MPLS(-TP) layer network, which may contain packets
that are not MPLS packets (e.g. IP or CNLS packets used by that are not MPLS packets (e.g., IP or Connectionless Network
the control/management plane of the client MPLS(-TP) layer Protocol (CNLP) packets used by the control/management plane
network). of the client MPLS(-TP) layer network).
34 It MUST be possible to operate the layers of a multi-layer 34 It MUST be possible to operate the layers of a multi-layer
network that includes an MPLS-TP layer autonomously. network that includes an MPLS-TP layer autonomously.
RFC 5654 MPLS-TP Requirements September 2009
The above are not only technology requirements, but also operational The above are not only technology requirements, but also operational
requirements. Different administrative groups may be responsible for requirements. Different administrative groups may be responsible for
the same layer network or different layer networks. the same layer network or different layer networks.
35 It MUST be possible to hide MPLS-TP layer network addressing and 35 It MUST be possible to hide MPLS-TP layer network addressing and
other information (e.g. topology) from client layer networks. other information (e.g., topology) from client layer networks.
However, it SHOULD be possible, at the option of the operator, to However, it SHOULD be possible, at the option of the operator, to
leak a limited amount of summarized information (such as SRLGs or leak a limited amount of summarized information (such as SRLGs or
reachability) between layers. reachability) between layers.
2.3. Data plane requirements 2.3. Data Plane Requirements
36 It MUST be possible to operate and configure the MPLS-TP data 36 It MUST be possible to operate and configure the MPLS-TP data
plane without any IP forwarding capability in the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data
plane. i.e. the data plane only operates on the MPLS label. plane. That is, the data plane only operates on the MPLS label.
37 It MUST be possible for the end points of an MPLS-TP transport 37 It MUST be possible for the end points of an MPLS-TP transport
path that is carrying an aggregate of client transport paths to path that is carrying an aggregate of client transport paths to
be able to decompose the aggregate transport path into its be able to decompose the aggregate transport path into its
component client transport paths. component client transport paths.
38 A transport path on a link MUST be uniquely identifiable by a 38 A transport path on a link MUST be uniquely identifiable by a
single label on that link. single label on that link.
39 A transport path's source MUST be identifiable at its destination 39 A transport path's source MUST be identifiable at its destination
within its layer network. within its layer network.
40 MPLS-TP MUST be capable of using P2MP server (sub-)layer 40 MPLS-TP MUST be capable of using P2MP server (sub)layer
capabilities as well as P2P server (sub-)layer capabilities when capabilities as well as P2P server (sub)layer capabilities when
supporting P2MP MPLS-TP transport paths. supporting P2MP MPLS-TP transport paths.
41 MPLS-TP MUST be extensible in order to accommodate new types of 41 MPLS-TP MUST be extensible in order to accommodate new types of
client layer networks and services. client layer networks and services.
42 MPLS-TP SHOULD support mechanisms to enable the reserved 42 MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth associated with a transport path to be increased bandwidth associated with a transport path to be increased
without impacting the existing traffic on that transport path without impacting the existing traffic on that transport path
provided enough resources are available. provided enough resources are available.
43 MPLS-TP SHOULD support mechanisms to enable the reserved 43 MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth of a transport path to be decreased without impacting bandwidth of a transport path to be decreased without impacting
the existing traffic on that transport path, provided that the the existing traffic on that transport path, provided that the
level of existing traffic is smaller than the reserved bandwidth level of existing traffic is smaller than the reserved bandwidth
following the decrease. following the decrease.
44 MPLS-TP MUST support mechanisms which ensure the integrity of the RFC 5654 MPLS-TP Requirements September 2009
44 MPLS-TP MUST support mechanisms that ensure the integrity of the
transported customer's service traffic as required by its transported customer's service traffic as required by its
associated SLA. Loss of integrity may be defined as packet associated SLA. Loss of integrity may be defined as packet
corruption, re-ordering or loss during normal network conditions. corruption, reordering, or loss during normal network conditions.
45 MPLS-TP MUST support mechanisms to detect when loss of integrity 45 MPLS-TP MUST support mechanisms to detect when loss of integrity
of the transported customer's service traffic has occurred. of the transported customer's service traffic has occurred.
46 MPLS-TP MUST support an unambiguous and reliable means of 46 MPLS-TP MUST support an unambiguous and reliable means of
distinguishing users' (client) packets from MPLS-TP control distinguishing users' (client) packets from MPLS-TP control
packets (e.g. control plane, management plane, OAM and protection packets (e.g., control plane, management plane, OAM, and
switching packets). protection-switching packets).
2.4. Control plane requirements 2.4. Control Plane Requirements
This section defines the requirements that apply to an MPLS-TP This section defines the requirements that apply to an MPLS-TP
control plane. Note that it MUST be possible to operate an MPLS-TP control plane. Note that it MUST be possible to operate an MPLS-TP
network without using a control plane. network without using a control plane.
The ITU-T has defined an architecture for Automatically Switched The ITU-T has defined an architecture for Automatically Switched
Optical Networks (ASON) in G.8080 [ITU.G8080.2006] and G.8080 Amd1 Optical Networks (ASONs) in G.8080 [ITU.G8080.2006] and G.8080
[ITU.G8080.2008]. The control plane for MPLS-TP MUST fit within the Amendment 1 [ITU.G8080.2008]. The control plane for MPLS-TP MUST fit
ASON architecture. within the ASON architecture.
An interpretation of the ASON signaling and routing requirements in An interpretation of the ASON signaling and routing requirements in
the context of GMPLS can be found in [RFC4139] and [RFC4258]. the context of GMPLS can be found in [RFC4139] and [RFC4258].
Additionally: Additionally:
47 The MPLS-TP control plane MUST support control plane topology and 47 The MPLS-TP control plane MUST support control-plane topology and
data plane topology independence. As a consequence a failure of data-plane topology independence. As a consequence, a failure of
the control plane does not imply that there has also been a the control plane does not imply that there has also been a
failure of the data plane. failure of the data plane.
48 The MPLS-TP control plane MUST be able to be operated independent 48 The MPLS-TP control plane MUST be able to be operated
of any particular client or server layer control plane. independently of any particular client- or server-layer control
plane.
49 MPLS-TP SHOULD define a solution to support an integrated control 49 MPLS-TP SHOULD define a solution to support an integrated control
plane encompassing MPLS-TP together with its server and client plane encompassing MPLS-TP together with its server and client
layer networks when these layer networks belong to the same layer networks when these layer networks belong to the same
administrative domain. administrative domain.
50 The MPLS-TP control plane MUST support establishing all the 50 The MPLS-TP control plane MUST support establishing all the
connectivity patterns defined for the MPLS-TP data plane (i.e., connectivity patterns defined for the MPLS-TP data plane (i.e.,
unidirectional P2P, associated bidirectional P2P, co-routed unidirectional P2P, associated bidirectional P2P, co-routed
bidirectional P2P, unidirectional P2MP) including configuration bidirectional P2P, unidirectional P2MP) including configuration
of protection functions and any associated maintenance functions. of protection functions and any associated maintenance functions.
RFC 5654 MPLS-TP Requirements September 2009
51 The MPLS-TP control plane MUST support the configuration and 51 The MPLS-TP control plane MUST support the configuration and
modification of OAM maintenance points as well as the activation/ modification of OAM maintenance points as well as the activation/
deactivation of OAM when the transport path or transport service deactivation of OAM when the transport path or transport service
is established or modified. is established or modified.
52 An MPLS-TP control plane MUST support operation of the recovery 52 An MPLS-TP control plane MUST support operation of the recovery
functions described in Section 2.8. functions described in Section 2.8.
53 An MPLS-TP control plane MUST scale gracefully to support a large 53 An MPLS-TP control plane MUST scale gracefully to support a large
number of transport paths, nodes and links. number of transport paths, nodes, and links.
54 If a control plane is used for MPLS-TP, following a control plane 54 If a control plane is used for MPLS-TP, following a control-plane
failure, the control plane MUST be capable of restarting and failure, the control plane MUST be capable of restarting and
relearning its previous state without impacting forwarding. relearning its previous state without impacting forwarding.
55 An MPLS-TP control plane MUST provide a mechanism for dynamic 55 An MPLS-TP control plane MUST provide a mechanism for dynamic
ownership transfer of the control of MPLS-TP transport paths from ownership transfer of the control of MPLS-TP transport paths from
the management plane to the control plane and vice versa. The the management plane to the control plane and vice versa. The
number of reconfigurations required in the data plane MUST be number of reconfigurations required in the data plane MUST be
minimized (preferably no data plane reconfiguration will be minimized (preferably no data-plane reconfiguration will be
required). required).
2.5. Recovery requirements 2.5. Recovery Requirements
Network survivability plays a critical role in the delivery of Network survivability plays a critical role in the delivery of
reliable services. Network availability is a significant contributor reliable services. Network availability is a significant contributor
to revenue and profit. Service guarantees in the form of SLAs to revenue and profit. Service guarantees in the form of SLAs
require a resilient network that rapidly detects facility or node require a resilient network that rapidly detects facility or node
failures and restores network operation in accordance with the terms failures and restores network operation in accordance with the terms
of the SLA. of the SLA.
56 MPLS-TP MUST provide protection and restoration mechanisms. 56 MPLS-TP MUST provide protection and restoration mechanisms.
skipping to change at page 20, line 19 skipping to change at page 19, line 51
similar as possible) to those already used in existing similar as possible) to those already used in existing
transport networks to simplify implementation and operations. transport networks to simplify implementation and operations.
However, this MUST NOT override any other requirement. However, this MUST NOT override any other requirement.
B. Recovery techniques used for P2P and P2MP SHOULD be identical B. Recovery techniques used for P2P and P2MP SHOULD be identical
to simplify implementation and operation. However, this MUST to simplify implementation and operation. However, this MUST
NOT override any other requirement. NOT override any other requirement.
57 MPLS-TP recovery mechanisms MUST be applicable at various levels 57 MPLS-TP recovery mechanisms MUST be applicable at various levels
throughout the network including support for link, transport throughout the network including support for link, transport
path, segment, concatenated segment and end to end recovery. path, segment, concatenated segment, and end-to-end recovery.
58 MPLS-TP recovery paths MUST meet the SLA protection objectives of 58 MPLS-TP recovery paths MUST meet the SLA protection objectives of
the service. the service.
RFC 5654 MPLS-TP Requirements September 2009
A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery
times from the moment of fault detection in networks with times from the moment of fault detection in networks with
spans less than 1200 km. spans less than 1200 km.
B. For protection it MUST be possible to require protection of B. For protection it MUST be possible to require protection of
100% of the traffic on the protected path. 100% of the traffic on the protected path.
C. Recovery MUST meet SLA requirements over multiple domains. C. Recovery MUST meet SLA requirements over multiple domains.
59 Recovery objectives SHOULD be configurable per transport path. 59 Recovery objectives SHOULD be configurable per transport path.
skipping to change at page 20, line 46 skipping to change at page 20, line 29
61 The recovery mechanisms MUST support the means to operate in 61 The recovery mechanisms MUST support the means to operate in
synergy with (including coordination of timing) the recovery synergy with (including coordination of timing) the recovery
mechanisms present in any client or server transport networks mechanisms present in any client or server transport networks
(for example, Ethernet, SDH, OTN, WDM) to avoid race conditions (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions
between the layers. between the layers.
62 MPLS-TP recovery and reversion mechanisms MUST prevent frequent 62 MPLS-TP recovery and reversion mechanisms MUST prevent frequent
operation of recovery in the event of an intermittent defect. operation of recovery in the event of an intermittent defect.
2.5.1. Data plane behavior requirements 2.5.1. Data-Plane Behavior Requirements
General protection and survivability requirements are expressed in General protection and survivability requirements are expressed in
terms of the behavior in the data plane. terms of the behavior in the data plane.
2.5.1.1. Protection 2.5.1.1. Protection
Note: Only nodes that are aware of the pairing relationship between Note: Only nodes that are aware of the pairing relationship between
the forward and backward directions of an associated bidirectional the forward and backward directions of an associated bidirectional
transport path can be used as end points to protect all or part of transport path can be used as end points to protect all or part of
that transport path. that transport path.
63 It MUST be possible to provide protection for the MPLS-TP data 63 It MUST be possible to provide protection for the MPLS-TP data
plane without any IP forwarding capability in the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data
plane. i.e. the data plane only operates on the MPLS label. plane. That is, the data plane only operates on the MPLS label.
64 MPLS-TP protection mechanisms MUST support revertive and non- 64 MPLS-TP protection mechanisms MUST support revertive and non-
revertive behavior. revertive behavior.
65 MPLS-TP MUST support 1+1 protection. 65 MPLS-TP MUST support 1+1 protection.
A. Bidirectional 1+1 protection for P2P connectivity MUST be A. Bidirectional 1+1 protection for P2P connectivity MUST be
supported. supported.
B. Unidirectional 1+1 protection for P2P connectivity MUST be B. Unidirectional 1+1 protection for P2P connectivity MUST be
supported. supported.
RFC 5654 MPLS-TP Requirements September 2009
C. Unidirectional 1+1 protection for P2MP connectivity MUST be C. Unidirectional 1+1 protection for P2MP connectivity MUST be
supported. supported.
66 MPLS-TP MUST support the ability to share protection resources 66 MPLS-TP MUST support the ability to share protection resources
amongst a number of transport paths. amongst a number of transport paths.
67 MPLS-TP MUST support 1:n protection (including 1:1 protection). 67 MPLS-TP MUST support 1:n protection (including 1:1 protection).
A. Bidirectional 1:n protection for P2P connectivity MUST be A. Bidirectional 1:n protection for P2P connectivity MUST be
supported, and SHOULD be the default behavior for 1:n supported and SHOULD be the default behavior for 1:n
protection. protection.
B. Unidirectional 1:n protection for P2MP connectivity MUST be B. Unidirectional 1:n protection for P2MP connectivity MUST be
supported. supported.
C. Unidirectional 1:n protection for P2P connectivity is not C. Unidirectional 1:n protection for P2P connectivity is not
required and MAY be omitted from the MPLS-TP specifications. required and MAY be omitted from the MPLS-TP specifications.
D. The action of protection switching MUST NOT cause the user D. The action of protection-switching MUST NOT cause the user
data to enter an uncontrolled loop. The protection switching data to enter an uncontrolled loop. The protection-switching
system MAY cause traffic to pass over a given link more than system MAY cause traffic to pass over a given link more than
once, but it must do so in a controlled way such that once, but it must do so in a controlled way such that
uncontrolled loops do not form. uncontrolled loops do not form.
Note: Support for extra traffic (as defined in [RFC4427]) is not Note: Support for extra traffic (as defined in [RFC4427]) is not
required in MPLS-TP and MAY be omitted from the MPLS-TP required in MPLS-TP and MAY be omitted from the MPLS-TP
specifications. specifications.
2.5.1.2. Sharing of protection resources 2.5.1.2. Sharing of Protection Resources
68 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh recovery. 68 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh recovery.
69 MPLS-TP MUST support sharing of protection resources such that 69 MPLS-TP MUST support sharing of protection resources such that
protection paths that are known not to be required concurrently protection paths that are known not to be required concurrently
can share the same resources. can share the same resources.
2.5.2. Restoration 2.5.2. Restoration
70 The restoration transport path MUST be able to share resources 70 The restoration transport path MUST be able to share resources
with the transport path being replaced (sometimes known as soft with the transport path being replaced (sometimes known as soft
rerouting). rerouting).
71 Restoration priority MUST be supported so that an implementation 71 Restoration priority MUST be supported so that an implementation
can determine the order in which transport paths should be can determine the order in which transport paths should be
restored (to minimize service restoration time as well as to gain restored (to minimize service restoration time as well as to gain
access to available spare capacity on the best paths). access to available spare capacity on the best paths).
RFC 5654 MPLS-TP Requirements September 2009
72 Preemption priority MUST be supported to allow restoration to 72 Preemption priority MUST be supported to allow restoration to
displace other transport paths in the event of resource displace other transport paths in the event of resource
constraint. constraint.
73 MPLS-TP restoration mechanisms MUST support revertive and non- 73 MPLS-TP restoration mechanisms MUST support revertive and non-
revertive behavior. revertive behavior.
2.5.3. Triggers for protection, restoration, and reversion 2.5.3. Triggers for Protection, Restoration, and Reversion
Recovery actions may be triggered from different places as follows: Recovery actions may be triggered from different places as follows:
74 MPLS-TP MUST support fault indication triggers from lower layers. 74 MPLS-TP MUST support fault indication triggers from lower layers.
This includes faults detected and reported by lower layer This includes faults detected and reported by lower-layer
protocols, and faults reported directly by the physical medium protocols, and faults reported directly by the physical medium
(for example, loss of light). (for example, loss of light).
75 MPLS-TP MUST support OAM-based triggers. 75 MPLS-TP MUST support OAM-based triggers.
76 MPLS-TP MUST support management plane triggers (e.g., forced 76 MPLS-TP MUST support management-plane triggers (e.g., forced
switch, etc.). switch, etc.).
77 There MUST be a mechanism to allow administrative recovery 77 There MUST be a mechanism to distinguish administrative recovery
actions to be distinguished from recovery actions initiated by actions from recovery actions initiated by other triggers.
other triggers.
78 Where a control plane is present, MPLS-TP SHOULD support control 78 Where a control plane is present, MPLS-TP SHOULD support control-
plane restoration triggers. plane restoration triggers.
79 MPLS-TP protection mechanisms MUST support priority logic to 79 MPLS-TP protection mechanisms MUST support priority logic to
negotiate and accommodate coexisting requests (i.e., multiple negotiate and accommodate coexisting requests (i.e., multiple
requests) for protection switching (e.g., administrative requests requests) for protection-switching (e.g., administrative requests
and requests due to link/node failures). and requests due to link/node failures).
2.5.4. Management plane operation of protection and restoration 2.5.4. Management-Plane Operation of Protection and Restoration
All functions described here are for control by the operator. All functions described here are for control by the operator.
80 It MUST be possible to configure protection paths and protection- 80 It MUST be possible to configure protection paths and protection-
to-working path relationships (sometimes known as protection to-working path relationships (sometimes known as protection
groups). groups).
81 There MUST be support for pre-calculation of recovery paths. 81 There MUST be support for pre-calculation of recovery paths.
82 There MUST be support for pre-provisioning of recovery paths. 82 There MUST be support for pre-provisioning of recovery paths.
RFC 5654 MPLS-TP Requirements September 2009
83 The external controls as defined in [RFC4427] MUST be supported. 83 The external controls as defined in [RFC4427] MUST be supported.
A. External controls overruled by higher priority requests A. External controls overruled by higher priority requests
(e.g., administrative requests and requests due to link/node (e.g., administrative requests and requests due to link/node
failures) or unable to be signaled to the remote end (e.g. failures) or unable to be signaled to the remote end (e.g.,
because of a protection state coordination fail) MUST be due to a coordination failure of the protection state) MUST
dropped. be dropped.
84 It MUST be possible to test and validate any protection/ 84 It MUST be possible to test and validate any protection/
restoration mechanisms and protocols: restoration mechanisms and protocols:
A. Including the integrity of the protection/recovery transport A. Including the integrity of the protection/recovery transport
path. path.
B. Without triggering the actual protection/restoration. B. Without triggering the actual protection/restoration.
C. While the working path is in service. C. While the working path is in service.
skipping to change at page 24, line 11 skipping to change at page 23, line 39
86 When preemption is supported for restoration purposes, it MUST be 86 When preemption is supported for restoration purposes, it MUST be
possible for the operator to configure it. possible for the operator to configure it.
87 The management plane MUST provide indications of protection 87 The management plane MUST provide indications of protection
events and triggers. events and triggers.
88 The management plane MUST allow the current protection status of 88 The management plane MUST allow the current protection status of
all transport paths to be determined. all transport paths to be determined.
2.5.5. Control plane and in-band OAM operation of recovery 2.5.5. Control Plane and In-Band OAM Operation of Recovery
89 The MPLS-TP control plane (which is not mandatory in an MPLS-TP 89 The MPLS-TP control plane (which is not mandatory in an MPLS-TP
implementation) MUST be capable of supporting: implementation) MUST be capable of supporting:
A. establishment and maintenance of all recovery entities and A. establishment and maintenance of all recovery entities and
functions functions
B. signaling of administrative control B. signaling of administrative control
C. protection state coordination (PSC). Since control plane C. protection state coordination (PSC). Since control plane
network topology is independent from the data plane network network topology is independent from the data plane network
topology, the PSC supported by the MPLS-TP control plane MAY topology, the PSC supported by the MPLS-TP control plane MAY
run on resources different than the data plane resources run on resources different than the data plane resources
handled within the recovery mechanism (e.g. backup). handled within the recovery mechanism (e.g., backup).
RFC 5654 MPLS-TP Requirements September 2009
90 In-band OAM MUST be capable of supporting: 90 In-band OAM MUST be capable of supporting:
A. signaling of administrative control A. signaling of administrative control
B. protection state coordination (PSC). Since in-band OAM tools B. protection state coordination (PSC). Since in-band OAM tools
share the data plane with the carried transport service, in share the data plane with the carried transport service, in
order to optimize the usage of network resources, the PSC order to optimize the usage of network resources, the PSC
supported by in-band OAM MUST run on protection resources. supported by in-band OAM MUST run on protection resources.
2.5.6. Topology-specific recovery mechanisms 2.5.6. Topology-Specific Recovery Mechanisms
91 MPLS-TP MAY support recovery mechanisms that are optimized for 91 MPLS-TP MAY support recovery mechanisms that are optimized for
specific network topologies. These mechanisms MUST be specific network topologies. These mechanisms MUST be
interoperable with the mechanisms defined for arbitrary topology interoperable with the mechanisms defined for arbitrary topology
(mesh) networks to enable protection of end-to-end transport (mesh) networks to enable protection of end-to-end transport
paths. paths.
2.5.6.1. Ring protection 2.5.6.1. Ring Protection
Several service providers have expressed a high level of interest in Several service providers have expressed a high level of interest in
operating MPLS-TP in ring topologies and require a high level of operating MPLS-TP in ring topologies and require a high level of
survivability function in these topologies. The requirements listed survivability function in these topologies. The requirements listed
below have been collected from these service providers and from the below have been collected from these service providers and from the
ITU-T. ITU-T.
The main objective in considering a specific topology (such as a The main objective in considering a specific topology (such as a
ring) is to determine whether it is possible to optimize any ring) is to determine whether it is possible to optimize any
mechanisms such that the performance of those mechanisms within the mechanisms such that the performance of those mechanisms within the
topology is significantly better than the performance of the generic topology is significantly better than the performance of the generic
mechanisms in the same topology. The benefits of such optimizations mechanisms in the same topology. The benefits of such optimizations
are traded against the costs of developing, implementing, deploying, are traded against the costs of developing, implementing, deploying,
and operating the additional optimized mechanisms noting that the and operating the additional optimized mechanisms noting that the
generic mechanisms MUST continue to be supported. generic mechanisms MUST continue to be supported.
Within the context of recovery in MPLS-TP networks, the optimization Within the context of recovery in MPLS-TP networks, the optimization
criteria considered in ring topologies are as follows: criteria considered in ring topologies are as follows:
a. Minimize the number of OAM entities that are needed to trigger a. Minimize the number of OAM entities that are needed to trigger
the recovery operation - less than are required by other recovery the recovery operation, such that it is less than is required by
mechanisms. other recovery mechanisms.
b. Minimize the number of elements of recovery in the ring - less b. Minimize the number of elements of recovery in the ring, such
than are required by other recovery mechanisms. that it is less than is required by other recovery mechanisms.
c. Minimize the number of labels required for the protection paths c. Minimize the number of labels required for the protection paths
across the ring - less than are required by other recovery across the ring, such that it is less than is required by other
mechanisms. recovery mechanisms.
d. Minimize the amount of control and management plane transactions RFC 5654 MPLS-TP Requirements September 2009
during a maintenance operation (e.g., ring upgrade) - less than
are required by other recovery mechanisms. d. Minimize the amount of control and management-plane transactions
during a maintenance operation (e.g., ring upgrade), such that it
is less than the amount required by other recovery mechanisms.
e. When a control plane is supported, minimize the impact on e. When a control plane is supported, minimize the impact on
signaling and routing information exchange during protection - signaling and routing information exchange during protection,
less than are required by other recovery mechanisms. such that it is less than the impact caused by other recovery
mechanisms.
It may be observed that the requirements in Section 2.5.6.1 are fully It may be observed that the requirements in Section 2.5.6.1 are fully
compatible with the generic requirements expressed in Section 2.5 compatible with the generic requirements expressed in Section 2.5
through Section 2.5.6 inclusive, and that no requirements that are through Section 2.5.6 inclusive, and that no requirements that are
specific to ring topologies have been identified. specific to ring topologies have been identified.
92 MPLS-TP MUST include recovery mechanisms that operate in any 92 MPLS-TP MUST include recovery mechanisms that operate in any
single ring supported in MPLS-TP, and continue to operate within single ring supported in MPLS-TP, and continue to operate within
the single rings even when the rings are interconnected. the single rings even when the rings are interconnected.
skipping to change at page 26, line 10 skipping to change at page 25, line 38
failure of the ring-interconnect nodes and links. failure of the ring-interconnect nodes and links.
94 MPLS-TP recovery in a ring MUST protect unidirectional and 94 MPLS-TP recovery in a ring MUST protect unidirectional and
bidirectional P2P transport paths. bidirectional P2P transport paths.
95 MPLS-TP recovery in a ring MUST protect unidirectional P2MP 95 MPLS-TP recovery in a ring MUST protect unidirectional P2MP
transport paths. transport paths.
96 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching 96 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching
time within 50 ms from the moment of fault detection in a time within 50 ms from the moment of fault detection in a
network with a 16 nodes ring with less than 1200 km of fiber. network with a 16-node ring with less than 1200 km of fiber.
97 The protection switching time in a ring MUST be independent of 97 The protection switching time in a ring MUST be independent of
the number of LSPs crossing the ring. the number of LSPs crossing the ring.
98 The configuration and operation of recovery mechanisms in a ring 98 The configuration and operation of recovery mechanisms in a ring
MUST scale well with: MUST scale well with:
A. the number of transport paths (must be better than linear A. the number of transport paths (MUST be better than linear
scaling) scaling)
B. the number of nodes on the ring (must be at least as good as B. the number of nodes on the ring (MUST be at least as good as
linear scaling) linear scaling)
C. the number of ring interconnects (must be at least as good C. the number of ring interconnects (MUST be at least as good
as linear scaling) as linear scaling)
RFC 5654 MPLS-TP Requirements September 2009
99 Recovery techniques used in a ring MUST NOT prevent the ring 99 Recovery techniques used in a ring MUST NOT prevent the ring
from being connected to a general MPLS-TP network in any from being connected to a general MPLS-TP network in any
arbitrary way, and MUST NOT prevent the operation of recovery arbitrary way, and MUST NOT prevent the operation of recovery
techniques in the rest of the network. techniques in the rest of the network.
100 Recovery techniques in a ring SHOULD be identical (or as similar 100 Recovery techniques in a ring SHOULD be identical (or as similar
as possible) to those in general transport networks to simplify as possible) to those in general transport networks to simplify
implementation and operations. However, this MUST NOT override implementation and operations. However, this MUST NOT override
any other requirement. any other requirement.
skipping to change at page 27, line 5 skipping to change at page 26, line 30
102 The default recovery scheme in a ring MUST be bidirectional 102 The default recovery scheme in a ring MUST be bidirectional
recovery in order to simplify the recovery operation. recovery in order to simplify the recovery operation.
103 The recovery mechanism in a ring MUST support revertive 103 The recovery mechanism in a ring MUST support revertive
switching, which MUST be the default behavior. This allows switching, which MUST be the default behavior. This allows
optimization of the use of the ring resources, and restores the optimization of the use of the ring resources, and restores the
preferred quality conditions for normal traffic (e.g., delay) preferred quality conditions for normal traffic (e.g., delay)
when the recovery mechanism is no longer needed. when the recovery mechanism is no longer needed.
104 The recovery mechanisms in a ring MUST support ways to allow 104 The recovery mechanisms in a ring MUST support ways to
administrative protection switching, to be distinguished from distinguish administrative protection-switching from protection-
protection switching initiated by other triggers. switching initiated by other triggers.
105 It MUST be possible to lockout (disable) protection mechanisms 105 It MUST be possible to lockout (disable) protection mechanisms
on selected links (spans) in a ring (depending on operator's on selected links (spans) in a ring (depending on the operator's
need). This may require lockout mechanisms to be applied to need). This may require lockout mechanisms to be applied to
intermediate nodes within a transport path. intermediate nodes within a transport path.
106 MPLS-TP recovery mechanisms in a ring: 106 MPLS-TP recovery mechanisms in a ring:
A. MUST include a mechanism to allow an implementation to A. MUST include a mechanism to allow an implementation to
handle (including the coordination of) coexisting requests handle and coordinate coexisting requests or triggers for
or triggers (i.e., multiple requests - not necessarily protection-switching based on priority. (For example, this
arriving simultaneously and located anywhere in the ring) includes multiple requests that are not necessarily arriving
for protection switching based on priority. Note that such simultaneously and that are located anywhere in the ring.)
coordination is the ring equivalent of the definition of Note that such coordination of the ring is equivalent to the
shared protection groups. use of shared protection groups.
B. SHOULD protect against multiple failures B. SHOULD protect against multiple failures
107 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a 107 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a
way to prevent frequent operation of recovery in the event of an way to prevent frequent operation of recovery in the event of an
intermittent defect. intermittent defect.
RFC 5654 MPLS-TP Requirements September 2009
108 MPLS-TP MUST support the sharing of protection bandwidth in a 108 MPLS-TP MUST support the sharing of protection bandwidth in a
ring by allowing best effort traffic. ring by allowing best-effort traffic.
109 MPLS-TP MUST support sharing of ring protection resources such 109 MPLS-TP MUST support sharing of ring protection resources such
that protection paths that are known not to be required that protection paths that are known not to be required
concurrently can share the same resources. concurrently can share the same resources.
2.6. QoS requirements 2.6. QoS Requirements
Carriers require advanced traffic management capabilities to enforce Carriers require advanced traffic-management capabilities to enforce
and guarantee the QoS parameters of customers' SLAs. and guarantee the QoS parameters of customers' SLAs.
Quality of service mechanisms are REQUIRED in an MPLS-TP network to Quality-of-service mechanisms are REQUIRED in an MPLS-TP network to
ensure: ensure:
110 Support for differentiated services and different traffic types 110 Support for differentiated services and different traffic types
with traffic class separation associated with different traffic. with traffic class separation associated with different traffic.
111 Enabling the provisioning and the guarantee of Service Level 111 Enabling the provisioning and the guarantee of Service Level
Specifications (SLS), with support for hard and relative end-to- Specifications (SLSs), with support for hard and relative end-
end bandwidth guaranteed. to-end bandwidth guaranteed.
112 Support of services, which are sensitive to jitter and delay. 112 Support of services, which are sensitive to jitter and delay.
113 Guarantee of fair access, within a particular class, to shared 113 Guarantee of fair access, within a particular class, to shared
resources. resources.
114 Guaranteed resources for in-band control and management plane 114 Guaranteed resources for in-band control and management-plane
traffic regardless of the amount of data plane traffic. traffic, regardless of the amount of data-plane traffic.
115 Carriers are provided with the capability to efficiently support 115 Carriers are provided with the capability to efficiently support
service demands over the MPLS-TP network. This MUST include service demands over the MPLS-TP network. This MUST include
support for a flexible bandwidth allocation scheme. support for a flexible bandwidth allocation scheme.
3. Requirements Discussed in Other Documents 3. Requirements Discussed in Other Documents
3.1. Network Management requirements 3.1. Network Management Requirements
For requirements related to network management functionality For requirements related to network management functionality
(Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP (Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP
Network Management requirements document [I-D.ietf-mpls-tp-nm-req]. Network Management requirements document [TP-NM-REQ].
3.2. Operation, Administration and Maintenance (OAM) requirements 3.2. Operation, Administration, and Maintenance (OAM) Requirements
For requirements related to OAM functionality for MPLS-TP, see the For requirements related to OAM functionality for MPLS-TP, see the
MPLS-TP OAM requirements document MPLS-TP OAM requirements document [TP-OAM-REQS].
[I-D.ietf-mpls-tp-oam-requirements].
3.3. Network performance monitoring requirements RFC 5654 MPLS-TP Requirements September 2009
For requirements related to performance monitoring functionality for 3.3. Network Performance-Monitoring Requirements
MPLS-TP, see the MPLS-TP OAM requirements document
[I-D.ietf-mpls-tp-oam-requirements].
3.4. Security requirements For requirements related to performance-monitoring functionality for
MPLS-TP, see the MPLS-TP OAM requirements document [TP-OAM-REQS].
3.4. Security Requirements
For a description of the security threats relevant in the context of For a description of the security threats relevant in the context of
MPLS and GMPLS and the defensive techniques to combat those threats MPLS and GMPLS and the defensive techniques to combat those threats,
see the Security Framework for MPLS & GMPLS Networks see "Security Framework for MPLS and GMPLS Networks" [G/MPLS-SEC].
[I-D.ietf-mpls-mpls-and-gmpls-security-framework].
For a description of additional security threats relevant in the For a description of additional security threats relevant in the
context of MPLS-TP and the defensive techniques to combat those context of MPLS-TP and the defensive techniques to combat those
threats see the Security Framework for MPLS-TP threats see "Security Framework for MPLS-TP" [TP-SEC-FMWK].
[I-D.ietf-fang-mpls-tp-security-framework].
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations 4. Security Considerations
See Section 3.4. See Section 3.4.
6. Acknowledgements 5. Acknowledgements
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in the IETF, and Working Team, the MPLS Interoperability Design Team in the IETF, and
the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and
specification of MPLS Transport Profile. specification of the MPLS Transport Profile.
The authors would also like to thank Loa Andersson, Dieter Beller, The authors would also like to thank Loa Andersson, Dieter Beller,
Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria
Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Jia He, Huub van Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Jia He, Huub van
Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy
Malis, Alan McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi Malis, Alan McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi
Ohta, Tom Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo Ohta, Tom Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo
Tancevski, Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve Tancevski, Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve
Varma and Maarten Vissers for their comments and enhancements to the Varma, and Maarten Vissers for their comments and enhancements to the
text. text.
An ad hoc discussion group consisting of Stewart Bryant, Italo Busi, An ad hoc discussion group consisting of Stewart Bryant, Italo Busi,
Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort,
Feng Huang, Harald Kullman, Han Li, Hao Long and Nurit Sprecher Feng Huang, Harald Kullman, Han Li, Hao Long, and Nurit Sprecher
provided valuable input to the requirements for deployment and provided valuable input to the requirements for deployment and
survivability in ring topologies. survivability in ring topologies.
7. References RFC 5654 MPLS-TP Requirements September 2009
7.1. Normative References 6. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Label Switching Architecture", RFC 3031, January 2001. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
Edge (PWE3) Architecture", RFC 3985, March 2005. "Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC4929] Andersson, L. and A. Farrel, "Change Process for [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation
Multiprotocol Label Switching (MPLS) and Generalized MPLS Edge-to-Edge (PWE3) Architecture", RFC 3985,
(GMPLS) Protocols and Procedures", BCP 129, RFC 4929, March 2005.
June 2007.
[ITU.G805.2000] [RFC4929] Andersson, L. and A. Farrel, "Change Process for
International Telecommunications Union, "Generic Multiprotocol Label Switching (MPLS) and
functional architecture of transport networks", ITU- Generalized MPLS (GMPLS) Protocols and Procedures",
T Recommendation G.805, March 2000. BCP 129, RFC 4929, June 2007.
[ITU.G8080.2006] [ITU.G805.2000] International Telecommunications Union, "Generic
International Telecommunications Union, "Architecture for functional architecture of transport networks",
the automatically switched optical network (ASON)", ITU- ITU-T Recommendation G.805, March 2000.
T Recommendation G.8080, June 2006.
[ITU.G8080.2008] [ITU.G8080.2006] International Telecommunications Union,
International Telecommunications Union, "Architecture for "Architecture for the automatically switched
the automatically switched optical network (ASON) optical network (ASON)", ITU-T Recommendation
Amendment 1", ITU-T Recommendation G.8080 Amendment 1, G.8080, June 2006.
March 2008.
7.2. Informative References [ITU.G8080.2008] International Telecommunications Union,
"Architecture for the automatically switched
optical network (ASON) Amendment 1", ITU-T
Recommendation G.8080 Amendment 1, March 2008.
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. 6.2. Informative References
Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical
Network (ASON)", RFC 4139, July 2005.
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A.,
Label Switching (GMPLS) Routing for the Automatically and L. Ong, "Requirements for Generalized MPLS
Switched Optical Network (ASON)", RFC 4258, November 2005. (GMPLS) Signaling Usage and Extensions for
Automatically Switched Optical Network (ASON)",
RFC 4139, July 2005.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the [RFC4258] Brungard, D., "Requirements for Generalized Multi-
Interpretation of Generalized Multiprotocol Label Protocol Label Switching (GMPLS) Routing for the
Switching (GMPLS) Terminology within the Context of the Automatically Switched Optical Network (ASON)",
ITU-T's Automatically Switched Optical Network (ASON) RFC 4258, November 2005.
Architecture", RFC 4397, February 2006.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and RFC 5654 MPLS-TP Requirements September 2009
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[I-D.ietf-fang-mpls-tp-security-framework] [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Fang, L. and B. Niven-Jenkins, "Security Framework for Interpretation of Generalized Multiprotocol Label
MPLS-TP", draft-fang-mpls-tp-security-framework-00 (work Switching (GMPLS) Terminology within the Context of
in progress), July 2008. the ITU-T's Automatically Switched Optical Network
(ASON) Architecture", RFC 4397, February 2006.
[I-D.ietf-mpls-mpls-and-gmpls-security-framework] [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery
Fang, L. and M. Behringer, "Security Framework for MPLS (Protection and Restoration) Terminology for
and GMPLS Networks", Generalized Multi-Protocol Label Switching
draft-ietf-mpls-mpls-and-gmpls-security-framework-05 (work (GMPLS)", RFC 4427, March 2006.
in progress), November 2008.
[I-D.ietf-mpls-tp-nm-req] [TP-SEC-FMWK] Fang, L. and B. Niven-Jenkins, "Security Framework
Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network for MPLS-TP", Work in Progress, July 2009.
Management Requirements", draft-ietf-mpls-tp-nm-req-01
(work in progress), April 2009.
[I-D.helvoort-mpls-tp-rosetta-stone] [G/MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and
van Helvoort, H., Andersson, L., and N. Sprecher, "A GMPLS Networks", Work in Progress, July 2009.
Thesaurus for the Terminology used in Multiprotocol Label
Switching Transport Profile (MPLS-TP) drafts/RFCs and
ITU-T's Transport Network Recommendations.",
draft-helvoort-mpls-tp-rosetta-stone-00 (work in
progress), March 2009.
[I-D.ietf-mpls-tp-oam-requirements] [TP-NM-REQ] Lam, H., Mansfield, S., and E. Gray, "MPLS TP
Vigoureux, M., Ward, D., and M. Betts, "Requirements for Network Management Requirements", Work in Progress,
OAM in MPLS Transport Networks", June 2009.
draft-ietf-mpls-tp-oam-requirements-01 (work in progress),
November 2008.
[I-D.ietf-pwe3-ms-pw-arch] [TP-TERMS] van Helvoort, H., Ed., Andersson, L., Ed., and N.
Bocci, M. and S. Bryant, "Requirements for OAM in MPLS Sprecher, Ed., "A Thesaurus for the Terminology
Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work used in Multiprotocol Label Switching Transport
in progress), September 2008. Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport
Network Recommendations", Work in Progress,
June 2009.
[ITU.Y1401.2008] [TP-OAM-REQS] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts,
International Telecommunications Union, "Principles of Ed., "Requirements for OAM in MPLS Transport
interworking", ITU-T Recommendation Y.1401, February 2008. Networks", Work in Progress, June 2009.
[ITU.Y2611.2006] [MS-PW-ARCH] Bocci, M. and S. Bryant, "An Architecture for
International Telecommunications Union, "High-level Multi-Segment Pseudowire Emulation Edge-to-Edge",
architecture of future packet-based networks", ITU- Work in Progress, July 2009.
T Recommendation Y.2611, December 2006.
[ITU.Y1401.2008] International Telecommunications Union, "Principles
of interworking", ITU-T Recommendation Y.1401,
February 2008.
[ITU.Y2611.2006] International Telecommunications Union, "High-level
architecture of future packet-based networks",
ITU-T Recommendation Y.2611, December 2006.
RFC 5654 MPLS-TP Requirements September 2009
Authors' Addresses Authors' Addresses
Ben Niven-Jenkins (editor) Ben Niven-Jenkins (editor)
BT BT
208 Callisto House, Adastral Park PP8a, 1st Floor, Orion Building, Adastral Park
Ipswich, Suffolk IP5 3RE Ipswich, Suffolk IP5 3RE
UK UK
Email: benjamin.niven-jenkins@bt.com EMail: benjamin.niven-jenkins@bt.com
Deborah Brungard (editor) Deborah Brungard (editor)
AT&T AT&T
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748 Middletown, NJ 07748
USA USA
Email: dbrungard@att.com EMail: dbrungard@att.com
Malcolm Betts (editor) Malcolm Betts (editor)
Huawei Technologies Huawei Technologies
Email: malcolm.betts@huawei.com EMail: malcolm.betts@huawei.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon, 45241
Israel Israel
Email: nurit.sprecher@nsn.com EMail: nurit.sprecher@nsn.com
Satoshi Ueno Satoshi Ueno
NTT NTT Communications
Email: satoshi.ueno@ntt.com EMail: satoshi.ueno@ntt.com
 End of changes. 206 change blocks. 
422 lines changed or deleted 461 lines changed or added

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