draft-ietf-mpls-tp-requirements-04.txt   draft-ietf-mpls-tp-requirements-05.txt 
Network Working Group B. Niven-Jenkins, Ed. MPLS Working Group B. Niven-Jenkins, Ed.
Internet-Draft BT Internet-Draft BT
Intended status: Informational D. Brungard, Ed. Intended status: Informational D. Brungard, Ed.
Expires: August 9, 2009 AT&T Expires: September 11, 2009 AT&T
M. Betts, Ed. M. Betts, Ed.
Nortel Networks Nortel Networks
N. Sprecher N. Sprecher
Nokia Siemens Networks Nokia Siemens Networks
S. Ueno S. Ueno
NTT NTT
February 5, 2009 March 10, 2009
MPLS-TP Requirements MPLS-TP Requirements
draft-ietf-mpls-tp-requirements-04 draft-ietf-mpls-tp-requirements-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 9, 2009. This Internet-Draft will expire on September 11, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
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 International
Telecommunications Union (ITU)-IETF effort to include an MPLS Telecommunications Union (ITU)-IETF effort to include an MPLS
Transport Profile within the IETF MPLS architecture to support the Transport Profile within the IETF MPLS and PWE3 architectures to
capabilities and functionalities of a packet transport network as support the capabilities and functionalities of a packet transport
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 architecture This work is based on two sources of requirements; MPLS and PWE3
as defined by IETF, and packet transport networks as defined by architectures as defined by IETF, and packet transport networks as
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 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Although this document is not a protocol specification, the key words
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
document are to be interpreted as described in RFC 2119. "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
interpreted as described in RFC 2119 [RFC2119] and are to be
interpreted as instructions to the protocol designers producing
solutions that satisfy the requirements set out in this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Transport network overview . . . . . . . . . . . . . . . . 8 1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6
1.3. Layer network overview . . . . . . . . . . . . . . . . . . 10 1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 10 1.2. Transport network overview . . . . . . . . . . . . . . . . 11
2.1. General requirements . . . . . . . . . . . . . . . . . . . 11 1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12
2.2. Layering requirements . . . . . . . . . . . . . . . . . . 12 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13
2.3. Data plane requirements . . . . . . . . . . . . . . . . . 13 2.1. General requirements . . . . . . . . . . . . . . . . . . . 13
2.4. Control plane requirements . . . . . . . . . . . . . . . . 15 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 15
2.5. Network Management (NM) requirements . . . . . . . . . . . 15 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 16
2.4. Control plane requirements . . . . . . . . . . . . . . . . 18
2.5. Network Management (NM) requirements . . . . . . . . . . . 19
2.6. Operation, Administration and Maintenance (OAM) 2.6. Operation, Administration and Maintenance (OAM)
requirements . . . . . . . . . . . . . . . . . . . . . . . 15 requirements . . . . . . . . . . . . . . . . . . . . . . . 19
2.7. Network performance management (PM) requirements . . . . . 16 2.7. Network performance management (PM) requirements . . . . . 19
2.8. Recovery & Survivability requirements . . . . . . . . . . 16 2.8. Recovery requirements . . . . . . . . . . . . . . . . . . 19
2.8.1. Data plane behavior requirements . . . . . . . . . . . 17 2.8.1. Data plane behavior requirements . . . . . . . . . . . 20
2.8.2. Triggers for protection, restoration, and reversion . 18 2.8.1.1. Protection . . . . . . . . . . . . . . . . . . . . 20
2.8.1.2. Restoration . . . . . . . . . . . . . . . . . . . 21
2.8.1.3. Sharing of protection resources . . . . . . . . . 21
2.8.1.4. Reversion . . . . . . . . . . . . . . . . . . . . 22
2.8.2. Triggers for protection, restoration, and reversion . 22
2.8.3. Management plane operation of protection and 2.8.3. Management plane operation of protection and
restoration . . . . . . . . . . . . . . . . . . . . . 19 restoration . . . . . . . . . . . . . . . . . . . . . 22
2.8.4. Control plane and in-band OAM operation of recovery . 19 2.8.4. Control plane and in-band OAM operation of recovery . 23
2.8.5. Topology-specific recovery mechanisms . . . . . . . . 20 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 24
2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 23 2.8.5.1. Ring protection . . . . . . . . . . . . . . . . . 24
2.10. Security requirements . . . . . . . . . . . . . . . . . . 24 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 27
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 2.10. Security requirements . . . . . . . . . . . . . . . . . . 27
4. Security Considerations . . . . . . . . . . . . . . . . . . . 24 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 4. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Normative References . . . . . . . . . . . . . . . . . . . 25 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Informative References . . . . . . . . . . . . . . . . . . 25 6.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 6.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
For many years, transport networks (e.g. Synchronous Optical Bandwidth demand continues to grow worldwide, stimulated by the
Networking (SONET)/Synchronous Digital hierarchy (SDH)) have provided accelerating growth and penetration of new packet based services and
carriers with a high benchmark for reliability and operational multimedia applications:
simplicity. With the accelerating growth and penetration of:
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 QoS requirements. o Applications with various bandwidth and QoS requirements.
This growth in demand has resulted in dramatic increases in access
rates that are, in turn, driving dramatic increases in metro and core
network bandwidth requirements.
Over the past two decades, the evolving optical transport
infrastructure (Synchronous Optical Networking (SONET)/Synchronous
Digital Hierarchy (SDH), Optical Transport Networ (OTN)) has provided
carriers with a high benchmark for reliability and operational
simplicity.
With the movement towards packet based services, the transport
network has to evolve to encompass the provision of packet aware
capabilities while enabling carriers to leverage their installed, as
well as planned, transport infrastructure investments.
Carriers are in need of technologies capable of efficiently 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. The need to increase their revenue while remaining networks with guaranteed Service Level Agreements (SLAs). The need
competitive forces operators to look for the lowest network Total to increase their revenue while remaining competitive forces
Cost of Ownership (TCO). Investment in equipment and facilities operators to look for the lowest network Total Cost of Ownership
(Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX) (TCO). Investment in equipment and facilities (Capital Expenditure
should be minimized. (CAPEX)) and Operational Expenditure (OPEX) should be minimized.
Carriers are considering migrating or evolving to packet transport There are a number of technology options for carriers to meet the
networks in order to reduce their costs and to improve their ability challenge of increased service sophistication and transport
to support services with guaranteed Service Level Agreements (SLAs). efficiency, with increasing usage of hybrid packet transport and
For carriers it is important that migrating from their existing circuit transport technology solutions. To realize these goals, it
transport networks to packet transport networks should not involve is essential that packet transport technology be available that can
dramatic changes in network operation, should not necessitate support the same high benchmarks for reliability and operational
extensive retraining, and should not require major changes to simplicity set by SDH/SONET and OTN technologies.
existing work practices. The aim is to preserve the look-and-feel to
which carriers have become accustomed in deploying their transport Furthermore for carriers it is important that operation of such
packet transport networks should preserve the look-and-feel to which
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 management for packet, circuit and lambda transport control and multi-technology management.
networks.
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 (Operations Support System (OSS) capabilities to support static (management plane based based) or
based) or dynamic (control plane) provisioning of deterministic, dynamic (control plane based) provisioning of deterministic,
protected and secured services and their associated resources. protected and secured services and their associated resources.
Carriers will still need to cope with legacy networks (which are It is also important to ensure smooth interworking of the packet
composed of many layers and technologies), thus the packet transport transport network with other existing/legacy packet networks, and
network should interwork as appropriate with other packet and provide mappings to enable packet transport carriage over a variety
transport networks (both horizontally and vertically). Vertical of transport network infrastructures. The latter has been termed
interworking is also known as client/server or network interworking. vertical interworking, and is also known as client/server or network
Horizontal interworking is also known as peer-partition or service interworking. The former has been termed horizontal interworking,
interworking. For more details on each type of interworking and some and is also known as peer-partition or service interworking. For
of the issues that may arise (especially with horizontal more details on interworking and some of the issues that may arise
interworking) see Y.1401 [ITU.Y1401.2008]. (especially with horizontal interworking) seeG.805 [ITU.G805.2000]
and Y.1401 [ITU.Y1401.2008].
MPLS is a maturing packet technology and it is already playing an MPLS is a maturing packet technology and it is already playing an
important role in transport networks and services. However, not all important role in transport networks and services. However, not all
of MPLS's capabilities and mechanisms are needed and/or consistent of MPLS's capabilities and mechanisms are needed and/or consistent
with transport network operations. There is therefore the need to with transport network operations. There are also transport
define an MPLS Transport Profile (MPLS-TP) in order to support the technology characteristics that are not currently reflected in MPLS.
capabilities and functionalities needed for packet transport network There is therefore the need to define an MPLS Transport Profile
services and operations through combining the packet experience of (MPLS-TP) that supports the capabilities and functionalities needed
MPLS with the operational experience of existing transport networks. for packet transport network services and operations through
combining the packet experience of MPLS with the operational
experience and practices of existing transport networks.
MPLS-TP will enable the migration of transport networks to a packet- MPLS-TP will enable the migration of transport networks to a packet-
based network that will efficiently scale to support packet services based network that will efficiently scale to support packet services
in a simple and cost effective way. MPLS-TP needs to combine the in a simple and cost effective way. MPLS-TP needs to combine the
necessary existing capabilities of MPLS with additional minimal necessary existing capabilities of MPLS with additional minimal
mechanisms in order that it can be used in a transport role. mechanisms in 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 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
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.
Although this document is not a protocol specification, the key words Although this document is not a protocol specification, the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used as "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used as
described in [RFC2119] and are to be interpreted as instructions to described in [RFC2119] and are to be interpreted as instructions to
the protocol designers producing solutions that satisfy the the protocol designers producing solutions that satisfy the
requirements set out in this document. requirements set out in this document.
This document is a product of a joint ITU-IETF effort to include an This document is a product of a joint ITU-T and IETF effort to
MPLS Transport Profile within the IETF MPLS architecture to support include an MPLS Transport Profile within the IETF MPLS and PWE3
the capabilities and functionalities of a packet transport network as architectures to support the capabilities and functionalities of a
defined by ITU-T. packet transport network as defined by ITU-T.
This work is based on two sources of requirements, MPLS architecture This work is based on two sources of requirements, MPLS and PWE3
as defined by IETF and packet transport networks as defined by ITU-T. architectures as defined by IETF and packet transport networks as
The requirements of MPLS-TP are provided below. The relevant defined by ITU-T. The requirements of MPLS-TP are provided below.
functions of MPLS are included in MPLS-TP, except where explicitly The relevant functions of MPLS and PWE3 are included in MPLS-TP,
excluded. except where explicitly excluded.
Although both static and dynamic configuration of MPLS-TP transport Although both static and dynamic configuration of MPLS-TP transport
paths (including Operations, Administration and Maintenance (OAM) and paths (including Operations, Administration and Maintenance (OAM) and
protection capabilities) is required by this document, it MUST be protection capabilities) is required by this document, it MUST be
possible for operators to be able to completely operate (including possible for operators to be able to completely operate (including
OAM and protection capabilities) an MPLS-TP network in the absence of OAM and protection capabilities) an MPLS-TP network in the absence of
any control plane protocols for dynamic configuration. any control plane protocols for dynamic configuration.
1.1. Terminology 1.1. 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
will be described in a subsequent document. will be described in a subsequent document.
The recovery requirements in this document use the recovery
terminology defined in RFC 4427 [RFC4427], this is applied to both
control plane and management plane based operations of MPLS-TP
transport paths.
1.1.1. Abbreviations
ASON: Automatically Switched Optical Network
ASTN: Automatic Switched Transport Network
ATM: Asynchronous Transfer Mode
CAPEX: Capital Expenditure
CE: Customer Edge
FR: Frame Relay
GMPLS: Generalised Multi-Protocol Label Switching
IGP: Interior Gateway Protocol
IPTV: IP Television
L2: Layer 2
L3: Layer 3
LSP: Label Switched Path
LSR: Label Switching Router
ME: Maintenance Entity
MPLS: Multi-Protocol Label Switching
OAM: Operations, Adminstration and Maintenance
OPEX: Operational Expenditure
OSI: Open Systems Interconnection
OTN: Optical Transport Network
P2MP: Point to Multi-Point
P2P: Point to Point
PDU: Protocol Data Unit
PM: Performance Management
PSC: Protection State Coordination
PW: Pseudo Wire
QoS: Quality of Service
RAN: Radio Access Network
SDH: Synchronous Digital Hierarchy
SLA: Service Level Agreement
SLS: Service Level Specification
S-PE: Switching Provider Edge
SONET: Synchronous Optical Network
SRLG: Shared Risk Link Group
TCO: Total Cost of Ownership
T-PE: Terminating Provider Edge
VoIP: Voice over IP
VPN: Virtual Private Network
WDM: Wavelength Division Multiplexing
1.1.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 which is constructed from a pair of
unidirectional paths (one for each direction) which are associated unidirectional paths (one for each direction) which are associated
with one another at the path's ingress/egress points. The forward with one another at the path's ingress/egress points. The forward
and backward directions may or may not follow the same route (links and backward directions are setup, monitored and protected
and nodes) across the network. independently. As a consequence they may or may not follow the same
route (links and nodes) across the network.
Bidirectional path: A path where the forward and backward directions Client layer network: In a client/server relationship (see G.805
follow the same route (links and nodes) across the network. [ITU.G805.2000]), the client layer network receives a (transport)
service from the lower server layer network (usually the layer
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. their interconnecting nodes in sequence. See also "Segment".
Co-routed bidirectional path: A bidirectional path where the forward Co-routed Bidirectional path: A path where the forward and backward
and backward directions follow the same route (links and nodes) directions follow the same route (links and nodes) across the
across its layer network. network. Both directions are setup, monitored and protected as a
single entity.
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 higher client layer network and may,
in turn, be a client to a lower layer network. A layer network is a in turn, be a client to a lower layer network. A layer network is a
logical construction somewhat independent of arrangement or 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(s) 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 zero or more sublayers. For additional explanation of how consist of one or more sublayers. Section 1.3 provides a more
layer networks relate to the OSI concept of layering see Appendix I detailed overview of what constitutes a layer network. For
of Y.2611 [ITU.Y2611.2006]. additional explanation of how layer networks relate to the OSI
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.
Logical Ring: An MPLS-TP logical ring is constructed from a set of MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from a
LSRs and logical data links (such as MPLS-TP LSP tunnels or MSPL-TP set of LSRs and logical data links (such as MPLS-TP LSP tunnels or
pseudowires) and physical data links that form a ring topology. MPLS-TP pseudowires) and physical data links that form a ring
topology.
Path: See Transport path. Path: See Transport Path.
Physical Ring: An MPLS-TP physical ring is constructed from a set of MPLS-TP Physical Ring: An MPLS-TP physical ring is constructed from a
LSRs and physical data links that form a ring topology. set of LSRs and physical data links that form a ring topology.
Ring Topology: In an MPLS-TP ring topology each LSR is connected to MPLS-TP Ring Topology: In an MPLS-TP ring topology each LSR is
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 data link. A ring may also be bidirectional MPLS-TP capable link. A ring may also be constructed
constructed from only two LSRs where there are also exactly two from only two LSRs where there are also exactly two links. Rings may
links. Rings may be connected to other LSRs to form a larger be connected to other LSRs to form a larger network. Traffic
network. Traffic originating or terminating outside the ring may be originating or terminating outside the ring may be carried over the
carried over the ring. Client network nodes (such as CEs) may be ring. Client network nodes (such as CEs) may be connected directly
connected directly to an LSR in the ring. to an LSR in the ring.
Section: A section is a server layer (which may be MPLS-TP or a Section Layer Network: A section is a server layer (which may be
different technology) which provides for encapsulation and OAM of a MPLS-TP or a different technology) which provides for encapsulation
MPLS-TP transport path client layer. A section layer may provide for and OAM of a client layer network. A section layer may provide for
aggregation of multiple MPLS-TP clients. Note that G.805 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 {S|T}-PEs). of adjacent {Switching|Terminating} Provider Edges). See also
"Concatenated Segment".
Server Layer Network: In a client/server relationship (see G.805
[ITU.G805.2000]), the server layer network provides a (transport)
service to the higher client layer network (usually the layer network
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].
Tandem Connection: A tandem connection is an arbitrary part of a Tandem Connection: A tandem connection is an arbitrary part of a
transport path that can be monitored (via OAM) independently from the transport path that can be monitored (via OAM) independently from the
end-to-end monitoring (OAM). It may be a monitored segment, a end-to-end monitoring (OAM). It may be a monitored segment or a
monitored concatenated segment or any other monitored ordered monitored concatenated segment of a transport path. The tandem
sequence of contiguous hops and/or segments (and their connection may also include the forwarding engine(s) of the node(s)
interconnecting nodes) of a transport path. at the edge(s) of the segment or concatenated segment.
Transport path: A network connection as defined in G.805 Terminating Provider Edge (T-PE): See [I-D.ietf-pwe3-ms-pw-arch].
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 layer network which provides point-to-point Transport Path Layer: A layer network that provides point-to-point or
or point-to-multipoint transport paths which are used to carry a point-to-multipoint transport paths that may be used to carry a
higher (client) layer network or aggregates of higher (client) layer higher (client) layer network or aggregates of higher (client) layer
networks, for example the transport service layer. It provides for networks, for example the transport service layer. It provides
independent OAM (of the client OAM) in the transport of the clients. independent (of the client) OAM when transporting its clients.
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 which provides sections Transmission Media Layer: A layer network, consisting of a section
(two-port point-to-point connections) to carry the aggregate of layer network and a physical layer network as defined in G.805
network transport path or network service layers on various physical [ITU.G805.2000], that provides sections (two-port point-to-point
media. connections) to carry the aggregate of network transport path or
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.2. Transport network overview
The connection (or transport path) service is the basic service The connectivity service is the basic service provided by a transport
provided by a transport network. The purpose of a transport network network. The purpose of a transport network is to carry its customer
is to carry its clients (i.e. the stream of client PDUs or client traffic (i.e. the stream of customer PDUs or customer bits, including
bits) between endpoints in the network (typically over several overhead) between endpoints in the transport network (typically over
intermediate nodes). These endpoints may be service switching points several intermediate nodes). The connectivity services offered to
or service terminating points. The connection services offered to customers are typically aggregated into large transport paths with
customers are aggregated into large transport paths with long-holding long-holding times and independent OAM (of the client OAM), which
times and independent OAM (of the client OAM), which contribute to contribute to enabling the efficient and reliable operation of the
enabling the efficient and reliable operation of the transport transport network. These transport paths are modified infrequently.
network. These transport paths are modified infrequently.
Aggregation and hierarchy are beneficial for achieving scalability Quality-of-service mechanisms are required in the packet transport
and security since: network to ensure the prioritization of critical services, to
guarantee bandwidth and to control jitter and delay. A transport
network must provide the means to commit quality of service
objectives to clients. This is achieved by providing a mechanism for
client network service demarcation for the network path together with
an associated network resiliency mechanism.
1. They reduce the number of provisioning and forwarding states in Aggregation is beneficial for achieving scalability and security
since:
1. It reduces the number of provisioning and forwarding states in
the network core. the network core.
2. They reduce 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. Clients are encapsulated and layer associated OAM overhead is 3. Customer traffic is encapsulated and layer associated OAM
added. This allows complete isolation of customer traffic and overhead is added. This allows complete isolation of customer
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. The client,
transport network and server layers are from a functional and transport network and server layers are from a functional and
operations point of view independent layer networks. Another key operations point of view 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 provide the means to commit quality of service transport network must also provide a method of service monitoring in
objectives to clients. This is achieved by providing a mechanism for order to verify the delivery of an agreed quality of service. This
client network service demarcation for the network path together with is enabled by means of carrier-grade OAM tools.
an associated network resiliency mechanism. A transport network must
also provide a method of service monitoring in order to verify the
delivery of an agreed quality of service. This is enabled by means
of carrier-grade OAM tools.
Clients are first encapsulated. These encapsulated client signals
may then be aggregated into a connection for transport through the
network in order to optimize network management. Server layer OAM is
used to monitor the transport integrity of the client layer or client
aggregate. At any hop, the aggregated signals may be further
aggregated in lower layer transport network paths for transport
across intermediate shared links. The encapsulated client signals
are extracted at the edges of aggregation domains, and are either
delivered to the client or forwarded to another domain. In the core
of the network, only the server layer aggregated signals are
monitored; individual client signals are monitored at the network
boundary in the client layer network. Although the connectivity of
the client of the transport path layer may be point-to-point, point-
to-multipoint or multipoint-to-multipoint, the transport path layer
itself only provides point-to-point or point-to-multipoint transport
paths which are used to carry the client.
Quality-of-service mechanisms are required in the packet transport Customer traffic is first encapsulated within the transport service
network to ensure the prioritization of critical services, to layer network. The transport service layer network signals may then
guarantee BW and to control jitter and delay. be aggregated into a transport path layer network for transport
through the network in order to optimize network management.
Transport service layer network OAM is used to monitor the transport
integrity of the customer traffic and transport path layer network
OAM is used to monitor the transport integrity of the aggregates. At
any hop, the aggregated signals may be further aggregated in lower
layer transport network paths for transport across intermediate
shared links. The transport service layer network signals are
extracted at the edges of aggregation domains, and are either
delivered to the customer or forwarded to another domain. In the
core of the network, only the transport path layer network signals
are monitored at intermediate points; individual transport service
layer network signals are monitored at the network boundary.
Although the connectivity of the transport service layer network may
be point-to-point, point-to-multipoint or multipoint-to-multipoint,
the transport path layer network only provides point-to-point or
point-to-multipoint transport paths which are used to carry
aggregates of transport service layer network traffic.
1.3. Layer network overview 1.3. 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 (individual packet payload for
connectionless networks, a sequence of packets payloads in the case connectionless networks, a sequence of packets payloads in the case
of connection oriented packet switched networks, and a deterministic of connection oriented packet switched networks, and a deterministic
schedule of payloads in the case of circuit switched networks) such schedule of payloads in the case of circuit switched networks) such
that the client can populate the payload without affecting any that the client can populate the payload without affecting any
operation within the serving layer network. operation within the serving layer network.
The operations within a layer network that are independent of the 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 of the reservation, the control of traffic demerging, and the OAM and
transport service. All of these operations are internal to a layer recovery of the transport service. All of these operations are
network. By definition, a layer network does not rely on any client internal to a layer network. By definition, a layer network does not
information to perform these operations and therefore all information rely on any client information to perform these operations and
required to perform these operations is independent of whatever therefore all information required to perform these operations is
client is using the layer network. independent of whatever client is using the layer network.
A layer network will have common features in order to support the A layer network will have common features in order to support the
control of forwarding, resource reservation, and OAM. For example, a control of forwarding, resource reservation, OAM and recovery. For
layer network will have a common addressing scheme for the end points example, a layer network will have a common addressing scheme for the
of the transport service and a common set of transport descriptors end points of the transport service and a common set of transport
for the transport service. However, a client may use a different descriptors for the transport service. However, a client may use a
addressing scheme or different traffic descriptors (consistent with different addressing scheme or different traffic descriptors
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 as the traverse within a layer network (or the transport services that traverse this
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 within 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
This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). The requirements are for the behavior of the protocol
mechanisms and procedures that constitute building blocks out of
which the MPLS transport profile is constructed. That is, the
requirements indicate what features are to be available in the MPLS
toolkit for use by MPLS-TP. The requirements in this document do not
describe what functions an MPLS-TP implementation supports. The
purpose of this document is to identify the toolkit and any new
protocol work that is required.
2.1. General requirements 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 sub-set (necessary and
sufficient subset) applicable to a transport network application. sufficient subset) applicable to a transport network application.
2 Any new functionality that is defined to fulfil the requirements 2 Any new functionality that is defined to fulfill the requirements
for MPLS-TP MUST be agreed within the IETF through the IETF for MPLS-TP MUST be agreed within the IETF through the IETF
consensus process and MUST re-use (as far as practically consensus process and MUST re-use (as far as practically
possible) existing MPLS standards. possible) existing MPLS standards.
3 Mechanisms and capabilities MUST be able to interoperate, without 3 Mechanisms and capabilities MUST be able to interoperate with
a gateway function, with existing IETF MPLS [RFC3031] and IETF existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and
PWE3 [RFC3985] control and data planes where appropriate. data planes where appropriate.
A. Data plane interoperability MUST NOT require a gateway
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 network, multiple vendors will be possible both within a single domain,
and between networks. and between domains.
5 MPLS-TP MUST be a connection-oriented packet switching model with 5 MPLS-TP MUST be a connection-oriented packet switching technology
traffic engineering capabilities that allow deterministic control with traffic engineering capabilities that allow deterministic
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 the logical separation of the control and 7 MPLS-TP MUST support the logical separation of the control and
management planes from the data plane. management planes from the data plane.
8 MPLS-TP MUST allow the physical separation of the control and 8 MPLS-TP MUST support the physical separation of the control and
management planes from the data plane. management planes from the data plane.
9 MPLS-TP MUST support static provisioning of transport paths via 9 MPLS-TP MUST support static provisioning of transport paths via
an OSS, i.e. via the management plane. the management plane.
10 Mechanisms in an MPLS-TP network that satisfy functional 10 Mechanisms in an MPLS-TP network that satisfy functional
requirements that are common to general transport networks (i.e., requirements that are common to general transport networks (i.e.,
independent of technology) SHOULD be operable in a way that is independent of technology) SHOULD be operable in a way that is
similar to the way the equivalent mechanisms are operated in similar to the way the equivalent mechanisms are operated in
other transport networks. other transport networks.
11 Static provisioning MUST NOT depend on the presence of any 11 Static provisioning MUST NOT depend on the presence of any
element of a control plane. element of a control plane.
12 MPLS-TP MUST support the capability for network operation 12 MPLS-TP MUST support the capability for network operation
(including OAM and recovery) via the management plane (without (including OAM and recovery) via the management plane (without
the use of any control plane protocols). the use of any control plane protocols).
13 A solution MUST be provided to support dynamic provisioning of 13 A solution MUST be defined to support dynamic provisioning and
MPLS-TP transport paths via a control plane. restoration of MPLS-TP transport paths via a control plane.
14 The MPLS-TP data plane MUST be capable of forwarding data and 14 The MPLS-TP data plane MUST be capable of
taking recovery actions independently of the control or
management plane used to operate the MPLS-TP layer network. That A. forwarding data independent of the control or management
is, the MPLS-TP data plane MUST continue to operate normally if plane used to configure and operate the MPLS-TP layer
the management plane or control plane that configured the network.
transport paths fails.
B. taking recovery actions independent of the control plane used
to configure the MPLS-TP layer network. If the control plane
does not restart, the data plane connections MUST be held and
NOT time out.
15 MPLS-TP MUST support mechanisms to avoid or minimize traffic 15 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.
16 MPLS-TP MUST support transport paths through multiple homogeneous 16 MPLS-TP MUST support transport paths through multiple homogeneous
domains. domains.
17 MPLS-TP MUST NOT dictate the deployment of any particular network 17 MPLS-TP SHOULD support transport paths through multiple non-
homogeneous domains.
18 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 TDM rings to MPLS-TP.
MPLS-TP SHOULD support rings with more than 16 nodes. MPLS-TP SHOULD support rings with more than 16 nodes.
18 MPLS-TP MUST be able to scale at least as well as existing 19 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 bandwidth demands,
number of customers, and number of services. number of customers, and number of services.
19 MPLS-TP SHOULD support mechanisms to safeguard against the 20 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 2.2. Layering requirements
20 A generic and extensible solution MUST be provided to support the
21 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,
Ethernet, ATM, FR, etc.) over an MPLS-TP layer network. IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
21 A solution MUST be provided to support the transport of MPLS-TP 22 A generic and extensible solution MUST be provided to support the
transport paths over one or more server layer networks (such as transport of MPLS-TP transport paths over one or more server
MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). Requirements for layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).
bandwidth management within a server layer network are outside Requirements for bandwidth management within a server layer
the scope of this document. network are outside the scope of this document.
22 In an environment where an MPLS-TP layer network is supporting a 23 In an environment where an MPLS-TP layer network is supporting a
client network, and the MPLS-TP layer network is supported by a client layer network, and the MPLS-TP layer network is supported
server layer network then operation of the MPLS-TP layer network by a server layer network then operation of the MPLS-TP layer
MUST be possible without any dependencies on the server or client network MUST be possible without any dependencies on the server
or client layer network.
A. The server layer MUST guarantee that the traffic loading
imposed by other clients does not cause the transport service
provided to the MPLS-TP layer to fall bellow the agreed
level. Mechanisms to achieve this are outside the scope of
these requirements.
24 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
network. network.
23 It MUST be possible to operate the layers of a multi-layer A. The level of co-ordination required between the client and
server MPLS(-TP) layer networks MUST be minimised (preferably
no co-ordination will be required).
B. The MPLS(-TP) server layer network MUST be capable of
transporting the complete set of packets generated by the
client MPLS(-TP) layer network, which may contain packets
that are not MPLS packets (e.g. IP or CNLS packets used by
the control/management plane of the client MPLS(-TP) layer
network).
25 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.
The above are not only technology requirements, but also operational. The above are not only technology requirements, but also operational
Different administrative groups may be responsible for the same layer requirements. Different administrative groups may be responsible for
network or different layer networks. the same layer network or different layer networks.
24 It MUST be possible to hide MPLS-TP layer network addressing and 26 It MUST be possible to hide MPLS-TP layer network addressing and
other information (e.g. topology) from client layers. other information (e.g. topology) from client layer networks.
However, it SHOULD be possible, at the option of the operator, to
leak a limited amount of summarized information (such as SRLGs or
reachability) between layers.
2.3. Data plane requirements 2.3. Data plane requirements
27 It MUST be possible for the end points of an MPLS-TP transport
path that is carrying an aggregate of client transport paths to
be be able to decompose the aggregate transport path into its
component client transport paths.
25 The identification of each transport path within its aggregate 28 A transport path on a link MUST be uniquely identifiable by a
MUST be supported. single label on that link.
26 A label in a particular link MUST uniquely identify the transport
path within that link.
27 A transport path's source MUST be identifiable at its destination 29 A transport path's source MUST be identifiable at its destination
within its layer network. within its layer network.
28 MPLS-TP MUST be capable of using P2MP server (sub-)layer 30 MPLS-TP MUST be capable of using P2MP server (sub-)layer
capabilities when supporting P2MP MPLS-TP transport paths (for capabilities as well as P2P server (sub-)layer capabilities when
example context-specific labels [RFC5331]). supporting P2MP MPLS-TP transport paths.
29 It MUST be possible to operate and configure the MPLS-TP data
(transport) plane without any IP forwarding capability in the
MPLS-TP data plane.
30 MPLS-TP MUST support unidirectional, bidirectional and co-routed
bidirectional point-to-point transport paths.
31 The forward and backward directions of a co-routed bidirectional 31 MPLS-TP MUST support unidirectional, co-routed bidirectional and
transport path MUST follow the same links and nodes within its associated bidirectional point-to-point transport paths.
(sub-)layer network.
32 The intermediate nodes at each (sub-)layer MUST be aware about 32 The intermediate nodes at each (sub-)layer MUST be aware about
the pairing relationship of the forward and the backward the pairing relationship of the forward and the backward
directions belonging to the same bidirectional transport path. directions belonging to the same co-routed bidirectional
transport path.
33 MPLS-TP MAY support transport paths with asymmetric bandwidth 33 MPLS-TP MUST support bidirectional transport paths with
requirements, i.e. the amount of reserved bandwidth differs asymmetric bandwidth requirements, i.e. the amount of reserved
between the forward and backward directions. bandwidth differs between the forward and backward directions.
34 MPLS-TP MUST support unidirectional point-to-multipoint transport 34 MPLS-TP MUST support unidirectional point-to-multipoint transport
paths. paths.
35 MPLS-TP MUST be extensible in order to accommodate new types of 35 MPLS-TP MUST be extensible in order to accommodate new types of
client networks and services. client layer networks and services.
36 MPLS-TP SHOULD support mechanisms to enable the reserved 36 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.
37 MPLS-TP SHOULD support mechanisms to enable the reserved 37 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.
38 MPLS-TP MUST support mechanisms which ensure the integrity of the 38 MPLS-TP MUST support mechanisms which 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
skipping to change at page 15, line 7 skipping to change at page 18, line 15
39 MPLS-TP MUST support mechanisms to detect when loss of integrity 39 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.
40 MPLS-TP MUST support an unambiguous and reliable means of 40 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 protection
switching packets). switching packets).
2.4. Control plane requirements 2.4. Control plane requirements
This section defines the requirements that apply to MPLS-TP when a This section defines the requirements that apply to an MPLS-TP
control plane is deployed. control plane. Note that it MUST be possible to operate an MPLS-TP
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 and Transport Networks (ASON/ASTN) in G.8080 Optical and Transport Networks (ASON/ASTN) in G.8080 [ITU.G8080.2006]
[ITU.G8080.2006]. The control plane for MPLS-TP MUST fit within the and G.8080 Amd1 [ITU.G8080.2008]. The control plane for MPLS-TP MUST
ASON/ASTN architecture. fit within the ASON/ASTN architecture.
An interpretation of the ASON/ASTN control plane requirements in the An interpretation of the ASON/ASTN signaling and routing requirements
context of GMPLS can be found in [RFC4139] and [RFC4258]. in the context of GMPLS can be found in [RFC4139] and [RFC4258].
Additionally: Additionally:
41 The MPLS-TP control pane SHOULD support control plane topology 41 It MUST be possible to operate and configure the MPLS-TP data
and data plane topology independence. plane without any IP forwarding capability in the MPLS-TP data
plane.
42 The MPLS-TP control plane MUST be able to be operated independent 42 The MPLS-TP control pane MUST support control plane topology and
data plane topology independence. As a consequence a failure of
the control plane does not imply that there has also been a
failure of the data plane.
43 The MPLS-TP control plane MUST be able to be operated independent
of any particular client or server layer control plane. of any particular client or server layer control plane.
43 The MPLS-TP control plane MUST support establishing all the 44 MPLS-TP SHOULD define a solution to support an integrated control
plane encompassing MPLS-TP together with its server and client
layer networks when these layer networks belong to the same
administrative domain.
45 The MPLS-TP control plane MUST support establishing all the
connectivity patterns defined for the MPLS-TP data plane (e.g., connectivity patterns defined for the MPLS-TP data plane (e.g.,
unidirectional and bidirectional P2P, unidirectional P2MP, etc.) unidirectional and bidirectional P2P, unidirectional P2MP, etc.)
including configuration of protection functions and any including configuration of protection functions and any
associated maintenance functions. associated maintenance functions.
44 The MPLS-TP control pane MUST support the configuration and 46 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.
45 An MPLS-TP control plane MUST support operation of the recovery 47 An MPLS-TP control plane MUST support operation of the recovery
functions described in Section 2.8. functions described in Section 2.8.
46 An MPLS-TP control plane MUST scale gracefully to support a large 48 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.
49 If a control plane is used for MPLS-TP, the control plane's
graceful restart capabilities, if any, MUST be supported.
2.5. Network Management (NM) requirements 2.5. Network Management (NM) requirements
For requirements related to NM functionality (Management Plane in For requirements related to NM functionality (Management Plane in
ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements
document [I-D.gray-mpls-tp-nm-req]. document [I-D.gray-mpls-tp-nm-req].
2.6. Operation, Administration and Maintenance (OAM) requirements 2.6. 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
[I-D.ietf-mpls-tp-oam-requirements]. [I-D.ietf-mpls-tp-oam-requirements].
2.7. Network performance management (PM) requirements 2.7. Network performance management (PM) requirements
For requirements related to PM functionality for MPLS-TP, see the For requirements related to PM functionality for MPLS-TP, see the
MPLS-TP OAM requirements document MPLS-TP OAM requirements document
[I-D.ietf-mpls-tp-oam-requirements]. [I-D.ietf-mpls-tp-oam-requirements].
2.8. Recovery & Survivability requirements 2.8. 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.
The requirements in this section use the recovery terminology defined 50 MPLS-TP MUST provide protection and restoration mechanisms.
in RFC 4427 [RFC4427].
47 MPLS-TP MUST provide protection and restoration mechanisms. A. MPLS-TP recovery techniques SHOULD be identical (or as
similar as possible) to those already used in existing
transport networks to simplify implementation and operations.
However, this MUST NOT override any other requirement.
A. 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.
48 MPLS-TP recovery mechanisms MUST be applicable at various levels 51 MPLS-TP recovery mechanisms MUST be applicable at various levels
throughout the network including support for link, path segment throughout the network including support for link, transport
and end-to-end path, and pseudowire segment, and end-to-end path, segment, concatenated segment and end to end recovery.
pseudowire recovery.
49 MPLS-TP recovery paths MUST meet the SLA protection objectives of 52 MPLS-TP recovery paths MUST meet the SLA protection objectives of
the service. the service.
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 objectives SHOULD be configurable per transport C. Recovery objectives SHOULD be configurable per transport
path, and SHOULD include bandwidth and QoS. path, and SHOULD support objectives for bandwidth and QoS.
50 The recovery mechanisms MUST all be applicable to any topology. D. Recovery MUST meet SLA requirements over multiple domains.
51 The recovery mechanisms MUST operate in synergy with (including 53 The recovery mechanisms SHOULD be applicable to any topology.
coordination of timing) the recovery mechanisms present in any
underlying server transport network (for example, Ethernet, SDH,
OTN, WDM) to avoid race conditions between the layers.
52 MPLS-TP protection mechanisms MUST support priority logic to 54 The recovery mechanisms MUST support the means to operate in
negotiate and accommodate coexisting requests (i.e., multiple synergy with (including coordination of timing) the recovery
requests) for protection switching (e.g., administrative requests mechanisms present in any client or server transport networks
and requests due to link/node failures). (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions
between the layers.
53 MPLS-TP recovery and reversion mechanisms MUST prevent frequent 55 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.8.1. Data plane behavior requirements 2.8.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.8.1.1. Protection 2.8.1.1. Protection
54 MPLS-TP MUST support 1+1 protection. 56 MPLS-TP MUST support 1+1 protection.
A. MPLS-TP 1+1 support MUST include bidirectional protection A. Bidirectional 1+1 protection for P2P connectivity MUST be
switching for P2P connectivity, and this SHOULD be the supported.
default behavior for 1+1 protection.
B. Unidirectional 1+1 protection for P2MP connectivity MUST be B. Unidirectional 1+1 protection for P2P connectivity MUST be
supported. supported.
C. Unidirectional 1+1 protection for P2P connectivity is not C. Unidirectional 1+1 protection for P2MP connectivity MUST be
required. supported.
55 MPLS-TP MUST support 1:n protection (including 1:1 protection). 57 MPLS-TP MUST support 1:n protection (including 1:1 protection).
A. MPLS-TP 1:n support MUST include bidirectional protection A. MPLS-TP 1:n protection MUST include bidirectional protection
switching for P2P connectivity, and this SHOULD be the switching for P2P connectivity, and this SHOULD be the
default behavior for 1:n protection. default behavior for 1:n 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. required.
D. The action of protection switching MUST NOT cause user data D. The action of protection switching MUST NOT cause user data
to loop. Backtracking is allowed. to loop. Backtracking is allowed.
Note: Support for extra traffic (as defined in G.870 [ITU.G870.2008]) Note: Support for extra traffic (as defined in [RFC4427]) is not
is not required in MPLS-TP. required in MPLS-TP.
2.8.1.2. Restoration 2.8.1.2. Restoration
56 The restoration LSP MUST be able to share resources with the LSP 58 The restoration transport path MUST be able to share resources
being replaced (sometimes known as soft rerouting). with the transport path being replaced (sometimes known as soft
rerouting).
57 Restoration priority MUST be supported so that an implementation 59 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).
58 Preemption priority MUST be supported to allow restoration to 60 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.
2.8.1.3. Sharing of protection resources 2.8.1.3. Sharing of protection resources
59 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh 61 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh
restoration. restoration.
60 MPLS-TP MUST support the sharing of protection bandwidth by 62 MPLS-TP MUST support the definition of shared protection groups
allowing best effort traffic.
61 MPLS-TP MUST support the definition of shared protection groups
to allow the coordination of protection actions resulting from to allow the coordination of protection actions resulting from
triggers caused by events at different locations in the network. triggers caused by events at different locations in the network.
62 MPLS-TP MUST support sharing of protection resources such that 63 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.8.1.4. Reversion 2.8.1.4. Reversion
63 MPLS-TP protection mechanisms MUST support revertive and non- 64 MPLS-TP protection mechanisms MUST support revertive and non-
revertive behavior. Reversion MUST be the default behavior. revertive behavior. Reversion MUST be the default behavior.
64 MPLS-TP restoration mechanisms MAY support revertive and non- 65 MPLS-TP restoration mechanisms MUST support revertive and non-
revertive behavior. revertive behavior.
2.8.2. Triggers for protection, restoration, and reversion 2.8.2. 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:
65 MPLS-TP MUST support physical layer fault indication triggers. 66 MPLS-TP MUST support physical layer fault indication triggers.
66 MPLS-TP MUST support OAM-based triggers. 67 MPLS-TP MUST support OAM-based triggers.
67 MPLS-TP MUST support management plane triggers (e.g., forced 68 MPLS-TP MUST support management plane triggers (e.g., forced
switch, etc.). switch, etc.).
68 There MUST be a mechanism to allow administrative recovery 69 There MUST be a mechanism to allow administrative recovery
actions to be distinguished from recovery actions initiated by actions to be distinguished from recovery actions initiated by
other triggers. other triggers.
69 Where a control plane is present, MPLS-TP SHOULD support control 70 Where a control plane is present, MPLS-TP SHOULD support control
plane triggers. plane triggers.
71 MPLS-TP protection mechanisms MUST support priority logic to
negotiate and accommodate coexisting requests (i.e., multiple
requests) for protection switching (e.g., administrative requests
and requests due to link/node failures).
2.8.3. Management plane operation of protection and restoration 2.8.3. 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.
70 It MUST be possible to configure of protection paths and 72 It MUST be possible to configure protection paths and protection-
protection-to-working path relationships (sometimes known as to-working path relationships (sometimes known as protection
protection groups). groups).
71 There MUST be support for pre-calculation of recovery paths. 73 There MUST be support for pre-calculation of recovery paths.
72 There MUST be support for pre-provisioning of recovery paths. 74 There MUST be support for pre-provisioning of recovery paths.
73 The external controls as defined in [RFC4427] MUST be supported. 75 The external controls as defined in [RFC4427] MUST be supported.
74 There MUST be support for the configuration of timers used for A. External controls overruled by higher priority requests
(e.g., administrative requests and requests due to link/node
failures) or unable to be signaled to the remote end (e.g.
because of a protection state coordination fail) MUST be
dropped.
76 There MUST be support for the configuration of timers used for
recovery operation. recovery operation.
75 Restoration resources MAY be pre-planned and selected a priori, 77 Restoration resources MAY be pre-planned and selected a priori,
or computed after failure occurrence. or computed after failure occurrence.
76 When preemption is supported for recovery purposes, it MUST be 78 When preemption is supported for restoration purposes, it MUST be
possible for the operator to configure it. possible for the operator to configure it.
77 The management plane MUST provide indications of protection 79 The management plane MUST provide indications of protection
events and triggers. events and triggers.
78 The management plane MUST allow the current protection status of 80 The management plane MUST allow the current protection status of
all transport paths to be determined. all transport paths to be determined.
2.8.4. Control plane and in-band OAM operation of recovery 2.8.4. Control plane and in-band OAM operation of recovery
79 The MPLS-TP control plane (which is not mandatory in an MPLS-TP
implementation) MUST support: 81 The MPLS-TP control plane (which is not mandatory in an MPLS-TP
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) C. protection state coordination (PSC). Since control plane
network topology is independent from the data plane network
topology, the PSC supported by the MPLS-TP control plane MAY
run on resources different than the data plane resources
handled within the recovery mechanism (e.g. backup).
80 In-band OAM MAY be used for: 82 In-band OAM MUST be capable of supporting:
A. signaling of administrative control A. signaling of administrative control
B. protection state coordination B. protection state coordination (PSC). Since in-band OAM tools
share the data plane with the carried transport service, in
order to optimize the usage of network resources, the PSC
supported by in-band OAM MUST run on protection resources.
2.8.5. Topology-specific recovery mechanisms 2.8.5. Topology-specific recovery mechanisms
81 MPLS-TP MAY support recovery mechanisms that are optimized for 83 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.
Note that topology-specific recovery mechanisms are subject to the
development of requirements using the normal IETF process.
2.8.5.1. Ring protection 2.8.5.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 MEs that are needed to trigger the a. Minimize the number of OAM entities that are needed to trigger
recovery operation - less than are required by other recovery the recovery operation - less than are required by other recovery
mechanisms. mechanisms.
b. Minimize the number of elements of recovery in the ring - less b. Minimize the number of elements of recovery in the ring - less
than are required by other recovery mechanisms. than are 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 - less than are required by other recovery
mechanisms. mechanisms.
d. Minimize the amount of management plane transactions during a d. Minimize the amount of control and management plane transactions
maintenance operation (e.g., ring upgrade) - less than are during a maintenance operation (e.g., ring upgrade) - less than
required by other recovery mechanisms. are required by other recovery mechanisms.
e. When a control plane is supported, minimize the impact on
signalling and routing information exchange during protection -
less than are required by other recovery mechanisms.
It may be observed that the requirements in this section are fully It may be observed that the requirements in this section are fully
compatible with the generic requirements expressed above, and that no compatible with the generic requirements expressed above, and that no
requirements that are specific to ring topologies have been requirements that are specific to ring topologies have been
identified. identified.
82 MPLS-TP MUST include recovery mechanisms that operate in any 84 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.
83 When a network is constructed from interconnected rings, MPLS-TP 85 When a network is constructed from interconnected rings, MPLS-TP
MUST support recovery mechanisms that protect user data that MUST support recovery mechanisms that protect user data that
traverses more than one ring. This includes the possibility of traverses more than one ring. This includes the possibility of
failure of the ring-interconnect nodes and links. failure of the ring-interconnect nodes and links.
84 MPLS-TP recovery in a ring MUST protect unidirectional and 86 MPLS-TP recovery in a ring MUST protect unidirectional and
bidirectional P2P transport paths. bidirectional P2P transport paths.
85 MPLS-TP recovery in a ring MUST protect unidirectional P2MP 87 MPLS-TP recovery in a ring MUST protect unidirectional P2MP
transport paths. transport paths.
86 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching 88 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 network 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. with a 16 nodes ring with less than 1200 km of fiber.
87 The protection switching time in a ring MUST be independent of 89 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.
88 Recovery actions in a ring MUST be data plane functions triggered 90 Recovery actions in a ring MUST be data plane functions triggered
by different elements of control. The triggers are configured by by different elements of control. The triggers are configured by
management or control planes and are subject to configurable management or control planes and are subject to configurable
policy. policy.
89 The configuration and operation of recovery mechanisms in a ring 91 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 as C. the number of ring interconnects (must be at least as good as
linear scaling) linear scaling)
92 Recovery techniques used in a ring MUST NOT prevent the ring from
90 MPLS-TP recovery in ring topologies MAY support multiple failures
without reconfiguring the protection actions.
91 Recovery techniques used in a ring MUST NOT prevent the ring from
being connected to a general MPLS-TP network in any arbitrary being connected to a general MPLS-TP network in any arbitrary
way, and MUST NOT prevent the operation of recovery techniques in way, and MUST NOT prevent the operation of recovery techniques in
the rest of the network. the rest of the network.
92 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally 93 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally
applicable in physical and logical rings. applicable in physical and logical rings.
93 Recovery techniques in a ring SHOULD be identical to those in 94 Recovery techniques in a ring SHOULD be identical (or as similar
general networks to simplify implementation. However, this MUST as possible) to those in general transport networks to simplify
NOT override any other requirement. implementation and operations. However, this MUST NOT override
any other requirement.
94 Recovery techniques in logical and physical rings SHOULD be 95 Recovery techniques in logical and physical rings SHOULD be
identical to simplify implementation and operation. However, identical to simplify implementation and operation. However,
this MUST NOT override any other requirement. this MUST NOT override any other requirement.
95 The default recovery scheme in a ring MUST be bidirectional 96 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.
96 The recovery mechanism in a ring MUST support revertive 97 The recovery mechanism in a ring MUST support revertive
switching, which MUST be the default behaviour. This allows switching, which MUST be the default behaviour. 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.
97 The recovery mechanisms in a ring MUST support ways to allow 98 The recovery mechanisms in a ring MUST support ways to allow
administrative protection switching, to be distinguished from administrative protection switching, to be distinguished from
protection switching initiated by other triggers. protection switching initiated by other triggers.
98 It MUST be possible to lockout (disable) protection mechanisms on 99 It MUST be possible to lockout (disable) protection mechanisms on
selected links (spans) in a ring (depending on operator's need). selected links (spans) in a ring (depending on operator's need).
This may require lockout mechanisms to be applied to intermediate This may require lockout mechanisms to be applied to intermediate
nodes within a transport path. nodes within a transport path.
99 MPLS-TP recovery mechanisms in a ring MUST include a mechanism 100 MPLS-TP recovery mechanisms in a ring:
to allow an implementation to handle coexisting requests (i.e.,
multiple requests - not necessarily arriving simultaneously) for
protection switching based on priority.
100 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a A. MUST include a mechanism to allow an implementation to
handle (including the coordination of) coexisting requests
or triggers (i.e., multiple requests - not necessarily
arriving simultaneously and located anywhere in the ring)
for protection switching based on priority. Note that such
coordiantion is the ring equivalent of the definition of
shared protection groups.
B. MAY support multiple failures without reconfiguring the
protection actions.
101 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.
101 MPLS-TP MUST support the sharing of protection bandwidth in a 102 MPLS-TP MUST support the sharing of protection bandwidth in a
ring by allowing best effort traffic. ring by allowing best effort traffic.
102 MPLS-TP MUST support sharing of ring protection resources such 103 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.
103 MUST support the coordination of triggers caused by events at
different locations in a ring. Note that this is the ring
equivalent of the definition of shared protection groups.
2.9. QoS requirements 2.9. 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:
104 Support for differentiated services and different traffic types 104 Support for differentiated services and different traffic types
with traffic class separation associated with different traffic. with traffic class separation associated with different traffic.
105 Prioritization of critical services. 105 Enabling the provisioning and the guarantee of Service Level
106 Enabling the provisioning and the guarantee of Service Level
Specifications (SLS), with support for hard and relative end-to- Specifications (SLS), with support for hard and relative end-to-
end bandwidth guaranteed. end bandwidth guaranteed.
107 Support of services, which are sensitive to jitter and delay. 106 Support of services, which are sensitive to jitter and delay.
108 Guarantee of fair access, within a particular class, to shared 107 Guarantee of fair access, within a particular class, to shared
resources. resources.
109 Guaranteed resources for in-band control and management plane 108 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.
110 Carriers are provided with the capability to efficiently support 109 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.
2.10. Security requirements 2.10. 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 the Security Framework for MPLS & GMPLS Networks
[I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]. [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework].
3. IANA Considerations 3. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
4. Security Considerations 4. Security Considerations
For a description of the security threats relevant in the context of See Section 2.10.
MPLS and GMPLS and the defensive techniques to combat those threats
see the Security Framework for MPLS & GMPLS Networks
[I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework].
5. 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 MPLS Transport Profile.
The authors would also like to thank Loa Andersson, Lou Berger, Italo The authors would also like to thank Loa Andersson, Dieter Beller,
Busi, John Drake, Adrian Farrel, Eric Gray, Neil Harrison, Huub van Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria
Helvoort, Wataru Imajuku, Julien Meuric, Tom Nadeau, Hiroshi Ohta, Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Huub van
George Swallow, Tomonori Takeda and Maarten Vissers for their Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy
Malis, Alan McGuire, Julien Meuric, Tom Nadeau, Hiroshi Ohta, Tom
Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo Tancevski,
Tomonori Takeda, Yuji Tochio, Eve Varma and Maarten Vissers for their
comments and enhancements to the text. comments and enhancements to the 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.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.gray-mpls-tp-nm-req]
Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network
Management Requirements", draft-gray-mpls-tp-nm-req-02
(work in progress), January 2009.
[I-D.ietf-mpls-tp-oam-requirements]
Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks",
draft-ietf-mpls-tp-oam-requirements-00 (work in progress),
November 2008.
6.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
Ong, "Requirements for Generalized MPLS (GMPLS) Signaling Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical Usage and Extensions for Automatically Switched Optical
Network (ASON)", RFC 4139, July 2005. Network (ASON)", RFC 4139, July 2005.
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol
Label Switching (GMPLS) Routing for the Automatically Label Switching (GMPLS) Routing for the Automatically
Switched Optical Network (ASON)", RFC 4258, November 2005. Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, February 2006.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006. Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [I-D.ietf-pwe3-ms-pw-arch]
Label Assignment and Context-Specific Label Space", Bocci, M. and S. Bryant, "Requirements for OAM in MPLS
RFC 5331, August 2008. Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work
in progress), September 2008.
[I-D.gray-mpls-tp-nm-req]
Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network
Management Requirements", draft-gray-mpls-tp-nm-req-03
(work in progress), January 2009.
[I-D.ietf-mpls-tp-oam-requirements]
Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks",
draft-ietf-mpls-tp-oam-requirements-01 (work in progress),
November 2008.
[I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework] [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]
Fang, L. and M. Behringer, "Security Framework for MPLS Fang, L. and M. Behringer, "Security Framework for MPLS
and GMPLS Networks", and GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework-04 (work draft-ietf-mpls-mpls-and-gmpls-security-framework-04 (work
in progress), November 2008. in progress), November 2008.
[ITU.G870.2008]
International Telecommunications Union, "Terms and
definitions for optical transport networks (OTN)", ITU-
T Recommendation G.870, March 2008.
[ITU.G8080.2006]
International Telecommunications Union, "Architecture for
the automatically switched optical network (ASON)", ITU-
T Recommendation G.8080, June 2006.
[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.
6.2. Informative References
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, February 2006.
[ITU.Y2611.2006] [ITU.Y2611.2006]
International Telecommunications Union, "High-level International Telecommunications Union, "High-level
architecture of future packet-based networks", ITU- architecture of future packet-based networks", ITU-
T Recommendation Y.2611, December 2006. T Recommendation Y.2611, December 2006.
[ITU.Y1401.2008] [ITU.Y1401.2008]
International Telecommunications Union, "Principles of International Telecommunications Union, "Principles of
interworking", ITU-T Recommendation Y.1401, February 2008. interworking", ITU-T Recommendation Y.1401, February 2008.
[ITU.G805.2000] [ITU.G805.2000]
International Telecommunications Union, "Generic International Telecommunications Union, "Generic
functional architecture of transport networks", ITU- functional architecture of transport networks", ITU-
T Recommendation G.805, March 2000. T Recommendation G.805, March 2000.
[ITU.G870.2008]
International Telecommunications Union, "Terms and
definitions for optical transport networks (OTN)", ITU-
T Recommendation G.870, March 2008.
[ITU.G8080.2006]
International Telecommunications Union, "Architecture for
the automatically switched optical network (ASON)", ITU-
T Recommendation G.8080, June 2006.
Authors' Addresses Authors' Addresses
Ben Niven-Jenkins (editor) Ben Niven-Jenkins (editor)
BT BT
208 Callisto House, Adastral Park 208 Callisto House, 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)
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Ottawa, Ontario K2H 8E9 Ottawa, Ontario K2H 8E9
Canada Canada
Email: betts01@nortel.com Email: betts01@nortel.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
 End of changes. 179 change blocks. 
429 lines changed or deleted 636 lines changed or added

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