draft-ietf-mpls-tp-requirements-00.txt   draft-ietf-mpls-tp-requirements-01.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: May 24, 2009 AT&T Expires: June 15, 2009 AT&T
M. Betts, Ed. M. Betts, Ed.
Nortel Networks Nortel Networks
N. Sprecher N. Sprecher
Nokia Siemens Networks Nokia Siemens Networks
November 20, 2008 S. Ueno
NTT
December 12, 2008
MPLS-TP Requirements MPLS-TP Requirements
draft-ietf-mpls-tp-requirements-00 draft-ietf-mpls-tp-requirements-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 39 skipping to change at page 1, line 41
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 May 24, 2009. This Internet-Draft will expire on June 15, 2009.
Abstract Abstract
This document specifies the requirements for a MPLS Transport Profile This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). This document is a product of a joint International (MPLS-TP). This document is a product of a joint International
Telecommunications Union (ITU)-IETF effort to include a MPLS Telecommunications Union (ITU)-IETF effort to include an MPLS
Transport Profile within the IETF MPLS architecture to support the Transport Profile within the IETF MPLS architecture to support the
capabilities and functionalities of a packet transport network as capabilities and functionalities of a packet transport network as
defined by International Telecommunications Union - defined by International Telecommunications Union -
Telecommunications Standardization Sector (ITU-T). Telecommunications Standardization Sector (ITU-T).
This work is based on two sources of requirements, MPLS architecture This work is based on two sources of requirements; MPLS 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 expressed in this document are for the behavior of
the protocol mechanisms and procedures that constitute building
blocks out of which the MPLS transport profile is constructed. The
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 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Transport network overview . . . . . . . . . . . . . . . . 5 1.2. Transport network overview . . . . . . . . . . . . . . . . 7
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 7 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 8
2.1. General requirements . . . . . . . . . . . . . . . . . . . 7 2.1. General requirements . . . . . . . . . . . . . . . . . . . 8
2.2. Layering requirements . . . . . . . . . . . . . . . . . . 8 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 10
2.3. Data plane requirements . . . . . . . . . . . . . . . . . 9 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 11
2.4. Control plane requirements . . . . . . . . . . . . . . . . 10 2.4. Control plane requirements . . . . . . . . . . . . . . . . 12
2.5. Network Management (NM) requirements . . . . . . . . . . . 11 2.5. Network Management (NM) requirements . . . . . . . . . . . 13
2.6. Operation, Administration and Maintenance (OAM) 2.6. Operation, Administration and Maintenance (OAM)
requirements . . . . . . . . . . . . . . . . . . . . . . . 11 requirements . . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Network performance management (PM) requirements . . . . . 11 2.7. Network performance management (PM) requirements . . . . . 13
2.8. Protection & Survivability requirements . . . . . . . . . 11 2.8. Recovery & Survivability requirements . . . . . . . . . . 13
2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 2.8.1. Data plane behavior requirements . . . . . . . . . . . 14
2.10. Security requirements . . . . . . . . . . . . . . . . . . 14 2.8.2. Triggers for protection, restoration, and reversion . 16
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 2.8.3. Management plane operation of protection and
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 restoration . . . . . . . . . . . . . . . . . . . . . 16
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 2.8.4. Control plane and in-band OAM operation of recovery . 17
6. Informative References . . . . . . . . . . . . . . . . . . . . 15 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 18 2.10. Security requirements . . . . . . . . . . . . . . . . . . 22
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . . 23
6.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 26
1. Introduction 1. Introduction
For many years, Synchronous Optical Networking (SONET)/Synchronous For many years, Synchronous Optical Networking (SONET)/Synchronous
Digital hierarchy (SDH) has provided carriers with a high benchmark Digital hierarchy (SDH) has provided carriers with a high benchmark
for reliability and operational simplicity. With the accelerating for reliability and operational simplicity. With the accelerating
growth of packet-based services (such as Ethernet, Voice over IP growth of packet-based services (such as Ethernet, Voice over IP
(VoIP), Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP (VoIP), 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.),
carriers are in need of capabilities to efficiently support packet- carriers are in need of capabilities to efficiently support packet-
skipping to change at page 4, line 15 skipping to change at page 5, line 15
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 SONET/SDH.
MPLS-TP will enable the migration of SONET/SDH networks to a packet- MPLS-TP will enable the migration of SONET/SDH 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 for a MPLS Transport Profile This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). This document is a product of a joint ITU-IETF effort to (MPLS-TP). The requirements are for the the behavior of the protocol
include a MPLS Transport Profile within the IETF MPLS architecture to mechanisms and procedures that constitute building blocks out of
support the capabilities and functionalities of a packet transport which the MPLS transport profile is constructed. That is, the
network as defined by ITU-T. requirements indicate what features are to be available in the MPLS
toolkit for use by MPLS-TP. The requirements in this document do not
describe what functions an MPLS-TP implementation supports. The
purpose of this document is to identify the toolkit and any new
protocol work that is required.
This document is a product of a joint ITU-IETF effort to include an
MPLS Transport Profile within the IETF MPLS architecture to support
the capabilities and functionalities of a packet transport network as
defined by ITU-T.
This work is based on two sources of requirements, MPLS architecture This work is based on two sources of requirements, MPLS 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
skipping to change at page 5, line 5 skipping to change at page 6, line 14
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 Link: A link as defined in G.805 [ITU.G805.2000] is used to describe
a fixed relationship between two ports. a fixed relationship between two ports.
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
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
LSRs and physical data links that form a ring topology.
Ring Topology: In an MPLS-TP ring topology each LSR is connected to
exactly two other LSRs, each via a single point-to-point
bidirectional MPLS-TP capable data link. A ring may also be
constructed from only two LSRs where there are also exactly two
links. Rings may be connected to other LSRs to form a larger
network. Traffic originating or terminating outside the ring may be
carried over the ring. Client network nodes (such as CEs) may be
connected directly to an LSR in the ring.
Section: A section is a MPLS-TP network server layer which provides Section: A section is a MPLS-TP network server layer which provides
for encapsulation and OAM of a MPLS-TP transport path client layer. for encapsulation and OAM of a MPLS-TP transport path client layer.
A section layer may provide for aggregation of multiple MPLS-TP A section layer may provide for aggregation of multiple MPLS-TP
clients. clients.
Segment: A segment corresponds to part of a path. A segment may be a Segment: A segment corresponds to part of a path. A segment may be a
single link (hop) within a path, a series of adjacent links (hops) single link (hop) within a path, a series of adjacent links (hops)
within a path, or the entire end-to-end-path. within a path, or the entire end-to-end-path.
Service layer: A layer network in which transport paths are used to Service layer: A layer network in which transport paths are used to
carry a customer's (individual or bundled) service (may be point-to- carry a customer's (individual or bundled) service (may be point-to-
point, point-to-multipoint or multipoint-to-multipoint services). point, point-to-multipoint or multipoint-to-multipoint services).
Span: A span is synonymous with a link. Span: A span is synonymous with a link.
Tandem Connection: A tandem connection corresponds to a segment of a Tandem Connection: A tandem connection corresponds to a segment of a
path. This may be either a segment of an LSP (i.e. a sub-path), or path. This may be either a segment of an LSP (i.e. a sub-path), or
one or more segment(s) of a PW. one or more segment(s) of a PW.
Transport path: A connection as defined in G.805 [ITU.G805.2000]. Transport path: A connection as defined in G.805 [ITU.G805.2000]. A
The combination of a PW (Single Segment or Multi-Segment) and LSP Transport path corresponds to an MPLS-TP LSP or to an MPLS-TP LSP and
corresponds to an MPLS-TP transport path. its associated PW or PWs (Single Segment or 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 network service layer. It provides for networks, for example the network 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.
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
skipping to change at page 7, line 9 skipping to change at page 8, line 31
boundary in the client layer network. boundary in the client layer network.
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.
2. MPLS-TP Requirements 2. MPLS-TP Requirements
2.1. General requirements 2.1. General requirements
1 MPLS-TP MUST be compatible with the MPLS data plane as defined by 1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as
IETF. When MPLS offers multiple options in this respect, MPLS-TP defined by the IETF. When MPLS offers multiple options in this
SHOULD select the minimum sub-set (necessary and sufficient respect, MPLS-TP SHOULD select the minimum sub-set (necessary and
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 IETF and re-use (as far as for MPLS-TP MUST be agreed within the IETF through the IETF
practically possible) existing MPLS standards. consensus process and MUST re-use (as far as practically
possible) existing MPLS standards.
3 Mechanisms and capabilities MUST be able to interoperate with 3 Mechanisms and capabilities MUST be able to interoperate, without
existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and a gateway function, with existing IETF MPLS [RFC3031] and IETF
data planes where appropriate. PWE3 [RFC3985] control and data planes where appropriate.
4 MPLS-TP MUST support a connection-oriented packet switching 4 MPLS-TP MUST be a connection-oriented packet switching model with
paradigm with traffic engineering capabilities that allow traffic engineering capabilities that allow deterministic control
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) or 5 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 6 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 7 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 a 8 MPLS-TP MUST support static provisioning of transport paths via a
Network Management System (NMS) or OSS (i.e. via the management Network Management System (NMS) or Operational Support Syste
plane). (OSS), i.e. via the management plane.
9 Static provisioning MUST NOT depend on routing or signaling 9 Mechanisms in an MPLS-TP network that satisfy functional
protocols (e.g. Generalized Multiprotocol Label Switching requirements that are common to general transport networks (i.e.,
(GMPLS), Open Shortest Path First (OSPF), Intermediate System to independent of technology) SHOULD be manageable in a way that is
Intermediate Systems (ISIS), Resource Reservation Protocol coherent with the way the equivalent mechanisms are managed in
(RSVP), Border gateway Protocol (BGP), Label Distribution other transport networks.
Protocol (LDP) etc.).
10 MPLS-TP MUST support the capability for network operation 10 Static provisioning MUST NOT depend on the presence of any
(including OAM) via an NMS/OSS (without the use of any control element of a control plane.
plane protocols).
11 A solution MUST be provided to suppor dynamic provisioning of 11 MPLS-TP MUST support the capability for network operation
(including OAM) via the management plane (without the use of any
control plane protocols).
12 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.
12 The MPLS-TP data plane MUST be capable of functioning 13 The MPLS-TP data plane MUST be capable of forwarding data and
independently of the control or management plane used to operate taken recovery actions independently of the control or management
the MPLS-TP layer network. That is the MPLS-TP data plane plane used to operate the MPLS-TP layer network. That is, the
operation MUST continue to operate normally if the management MPLS-TP data plane MUST continue to operate normally if the
plane or control plane that configured the transport paths fails. management plane or control plane that configured the transport
paths fails.
13 MPLS-TP MUST support transport paths through multiple homogeneous 14 MPLS-TP MUST support transport paths through multiple homogeneous
domains. domains.
14 MPLS-TP MUST NOT dictate the deployment of any particular network 15 MPLS-TP MUST NOT dictate the deployment of any particular network
topology either physical or logical. topology either physical or logical, however:
15 MPLS-TP MUST be able to scale with growing and increasingly A. It MUST be possible to deploy MPLS-TP in rings.
complex network topologies as well as increasing bandwidth
demands, number of customers or number of services.
16 MPLS-TP SHOULD support mechanisms to safeguard against the B. It MUST be possible to deploy MPLS-TP in arbitrarily
interconnected rings with one or two points of
interconnection.
C. MPLS-TP MUST support rings of at least 16 nodes in order to
support the upgrade of existing TDM rings to MPLS-TP.
MPLS-TP SHOULD support rings with more than 16 nodes.
D. It MUST be possible to construct rings from equipment
supplied by different vendors and to interconnect rings made
wholly from equipment from different vendors. [Editor's
note: This requirement comes from work provided by ITU-T
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.]
16 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.
17 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
17 An MPLS-TP network MUST operate in a multiple layer network 18 An MPLS-TP network MUST be able to support one or more client
environment consisting of independent service, transport path and network layers, and MUST be able to use one or more server
transmission media layers. network layers.
MPLS-TP may be used as the service layer (for P2P and P2MP services)
and/or as the transport path layer within a packet transport network.
18 A solution MUST be provided to support the transport of MPLS-TP 19 A solution MUST be provided to support the transport of MPLS-TP
and non MPLS-TP client layer networks over an MPLS-TP layer and non MPLS-TP client layer networks over an MPLS-TP layer
network. network.
19 A solution MUST be provided to support the transport of an 20 A solution MUST be provided to support the transport of an
MPLS-TP layer network over MPLS-TP and non MPLS-TP server layer MPLS-TP layer network over MPLS-TP and non MPLS-TP server layer
networks (such as Ethernet, OTN, etc.) networks (such as Ethernet, OTN, etc.)
20 In an environment where an MPLS-TP layer network is supporting a 21 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.
22 It MUST be possible to operate the layers of a multi-layer
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, and require the capability for network or different layer networks.
autonomous network operations.
21 It MUST be possible to hide MPLS-TP layer network addressing and 23 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
22 The identification of each transport path within its aggregate 24 The identification of each transport path within its aggregate
MUST be supported. MUST be supported.
23 A label in a particular section MUST uniquely identify the 25 A label in a particular section MUST uniquely identify the
transport path. transport path.
24 A transport path's source MUST be identifiable at its 26 A transport path's source MUST be identifiable at its
destination. destination.
Transport paths can be aggregated by pushing and de-aggregated by 27 MPLS-TP MUST support MPLS labels that are assigned by the
popping labels. MPLS-TP labels are swapped within a transport path
in a layer network instance when the traffic is forwarded from one
MPLS-TP link to another MPLS-TP link.
25 MPLS-TP MUST support MPLS labels that are assigned by the
downstream (with respect to data flow) node per [RFC3031] and downstream (with respect to data flow) node per [RFC3031] and
[RFC3473] and MAY support context-specific MPLS labels as defined [RFC3473] and MAY support context-specific MPLS labels as defined
in [RFC5331]. in [RFC5331].
26 It MUST be possible to operate and configure the MPLS-TP data 28 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.
27 MPLS-TP MUST support both unidirectional and bi-directional 29 MPLS-TP MUST support both unidirectional and bidirectional point-
point-to-point transport paths. to-point transport paths.
28 An MPLS-TP network MUST require the forward and backward 30 An MPLS-TP network MUST require the forward and backward
directions of a bi-directional transport path to follow the same directions of a bidirectional transport path to follow the same
path at each layer. path at each layer.
29 The intermediate nodes at each layer MUST be aware about the 31 The intermediate nodes at each layer MUST be aware about the
pairing relationship of the forward and the backward directions pairing relationship of the forward and the backward directions
belonging to the same bi-directional transport path. belonging to the same bi-directional transport path.
30 MPLS-TP MUST support unidirectional point-to-multipoint transport 32 MPLS-TP MAY support transport paths with asymmetric bandwidth
paths. requirements, i.e. the amount of reserved bandwidth differs
between the forward and backward directions.
31 MPLS-TP transport paths MUST NOT perform merging in a way that 33 MPLS-TP MUST support unidirectional point-to-multipoint transport
prevents the unique identification of the source at the paths.
destination (e.g. no use of LDP mp2p signaling in order to avoid
losing LSP head-end information, no use of PHP, etc).
32 MPLS-TP MUST be able to accommodate new types of client networks 34 MPLS-TP MUST be able to accommodate new types of client networks
and services. and services.
33 MPLS-TP SHOULD support mechanisms to minimize traffic impact 35 MPLS-TP SHOULD support mechanisms to minimize traffic impact
during network reconfiguration. during network reconfiguration.
34 MPLS-TP SHOULD support mechanisms which ensure the integrity of 36 MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth associated with a transport path to be increased
without impacting the > existing traffic on that transport path
37 MPLS-TP SHOULD support mechanisms to enable the reserved
bandwidth of a transport path to be decreased without impacting
the existing traffic on that transport path, provided that the
level of existing traffic is smaller than the reserved bandwidth
following the decrease.
38 MPLS-TP SHOULD support mechanisms which ensure the integrity of
the transported customer's service traffic. the transported customer's service traffic.
35 MPLS-TP MUST support an unambiguous and reliable means of 39 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
The requirements for ASON signalling and routing and the requirements The requirements for ASON signalling and routing and the requirements
for multi-region and multi-layer networks as specified in [RFC4139], for multi-region and multi-layer networks as specified in [RFC4139],
[RFC4258] and [RFC5212] respectively apply to MPLS-TP. [RFC4258] and [RFC5212] respectively apply to MPLS-TP.
Additionally: Additionally:
36 MPLS-TP SHOULD support control plane topologies that are 40 MPLS-TP SHOULD support control plane topologies that are
independent of the data plane topology. independent of the data plane topology.
37 The MPLS-TP control plane MUST be able to be operated independent 41 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.
38 The MPLS-TP control plane MUST support establishing all the 42 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.,
uni-directional and bidirectional P2P, uni-directional P2MP, unidirectional and bidirectional P2P, unidirectional P2MP, etc.)
etc.) including configuration of protection functions and any including configuration of protection functions and any
associated maintenance functions. associated maintenance functions.
39 The MPLS-TP control pane MUST support the configuration and 43 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 is established or
modified. modified.
40 An MPLS-TP control plane MUST support pre-allocated path 44 An MPLS-TP control plane MUST support operation of the recovery
protection. functions described in Section 2.8.
In some situations it is impractical to expect acceptable recovery
performance to be achieved using dynamic recalculation of transport
path routes. For this reason, it is necessary to allow for pre-
planning of protection routes for selected transport paths.
41 An MPLS-TP control plane MUST scale gracefully to support a large 45 An MPLS-TP control plane MUST scale gracefully to support a large
number of transport paths. number of transport paths.
42 An MPLS-TP control plane SHOULD provide a common control 46 An MPLS-TP control plane SHOULD provide a common control
mechanism for architecturally similar operations. mechanism for architecturally similar operations.
2.5. Network Management (NM) requirements 2.5. Network Management (NM) requirements
For requirements related to NM functionality for MPLS-TP, see the For requirements related to NM functionality for MPLS-TP, see the
MPLS-TP NM requirements document [I-D.gray-mpls-tp-nm-req]. MPLS-TP NM requirements 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.vigoureux-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.vigoureux-mpls-tp-oam-requirements].
2.8. Protection & Survivability requirements 2.8. Recovery & Survivability requirements
Network survivability plays a critical factor 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].
43 MPLS-TP MUST support transport network style protection switching 47 MPLS-TP MUST provide protection and restoration mechanisms.
mechanisms (tandem network connection protection, LSP protection
and PW protection) to provide the appropriate recovery time
required to maintain customer SLAs when potentially thousands of
services are simultaneously affected by a single failure.
44 MPLS-TP recovery mechanisms MUST be applicable at various levels A. Recovery techniques used for P2P and P2MP SHOULD be identical
throughout the network including support for span, tandem to simplify implementation and operation. However, this MUST
connection and end-to-end recovery. NOT override any other requirement.
45 MPLS-TP MUST support network restoration mechanisms controlled by 48 MPLS-TP recovery mechanisms MUST be applicable at various levels
a distributed control plane and MUST support network restoration throughout the network including support for span, path segment
mechanisms controlled by a management plane. and end-to-end path, and pseudowire segment, and end-to-end
pseudowire recovery.
A. The restoration resources MAY be pre-planned and selected a 49 MPLS-TP recovery paths MUST meet the SLA protection objectives of
priori, or computed after failure occurrence. the service.
B. MPLS-TP MAY support shared-mesh restoration. A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery
times from the moment of fault detection in networks with
spans less than 1200 km.
C. MPLS-TP MUST support soft (make before break) LSP B. For protection it MUST be possible to require protection of
100% of the traffic on the protected path.
C. Recovery objectives SHOULD be configurable per transport
path, and SHOULD include bandwidth and QoS.
50 The recovery mechanisms MUST all be applicable to any topology.
51 The recovery mechanisms MUST operate in synergy with (including
coordination of timing) the recovery mechanisms present in any
underlying server transport network (for example, Ethernet, SDH,
OTN, WDM) to avoid race conditions between the layers.
52 MPLS-TP protection mechanisms MUST support priority logic to
negotiate and accommodate coexisting requests (i.e., multiple
requests) for protection switching (e.g., administrative requests
and requests due to link/node failures).
53 MPLS-TP recovery and reversion mechanisms MUST prevent frequent
operation of recovery in the event of an intermittent defect.
2.8.1. Data plane behavior requirements
General protection and survivability requirements are expressed in
terms of the behavior in the data plane.
2.8.1.1. Protection
54 MPLS-TP MUST support 1+1 Protection.
A. MPLS-TP 1+1 support MUST include bidirectional protection
switching for P2P connectivity, and this SHOULD be the
default behavior.
B. Unidirectional 1+1 protection for P2MP connectivity MUST be
supported.
C. Unidirectional 1+1 protection for P2P connectivity is NOT
REQUIRED.
55 MPLS-TP MUST support 1:n Protection (including 1:1 protection).
A. MPLS-TP 1:n support MUST include bidirectional protection
switching for P2P connectivity, and this SHOULD be the
default behavior.
B. Unidirectional 1:n protection for P2MP connectivity MUST be
supported.
C. Unidirectional 1:n protection for P2P connectivity is NOT
REQUIRED.
D. The action of protection switching MUST NOT cause user data
to loop. Backtracking is allowed.
56 MPLS-TP SHOULD support extra traffic carried on 1:n protection
resources when protection is not in use.
2.8.1.2. Restoration
57 The restoration LSP MUST be able to share resources with the LSP
being replaced (sometimes known as soft rerouting).
58 Restoration priority MUST be supported so that an implementation
can determine the order in which transport paths should be
restored (to minimize service restoration time as well as to gain
access to available spare capacity on the best paths).
59 Preemption priority MUST be supported to allow restoration to
displace other transport paths in the event of resource
constraint.
60 Recovery mechanisms MUST be bidirectional.
2.8.1.3. Sharing of protection resources
61 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh
restoration. restoration.
D. MPLS-TP MAY support hard (break before make) LSP restoration. 62 MPLS-TP MUST support the sharing of protection bandwidth by
allowing best effort traffic.
E. The restoration mechanism MUST be applicable to any topology. 63 MPLS-TP MUST support the definition of shared protection groups
to allow the coordination of protection actions resulting from
triggers caused by events at different locations in the network.
F. Restoration priority MUST be implemented to determine the 64 MPLS-TP MUST support sharing of protection resources such that
order in which transport paths should be restored (to protection paths that are known not to be required concurrently
minimize service restoration time as well as to gain access can share the same resources.
to available spare capacity on the best paths). Preemption
priority MUST be supported, so that in the event that not all
transport paths can be restored transport paths with lower
preemption priority can be released. When preemption is
supported, its use MUST be operator configurable.
G. The restoration mechanism MUST operate in synergy with other 2.8.1.4. Reversion
transport network technologies (SDH, OTN, WDM).
46 MPLS-TP MUST support inband OAM driven protection mechanisms 65 MPLS-TP protection mechanisms MUST support revertive and non-
(without any dependency on a control plane) to enable fast revertive behavior. Reversion MUST be the default behavior.
recovery from failure.
47 If protection is supported then: 66 MPLS-TP restoration mechanisms MAY support revertive and non-
revertive behavior.
A. MPLS-TP protection mechanisms MUST apply to LSPs and PWs. 2.8.2. Triggers for protection, restoration, and reversion
B. MPLS-TP MUST support mechanisms that rapidly detect, locate, Recovery actions may be triggered from different places as follows:
notify and remedy network faults.
C. MPLS-TP MAY support 1:1 bidirectional protection switching. 67 MPLS-TP MUST support physical layer fault indication triggers.
If bi-directional 1:1 protection switching is activated then
the protection state of both ends of the protected entity
MUST be synchronized.
D. MPLS-TP MAY support 1+1 unidirectional protection switching. 68 MPLS-TP MUST support OAM-based triggers.
E. MPLS-TP protection mechanisms MUST be applicable to point-to- 69 MPLS-TP MUST support management plane triggers (e.g., forced
point and point-to-multipoint transport paths. switch, etc.).
F. Protection ratio MUST be of 100%, i.e. 100% of impaired 70 There MUST be a mechanism to allow administrative recovery
working traffic MUST be protected for a failure on the actions to be distinguished from recovery actions initiated by
working path. Additionally: other triggers.
1. The QoS objectives defined by the operator MUST also be 71 Where a control plane is present, MPLS-TP SHOULD support control
met along the protection path. plane triggers.
2. In the case of 1:1 protection mechanisms, the bandwidth 2.8.3. Management plane operation of protection and restoration
reserved for the protection path MAY be available for
other traffic when the working path is operational.
G. Operator requests for manual control of protection switching All functions described here are for control by the operator.
such as clear, lockout of protection, forced-switch and
manual-switch commands MUST be supported. Prioritized
protection between Signal Fail (SF), Signal Degradation (SD)
and operator switch requests MUST be supported.
H. MPLS-TP protection mechanisms MUST support priority logic to 72 It MUST be possible to configure of protection paths and
negotiate and accommodate coexisting requests (i.e. multiple protection-to-working path relationships (sometimes known as
requests) for protection switching (e.g. "administrative" protection groups).
requests and requests due to link/node failures).
I. MPLS-TP protection mechanisms MUST support revertive and non- 73 There MUST be support for pre-calculation of recovery paths.
revertive behaviour.
J. MPLS-TP protection switching mechanisms MUST prevent frequent 74 There MUST be support for pre-provisioning of recovery paths.
operation of the protection switch due to an intermittent
defect.
K. MPLS-TP protection mechanisms MUST ensure co-ordination of 75 The following administrative control MUST be supported:
timing of protection switches at multiple layers to avoid
races and to allow the protection switching mechanism of the
server layer to fix the problem before switching at the
MPLS-TP layer.
L. MPLS-TP MAY support mechanisms that are optimized for A. lockout
specific network topologies (e.g. ring). These mechanisms
MUST be interoperable with the mechanisms defined for
arbitrary topology (mesh) networks.
M. If optimised mechanisms for ring topologies are supported B. forced switchover
then they MUST support switching times within 50 ms C. manual switchover
(depending on CV rate configuration) assuming a reference
network of a 16 node ring with less than 1200 Km of fiber, as D. simulated fault
defined by ITU SG15, Question 9.
76 There MUST be support for the configuration of timers used for
recovery operation.
77 Restoration resources MAY be pre-planned and selected a priori,
or computed after failure occurrence.
78 When preemption is supported for recovery purposes, it MUST be
possible for the operator to configure it.
79 The management plane MUST provide indications of protection
events and triggers.
80 The management plane MUST allow the current protection status of
all transport paths to be determined.
2.8.4. Control plane and in-band OAM operation of recovery
81 The MPLS-TP control plane (which is not mandatory in an MPLS-TP
implementation) MUST support:
A. establishment and maintenance of all recovery entities and
functions
B. signaling of administrative control
C. protection state coordination (PSC)
82 In-band OAM MAY be used for:
A. signaling of administrative control
B. protection state coordination
2.8.5. Topology-specific recovery mechanisms
83 MPLS-TP MAY support recovery mechanisms that are optimized for
specific network topologies. These mechanisms MUST be
interoperable with the mechanisms defined for arbitrary topology
(mesh) networks to enable protection of end-to-end transport
paths.
Note that topology-specific recovery mechanisms are subject to the
development of requirements using the normal IETF process.
2.8.5.1. Ring protection
Several service providers have expressed a high level of interest in
operating MPLS-TP in ring topologies and require a high level of
survivability function in these topologies. The requirements listed
below have been collected from these service providers and from the
ITU-T.
The main objective in considering a specific topology (such as a
ring) is to determine whether it is possible to optimize any
mechanisms such that the performance of those mechanisms within the
topology is significantly better than the performance of the generic
mechanisms in the same topology. The benefits of such optimizations
are traded against the costs of developing, implementing, deploying,
and operating the additional optimized mechanisms noting that the
generic mechanisms MUST continue to be supported.
Within the context of recovery in MPLS-TP networks, the optimization
criteria considered in ring topologies are as follows:
a. Minimize the number of OAM MEs that are needed to trigger the
recovery operation - less than are required by other recovery
mechanisms.
b. Minimize the number of elements of recovery in the ring - less
than are required by other recovery mechanisms.
c. Minimize the number of labels required for the protection paths
across the ring - less than are required by other recovery
mechanisms.
d. Minimize the amount of management plane transactions during a
maintenance operation (e.g., ring upgrade) - less than are
required by other recovery mechanisms.
It may be observed that this list is fully compatible with the
generic requirements expressed above, and that no requirements that
are specific to ring topologies have been identified. [Editors'
Note: This statement is to be confirmed at the end of the work and
may be removed if it does not hold.]
In the list of requirements below, those requirements that are
generic are marked "[G]"; those that are Ring-specific are marked
"[R]". [Editors' Note: Still need to mark up the requirements below
as [R] and [G].]
84 MPLS-TP MUST include recovery mechanisms that operate in any
single ring supported in MPLS-TP, and continue to operate within
the single rings even when the rings are interconnected.
85 When a network is constructed from interconnected rings, MPLS-TP
MUST support recovery mechanisms that protect user data that
traverses more than one ring. This includes the possibility of
failure of the ring-interconnect nodes and links.
86 MPLS-TP recovery in a ring MUST protect unidirectional and
bidirectional P2P transport paths.
87 MPLS-TP recovery in a ring MUST protect unidirectional P2MP
transport paths.
88 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching
time within 50 ms from the moment of fault detection in a network
with a 16 nodes ring with less than 1200 km of fiber. This is
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.]
89 The protection switching time in a ring MUST be independent of
the number of LSPs crossing the ring.
90 Recovery actions in a ring MUST be data plane functions
triggered by different elements of control. The triggers are
configured by management or control planes and are subject to
configurable policy.
91 The configuration and operation of recovery mechanisms in a ring
MUST scale well with:
A. the number of transport paths (must be better than linear
scaling)
B. the number of nodes on the ring (must be at least as good as
linear scaling)
C. the number of ring interconnects (must be at least as good
as linear scaling)
92 MPLS-TP recovery in ring topologies MAY support multiple
failures without reconfiguring the protection actions.
93 Recovery techniques used in a ring MUST NOT prevent the ring
from being connected to a general MPLS-TP network in any
arbitrary way, and MUST NOT prevent the operation of recovery
techniques in the rest of the network.
94 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally
applicable in physical and logical rings.
95 Recovery techniques in a ring SHOULD be identical to those in
general networks to simplify implementation. However, this MUST
NOT override any other requirement.
96 Recovery techniques in logical and physical rings SHOULD be
identical to simplify implementation and operation. However,
this MUST NOT override any other requirement.
97 The default recovery scheme in a ring MUST be bidirectional
recovery in order to simplify the recovery operation.
98 The recovery mechanism in a ring MUST support revertive
switching, which MUST be the default behaviour. This allows
optimization of the use of the ring resources, and restores the
preferred quality conditions for normal traffic (e.g., delay)
when the recovery mechanism is no longer needed.
99 The recovery mechanisms in a ring MUST support ways to allow
administrative protection switching, to be distinguished from
protection switching initiated by other triggers.
100 It MUST be possible to disable protection mechanisms on selected
links in a ring (depending on operator's need).
[Editor note: This requirement was originated from ITU-T Q9/15 and
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.]
101 MPLS-TP recovery mechanisms in a ring MUST include a mechanism
to allow an implementation to handle coexisting requests (i.e.,
multiple requests - not necessarily arriving simultaneously) for
protection switching based on priority.
102 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a
way to prevent frequent operation of recovery in the event of an
intermittent defect.
103 MPLS-TP MUST support the sharing of protection bandwidth in a
ring by allowing best effort traffic.
104 MPLS-TP MUST support sharing of ring protection resources such
that protection paths that are known not to be required
concurrently can share the same resources.
105 MUST support the coordination of triggers caused by events at
different locations in a ring. Note that this is the ring
equivalent of the definition of shared protection groups.
2.9. QoS requirements 2.9. QoS requirements
Carriers require advanced traffic management capabilities to enforce Carriers require advanced traffic management capabilities to enforce
and guarantee the QoS parameters of customers' SLAs. and guarantee the QoS parameters of customers' SLAs.
Quality of service mechanisms are required to ensure: Quality of service mechanisms are REQUIRED in an MPLS-TP network to
ensure:
48 Support for differentiated services and different traffic types 106 Support for differentiated services and different traffic types
with traffic class separation associated with different traffic. with traffic class separation associated with different traffic.
49 Prioritization of critical services. 107 Prioritization of critical services.
50 Enabling the provisioning and the guarantee of Service Level 108 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 BW guaranteed. end bandwidth guaranteed.
51 Controlled jitter and delay. 109 Controlled jitter and delay.
52 Guarantee of fair access to shared resources in an MPLS-TP 110 Guarantee of fair access to shared resources.
network.
53 Resources for control and management plane packets so that data 111 Resources for control and management plane packets so that data
plane traffic, regardless of the amount, will not cause control plane traffic, regardless of the amount, will not cause control
and management functions to become inoperative. and management functions to become inoperative.
54 MPLS-TP MUST support a flexible bandwidth allocation scheme. 112 Carriers are provided with the capability to efficiently support
This will provide carriers with the capability to efficiently service demands over the MPLS-TP network. This MUST include
support service demands over the MPLS-TP network. support for a flexible bandwidth allocation scheme.
[Should we refer here to the requirements specified in RFC 2702?] [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
skipping to change at page 15, line 15 skipping to change at page 22, line 29
4. Security Considerations 4. Security Considerations
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].
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 IETF and the Working Team, the MPLS Interoperability Design Team in the IETF, and
T-MPLS Ad Hoc Group in 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, Italo Busi, John The authors would also like to thank Loa Andersson, Lou Berger, Italo
Drake, Neil Harrison, Wataru Imajuku, Julien Meuric, Tom Nadeau, Busi, John Drake, Adrian Farrel, Neil Harrison, Wataru Imajuku,
Hiroshi Ohta, Tomonori Takeda and Satoshi Ueno for their comments and Julien Meuric, Tom Nadeau, Hiroshi Ohta and Tomonori Takeda for their
enhancements to the text. comments and enhancements to the text.
6. Informative References An ad hoc discussion group consisting of Stewart Bryant, Italo Busi,
Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort,
Feng Huang, Harald Kullman, Han Li, Hao Long and Nurit Sprecher
provided valuable input to the requirements for deployment and
survivability in ring topologies.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.gray-mpls-tp-nm-req]
Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network
Management Requirements", draft-gray-mpls-tp-nm-req-01
(work in progress), July 2008.
[I-D.vigoureux-mpls-tp-oam-requirements]
Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks",
draft-vigoureux-mpls-tp-oam-requirements-00 (work in
progress), July 2008.
6.2. Informative References
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3473] Berger, L., "Multiprotocol Label Switching Architecture", [RFC3473] Berger, L., "Multiprotocol Label Switching Architecture",
RFC 3473, January 2003. 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.
skipping to change at page 16, line 14 skipping to change at page 24, line 5
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi- M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
July 2008. 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.gray-mpls-tp-nm-req]
Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network
Management Requirements", draft-gray-mpls-tp-nm-req-01
(work in progress), July 2008.
[I-D.vigoureux-mpls-tp-oam-requirements]
Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks",
draft-vigoureux-mpls-tp-oam-requirements-00 (work in
progress), July 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-03 (work
in progress), July 2008. in progress), July 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.
skipping to change at page 18, line 5 skipping to change at page 25, line 20
Email: betts01@nortel.com Email: betts01@nortel.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon, 45241
Israel Israel
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
Satoshi Ueno
NTT
Email: satoshi.ueno@ntt.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 101 change blocks. 
235 lines changed or deleted 559 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/