--- 1/draft-ietf-mpls-tp-requirements-01.txt 2009-01-07 14:12:22.000000000 +0100 +++ 2/draft-ietf-mpls-tp-requirements-02.txt 2009-01-07 14:12:22.000000000 +0100 @@ -1,50 +1,60 @@ Network Working Group B. Niven-Jenkins, Ed. Internet-Draft BT Intended status: Informational D. Brungard, Ed. -Expires: June 15, 2009 AT&T +Expires: July 7, 2009 AT&T M. Betts, Ed. Nortel Networks N. Sprecher Nokia Siemens Networks S. Ueno NTT - December 12, 2008 + January 3, 2009 MPLS-TP Requirements - draft-ietf-mpls-tp-requirements-01 + draft-ietf-mpls-tp-requirements-02 Status of this Memo - By submitting this Internet-Draft, each author represents that any - 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 - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 15, 2009. + This Internet-Draft will expire on July 7, 2009. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Abstract This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union (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 International Telecommunications Union - Telecommunications Standardization Sector (ITU-T). @@ -60,80 +70,85 @@ Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Transport network overview . . . . . . . . . . . . . . . . 7 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 8 - 2.1. General requirements . . . . . . . . . . . . . . . . . . . 8 - 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 10 + 2.1. General requirements . . . . . . . . . . . . . . . . . . . 9 + 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 11 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 11 2.4. Control plane requirements . . . . . . . . . . . . . . . . 12 2.5. Network Management (NM) requirements . . . . . . . . . . . 13 2.6. Operation, Administration and Maintenance (OAM) - requirements . . . . . . . . . . . . . . . . . . . . . . . 13 - 2.7. Network performance management (PM) requirements . . . . . 13 - 2.8. Recovery & Survivability requirements . . . . . . . . . . 13 - 2.8.1. Data plane behavior requirements . . . . . . . . . . . 14 - 2.8.2. Triggers for protection, restoration, and reversion . 16 + requirements . . . . . . . . . . . . . . . . . . . . . . . 14 + 2.7. Network performance management (PM) requirements . . . . . 14 + 2.8. Recovery & Survivability requirements . . . . . . . . . . 14 + 2.8.1. Data plane behavior requirements . . . . . . . . . . . 15 + 2.8.2. Triggers for protection, restoration, and reversion . 17 2.8.3. Management plane operation of protection and - restoration . . . . . . . . . . . . . . . . . . . . . 16 - 2.8.4. Control plane and in-band OAM operation of recovery . 17 - 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 17 - 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 21 + restoration . . . . . . . . . . . . . . . . . . . . . 17 + 2.8.4. Control plane and in-band OAM operation of recovery . 18 + 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 18 + 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 22 2.10. Security requirements . . . . . . . . . . . . . . . . . . 22 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . . 23 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 - Intellectual Property and Copyright Statements . . . . . . . . . . 26 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction For many years, Synchronous Optical Networking (SONET)/Synchronous Digital hierarchy (SDH) has provided carriers with a high benchmark for reliability and operational simplicity. With the accelerating - growth of packet-based services (such as Ethernet, Voice over IP - (VoIP), Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP - Television (IPTV), Radio Access Network (RAN) backhauling, etc.), - carriers are in need of capabilities to efficiently support packet- - based services on their transport networks. The need to increase - their revenue while remaining competitive forces operators to look - for the lowest network Total Cost of Ownership (TCO). Investment in - equipment and facilities (Capital Expenditure (CAPEX)) and - Operational Expenditure (OPEX) should be minimized. + growth and penetration of: + + o Packet-based services such as Ethernet, Voice over IP (VoIP), + Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP + Television (IPTV), Radio Access Network (RAN) backhauling, etc. + + o Applications with various bandwidth and QoS requirements. + + Carriers are in need of technologies capable of efficiently + supporting packet-based services and applications on their transport + networks. The need to increase their revenue while remaining + competitive forces operators to look for the lowest network Total + Cost of Ownership (TCO). Investment in equipment and facilities + (Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX) + should be minimized. Carriers are considering migrating or evolving to packet transport networks in order to reduce their costs and to improve their ability to support services with guaranteed Service Level Agreements (SLAs). For carriers it is important that migrating from SONET/SDH to packet transport networks should not involve dramatic changes in network operation, should not necessitate extensive retraining, and should not require major changes to existing work practices. The aim is to preserve the look-and-feel to which carriers have become accustomed in deploying their SONET/SDH networks, while providing common, multi- layer operations, resiliency, control and management for packet, circuit and lambda transport networks. Transport carriers require control and deterministic usage of network resources. They need end-to-end control to engineer network paths and to efficiently utilize network resources. They require - capabilities to support static (Operational Support System (OSS) + capabilities to support static (Operations Support System (OSS) based) or dynamic (control plane) provisioning of deterministic, protected and secured services and their associated resources. Carriers will still need to cope with legacy networks (which are composed of many layers and technologies), thus the packet transport network should interwork with other packet and transport networks (both horizontally and vertically). Vertical interworking is also known as client/server or network interworking. Horizontal interworking is also known as peer-partition or service interworking. For more details on each type of interworking and some of the issues @@ -193,69 +208,75 @@ etc. Examples of such domains include IGP areas and Autonomous Systems. Layer network: A layer network as defined in G.805 [ITU.G805.2000] provides for the transfer of client information and independent operations (OAM) of the client OAM. For an explanation of how a layer network as described by G.805 relates to the OSI concept of layering see Appendix I of Y.2611 [ITU.Y2611.2006]. 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 within a layer network. A + link is not necessarily a physical link but can also be supported by + a transport path in the server layer (e.g. SONET/SDH, OTN or + MPLS-TP). 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. 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 - for encapsulation and OAM of a MPLS-TP transport path client layer. - A section layer may provide for aggregation of multiple MPLS-TP - clients. - - 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) - within a path, or the entire end-to-end-path. - - Service layer: A layer network in which transport paths are used to - carry a customer's (individual or bundled) service (may be point-to- - point, point-to-multipoint or multipoint-to-multipoint services). + Section: A section is a server layer (which may be MPLS-TP or a + different technology) which provides for encapsulation and OAM of a + MPLS-TP transport path client layer. A section layer may provide for + aggregation of multiple MPLS-TP clients. - Span: A span is synonymous with a link. + Segment: A segment is a single resource or a set of cross-connected + resources that constitutes part of a path. A segment may be a single + link (hop) within a path, a series of adjacent links (hops) within a + path, or the entire end-to-end-path. - 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 - one or more segment(s) of a PW. + 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 segment or any other + ordered sequence of contiguous links and/or segments of a transport + path. - Transport path: A connection as defined in G.805 [ITU.G805.2000]. A - Transport path corresponds to an MPLS-TP LSP or to an MPLS-TP LSP and - its associated PW or PWs (Single Segment or Multi-Segment). + Transport path: A network connection as defined in G.805 + [ITU.G805.2000]. A Transport path corresponds to an MPLS-TP LSP or + to an MPLS-TP LSP and its associated PW or PWs (Single Segment or + Multi-Segment). Transport path layer: A layer network which provides point-to-point or point-to-multipoint transport paths which are used to carry a higher (client) layer network or aggregates of higher (client) layer - networks, for example the network service layer. It provides for + networks, for example the transport service layer. It provides for independent OAM (of the client OAM) in the transport of the clients. + Transport service layer: A layer network in which transport paths are + used to carry a customer's (individual or bundled) service (may be + point-to-point, point-to-multipoint or multipoint-to-multipoint + services). + Transmission media layer: A layer network which provides sections (two-port point-to-point connections) to carry the aggregate of network transport path or network service layers on various physical media. 1.2. Transport network overview The connection (or transport path) service is the basic service provided by a transport network. The purpose of a transport network is to carry its clients (i.e. the stream of client PDUs or client @@ -299,21 +320,25 @@ may then be aggregated into a connection for transport through the network in order to optimize network management. Server layer OAM is used to monitor the transport integrity of the client layer or client aggregate. At any hop, the aggregated signals may be further aggregated in lower layer transport network paths for transport across intermediate shared links. The encapsulated client signals are extracted at the edges of aggregation domains, and are either delivered to the client or forwarded to another domain. In the core of the network, only the server layer aggregated signals are monitored; individual client signals are monitored at the network - boundary in the client layer network. + boundary in the client layer network. Although the connectivity of + the client of the transport path layer may be point-to-point, point- + to-multipoint or multipoint-to-multipoint, the transport path layer + itself only provides point-to-point or point-to-multipoint transport + paths which are used to carry the client. Quality-of-service mechanisms are required in the packet transport network to ensure the prioritization of critical services, to guarantee BW and to control jitter and delay. 2. MPLS-TP Requirements 2.1. General requirements 1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as @@ -336,51 +361,54 @@ 5 MPLS-TP MUST support traffic engineered point to point (P2P) and point to multipoint (P2MP) transport paths. 6 MPLS-TP MUST support the logical separation of the control and management planes from the data plane. 7 MPLS-TP MUST allow the physical separation of the control and management planes from the data plane. - 8 MPLS-TP MUST support static provisioning of transport paths via a - Network Management System (NMS) or Operational Support Syste - (OSS), i.e. via the management plane. + 8 MPLS-TP MUST support static provisioning of transport paths via + an OSS, i.e. via the management plane. 9 Mechanisms in an MPLS-TP network that satisfy functional requirements that are common to general transport networks (i.e., independent of technology) SHOULD be manageable in a way that is coherent with the way the equivalent mechanisms are managed in other transport networks. 10 Static provisioning MUST NOT depend on the presence of any element of a control plane. 11 MPLS-TP MUST support the capability for network operation - (including OAM) via the management plane (without the use of any - control plane protocols). + (including OAM and recovery) 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. 13 The MPLS-TP data plane MUST be capable of forwarding data and taken recovery actions independently of the control or management plane used to operate the MPLS-TP layer network. That is, the MPLS-TP data plane MUST continue to operate normally if the management plane or control plane that configured the transport paths fails. - 14 MPLS-TP MUST support transport paths through multiple homogeneous + 14 MPLS-TP SHOULD support mechanisms to avoid or minimize traffic + impact (e.g. packet delay, reordering and loss) during network + reconfiguration. + + 15 MPLS-TP MUST support transport paths through multiple homogeneous domains. - 15 MPLS-TP MUST NOT dictate the deployment of any particular network + 16 MPLS-TP MUST NOT dictate the deployment of any particular network topology either physical or logical, however: A. It MUST be possible to deploy MPLS-TP in rings. 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. @@ -388,158 +416,171 @@ 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 + 17 MPLS-TP MUST be able to scale gracefully with growing and increasingly complex network topologies as well as with increasing bandwidth demands, number of customers, and number of services. - 17 MPLS-TP SHOULD support mechanisms to safeguard against the + 18 MPLS-TP SHOULD support mechanisms to safeguard against the provisioning of transport paths which contain forwarding loops. 2.2. Layering requirements - 18 An MPLS-TP network MUST be able to support one or more client + 19 An MPLS-TP network MUST be able to support one or more client network layers, and MUST be able to use one or more server network layers. - 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 - network. + 20 A solution MUST be provided to support the transport of MPLS-TP + transport paths over MPLS-TP (MPLS-TP as a client of MPLS-TP) - 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 - networks (such as Ethernet, OTN, etc.) + 21 A generic and extensible solution MUST be provided to support the + transport of any client layer network (e.g. Ethernet, ATM, FR, + etc.) over an MPLS-TP layer network. - 21 In an environment where an MPLS-TP layer network is supporting a + 22 A solution MUST be provided to support the transport of MPLS-TP + transport paths over any server layer network (such as Ethernet, + SONET/SDH, OTN, etc.). + + 23 In an environment where an MPLS-TP layer network is supporting a client network, and the MPLS-TP layer network is supported by a server layer network then operation of the MPLS-TP layer network MUST be possible without any dependencies on the server or client network. - 22 It MUST be possible to operate the layers of a multi-layer + 24 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. Different administrative groups may be responsible for the same layer network or different layer networks. - 23 It MUST be possible to hide MPLS-TP layer network addressing and + 25 It MUST be possible to hide MPLS-TP layer network addressing and other information (e.g. topology) from client layers. 2.3. Data plane requirements - 24 The identification of each transport path within its aggregate + 26 The identification of each transport path within its aggregate MUST be supported. - 25 A label in a particular section MUST uniquely identify the - transport path. + 27 A label in a particular link MUST uniquely identify the transport + path within that link. - 26 A transport path's source MUST be identifiable at its - destination. + 28 A transport path's source MUST be identifiable at its destination + within its layer network. - 27 MPLS-TP MUST support MPLS labels that are assigned by the + 29 MPLS-TP MUST support MPLS labels that are assigned by the downstream (with respect to data flow) node per [RFC3031] and [RFC3473] and MAY support context-specific MPLS labels as defined in [RFC5331]. - 28 It MUST be possible to operate and configure the MPLS-TP data + 30 It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP forwarding capability in the MPLS-TP data plane. - 29 MPLS-TP MUST support both unidirectional and bidirectional point- + 31 MPLS-TP MUST support both unidirectional and bidirectional point- to-point transport paths. - 30 An MPLS-TP network MUST require the forward and backward + 32 An MPLS-TP network MUST require the forward and backward directions of a bidirectional transport path to follow the same path at each layer. - 31 The intermediate nodes at each layer MUST be aware about the + 33 The intermediate nodes at each layer MUST be aware about the pairing relationship of the forward and the backward directions belonging to the same bi-directional transport path. - 32 MPLS-TP MAY support transport paths with asymmetric bandwidth + 34 MPLS-TP MAY support transport paths with asymmetric bandwidth requirements, i.e. the amount of reserved bandwidth differs between the forward and backward directions. - 33 MPLS-TP MUST support unidirectional point-to-multipoint transport + 35 MPLS-TP MUST support unidirectional point-to-multipoint transport paths. - 34 MPLS-TP MUST be able to accommodate new types of client networks - and services. - - 35 MPLS-TP SHOULD support mechanisms to minimize traffic impact - during network reconfiguration. + 36 MPLS-TP MUST be extensible in order to accommodate new types of + client networks and services. - 36 MPLS-TP SHOULD support mechanisms to enable the reserved + 37 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 + 38 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. + 39 MPLS-TP MUST support mechanisms which ensure the integrity of the + transported customer's service traffic. - 39 MPLS-TP MUST support an unambiguous and reliable means of + 40 MPLS-TP MUST support an unambiguous and reliable means of distinguishing users' (client) packets from MPLS-TP control packets (e.g. control plane, management plane, OAM and protection switching packets). 2.4. Control plane requirements + This section defines the requirements that apply to MPLS-TP when a + control plane is deployed. + The requirements for ASON signalling and routing and the requirements for multi-region and multi-layer networks as specified in [RFC4139], [RFC4258] and [RFC5212] respectively apply to MPLS-TP. + [ITU-T Comment: the MPLS-TP control plane should meet the + requirements for ASON architecture (G.8080, ...) unless explicitly + excluded as well as the additional MPLS-TP specific requirements + explicitly added.] + + [Editors' Note: Following other comments on above references, need to + produce consolidated text that references correct documents & + requirements.] + Additionally: - 40 MPLS-TP SHOULD support control plane topologies that are - independent of the data plane topology. + 41 The MPLS-TP control pane SHOULD support control plane topology + and data plane topology independence. - 41 The MPLS-TP control plane MUST be able to be operated independent + 42 The MPLS-TP control plane MUST be able to be operated independent of any particular client or server layer control plane. - 42 The MPLS-TP control plane MUST support establishing all the + 43 The MPLS-TP control plane MUST support establishing all the connectivity patterns defined for the MPLS-TP data plane (e.g., unidirectional and bidirectional P2P, unidirectional P2MP, etc.) including configuration of protection functions and any associated maintenance functions. - 43 The MPLS-TP control pane MUST support the configuration and + 44 The MPLS-TP control pane MUST support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the transport path is established or modified. - 44 An MPLS-TP control plane MUST support operation of the recovery + 45 An MPLS-TP control plane MUST support operation of the recovery functions described in Section 2.8. - 45 An MPLS-TP control plane MUST scale gracefully to support a large - number of transport paths. + 46 An MPLS-TP control plane MUST scale gracefully to support a large + number of transport paths, nodes and links. - 46 An MPLS-TP control plane SHOULD provide a common control + 47 An MPLS-TP control plane SHOULD provide a common control mechanism for architecturally similar operations. 2.5. Network Management (NM) requirements - For requirements related to NM functionality for MPLS-TP, see the - MPLS-TP NM requirements document [I-D.gray-mpls-tp-nm-req]. + For requirements related to NM functionality (Management Plane in + ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements + document [I-D.gray-mpls-tp-nm-req]. 2.6. Operation, Administration and Maintenance (OAM) requirements For requirements related to OAM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [I-D.vigoureux-mpls-tp-oam-requirements]. 2.7. Network performance management (PM) requirements For requirements related to PM functionality for MPLS-TP, see the @@ -551,211 +592,216 @@ Network survivability plays a critical role in the delivery of reliable services. Network availability is a significant contributor to revenue and profit. Service guarantees in the form of SLAs require a resilient network that rapidly detects facility or node failures and restores network operation in accordance with the terms of the SLA. The requirements in this section use the recovery terminology defined in RFC 4427 [RFC4427]. - 47 MPLS-TP MUST provide protection and restoration mechanisms. + 48 MPLS-TP MUST provide protection and restoration mechanisms. A. Recovery techniques used for P2P and P2MP SHOULD be identical to simplify implementation and operation. However, this MUST NOT override any other requirement. - 48 MPLS-TP recovery mechanisms MUST be applicable at various levels - throughout the network including support for span, path segment + 49 MPLS-TP recovery mechanisms MUST be applicable at various levels + throughout the network including support for link, path segment and end-to-end path, and pseudowire segment, and end-to-end pseudowire recovery. - 49 MPLS-TP recovery paths MUST meet the SLA protection objectives of + 50 MPLS-TP recovery paths MUST meet the SLA protection objectives of the service. 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. 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 all be applicable to any topology. - 51 The recovery mechanisms MUST operate in synergy with (including + 52 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 + 53 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 + 54 MPLS-TP recovery and reversion mechanisms MUST prevent frequent operation of recovery in the event of an intermittent defect. + [Editors' Note: ITU-T Q9/15 and Q12/15 will provide by a + requirement for protection switching time in case of linear + protection (e.g. within 50 ms) together with a reference network.] + 2.8.1. Data plane behavior requirements 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. + 55 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). + 56 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 + 57 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 + 58 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 + 59 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 + 60 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. + 61 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 + 62 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh restoration. - 62 MPLS-TP MUST support the sharing of protection bandwidth by + 63 MPLS-TP MUST support the sharing of protection bandwidth by allowing best effort traffic. - 63 MPLS-TP MUST support the definition of shared protection groups + 64 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. - 64 MPLS-TP MUST support sharing of protection resources such that + 65 MPLS-TP MUST support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same resources. 2.8.1.4. Reversion - 65 MPLS-TP protection mechanisms MUST support revertive and non- + 66 MPLS-TP protection mechanisms MUST support revertive and non- revertive behavior. Reversion MUST be the default behavior. - 66 MPLS-TP restoration mechanisms MAY support revertive and non- + 67 MPLS-TP restoration mechanisms MAY support revertive and non- revertive behavior. 2.8.2. Triggers for protection, restoration, and reversion Recovery actions may be triggered from different places as follows: - 67 MPLS-TP MUST support physical layer fault indication triggers. + 68 MPLS-TP MUST support physical layer fault indication triggers. - 68 MPLS-TP MUST support OAM-based triggers. + 69 MPLS-TP MUST support OAM-based triggers. - 69 MPLS-TP MUST support management plane triggers (e.g., forced + 70 MPLS-TP MUST support management plane triggers (e.g., forced switch, etc.). - 70 There MUST be a mechanism to allow administrative recovery + 71 There MUST be a mechanism to allow administrative recovery actions to be distinguished from recovery actions initiated by other triggers. - 71 Where a control plane is present, MPLS-TP SHOULD support control + 72 Where a control plane is present, MPLS-TP SHOULD support control plane triggers. 2.8.3. Management plane operation of protection and restoration All functions described here are for control by the operator. - 72 It MUST be possible to configure of protection paths and + 73 It MUST be possible to configure of protection paths and protection-to-working path relationships (sometimes known as protection groups). - 73 There MUST be support for pre-calculation of recovery paths. + 74 There MUST be support for pre-calculation of recovery paths. - 74 There MUST be support for pre-provisioning of recovery paths. + 75 There MUST be support for pre-provisioning of recovery paths. - 75 The following administrative control MUST be supported: + 76 The following administrative control MUST be supported: A. lockout B. forced switchover + C. manual switchover D. simulated fault - 76 There MUST be support for the configuration of timers used for + 77 There MUST be support for the configuration of timers used for recovery operation. - 77 Restoration resources MAY be pre-planned and selected a priori, + 78 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 + 79 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 + 80 The management plane MUST provide indications of protection events and triggers. - 80 The management plane MUST allow the current protection status of + 81 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 + 82 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: + 83 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 + 84 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 @@ -795,152 +841,154 @@ 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 + + 85 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 + 86 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 + 87 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 + 88 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 + 89 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 + 90 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 + 91 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 + 92 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 + + 93 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 + 94 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 + 95 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 + 96 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 + 97 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 + 98 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 + 99 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 + 100 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 + 101 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 + 102 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 + 103 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 + 104 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 + 105 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 + 106 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 Carriers require advanced traffic management capabilities to enforce and guarantee the QoS parameters of customers' SLAs. Quality of service mechanisms are REQUIRED in an MPLS-TP network to ensure: - 106 Support for differentiated services and different traffic types + 107 Support for differentiated services and different traffic types with traffic class separation associated with different traffic. - 107 Prioritization of critical services. + 108 Prioritization of critical services. - 108 Enabling the provisioning and the guarantee of Service Level + 109 Enabling the provisioning and the guarantee of Service Level Specifications (SLS), with support for hard and relative end-to- end bandwidth guaranteed. - 109 Controlled jitter and delay. + 110 Support of services, which are sensitive to jitter and delay. - 110 Guarantee of fair access to shared resources. + 111 Guarantee of fair access, within a particular class, to shared + resources. - 111 Resources for control and management plane packets so that data - plane traffic, regardless of the amount, will not cause control - and management functions to become inoperative. + 112 Guaranteed resources for in-band control and management plane + traffic regardless of the amount of data plane traffic. - 112 Carriers are provided with the capability to efficiently support + 113 Carriers are provided with the capability to efficiently support service demands over the MPLS-TP network. This MUST include support for a flexible bandwidth allocation scheme. [Editors' Note: Should we refer here to the requirements specified in RFC 2702?] 2.10. Security requirements For a description of the security threats relevant in the context of MPLS and GMPLS and the defensive techniques to combat those threats @@ -1075,55 +1124,14 @@ Email: betts01@nortel.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com - Satoshi Ueno NTT Email: satoshi.ueno@ntt.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org.