draft-ietf-mpls-tp-requirements-05.txt   draft-ietf-mpls-tp-requirements-06.txt 
MPLS 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: Standards Track D. Brungard, Ed.
Expires: September 11, 2009 AT&T Expires: October 6, 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
March 10, 2009 April 4, 2009
MPLS-TP Requirements MPLS-TP Requirements
draft-ietf-mpls-tp-requirements-05 draft-ietf-mpls-tp-requirements-06
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 September 11, 2009. This Internet-Draft will expire on October 6, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6 1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6
1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8 1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8
1.2. Transport network overview . . . . . . . . . . . . . . . . 11 1.2. Transport network overview . . . . . . . . . . . . . . . . 11
1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12 1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13
2.1. General requirements . . . . . . . . . . . . . . . . . . . 13 2.1. General requirements . . . . . . . . . . . . . . . . . . . 13
2.2. Layering requirements . . . . . . . . . . . . . . . . . . 15 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 16
2.3. Data plane requirements . . . . . . . . . . . . . . . . . 16 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 17
2.4. Control plane requirements . . . . . . . . . . . . . . . . 18 2.4. Control plane requirements . . . . . . . . . . . . . . . . 18
2.5. Network Management (NM) requirements . . . . . . . . . . . 19 2.5. Network Management (NM) requirements . . . . . . . . . . . 20
2.6. Operation, Administration and Maintenance (OAM) 2.6. Operation, Administration and Maintenance (OAM)
requirements . . . . . . . . . . . . . . . . . . . . . . . 19 requirements . . . . . . . . . . . . . . . . . . . . . . . 20
2.7. Network performance management (PM) requirements . . . . . 19 2.7. Network performance management (PM) requirements . . . . . 20
2.8. Recovery requirements . . . . . . . . . . . . . . . . . . 19 2.8. Recovery requirements . . . . . . . . . . . . . . . . . . 20
2.8.1. Data plane behavior requirements . . . . . . . . . . . 20 2.8.1. Data plane behavior requirements . . . . . . . . . . . 21
2.8.1.1. Protection . . . . . . . . . . . . . . . . . . . . 20 2.8.1.1. Protection . . . . . . . . . . . . . . . . . . . . 21
2.8.1.2. Restoration . . . . . . . . . . . . . . . . . . . 21 2.8.1.2. Restoration . . . . . . . . . . . . . . . . . . . 22
2.8.1.3. Sharing of protection resources . . . . . . . . . 21 2.8.1.3. Sharing of protection resources . . . . . . . . . 22
2.8.1.4. Reversion . . . . . . . . . . . . . . . . . . . . 22 2.8.1.4. Reversion . . . . . . . . . . . . . . . . . . . . 23
2.8.2. Triggers for protection, restoration, and reversion . 22 2.8.2. Triggers for protection, restoration, and reversion . 23
2.8.3. Management plane operation of protection and 2.8.3. Management plane operation of protection and
restoration . . . . . . . . . . . . . . . . . . . . . 22 restoration . . . . . . . . . . . . . . . . . . . . . 23
2.8.4. Control plane and in-band OAM operation of recovery . 23 2.8.4. Control plane and in-band OAM operation of recovery . 24
2.8.5. Topology-specific recovery mechanisms . . . . . . . . 24 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 25
2.8.5.1. Ring protection . . . . . . . . . . . . . . . . . 24 2.8.5.1. Ring protection . . . . . . . . . . . . . . . . . 25
2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 27 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 28
2.10. Security requirements . . . . . . . . . . . . . . . . . . 27 2.10. Security requirements . . . . . . . . . . . . . . . . . . 28
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
4. Security Considerations . . . . . . . . . . . . . . . . . . . 28 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1. Normative References . . . . . . . . . . . . . . . . . . . 28 6.1. Normative References . . . . . . . . . . . . . . . . . . . 29
6.2. Informative References . . . . . . . . . . . . . . . . . . 30 6.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Bandwidth demand continues to grow worldwide, stimulated by the Bandwidth demand continues to grow worldwide, stimulated by the
accelerating growth and penetration of new packet based services and accelerating growth and penetration of new packet based services and
multimedia applications: multimedia applications:
o Packet-based services such as Ethernet, Voice over IP (VoIP), o Packet-based services such as Ethernet, Voice over IP (VoIP),
Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP
Television (IPTV), Radio Access Network (RAN) backhauling, etc., Television (IPTV), Radio Access Network (RAN) backhauling, etc.,
o Applications with various bandwidth and QoS requirements. o Applications with various bandwidth and Quality of Service (QoS)
requirements.
This growth in demand has resulted in dramatic increases in access This growth in demand has resulted in dramatic increases in access
rates that are, in turn, driving dramatic increases in metro and core rates that are, in turn, driving dramatic increases in metro and core
network bandwidth requirements. network bandwidth requirements.
Over the past two decades, the evolving optical transport Over the past two decades, the evolving optical transport
infrastructure (Synchronous Optical Networking (SONET)/Synchronous infrastructure (Synchronous Optical Networking (SONET)/Synchronous
Digital Hierarchy (SDH), Optical Transport Networ (OTN)) has provided Digital Hierarchy (SDH), Optical Transport Network (OTN)) has
carriers with a high benchmark for reliability and operational provided carriers with a high benchmark for reliability and
simplicity. operational simplicity.
With the movement towards packet based services, the transport With the movement towards packet based services, the transport
network has to evolve to encompass the provision of packet aware network has to evolve to encompass the provision of packet aware
capabilities while enabling carriers to leverage their installed, as capabilities while enabling carriers to leverage their installed, as
well as planned, transport infrastructure investments. well as planned, transport infrastructure investments.
Carriers are in need of technologies capable of efficiently Carriers are in need of technologies capable of efficiently
supporting packet based services and applications on their transport supporting packet based services and applications on their transport
networks with guaranteed Service Level Agreements (SLAs). The need networks with guaranteed Service Level Agreements (SLAs). The need
to increase their revenue while remaining competitive forces to increase their revenue while remaining competitive forces
skipping to change at page 5, line 8 skipping to change at page 5, line 9
Furthermore for carriers it is important that operation of such Furthermore for carriers it is important that operation of such
packet transport networks should preserve the look-and-feel to which packet transport networks should preserve the look-and-feel to which
carriers have become accustomed in deploying their optical transport carriers have become accustomed in deploying their optical transport
networks, while providing common, multi-layer operations, resiliency, networks, while providing common, multi-layer operations, resiliency,
control and multi-technology management. control and multi-technology management.
Transport carriers require control and deterministic usage of network Transport carriers require control and deterministic usage of network
resources. They need end-to-end control to engineer network paths resources. They need end-to-end control to engineer network paths
and to efficiently utilize network resources. They require and to efficiently utilize network resources. They require
capabilities to support static (management plane based based) or capabilities to support static (management plane based) or dynamic
dynamic (control plane based) provisioning of deterministic, (control plane based) provisioning of deterministic, protected and
protected and secured services and their associated resources. secured services and their associated resources.
It is also important to ensure smooth interworking of the packet It is also important to ensure smooth interworking of the packet
transport network with other existing/legacy packet networks, and transport network with other existing/legacy packet networks, and
provide mappings to enable packet transport carriage over a variety provide mappings to enable packet transport carriage over a variety
of transport network infrastructures. The latter has been termed of transport network infrastructures. The latter has been termed
vertical interworking, and is also known as client/server or network vertical interworking, and is also known as client/server or network
interworking. The former has been termed horizontal interworking, interworking. The former has been termed horizontal interworking,
and is also known as peer-partition or service interworking. For and is also known as peer-partition or service interworking. For
more details on interworking and some of the issues that may arise more details on interworking and some of the issues that may arise
(especially with horizontal interworking) seeG.805 [ITU.G805.2000] (especially with horizontal interworking) seeG.805 [ITU.G805.2000]
and Y.1401 [ITU.Y1401.2008]. and Y.1401 [ITU.Y1401.2008].
MPLS is a maturing packet technology and it is already playing an Multi-Protocol Label Switching (MPLS) is a maturing packet technology
important role in transport networks and services. However, not all and it is already playing an important role in transport networks and
of MPLS's capabilities and mechanisms are needed and/or consistent services. However, not all of MPLS's capabilities and mechanisms are
with transport network operations. There are also transport needed and/or consistent with transport network operations. There
technology characteristics that are not currently reflected in MPLS. are also transport technology characteristics that are not currently
There is therefore the need to define an MPLS Transport Profile reflected in MPLS. There is therefore the need to define an MPLS
(MPLS-TP) that supports the capabilities and functionalities needed Transport Profile (MPLS-TP) that supports the capabilities and
for packet transport network services and operations through functionalities needed for packet transport network services and
combining the packet experience of MPLS with the operational operations through combining the packet experience of MPLS with the
experience and practices of existing transport networks. 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 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
skipping to change at page 7, line 16 skipping to change at page 7, line 18
IPTV: IP Television IPTV: IP Television
L2: Layer 2 L2: Layer 2
L3: Layer 3 L3: Layer 3
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
ME: Maintenance Entity MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
OAM: Operations, Adminstration and Maintenance OAM: Operations, Administration and Maintenance
OPEX: Operational Expenditure OPEX: Operational Expenditure
OSI: Open Systems Interconnection OSI: Open Systems Interconnection
OTN: Optical Transport Network OTN: Optical Transport Network
P2MP: Point to Multi-Point P2MP: Point to Multi-Point
P2P: Point to Point P2P: Point to Point
skipping to change at page 13, line 6 skipping to change at page 13, line 10
The operations within a layer network that are independent of its The operations within a layer network that are independent of its
clients include the control of forwarding, the control of resource clients include the control of forwarding, the control of resource
reservation, the control of traffic demerging, and the OAM and reservation, the control of traffic demerging, and the OAM and
recovery of the transport service. All of these operations are recovery of the transport service. All of these operations are
internal to a layer network. By definition, a layer network does not internal to a layer network. By definition, a layer network does not
rely on any client information to perform these operations and rely on any client information to perform these operations and
therefore all information required to perform these operations is therefore all information required to perform these operations is
independent of whatever client is using the layer network. independent of whatever client is using the layer network.
A layer network will have common features in order to support the A layer network will have consistent features in order to support the
control of forwarding, resource reservation, OAM and recovery. For control of forwarding, resource reservation, OAM and recovery. For
example, a layer network will have a common addressing scheme for the example, a layer network will have a common addressing scheme for the
end points of the transport service and a common set of transport end points of the transport service and a common set of transport
descriptors for the transport service. However, a client may use a descriptors for the transport service. However, a client may use a
different addressing scheme or different traffic descriptors different addressing scheme or different traffic descriptors
(consistent with performance inheritance). (consistent with performance inheritance).
It is sometimes useful to independently monitor a smaller domain It is sometimes useful to independently monitor a smaller domain
within a layer network (or the transport services that traverse this within a layer network (or the transport services that traverse this
smaller domain) but the control of forwarding or the control of smaller domain) but the control of forwarding or the control of
skipping to change at page 14, line 49 skipping to change at page 15, line 8
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 defined to support dynamic provisioning and 13 A solution MUST be defined to support dynamic provisioning and
restoration of MPLS-TP transport paths via a control plane. restoration of MPLS-TP transport paths via a control plane.
14 The MPLS-TP data plane MUST be capable of 14 MPLS-TP MUST support the co-existence of statically and
dynamically provisioned/managed MPLS-TP transport paths within
the same layer network or domain.
15 The MPLS-TP data plane MUST be capable of
A. forwarding data independent of the control or management A. forwarding data independent of the control or management
plane used to configure and operate the MPLS-TP layer plane used to configure and operate the MPLS-TP layer
network. network.
B. taking recovery actions independent of the control plane used B. taking recovery actions independent of the control plane used
to configure the MPLS-TP layer network. If the control plane to configure the MPLS-TP layer network. If the control plane
does not restart, the data plane connections MUST be held and does not restart, the data plane connections MUST be held and
NOT time out. NOT time out.
15 MPLS-TP MUST support mechanisms to avoid or minimize traffic 16 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 17 MPLS-TP MUST support transport paths through multiple homogeneous
domains. domains.
17 MPLS-TP SHOULD support transport paths through multiple non- 18 MPLS-TP SHOULD support transport paths through multiple non-
homogeneous domains. homogeneous domains.
18 MPLS-TP MUST NOT dictate the deployment of any particular network 19 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.
19 MPLS-TP MUST be able to scale at least as well as existing 20 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.
20 MPLS-TP SHOULD support mechanisms to safeguard against the 21 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
21 A generic and extensible solution MUST be provided to support the 22 A generic and extensible solution MUST be provided to support the
transport of one or more client layer networks (e.g. MPLS-TP, transport of one or more client layer networks (e.g. MPLS-TP,
IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network. IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
22 A generic and extensible solution MUST be provided to support the 23 A generic and extensible solution MUST be provided to support the
transport of MPLS-TP transport paths over one or more server transport of MPLS-TP transport paths over one or more server
layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).
Requirements for bandwidth management within a server layer Requirements for bandwidth management within a server layer
network are outside the scope of this document. network are outside the scope of this document.
23 In an environment where an MPLS-TP layer network is supporting a 24 In an environment where an MPLS-TP layer network is supporting a
client layer network, and the MPLS-TP layer network is supported client layer network, and the MPLS-TP layer network is supported
by a server layer network then operation of the MPLS-TP layer by a server layer network then operation of the MPLS-TP layer
network MUST be possible without any dependencies on the server network MUST be possible without any dependencies on the server
or client layer network. or client layer network.
A. The server layer MUST guarantee that the traffic loading A. The server layer MUST guarantee that the traffic loading
imposed by other clients does not cause the transport service imposed by other clients does not cause the transport service
provided to the MPLS-TP layer to fall bellow the agreed provided to the MPLS-TP layer to fall bellow the agreed
level. Mechanisms to achieve this are outside the scope of level. Mechanisms to achieve this are outside the scope of
these requirements. these requirements.
24 A solution MUST be provided to support the transport of a client B. It MUST be possible to isolate the control and management
planes of the MPLS-TP layer network from the control and
management planes of the client and server layer networks.
25 A solution MUST be provided to support the transport of a client
MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer
network. network.
A. The level of co-ordination required between the client and A. The level of co-ordination required between the client and
server MPLS(-TP) layer networks MUST be minimised (preferably server MPLS(-TP) layer networks MUST be minimized (preferably
no co-ordination will be required). no co-ordination will be required).
B. The MPLS(-TP) server layer network MUST be capable of B. The MPLS(-TP) server layer network MUST be capable of
transporting the complete set of packets generated by the transporting the complete set of packets generated by the
client MPLS(-TP) layer network, which may contain packets client MPLS(-TP) layer network, which may contain packets
that are not MPLS packets (e.g. IP or CNLS packets used by that are not MPLS packets (e.g. IP or CNLS packets used by
the control/management plane of the client MPLS(-TP) layer the control/management plane of the client MPLS(-TP) layer
network). network).
25 It MUST be possible to operate the layers of a multi-layer 26 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
requirements. Different administrative groups may be responsible for requirements. Different administrative groups may be responsible for
the same layer network or different layer networks. the same layer network or different layer networks.
26 It MUST be possible to hide MPLS-TP layer network addressing and 27 It MUST be possible to hide MPLS-TP layer network addressing and
other information (e.g. topology) from client layer networks. other information (e.g. topology) from client layer networks.
However, it SHOULD be possible, at the option of the operator, to However, it SHOULD be possible, at the option of the operator, to
leak a limited amount of summarized information (such as SRLGs or leak a limited amount of summarized information (such as SRLGs or
reachability) between layers. reachability) between layers.
2.3. Data plane requirements 2.3. Data plane requirements
27 It MUST be possible for the end points of an MPLS-TP transport
28 It MUST be possible for the end points of an MPLS-TP transport
path that is carrying an aggregate of client transport paths to path that is carrying an aggregate of client transport paths to
be be able to decompose the aggregate transport path into its be able to decompose the aggregate transport path into its
component client transport paths. component client transport paths.
28 A transport path on a link MUST be uniquely identifiable by a 29 A transport path on a link MUST be uniquely identifiable by a
single label on that link. single label on that link.
29 A transport path's source MUST be identifiable at its destination 30 A transport path's source MUST be identifiable at its destination
within its layer network. within its layer network in coordination with the management
plane or control plane.
30 MPLS-TP MUST be capable of using P2MP server (sub-)layer 31 MPLS-TP MUST be capable of using P2MP server (sub-)layer
capabilities as well as P2P server (sub-)layer capabilities when capabilities as well as P2P server (sub-)layer capabilities when
supporting P2MP MPLS-TP transport paths. supporting P2MP MPLS-TP transport paths.
31 MPLS-TP MUST support unidirectional, co-routed bidirectional and 32 MPLS-TP MUST support unidirectional, co-routed bidirectional and
associated bidirectional point-to-point transport paths. associated bidirectional point-to-point transport paths.
32 The intermediate nodes at each (sub-)layer MUST be aware about 33 The end points of a co-routed bidirectional transport path MUST
the pairing relationship of the forward and the backward be aware of the pairing relationship of the forward and reverse
directions belonging to the same co-routed bidirectional paths used to support the bidirectional service.
34 The intermediate nodes (including MEPs, MIPs and other internal
functions as appropriate) of a co-routed bidirectional transport
path at each (sub-)layer MUST be aware of the pairing
relationship of the forward and the backward directions of that
transport path. transport path.
33 MPLS-TP MUST support bidirectional transport paths with 35 The end points of an associated bidirectional transport path MUST
be aware of the pairing relationship of the forward and reverse
paths used to support the bidirectional service.
36 The intermediate nodes (including MEPs, MIPs and other internal
functions as appropriate) of an associated bidirectional
transport path at each (sub-)layer SHOULD NOT be aware of the
pairing relationship of the forward and the backward directions
of that transport path.
37 MPLS-TP MUST support bidirectional transport paths with
asymmetric bandwidth requirements, i.e. the amount of reserved asymmetric bandwidth requirements, i.e. the amount of reserved
bandwidth differs between the forward and backward directions. bandwidth differs between the forward and backward directions.
34 MPLS-TP MUST support unidirectional point-to-multipoint transport 38 MPLS-TP MUST support unidirectional point-to-multipoint transport
paths. paths.
35 MPLS-TP MUST be extensible in order to accommodate new types of 39 MPLS-TP MUST be extensible in order to accommodate new types of
client layer networks and services. client layer networks and services.
36 MPLS-TP SHOULD support mechanisms to enable the reserved 40 MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth associated with a transport path to be increased bandwidth associated with a transport path to be increased
without impacting the existing traffic on that transport path without impacting the existing traffic on that transport path
provided enough resources are available. provided enough resources are available.
37 MPLS-TP SHOULD support mechanisms to enable the reserved 41 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 42 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
corruption, re-ordering or loss during normal network conditions. corruption, re-ordering or loss during normal network conditions.
39 MPLS-TP MUST support mechanisms to detect when loss of integrity 43 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 44 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 an MPLS-TP This section defines the requirements that apply to an MPLS-TP
control plane. Note that it MUST be possible to operate an MPLS-TP control plane. Note that it MUST be possible to operate an MPLS-TP
network without using a control plane. network without using a control plane.
The ITU-T has defined an architecture for Automatically Switched The ITU-T has defined an architecture for Automatically Switched
Optical and Transport Networks (ASON/ASTN) in G.8080 [ITU.G8080.2006] Optical and Transport Networks (ASON/ASTN) in G.8080 [ITU.G8080.2006]
and G.8080 Amd1 [ITU.G8080.2008]. The control plane for MPLS-TP MUST and G.8080 Amd1 [ITU.G8080.2008]. The control plane for MPLS-TP MUST
fit within the ASON/ASTN architecture. fit within the ASON/ASTN architecture.
An interpretation of the ASON/ASTN signaling and routing requirements An interpretation of the ASON/ASTN signaling and routing requirements
in the 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 It MUST be possible to operate and configure the MPLS-TP data 45 It MUST be possible to operate and configure the MPLS-TP data
plane without any IP forwarding capability in the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data
plane. plane.
42 The MPLS-TP control pane MUST support control plane topology and 46 The MPLS-TP control pane MUST support control plane topology and
data plane topology independence. As a consequence a failure of data plane topology independence. As a consequence a failure of
the control plane does not imply that there has also been a the control plane does not imply that there has also been a
failure of the data plane. failure of the data plane.
43 The MPLS-TP control plane MUST be able to be operated independent 47 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.
44 MPLS-TP SHOULD define a solution to support an integrated control 48 MPLS-TP SHOULD define a solution to support an integrated control
plane encompassing MPLS-TP together with its server and client plane encompassing MPLS-TP together with its server and client
layer networks when these layer networks belong to the same layer networks when these layer networks belong to the same
administrative domain. administrative domain.
45 The MPLS-TP control plane MUST support establishing all the 49 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.
46 The MPLS-TP control plane MUST support the configuration and 50 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.
47 An MPLS-TP control plane MUST support operation of the recovery 51 An MPLS-TP control plane MUST support operation of the recovery
functions described in Section 2.8. functions described in Section 2.8.
48 An MPLS-TP control plane MUST scale gracefully to support a large 52 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 53 If a control plane is used for MPLS-TP, the control plane's
graceful restart capabilities, if any, MUST be supported. graceful restart capabilities, if any, MUST be supported.
54 An MPLS-TP control plane MUST provide a mechanism for dynamic
ownership transfer of the control of MPLS-TP transport paths from
the management plane to the control plane and vice versa. The
number of reconfigurations required in the data plane MUST be
minimized (preferably no data plane reconfiguration will be
required).
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.ietf-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
skipping to change at page 19, line 46 skipping to change at page 20, line 39
2.8. Recovery 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.
50 MPLS-TP MUST provide protection and restoration mechanisms. 55 MPLS-TP MUST provide protection and restoration mechanisms.
A. MPLS-TP recovery techniques SHOULD be identical (or as A. MPLS-TP recovery techniques SHOULD be identical (or as
similar as possible) to those already used in existing similar as possible) to those already used in existing
transport networks to simplify implementation and operations. transport networks to simplify implementation and operations.
However, this MUST NOT override any other requirement. However, this MUST NOT override any other requirement.
B. Recovery techniques used for P2P and P2MP SHOULD be identical B. Recovery techniques used for P2P and P2MP SHOULD be identical
to simplify implementation and operation. However, this MUST to simplify implementation and operation. However, this MUST
NOT override any other requirement. NOT override any other requirement.
51 MPLS-TP recovery mechanisms MUST be applicable at various levels 56 MPLS-TP recovery mechanisms MUST be applicable at various levels
throughout the network including support for link, transport throughout the network including support for link, transport
path, segment, concatenated segment and end to end recovery. path, segment, concatenated segment and end to end recovery.
52 MPLS-TP recovery paths MUST meet the SLA protection objectives of 57 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 support objectives for bandwidth and QoS. path, and SHOULD support objectives for bandwidth and QoS.
D. Recovery MUST meet SLA requirements over multiple domains. D. Recovery MUST meet SLA requirements over multiple domains.
53 The recovery mechanisms SHOULD be applicable to any topology. 58 The recovery mechanisms SHOULD be applicable to any topology.
54 The recovery mechanisms MUST support the means to operate in 59 The recovery mechanisms MUST support the means to operate in
synergy with (including coordination of timing) the recovery synergy with (including coordination of timing) the recovery
mechanisms present in any client or server transport networks mechanisms present in any client or server transport networks
(for example, Ethernet, SDH, OTN, WDM) to avoid race conditions (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions
between the layers. between the layers.
55 MPLS-TP recovery and reversion mechanisms MUST prevent frequent 60 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
56 MPLS-TP MUST support 1+1 protection. Note: Only nodes that are aware of the pairing relationship between
the forward and backward directions of an associated bidirectional
transport path can be used as end points to protect all or part of
that transport path.
61 MPLS-TP MUST support 1+1 protection.
A. Bidirectional 1+1 protection for P2P connectivity MUST be A. Bidirectional 1+1 protection for P2P connectivity MUST be
supported. supported.
B. Unidirectional 1+1 protection for P2P connectivity MUST be B. Unidirectional 1+1 protection for P2P connectivity MUST be
supported. supported.
C. Unidirectional 1+1 protection for P2MP connectivity MUST be C. Unidirectional 1+1 protection for P2MP connectivity MUST be
supported. supported.
57 MPLS-TP MUST support 1:n protection (including 1:1 protection). 62 MPLS-TP MUST support 1:n protection (including 1:1 protection).
A. MPLS-TP 1:n protection 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 and MAY be omitted from the MPLS-TP specifications.
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 [RFC4427]) is not Note: Support for extra traffic (as defined in [RFC4427]) is not
required in MPLS-TP. required in MPLS-TP and MAY be omitted from the MPLS-TP
specifications.
2.8.1.2. Restoration 2.8.1.2. Restoration
58 The restoration transport path MUST be able to share resources 63 The restoration transport path MUST be able to share resources
with the transport path being replaced (sometimes known as soft with the transport path being replaced (sometimes known as soft
rerouting). rerouting).
59 Restoration priority MUST be supported so that an implementation 64 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).
60 Preemption priority MUST be supported to allow restoration to 65 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
61 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh 66 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh
restoration. restoration.
62 MPLS-TP MUST support the definition of shared protection groups 67 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.
63 MPLS-TP MUST support sharing of protection resources such that 68 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
64 MPLS-TP protection mechanisms MUST support revertive and non- 69 MPLS-TP protection mechanisms MUST support revertive and non-
revertive behavior. Reversion MUST be the default behavior. revertive behavior.
65 MPLS-TP restoration mechanisms MUST support revertive and non- 70 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:
66 MPLS-TP MUST support physical layer fault indication triggers. 71 MPLS-TP MUST support physical layer fault indication triggers.
67 MPLS-TP MUST support OAM-based triggers. 72 MPLS-TP MUST support OAM-based triggers.
68 MPLS-TP MUST support management plane triggers (e.g., forced 73 MPLS-TP MUST support management plane triggers (e.g., forced
switch, etc.). switch, etc.).
69 There MUST be a mechanism to allow administrative recovery 74 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.
70 Where a control plane is present, MPLS-TP SHOULD support control 75 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 76 MPLS-TP protection mechanisms MUST support priority logic to
negotiate and accommodate coexisting requests (i.e., multiple negotiate and accommodate coexisting requests (i.e., multiple
requests) for protection switching (e.g., administrative requests requests) for protection switching (e.g., administrative requests
and requests due to link/node failures). and requests due to link/node failures).
2.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.
72 It MUST be possible to configure protection paths and protection- 77 It MUST be possible to configure protection paths and protection-
to-working path relationships (sometimes known as protection to-working path relationships (sometimes known as protection
groups). groups).
73 There MUST be support for pre-calculation of recovery paths. 78 There MUST be support for pre-calculation of recovery paths.
74 There MUST be support for pre-provisioning of recovery paths. 79 There MUST be support for pre-provisioning of recovery paths.
75 The external controls as defined in [RFC4427] MUST be supported. 80 The external controls as defined in [RFC4427] MUST be supported.
A. External controls overruled by higher priority requests A. External controls overruled by higher priority requests
(e.g., administrative requests and requests due to link/node (e.g., administrative requests and requests due to link/node
failures) or unable to be signaled to the remote end (e.g. failures) or unable to be signaled to the remote end (e.g.
because of a protection state coordination fail) MUST be because of a protection state coordination fail) MUST be
dropped. dropped.
76 There MUST be support for the configuration of timers used for 81 There MUST be support for the configuration of timers used for
recovery operation. recovery operation.
77 Restoration resources MAY be pre-planned and selected a priori, 82 Restoration resources MAY be pre-planned and selected a priori,
or computed after failure occurrence. or computed after failure occurrence.
78 When preemption is supported for restoration purposes, it MUST be 83 When preemption is supported for restoration purposes, it MUST be
possible for the operator to configure it. possible for the operator to configure it.
79 The management plane MUST provide indications of protection 84 The management plane MUST provide indications of protection
events and triggers. events and triggers.
80 The management plane MUST allow the current protection status of 85 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
81 The MPLS-TP control plane (which is not mandatory in an MPLS-TP 86 The MPLS-TP control plane (which is not mandatory in an MPLS-TP
implementation) MUST be capable of supporting: implementation) MUST be capable of supporting:
A. establishment and maintenance of all recovery entities and A. establishment and maintenance of all recovery entities and
functions functions
B. signaling of administrative control B. signaling of administrative control
C. protection state coordination (PSC). Since control plane C. protection state coordination (PSC). Since control plane
network topology is independent from the data plane network network topology is independent from the data plane network
topology, the PSC supported by the MPLS-TP control plane MAY topology, the PSC supported by the MPLS-TP control plane MAY
run on resources different than the data plane resources run on resources different than the data plane resources
handled within the recovery mechanism (e.g. backup). handled within the recovery mechanism (e.g. backup).
82 In-band OAM MUST be capable of supporting: 87 In-band OAM MUST be capable of supporting:
A. signaling of administrative control A. signaling of administrative control
B. protection state coordination (PSC). Since in-band OAM tools B. protection state coordination (PSC). Since in-band OAM tools
share the data plane with the carried transport service, in share the data plane with the carried transport service, in
order to optimize the usage of network resources, the PSC order to optimize the usage of network resources, the PSC
supported by in-band OAM MUST run on protection resources. supported by in-band OAM MUST run on protection resources.
2.8.5. Topology-specific recovery mechanisms 2.8.5. Topology-specific recovery mechanisms
83 MPLS-TP MAY support recovery mechanisms that are optimized for 88 MPLS-TP MAY support recovery mechanisms that are optimized for
specific network topologies. These mechanisms MUST be specific network topologies. These mechanisms MUST be
interoperable with the mechanisms defined for arbitrary topology interoperable with the mechanisms defined for arbitrary topology
(mesh) networks to enable protection of end-to-end transport (mesh) networks to enable protection of end-to-end transport
paths. paths.
2.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
skipping to change at page 24, line 50 skipping to change at page 26, line 6
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 control and management plane transactions d. Minimize the amount of control and management plane transactions
during a maintenance operation (e.g., ring upgrade) - less than during a maintenance operation (e.g., ring upgrade) - less than
are required by other recovery mechanisms. are required by other recovery mechanisms.
e. When a control plane is supported, minimize the impact on e. When a control plane is supported, minimize the impact on
signalling and routing information exchange during protection - signaling and routing information exchange during protection -
less than are required by other recovery mechanisms. 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.
84 MPLS-TP MUST include recovery mechanisms that operate in any 89 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.
85 When a network is constructed from interconnected rings, MPLS-TP 90 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.
86 MPLS-TP recovery in a ring MUST protect unidirectional and 91 MPLS-TP recovery in a ring MUST protect unidirectional and
bidirectional P2P transport paths. bidirectional P2P transport paths.
87 MPLS-TP recovery in a ring MUST protect unidirectional P2MP 92 MPLS-TP recovery in a ring MUST protect unidirectional P2MP
transport paths. transport paths.
88 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching 93 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
with a 16 nodes ring with less than 1200 km of fiber. network with a 16 nodes ring with less than 1200 km of fiber.
89 The protection switching time in a ring MUST be independent of 94 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.
90 Recovery actions in a ring MUST be data plane functions triggered 95 Recovery actions in a ring MUST be data plane functions
by different elements of control. The triggers are configured by triggered by different elements of control. The triggers are
management or control planes and are subject to configurable configured by management or control planes and are subject to
policy. configurable policy.
91 The configuration and operation of recovery mechanisms in a ring 96 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
linear scaling) as linear scaling)
92 Recovery techniques used in a ring MUST NOT prevent the ring from 97 Recovery techniques used in a ring MUST NOT prevent the ring
being connected to a general MPLS-TP network in any arbitrary from being connected to a general MPLS-TP network in any
way, and MUST NOT prevent the operation of recovery techniques in arbitrary way, and MUST NOT prevent the operation of recovery
the rest of the network. techniques in the rest of the network.
93 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally 98 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally
applicable in physical and logical rings. applicable in physical and logical rings.
94 Recovery techniques in a ring SHOULD be identical (or as similar 99 Recovery techniques in a ring SHOULD be identical (or as similar
as possible) to those in general transport networks to simplify as possible) to those in general transport networks to simplify
implementation and operations. However, this MUST NOT override implementation and operations. However, this MUST NOT override
any other requirement. any other requirement.
95 Recovery techniques in logical and physical rings SHOULD be 100 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.
96 The default recovery scheme in a ring MUST be bidirectional 101 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.
97 The recovery mechanism in a ring MUST support revertive 102 The recovery mechanism in a ring MUST support revertive
switching, which MUST be the default behaviour. This allows switching, which MUST be the default behavior. This allows
optimization of the use of the ring resources, and restores the optimization of the use of the ring resources, and restores the
preferred quality conditions for normal traffic (e.g., delay) preferred quality conditions for normal traffic (e.g., delay)
when the recovery mechanism is no longer needed. when the recovery mechanism is no longer needed.
98 The recovery mechanisms in a ring MUST support ways to allow 103 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.
99 It MUST be possible to lockout (disable) protection mechanisms on 104 It MUST be possible to lockout (disable) protection mechanisms
selected links (spans) in a ring (depending on operator's need). on selected links (spans) in a ring (depending on operator's
This may require lockout mechanisms to be applied to intermediate need). This may require lockout mechanisms to be applied to
nodes within a transport path. intermediate nodes within a transport path.
100 MPLS-TP recovery mechanisms in a ring: 105 MPLS-TP recovery mechanisms in a ring:
A. MUST include a mechanism to allow an implementation to A. MUST include a mechanism to allow an implementation to
handle (including the coordination of) coexisting requests handle (including the coordination of) coexisting requests
or triggers (i.e., multiple requests - not necessarily or triggers (i.e., multiple requests - not necessarily
arriving simultaneously and located anywhere in the ring) arriving simultaneously and located anywhere in the ring)
for protection switching based on priority. Note that such for protection switching based on priority. Note that such
coordiantion is the ring equivalent of the definition of coordination is the ring equivalent of the definition of
shared protection groups. shared protection groups.
B. MAY support multiple failures without reconfiguring the B. MAY support multiple failures without reconfiguring the
protection actions. protection actions.
101 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a 106 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.
102 MPLS-TP MUST support the sharing of protection bandwidth in a 107 MPLS-TP MUST support the sharing of protection bandwidth in a
ring by allowing best effort traffic. ring by allowing best effort traffic.
103 MPLS-TP MUST support sharing of ring protection resources such 108 MPLS-TP MUST support sharing of ring protection resources such
that protection paths that are known not to be required that protection paths that are known not to be required
concurrently can share the same resources. concurrently can share the same resources.
2.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 109 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 Enabling the provisioning and the guarantee of Service Level 110 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.
106 Support of services, which are sensitive to jitter and delay. 111 Support of services, which are sensitive to jitter and delay.
107 Guarantee of fair access, within a particular class, to shared 112 Guarantee of fair access, within a particular class, to shared
resources. resources.
108 Guaranteed resources for in-band control and management plane 113 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.
109 Carriers are provided with the capability to efficiently support 114 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.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
skipping to change at page 28, line 27 skipping to change at page 29, line 27
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, Dieter Beller, The authors would also like to thank Loa Andersson, Dieter Beller,
Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria
Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Huub van Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Huub van
Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy
Malis, Alan McGuire, Julien Meuric, Tom Nadeau, Hiroshi Ohta, Tom Malis, Alan McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi
Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo Tancevski, Ohta, Tom Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo
Tomonori Takeda, Yuji Tochio, Eve Varma and Maarten Vissers for their Tancevski, Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve
comments and enhancements to the text. Varma and Maarten Vissers for their 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.
[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.
Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical
Network (ASON)", RFC 4139, July 2005.
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol
Label Switching (GMPLS) Routing for the Automatically
Switched Optical Network (ASON)", RFC 4258, November 2005.
[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.
[I-D.ietf-mpls-mpls-and-gmpls-security-framework]
Fang, L. and M. Behringer, "Security Framework for MPLS
and GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework-05 (work
in progress), November 2008.
[I-D.ietf-pwe3-ms-pw-arch] [I-D.ietf-pwe3-ms-pw-arch]
Bocci, M. and S. Bryant, "Requirements for OAM in MPLS Bocci, M. and S. Bryant, "Requirements for OAM in MPLS
Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work
in progress), September 2008. in progress), September 2008.
[I-D.gray-mpls-tp-nm-req] [ITU.G805.2000]
Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network International Telecommunications Union, "Generic
Management Requirements", draft-gray-mpls-tp-nm-req-03 functional architecture of transport networks", ITU-
(work in progress), January 2009. T Recommendation G.805, March 2000.
[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]
Fang, L. and M. Behringer, "Security Framework for MPLS
and GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework-04 (work
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] [ITU.G8080.2006]
International Telecommunications Union, "Architecture for International Telecommunications Union, "Architecture for
the automatically switched optical network (ASON)", ITU- the automatically switched optical network (ASON)", ITU-
T Recommendation G.8080, June 2006. T Recommendation G.8080, June 2006.
[ITU.G8080.2008] [ITU.G8080.2008]
International Telecommunications Union, "Architecture for International Telecommunications Union, "Architecture for
the automatically switched optical network (ASON) the automatically switched optical network (ASON)
Amendment 1", ITU-T Recommendation G.8080 Amendment 1, Amendment 1", ITU-T Recommendation G.8080 Amendment 1,
March 2008. March 2008.
6.2. Informative References 6.2. Informative References
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical
Network (ASON)", RFC 4139, July 2005.
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol
Label Switching (GMPLS) Routing for the Automatically
Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of the Switching (GMPLS) Terminology within the Context of the
ITU-T's Automatically Switched Optical Network (ASON) ITU-T's Automatically Switched Optical Network (ASON)
Architecture", RFC 4397, February 2006. Architecture", RFC 4397, February 2006.
[ITU.Y2611.2006] [I-D.ietf-mpls-tp-nm-req]
International Telecommunications Union, "High-level Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network
architecture of future packet-based networks", ITU- Management Requirements", draft-ietf-mpls-tp-nm-req-00
T Recommendation Y.2611, December 2006. (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.
[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.Y2611.2006]
International Telecommunications Union, "Generic International Telecommunications Union, "High-level
functional architecture of transport networks", ITU- architecture of future packet-based networks", ITU-
T Recommendation G.805, March 2000. T Recommendation Y.2611, December 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
 End of changes. 129 change blocks. 
214 lines changed or deleted 250 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/