idnits 2.17.1 draft-ietf-mpls-tp-requirements-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 16, 2009) is 5360 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3985 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G805.2000' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G8080.2006' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G8080.2008' == Outdated reference: A later version (-05) exists of draft-fang-mpls-tp-security-framework-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-05 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-nm-req-01 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-01 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-arch-06 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group B. Niven-Jenkins, Ed. 3 Internet-Draft BT 4 Intended status: Standards Track D. Brungard, Ed. 5 Expires: February 17, 2010 AT&T 6 M. Betts, Ed. 7 Huawei Technologies 8 N. Sprecher 9 Nokia Siemens Networks 10 S. Ueno 11 NTT 12 August 16, 2009 14 MPLS-TP Requirements 15 draft-ietf-mpls-tp-requirements-10 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 17, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 This document specifies the requirements of an MPLS Transport Profile 54 (MPLS-TP). This document is a product of a joint International 55 Telecommunications Union (ITU)-IETF effort to include an MPLS 56 Transport Profile within the IETF MPLS and PWE3 architectures to 57 support the capabilities and functionalities of a packet transport 58 network as defined by International Telecommunications Union - 59 Telecommunications Standardization Sector (ITU-T). 61 This work is based on two sources of requirements; MPLS and PWE3 62 architectures as defined by IETF, and packet transport networks as 63 defined by ITU-T. 65 The requirements expressed in this document are for the behavior of 66 the protocol mechanisms and procedures that constitute building 67 blocks out of which the MPLS transport profile is constructed. The 68 requirements are not implementation requirements. 70 Requirements Language 72 Although this document is not a protocol specification, the key words 73 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 74 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be 75 interpreted as described in RFC 2119 [RFC2119] and are to be 76 interpreted as instructions to the protocol designers producing 77 solutions that satisfy the requirements set out in this document. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 83 1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 6 84 1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 8 85 1.2. Transport network overview . . . . . . . . . . . . . . . . 11 86 1.3. Layer network overview . . . . . . . . . . . . . . . . . . 12 87 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 13 88 2.1. General requirements . . . . . . . . . . . . . . . . . . . 13 89 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 16 90 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 17 91 2.4. Control plane requirements . . . . . . . . . . . . . . . . 18 92 2.5. Recovery requirements . . . . . . . . . . . . . . . . . . 19 93 2.5.1. Data plane behavior requirements . . . . . . . . . . . 20 94 2.5.1.1. Protection . . . . . . . . . . . . . . . . . . . . 21 95 2.5.1.2. Sharing of protection resources . . . . . . . . . 22 96 2.5.2. Restoration . . . . . . . . . . . . . . . . . . . . . 22 97 2.5.3. Triggers for protection, restoration, and reversion . 22 98 2.5.4. Management plane operation of protection and 99 restoration . . . . . . . . . . . . . . . . . . . . . 23 100 2.5.5. Control plane and in-band OAM operation of recovery . 24 101 2.5.6. Topology-specific recovery mechanisms . . . . . . . . 24 102 2.5.6.1. Ring protection . . . . . . . . . . . . . . . . . 24 103 2.6. QoS requirements . . . . . . . . . . . . . . . . . . . . . 27 104 3. Requirements Discussed in Other Documents . . . . . . . . . . 28 105 3.1. Network Management requirements . . . . . . . . . . . . . 28 106 3.2. Operation, Administration and Maintenance (OAM) 107 requirements . . . . . . . . . . . . . . . . . . . . . . . 28 108 3.3. Network performance monitoring requirements . . . . . . . 28 109 3.4. Security requirements . . . . . . . . . . . . . . . . . . 28 110 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 111 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 112 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 113 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 114 7.1. Normative References . . . . . . . . . . . . . . . . . . . 29 115 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 118 1. Introduction 120 Bandwidth demand continues to grow worldwide, stimulated by the 121 accelerating growth and penetration of new packet based services and 122 multimedia applications: 124 o Packet-based services such as Ethernet, Voice over IP (VoIP), 125 Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP 126 Television (IPTV), Radio Access Network (RAN) backhauling, etc., 128 o Applications with various bandwidth and Quality of Service (QoS) 129 requirements. 131 This growth in demand has resulted in dramatic increases in access 132 rates that are, in turn, driving dramatic increases in metro and core 133 network bandwidth requirements. 135 Over the past two decades, the evolving optical transport 136 infrastructure (Synchronous Optical Networking (SONET)/Synchronous 137 Digital Hierarchy (SDH), Optical Transport Network (OTN)) has 138 provided carriers with a high benchmark for reliability and 139 operational simplicity. 141 With the movement towards packet based services, the transport 142 network has to evolve to encompass the provision of packet aware 143 capabilities while enabling carriers to leverage their installed, as 144 well as planned, transport infrastructure investments. 146 Carriers are in need of technologies capable of efficiently 147 supporting packet based services and applications on their transport 148 networks with guaranteed Service Level Agreements (SLAs). The need 149 to increase their revenue while remaining competitive forces 150 operators to look for the lowest network Total Cost of Ownership 151 (TCO). Investment in equipment and facilities (Capital Expenditure 152 (CAPEX)) and Operational Expenditure (OPEX) should be minimized. 154 There are a number of technology options for carriers to meet the 155 challenge of increased service sophistication and transport 156 efficiency, with increasing usage of hybrid packet transport and 157 circuit transport technology solutions. To realize these goals, it 158 is essential that packet transport technology be available that can 159 support the same high benchmarks for reliability and operational 160 simplicity set by SDH/SONET and OTN technologies. 162 Furthermore for carriers it is important that operation of such 163 packet transport networks should preserve the look-and-feel to which 164 carriers have become accustomed in deploying their optical transport 165 networks, while providing common, multi-layer operations, resiliency, 166 control and multi-technology management. 168 Transport carriers require control and deterministic usage of network 169 resources. They need end-to-end control to engineer network paths 170 and to efficiently utilize network resources. They require 171 capabilities to support static (management plane based) or dynamic 172 (control plane based) provisioning of deterministic, protected and 173 secured services and their associated resources. 175 It is also important to ensure smooth interworking of the packet 176 transport network with other existing/legacy packet networks, and 177 provide mappings to enable packet transport carriage over a variety 178 of transport network infrastructures. The latter has been termed 179 vertical interworking, and is also known as client/server or network 180 interworking. The former has been termed horizontal interworking, 181 and is also known as peer-partition or service interworking. For 182 more details on interworking and some of the issues that may arise 183 (especially with horizontal interworking) see G.805 [ITU.G805.2000] 184 and Y.1401 [ITU.Y1401.2008]. 186 Multi-Protocol Label Switching (MPLS) is a maturing packet technology 187 and it is already playing an important role in transport networks and 188 services. However, not all of MPLS's capabilities and mechanisms are 189 needed and/or consistent with transport network operations. There 190 are also transport technology characteristics that are not currently 191 reflected in MPLS. There is therefore the need to define an MPLS 192 Transport Profile (MPLS-TP) that supports the capabilities and 193 functionalities needed for packet transport network services and 194 operations through combining the packet experience of MPLS with the 195 operational experience and practices of existing transport networks. 197 MPLS-TP will enable the deployment of packet based transport networks 198 that will efficiently scale to support packet services in a simple 199 and cost effective way. MPLS-TP needs to combine the necessary 200 existing capabilities of MPLS with additional minimal mechanisms in 201 order that it can be used in a transport role. 203 This document specifies the requirements of an MPLS Transport Profile 204 (MPLS-TP). The requirements are for the behavior of the protocol 205 mechanisms and procedures that constitute building blocks out of 206 which the MPLS transport profile is constructed. That is, the 207 requirements indicate what features are to be available in the MPLS 208 toolkit for use by MPLS-TP. The requirements in this document do not 209 describe what functions an MPLS-TP implementation supports. The 210 purpose of this document is to identify the toolkit and any new 211 protocol work that is required. 213 This document is a product of a joint ITU-T and IETF effort to 214 include an MPLS Transport Profile within the IETF MPLS and PWE3 215 architectures to support the capabilities and functionalities of a 216 packet transport network as defined by ITU-T. The document is a 217 requirements specification, but is presented on the Standards Track 218 so that it can be more easily cited as a normative reference from 219 within the work of the ITU-T. 221 This work is based on two sources of requirements, MPLS and PWE3 222 architectures as defined by IETF and packet transport networks as 223 defined by ITU-T. The requirements of MPLS-TP are provided below. 224 The relevant functions of MPLS and PWE3 are included in MPLS-TP, 225 except where explicitly excluded. Any new functionality that is 226 defined to fulfill the requirements for MPLS-TP must be agreed within 227 the IETF through the IETF consensus process as per [RFC4929]. 229 MPLS-TP transport paths may be established using static or dynamic 230 configuration. It should be noted that the MPLS-TP network and its 231 transport paths can always be operated fully (including OAM and 232 protection capabilities) in the absence of any control plane. 234 1.1. Terminology 236 Note: Mapping between the terms in this section and ITU-T terminology 237 is described in [I-D.helvoort-mpls-tp-rosetta-stone]. 239 The recovery requirements in this document use the recovery 240 terminology defined in RFC 4427 [RFC4427], this is applied to both 241 control plane and management plane based operations of MPLS-TP 242 transport paths. 244 1.1.1. Abbreviations 246 ASON: Automatically Switched Optical Network 248 ATM: Asynchronous Transfer Mode 250 CAPEX: Capital Expenditure 252 CE: Customer Edge 254 FR: Frame Relay 256 GMPLS: Generalised Multi-Protocol Label Switching 258 IGP: Interior Gateway Protocol 260 IPTV: IP Television 261 L2: Layer 2 263 L3: Layer 3 265 LSP: Label Switched Path 267 LSR: Label Switching Router 269 MPLS: Multi-Protocol Label Switching 271 OAM: Operations, Administration and Maintenance 273 OPEX: Operational Expenditure 275 OSI: Open Systems Interconnection 277 OTN: Optical Transport Network 279 P2MP: Point to Multi-Point 281 P2P: Point to Point 283 PDU: Protocol Data Unit 285 PSC: Protection State Coordination 287 PW: Pseudowire 289 QoS: Quality of Service 291 SDH: Synchronous Digital Hierarchy 293 SLA: Service Level Agreement 295 SLS: Service Level Specification 297 S-PE: Switching Provider Edge 299 SONET: Synchronous Optical Network 301 SRLG: Shared Risk Link Group 303 TCO: Total Cost of Ownership 305 T-PE: Terminating Provider Edge 307 VoIP: Voice over IP 308 VPN: Virtual Private Network 310 WDM: Wavelength Division Multiplexing 312 1.1.2. Definitions 314 Note: The definition of segment in a GMPLS/ASON context (i.e. as 315 defined in RFC4397 [RFC4397]) encompasses both segment and 316 concatenated segment as defined in this document. 318 Associated bidirectional path: A path that supports traffic flow in 319 both directions but which is constructed from a pair of 320 unidirectional paths (one for each direction) which are associated 321 with one another at the path's ingress/egress points. The forward 322 and backward directions are setup, monitored and protected 323 independently. As a consequence they may or may not follow the same 324 route (links and nodes) across the network. 326 Client layer network: In a client/server relationship (see G.805 327 [ITU.G805.2000]), the client layer network receives a (transport) 328 service from the lower server layer network (usually the layer 329 network under consideration). 331 Concatenated Segment: A serial-compound link connection as defined in 332 G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part 333 of an LSP or multi-segment PW that comprises a set of segments and 334 their interconnecting nodes in sequence. See also "Segment". 336 Control Plane: Within the scope of this document the control plane 337 performs transport path control functions. Through signalling, the 338 control plane sets up, modifies and releases transport paths, and may 339 recover a transport path in case of a failure. The control plane 340 also performs other functions in support of transport path control, 341 such as routing information dissemination. 343 Co-routed Bidirectional path: A path where the forward and backward 344 directions follow the same route (links and nodes) across the 345 network. Both directions are setup, monitored and protected as a 346 single entity. A transport network path is typically co-routed. 348 Domain: A domain represents a collection of entities (for example 349 network elements) that are grouped for a particular purpose, examples 350 of which are administrative and/or managerial responsibilities, trust 351 relationships, addressing schemes, infrastructure capabilities, 352 aggregation, survivability techniques, distributions of control 353 functionality, etc. Examples of such domains include IGP areas and 354 Autonomous Systems. 356 Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A 357 layer network provides for the transfer of client information and 358 independent operation of the client OAM. A Layer Network may be 359 described in a service context as follows: one layer network may 360 provide a (transport) service to higher client layer network and may, 361 in turn, be a client to a lower layer network. A layer network is a 362 logical construction somewhat independent of arrangement or 363 composition of physical network elements. A particular physical 364 network element may topologically belong to more than one layer 365 network, depending on the actions it takes on the encapsulation 366 associated with the logical layers (e.g. the label stack), and thus 367 could be modeled as multiple logical elements. A layer network may 368 consist of one or more sublayers. Section 1.3 provides a more 369 detailed overview of what constitutes a layer network. For 370 additional explanation of how layer networks relate to the OSI 371 concept of layering see Appendix I of Y.2611 [ITU.Y2611.2006]. 373 Link: A physical or logical connection between a pair of LSRs that 374 are adjacent at the (sub)layer network under consideration. A link 375 may carry zero, one or more LSPs or PWs. A packet entering a link 376 will emerge with the same label stack entry values. 378 MPLS-TP Logical Ring: An MPLS-TP logical ring is constructed from a 379 set of LSRs and logical data links (such as MPLS-TP LSP tunnels or 380 MPLS-TP pseudowires) and physical data links that form a ring 381 topology. 383 Path: See Transport Path. 385 MPLS-TP Physical Ring: An MPLS-TP physical ring is constructed from a 386 set of LSRs and physical data links that form a ring topology. 388 MPLS-TP Ring Topology: In an MPLS-TP ring topology each LSR is 389 connected to exactly two other LSRs, each via a single point-to-point 390 bidirectional MPLS-TP capable link. A ring may also be constructed 391 from only two LSRs where there are also exactly two links. Rings may 392 be connected to other LSRs to form a larger network. Traffic 393 originating or terminating outside the ring may be carried over the 394 ring. Client network nodes (such as CEs) may be connected directly 395 to an LSR in the ring. 397 Section Layer Network: A section layer is a server layer (which may 398 be MPLS-TP or a different technology) which provides for the transfer 399 of the section layer client information between adjacent nodes in the 400 transport path layer or transport service layer. A section layer may 401 provide for aggregation of multiple MPLS-TP clients. Note that G.805 402 [ITU.G805.2000] defines the section layer as one of the two layer 403 networks in a transmission media layer network. The other layer 404 network is the physical media layer network. 406 Segment: A link connection as defined in G.805 [ITU.G805.2000]. A 407 segment is the part of an LSP that traverses a single link or the 408 part of a PW that traverses a single link (i.e. that connects a pair 409 of adjacent {Switching|Terminating} Provider Edges). See also 410 "Concatenated Segment". 412 Server Layer Network: In a client/server relationship (see G.805 413 [ITU.G805.2000]), the server layer network provides a (transport) 414 service to the higher client layer network (usually the layer network 415 under consideration). 417 Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The 418 distinction between a layer network and a sublayer is that a sublayer 419 is not directly accessible to clients outside of its encapsulating 420 layer network and offers no direct transport service for a higher 421 layer (client) network. 423 Switching Provider Edge (S-PE): See [I-D.ietf-pwe3-ms-pw-arch]. 425 Terminating Provider Edge (T-PE): See [I-D.ietf-pwe3-ms-pw-arch]. 427 Transport Path: A network connection as defined in G.805 428 [ITU.G805.2000]. In an MPLS-TP environment a transport path 429 corresponds to an LSP or a PW. 431 Transport Path Layer: A (sub-)layer network that provides point-to- 432 point or point-to-multipoint transport paths. It provides 433 independent (of the client) OAM when transporting its clients. 435 Transport Service Layer: A layer network in which transport paths are 436 used to carry a customer's (individual or bundled) service (may be 437 point-to-point, point-to-multipoint or multipoint-to-multipoint 438 services). 440 Transmission Media Layer: A layer network, consisting of a section 441 layer network and a physical layer network as defined in G.805 442 [ITU.G805.2000], that provides sections (two-port point-to-point 443 connections) to carry the aggregate of network transport path or 444 network service layers on various physical media. 446 Unidirectional Path: A path that supports traffic flow in only one 447 direction. 449 1.2. Transport network overview 451 The connectivity service is the basic service provided by a transport 452 network. The purpose of a transport network is to carry its customer 453 traffic (i.e. the stream of customer PDUs or customer bits, including 454 overhead) between endpoints in the transport network (typically over 455 several intermediate nodes). The connectivity services offered to 456 customers are typically aggregated into large transport paths with 457 long-holding times and independent OAM (of the client OAM), which 458 contribute to enabling the efficient and reliable operation of the 459 transport network. These transport paths are modified infrequently. 461 Quality-of-service mechanisms are required in the packet transport 462 network to ensure the prioritization of critical services, to 463 guarantee bandwidth and to control jitter and delay. A transport 464 network must provide the means to commit quality of service 465 objectives to clients. This is achieved by providing a mechanism for 466 client network service demarcation for the network path together with 467 an associated network resiliency mechanism. 469 Aggregation is beneficial for achieving scalability and security 470 since: 472 1. It reduces the number of provisioning and forwarding states in 473 the network core. 475 2. It reduces load and the cost of implementing service assurance 476 and fault management. 478 3. Customer traffic is encapsulated and layer associated OAM 479 overhead is added. This allows complete isolation of customer 480 traffic and its management from carrier operations. 482 An important attribute of a transport network is that it is able to 483 function regardless of which clients are using its connection service 484 or over which transmission media it is running. The client, 485 transport network and server layers are from a functional and 486 operations point of view independent layer networks. Another key 487 characteristic of transport networks is the capability to maintain 488 the integrity of the client across the transport network. A 489 transport network must also provide a method of service monitoring in 490 order to verify the delivery of an agreed quality of service. This 491 is enabled by means of carrier-grade OAM tools. 493 Customer traffic is first encapsulated within the transport service 494 layer network. The transport service layer network signals may then 495 be aggregated into a transport path layer network for transport 496 through the network in order to optimize network management. 498 Transport service layer network OAM is used to monitor the transport 499 integrity of the customer traffic and transport path layer network 500 OAM is used to monitor the transport integrity of the aggregates. At 501 any hop, the aggregated signals may be further aggregated in lower 502 layer transport network paths for transport across intermediate 503 shared links. The transport service layer network signals are 504 extracted at the edges of aggregation domains, and are either 505 delivered to the customer or forwarded to another domain. In the 506 core of the network, only the transport path layer network signals 507 are monitored at intermediate points; individual transport service 508 layer network signals are monitored at the network boundary. 509 Although the connectivity of the transport service layer network may 510 be point-to-point, point-to-multipoint or multipoint-to-multipoint, 511 the transport path layer network only provides point-to-point or 512 point-to-multipoint transport paths which are used to carry 513 aggregates of transport service layer network traffic. 515 1.3. Layer network overview 517 A layer network provides its clients with a transport service and the 518 operation of the layer network is independent of whatever client 519 happens to use the layer network. Information that passes between 520 any client to the layer network is common to all clients and is the 521 minimum needed to be consistent with the definition of the transport 522 service offered. The client layer network can be connectionless, 523 connection oriented packet switched, or circuit switched. The 524 transport service transfers a payload (individual packet payload for 525 connectionless networks, a sequence of packets payloads in the case 526 of connection oriented packet switched networks, and a deterministic 527 schedule of payloads in the case of circuit switched networks) such 528 that the client can populate the payload without affecting any 529 operation within the serving layer network. 531 The operations within a layer network that are independent of its 532 clients include the control of forwarding, the control of resource 533 reservation, the control of traffic demerging, and the OAM and 534 recovery of the transport service. All of these operations are 535 internal to a layer network. By definition, a layer network does not 536 rely on any client information to perform these operations and 537 therefore all information required to perform these operations is 538 independent of whatever client is using the layer network. 540 A layer network will have consistent features in order to support the 541 control of forwarding, resource reservation, OAM and recovery. For 542 example, a layer network will have a common addressing scheme for the 543 end points of the transport service and a common set of transport 544 descriptors for the transport service. However, a client may use a 545 different addressing scheme or different traffic descriptors 546 (consistent with performance inheritance). 548 It is sometimes useful to independently monitor a smaller domain 549 within a layer network (or the transport services that traverse this 550 smaller domain) but the control of forwarding or the control of 551 resource reservation involved retain their common elements. These 552 smaller monitored domains are sublayers. 554 It is sometimes useful to independently control forwarding in a 555 smaller domain within a layer network but the control of resource 556 reservation and OAM retain their common elements. These smaller 557 domains are partitions of the layer network. 559 2. MPLS-TP Requirements 561 The MPLS-TP requirements set out in this section are for the behavior 562 of the protocol mechanisms and procedures that constitute building 563 blocks out of which the MPLS transport profile is constructed. That 564 is, the requirements indicate what features are to be available in 565 the MPLS toolkit for use by MPLS-TP. 567 2.1. General requirements 569 1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as 570 defined by the IETF. When MPLS offers multiple options in this 571 respect, MPLS-TP SHOULD select the minimum sub-set (necessary and 572 sufficient subset) applicable to a transport network application. 574 2 The MPLS-TP design SHOULD as far as reasonably possible re-use 575 existing MPLS standards. 577 3 Mechanisms and capabilities MUST be able to interoperate with 578 existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and 579 data planes where appropriate. 581 A. Data plane interoperability MUST NOT require a gateway 582 function. 584 4 MPLS-TP and its interfaces, both internal and external, MUST be 585 sufficiently well-defined that interworking equipment supplied by 586 multiple vendors will be possible both within a single domain, 587 and between domains. 589 5 MPLS-TP MUST be a connection-oriented packet switching technology 590 with traffic engineering capabilities that allow deterministic 591 control of the use of network resources. 593 6 MPLS-TP MUST support traffic engineered point to point (P2P) and 594 point to multipoint (P2MP) transport paths. 596 7 MPLS-TP MUST support unidirectional, co-routed bidirectional and 597 associated bidirectional point-to-point transport paths. 599 8 MPLS-TP MUST support unidirectional point-to-multipoint transport 600 paths. 602 9 The end points of a co-routed bidirectional transport path MUST 603 be aware of the pairing relationship of the forward and reverse 604 paths used to support the bidirectional service. 606 10 All nodes on the path of a co-routed bidirectional transport path 607 in the same (sub-)layer as the path MUST be aware of the pairing 608 relationship of the forward and the backward directions of the 609 transport path. 611 11 The end points of an associated bidirectional transport path MUST 612 be aware of the pairing relationship of the forward and reverse 613 paths used to support the bidirectional service. 615 12 Nodes on the path of an associated bidirectional transport path 616 where both the forward and backward directions transit the same 617 node in the same (sub-)layer as the path SHOULD be aware of the 618 pairing relationship of the forward and the backward directions 619 of the transport path. 621 13 MPLS-TP MUST support bidirectional transport paths with symmetric 622 bandwidth requirements, i.e. the amount of reserved bandwidth is 623 the same between the forward and backward directions. 625 14 MPLS-TP MUST support bidirectional transport paths with 626 asymmetric bandwidth requirements, i.e. the amount of reserved 627 bandwidth differs between the forward and backward directions. 629 15 MPLS-TP MUST support the logical separation of the control and 630 management planes from the data plane. 632 16 MPLS-TP MUST support the physical separation of the control and 633 management planes from the data plane. That is, it must be 634 possible to operate the control and management planes out-of-band 635 and no assumptions should be made about the state of the data 636 plane channels from information about the control or management 637 plane channels when they are running out-of-band. 639 17 MPLS-TP MUST support static provisioning of transport paths via 640 the management plane. 642 18 A solution MUST be defined to support dynamic provisioning and 643 restoration of MPLS-TP transport paths via a control plane. 645 19 Static provisioning MUST NOT depend on the presence of any 646 element of a control plane. 648 20 MPLS-TP MUST support the co-existence of statically and 649 dynamically provisioned/managed MPLS-TP transport paths within 650 the same layer network or domain. 652 21 Mechanisms in an MPLS-TP layer network that satisfy functional 653 requirements that are common to general transport layer networks 654 (i.e., independent of technology) SHOULD be operable in a way 655 that is similar to the way the equivalent mechanisms are operated 656 in other transport layer technologies. 658 22 MPLS-TP MUST support the capability for network operation via the 659 management plane (without the use of any control plane 660 protocols). This includes the configuration and control of OAM 661 and recovery functions. 663 23 The MPLS-TP data plane MUST be capable of 665 A. forwarding data independent of the control or management 666 plane used to configure and operate the MPLS-TP layer 667 network. 669 B. taking recovery actions independent of the control or 670 management plane used to configure the MPLS-TP layer network. 672 C. operating normally (i.e. forwarding, OAM and protection MUST 673 continue to operate) if the management plane or control plane 674 that configured the transport paths fails. 676 24 MPLS-TP MUST support mechanisms to avoid or minimize traffic 677 impact (e.g. packet delay, reordering and loss) during network 678 reconfiguration. 680 25 MPLS-TP MUST support transport paths through multiple homogeneous 681 domains. 683 26 MPLS-TP SHOULD support transport paths through multiple non- 684 homogeneous domains. 686 27 MPLS-TP MUST NOT dictate the deployment of any particular network 687 topology either physical or logical, however: 689 A. It MUST be possible to deploy MPLS-TP in rings. 691 B. It MUST be possible to deploy MPLS-TP in arbitrarily 692 interconnected rings with one or two points of 693 interconnection. 695 C. MPLS-TP MUST support rings of at least 16 nodes in order to 696 support the upgrade of existing TDM rings to MPLS-TP. 697 MPLS-TP SHOULD support rings with more than 16 nodes. 699 28 MPLS-TP MUST be able to scale at least as well as existing 700 transport technologies with growing and increasingly complex 701 network topologies as well as with increasing bandwidth demands, 702 number of customers, and number of services. 704 29 MPLS-TP SHOULD support mechanisms to safeguard against the 705 provisioning of transport paths which contain forwarding loops. 707 2.2. Layering requirements 709 30 A generic and extensible solution MUST be provided to support the 710 transport of one or more client layer networks (e.g. MPLS-TP, 711 IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network. 713 31 A generic and extensible solution MUST be provided to support the 714 transport of MPLS-TP transport paths over one or more server 715 layer networks (such as MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). 716 Requirements for bandwidth management within a server layer 717 network are outside the scope of this document. 719 32 In an environment where an MPLS-TP layer network is supporting a 720 client layer network, and the MPLS-TP layer network is supported 721 by a server layer network then operation of the MPLS-TP layer 722 network MUST be possible without any dependencies on the server 723 or client layer network. 725 A. The server layer MUST guarantee that the traffic loading 726 imposed by other clients does not cause the transport service 727 provided to the MPLS-TP layer to fall below the agreed level. 728 Mechanisms to achieve this are outside the scope of these 729 requirements. 731 B. It MUST be possible to isolate the control and management 732 planes of the MPLS-TP layer network from the control and 733 management planes of the client and server layer networks. 735 33 A solution MUST be provided to support the transport of a client 736 MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer 737 network. 739 A. The level of co-ordination required between the client and 740 server MPLS(-TP) layer networks MUST be minimized (preferably 741 no co-ordination will be required). 743 B. The MPLS(-TP) server layer network MUST be capable of 744 transporting the complete set of packets generated by the 745 client MPLS(-TP) layer network, which may contain packets 746 that are not MPLS packets (e.g. IP or CNLS packets used by 747 the control/management plane of the client MPLS(-TP) layer 748 network). 750 34 It MUST be possible to operate the layers of a multi-layer 751 network that includes an MPLS-TP layer autonomously. 753 The above are not only technology requirements, but also operational 754 requirements. Different administrative groups may be responsible for 755 the same layer network or different layer networks. 757 35 It MUST be possible to hide MPLS-TP layer network addressing and 758 other information (e.g. topology) from client layer networks. 759 However, it SHOULD be possible, at the option of the operator, to 760 leak a limited amount of summarized information (such as SRLGs or 761 reachability) between layers. 763 2.3. Data plane requirements 765 36 It MUST be possible to operate and configure the MPLS-TP data 766 plane without any IP forwarding capability in the MPLS-TP data 767 plane. i.e. the data plane only operates on the MPLS label. 769 37 It MUST be possible for the end points of an MPLS-TP transport 770 path that is carrying an aggregate of client transport paths to 771 be able to decompose the aggregate transport path into its 772 component client transport paths. 774 38 A transport path on a link MUST be uniquely identifiable by a 775 single label on that link. 777 39 A transport path's source MUST be identifiable at its destination 778 within its layer network. 780 40 MPLS-TP MUST be capable of using P2MP server (sub-)layer 781 capabilities as well as P2P server (sub-)layer capabilities when 782 supporting P2MP MPLS-TP transport paths. 784 41 MPLS-TP MUST be extensible in order to accommodate new types of 785 client layer networks and services. 787 42 MPLS-TP SHOULD support mechanisms to enable the reserved 788 bandwidth associated with a transport path to be increased 789 without impacting the existing traffic on that transport path 790 provided enough resources are available. 792 43 MPLS-TP SHOULD support mechanisms to enable the reserved 793 bandwidth of a transport path to be decreased without impacting 794 the existing traffic on that transport path, provided that the 795 level of existing traffic is smaller than the reserved bandwidth 796 following the decrease. 798 44 MPLS-TP MUST support mechanisms which ensure the integrity of the 799 transported customer's service traffic as required by its 800 associated SLA. Loss of integrity may be defined as packet 801 corruption, re-ordering or loss during normal network conditions. 803 45 MPLS-TP MUST support mechanisms to detect when loss of integrity 804 of the transported customer's service traffic has occurred. 806 46 MPLS-TP MUST support an unambiguous and reliable means of 807 distinguishing users' (client) packets from MPLS-TP control 808 packets (e.g. control plane, management plane, OAM and protection 809 switching packets). 811 2.4. Control plane requirements 813 This section defines the requirements that apply to an MPLS-TP 814 control plane. Note that it MUST be possible to operate an MPLS-TP 815 network without using a control plane. 817 The ITU-T has defined an architecture for Automatically Switched 818 Optical Networks (ASON) in G.8080 [ITU.G8080.2006] and G.8080 Amd1 819 [ITU.G8080.2008]. The control plane for MPLS-TP MUST fit within the 820 ASON architecture. 822 An interpretation of the ASON signaling and routing requirements in 823 the context of GMPLS can be found in [RFC4139] and [RFC4258]. 825 Additionally: 827 47 The MPLS-TP control plane MUST support control plane topology and 828 data plane topology independence. As a consequence a failure of 829 the control plane does not imply that there has also been a 830 failure of the data plane. 832 48 The MPLS-TP control plane MUST be able to be operated independent 833 of any particular client or server layer control plane. 835 49 MPLS-TP SHOULD define a solution to support an integrated control 836 plane encompassing MPLS-TP together with its server and client 837 layer networks when these layer networks belong to the same 838 administrative domain. 840 50 The MPLS-TP control plane MUST support establishing all the 841 connectivity patterns defined for the MPLS-TP data plane (i.e., 842 unidirectional P2P, associated bidirectional P2P, co-routed 843 bidirectional P2P, unidirectional P2MP) including configuration 844 of protection functions and any associated maintenance functions. 846 51 The MPLS-TP control plane MUST support the configuration and 847 modification of OAM maintenance points as well as the activation/ 848 deactivation of OAM when the transport path or transport service 849 is established or modified. 851 52 An MPLS-TP control plane MUST support operation of the recovery 852 functions described in Section 2.8. 854 53 An MPLS-TP control plane MUST scale gracefully to support a large 855 number of transport paths, nodes and links. 857 54 If a control plane is used for MPLS-TP, following a control plane 858 failure, the control plane MUST be capable of restarting and 859 relearning its previous state without impacting forwarding. 861 55 An MPLS-TP control plane MUST provide a mechanism for dynamic 862 ownership transfer of the control of MPLS-TP transport paths from 863 the management plane to the control plane and vice versa. The 864 number of reconfigurations required in the data plane MUST be 865 minimized (preferably no data plane reconfiguration will be 866 required). 868 2.5. Recovery requirements 870 Network survivability plays a critical role in the delivery of 871 reliable services. Network availability is a significant contributor 872 to revenue and profit. Service guarantees in the form of SLAs 873 require a resilient network that rapidly detects facility or node 874 failures and restores network operation in accordance with the terms 875 of the SLA. 877 56 MPLS-TP MUST provide protection and restoration mechanisms. 879 A. MPLS-TP recovery techniques SHOULD be identical (or as 880 similar as possible) to those already used in existing 881 transport networks to simplify implementation and operations. 882 However, this MUST NOT override any other requirement. 884 B. Recovery techniques used for P2P and P2MP SHOULD be identical 885 to simplify implementation and operation. However, this MUST 886 NOT override any other requirement. 888 57 MPLS-TP recovery mechanisms MUST be applicable at various levels 889 throughout the network including support for link, transport 890 path, segment, concatenated segment and end to end recovery. 892 58 MPLS-TP recovery paths MUST meet the SLA protection objectives of 893 the service. 895 A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery 896 times from the moment of fault detection in networks with 897 spans less than 1200 km. 899 B. For protection it MUST be possible to require protection of 900 100% of the traffic on the protected path. 902 C. Recovery MUST meet SLA requirements over multiple domains. 904 59 Recovery objectives SHOULD be configurable per transport path. 906 60 The recovery mechanisms SHOULD be applicable to any topology. 908 61 The recovery mechanisms MUST support the means to operate in 909 synergy with (including coordination of timing) the recovery 910 mechanisms present in any client or server transport networks 911 (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions 912 between the layers. 914 62 MPLS-TP recovery and reversion mechanisms MUST prevent frequent 915 operation of recovery in the event of an intermittent defect. 917 2.5.1. Data plane behavior requirements 919 General protection and survivability requirements are expressed in 920 terms of the behavior in the data plane. 922 2.5.1.1. Protection 924 Note: Only nodes that are aware of the pairing relationship between 925 the forward and backward directions of an associated bidirectional 926 transport path can be used as end points to protect all or part of 927 that transport path. 929 63 It MUST be possible to provide protection for the MPLS-TP data 930 plane without any IP forwarding capability in the MPLS-TP data 931 plane. i.e. the data plane only operates on the MPLS label. 933 64 MPLS-TP protection mechanisms MUST support revertive and non- 934 revertive behavior. 936 65 MPLS-TP MUST support 1+1 protection. 938 A. Bidirectional 1+1 protection for P2P connectivity MUST be 939 supported. 941 B. Unidirectional 1+1 protection for P2P connectivity MUST be 942 supported. 944 C. Unidirectional 1+1 protection for P2MP connectivity MUST be 945 supported. 947 66 MPLS-TP MUST support the ability to share protection resources 948 amongst a number of transport paths. 950 67 MPLS-TP MUST support 1:n protection (including 1:1 protection). 952 A. Bidirectional 1:n protection for P2P connectivity MUST be 953 supported, and SHOULD be the default behavior for 1:n 954 protection. 956 B. Unidirectional 1:n protection for P2MP connectivity MUST be 957 supported. 959 C. Unidirectional 1:n protection for P2P connectivity is not 960 required and MAY be omitted from the MPLS-TP specifications. 962 D. The action of protection switching MUST NOT cause the user 963 data to enter an uncontrolled loop. The protection switching 964 system MAY cause traffic to pass over a given link more than 965 once, but it must do so in a controlled way such that 966 uncontrolled loops do not form. 968 Note: Support for extra traffic (as defined in [RFC4427]) is not 969 required in MPLS-TP and MAY be omitted from the MPLS-TP 970 specifications. 972 2.5.1.2. Sharing of protection resources 974 68 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh recovery. 976 69 MPLS-TP MUST support sharing of protection resources such that 977 protection paths that are known not to be required concurrently 978 can share the same resources. 980 2.5.2. Restoration 982 70 The restoration transport path MUST be able to share resources 983 with the transport path being replaced (sometimes known as soft 984 rerouting). 986 71 Restoration priority MUST be supported so that an implementation 987 can determine the order in which transport paths should be 988 restored (to minimize service restoration time as well as to gain 989 access to available spare capacity on the best paths). 991 72 Preemption priority MUST be supported to allow restoration to 992 displace other transport paths in the event of resource 993 constraint. 995 73 MPLS-TP restoration mechanisms MUST support revertive and non- 996 revertive behavior. 998 2.5.3. Triggers for protection, restoration, and reversion 1000 Recovery actions may be triggered from different places as follows: 1002 74 MPLS-TP MUST support fault indication triggers from lower layers. 1003 This includes faults detected and reported by lower layer 1004 protocols, and faults reported directly by the physical medium 1005 (for example, loss of light). 1007 75 MPLS-TP MUST support OAM-based triggers. 1009 76 MPLS-TP MUST support management plane triggers (e.g., forced 1010 switch, etc.). 1012 77 There MUST be a mechanism to allow administrative recovery 1013 actions to be distinguished from recovery actions initiated by 1014 other triggers. 1016 78 Where a control plane is present, MPLS-TP SHOULD support control 1017 plane restoration triggers. 1019 79 MPLS-TP protection mechanisms MUST support priority logic to 1020 negotiate and accommodate coexisting requests (i.e., multiple 1021 requests) for protection switching (e.g., administrative requests 1022 and requests due to link/node failures). 1024 2.5.4. Management plane operation of protection and restoration 1026 All functions described here are for control by the operator. 1028 80 It MUST be possible to configure protection paths and protection- 1029 to-working path relationships (sometimes known as protection 1030 groups). 1032 81 There MUST be support for pre-calculation of recovery paths. 1034 82 There MUST be support for pre-provisioning of recovery paths. 1036 83 The external controls as defined in [RFC4427] MUST be supported. 1038 A. External controls overruled by higher priority requests 1039 (e.g., administrative requests and requests due to link/node 1040 failures) or unable to be signaled to the remote end (e.g. 1041 because of a protection state coordination fail) MUST be 1042 dropped. 1044 84 It MUST be possible to test and validate any protection/ 1045 restoration mechanisms and protocols: 1047 A. Including the integrity of the protection/recovery transport 1048 path. 1050 B. Without triggering the actual protection/restoration. 1052 C. While the working path is in service. 1054 D. While the working path is out of service. 1056 85 Restoration resources MAY be pre-planned and selected a priori, 1057 or computed after failure occurrence. 1059 86 When preemption is supported for restoration purposes, it MUST be 1060 possible for the operator to configure it. 1062 87 The management plane MUST provide indications of protection 1063 events and triggers. 1065 88 The management plane MUST allow the current protection status of 1066 all transport paths to be determined. 1068 2.5.5. Control plane and in-band OAM operation of recovery 1070 89 The MPLS-TP control plane (which is not mandatory in an MPLS-TP 1071 implementation) MUST be capable of supporting: 1073 A. establishment and maintenance of all recovery entities and 1074 functions 1076 B. signaling of administrative control 1078 C. protection state coordination (PSC). Since control plane 1079 network topology is independent from the data plane network 1080 topology, the PSC supported by the MPLS-TP control plane MAY 1081 run on resources different than the data plane resources 1082 handled within the recovery mechanism (e.g. backup). 1084 90 In-band OAM MUST be capable of supporting: 1086 A. signaling of administrative control 1088 B. protection state coordination (PSC). Since in-band OAM tools 1089 share the data plane with the carried transport service, in 1090 order to optimize the usage of network resources, the PSC 1091 supported by in-band OAM MUST run on protection resources. 1093 2.5.6. Topology-specific recovery mechanisms 1095 91 MPLS-TP MAY support recovery mechanisms that are optimized for 1096 specific network topologies. These mechanisms MUST be 1097 interoperable with the mechanisms defined for arbitrary topology 1098 (mesh) networks to enable protection of end-to-end transport 1099 paths. 1101 2.5.6.1. Ring protection 1103 Several service providers have expressed a high level of interest in 1104 operating MPLS-TP in ring topologies and require a high level of 1105 survivability function in these topologies. The requirements listed 1106 below have been collected from these service providers and from the 1107 ITU-T. 1109 The main objective in considering a specific topology (such as a 1110 ring) is to determine whether it is possible to optimize any 1111 mechanisms such that the performance of those mechanisms within the 1112 topology is significantly better than the performance of the generic 1113 mechanisms in the same topology. The benefits of such optimizations 1114 are traded against the costs of developing, implementing, deploying, 1115 and operating the additional optimized mechanisms noting that the 1116 generic mechanisms MUST continue to be supported. 1118 Within the context of recovery in MPLS-TP networks, the optimization 1119 criteria considered in ring topologies are as follows: 1121 a. Minimize the number of OAM entities that are needed to trigger 1122 the recovery operation - less than are required by other recovery 1123 mechanisms. 1125 b. Minimize the number of elements of recovery in the ring - less 1126 than are required by other recovery mechanisms. 1128 c. Minimize the number of labels required for the protection paths 1129 across the ring - less than are required by other recovery 1130 mechanisms. 1132 d. Minimize the amount of control and management plane transactions 1133 during a maintenance operation (e.g., ring upgrade) - less than 1134 are required by other recovery mechanisms. 1136 e. When a control plane is supported, minimize the impact on 1137 signaling and routing information exchange during protection - 1138 less than are required by other recovery mechanisms. 1140 It may be observed that the requirements in Section 2.5.6.1 are fully 1141 compatible with the generic requirements expressed in Section 2.5 1142 through Section 2.5.6 inclusive, and that no requirements that are 1143 specific to ring topologies have been identified. 1145 92 MPLS-TP MUST include recovery mechanisms that operate in any 1146 single ring supported in MPLS-TP, and continue to operate within 1147 the single rings even when the rings are interconnected. 1149 93 When a network is constructed from interconnected rings, MPLS-TP 1150 MUST support recovery mechanisms that protect user data that 1151 traverses more than one ring. This includes the possibility of 1152 failure of the ring-interconnect nodes and links. 1154 94 MPLS-TP recovery in a ring MUST protect unidirectional and 1155 bidirectional P2P transport paths. 1157 95 MPLS-TP recovery in a ring MUST protect unidirectional P2MP 1158 transport paths. 1160 96 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching 1161 time within 50 ms from the moment of fault detection in a 1162 network with a 16 nodes ring with less than 1200 km of fiber. 1164 97 The protection switching time in a ring MUST be independent of 1165 the number of LSPs crossing the ring. 1167 98 The configuration and operation of recovery mechanisms in a ring 1168 MUST scale well with: 1170 A. the number of transport paths (must be better than linear 1171 scaling) 1173 B. the number of nodes on the ring (must be at least as good as 1174 linear scaling) 1176 C. the number of ring interconnects (must be at least as good 1177 as linear scaling) 1179 99 Recovery techniques used in a ring MUST NOT prevent the ring 1180 from being connected to a general MPLS-TP network in any 1181 arbitrary way, and MUST NOT prevent the operation of recovery 1182 techniques in the rest of the network. 1184 100 Recovery techniques in a ring SHOULD be identical (or as similar 1185 as possible) to those in general transport networks to simplify 1186 implementation and operations. However, this MUST NOT override 1187 any other requirement. 1189 101 Recovery techniques in logical and physical rings SHOULD be 1190 identical to simplify implementation and operation. However, 1191 this MUST NOT override any other requirement. 1193 102 The default recovery scheme in a ring MUST be bidirectional 1194 recovery in order to simplify the recovery operation. 1196 103 The recovery mechanism in a ring MUST support revertive 1197 switching, which MUST be the default behavior. This allows 1198 optimization of the use of the ring resources, and restores the 1199 preferred quality conditions for normal traffic (e.g., delay) 1200 when the recovery mechanism is no longer needed. 1202 104 The recovery mechanisms in a ring MUST support ways to allow 1203 administrative protection switching, to be distinguished from 1204 protection switching initiated by other triggers. 1206 105 It MUST be possible to lockout (disable) protection mechanisms 1207 on selected links (spans) in a ring (depending on operator's 1208 need). This may require lockout mechanisms to be applied to 1209 intermediate nodes within a transport path. 1211 106 MPLS-TP recovery mechanisms in a ring: 1213 A. MUST include a mechanism to allow an implementation to 1214 handle (including the coordination of) coexisting requests 1215 or triggers (i.e., multiple requests - not necessarily 1216 arriving simultaneously and located anywhere in the ring) 1217 for protection switching based on priority. Note that such 1218 coordination is the ring equivalent of the definition of 1219 shared protection groups. 1221 B. SHOULD protect against multiple failures 1223 107 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a 1224 way to prevent frequent operation of recovery in the event of an 1225 intermittent defect. 1227 108 MPLS-TP MUST support the sharing of protection bandwidth in a 1228 ring by allowing best effort traffic. 1230 109 MPLS-TP MUST support sharing of ring protection resources such 1231 that protection paths that are known not to be required 1232 concurrently can share the same resources. 1234 2.6. QoS requirements 1236 Carriers require advanced traffic management capabilities to enforce 1237 and guarantee the QoS parameters of customers' SLAs. 1239 Quality of service mechanisms are REQUIRED in an MPLS-TP network to 1240 ensure: 1242 110 Support for differentiated services and different traffic types 1243 with traffic class separation associated with different traffic. 1245 111 Enabling the provisioning and the guarantee of Service Level 1246 Specifications (SLS), with support for hard and relative end-to- 1247 end bandwidth guaranteed. 1249 112 Support of services, which are sensitive to jitter and delay. 1251 113 Guarantee of fair access, within a particular class, to shared 1252 resources. 1254 114 Guaranteed resources for in-band control and management plane 1255 traffic regardless of the amount of data plane traffic. 1257 115 Carriers are provided with the capability to efficiently support 1258 service demands over the MPLS-TP network. This MUST include 1259 support for a flexible bandwidth allocation scheme. 1261 3. Requirements Discussed in Other Documents 1263 3.1. Network Management requirements 1265 For requirements related to network management functionality 1266 (Management Plane in ITU-T terminology) for MPLS-TP, see the MPLS-TP 1267 Network Management requirements document [I-D.ietf-mpls-tp-nm-req]. 1269 3.2. Operation, Administration and Maintenance (OAM) requirements 1271 For requirements related to OAM functionality for MPLS-TP, see the 1272 MPLS-TP OAM requirements document 1273 [I-D.ietf-mpls-tp-oam-requirements]. 1275 3.3. Network performance monitoring requirements 1277 For requirements related to performance monitoring functionality for 1278 MPLS-TP, see the MPLS-TP OAM requirements document 1279 [I-D.ietf-mpls-tp-oam-requirements]. 1281 3.4. Security requirements 1283 For a description of the security threats relevant in the context of 1284 MPLS and GMPLS and the defensive techniques to combat those threats 1285 see the Security Framework for MPLS & GMPLS Networks 1286 [I-D.ietf-mpls-mpls-and-gmpls-security-framework]. 1288 For a description of additional security threats relevant in the 1289 context of MPLS-TP and the defensive techniques to combat those 1290 threats see the Security Framework for MPLS-TP 1291 [I-D.ietf-fang-mpls-tp-security-framework]. 1293 4. IANA Considerations 1295 This document makes no request of IANA. 1297 Note to RFC Editor: this section may be removed on publication as an 1298 RFC. 1300 5. Security Considerations 1302 See Section 3.4. 1304 6. Acknowledgements 1306 The authors would like to thank all members of the teams (the Joint 1307 Working Team, the MPLS Interoperability Design Team in the IETF, and 1308 the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and 1309 specification of MPLS Transport Profile. 1311 The authors would also like to thank Loa Andersson, Dieter Beller, 1312 Lou Berger, Italo Busi, John Drake, Adrian Farrel, Annamaria 1313 Fulignoli, Pietro Grandi, Eric Gray, Neil Harrison, Jia He, Huub van 1314 Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Andy 1315 Malis, Alan McGuire, Julien Meuric, Greg Mirsky, Tom Nadeau, Hiroshi 1316 Ohta, Tom Petch, Andy Reid, Vincenzo Sestito, George Swallow, Lubo 1317 Tancevski, Tomonori Takeda, Yuji Tochio, Alexander Vainshtein, Eve 1318 Varma and Maarten Vissers for their comments and enhancements to the 1319 text. 1321 An ad hoc discussion group consisting of Stewart Bryant, Italo Busi, 1322 Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, 1323 Feng Huang, Harald Kullman, Han Li, Hao Long and Nurit Sprecher 1324 provided valuable input to the requirements for deployment and 1325 survivability in ring topologies. 1327 7. References 1329 7.1. Normative References 1331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1332 Requirement Levels", BCP 14, RFC 2119, March 1997. 1334 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1335 Label Switching Architecture", RFC 3031, January 2001. 1337 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1338 Edge (PWE3) Architecture", RFC 3985, March 2005. 1340 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 1341 Multiprotocol Label Switching (MPLS) and Generalized MPLS 1342 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 1343 June 2007. 1345 [ITU.G805.2000] 1346 International Telecommunications Union, "Generic 1347 functional architecture of transport networks", ITU- 1348 T Recommendation G.805, March 2000. 1350 [ITU.G8080.2006] 1351 International Telecommunications Union, "Architecture for 1352 the automatically switched optical network (ASON)", ITU- 1353 T Recommendation G.8080, June 2006. 1355 [ITU.G8080.2008] 1356 International Telecommunications Union, "Architecture for 1357 the automatically switched optical network (ASON) 1358 Amendment 1", ITU-T Recommendation G.8080 Amendment 1, 1359 March 2008. 1361 7.2. Informative References 1363 [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. 1364 Ong, "Requirements for Generalized MPLS (GMPLS) Signaling 1365 Usage and Extensions for Automatically Switched Optical 1366 Network (ASON)", RFC 4139, July 2005. 1368 [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol 1369 Label Switching (GMPLS) Routing for the Automatically 1370 Switched Optical Network (ASON)", RFC 4258, November 2005. 1372 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 1373 Interpretation of Generalized Multiprotocol Label 1374 Switching (GMPLS) Terminology within the Context of the 1375 ITU-T's Automatically Switched Optical Network (ASON) 1376 Architecture", RFC 4397, February 2006. 1378 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1379 Restoration) Terminology for Generalized Multi-Protocol 1380 Label Switching (GMPLS)", RFC 4427, March 2006. 1382 [I-D.ietf-fang-mpls-tp-security-framework] 1383 Fang, L. and B. Niven-Jenkins, "Security Framework for 1384 MPLS-TP", draft-fang-mpls-tp-security-framework-00 (work 1385 in progress), July 2008. 1387 [I-D.ietf-mpls-mpls-and-gmpls-security-framework] 1388 Fang, L. and M. Behringer, "Security Framework for MPLS 1389 and GMPLS Networks", 1390 draft-ietf-mpls-mpls-and-gmpls-security-framework-05 (work 1391 in progress), November 2008. 1393 [I-D.ietf-mpls-tp-nm-req] 1394 Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network 1395 Management Requirements", draft-ietf-mpls-tp-nm-req-01 1396 (work in progress), April 2009. 1398 [I-D.helvoort-mpls-tp-rosetta-stone] 1399 van Helvoort, H., Andersson, L., and N. Sprecher, "A 1400 Thesaurus for the Terminology used in Multiprotocol Label 1401 Switching Transport Profile (MPLS-TP) drafts/RFCs and 1402 ITU-T's Transport Network Recommendations.", 1403 draft-helvoort-mpls-tp-rosetta-stone-00 (work in 1404 progress), March 2009. 1406 [I-D.ietf-mpls-tp-oam-requirements] 1407 Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1408 OAM in MPLS Transport Networks", 1409 draft-ietf-mpls-tp-oam-requirements-01 (work in progress), 1410 November 2008. 1412 [I-D.ietf-pwe3-ms-pw-arch] 1413 Bocci, M. and S. Bryant, "Requirements for OAM in MPLS 1414 Transport Networks", draft-ietf-pwe3-ms-pw-arch-06 (work 1415 in progress), September 2008. 1417 [ITU.Y1401.2008] 1418 International Telecommunications Union, "Principles of 1419 interworking", ITU-T Recommendation Y.1401, February 2008. 1421 [ITU.Y2611.2006] 1422 International Telecommunications Union, "High-level 1423 architecture of future packet-based networks", ITU- 1424 T Recommendation Y.2611, December 2006. 1426 Authors' Addresses 1428 Ben Niven-Jenkins (editor) 1429 BT 1430 208 Callisto House, Adastral Park 1431 Ipswich, Suffolk IP5 3RE 1432 UK 1434 Email: benjamin.niven-jenkins@bt.com 1436 Deborah Brungard (editor) 1437 AT&T 1438 Rm. D1-3C22 - 200 S. Laurel Ave. 1439 Middletown, NJ 07748 1440 USA 1442 Email: dbrungard@att.com 1444 Malcolm Betts (editor) 1445 Huawei Technologies 1447 Email: malcolm.betts@huawei.com 1449 Nurit Sprecher 1450 Nokia Siemens Networks 1451 3 Hanagar St. Neve Ne'eman B 1452 Hod Hasharon, 45241 1453 Israel 1455 Email: nurit.sprecher@nsn.com 1457 Satoshi Ueno 1458 NTT 1460 Email: satoshi.ueno@ntt.com