draft-ietf-mpls-tp-requirements-03.txt   draft-ietf-mpls-tp-requirements-04.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 29, 2009 AT&T Expires: August 9, 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 25, 2009 February 5, 2009
MPLS-TP Requirements MPLS-TP Requirements
draft-ietf-mpls-tp-requirements-03 draft-ietf-mpls-tp-requirements-04
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 29, 2009. This Internet-Draft will expire on August 9, 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 3, line 10 skipping to change at page 3, line 10
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 RFC 2119. 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 . . . . . . . . . . . . . . . . 8 1.2. Transport network overview . . . . . . . . . . . . . . . . 8
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 9 1.3. Layer network overview . . . . . . . . . . . . . . . . . . 10
2.1. General requirements . . . . . . . . . . . . . . . . . . . 9 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 10
2.2. Layering requirements . . . . . . . . . . . . . . . . . . 11 2.1. General requirements . . . . . . . . . . . . . . . . . . . 11
2.3. Data plane requirements . . . . . . . . . . . . . . . . . 12 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 12
2.4. Control plane requirements . . . . . . . . . . . . . . . . 13 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 13
2.5. Network Management (NM) requirements . . . . . . . . . . . 14 2.4. Control plane requirements . . . . . . . . . . . . . . . . 15
2.5. Network Management (NM) requirements . . . . . . . . . . . 15
2.6. Operation, Administration and Maintenance (OAM) 2.6. Operation, Administration and Maintenance (OAM)
requirements . . . . . . . . . . . . . . . . . . . . . . . 14 requirements . . . . . . . . . . . . . . . . . . . . . . . 15
2.7. Network performance management (PM) requirements . . . . . 14 2.7. Network performance management (PM) requirements . . . . . 16
2.8. Recovery & Survivability requirements . . . . . . . . . . 14 2.8. Recovery & Survivability requirements . . . . . . . . . . 16
2.8.1. Data plane behavior requirements . . . . . . . . . . . 15 2.8.1. Data plane behavior requirements . . . . . . . . . . . 17
2.8.2. Triggers for protection, restoration, and reversion . 17 2.8.2. Triggers for protection, restoration, and reversion . 18
2.8.3. Management plane operation of protection and 2.8.3. Management plane operation of protection and
restoration . . . . . . . . . . . . . . . . . . . . . 17 restoration . . . . . . . . . . . . . . . . . . . . . 19
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 . 19
2.8.5. Topology-specific recovery mechanisms . . . . . . . . 18 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 20
2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 22 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 23
2.10. Security requirements . . . . . . . . . . . . . . . . . . 22 2.10. Security requirements . . . . . . . . . . . . . . . . . . 24
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
4. Security Considerations . . . . . . . . . . . . . . . . . . . 23 4. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Normative References . . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . . 25
6.2. Informative References . . . . . . . . . . . . . . . . . . 24 6.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
For many years, transport networks (e.g. Synchronous Optical For many years, transport networks (e.g. Synchronous Optical
Networking (SONET)/Synchronous Digital hierarchy (SDH)) have provided Networking (SONET)/Synchronous Digital hierarchy (SDH)) have provided
carriers with a high benchmark for reliability and operational carriers with a high benchmark for reliability and operational
simplicity. With the accelerating 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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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 as appropriate with other packet and network should interwork as appropriate with other packet and
transport networks (both horizontally and vertically). Vertical transport networks (both horizontally and vertically). Vertical
interworking is also known as client/server or network interworking. interworking is also known as client/server or network interworking.
Horizontal interworking is also known as peer-partition or service Horizontal interworking is also known as peer-partition or service
interworking. For more details on each type of interworking and some interworking. For more details on each type of interworking and some
of the issues that may arise (especially with horizontal of the issues that may arise (especially with horizontal
interworking) see [ITU.Y1401.2008]. interworking) see Y.1401 [ITU.Y1401.2008].
MPLS is a maturing packet technology and it is already playing an MPLS is a maturing packet technology and it is already playing an
important role in transport networks and services. However, not all important role in transport networks and services. However, not all
of MPLS's capabilities and mechanisms are needed and/or consistent of MPLS's capabilities and mechanisms are needed and/or consistent
with transport network operations. There is therefore the need to with transport network operations. There 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 existing transport networks. MPLS with the operational experience of existing transport networks.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
Although both static and dynamic configuration of MPLS-TP transport Although both static and dynamic configuration of MPLS-TP transport
paths (including Operations, Administration and Maintenance (OAM) and paths (including Operations, Administration and Maintenance (OAM) and
protection capabilities) is required by this document, it MUST be protection capabilities) is required by this document, it MUST be
possible for operators to be able to completely operate (including possible for operators to be able to completely operate (including
OAM and protection capabilities) an MPLS-TP network in the absence of OAM and protection capabilities) an MPLS-TP network in the absence of
any control plane protocols for dynamic configuration. any control plane protocols for dynamic configuration.
1.1. Terminology 1.1. Terminology
Note: Mapping between the terms in this section and ITU-T terminology Note: Mapping between the terms in this section and ITU-T terminology
will be described in the rosetta stone document [REF]. will be described in a subsequent document.
Note: The definition of segment in a GMPLS/ASON context (i.e. as Note: The definition of segment in a GMPLS/ASON context (i.e. as
defined in [RFC4397]) encompasses both segment and concatenated defined in RFC4397 [RFC4397]) encompasses both segment and
segment as defined in this document. concatenated segment as defined in this document.
Associated unidirectional path: A path that supports traffic flow in Associated bidirectional path: A path that supports traffic flow in
both directions but which is constructed from a pair of both directions but which is constructed from a pair of
unidirectional paths (one for each direction) which are associated unidirectional paths (one for each direction) which are associated
with one another at the path's ingress/egress points. The forward with one another at the path's ingress/egress points. The forward
and backward directions may not follow the same path (links and and backward directions may or may not follow the same route (links
nodes) across the network. and nodes) across the network.
Bidirectional path: A path where the forward and backward directions Bidirectional path: A path where the forward and backward directions
follow the same path (links and nodes) across the network. follow the same route (links and nodes) across the network.
Concatenated Segment: A contiguous part of an LSP or mult-segment PW Concatenated Segment: A serial-compound link connection as defined in
that comprises a set of segments in sequence. G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part
of an LSP or multi-segment PW that comprises a set of segments and
their interconnecting nodes in sequence.
Co-routed bidirectional path: A bidirectional path where the forward
and backward directions follow the same route (links and nodes)
across its layer network.
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, aggregation, survivability techniques, distributions of control
etc. Examples of such domains include IGP areas and Autonomous functionality, etc. Examples of such domains include IGP areas and
Systems. Autonomous Systems.
Layer network: A layer network as defined in G.805 [ITU.G805.2000]
provides for the transfer of client information and independent
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
layering see Appendix I of Y.2611 [ITU.Y2611.2006].
[Editors' Note: Eric Gray to provide text on what is a layer network Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A
in the context of MPLS-TP.] layer network provides for the transfer of client information and
independent operation of the client OAM. A Layer Network may be
described in a service context as follows: one layer network may
provide a (transport) service to higher client layer network and may,
in turn, be a client to a lower layer network. A layer network is a
logical construction somewhat independent of arrangement or
composition of physical network elements. A particular physical
network element may topologically belong to more than one layer
network, depending on the actions it takes on the encapsulation(s)
associated with the logical layers (e.g. the label stack), and thus
could be modeled as multiple logical elements. A layer network may
consist of zero or more sublayers. For additional explanation of how
layer networks relate to the OSI concept of layering see Appendix I
of Y.2611 [ITU.Y2611.2006].
Link: A physical or logical connection between a pair of LSRs that Link: A physical or logical connection between a pair of LSRs that
are adjacent at the (sub)layer network under consideration. A link are adjacent at the (sub)layer network under consideration. A link
may carry zero, one or more LSPs or PWs. A packet entering a link may carry zero, one or more LSPs or PWs. A packet entering a link
will emerge with the same label stack entry values. will emerge with the same label stack entry values.
Logical Ring: An MPLS-TP logical ring is constructed from a set of 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.
skipping to change at page 7, line 26 skipping to change at page 7, line 39
bidirectional MPLS-TP capable data link. A ring may also be bidirectional MPLS-TP capable data link. A ring may also be
constructed from only two LSRs where there are also exactly two constructed from only two LSRs where there are also exactly two
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. Note that G.805
[ITU.G805.2000] defines the section layer as one of the two layer
networks in a transmission media layer network. The other layer
network is the physical media layer network.
Segment: The part of an LSP that traverses a single link or the part Segment: A link connection as defined in G.805 [ITU.G805.2000]. A
of a PW that traverses a single link (i.e. that connects a pair of segment is the part of an LSP that traverses a single link or the
adjacent {S|T}-PEs). part of a PW that traverses a single link (i.e. that connects a pair
of adjacent {S|T}-PEs).
Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The
distinction between a layer network and a sublayer is that a sublayer
is not directly accessible to clients outside of its encapsulating
layer network and offers no direct transport service for a higher
layer (client) network.
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, a concatenated end-to-end monitoring (OAM). It may be a monitored segment, a
segment or any other ordered sequence of contiguous links and/or monitored concatenated segment or any other monitored ordered
segments of a transport path. sequence of contiguous hops and/or segments (and their
interconnecting nodes) 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]. In an MPLS-TP environment a transport path [ITU.G805.2000]. In an MPLS-TP environment a transport path
corresponds to an LSP or a PW. corresponds to an LSP or a PW.
Transport path layer: A layer network which provides point-to-point Transport path layer: A layer network 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.
skipping to change at page 9, line 26 skipping to change at page 10, line 5
boundary in the client layer network. Although the connectivity of boundary in the client layer network. Although the connectivity of
the client of the transport path layer may be point-to-point, point- the client of the transport path layer may be point-to-point, point-
to-multipoint or multipoint-to-multipoint, the transport path layer to-multipoint or multipoint-to-multipoint, the transport path layer
itself only provides point-to-point or point-to-multipoint transport itself only provides point-to-point or point-to-multipoint transport
paths which are used to carry the client. paths which are used to carry the client.
Quality-of-service mechanisms are required in the packet transport Quality-of-service mechanisms are required in the packet transport
network to ensure the prioritization of critical services, to network to ensure the prioritization of critical services, to
guarantee BW and to control jitter and delay. guarantee BW and to control jitter and delay.
1.3. Layer network overview
A layer network provides its clients with a transport service and the
operation of the layer network is independent of whatever client
happens to use the layer network. Information that passes between
any client to the layer network is common to all clients and is the
minimum needed to be consistent with the definition of the transport
service offered. The client layer network can be connectionless,
connection oriented packet switched, or circuit switched. The
transport service transfers a payload (individual packet payload for
connectionless networks, a sequence of packets payloads in the case
of connection oriented packet switched networks, and a deterministic
schedule of payloads in the case of circuit switched networks) such
that the client can populate the payload without affecting any
operation within the serving layer network.
The operations within a layer network that are independent of the
clients include the control of forwarding, the control of resource
reservation, the control of traffic demerging, and the OAM of the
transport service. All of these operations are internal to a layer
network. By definition, a layer network does not rely on any client
information to perform these operations and therefore all information
required to perform these operations is independent of whatever
client is using the layer network.
A layer network will have common features in order to support the
control of forwarding, resource reservation, and OAM. For example, a
layer network will have a common addressing scheme for the end points
of the transport service and a common set of transport descriptors
for the transport service. However, a client may use a different
addressing scheme or different traffic descriptors (consistent with
performance inheritance).
It is sometimes useful to independently monitor a smaller domain
within a layer network (or the transport services as the traverse
this smaller domain) but the control of forwarding or the control of
resource reservation involved retain their common elements. These
smaller monitored domains are sublayers.
It is sometimes useful to independently control forwarding within
smaller domain within a layer network but the control of resource
reservation and OAM retain their common elements. These smaller
domains are partitions of the layer network.
2. MPLS-TP Requirements 2. MPLS-TP Requirements
2.1. General requirements 2.1. General requirements
1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as 1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as
defined by the IETF. When MPLS offers multiple options in this defined by the IETF. When MPLS offers multiple options in this
respect, MPLS-TP SHOULD select the minimum sub-set (necessary and respect, MPLS-TP SHOULD select the minimum sub-set (necessary and
sufficient subset) applicable to a transport network application. sufficient subset) applicable to a transport network application.
2 Any new functionality that is defined to fulfil the requirements 2 Any new functionality that is defined to 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 It MUST be possible to construct MPLS-TP networks from equipment 4 MPLS-TP and its interfaces, both internal and external, MUST be
supplied by different vendors and to interconnect MPLS-TP sufficiently well-defined that interworking equipment supplied by
networks made wholly from equipment from different vendors. multiple vendors will be possible both within a single network,
[Editors' note: Andy Mallis/Eric Gray to refine text of this and between networks.
requirement.]
5 MPLS-TP MUST be a connection-oriented packet switching model with 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.
6 MPLS-TP MUST support traffic engineered point to point (P2P) and 6 MPLS-TP MUST support traffic engineered point to point (P2P) and
point to multipoint (P2MP) transport paths. point to multipoint (P2MP) transport paths.
7 MPLS-TP MUST support the logical separation of the control and 7 MPLS-TP MUST support the logical separation of the control and
management planes from the data plane. management planes from the data plane.
skipping to change at page 10, line 43 skipping to change at page 12, line 19
13 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.
14 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
taking recovery actions independently of the control or taking recovery actions independently of the control or
management plane used to operate the MPLS-TP layer network. That management plane used to operate the MPLS-TP layer network. That
is, the MPLS-TP data plane MUST continue to operate normally if is, the MPLS-TP data plane MUST continue to operate normally if
the management plane or control plane that configured the the management plane or control plane that configured the
transport paths fails. transport paths fails.
15 MPLS-TP SHOULD support mechanisms to avoid or minimize traffic 15 MPLS-TP MUST support mechanisms to avoid or minimize traffic
impact (e.g. packet delay, reordering and loss) during network impact (e.g. packet delay, reordering and loss) during network
reconfiguration. reconfiguration.
16 MPLS-TP MUST support transport paths through multiple homogeneous 16 MPLS-TP MUST support transport paths through multiple homogeneous
domains. domains.
17 MPLS-TP MUST NOT dictate the deployment of any particular network 17 MPLS-TP 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.
skipping to change at page 12, line 27 skipping to change at page 14, line 5
within its layer network. within its layer network.
28 MPLS-TP MUST be capable of using P2MP server (sub-)layer 28 MPLS-TP MUST be capable of using P2MP server (sub-)layer
capabilities when supporting P2MP MPLS-TP transport paths (for capabilities when supporting P2MP MPLS-TP transport paths (for
example context-specific labels [RFC5331]). example context-specific labels [RFC5331]).
29 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.
30 MPLS-TP MUST support unidirectional, associated unidirectional 30 MPLS-TP MUST support unidirectional, bidirectional and co-routed
and bidirectional point-to-point transport paths. bidirectional point-to-point transport paths.
31 The forward and backward directions of a bidirectional transport 31 The forward and backward directions of a co-routed bidirectional
path MUST follow the same links and nodes within its (sub-)layer transport path MUST follow the same links and nodes within its
network. (sub-)layer network.
32 The intermediate nodes at each (sub-)layer MUST be aware about 32 The intermediate nodes at each (sub-)layer MUST be aware about
the pairing relationship of the forward and the backward the pairing relationship of the forward and the backward
directions belonging to the same bidirectional transport path. directions belonging to the same bidirectional transport path.
33 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.
34 MPLS-TP MUST support unidirectional point-to-multipoint transport 34 MPLS-TP MUST support unidirectional point-to-multipoint transport
paths. paths.
35 MPLS-TP MUST be extensible in order to accommodate new types of 35 MPLS-TP MUST be extensible in order to accommodate new types of
client networks and services. client networks and services.
36 MPLS-TP SHOULD support mechanisms to enable the reserved 36 MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth associated with a transport path to be increased bandwidth associated with a transport path to be increased
without impacting the > existing traffic on that transport path without impacting the existing traffic on that transport path
37 MPLS-TP SHOULD support mechanisms to enable the reserved 37 MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth of a transport path to be decreased without impacting bandwidth of a transport path to be decreased without impacting
the existing traffic on that transport path, provided that the the existing traffic on that transport path, provided that the
level of existing traffic is smaller than the reserved bandwidth level of existing traffic is smaller than the reserved bandwidth
following the decrease. following the decrease.
38 MPLS-TP MUST support mechanisms which ensure the integrity of the 38 MPLS-TP MUST support mechanisms which ensure the integrity of the
transported customer's service traffic as required by its transported customer's service traffic as required by its
associated SLA. Loss of integrity may be defined as packet associated SLA. Loss of integrity may be defined as packet
corruption, re-ordering or loss during normal network conditions. corruption, re-ordering or loss during normal network conditions.
skipping to change at page 13, line 29 skipping to change at page 15, line 11
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 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 [ITU.G8080.2006]. The Optical and Transport Networks (ASON/ASTN) in G.8080
control plane for MPLS-TP MUST fit within the ASON/ASTN architecture. [ITU.G8080.2006]. The control plane for MPLS-TP MUST fit within the
ASON/ASTN architecture.
An interpretation of the ASON/ASTN control plane requirements in the An interpretation of the ASON/ASTN control plane requirements in the
context of GMPLS can be found in [RFC4139] and [RFC4258]. context of GMPLS can be found in [RFC4139] and [RFC4258].
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
connectivity patterns defined for the MPLS-TP data plane (e.g., connectivity patterns defined for the MPLS-TP data plane (e.g.,
unidirectional and bidirectional P2P, unidirectional P2MP, etc.) unidirectional and bidirectional P2P, unidirectional P2MP, etc.)
including configuration of protection functions and any including configuration of protection functions and any
associated maintenance functions. associated maintenance functions.
44 The MPLS-TP control pane MUST support the configuration and 44 The MPLS-TP control pane 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 is established or deactivation of OAM when the transport path or transport service
modified. is established or 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.
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
skipping to change at page 15, line 38 skipping to change at page 17, line 20
OTN, WDM) to avoid race conditions between the layers. OTN, WDM) to avoid race conditions between the layers.
52 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).
53 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
requirement for protection switching time in case of linear
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. 54 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 for 1+1 protection. 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.
55 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 for 1:n protection. default behavior for 1:n protection.
B. Unidirectional 1:n protection for P2MP connectivity MUST be B. Unidirectional 1:n protection for P2MP connectivity MUST be
supported. supported.
C. Unidirectional 1:n protection for P2P connectivity is NOT C. Unidirectional 1:n protection for P2P connectivity is not
REQUIRED. required.
D. The action of protection switching MUST NOT cause user data D. The action of protection switching MUST NOT cause user data
to loop. Backtracking is allowed. to loop. Backtracking is allowed.
Note: Support for extra traffic (as defined in [ITU.G870.2008]) is Note: Support for extra traffic (as defined in G.870 [ITU.G870.2008])
NOT REQUIRED in MPLS-TP. is not required in MPLS-TP.
2.8.1.2. Restoration 2.8.1.2. Restoration
56 The restoration LSP MUST be able to share resources with the LSP 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).
57 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).
skipping to change at page 20, line 5 skipping to change at page 21, line 25
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 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.
[Editors' Note: The statement above is to be confirmed at the end of
the work and may be removed if it does not hold.]
82 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.
83 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.
84 MPLS-TP recovery in a ring MUST protect unidirectional and 84 MPLS-TP recovery in a ring MUST protect unidirectional and
skipping to change at page 21, line 34 skipping to change at page 22, line 49
96 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.
97 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.
98 It MUST be possible to disable protection mechanisms on selected 98 It MUST be possible to lockout (disable) protection mechanisms on
links in a ring (depending on operator's need). selected links (spans) in a ring (depending on operator's need).
This may require lockout mechanisms to be applied to intermediate
[Editor note: This requirement was originated from ITU-T Q9/15 and nodes within a transport path.
needs further clarification. If it means that a lockout is required
for use on specific spans, then this is already covered by a general
requirement, and this requirement could be deleted or rewritten for
clarity. On the other hand, there may be another meaning in which
case the requirement needs to be rewritten.]
99 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.
100 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.
skipping to change at page 23, line 27 skipping to change at page 24, line 38
[I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]. [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework].
5. Acknowledgements 5. Acknowledgements
The authors would like to thank all members of the teams (the Joint The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in the IETF, and Working Team, the MPLS Interoperability Design Team in the IETF, and
the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and
specification of MPLS Transport Profile. specification of MPLS Transport Profile.
The authors would also like to thank Loa Andersson, Lou Berger, Italo The authors would also like to thank Loa Andersson, Lou Berger, Italo
Busi, John Drake, Adrian Farrel, Neil Harrison, Wataru Imajuku, Busi, John Drake, Adrian Farrel, Eric Gray, Neil Harrison, Huub van
Julien Meuric, Tom Nadeau, Hiroshi Ohta and Tomonori Takeda for their Helvoort, Wataru Imajuku, Julien Meuric, Tom Nadeau, Hiroshi Ohta,
George Swallow, Tomonori Takeda and Maarten Vissers for their
comments and enhancements to the text. comments and enhancements to the text.
An ad hoc discussion group consisting of Stewart Bryant, Italo Busi, An ad hoc discussion group consisting of Stewart Bryant, Italo Busi,
Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort,
Feng Huang, Harald Kullman, Han Li, Hao Long and Nurit Sprecher Feng Huang, Harald Kullman, Han Li, Hao Long and Nurit Sprecher
provided valuable input to the requirements for deployment and provided valuable input to the requirements for deployment and
survivability in ring topologies. survivability in ring topologies.
6. References 6. References
 End of changes. 35 change blocks. 
95 lines changed or deleted 156 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/