draft-ietf-mpls-tp-requirements-06.txt | draft-ietf-mpls-tp-requirements-07.txt | |||
---|---|---|---|---|
MPLS Working Group B. Niven-Jenkins, Ed. | MPLS Working Group B. Niven-Jenkins, Ed. | |||
Internet-Draft BT | Internet-Draft BT | |||
Intended status: Standards Track D. Brungard, Ed. | Intended status: Standards Track D. Brungard, Ed. | |||
Expires: October 6, 2009 AT&T | Expires: November 19, 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 | |||
April 4, 2009 | May 18, 2009 | |||
MPLS-TP Requirements | MPLS-TP Requirements | |||
draft-ietf-mpls-tp-requirements-06 | draft-ietf-mpls-tp-requirements-07 | |||
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 October 6, 2009. | This Internet-Draft will expire on November 19, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 3, line 18 | skipping to change at page 3, line 18 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6 | 1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6 | |||
1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8 | 1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8 | |||
1.2. Transport network overview . . . . . . . . . . . . . . . . 11 | 1.2. Transport network overview . . . . . . . . . . . . . . . . 11 | |||
1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12 | 1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12 | |||
2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13 | 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13 | |||
2.1. General requirements . . . . . . . . . . . . . . . . . . . 13 | 2.1. General requirements . . . . . . . . . . . . . . . . . . . 13 | |||
2.2. Layering requirements . . . . . . . . . . . . . . . . . . 16 | 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 16 | |||
2.3. Data plane requirements . . . . . . . . . . . . . . . . . 17 | 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 17 | |||
2.4. Control plane requirements . . . . . . . . . . . . . . . . 18 | 2.4. Control plane requirements . . . . . . . . . . . . . . . . 18 | |||
2.5. Network Management (NM) requirements . . . . . . . . . . . 20 | 2.5. Network Management requirements . . . . . . . . . . . . . 20 | |||
2.6. Operation, Administration and Maintenance (OAM) | 2.6. Operation, Administration and Maintenance (OAM) | |||
requirements . . . . . . . . . . . . . . . . . . . . . . . 20 | requirements . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
2.7. Network performance management (PM) requirements . . . . . 20 | 2.7. Network performance monitoring requirements . . . . . . . 20 | |||
2.8. Recovery requirements . . . . . . . . . . . . . . . . . . 20 | 2.8. Recovery requirements . . . . . . . . . . . . . . . . . . 20 | |||
2.8.1. Data plane behavior requirements . . . . . . . . . . . 21 | 2.8.1. Data plane behavior requirements . . . . . . . . . . . 21 | |||
2.8.1.1. Protection . . . . . . . . . . . . . . . . . . . . 21 | 2.8.1.1. Protection . . . . . . . . . . . . . . . . . . . . 21 | |||
2.8.1.2. Restoration . . . . . . . . . . . . . . . . . . . 22 | 2.8.1.2. Sharing of protection resources . . . . . . . . . 22 | |||
2.8.1.3. Sharing of protection resources . . . . . . . . . 22 | 2.8.1.3. Reversion . . . . . . . . . . . . . . . . . . . . 22 | |||
2.8.1.4. Reversion . . . . . . . . . . . . . . . . . . . . 23 | 2.8.2. Restoration . . . . . . . . . . . . . . . . . . . . . 22 | |||
2.8.2. Triggers for protection, restoration, and reversion . 23 | 2.8.3. Triggers for protection, restoration, and reversion . 23 | |||
2.8.3. Management plane operation of protection and | 2.8.4. Management plane operation of protection and | |||
restoration . . . . . . . . . . . . . . . . . . . . . 23 | restoration . . . . . . . . . . . . . . . . . . . . . 23 | |||
2.8.4. Control plane and in-band OAM operation of recovery . 24 | 2.8.5. Control plane and in-band OAM operation of recovery . 24 | |||
2.8.5. Topology-specific recovery mechanisms . . . . . . . . 25 | 2.8.6. Topology-specific recovery mechanisms . . . . . . . . 25 | |||
2.8.5.1. Ring protection . . . . . . . . . . . . . . . . . 25 | 2.8.6.1. Ring protection . . . . . . . . . . . . . . . . . 25 | |||
2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 28 | 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 28 | |||
2.10. Security requirements . . . . . . . . . . . . . . . . . . 28 | 2.10. Security requirements . . . . . . . . . . . . . . . . . . 28 | |||
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | 6.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | |||
6.2. Informative References . . . . . . . . . . . . . . . . . . 30 | 6.2. Informative References . . . . . . . . . . . . . . . . . . 30 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
1. Introduction | 1. Introduction | |||
Bandwidth demand continues to grow worldwide, stimulated by the | Bandwidth demand continues to grow worldwide, stimulated by the | |||
skipping to change at page 5, line 35 | skipping to change at page 5, line 35 | |||
and it is already playing an important role in transport networks and | and it is already playing an important role in transport networks and | |||
services. However, not all of MPLS's capabilities and mechanisms are | services. However, not all of MPLS's capabilities and mechanisms are | |||
needed and/or consistent with transport network operations. There | needed and/or consistent with transport network operations. There | |||
are also transport technology characteristics that are not currently | are also transport technology characteristics that are not currently | |||
reflected in MPLS. There is therefore the need to define an MPLS | reflected in MPLS. There is therefore the need to define an MPLS | |||
Transport Profile (MPLS-TP) that supports the capabilities and | Transport Profile (MPLS-TP) that supports the capabilities and | |||
functionalities needed for packet transport network services and | functionalities needed for packet transport network services and | |||
operations through combining the packet experience of MPLS with the | operations through combining the packet experience of MPLS with the | |||
operational experience and practices of existing transport networks. | operational experience and practices of existing transport networks. | |||
MPLS-TP will enable the migration of transport networks to a packet- | MPLS-TP will enable the depoyment of packet based transport networks | |||
based network that will efficiently scale to support packet services | that will efficiently scale to support packet services in a simple | |||
in a simple and cost effective way. MPLS-TP needs to combine the | and cost effective way. MPLS-TP needs to combine the necessary | |||
necessary existing capabilities of MPLS with additional minimal | existing capabilities of MPLS with additional minimal mechanisms in | |||
mechanisms in order that it can be used in a transport role. | order that it can be used in a transport role. | |||
This document specifies the requirements of an MPLS Transport Profile | This document specifies the requirements of an MPLS Transport Profile | |||
(MPLS-TP). The requirements are for the behavior of the protocol | (MPLS-TP). The requirements are for the behavior of the protocol | |||
mechanisms and procedures that constitute building blocks out of | mechanisms and procedures that constitute building blocks out of | |||
which the MPLS transport profile is constructed. That is, the | which the MPLS transport profile is constructed. That is, the | |||
requirements indicate what features are to be available in the MPLS | requirements indicate what features are to be available in the MPLS | |||
toolkit for use by MPLS-TP. The requirements in this document do not | toolkit for use by MPLS-TP. The requirements in this document do not | |||
describe what functions an MPLS-TP implementation supports. The | describe what functions an MPLS-TP implementation supports. The | |||
purpose of this document is to identify the toolkit and any new | purpose of this document is to identify the toolkit and any new | |||
protocol work that is required. | protocol work that is required. | |||
skipping to change at page 6, line 31 | skipping to change at page 6, line 31 | |||
Although both static and dynamic configuration of MPLS-TP transport | Although both static and dynamic configuration of MPLS-TP transport | |||
paths (including Operations, Administration and Maintenance (OAM) and | paths (including Operations, Administration and Maintenance (OAM) and | |||
protection capabilities) is required by this document, it MUST be | protection capabilities) is required by this document, it MUST be | |||
possible for operators to be able to completely operate (including | possible for operators to be able to completely operate (including | |||
OAM and protection capabilities) an MPLS-TP network in the absence of | OAM and protection capabilities) an MPLS-TP network in the absence of | |||
any control plane protocols for dynamic configuration. | any control plane protocols for dynamic configuration. | |||
1.1. Terminology | 1.1. Terminology | |||
Note: Mapping between the terms in this section and ITU-T terminology | Note: Mapping between the terms in this section and ITU-T terminology | |||
will be described in a subsequent document. | is described in [I-D.helvoort-mpls-tp-rosetta-stone]. | |||
The recovery requirements in this document use the recovery | The recovery requirements in this document use the recovery | |||
terminology defined in RFC 4427 [RFC4427], this is applied to both | terminology defined in RFC 4427 [RFC4427], this is applied to both | |||
control plane and management plane based operations of MPLS-TP | control plane and management plane based operations of MPLS-TP | |||
transport paths. | transport paths. | |||
1.1.1. Abbreviations | 1.1.1. Abbreviations | |||
ASON: Automatically Switched Optical Network | ASON: Automatically Switched Optical Network | |||
skipping to change at page 7, line 18 | skipping to change at page 7, line 18 | |||
IPTV: IP Television | IPTV: IP Television | |||
L2: Layer 2 | L2: Layer 2 | |||
L3: Layer 3 | L3: Layer 3 | |||
LSP: Label Switched Path | LSP: Label Switched Path | |||
LSR: Label Switching Router | LSR: Label Switching Router | |||
MEP: Maintenance End Point | ||||
MIP: Maintenance Intermediate Point | ||||
MPLS: Multi-Protocol Label Switching | MPLS: Multi-Protocol Label Switching | |||
OAM: Operations, Administration and Maintenance | OAM: Operations, Administration and Maintenance | |||
OPEX: Operational Expenditure | OPEX: Operational Expenditure | |||
OSI: Open Systems Interconnection | OSI: Open Systems Interconnection | |||
OTN: Optical Transport Network | OTN: Optical Transport Network | |||
P2MP: Point to Multi-Point | P2MP: Point to Multi-Point | |||
P2P: Point to Point | P2P: Point to Point | |||
PDU: Protocol Data Unit | PDU: Protocol Data Unit | |||
PM: Performance Management | ||||
PSC: Protection State Coordination | PSC: Protection State Coordination | |||
PW: Pseudo Wire | PW: Pseudo Wire | |||
QoS: Quality of Service | QoS: Quality of Service | |||
RAN: Radio Access Network | RAN: Radio Access Network | |||
SDH: Synchronous Digital Hierarchy | SDH: Synchronous Digital Hierarchy | |||
skipping to change at page 8, line 46 | skipping to change at page 8, line 40 | |||
Client layer network: In a client/server relationship (see G.805 | Client layer network: In a client/server relationship (see G.805 | |||
[ITU.G805.2000]), the client layer network receives a (transport) | [ITU.G805.2000]), the client layer network receives a (transport) | |||
service from the lower server layer network (usually the layer | service from the lower server layer network (usually the layer | |||
network under consideration). | network under consideration). | |||
Concatenated Segment: A serial-compound link connection as defined in | Concatenated Segment: A serial-compound link connection as defined in | |||
G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part | G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part | |||
of an LSP or multi-segment PW that comprises a set of segments and | of an LSP or multi-segment PW that comprises a set of segments and | |||
their interconnecting nodes in sequence. See also "Segment". | their interconnecting nodes in sequence. See also "Segment". | |||
Control Plane: Within the scope of this document the control plane | ||||
performs transport path control functions. Through signalling, the | ||||
control plane sets up, modifies and releases transport paths, and may | ||||
recover a transport path in case of a failure. The control plane | ||||
also performs other functions in support of transport path control, | ||||
such as routing information dissemination. | ||||
Co-routed Bidirectional path: A path where the forward and backward | Co-routed Bidirectional path: A path where the forward and backward | |||
directions follow the same route (links and nodes) across the | directions follow the same route (links and nodes) across the | |||
network. Both directions are setup, monitored and protected as a | network. Both directions are setup, monitored and protected as a | |||
single entity. | single entity. A transport network path is typically co-routed. | |||
Domain: A domain represents a collection of entities (for example | Domain: A domain represents a collection of entities (for example | |||
network elements) that are grouped for a particular purpose, examples | network elements) that are grouped for a particular purpose, examples | |||
of which are administrative and/or managerial responsibilities, trust | of which are administrative and/or managerial responsibilities, trust | |||
relationships, addressing schemes, infrastructure capabilities, | relationships, addressing schemes, infrastructure capabilities, | |||
aggregation, survivability techniques, distributions of control | aggregation, survivability techniques, distributions of control | |||
functionality, etc. Examples of such domains include IGP areas and | functionality, etc. Examples of such domains include IGP areas and | |||
Autonomous Systems. | Autonomous Systems. | |||
Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A | Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A | |||
skipping to change at page 10, line 5 | skipping to change at page 10, line 5 | |||
MPLS-TP Ring Topology: In an MPLS-TP ring topology each LSR is | MPLS-TP Ring Topology: In an MPLS-TP ring topology each LSR is | |||
connected to exactly two other LSRs, each via a single point-to-point | connected to exactly two other LSRs, each via a single point-to-point | |||
bidirectional MPLS-TP capable link. A ring may also be constructed | bidirectional MPLS-TP capable link. A ring may also be constructed | |||
from only two LSRs where there are also exactly two links. Rings may | from only two LSRs where there are also exactly two links. Rings may | |||
be connected to other LSRs to form a larger network. Traffic | be connected to other LSRs to form a larger network. Traffic | |||
originating or terminating outside the ring may be carried over the | originating or terminating outside the ring may be carried over the | |||
ring. Client network nodes (such as CEs) may be connected directly | ring. Client network nodes (such as CEs) may be connected directly | |||
to an LSR in the ring. | to an LSR in the ring. | |||
Section Layer Network: A section is a server layer (which may be | Section Layer Network: A section layer is a server layer (which may | |||
MPLS-TP or a different technology) which provides for encapsulation | be MPLS-TP or a different technology) which provides for the transfer | |||
and OAM of a client layer network. A section layer may provide for | of the section layer client information between adjacent nodes in the | |||
aggregation of multiple MPLS-TP clients. Note that G.805 | transport path layer or transport service layer. A section layer may | |||
provide for aggregation of multiple MPLS-TP clients. Note that G.805 | ||||
[ITU.G805.2000] defines the section layer as one of the two layer | [ITU.G805.2000] defines the section layer as one of the two layer | |||
networks in a transmission media layer network. The other layer | networks in a transmission media layer network. The other layer | |||
network is the physical media layer network. | network is the physical media layer network. | |||
Segment: A link connection as defined in G.805 [ITU.G805.2000]. A | Segment: A link connection as defined in G.805 [ITU.G805.2000]. A | |||
segment is the part of an LSP that traverses a single link or the | segment is the part of an LSP that traverses a single link or the | |||
part of a PW that traverses a single link (i.e. that connects a pair | part of a PW that traverses a single link (i.e. that connects a pair | |||
of adjacent {Switching|Terminating} Provider Edges). See also | of adjacent {Switching|Terminating} Provider Edges). See also | |||
"Concatenated Segment". | "Concatenated Segment". | |||
skipping to change at page 10, line 32 | skipping to change at page 10, line 33 | |||
under consideration). | under consideration). | |||
Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The | Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The | |||
distinction between a layer network and a sublayer is that a sublayer | distinction between a layer network and a sublayer is that a sublayer | |||
is not directly accessible to clients outside of its encapsulating | is not directly accessible to clients outside of its encapsulating | |||
layer network and offers no direct transport service for a higher | layer network and offers no direct transport service for a higher | |||
layer (client) network. | layer (client) network. | |||
Switching Provider Edge (S-PE): See [I-D.ietf-pwe3-ms-pw-arch]. | Switching Provider Edge (S-PE): See [I-D.ietf-pwe3-ms-pw-arch]. | |||
Tandem Connection: A tandem connection is an arbitrary part of a | ||||
transport path that can be monitored (via OAM) independently from the | ||||
end-to-end monitoring (OAM). It may be a monitored segment or a | ||||
monitored concatenated segment of a transport path. The tandem | ||||
connection may also include the forwarding engine(s) of the node(s) | ||||
at the edge(s) of the segment or concatenated segment. | ||||
Terminating Provider Edge (T-PE): See [I-D.ietf-pwe3-ms-pw-arch]. | Terminating Provider Edge (T-PE): See [I-D.ietf-pwe3-ms-pw-arch]. | |||
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 that provides point-to-point or | Transport Path Layer: A (sub-)layer network that provides point-to- | |||
point-to-multipoint transport paths that may be used to carry a | point or point-to-multipoint transport paths. It provides | |||
higher (client) layer network or aggregates of higher (client) layer | ||||
networks, for example the transport service layer. It provides | ||||
independent (of the client) OAM when transporting its clients. | independent (of the client) OAM when transporting its clients. | |||
Transport Service Layer: A layer network in which transport paths are | Transport Service Layer: A layer network in which transport paths are | |||
used to carry a customer's (individual or bundled) service (may be | used to carry a customer's (individual or bundled) service (may be | |||
point-to-point, point-to-multipoint or multipoint-to-multipoint | point-to-point, point-to-multipoint or multipoint-to-multipoint | |||
services). | services). | |||
Transmission Media Layer: A layer network, consisting of a section | Transmission Media Layer: A layer network, consisting of a section | |||
layer network and a physical layer network as defined in G.805 | layer network and a physical layer network as defined in G.805 | |||
[ITU.G805.2000], that provides sections (two-port point-to-point | [ITU.G805.2000], that provides sections (two-port point-to-point | |||
skipping to change at page 14, line 7 | skipping to change at page 13, line 41 | |||
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 fulfill the requirements | 2 Any new functionality that is defined to fulfill the requirements | |||
for MPLS-TP MUST be agreed within the IETF through the IETF | for MPLS-TP MUST be agreed within the IETF through the IETF | |||
consensus process and MUST re-use (as far as practically | consensus process as per [RFC4929] | |||
possible) existing MPLS standards. | ||||
3 Mechanisms and capabilities MUST be able to interoperate with | 3 The MPLS-TP design SHOULD as far as reasonably possible re-use | |||
existing MPLS standards. | ||||
4 Mechanisms and capabilities MUST be able to interoperate with | ||||
existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and | existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and | |||
data planes where appropriate. | data planes where appropriate. | |||
A. Data plane interoperability MUST NOT require a gateway | A. Data plane interoperability MUST NOT require a gateway | |||
function. | function. | |||
4 MPLS-TP and its interfaces, both internal and external, MUST be | 5 MPLS-TP and its interfaces, both internal and external, MUST be | |||
sufficiently well-defined that interworking equipment supplied by | sufficiently well-defined that interworking equipment supplied by | |||
multiple vendors will be possible both within a single domain, | multiple vendors will be possible both within a single domain, | |||
and between domains. | and between domains. | |||
5 MPLS-TP MUST be a connection-oriented packet switching technology | 6 MPLS-TP MUST be a connection-oriented packet switching technology | |||
with traffic engineering capabilities that allow deterministic | with traffic engineering capabilities that allow deterministic | |||
control of the use of network resources. | control of the use of network resources. | |||
6 MPLS-TP MUST support traffic engineered point to point (P2P) and | 7 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 | 8 MPLS-TP MUST support unidirectional, co-routed bidirectional and | |||
associated bidirectional point-to-point transport paths. | ||||
9 The end points of a co-routed bidirectional transport path MUST | ||||
be aware of the pairing relationship of the forward and reverse | ||||
paths used to support the bidirectional service. | ||||
10 The intermediate nodes of a co-routed bidirectional transport | ||||
path at each (sub-)layer MUST be aware of the pairing | ||||
relationship of the forward and the backward directions of that | ||||
transport path. | ||||
11 The end points of an associated bidirectional transport path MUST | ||||
be aware of the pairing relationship of the forward and reverse | ||||
paths used to support the bidirectional service. | ||||
12 The intermediate nodes of an associated bidirectional transport | ||||
path at each (sub-)layer SHOULD NOT be aware of the pairing | ||||
relationship of the forward and the backward directions of that | ||||
transport path. | ||||
13 MPLS-TP MUST support bidirectional transport paths with symmetric | ||||
bandwidth requirements, i.e. the amount of reserved bandwidth is | ||||
the same between the forward and backward directions. | ||||
14 MPLS-TP MUST support bidirectional transport paths with | ||||
asymmetric bandwidth requirements, i.e. the amount of reserved | ||||
bandwidth differs between the forward and backward directions. | ||||
15 MPLS-TP MUST support the logical separation of the control and | ||||
management planes from the data plane. | management planes from the data plane. | |||
8 MPLS-TP MUST support the physical separation of the control and | 16 MPLS-TP MUST support the physical separation of the control and | |||
management planes from the data plane. | management planes from the data plane. | |||
9 MPLS-TP MUST support static provisioning of transport paths via | 17 MPLS-TP MUST support static provisioning of transport paths via | |||
the management plane. | the management plane. | |||
10 Mechanisms in an MPLS-TP network that satisfy functional | 18 Mechanisms in an MPLS-TP layer network that satisfy functional | |||
requirements that are common to general transport networks (i.e., | requirements that are common to general transport layer networks | |||
independent of technology) SHOULD be operable in a way that is | (i.e., independent of technology) SHOULD be operable in a way | |||
similar to the way the equivalent mechanisms are operated in | that is similar to the way the equivalent mechanisms are operated | |||
other transport networks. | in other transport layer technologies. | |||
11 Static provisioning MUST NOT depend on the presence of any | 19 Static provisioning MUST NOT depend on the presence of any | |||
element of a control plane. | element of a control plane. | |||
12 MPLS-TP MUST support the capability for network operation | 20 MPLS-TP MUST support the capability for network operation | |||
(including OAM and recovery) via the management plane (without | (including OAM and recovery) via the management plane (without | |||
the use of any control plane protocols). | the use of any control plane protocols). | |||
13 A solution MUST be defined to support dynamic provisioning and | 21 A solution MUST be defined to support dynamic provisioning and | |||
restoration of MPLS-TP transport paths via a control plane. | restoration of MPLS-TP transport paths via a control plane. | |||
14 MPLS-TP MUST support the co-existence of statically and | 22 MPLS-TP MUST support the co-existence of statically and | |||
dynamically provisioned/managed MPLS-TP transport paths within | dynamically provisioned/managed MPLS-TP transport paths within | |||
the same layer network or domain. | the same layer network or domain. | |||
15 The MPLS-TP data plane MUST be capable of | 23 The MPLS-TP data plane MUST be capable of | |||
A. forwarding data independent of the control or management | A. forwarding data independent of the control or management | |||
plane used to configure and operate the MPLS-TP layer | plane used to configure and operate the MPLS-TP layer | |||
network. | network. | |||
B. taking recovery actions independent of the control plane used | B. taking recovery actions independent of the control or | |||
to configure the MPLS-TP layer network. If the control plane | management plane used to configure the MPLS-TP layer network. | |||
does not restart, the data plane connections MUST be held and | ||||
NOT time out. | ||||
16 MPLS-TP MUST support mechanisms to avoid or minimize traffic | C. operating normally (i.e. forwarding, OAM and protection MUST | |||
continue to operate) if the management plane or control plane | ||||
that configured the transport paths fails. | ||||
24 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. | |||
17 MPLS-TP MUST support transport paths through multiple homogeneous | 25 MPLS-TP MUST support transport paths through multiple homogeneous | |||
domains. | domains. | |||
18 MPLS-TP SHOULD support transport paths through multiple non- | 26 MPLS-TP SHOULD support transport paths through multiple non- | |||
homogeneous domains. | homogeneous domains. | |||
19 MPLS-TP MUST NOT dictate the deployment of any particular network | 27 MPLS-TP MUST NOT dictate the deployment of any particular network | |||
topology either physical or logical, however: | topology either physical or logical, however: | |||
A. It MUST be possible to deploy MPLS-TP in rings. | A. It MUST be possible to deploy MPLS-TP in rings. | |||
B. It MUST be possible to deploy MPLS-TP in arbitrarily | B. It MUST be possible to deploy MPLS-TP in arbitrarily | |||
interconnected rings with one or two points of | interconnected rings with one or two points of | |||
interconnection. | interconnection. | |||
C. MPLS-TP MUST support rings of at least 16 nodes in order to | C. MPLS-TP MUST support rings of at least 16 nodes in order to | |||
support the upgrade of existing TDM rings to MPLS-TP. | support the upgrade of existing TDM rings to MPLS-TP. | |||
MPLS-TP SHOULD support rings with more than 16 nodes. | MPLS-TP SHOULD support rings with more than 16 nodes. | |||
20 MPLS-TP MUST be able to scale at least as well as existing | 28 MPLS-TP MUST be able to scale at least as well as existing | |||
transport technologies with growing and increasingly complex | transport technologies with growing and increasingly complex | |||
network topologies as well as with increasing bandwidth demands, | network topologies as well as with increasing bandwidth demands, | |||
number of customers, and number of services. | number of customers, and number of services. | |||
21 MPLS-TP SHOULD support mechanisms to safeguard against the | 29 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 | |||
22 A generic and extensible solution MUST be provided to support the | 30 A generic and extensible solution MUST be provided to support the | |||
transport of one or more client layer networks (e.g. MPLS-TP, | transport of one or more client layer networks (e.g. MPLS-TP, | |||
IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network. | IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network. | |||
23 A generic and extensible solution MUST be provided to support the | 31 A generic and extensible solution MUST be provided to support the | |||
transport of MPLS-TP transport paths over one or more server | transport of MPLS-TP transport paths over one or more server | |||
layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). | layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). | |||
Requirements for bandwidth management within a server layer | Requirements for bandwidth management within a server layer | |||
network are outside the scope of this document. | network are outside the scope of this document. | |||
24 In an environment where an MPLS-TP layer network is supporting a | 32 In an environment where an MPLS-TP layer network is supporting a | |||
client layer network, and the MPLS-TP layer network is supported | client layer network, and the MPLS-TP layer network is supported | |||
by a server layer network then operation of the MPLS-TP layer | by a server layer network then operation of the MPLS-TP layer | |||
network MUST be possible without any dependencies on the server | network MUST be possible without any dependencies on the server | |||
or client layer network. | or client layer network. | |||
A. The server layer MUST guarantee that the traffic loading | A. The server layer MUST guarantee that the traffic loading | |||
imposed by other clients does not cause the transport service | imposed by other clients does not cause the transport service | |||
provided to the MPLS-TP layer to fall bellow the agreed | provided to the MPLS-TP layer to fall bellow the agreed | |||
level. Mechanisms to achieve this are outside the scope of | level. Mechanisms to achieve this are outside the scope of | |||
these requirements. | these requirements. | |||
B. It MUST be possible to isolate the control and management | B. It MUST be possible to isolate the control and management | |||
planes of the MPLS-TP layer network from the control and | planes of the MPLS-TP layer network from the control and | |||
management planes of the client and server layer networks. | management planes of the client and server layer networks. | |||
25 A solution MUST be provided to support the transport of a client | 33 A solution MUST be provided to support the transport of a client | |||
MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer | MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer | |||
network. | network. | |||
A. The level of co-ordination required between the client and | A. The level of co-ordination required between the client and | |||
server MPLS(-TP) layer networks MUST be minimized (preferably | server MPLS(-TP) layer networks MUST be minimized (preferably | |||
no co-ordination will be required). | no co-ordination will be required). | |||
B. The MPLS(-TP) server layer network MUST be capable of | B. The MPLS(-TP) server layer network MUST be capable of | |||
transporting the complete set of packets generated by the | transporting the complete set of packets generated by the | |||
client MPLS(-TP) layer network, which may contain packets | client MPLS(-TP) layer network, which may contain packets | |||
that are not MPLS packets (e.g. IP or CNLS packets used by | that are not MPLS packets (e.g. IP or CNLS packets used by | |||
the control/management plane of the client MPLS(-TP) layer | the control/management plane of the client MPLS(-TP) layer | |||
network). | network). | |||
26 It MUST be possible to operate the layers of a multi-layer | 34 It MUST be possible to operate the layers of a multi-layer | |||
network that includes an MPLS-TP layer autonomously. | network that includes an MPLS-TP layer autonomously. | |||
The above are not only technology requirements, but also operational | The above are not only technology requirements, but also operational | |||
requirements. Different administrative groups may be responsible for | requirements. Different administrative groups may be responsible for | |||
the same layer network or different layer networks. | the same layer network or different layer networks. | |||
27 It MUST be possible to hide MPLS-TP layer network addressing and | 35 It MUST be possible to hide MPLS-TP layer network addressing and | |||
other information (e.g. topology) from client layer networks. | other information (e.g. topology) from client layer networks. | |||
However, it SHOULD be possible, at the option of the operator, to | However, it SHOULD be possible, at the option of the operator, to | |||
leak a limited amount of summarized information (such as SRLGs or | leak a limited amount of summarized information (such as SRLGs or | |||
reachability) between layers. | reachability) between layers. | |||
2.3. Data plane requirements | 2.3. Data plane requirements | |||
28 It MUST be possible for the end points of an MPLS-TP transport | 36 It MUST be possible for the end points of an MPLS-TP transport | |||
path that is carrying an aggregate of client transport paths to | path that is carrying an aggregate of client transport paths to | |||
be able to decompose the aggregate transport path into its | be able to decompose the aggregate transport path into its | |||
component client transport paths. | component client transport paths. | |||
29 A transport path on a link MUST be uniquely identifiable by a | 37 A transport path on a link MUST be uniquely identifiable by a | |||
single label on that link. | single label on that link. | |||
30 A transport path's source MUST be identifiable at its destination | 38 A transport path's source MUST be identifiable at its destination | |||
within its layer network in coordination with the management | within its layer network. | |||
plane or control plane. | ||||
31 MPLS-TP MUST be capable of using P2MP server (sub-)layer | 39 MPLS-TP MUST be capable of using P2MP server (sub-)layer | |||
capabilities as well as P2P server (sub-)layer capabilities when | capabilities as well as P2P server (sub-)layer capabilities when | |||
supporting P2MP MPLS-TP transport paths. | supporting P2MP MPLS-TP transport paths. | |||
32 MPLS-TP MUST support unidirectional, co-routed bidirectional and | 40 MPLS-TP MUST support unidirectional point-to-multipoint transport | |||
associated bidirectional point-to-point transport paths. | ||||
33 The end points of a co-routed bidirectional transport path MUST | ||||
be aware of the pairing relationship of the forward and reverse | ||||
paths used to support the bidirectional service. | ||||
34 The intermediate nodes (including MEPs, MIPs and other internal | ||||
functions as appropriate) of a co-routed bidirectional transport | ||||
path at each (sub-)layer MUST be aware of the pairing | ||||
relationship of the forward and the backward directions of that | ||||
transport path. | ||||
35 The end points of an associated bidirectional transport path MUST | ||||
be aware of the pairing relationship of the forward and reverse | ||||
paths used to support the bidirectional service. | ||||
36 The intermediate nodes (including MEPs, MIPs and other internal | ||||
functions as appropriate) of an associated bidirectional | ||||
transport path at each (sub-)layer SHOULD NOT be aware of the | ||||
pairing relationship of the forward and the backward directions | ||||
of that transport path. | ||||
37 MPLS-TP MUST support bidirectional transport paths with | ||||
asymmetric bandwidth requirements, i.e. the amount of reserved | ||||
bandwidth differs between the forward and backward directions. | ||||
38 MPLS-TP MUST support unidirectional point-to-multipoint transport | ||||
paths. | paths. | |||
39 MPLS-TP MUST be extensible in order to accommodate new types of | 41 MPLS-TP MUST be extensible in order to accommodate new types of | |||
client layer networks and services. | client layer networks and services. | |||
40 MPLS-TP SHOULD support mechanisms to enable the reserved | 42 MPLS-TP SHOULD support mechanisms to enable the reserved | |||
bandwidth associated with a transport path to be increased | bandwidth associated with a transport path to be increased | |||
without impacting the existing traffic on that transport path | without impacting the existing traffic on that transport path | |||
provided enough resources are available. | provided enough resources are available. | |||
41 MPLS-TP SHOULD support mechanisms to enable the reserved | 43 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. | |||
42 MPLS-TP MUST support mechanisms which ensure the integrity of the | 44 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. | |||
43 MPLS-TP MUST support mechanisms to detect when loss of integrity | 45 MPLS-TP MUST support mechanisms to detect when loss of integrity | |||
of the transported customer's service traffic has occurred. | of the transported customer's service traffic has occurred. | |||
44 MPLS-TP MUST support an unambiguous and reliable means of | 46 MPLS-TP MUST support an unambiguous and reliable means of | |||
distinguishing users' (client) packets from MPLS-TP control | distinguishing users' (client) packets from MPLS-TP control | |||
packets (e.g. control plane, management plane, OAM and protection | packets (e.g. control plane, management plane, OAM and protection | |||
switching packets). | switching packets). | |||
2.4. Control plane requirements | 2.4. Control plane requirements | |||
This section defines the requirements that apply to an MPLS-TP | This section defines the requirements that apply to an MPLS-TP | |||
control plane. Note that it MUST be possible to operate an MPLS-TP | control plane. Note that it MUST be possible to operate an MPLS-TP | |||
network without using a control plane. | network without using a control plane. | |||
The ITU-T has defined an architecture for Automatically Switched | The ITU-T has defined an architecture for Automatically Switched | |||
Optical and Transport Networks (ASON/ASTN) in G.8080 [ITU.G8080.2006] | Optical Networks (ASON) in G.8080 [ITU.G8080.2006] and G.8080 Amd1 | |||
and G.8080 Amd1 [ITU.G8080.2008]. The control plane for MPLS-TP MUST | [ITU.G8080.2008]. The control plane for MPLS-TP MUST fit within the | |||
fit within the ASON/ASTN architecture. | ASON architecture. | |||
An interpretation of the ASON/ASTN signaling and routing requirements | An interpretation of the ASON/ASTN signaling and routing requirements | |||
in the context of GMPLS can be found in [RFC4139] and [RFC4258]. | in the context of GMPLS can be found in [RFC4139] and [RFC4258]. | |||
Additionally: | Additionally: | |||
45 It MUST be possible to operate and configure the MPLS-TP data | 47 It MUST be possible to operate and configure the MPLS-TP data | |||
plane without any IP forwarding capability in the MPLS-TP data | plane without any IP forwarding capability in the MPLS-TP data | |||
plane. | plane. i.e. the data plane only operates on the MPLS label. | |||
46 The MPLS-TP control pane MUST support control plane topology and | 48 The MPLS-TP control plane MUST support control plane topology and | |||
data plane topology independence. As a consequence a failure of | data plane topology independence. As a consequence a failure of | |||
the control plane does not imply that there has also been a | the control plane does not imply that there has also been a | |||
failure of the data plane. | failure of the data plane. | |||
47 The MPLS-TP control plane MUST be able to be operated independent | 49 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. | |||
48 MPLS-TP SHOULD define a solution to support an integrated control | 50 MPLS-TP SHOULD define a solution to support an integrated control | |||
plane encompassing MPLS-TP together with its server and client | plane encompassing MPLS-TP together with its server and client | |||
layer networks when these layer networks belong to the same | layer networks when these layer networks belong to the same | |||
administrative domain. | administrative domain. | |||
49 The MPLS-TP control plane MUST support establishing all the | 51 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 (i.e., | |||
unidirectional and bidirectional P2P, unidirectional P2MP, etc.) | unidirectional P2P, associated bidirectional P2P, co-routed | |||
including configuration of protection functions and any | bidirectional P2P, unidirectional P2MP) including configuration | |||
associated maintenance functions. | of protection functions and any associated maintenance functions. | |||
50 The MPLS-TP control plane MUST support the configuration and | 52 The MPLS-TP control plane MUST support the configuration and | |||
modification of OAM maintenance points as well as the activation/ | modification of OAM maintenance points as well as the activation/ | |||
deactivation of OAM when the transport path or transport service | deactivation of OAM when the transport path or transport service | |||
is established or modified. | is established or modified. | |||
51 An MPLS-TP control plane MUST support operation of the recovery | 53 An MPLS-TP control plane MUST support operation of the recovery | |||
functions described in Section 2.8. | functions described in Section 2.8. | |||
52 An MPLS-TP control plane MUST scale gracefully to support a large | 54 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. | |||
53 If a control plane is used for MPLS-TP, the control plane's | 55 If a control plane is used for MPLS-TP, following a control plane | |||
graceful restart capabilities, if any, MUST be supported. | failure, the control plane MUST be capable of restarting and | |||
relearning its previous state without impacting forwarding. | ||||
54 An MPLS-TP control plane MUST provide a mechanism for dynamic | 56 An MPLS-TP control plane MUST provide a mechanism for dynamic | |||
ownership transfer of the control of MPLS-TP transport paths from | ownership transfer of the control of MPLS-TP transport paths from | |||
the management plane to the control plane and vice versa. The | the management plane to the control plane and vice versa. The | |||
number of reconfigurations required in the data plane MUST be | number of reconfigurations required in the data plane MUST be | |||
minimized (preferably no data plane reconfiguration will be | minimized (preferably no data plane reconfiguration will be | |||
required). | required). | |||
2.5. Network Management (NM) requirements | 2.5. Network Management requirements | |||
For requirements related to NM functionality (Management Plane in | For requirements related to network management functionality | |||
ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements | (Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP | |||
document [I-D.ietf-mpls-tp-nm-req]. | Network Management requirements document [I-D.ietf-mpls-tp-nm-req]. | |||
2.6. Operation, Administration and Maintenance (OAM) requirements | 2.6. Operation, Administration and Maintenance (OAM) requirements | |||
For requirements related to OAM functionality for MPLS-TP, see the | For requirements related to OAM functionality for MPLS-TP, see the | |||
MPLS-TP OAM requirements document | MPLS-TP OAM requirements document | |||
[I-D.ietf-mpls-tp-oam-requirements]. | [I-D.ietf-mpls-tp-oam-requirements]. | |||
2.7. Network performance management (PM) requirements | 2.7. Network performance monitoring requirements | |||
For requirements related to PM functionality for MPLS-TP, see the | For requirements related to performance monitoring functionality for | |||
MPLS-TP OAM requirements document | MPLS-TP, see the MPLS-TP OAM requirements document | |||
[I-D.ietf-mpls-tp-oam-requirements]. | [I-D.ietf-mpls-tp-oam-requirements]. | |||
2.8. Recovery requirements | 2.8. Recovery requirements | |||
Network survivability plays a critical role in the delivery of | Network survivability plays a critical role in the delivery of | |||
reliable services. Network availability is a significant contributor | reliable services. Network availability is a significant contributor | |||
to revenue and profit. Service guarantees in the form of SLAs | to revenue and profit. Service guarantees in the form of SLAs | |||
require a resilient network that rapidly detects facility or node | require a resilient network that rapidly detects facility or node | |||
failures and restores network operation in accordance with the terms | failures and restores network operation in accordance with the terms | |||
of the SLA. | of the SLA. | |||
55 MPLS-TP MUST provide protection and restoration mechanisms. | 57 MPLS-TP MUST provide protection and restoration mechanisms. | |||
A. MPLS-TP recovery techniques SHOULD be identical (or as | A. MPLS-TP recovery techniques SHOULD be identical (or as | |||
similar as possible) to those already used in existing | similar as possible) to those already used in existing | |||
transport networks to simplify implementation and operations. | transport networks to simplify implementation and operations. | |||
However, this MUST NOT override any other requirement. | However, this MUST NOT override any other requirement. | |||
B. Recovery techniques used for P2P and P2MP SHOULD be identical | B. Recovery techniques used for P2P and P2MP SHOULD be identical | |||
to simplify implementation and operation. However, this MUST | to simplify implementation and operation. However, this MUST | |||
NOT override any other requirement. | NOT override any other requirement. | |||
56 MPLS-TP recovery mechanisms MUST be applicable at various levels | 58 MPLS-TP recovery mechanisms MUST be applicable at various levels | |||
throughout the network including support for link, transport | throughout the network including support for link, transport | |||
path, segment, concatenated segment and end to end recovery. | path, segment, concatenated segment and end to end recovery. | |||
57 MPLS-TP recovery paths MUST meet the SLA protection objectives of | 59 MPLS-TP recovery paths MUST meet the SLA protection objectives of | |||
the service. | the service. | |||
A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery | A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery | |||
times from the moment of fault detection in networks with | times from the moment of fault detection in networks with | |||
spans less than 1200 km. | spans less than 1200 km. | |||
B. For protection it MUST be possible to require protection of | B. For protection it MUST be possible to require protection of | |||
100% of the traffic on the protected path. | 100% of the traffic on the protected path. | |||
C. Recovery objectives SHOULD be configurable per transport | C. Recovery objectives SHOULD be configurable per transport | |||
path, and SHOULD support objectives for bandwidth and QoS. | path. | |||
D. Recovery MUST meet SLA requirements over multiple domains. | D. Recovery MUST meet SLA requirements over multiple domains. | |||
58 The recovery mechanisms SHOULD be applicable to any topology. | 60 The recovery mechanisms SHOULD be applicable to any topology. | |||
59 The recovery mechanisms MUST support the means to operate in | 61 The recovery mechanisms MUST support the means to operate in | |||
synergy with (including coordination of timing) the recovery | synergy with (including coordination of timing) the recovery | |||
mechanisms present in any client or server transport networks | mechanisms present in any client or server transport networks | |||
(for example, Ethernet, SDH, OTN, WDM) to avoid race conditions | (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions | |||
between the layers. | between the layers. | |||
60 MPLS-TP recovery and reversion mechanisms MUST prevent frequent | 62 MPLS-TP recovery and reversion mechanisms MUST prevent frequent | |||
operation of recovery in the event of an intermittent defect. | operation of recovery in the event of an intermittent defect. | |||
2.8.1. Data plane behavior requirements | 2.8.1. Data plane behavior requirements | |||
General protection and survivability requirements are expressed in | General protection and survivability requirements are expressed in | |||
terms of the behavior in the data plane. | terms of the behavior in the data plane. | |||
2.8.1.1. Protection | 2.8.1.1. Protection | |||
Note: Only nodes that are aware of the pairing relationship between | Note: Only nodes that are aware of the pairing relationship between | |||
the forward and backward directions of an associated bidirectional | the forward and backward directions of an associated bidirectional | |||
transport path can be used as end points to protect all or part of | transport path can be used as end points to protect all or part of | |||
that transport path. | that transport path. | |||
61 MPLS-TP MUST support 1+1 protection. | 63 It MUST be possible to provide protection for the MPLS-TP data | |||
plane without any IP forwarding capability in the MPLS-TP data | ||||
plane. i.e. the data plane only operates on the MPLS label. | ||||
64 MPLS-TP MUST support 1+1 protection. | ||||
A. Bidirectional 1+1 protection for P2P connectivity MUST be | A. Bidirectional 1+1 protection for P2P connectivity MUST be | |||
supported. | supported. | |||
B. Unidirectional 1+1 protection for P2P connectivity MUST be | B. Unidirectional 1+1 protection for P2P connectivity MUST be | |||
supported. | supported. | |||
C. Unidirectional 1+1 protection for P2MP connectivity MUST be | C. Unidirectional 1+1 protection for P2MP connectivity MUST be | |||
supported. | supported. | |||
62 MPLS-TP MUST support 1:n protection (including 1:1 protection). | 65 MPLS-TP MUST support the ability to share protection resources | |||
amongst a number of transport paths. | ||||
A. MPLS-TP 1:n protection MUST include bidirectional protection | 66 MPLS-TP MUST support 1:n protection (including 1:1 protection). | |||
switching for P2P connectivity, and this SHOULD be the | ||||
default behavior for 1:n protection. | A. Bidirectional 1:n protection for P2P connectivity MUST be | |||
supported, and SHOULD be the 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 and MAY be omitted from the MPLS-TP specifications. | required and MAY be omitted from the MPLS-TP specifications. | |||
D. The action of protection switching MUST NOT cause user data | D. The action of protection switching MUST NOT cause user data | |||
to loop. Backtracking is allowed. | to loop. Backtracking is allowed. | |||
Note: Support for extra traffic (as defined in [RFC4427]) is not | Note: Support for extra traffic (as defined in [RFC4427]) is not | |||
required in MPLS-TP and MAY be omitted from the MPLS-TP | required in MPLS-TP and MAY be omitted from the MPLS-TP | |||
specifications. | specifications. | |||
2.8.1.2. Restoration | 2.8.1.2. Sharing of protection resources | |||
63 The restoration transport path MUST be able to share resources | ||||
with the transport path being replaced (sometimes known as soft | ||||
rerouting). | ||||
64 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). | ||||
65 Preemption priority MUST be supported to allow restoration to | ||||
displace other transport paths in the event of resource | ||||
constraint. | ||||
2.8.1.3. Sharing of protection resources | ||||
66 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh | ||||
restoration. | ||||
67 MPLS-TP MUST support the definition of shared protection groups | 67 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh recovery. | |||
to allow the coordination of protection actions resulting from | ||||
triggers caused by events at different locations in the network. | ||||
68 MPLS-TP MUST support sharing of protection resources such that | 68 MPLS-TP MUST support sharing of protection resources such that | |||
protection paths that are known not to be required concurrently | protection paths that are known not to be required concurrently | |||
can share the same resources. | can share the same resources. | |||
2.8.1.4. Reversion | 2.8.1.3. Reversion | |||
69 MPLS-TP protection mechanisms MUST support revertive and non- | 69 MPLS-TP protection mechanisms MUST support revertive and non- | |||
revertive behavior. | revertive behavior. | |||
70 MPLS-TP restoration mechanisms MUST support revertive and non- | 70 MPLS-TP restoration mechanisms MUST support revertive and non- | |||
revertive behavior. | revertive behavior. | |||
2.8.2. Triggers for protection, restoration, and reversion | 2.8.2. Restoration | |||
71 The restoration transport path MUST be able to share resources | ||||
with the transport path being replaced (sometimes known as soft | ||||
rerouting). | ||||
72 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). | ||||
73 Preemption priority MUST be supported to allow restoration to | ||||
displace other transport paths in the event of resource | ||||
constraint. | ||||
2.8.3. Triggers for protection, restoration, and reversion | ||||
Recovery actions may be triggered from different places as follows: | Recovery actions may be triggered from different places as follows: | |||
71 MPLS-TP MUST support physical layer fault indication triggers. | 74 MPLS-TP MUST support physical layer fault indication triggers. | |||
72 MPLS-TP MUST support OAM-based triggers. | 75 MPLS-TP MUST support OAM-based triggers. | |||
73 MPLS-TP MUST support management plane triggers (e.g., forced | 76 MPLS-TP MUST support management plane triggers (e.g., forced | |||
switch, etc.). | switch, etc.). | |||
74 There MUST be a mechanism to allow administrative recovery | 77 There MUST be a mechanism to allow administrative recovery | |||
actions to be distinguished from recovery actions initiated by | actions to be distinguished from recovery actions initiated by | |||
other triggers. | other triggers. | |||
75 Where a control plane is present, MPLS-TP SHOULD support control | 78 Where a control plane is present, MPLS-TP SHOULD support control | |||
plane triggers. | plane restoration triggers. | |||
76 MPLS-TP protection mechanisms MUST support priority logic to | 79 MPLS-TP protection mechanisms MUST support priority logic to | |||
negotiate and accommodate coexisting requests (i.e., multiple | negotiate and accommodate coexisting requests (i.e., multiple | |||
requests) for protection switching (e.g., administrative requests | requests) for protection switching (e.g., administrative requests | |||
and requests due to link/node failures). | and requests due to link/node failures). | |||
2.8.3. Management plane operation of protection and restoration | 2.8.4. Management plane operation of protection and restoration | |||
All functions described here are for control by the operator. | All functions described here are for control by the operator. | |||
77 It MUST be possible to configure protection paths and protection- | 80 It MUST be possible to configure protection paths and protection- | |||
to-working path relationships (sometimes known as protection | to-working path relationships (sometimes known as protection | |||
groups). | groups). | |||
78 There MUST be support for pre-calculation of recovery paths. | 81 There MUST be support for pre-calculation of recovery paths. | |||
79 There MUST be support for pre-provisioning of recovery paths. | 82 There MUST be support for pre-provisioning of recovery paths. | |||
80 The external controls as defined in [RFC4427] MUST be supported. | 83 The external controls as defined in [RFC4427] MUST be supported. | |||
A. External controls overruled by higher priority requests | A. External controls overruled by higher priority requests | |||
(e.g., administrative requests and requests due to link/node | (e.g., administrative requests and requests due to link/node | |||
failures) or unable to be signaled to the remote end (e.g. | failures) or unable to be signaled to the remote end (e.g. | |||
because of a protection state coordination fail) MUST be | because of a protection state coordination fail) MUST be | |||
dropped. | dropped. | |||
81 There MUST be support for the configuration of timers used for | 84 It MUST be possible to test and validate any protection/ | |||
recovery operation. | restoration mechanisms and protocols: | |||
82 Restoration resources MAY be pre-planned and selected a priori, | A. Including the integrity of the protection/recovery transport | |||
path. | ||||
B. Without triggering the actual protection/restoration. | ||||
C. While the working path is in service. | ||||
D. While the working path is out of service. | ||||
85 Restoration resources MAY be pre-planned and selected a priori, | ||||
or computed after failure occurrence. | or computed after failure occurrence. | |||
83 When preemption is supported for restoration purposes, it MUST be | 86 When preemption is supported for restoration purposes, it MUST be | |||
possible for the operator to configure it. | possible for the operator to configure it. | |||
84 The management plane MUST provide indications of protection | 87 The management plane MUST provide indications of protection | |||
events and triggers. | events and triggers. | |||
85 The management plane MUST allow the current protection status of | 88 The management plane MUST allow the current protection status of | |||
all transport paths to be determined. | all transport paths to be determined. | |||
2.8.4. Control plane and in-band OAM operation of recovery | 2.8.5. Control plane and in-band OAM operation of recovery | |||
86 The MPLS-TP control plane (which is not mandatory in an MPLS-TP | 89 The MPLS-TP control plane (which is not mandatory in an MPLS-TP | |||
implementation) MUST be capable of supporting: | implementation) MUST be capable of supporting: | |||
A. establishment and maintenance of all recovery entities and | A. establishment and maintenance of all recovery entities and | |||
functions | functions | |||
B. signaling of administrative control | B. signaling of administrative control | |||
C. protection state coordination (PSC). Since control plane | C. protection state coordination (PSC). Since control plane | |||
network topology is independent from the data plane network | network topology is independent from the data plane network | |||
topology, the PSC supported by the MPLS-TP control plane MAY | topology, the PSC supported by the MPLS-TP control plane MAY | |||
run on resources different than the data plane resources | run on resources different than the data plane resources | |||
handled within the recovery mechanism (e.g. backup). | handled within the recovery mechanism (e.g. backup). | |||
87 In-band OAM MUST be capable of supporting: | 90 In-band OAM MUST be capable of supporting: | |||
A. signaling of administrative control | A. signaling of administrative control | |||
B. protection state coordination (PSC). Since in-band OAM tools | B. protection state coordination (PSC). Since in-band OAM tools | |||
share the data plane with the carried transport service, in | share the data plane with the carried transport service, in | |||
order to optimize the usage of network resources, the PSC | order to optimize the usage of network resources, the PSC | |||
supported by in-band OAM MUST run on protection resources. | supported by in-band OAM MUST run on protection resources. | |||
2.8.5. Topology-specific recovery mechanisms | 2.8.6. Topology-specific recovery mechanisms | |||
88 MPLS-TP MAY support recovery mechanisms that are optimized for | 91 MPLS-TP MAY support recovery mechanisms that are optimized for | |||
specific network topologies. These mechanisms MUST be | specific network topologies. These mechanisms MUST be | |||
interoperable with the mechanisms defined for arbitrary topology | interoperable with the mechanisms defined for arbitrary topology | |||
(mesh) networks to enable protection of end-to-end transport | (mesh) networks to enable protection of end-to-end transport | |||
paths. | paths. | |||
2.8.5.1. Ring protection | 2.8.6.1. Ring protection | |||
Several service providers have expressed a high level of interest in | Several service providers have expressed a high level of interest in | |||
operating MPLS-TP in ring topologies and require a high level of | operating MPLS-TP in ring topologies and require a high level of | |||
survivability function in these topologies. The requirements listed | survivability function in these topologies. The requirements listed | |||
below have been collected from these service providers and from the | below have been collected from these service providers and from the | |||
ITU-T. | ITU-T. | |||
The main objective in considering a specific topology (such as a | The main objective in considering a specific topology (such as a | |||
ring) is to determine whether it is possible to optimize any | ring) is to determine whether it is possible to optimize any | |||
mechanisms such that the performance of those mechanisms within the | mechanisms such that the performance of those mechanisms within the | |||
skipping to change at page 26, line 14 | skipping to change at page 26, line 8 | |||
e. When a control plane is supported, minimize the impact on | e. When a control plane is supported, minimize the impact on | |||
signaling and routing information exchange during protection - | signaling and routing information exchange during protection - | |||
less than are required by other recovery mechanisms. | less than are required by other recovery mechanisms. | |||
It may be observed that the requirements in this section are fully | It may be observed that the requirements in this section are fully | |||
compatible with the generic requirements expressed above, and that no | compatible with the generic requirements expressed above, and that no | |||
requirements that are specific to ring topologies have been | requirements that are specific to ring topologies have been | |||
identified. | identified. | |||
89 MPLS-TP MUST include recovery mechanisms that operate in any | 92 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. | |||
90 When a network is constructed from interconnected rings, MPLS-TP | 93 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. | |||
91 MPLS-TP recovery in a ring MUST protect unidirectional and | 94 MPLS-TP recovery in a ring MUST protect unidirectional and | |||
bidirectional P2P transport paths. | bidirectional P2P transport paths. | |||
92 MPLS-TP recovery in a ring MUST protect unidirectional P2MP | 95 MPLS-TP recovery in a ring MUST protect unidirectional P2MP | |||
transport paths. | transport paths. | |||
93 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching | 96 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 | 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. | network with a 16 nodes ring with less than 1200 km of fiber. | |||
94 The protection switching time in a ring MUST be independent of | 97 The protection switching time in a ring MUST be independent of | |||
the number of LSPs crossing the ring. | the number of LSPs crossing the ring. | |||
95 Recovery actions in a ring MUST be data plane functions | 98 The configuration and operation of recovery mechanisms in a ring | |||
triggered by different elements of control. The triggers are | ||||
configured by management or control planes and are subject to | ||||
configurable policy. | ||||
96 The configuration and operation of recovery mechanisms in a ring | ||||
MUST scale well with: | MUST scale well with: | |||
A. the number of transport paths (must be better than linear | A. the number of transport paths (must be better than linear | |||
scaling) | scaling) | |||
B. the number of nodes on the ring (must be at least as good as | B. the number of nodes on the ring (must be at least as good as | |||
linear scaling) | linear scaling) | |||
C. the number of ring interconnects (must be at least as good | C. the number of ring interconnects (must be at least as good | |||
as linear scaling) | as linear scaling) | |||
97 Recovery techniques used in a ring MUST NOT prevent the ring | ||||
99 Recovery techniques used in a ring MUST NOT prevent the ring | ||||
from being connected to a general MPLS-TP network in any | from being connected to a general MPLS-TP network in any | |||
arbitrary way, and MUST NOT prevent the operation of recovery | arbitrary way, and MUST NOT prevent the operation of recovery | |||
techniques in the rest of the network. | techniques in the rest of the network. | |||
98 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally | 100 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally | |||
applicable in physical and logical rings. | applicable in physical and logical rings. | |||
99 Recovery techniques in a ring SHOULD be identical (or as similar | 101 Recovery techniques in a ring SHOULD be identical (or as similar | |||
as possible) to those in general transport networks to simplify | as possible) to those in general transport networks to simplify | |||
implementation and operations. However, this MUST NOT override | implementation and operations. However, this MUST NOT override | |||
any other requirement. | any other requirement. | |||
100 Recovery techniques in logical and physical rings SHOULD be | 102 Recovery techniques in logical and physical rings SHOULD be | |||
identical to simplify implementation and operation. However, | identical to simplify implementation and operation. However, | |||
this MUST NOT override any other requirement. | this MUST NOT override any other requirement. | |||
101 The default recovery scheme in a ring MUST be bidirectional | 103 The default recovery scheme in a ring MUST be bidirectional | |||
recovery in order to simplify the recovery operation. | recovery in order to simplify the recovery operation. | |||
102 The recovery mechanism in a ring MUST support revertive | 104 The recovery mechanism in a ring MUST support revertive | |||
switching, which MUST be the default behavior. This allows | switching, which MUST be the default behavior. This allows | |||
optimization of the use of the ring resources, and restores the | optimization of the use of the ring resources, and restores the | |||
preferred quality conditions for normal traffic (e.g., delay) | preferred quality conditions for normal traffic (e.g., delay) | |||
when the recovery mechanism is no longer needed. | when the recovery mechanism is no longer needed. | |||
103 The recovery mechanisms in a ring MUST support ways to allow | 105 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. | |||
104 It MUST be possible to lockout (disable) protection mechanisms | 106 It MUST be possible to lockout (disable) protection mechanisms | |||
on selected links (spans) in a ring (depending on operator's | on selected links (spans) in a ring (depending on operator's | |||
need). This may require lockout mechanisms to be applied to | need). This may require lockout mechanisms to be applied to | |||
intermediate nodes within a transport path. | intermediate nodes within a transport path. | |||
105 MPLS-TP recovery mechanisms in a ring: | 107 MPLS-TP recovery mechanisms in a ring: | |||
A. MUST include a mechanism to allow an implementation to | A. MUST include a mechanism to allow an implementation to | |||
handle (including the coordination of) coexisting requests | handle (including the coordination of) coexisting requests | |||
or triggers (i.e., multiple requests - not necessarily | or triggers (i.e., multiple requests - not necessarily | |||
arriving simultaneously and located anywhere in the ring) | arriving simultaneously and located anywhere in the ring) | |||
for protection switching based on priority. Note that such | for protection switching based on priority. Note that such | |||
coordination is the ring equivalent of the definition of | coordination is the ring equivalent of the definition of | |||
shared protection groups. | shared protection groups. | |||
B. MAY support multiple failures without reconfiguring the | B. MAY support multiple failures without reconfiguring the | |||
protection actions. | protection actions. | |||
106 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a | 108 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. | |||
107 MPLS-TP MUST support the sharing of protection bandwidth in a | 109 MPLS-TP MUST support the sharing of protection bandwidth in a | |||
ring by allowing best effort traffic. | ring by allowing best effort traffic. | |||
108 MPLS-TP MUST support sharing of ring protection resources such | 110 MPLS-TP MUST support sharing of ring protection resources such | |||
that protection paths that are known not to be required | that protection paths that are known not to be required | |||
concurrently can share the same resources. | concurrently can share the same resources. | |||
2.9. QoS requirements | 2.9. QoS requirements | |||
Carriers require advanced traffic management capabilities to enforce | Carriers require advanced traffic management capabilities to enforce | |||
and guarantee the QoS parameters of customers' SLAs. | and guarantee the QoS parameters of customers' SLAs. | |||
Quality of service mechanisms are REQUIRED in an MPLS-TP network to | Quality of service mechanisms are REQUIRED in an MPLS-TP network to | |||
ensure: | ensure: | |||
109 Support for differentiated services and different traffic types | 111 Support for differentiated services and different traffic types | |||
with traffic class separation associated with different traffic. | with traffic class separation associated with different traffic. | |||
110 Enabling the provisioning and the guarantee of Service Level | 112 Enabling the provisioning and the guarantee of Service Level | |||
Specifications (SLS), with support for hard and relative end-to- | Specifications (SLS), with support for hard and relative end-to- | |||
end bandwidth guaranteed. | end bandwidth guaranteed. | |||
111 Support of services, which are sensitive to jitter and delay. | 113 Support of services, which are sensitive to jitter and delay. | |||
112 Guarantee of fair access, within a particular class, to shared | 114 Guarantee of fair access, within a particular class, to shared | |||
resources. | resources. | |||
113 Guaranteed resources for in-band control and management plane | 115 Guaranteed resources for in-band control and management plane | |||
traffic regardless of the amount of data plane traffic. | traffic regardless of the amount of data plane traffic. | |||
114 Carriers are provided with the capability to efficiently support | 116 Carriers are provided with the capability to efficiently support | |||
service demands over the MPLS-TP network. This MUST include | service demands over the MPLS-TP network. This MUST include | |||
support for a flexible bandwidth allocation scheme. | support for a flexible bandwidth allocation scheme. | |||
2.10. Security requirements | 2.10. Security requirements | |||
For a description of the security threats relevant in the context of | For a description of the security threats relevant in the context of | |||
MPLS and GMPLS and the defensive techniques to combat those threats | MPLS and GMPLS and the defensive techniques to combat those threats | |||
see the Security Framework for MPLS & GMPLS Networks | see the Security Framework for MPLS & GMPLS Networks | |||
[I-D.ietf-mpls-mpls-and-gmpls-security-framework]. | [I-D.ietf-mpls-mpls-and-gmpls-security-framework]. | |||
skipping to change at page 30, line 6 | skipping to change at page 29, line 45 | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
Label Switching Architecture", RFC 3031, January 2001. | Label Switching Architecture", RFC 3031, January 2001. | |||
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- | [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- | |||
Edge (PWE3) Architecture", RFC 3985, March 2005. | Edge (PWE3) Architecture", RFC 3985, March 2005. | |||
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and | [RFC4929] Andersson, L. and A. Farrel, "Change Process for | |||
Restoration) Terminology for Generalized Multi-Protocol | Multiprotocol Label Switching (MPLS) and Generalized MPLS | |||
Label Switching (GMPLS)", RFC 4427, March 2006. | (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, | |||
June 2007. | ||||
[I-D.ietf-mpls-mpls-and-gmpls-security-framework] | ||||
Fang, L. and M. Behringer, "Security Framework for MPLS | ||||
and GMPLS Networks", | ||||
draft-ietf-mpls-mpls-and-gmpls-security-framework-05 (work | ||||
in progress), November 2008. | ||||
[I-D.ietf-pwe3-ms-pw-arch] | ||||
Bocci, M. and S. Bryant, "Requirements for OAM in MPLS | ||||
Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work | ||||
in progress), September 2008. | ||||
[ITU.G805.2000] | [ITU.G805.2000] | |||
International Telecommunications Union, "Generic | International Telecommunications Union, "Generic | |||
functional architecture of transport networks", ITU- | functional architecture of transport networks", ITU- | |||
T Recommendation G.805, March 2000. | T Recommendation G.805, March 2000. | |||
[ITU.G8080.2006] | [ITU.G8080.2006] | |||
International Telecommunications Union, "Architecture for | International Telecommunications Union, "Architecture for | |||
the automatically switched optical network (ASON)", ITU- | the automatically switched optical network (ASON)", ITU- | |||
T Recommendation G.8080, June 2006. | T Recommendation G.8080, June 2006. | |||
skipping to change at page 31, line 6 | skipping to change at page 30, line 36 | |||
[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol | [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol | |||
Label Switching (GMPLS) Routing for the Automatically | Label Switching (GMPLS) Routing for the Automatically | |||
Switched Optical Network (ASON)", RFC 4258, November 2005. | Switched Optical Network (ASON)", RFC 4258, November 2005. | |||
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the | [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the | |||
Interpretation of Generalized Multiprotocol Label | Interpretation of Generalized Multiprotocol Label | |||
Switching (GMPLS) Terminology within the Context of the | Switching (GMPLS) Terminology within the Context of the | |||
ITU-T's Automatically Switched Optical Network (ASON) | ITU-T's Automatically Switched Optical Network (ASON) | |||
Architecture", RFC 4397, February 2006. | Architecture", RFC 4397, February 2006. | |||
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and | ||||
Restoration) Terminology for Generalized Multi-Protocol | ||||
Label Switching (GMPLS)", RFC 4427, March 2006. | ||||
[I-D.ietf-mpls-mpls-and-gmpls-security-framework] | ||||
Fang, L. and M. Behringer, "Security Framework for MPLS | ||||
and GMPLS Networks", | ||||
draft-ietf-mpls-mpls-and-gmpls-security-framework-05 (work | ||||
in progress), November 2008. | ||||
[I-D.ietf-mpls-tp-nm-req] | [I-D.ietf-mpls-tp-nm-req] | |||
Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network | Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network | |||
Management Requirements", draft-ietf-mpls-tp-nm-req-00 | Management Requirements", draft-ietf-mpls-tp-nm-req-01 | |||
(work in progress), January 2009. | (work in progress), April 2009. | |||
[I-D.helvoort-mpls-tp-rosetta-stone] | ||||
van Helvoort, H., Andersson, L., and N. Sprecher, "A | ||||
Thesaurus for the Terminology used in Multiprotocol Label | ||||
Switching Transport Profile (MPLS-TP) drafts/RFCs and | ||||
ITU-T's Transport Network Recommendations.", | ||||
draft-helvoort-mpls-tp-rosetta-stone-00 (work in | ||||
progress), March 2009. | ||||
[I-D.ietf-mpls-tp-oam-requirements] | [I-D.ietf-mpls-tp-oam-requirements] | |||
Vigoureux, M., Ward, D., and M. Betts, "Requirements for | Vigoureux, M., Ward, D., and M. Betts, "Requirements for | |||
OAM in MPLS Transport Networks", | OAM in MPLS Transport Networks", | |||
draft-ietf-mpls-tp-oam-requirements-01 (work in progress), | draft-ietf-mpls-tp-oam-requirements-01 (work in progress), | |||
November 2008. | November 2008. | |||
[I-D.ietf-pwe3-ms-pw-arch] | ||||
Bocci, M. and S. Bryant, "Requirements for OAM in MPLS | ||||
Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work | ||||
in progress), September 2008. | ||||
[ITU.Y1401.2008] | [ITU.Y1401.2008] | |||
International Telecommunications Union, "Principles of | International Telecommunications Union, "Principles of | |||
interworking", ITU-T Recommendation Y.1401, February 2008. | interworking", ITU-T Recommendation Y.1401, February 2008. | |||
[ITU.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. | |||
Authors' Addresses | Authors' Addresses | |||
End of changes. 138 change blocks. | ||||
250 lines changed or deleted | 270 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/ |