draft-ietf-mpls-tp-requirements-02.txt   draft-ietf-mpls-tp-requirements-03.txt 
Network Working Group B. Niven-Jenkins, Ed. Network 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: July 7, 2009 AT&T Expires: July 29, 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
January 3, 2009 January 25, 2009
MPLS-TP Requirements MPLS-TP Requirements
draft-ietf-mpls-tp-requirements-02 draft-ietf-mpls-tp-requirements-03
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 July 7, 2009. This Internet-Draft will expire on July 29, 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in RFC 2119.
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 . . . . . . . . . . . . . . . . 7 1.2. Transport network overview . . . . . . . . . . . . . . . . 8
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 8 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 9
2.1. General requirements . . . . . . . . . . . . . . . . . . . 9 2.1. General requirements . . . . . . . . . . . . . . . . . . . 9
2.2. Layering requirements . . . . . . . . . . . . . . . . . . 11 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 11
2.3. Data plane requirements . . . . . . . . . . . . . . . . . 11 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 12
2.4. Control plane requirements . . . . . . . . . . . . . . . . 12 2.4. Control plane requirements . . . . . . . . . . . . . . . . 13
2.5. Network Management (NM) requirements . . . . . . . . . . . 13 2.5. Network Management (NM) requirements . . . . . . . . . . . 14
2.6. Operation, Administration and Maintenance (OAM) 2.6. Operation, Administration and Maintenance (OAM)
requirements . . . . . . . . . . . . . . . . . . . . . . . 14 requirements . . . . . . . . . . . . . . . . . . . . . . . 14
2.7. Network performance management (PM) requirements . . . . . 14 2.7. Network performance management (PM) requirements . . . . . 14
2.8. Recovery & Survivability requirements . . . . . . . . . . 14 2.8. Recovery & Survivability requirements . . . . . . . . . . 14
2.8.1. Data plane behavior requirements . . . . . . . . . . . 15 2.8.1. Data plane behavior requirements . . . . . . . . . . . 15
2.8.2. Triggers for protection, restoration, and reversion . 17 2.8.2. Triggers for protection, restoration, and reversion . 17
2.8.3. Management plane operation of protection and 2.8.3. Management plane operation of protection and
restoration . . . . . . . . . . . . . . . . . . . . . 17 restoration . . . . . . . . . . . . . . . . . . . . . 17
2.8.4. Control plane and in-band OAM operation of recovery . 18 2.8.4. Control plane and in-band OAM operation of recovery . 18
2.8.5. Topology-specific recovery mechanisms . . . . . . . . 18 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 18
2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 22 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 22
2.10. Security requirements . . . . . . . . . . . . . . . . . . 22 2.10. Security requirements . . . . . . . . . . . . . . . . . . 22
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
4. Security Considerations . . . . . . . . . . . . . . . . . . . 23 4. Security Considerations . . . . . . . . . . . . . . . . . . . 23
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . . 23
6.2. Informative References . . . . . . . . . . . . . . . . . . 24 6.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
For many years, Synchronous Optical Networking (SONET)/Synchronous For many years, transport networks (e.g. Synchronous Optical
Digital hierarchy (SDH) has provided carriers with a high benchmark Networking (SONET)/Synchronous Digital hierarchy (SDH)) have provided
for reliability and operational simplicity. With the accelerating carriers with a high benchmark for reliability and operational
growth and penetration of: 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.
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. The need to increase their revenue while remaining
competitive forces operators to look for the lowest network Total competitive forces operators to look for the lowest network Total
Cost of Ownership (TCO). Investment in equipment and facilities Cost of Ownership (TCO). Investment in equipment and facilities
(Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX) (Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX)
should be minimized. should be minimized.
Carriers are considering migrating or evolving to packet transport Carriers are considering migrating or evolving to packet transport
networks in order to reduce their costs and to improve their ability networks in order to reduce their costs and to improve their ability
to support services with guaranteed Service Level Agreements (SLAs). to support services with guaranteed Service Level Agreements (SLAs).
For carriers it is important that migrating from SONET/SDH to packet For carriers it is important that migrating from their existing
transport networks should not involve dramatic changes in network transport networks to packet transport networks should not involve
operation, should not necessitate extensive retraining, and should dramatic changes in network operation, should not necessitate
not require major changes to existing work practices. The aim is to extensive retraining, and should not require major changes to
preserve the look-and-feel to which carriers have become accustomed existing work practices. The aim is to preserve the look-and-feel to
in deploying their SONET/SDH networks, while providing common, multi- which carriers have become accustomed in deploying their transport
layer operations, resiliency, control and management for packet, networks, while providing common, multi-layer operations, resiliency,
circuit and lambda transport networks. control and management for packet, circuit and lambda transport
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 (Operations Support System (OSS)
based) or dynamic (control plane) provisioning of deterministic, based) or dynamic (control plane) 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 Carriers will still need to cope with legacy networks (which are
composed of many layers and technologies), thus the packet transport composed of many layers and technologies), thus the packet transport
network should interwork with other packet and transport networks network should interwork as appropriate with other packet and
(both horizontally and vertically). Vertical interworking is also transport networks (both horizontally and vertically). Vertical
known as client/server or network interworking. Horizontal interworking is also known as client/server or network interworking.
interworking is also known as peer-partition or service interworking. Horizontal interworking is also known as peer-partition or service
For more details on each type of interworking and some of the issues interworking. For more details on each type of interworking and some
that may arise (especially with horizontal interworking) see of the issues that may arise (especially with horizontal
[ITU.Y1401.2008]. interworking) see [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 is therefore the need to
define an MPLS Transport Profile (MPLS-TP) in order to support the define an MPLS Transport Profile (MPLS-TP) in order to support the
capabilities and functionalities needed for packet transport network capabilities and functionalities needed for packet transport network
services and operations through combining the packet experience of services and operations through combining the packet experience of
MPLS with the operational experience of SONET/SDH. MPLS with the operational experience of existing transport networks.
MPLS-TP will enable the migration of SONET/SDH 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 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
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used as
described in [RFC2119] and are to be interpreted as instructions to
the protocol designers producing solutions that satisfy the
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-IETF effort to include an
MPLS Transport Profile within the IETF MPLS architecture to support MPLS Transport Profile within the IETF MPLS architecture to support
the capabilities and functionalities of a packet transport network as the capabilities and functionalities of a packet transport network as
defined by ITU-T. 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 architecture
as defined by IETF and packet transport networks as defined by ITU-T. as defined by IETF and packet transport networks as defined by ITU-T.
The requirements of MPLS-TP are provided below. The relevant The requirements of MPLS-TP are provided below. The relevant
functions of MPLS are included in MPLS-TP, except where explicitly functions of MPLS are included in MPLS-TP, except where explicitly
excluded. 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
will be described in the rosetta stone document [REF].
Note: The definition of segment in a GMPLS/ASON context (i.e. as
defined in [RFC4397]) encompasses both segment and concatenated
segment as defined in this document.
Associated unidirectional path: A path that supports traffic flow in
both directions but which is constructed from a pair of
unidirectional paths (one for each direction) which are associated
with one another at the path's ingress/egress points. The forward
and backward directions may not follow the same path (links and
nodes) across the network.
Bidirectional path: A path where the forward and backward directions
follow the same path (links and nodes) across the network.
Concatenated Segment: A contiguous part of an LSP or mult-segment PW
that comprises a set of segments in sequence.
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,
survivability techniques, distributions of control functionality, survivability techniques, distributions of control functionality,
etc. Examples of such domains include IGP areas and Autonomous etc. Examples of such domains include IGP areas and Autonomous
Systems. Systems.
Layer network: A layer network as defined in G.805 [ITU.G805.2000] Layer network: A layer network as defined in G.805 [ITU.G805.2000]
provides for the transfer of client information and independent provides for the transfer of client information and independent
operations (OAM) of the client OAM. For an explanation of how a operations (OAM) of the client OAM. For an explanation of how a
layer network as described by G.805 relates to the OSI concept of layer network as described by G.805 relates to the OSI concept of
layering see Appendix I of Y.2611 [ITU.Y2611.2006]. layering see Appendix I of Y.2611 [ITU.Y2611.2006].
Link: A link as defined in G.805 [ITU.G805.2000] is used to describe [Editors' Note: Eric Gray to provide text on what is a layer network
a fixed relationship between two ports within a layer network. A in the context of MPLS-TP.]
link is not necessarily a physical link but can also be supported by
a transport path in the server layer (e.g. SONET/SDH, OTN or Link: A physical or logical connection between a pair of LSRs that
MPLS-TP). 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
will emerge with the same label stack entry values.
Logical Ring: An MPLS-TP logical ring is constructed from a set of Logical Ring: An MPLS-TP logical ring is constructed from a set of
LSRs and logical data links (such as MPLS-TP LSP tunnels or MSPL-TP LSRs and logical data links (such as MPLS-TP LSP tunnels or MSPL-TP
pseudowires) and physical data links that form a ring topology. 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 Physical Ring: An MPLS-TP physical ring is constructed from a set of
LSRs and physical data links that form a ring topology. LSRs and physical data links that form a ring topology.
skipping to change at page 6, line 50 skipping to change at page 7, line 28
links. Rings may be connected to other LSRs to form a larger links. Rings may be connected to other LSRs to form a larger
network. Traffic originating or terminating outside the ring may be network. Traffic originating or terminating outside the ring may be
carried over the ring. Client network nodes (such as CEs) may be carried over the ring. Client network nodes (such as CEs) may be
connected directly to an LSR in the ring. connected directly to an LSR in the ring.
Section: A section is a server layer (which may be MPLS-TP or a Section: A section is a server layer (which may be MPLS-TP or a
different technology) which provides for encapsulation and OAM of a different technology) which provides for encapsulation and OAM of a
MPLS-TP transport path client layer. A section layer may provide for MPLS-TP transport path client layer. A section layer may provide for
aggregation of multiple MPLS-TP clients. aggregation of multiple MPLS-TP clients.
Segment: A segment is a single resource or a set of cross-connected Segment: The part of an LSP that traverses a single link or the part
resources that constitutes part of a path. A segment may be a single of a PW that traverses a single link (i.e. that connects a pair of
link (hop) within a path, a series of adjacent links (hops) within a adjacent {S|T}-PEs).
path, or the entire end-to-end-path.
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 segment or any other end-to-end monitoring (OAM). It may be a segment, a concatenated
ordered sequence of contiguous links and/or segments of a transport segment or any other ordered sequence of contiguous links and/or
path. segments of a transport path.
Transport path: A network connection as defined in G.805 Transport path: A network connection as defined in G.805
[ITU.G805.2000]. A Transport path corresponds to an MPLS-TP LSP or [ITU.G805.2000]. In an MPLS-TP environment a transport path
to an MPLS-TP LSP and its associated PW or PWs (Single Segment or corresponds to an LSP or a PW.
Multi-Segment).
Transport path layer: A layer network which provides point-to-point Transport path layer: A layer network which provides point-to-point
or point-to-multipoint transport paths which are used to carry a or point-to-multipoint transport paths which are 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 for
independent OAM (of the client OAM) in the transport of the clients. independent OAM (of the client OAM) in the transport of the 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 which provides sections
(two-port point-to-point connections) to carry the aggregate of (two-port point-to-point connections) to carry the aggregate of
network transport path or network service layers on various physical network transport path or network service layers on various physical
media. media.
Unidirectional path: A path that supports traffic flow in only one
direction.
1.2. Transport network overview 1.2. Transport network overview
The connection (or transport path) service is the basic service The connection (or transport path) service is the basic service
provided by a transport network. The purpose of a transport network provided by a transport network. The purpose of a transport network
is to carry its clients (i.e. the stream of client PDUs or client is to carry its clients (i.e. the stream of client PDUs or client
bits) between endpoints in the network (typically over several bits) between endpoints in the network (typically over several
intermediate nodes). These endpoints may be service switching points intermediate nodes). These endpoints may be service switching points
or service terminating points. The connection services offered to or service terminating points. The connection services offered to
customers are aggregated into large transport paths with long-holding customers are aggregated into large transport paths with long-holding
times and independent OAM (of the client OAM), which contribute to times and independent OAM (of the client OAM), which contribute to
skipping to change at page 9, line 21 skipping to change at page 9, line 44
2 Any new functionality that is defined to fulfil the requirements 2 Any new functionality that is defined to fulfil 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, without
a gateway function, with existing IETF MPLS [RFC3031] and IETF a gateway function, with existing IETF MPLS [RFC3031] and IETF
PWE3 [RFC3985] control and data planes where appropriate. PWE3 [RFC3985] control and data planes where appropriate.
4 MPLS-TP MUST be a connection-oriented packet switching model with 4 It MUST be possible to construct MPLS-TP networks from equipment
supplied by different vendors and to interconnect MPLS-TP
networks made wholly from equipment from different vendors.
[Editors' note: Andy Mallis/Eric Gray to refine text of this
requirement.]
5 MPLS-TP MUST be a connection-oriented packet switching model with
traffic engineering capabilities that allow deterministic control traffic engineering capabilities that allow deterministic control
of the use of network resources. of the use of network resources.
5 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.
6 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.
7 MPLS-TP MUST allow the physical separation of the control and 8 MPLS-TP MUST allow the physical separation of the control and
management planes from the data plane. management planes from the data plane.
8 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. an OSS, i.e. via the management plane.
9 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 manageable in a way that is independent of technology) SHOULD be operable in a way that is
coherent with the way the equivalent mechanisms are managed in similar to the way the equivalent mechanisms are operated in
other transport networks. other transport networks.
10 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.
11 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).
12 A solution MUST be provided to support dynamic provisioning of 13 A solution MUST be provided to support dynamic provisioning of
MPLS-TP transport paths via a control plane. MPLS-TP transport paths via a control plane.
13 The MPLS-TP data plane MUST be capable of forwarding data and 14 The MPLS-TP data plane MUST be capable of forwarding data and
taken recovery actions independently of the control or management taking recovery actions independently of the control or
plane used to operate the MPLS-TP layer network. That is, the management plane used to operate the MPLS-TP layer network. That
MPLS-TP data plane MUST continue to operate normally if the is, the MPLS-TP data plane MUST continue to operate normally if
management plane or control plane that configured the transport the management plane or control plane that configured the
paths fails. transport paths fails.
14 MPLS-TP SHOULD support mechanisms to avoid or minimize traffic 15 MPLS-TP SHOULD 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.
15 MPLS-TP MUST support transport paths through multiple homogeneous 16 MPLS-TP MUST support transport paths through multiple homogeneous
domains. domains.
16 MPLS-TP MUST NOT dictate the deployment of any particular network 17 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.
D. It MUST be possible to construct rings from equipment 18 MPLS-TP MUST be able to scale at least as well as existing
supplied by different vendors and to interconnect rings made transport technologies with growing and increasingly complex
wholly from equipment from different vendors. [Editor's network topologies as well as with increasing bandwidth demands,
note: This requirement comes from work provided by ITU-T number of customers, and number of services.
Q9/15. Unless someone can provide a reason why this would
not be the case we should remove this requirement. It is
equivalent to saying that all correct implementations of
MPLS-TP MUST interwork.]
17 MPLS-TP MUST be able to scale gracefully with growing and
increasingly complex network topologies as well as with
increasing bandwidth demands, number of customers, and number of
services.
18 MPLS-TP SHOULD support mechanisms to safeguard against the 19 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
19 An MPLS-TP network MUST be able to support one or more client 20 A generic and extensible solution MUST be provided to support the
network layers, and MUST be able to use one or more server transport of one or more client layer networks (e.g. MPLS-TP,
network layers. Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
20 A solution MUST be provided to support the transport of MPLS-TP
transport paths over MPLS-TP (MPLS-TP as a client of MPLS-TP)
21 A generic and extensible solution MUST be provided to support the
transport of any client layer network (e.g. Ethernet, ATM, FR,
etc.) over an MPLS-TP layer network.
22 A solution MUST be provided to support the transport of MPLS-TP 21 A solution MUST be provided to support the transport of MPLS-TP
transport paths over any server layer network (such as Ethernet, transport paths over one or more server layer networks (such as
SONET/SDH, OTN, etc.). MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). Requirements for
bandwidth management within a server layer network are outside
the scope of this document.
23 In an environment where an MPLS-TP layer network is supporting a 22 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 network, and the MPLS-TP layer network is supported by a
server layer network then operation of the MPLS-TP layer network server layer network then operation of the MPLS-TP layer network
MUST be possible without any dependencies on the server or client MUST be possible without any dependencies on the server or client
network. network.
24 It MUST be possible to operate the layers of a multi-layer 23 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 Different administrative groups may be responsible for the same layer
network or different layer networks. network or different layer networks.
25 It MUST be possible to hide MPLS-TP layer network addressing and 24 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 layers.
2.3. Data plane requirements 2.3. Data plane requirements
26 The identification of each transport path within its aggregate 25 The identification of each transport path within its aggregate
MUST be supported. MUST be supported.
27 A label in a particular link MUST uniquely identify the transport 26 A label in a particular link MUST uniquely identify the transport
path within that link. path within that link.
28 A transport path's source MUST be identifiable at its destination 27 A transport path's source MUST be identifiable at its destination
within its layer network. within its layer network.
29 MPLS-TP MUST support MPLS labels that are assigned by the 28 MPLS-TP MUST be capable of using P2MP server (sub-)layer
downstream (with respect to data flow) node per [RFC3031] and capabilities when supporting P2MP MPLS-TP transport paths (for
[RFC3473] and MAY support context-specific MPLS labels as defined example context-specific labels [RFC5331]).
in [RFC5331].
30 It MUST be possible to operate and configure the MPLS-TP data 29 It MUST be possible to operate and configure the MPLS-TP data
(transport) plane without any IP forwarding capability in the (transport) plane without any IP forwarding capability in the
MPLS-TP data plane. MPLS-TP data plane.
31 MPLS-TP MUST support both unidirectional and bidirectional point- 30 MPLS-TP MUST support unidirectional, associated unidirectional
to-point transport paths. and bidirectional point-to-point transport paths.
32 An MPLS-TP network MUST require the forward and backward 31 The forward and backward directions of a bidirectional transport
directions of a bidirectional transport path to follow the same path MUST follow the same links and nodes within its (sub-)layer
path at each layer. network.
33 The intermediate nodes at each layer MUST be aware about the 32 The intermediate nodes at each (sub-)layer MUST be aware about
pairing relationship of the forward and the backward directions the pairing relationship of the forward and the backward
belonging to the same bi-directional transport path. directions belonging to the same bidirectional transport path.
34 MPLS-TP MAY support transport paths with asymmetric bandwidth 33 MPLS-TP MAY support transport paths with asymmetric bandwidth
requirements, i.e. the amount of reserved bandwidth differs requirements, i.e. the amount of reserved bandwidth differs
between the forward and backward directions. between the forward and backward directions.
35 MPLS-TP MUST support unidirectional point-to-multipoint transport 34 MPLS-TP MUST support unidirectional point-to-multipoint transport
paths. paths.
36 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 networks and services.
37 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
37 MPLS-TP SHOULD support mechanisms to enable the reserved
38 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.
39 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. transported customer's service traffic as required by its
associated SLA. Loss of integrity may be defined as packet
corruption, re-ordering or loss during normal network conditions.
39 MPLS-TP MUST support mechanisms to detect when loss of integrity
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 MPLS-TP when a
control plane is deployed. control plane is deployed.
The requirements for ASON signalling and routing and the requirements The ITU-T has defined an architecture for Automatically Switched
for multi-region and multi-layer networks as specified in [RFC4139], Optical and Transport Networks (ASON/ASTN) in [ITU.G8080.2006]. The
[RFC4258] and [RFC5212] respectively apply to MPLS-TP. control plane for MPLS-TP MUST fit within the ASON/ASTN architecture.
[ITU-T Comment: the MPLS-TP control plane should meet the
requirements for ASON architecture (G.8080, ...) unless explicitly
excluded as well as the additional MPLS-TP specific requirements
explicitly added.]
[Editors' Note: Following other comments on above references, need to An interpretation of the ASON/ASTN control plane requirements in the
produce consolidated text that references correct documents & context of GMPLS can be found in [RFC4139] and [RFC4258].
requirements.]
Additionally: Additionally:
41 The MPLS-TP control pane SHOULD support control plane topology 41 The MPLS-TP control pane SHOULD support control plane topology
and data plane topology independence. and data plane topology independence.
42 The MPLS-TP control plane MUST be able to be operated independent 42 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 43 The MPLS-TP control plane MUST support establishing all the
skipping to change at page 13, line 43 skipping to change at page 14, line 16
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 is established or deactivation of OAM when the transport path is established or
modified. modified.
45 An MPLS-TP control plane MUST support operation of the recovery 45 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 46 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.
47 An MPLS-TP control plane SHOULD provide a common control
mechanism for architecturally similar operations.
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.vigoureux-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.vigoureux-mpls-tp-oam-requirements]. [I-D.ietf-mpls-tp-oam-requirements].
2.8. Recovery & Survivability requirements 2.8. Recovery & Survivability 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 The requirements in this section use the recovery terminology defined
in RFC 4427 [RFC4427]. in RFC 4427 [RFC4427].
48 MPLS-TP MUST provide protection and restoration mechanisms. 47 MPLS-TP MUST provide protection and restoration mechanisms.
A. Recovery techniques used for P2P and P2MP SHOULD be identical A. 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.
49 MPLS-TP recovery mechanisms MUST be applicable at various levels 48 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, path segment
and end-to-end path, and pseudowire segment, and end-to-end and end-to-end path, and pseudowire segment, and end-to-end
pseudowire recovery. pseudowire recovery.
50 MPLS-TP recovery paths MUST meet the SLA protection objectives of 49 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 include bandwidth and QoS.
51 The recovery mechanisms MUST all be applicable to any topology. 50 The recovery mechanisms MUST all be applicable to any topology.
52 The recovery mechanisms MUST operate in synergy with (including 51 The recovery mechanisms MUST operate in synergy with (including
coordination of timing) the recovery mechanisms present in any coordination of timing) the recovery mechanisms present in any
underlying server transport network (for example, Ethernet, SDH, underlying server transport network (for example, Ethernet, SDH,
OTN, WDM) to avoid race conditions between the layers. OTN, WDM) to avoid race conditions between the layers.
53 MPLS-TP protection mechanisms MUST support priority logic to 52 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).
54 MPLS-TP recovery and reversion mechanisms MUST prevent frequent 53 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.
[Editors' Note: ITU-T Q9/15 and Q12/15 will provide by <TBD> a [Editors' Note: ITU-T Q9/15 and Q12/15 will provide by <TBD> a
requirement for protection switching time in case of linear requirement for protection switching time in case of linear
protection (e.g. within 50 ms) together with a reference network.] protection (e.g. within 50 ms) together with a reference network.]
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.
55 MPLS-TP MUST support 1+1 Protection.
A. MPLS-TP 1+1 support MUST include bidirectional protection A. MPLS-TP 1+1 support MUST include bidirectional protection
switching for P2P connectivity, and this SHOULD be the switching for P2P connectivity, and this SHOULD be the
default behavior. default behavior for 1+1 protection.
B. Unidirectional 1+1 protection for P2MP connectivity MUST be B. Unidirectional 1+1 protection for P2MP connectivity MUST be
supported. supported.
C. Unidirectional 1+1 protection for P2P connectivity is NOT C. Unidirectional 1+1 protection for P2P connectivity is NOT
REQUIRED. REQUIRED.
56 MPLS-TP MUST support 1:n Protection (including 1:1 protection). 55 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 support MUST include bidirectional protection
switching for P2P connectivity, and this SHOULD be the switching for P2P connectivity, and this SHOULD be the
default behavior. 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.
57 MPLS-TP SHOULD support extra traffic carried on 1:n protection Note: Support for extra traffic (as defined in [ITU.G870.2008]) is
resources when protection is not in use. NOT REQUIRED in MPLS-TP.
2.8.1.2. Restoration 2.8.1.2. Restoration
58 The restoration LSP MUST be able to share resources with the LSP 56 The restoration LSP MUST be able to share resources with the LSP
being replaced (sometimes known as soft rerouting). being replaced (sometimes known as soft rerouting).
59 Restoration priority MUST be supported so that an implementation 57 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 58 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.
61 Recovery mechanisms MUST be bidirectional.
2.8.1.3. Sharing of protection resources 2.8.1.3. Sharing of protection resources
62 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh 59 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh
restoration. restoration.
63 MPLS-TP MUST support the sharing of protection bandwidth by 60 MPLS-TP MUST support the sharing of protection bandwidth by
allowing best effort traffic. allowing best effort traffic.
64 MPLS-TP MUST support the definition of shared protection groups 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.
65 MPLS-TP MUST support sharing of protection resources such that 62 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
66 MPLS-TP protection mechanisms MUST support revertive and non- 63 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.
67 MPLS-TP restoration mechanisms MAY support revertive and non- 64 MPLS-TP restoration mechanisms MAY 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:
68 MPLS-TP MUST support physical layer fault indication triggers. 65 MPLS-TP MUST support physical layer fault indication triggers.
69 MPLS-TP MUST support OAM-based triggers. 66 MPLS-TP MUST support OAM-based triggers.
70 MPLS-TP MUST support management plane triggers (e.g., forced 67 MPLS-TP MUST support management plane triggers (e.g., forced
switch, etc.). switch, etc.).
71 There MUST be a mechanism to allow administrative recovery 68 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.
72 Where a control plane is present, MPLS-TP SHOULD support control 69 Where a control plane is present, MPLS-TP SHOULD support control
plane triggers. plane triggers.
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.
73 It MUST be possible to configure of protection paths and 70 It MUST be possible to configure of protection paths and
protection-to-working path relationships (sometimes known as protection-to-working path relationships (sometimes known as
protection groups). protection groups).
74 There MUST be support for pre-calculation of recovery paths. 71 There MUST be support for pre-calculation of recovery paths.
75 There MUST be support for pre-provisioning of recovery paths.
76 The following administrative control MUST be supported:
A. lockout
B. forced switchover
C. manual switchover 72 There MUST be support for pre-provisioning of recovery paths.
D. simulated fault 73 The external controls as defined in [RFC4427] MUST be supported.
77 There MUST be support for the configuration of timers used for 74 There MUST be support for the configuration of timers used for
recovery operation. recovery operation.
78 Restoration resources MAY be pre-planned and selected a priori, 75 Restoration resources MAY be pre-planned and selected a priori,
or computed after failure occurrence. or computed after failure occurrence.
79 When preemption is supported for recovery purposes, it MUST be 76 When preemption is supported for recovery purposes, it MUST be
possible for the operator to configure it. possible for the operator to configure it.
80 The management plane MUST provide indications of protection 77 The management plane MUST provide indications of protection
events and triggers. events and triggers.
81 The management plane MUST allow the current protection status of 78 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
82 The MPLS-TP control plane (which is not mandatory in an MPLS-TP 79 The MPLS-TP control plane (which is not mandatory in an MPLS-TP
implementation) MUST support: implementation) MUST support:
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)
83 In-band OAM MAY be used for: 80 In-band OAM MAY be used for:
A. signaling of administrative control A. signaling of administrative control
B. protection state coordination B. protection state coordination
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
84 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 Note that topology-specific recovery mechanisms are subject to the
development of requirements using the normal IETF process. development of requirements using the normal IETF process.
2.8.5.1. Ring protection 2.8.5.1. Ring protection
skipping to change at page 19, line 32 skipping to change at page 19, line 48
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 management plane transactions during a
maintenance operation (e.g., ring upgrade) - less than are maintenance operation (e.g., ring upgrade) - less than are
required by other recovery mechanisms. required by other recovery mechanisms.
It may be observed that this list is fully compatible with the It may be observed that the requirements in this section are fully
generic requirements expressed above, and that no requirements that compatible with the generic requirements expressed above, and that no
are specific to ring topologies have been identified. [Editors' requirements that are specific to ring topologies have been
Note: This statement is to be confirmed at the end of the work and identified.
may be removed if it does not hold.]
In the list of requirements below, those requirements that are [Editors' Note: The statement above is to be confirmed at the end of
generic are marked "[G]"; those that are Ring-specific are marked the work and may be removed if it does not hold.]
"[R]". [Editors' Note: Still need to mark up the requirements below
as [R] and [G].]
85 MPLS-TP MUST include recovery mechanisms that operate in any 82 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.
86 When a network is constructed from interconnected rings, MPLS-TP 83 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.
87 MPLS-TP recovery in a ring MUST protect unidirectional and 84 MPLS-TP recovery in a ring MUST protect unidirectional and
bidirectional P2P transport paths. bidirectional P2P transport paths.
88 MPLS-TP recovery in a ring MUST protect unidirectional P2MP 85 MPLS-TP recovery in a ring MUST protect unidirectional P2MP
transport paths. transport paths.
89 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching 86 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. This is with a 16 nodes ring with less than 1200 km of fiber.
NOT REQUIRED when extra traffic is present.
[Editor note: the opinion of some people in the T103 room in Geneva
is that support for extra traffic is NOT REQUIRED in ring topologies.
It may be further NOT REQUIRED in any topology. This is for further
discussion especially with respect to G.8131.]
90 The protection switching time in a ring MUST be independent of 87 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.
91 Recovery actions in a ring MUST be data plane functions 88 Recovery actions in a ring MUST be data plane functions triggered
triggered by different elements of control. The triggers are by different elements of control. The triggers are configured by
configured by management or control planes and are subject to management or control planes and are subject to configurable
configurable policy. policy.
92 The configuration and operation of recovery mechanisms in a ring 89 The configuration and operation of recovery mechanisms in a ring
MUST scale well with: MUST scale well with:
A. the number of transport paths (must be better than linear A. the number of transport paths (must be better than linear
scaling) scaling)
B. the number of nodes on the ring (must be at least as good as B. the number of nodes on the ring (must be at least as good as
linear scaling) linear scaling)
C. the number of ring interconnects (must be at least as good C. the number of ring interconnects (must be at least as good as
as linear scaling) linear scaling)
93 MPLS-TP recovery in ring topologies MAY support multiple 90 MPLS-TP recovery in ring topologies MAY support multiple failures
failures without reconfiguring the protection actions. without reconfiguring the protection actions.
94 Recovery techniques used in a ring MUST NOT prevent the ring 91 Recovery techniques used in a ring MUST NOT prevent the ring from
from being connected to a general MPLS-TP network in any being connected to a general MPLS-TP network in any arbitrary
arbitrary way, and MUST NOT prevent the operation of recovery way, and MUST NOT prevent the operation of recovery techniques in
techniques in the rest of the network. the rest of the network.
95 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally 92 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally
applicable in physical and logical rings. applicable in physical and logical rings.
96 Recovery techniques in a ring SHOULD be identical to those in 93 Recovery techniques in a ring SHOULD be identical to those in
general networks to simplify implementation. However, this MUST general networks to simplify implementation. However, this MUST
NOT override any other requirement. NOT override any other requirement.
97 Recovery techniques in logical and physical rings SHOULD be 94 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.
98 The default recovery scheme in a ring MUST be bidirectional 95 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.
99 The recovery mechanism in a ring MUST support revertive 96 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.
100 The recovery mechanisms in a ring MUST support ways to allow 97 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.
101 It MUST be possible to disable protection mechanisms on selected 98 It MUST be possible to disable protection mechanisms on selected
links in a ring (depending on operator's need). links in a ring (depending on operator's need).
[Editor note: This requirement was originated from ITU-T Q9/15 and [Editor note: This requirement was originated from ITU-T Q9/15 and
needs further clarification. If it means that a lockout is required needs further clarification. If it means that a lockout is required
for use on specific spans, then this is already covered by a general for use on specific spans, then this is already covered by a general
requirement, and this requirement could be deleted or rewritten for requirement, and this requirement could be deleted or rewritten for
clarity. On the other hand, there may be another meaning in which clarity. On the other hand, there may be another meaning in which
case the requirement needs to be rewritten.] case the requirement needs to be rewritten.]
102 MPLS-TP recovery mechanisms in a ring MUST include a mechanism 99 MPLS-TP recovery mechanisms in a ring MUST include a mechanism
to allow an implementation to handle coexisting requests (i.e., to allow an implementation to handle coexisting requests (i.e.,
multiple requests - not necessarily arriving simultaneously) for multiple requests - not necessarily arriving simultaneously) for
protection switching based on priority. protection switching based on priority.
103 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a 100 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.
104 MPLS-TP MUST support the sharing of protection bandwidth in a 101 MPLS-TP MUST support the sharing of protection bandwidth in a
ring by allowing best effort traffic. ring by allowing best effort traffic.
105 MPLS-TP MUST support sharing of ring protection resources such 102 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.
106 MUST support the coordination of triggers caused by events at 103 MUST support the coordination of triggers caused by events at
different locations in a ring. Note that this is the ring different locations in a ring. Note that this is the ring
equivalent of the definition of shared protection groups. 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:
107 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.
108 Prioritization of critical services. 105 Prioritization of critical services.
109 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.
110 Support of services, which are sensitive to jitter and delay. 107 Support of services, which are sensitive to jitter and delay.
111 Guarantee of fair access, within a particular class, to shared 108 Guarantee of fair access, within a particular class, to shared
resources. resources.
112 Guaranteed resources for in-band control and management plane 109 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.
113 Carriers are provided with the capability to efficiently support 110 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.
[Editors' Note: Should we refer here to the requirements specified in
RFC 2702?]
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.
skipping to change at page 23, line 42 skipping to change at page 23, line 46
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] [I-D.gray-mpls-tp-nm-req]
Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network
Management Requirements", draft-gray-mpls-tp-nm-req-01 Management Requirements", draft-gray-mpls-tp-nm-req-02
(work in progress), July 2008. (work in progress), January 2009.
[I-D.vigoureux-mpls-tp-oam-requirements] [I-D.ietf-mpls-tp-oam-requirements]
Vigoureux, M., Ward, D., and M. Betts, "Requirements for Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks", OAM in MPLS Transport Networks",
draft-vigoureux-mpls-tp-oam-requirements-00 (work in draft-ietf-mpls-tp-oam-requirements-00 (work in progress),
progress), July 2008. November 2008.
6.2. Informative References 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.
[RFC3473] Berger, L., "Multiprotocol Label Switching Architecture",
RFC 3473, January 2003.
[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.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
July 2008.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space",
RFC 5331, August 2008. RFC 5331, August 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-03 (work draft-ietf-mpls-mpls-and-gmpls-security-framework-04 (work
in progress), July 2008. in progress), November 2008.
[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
 End of changes. 141 change blocks. 
260 lines changed or deleted 260 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/