idnits 2.17.1 draft-ietf-mpls-tp-requirements-02.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (January 3, 2009) is 5589 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'R' is mentioned on line 850, but not defined == Missing Reference: 'G' is mentioned on line 850, but not defined == Outdated reference: A later version (-03) exists of draft-gray-mpls-tp-nm-req-01 == Outdated reference: A later version (-01) exists of draft-vigoureux-mpls-tp-oam-requirements-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins, Ed. 3 Internet-Draft BT 4 Intended status: Informational D. Brungard, Ed. 5 Expires: July 7, 2009 AT&T 6 M. Betts, Ed. 7 Nortel Networks 8 N. Sprecher 9 Nokia Siemens Networks 10 S. Ueno 11 NTT 12 January 3, 2009 14 MPLS-TP Requirements 15 draft-ietf-mpls-tp-requirements-02 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 July 7, 2009. 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 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Abstract 54 This document specifies the requirements of an MPLS Transport Profile 55 (MPLS-TP). This document is a product of a joint International 56 Telecommunications Union (ITU)-IETF effort to include an MPLS 57 Transport Profile within the IETF MPLS architecture to support the 58 capabilities and functionalities of a packet transport network as 59 defined by International Telecommunications Union - 60 Telecommunications Standardization Sector (ITU-T). 62 This work is based on two sources of requirements; MPLS architecture 63 as defined by IETF, and packet transport networks as defined by 64 ITU-T. 66 The requirements expressed in this document are for the behavior of 67 the protocol mechanisms and procedures that constitute building 68 blocks out of which the MPLS transport profile is constructed. The 69 requirements are not implementation requirements. 71 Requirements Language 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 81 1.2. Transport network overview . . . . . . . . . . . . . . . . 7 82 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 8 83 2.1. General requirements . . . . . . . . . . . . . . . . . . . 9 84 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 11 85 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 11 86 2.4. Control plane requirements . . . . . . . . . . . . . . . . 12 87 2.5. Network Management (NM) requirements . . . . . . . . . . . 13 88 2.6. Operation, Administration and Maintenance (OAM) 89 requirements . . . . . . . . . . . . . . . . . . . . . . . 14 90 2.7. Network performance management (PM) requirements . . . . . 14 91 2.8. Recovery & Survivability requirements . . . . . . . . . . 14 92 2.8.1. Data plane behavior requirements . . . . . . . . . . . 15 93 2.8.2. Triggers for protection, restoration, and reversion . 17 94 2.8.3. Management plane operation of protection and 95 restoration . . . . . . . . . . . . . . . . . . . . . 17 96 2.8.4. Control plane and in-band OAM operation of recovery . 18 97 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 18 98 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 22 99 2.10. Security requirements . . . . . . . . . . . . . . . . . . 22 100 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 101 4. Security Considerations . . . . . . . . . . . . . . . . . . . 23 102 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 103 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 6.1. Normative References . . . . . . . . . . . . . . . . . . . 23 105 6.2. Informative References . . . . . . . . . . . . . . . . . . 24 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 108 1. Introduction 110 For many years, Synchronous Optical Networking (SONET)/Synchronous 111 Digital hierarchy (SDH) has provided carriers with a high benchmark 112 for reliability and operational simplicity. With the accelerating 113 growth and penetration of: 115 o Packet-based services such as Ethernet, Voice over IP (VoIP), 116 Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP 117 Television (IPTV), Radio Access Network (RAN) backhauling, etc. 119 o Applications with various bandwidth and QoS requirements. 121 Carriers are in need of technologies capable of efficiently 122 supporting packet-based services and applications on their transport 123 networks. The need to increase their revenue while remaining 124 competitive forces operators to look for the lowest network Total 125 Cost of Ownership (TCO). Investment in equipment and facilities 126 (Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX) 127 should be minimized. 129 Carriers are considering migrating or evolving to packet transport 130 networks in order to reduce their costs and to improve their ability 131 to support services with guaranteed Service Level Agreements (SLAs). 132 For carriers it is important that migrating from SONET/SDH to packet 133 transport networks should not involve dramatic changes in network 134 operation, should not necessitate extensive retraining, and should 135 not require major changes to existing work practices. The aim is to 136 preserve the look-and-feel to which carriers have become accustomed 137 in deploying their SONET/SDH networks, while providing common, multi- 138 layer operations, resiliency, control and management for packet, 139 circuit and lambda transport networks. 141 Transport carriers require control and deterministic usage of network 142 resources. They need end-to-end control to engineer network paths 143 and to efficiently utilize network resources. They require 144 capabilities to support static (Operations Support System (OSS) 145 based) or dynamic (control plane) provisioning of deterministic, 146 protected and secured services and their associated resources. 148 Carriers will still need to cope with legacy networks (which are 149 composed of many layers and technologies), thus the packet transport 150 network should interwork with other packet and transport networks 151 (both horizontally and vertically). Vertical interworking is also 152 known as client/server or network interworking. Horizontal 153 interworking is also known as peer-partition or service interworking. 154 For more details on each type of interworking and some of the issues 155 that may arise (especially with horizontal interworking) see 157 [ITU.Y1401.2008]. 159 MPLS is a maturing packet technology and it is already playing an 160 important role in transport networks and services. However, not all 161 of MPLS's capabilities and mechanisms are needed and/or consistent 162 with transport network operations. There is therefore the need to 163 define an MPLS Transport Profile (MPLS-TP) in order to support the 164 capabilities and functionalities needed for packet transport network 165 services and operations through combining the packet experience of 166 MPLS with the operational experience of SONET/SDH. 168 MPLS-TP will enable the migration of SONET/SDH networks to a packet- 169 based network that will efficiently scale to support packet services 170 in a simple and cost effective way. MPLS-TP needs to combine the 171 necessary existing capabilities of MPLS with additional minimal 172 mechanisms in order that it can be used in a transport role. 174 This document specifies the requirements of an MPLS Transport Profile 175 (MPLS-TP). The requirements are for the the behavior of the protocol 176 mechanisms and procedures that constitute building blocks out of 177 which the MPLS transport profile is constructed. That is, the 178 requirements indicate what features are to be available in the MPLS 179 toolkit for use by MPLS-TP. The requirements in this document do not 180 describe what functions an MPLS-TP implementation supports. The 181 purpose of this document is to identify the toolkit and any new 182 protocol work that is required. 184 This document is a product of a joint ITU-IETF effort to include an 185 MPLS Transport Profile within the IETF MPLS architecture to support 186 the capabilities and functionalities of a packet transport network as 187 defined by ITU-T. 189 This work is based on two sources of requirements, MPLS architecture 190 as defined by IETF and packet transport networks as defined by ITU-T. 191 The requirements of MPLS-TP are provided below. The relevant 192 functions of MPLS are included in MPLS-TP, except where explicitly 193 excluded. 195 Although both static and dynamic configuration of MPLS-TP transport 196 paths (including Operations, Administration and Maintenance (OAM) and 197 protection capabilities) is required by this document, it MUST be 198 possible for operators to be able to completely operate (including 199 OAM and protection capabilities) an MPLS-TP network in the absence of 200 any control plane protocols for dynamic configuration. 202 1.1. Terminology 204 Domain: A domain represents a collection of entities (for example 205 network elements) that are grouped for a particular purpose, examples 206 of which are administrative and/or managerial responsibilities, trust 207 relationships, addressing schemes, infrastructure capabilities, 208 survivability techniques, distributions of control functionality, 209 etc. Examples of such domains include IGP areas and Autonomous 210 Systems. 212 Layer network: A layer network as defined in G.805 [ITU.G805.2000] 213 provides for the transfer of client information and independent 214 operations (OAM) of the client OAM. For an explanation of how a 215 layer network as described by G.805 relates to the OSI concept of 216 layering see Appendix I of Y.2611 [ITU.Y2611.2006]. 218 Link: A link as defined in G.805 [ITU.G805.2000] is used to describe 219 a fixed relationship between two ports within a layer network. A 220 link is not necessarily a physical link but can also be supported by 221 a transport path in the server layer (e.g. SONET/SDH, OTN or 222 MPLS-TP). 224 Logical Ring: An MPLS-TP logical ring is constructed from a set of 225 LSRs and logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 226 pseudowires) and physical data links that form a ring topology. 228 Path: See Transport path. 230 Physical Ring: An MPLS-TP physical ring is constructed from a set of 231 LSRs and physical data links that form a ring topology. 233 Ring Topology: In an MPLS-TP ring topology each LSR is connected to 234 exactly two other LSRs, each via a single point-to-point 235 bidirectional MPLS-TP capable data link. A ring may also be 236 constructed from only two LSRs where there are also exactly two 237 links. Rings may be connected to other LSRs to form a larger 238 network. Traffic originating or terminating outside the ring may be 239 carried over the ring. Client network nodes (such as CEs) may be 240 connected directly to an LSR in the ring. 242 Section: A section is a server layer (which may be MPLS-TP or a 243 different technology) which provides for encapsulation and OAM of a 244 MPLS-TP transport path client layer. A section layer may provide for 245 aggregation of multiple MPLS-TP clients. 247 Segment: A segment is a single resource or a set of cross-connected 248 resources that constitutes part of a path. A segment may be a single 249 link (hop) within a path, a series of adjacent links (hops) within a 250 path, or the entire end-to-end-path. 252 Tandem Connection: A tandem connection is an arbitrary part of a 253 transport path that can be monitored (via OAM) independently from the 254 end-to-end monitoring (OAM). It may be a segment or any other 255 ordered sequence of contiguous links and/or segments of a transport 256 path. 258 Transport path: A network connection as defined in G.805 259 [ITU.G805.2000]. A Transport path corresponds to an MPLS-TP LSP or 260 to an MPLS-TP LSP and its associated PW or PWs (Single Segment or 261 Multi-Segment). 263 Transport path layer: A layer network which provides point-to-point 264 or point-to-multipoint transport paths which are used to carry a 265 higher (client) layer network or aggregates of higher (client) layer 266 networks, for example the transport service layer. It provides for 267 independent OAM (of the client OAM) in the transport of the clients. 269 Transport service layer: A layer network in which transport paths are 270 used to carry a customer's (individual or bundled) service (may be 271 point-to-point, point-to-multipoint or multipoint-to-multipoint 272 services). 274 Transmission media layer: A layer network which provides sections 275 (two-port point-to-point connections) to carry the aggregate of 276 network transport path or network service layers on various physical 277 media. 279 1.2. Transport network overview 281 The connection (or transport path) service is the basic service 282 provided by a transport network. The purpose of a transport network 283 is to carry its clients (i.e. the stream of client PDUs or client 284 bits) between endpoints in the network (typically over several 285 intermediate nodes). These endpoints may be service switching points 286 or service terminating points. The connection services offered to 287 customers are aggregated into large transport paths with long-holding 288 times and independent OAM (of the client OAM), which contribute to 289 enabling the efficient and reliable operation of the transport 290 network. These transport paths are modified infrequently. 292 Aggregation and hierarchy are beneficial for achieving scalability 293 and security since: 295 1. They reduce the number of provisioning and forwarding states in 296 the network core. 298 2. They reduce load and the cost of implementing service assurance 299 and fault management. 301 3. Clients are encapsulated and layer associated OAM overhead is 302 added. This allows complete isolation of customer traffic and 303 its management from carrier operations. 305 An important attribute of a transport network is that it is able to 306 function regardless of which clients are using its connection service 307 or over which transmission media it is running. The client, 308 transport network and server layers are from a functional and 309 operations point of view independent layer networks. Another key 310 characteristic of transport networks is the capability to maintain 311 the integrity of the client across the transport network. A 312 transport network must provide the means to commit quality of service 313 objectives to clients. This is achieved by providing a mechanism for 314 client network service demarcation for the network path together with 315 an associated network resiliency mechanism. A transport network must 316 also provide a method of service monitoring in order to verify the 317 delivery of an agreed quality of service. This is enabled by means 318 of carrier-grade OAM tools. 320 Clients are first encapsulated. These encapsulated client signals 321 may then be aggregated into a connection for transport through the 322 network in order to optimize network management. Server layer OAM is 323 used to monitor the transport integrity of the client layer or client 324 aggregate. At any hop, the aggregated signals may be further 325 aggregated in lower layer transport network paths for transport 326 across intermediate shared links. The encapsulated client signals 327 are extracted at the edges of aggregation domains, and are either 328 delivered to the client or forwarded to another domain. In the core 329 of the network, only the server layer aggregated signals are 330 monitored; individual client signals are monitored at the network 331 boundary in the client layer network. Although the connectivity of 332 the client of the transport path layer may be point-to-point, point- 333 to-multipoint or multipoint-to-multipoint, the transport path layer 334 itself only provides point-to-point or point-to-multipoint transport 335 paths which are used to carry the client. 337 Quality-of-service mechanisms are required in the packet transport 338 network to ensure the prioritization of critical services, to 339 guarantee BW and to control jitter and delay. 341 2. MPLS-TP Requirements 342 2.1. General requirements 344 1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as 345 defined by the IETF. When MPLS offers multiple options in this 346 respect, MPLS-TP SHOULD select the minimum sub-set (necessary and 347 sufficient subset) applicable to a transport network application. 349 2 Any new functionality that is defined to fulfil the requirements 350 for MPLS-TP MUST be agreed within the IETF through the IETF 351 consensus process and MUST re-use (as far as practically 352 possible) existing MPLS standards. 354 3 Mechanisms and capabilities MUST be able to interoperate, without 355 a gateway function, with existing IETF MPLS [RFC3031] and IETF 356 PWE3 [RFC3985] control and data planes where appropriate. 358 4 MPLS-TP MUST be a connection-oriented packet switching model with 359 traffic engineering capabilities that allow deterministic control 360 of the use of network resources. 362 5 MPLS-TP MUST support traffic engineered point to point (P2P) and 363 point to multipoint (P2MP) transport paths. 365 6 MPLS-TP MUST support the logical separation of the control and 366 management planes from the data plane. 368 7 MPLS-TP MUST allow the physical separation of the control and 369 management planes from the data plane. 371 8 MPLS-TP MUST support static provisioning of transport paths via 372 an OSS, i.e. via the management plane. 374 9 Mechanisms in an MPLS-TP network that satisfy functional 375 requirements that are common to general transport networks (i.e., 376 independent of technology) SHOULD be manageable in a way that is 377 coherent with the way the equivalent mechanisms are managed in 378 other transport networks. 380 10 Static provisioning MUST NOT depend on the presence of any 381 element of a control plane. 383 11 MPLS-TP MUST support the capability for network operation 384 (including OAM and recovery) via the management plane (without 385 the use of any control plane protocols). 387 12 A solution MUST be provided to support dynamic provisioning of 388 MPLS-TP transport paths via a control plane. 390 13 The MPLS-TP data plane MUST be capable of forwarding data and 391 taken recovery actions independently of the control or management 392 plane used to operate the MPLS-TP layer network. That is, the 393 MPLS-TP data plane MUST continue to operate normally if the 394 management plane or control plane that configured the transport 395 paths fails. 397 14 MPLS-TP SHOULD support mechanisms to avoid or minimize traffic 398 impact (e.g. packet delay, reordering and loss) during network 399 reconfiguration. 401 15 MPLS-TP MUST support transport paths through multiple homogeneous 402 domains. 404 16 MPLS-TP MUST NOT dictate the deployment of any particular network 405 topology either physical or logical, however: 407 A. It MUST be possible to deploy MPLS-TP in rings. 409 B. It MUST be possible to deploy MPLS-TP in arbitrarily 410 interconnected rings with one or two points of 411 interconnection. 413 C. MPLS-TP MUST support rings of at least 16 nodes in order to 414 support the upgrade of existing TDM rings to MPLS-TP. 415 MPLS-TP SHOULD support rings with more than 16 nodes. 417 D. It MUST be possible to construct rings from equipment 418 supplied by different vendors and to interconnect rings made 419 wholly from equipment from different vendors. [Editor's 420 note: This requirement comes from work provided by ITU-T 421 Q9/15. Unless someone can provide a reason why this would 422 not be the case we should remove this requirement. It is 423 equivalent to saying that all correct implementations of 424 MPLS-TP MUST interwork.] 426 17 MPLS-TP MUST be able to scale gracefully with growing and 427 increasingly complex network topologies as well as with 428 increasing bandwidth demands, number of customers, and number of 429 services. 431 18 MPLS-TP SHOULD support mechanisms to safeguard against the 432 provisioning of transport paths which contain forwarding loops. 434 2.2. Layering requirements 436 19 An MPLS-TP network MUST be able to support one or more client 437 network layers, and MUST be able to use one or more server 438 network layers. 440 20 A solution MUST be provided to support the transport of MPLS-TP 441 transport paths over MPLS-TP (MPLS-TP as a client of MPLS-TP) 443 21 A generic and extensible solution MUST be provided to support the 444 transport of any client layer network (e.g. Ethernet, ATM, FR, 445 etc.) over an MPLS-TP layer network. 447 22 A solution MUST be provided to support the transport of MPLS-TP 448 transport paths over any server layer network (such as Ethernet, 449 SONET/SDH, OTN, etc.). 451 23 In an environment where an MPLS-TP layer network is supporting a 452 client network, and the MPLS-TP layer network is supported by a 453 server layer network then operation of the MPLS-TP layer network 454 MUST be possible without any dependencies on the server or client 455 network. 457 24 It MUST be possible to operate the layers of a multi-layer 458 network that includes an MPLS-TP layer autonomously. 460 The above are not only technology requirements, but also operational. 461 Different administrative groups may be responsible for the same layer 462 network or different layer networks. 464 25 It MUST be possible to hide MPLS-TP layer network addressing and 465 other information (e.g. topology) from client layers. 467 2.3. Data plane requirements 469 26 The identification of each transport path within its aggregate 470 MUST be supported. 472 27 A label in a particular link MUST uniquely identify the transport 473 path within that link. 475 28 A transport path's source MUST be identifiable at its destination 476 within its layer network. 478 29 MPLS-TP MUST support MPLS labels that are assigned by the 479 downstream (with respect to data flow) node per [RFC3031] and 480 [RFC3473] and MAY support context-specific MPLS labels as defined 481 in [RFC5331]. 483 30 It MUST be possible to operate and configure the MPLS-TP data 484 (transport) plane without any IP forwarding capability in the 485 MPLS-TP data plane. 487 31 MPLS-TP MUST support both unidirectional and bidirectional point- 488 to-point transport paths. 490 32 An MPLS-TP network MUST require the forward and backward 491 directions of a bidirectional transport path to follow the same 492 path at each layer. 494 33 The intermediate nodes at each layer MUST be aware about the 495 pairing relationship of the forward and the backward directions 496 belonging to the same bi-directional transport path. 498 34 MPLS-TP MAY support transport paths with asymmetric bandwidth 499 requirements, i.e. the amount of reserved bandwidth differs 500 between the forward and backward directions. 502 35 MPLS-TP MUST support unidirectional point-to-multipoint transport 503 paths. 505 36 MPLS-TP MUST be extensible in order to accommodate new types of 506 client networks and services. 508 37 MPLS-TP SHOULD support mechanisms to enable the reserved 509 bandwidth associated with a transport path to be increased 510 without impacting the > existing traffic on that transport path 512 38 MPLS-TP SHOULD support mechanisms to enable the reserved 513 bandwidth of a transport path to be decreased without impacting 514 the existing traffic on that transport path, provided that the 515 level of existing traffic is smaller than the reserved bandwidth 516 following the decrease. 518 39 MPLS-TP MUST support mechanisms which ensure the integrity of the 519 transported customer's service traffic. 521 40 MPLS-TP MUST support an unambiguous and reliable means of 522 distinguishing users' (client) packets from MPLS-TP control 523 packets (e.g. control plane, management plane, OAM and protection 524 switching packets). 526 2.4. Control plane requirements 528 This section defines the requirements that apply to MPLS-TP when a 529 control plane is deployed. 531 The requirements for ASON signalling and routing and the requirements 532 for multi-region and multi-layer networks as specified in [RFC4139], 533 [RFC4258] and [RFC5212] respectively apply to MPLS-TP. 535 [ITU-T Comment: the MPLS-TP control plane should meet the 536 requirements for ASON architecture (G.8080, ...) unless explicitly 537 excluded as well as the additional MPLS-TP specific requirements 538 explicitly added.] 540 [Editors' Note: Following other comments on above references, need to 541 produce consolidated text that references correct documents & 542 requirements.] 544 Additionally: 546 41 The MPLS-TP control pane SHOULD support control plane topology 547 and data plane topology independence. 549 42 The MPLS-TP control plane MUST be able to be operated independent 550 of any particular client or server layer control plane. 552 43 The MPLS-TP control plane MUST support establishing all the 553 connectivity patterns defined for the MPLS-TP data plane (e.g., 554 unidirectional and bidirectional P2P, unidirectional P2MP, etc.) 555 including configuration of protection functions and any 556 associated maintenance functions. 558 44 The MPLS-TP control pane MUST support the configuration and 559 modification of OAM maintenance points as well as the activation/ 560 deactivation of OAM when the transport path is established or 561 modified. 563 45 An MPLS-TP control plane MUST support operation of the recovery 564 functions described in Section 2.8. 566 46 An MPLS-TP control plane MUST scale gracefully to support a large 567 number of transport paths, nodes and links. 569 47 An MPLS-TP control plane SHOULD provide a common control 570 mechanism for architecturally similar operations. 572 2.5. Network Management (NM) requirements 574 For requirements related to NM functionality (Management Plane in 575 ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements 576 document [I-D.gray-mpls-tp-nm-req]. 578 2.6. Operation, Administration and Maintenance (OAM) requirements 580 For requirements related to OAM functionality for MPLS-TP, see the 581 MPLS-TP OAM requirements document 582 [I-D.vigoureux-mpls-tp-oam-requirements]. 584 2.7. Network performance management (PM) requirements 586 For requirements related to PM functionality for MPLS-TP, see the 587 MPLS-TP OAM requirements document 588 [I-D.vigoureux-mpls-tp-oam-requirements]. 590 2.8. Recovery & Survivability requirements 592 Network survivability plays a critical role in the delivery of 593 reliable services. Network availability is a significant contributor 594 to revenue and profit. Service guarantees in the form of SLAs 595 require a resilient network that rapidly detects facility or node 596 failures and restores network operation in accordance with the terms 597 of the SLA. 599 The requirements in this section use the recovery terminology defined 600 in RFC 4427 [RFC4427]. 602 48 MPLS-TP MUST provide protection and restoration mechanisms. 604 A. Recovery techniques used for P2P and P2MP SHOULD be identical 605 to simplify implementation and operation. However, this MUST 606 NOT override any other requirement. 608 49 MPLS-TP recovery mechanisms MUST be applicable at various levels 609 throughout the network including support for link, path segment 610 and end-to-end path, and pseudowire segment, and end-to-end 611 pseudowire recovery. 613 50 MPLS-TP recovery paths MUST meet the SLA protection objectives of 614 the service. 616 A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery 617 times from the moment of fault detection in networks with 618 spans less than 1200 km. 620 B. For protection it MUST be possible to require protection of 621 100% of the traffic on the protected path. 623 C. Recovery objectives SHOULD be configurable per transport 624 path, and SHOULD include bandwidth and QoS. 626 51 The recovery mechanisms MUST all be applicable to any topology. 628 52 The recovery mechanisms MUST operate in synergy with (including 629 coordination of timing) the recovery mechanisms present in any 630 underlying server transport network (for example, Ethernet, SDH, 631 OTN, WDM) to avoid race conditions between the layers. 633 53 MPLS-TP protection mechanisms MUST support priority logic to 634 negotiate and accommodate coexisting requests (i.e., multiple 635 requests) for protection switching (e.g., administrative requests 636 and requests due to link/node failures). 638 54 MPLS-TP recovery and reversion mechanisms MUST prevent frequent 639 operation of recovery in the event of an intermittent defect. 641 [Editors' Note: ITU-T Q9/15 and Q12/15 will provide by a 642 requirement for protection switching time in case of linear 643 protection (e.g. within 50 ms) together with a reference network.] 645 2.8.1. Data plane behavior requirements 647 General protection and survivability requirements are expressed in 648 terms of the behavior in the data plane. 650 2.8.1.1. Protection 652 55 MPLS-TP MUST support 1+1 Protection. 654 A. MPLS-TP 1+1 support MUST include bidirectional protection 655 switching for P2P connectivity, and this SHOULD be the 656 default behavior. 658 B. Unidirectional 1+1 protection for P2MP connectivity MUST be 659 supported. 661 C. Unidirectional 1+1 protection for P2P connectivity is NOT 662 REQUIRED. 664 56 MPLS-TP MUST support 1:n Protection (including 1:1 protection). 666 A. MPLS-TP 1:n support MUST include bidirectional protection 667 switching for P2P connectivity, and this SHOULD be the 668 default behavior. 670 B. Unidirectional 1:n protection for P2MP connectivity MUST be 671 supported. 673 C. Unidirectional 1:n protection for P2P connectivity is NOT 674 REQUIRED. 676 D. The action of protection switching MUST NOT cause user data 677 to loop. Backtracking is allowed. 679 57 MPLS-TP SHOULD support extra traffic carried on 1:n protection 680 resources when protection is not in use. 682 2.8.1.2. Restoration 684 58 The restoration LSP MUST be able to share resources with the LSP 685 being replaced (sometimes known as soft rerouting). 687 59 Restoration priority MUST be supported so that an implementation 688 can determine the order in which transport paths should be 689 restored (to minimize service restoration time as well as to gain 690 access to available spare capacity on the best paths). 692 60 Preemption priority MUST be supported to allow restoration to 693 displace other transport paths in the event of resource 694 constraint. 696 61 Recovery mechanisms MUST be bidirectional. 698 2.8.1.3. Sharing of protection resources 700 62 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh 701 restoration. 703 63 MPLS-TP MUST support the sharing of protection bandwidth by 704 allowing best effort traffic. 706 64 MPLS-TP MUST support the definition of shared protection groups 707 to allow the coordination of protection actions resulting from 708 triggers caused by events at different locations in the network. 710 65 MPLS-TP MUST support sharing of protection resources such that 711 protection paths that are known not to be required concurrently 712 can share the same resources. 714 2.8.1.4. Reversion 716 66 MPLS-TP protection mechanisms MUST support revertive and non- 717 revertive behavior. Reversion MUST be the default behavior. 719 67 MPLS-TP restoration mechanisms MAY support revertive and non- 720 revertive behavior. 722 2.8.2. Triggers for protection, restoration, and reversion 724 Recovery actions may be triggered from different places as follows: 726 68 MPLS-TP MUST support physical layer fault indication triggers. 728 69 MPLS-TP MUST support OAM-based triggers. 730 70 MPLS-TP MUST support management plane triggers (e.g., forced 731 switch, etc.). 733 71 There MUST be a mechanism to allow administrative recovery 734 actions to be distinguished from recovery actions initiated by 735 other triggers. 737 72 Where a control plane is present, MPLS-TP SHOULD support control 738 plane triggers. 740 2.8.3. Management plane operation of protection and restoration 742 All functions described here are for control by the operator. 744 73 It MUST be possible to configure of protection paths and 745 protection-to-working path relationships (sometimes known as 746 protection groups). 748 74 There MUST be support for pre-calculation of recovery paths. 750 75 There MUST be support for pre-provisioning of recovery paths. 752 76 The following administrative control MUST be supported: 754 A. lockout 756 B. forced switchover 758 C. manual switchover 760 D. simulated fault 762 77 There MUST be support for the configuration of timers used for 763 recovery operation. 765 78 Restoration resources MAY be pre-planned and selected a priori, 766 or computed after failure occurrence. 768 79 When preemption is supported for recovery purposes, it MUST be 769 possible for the operator to configure it. 771 80 The management plane MUST provide indications of protection 772 events and triggers. 774 81 The management plane MUST allow the current protection status of 775 all transport paths to be determined. 777 2.8.4. Control plane and in-band OAM operation of recovery 779 82 The MPLS-TP control plane (which is not mandatory in an MPLS-TP 780 implementation) MUST support: 782 A. establishment and maintenance of all recovery entities and 783 functions 785 B. signaling of administrative control 787 C. protection state coordination (PSC) 789 83 In-band OAM MAY be used for: 791 A. signaling of administrative control 793 B. protection state coordination 795 2.8.5. Topology-specific recovery mechanisms 797 84 MPLS-TP MAY support recovery mechanisms that are optimized for 798 specific network topologies. These mechanisms MUST be 799 interoperable with the mechanisms defined for arbitrary topology 800 (mesh) networks to enable protection of end-to-end transport 801 paths. 803 Note that topology-specific recovery mechanisms are subject to the 804 development of requirements using the normal IETF process. 806 2.8.5.1. Ring protection 808 Several service providers have expressed a high level of interest in 809 operating MPLS-TP in ring topologies and require a high level of 810 survivability function in these topologies. The requirements listed 811 below have been collected from these service providers and from the 812 ITU-T. 814 The main objective in considering a specific topology (such as a 815 ring) is to determine whether it is possible to optimize any 816 mechanisms such that the performance of those mechanisms within the 817 topology is significantly better than the performance of the generic 818 mechanisms in the same topology. The benefits of such optimizations 819 are traded against the costs of developing, implementing, deploying, 820 and operating the additional optimized mechanisms noting that the 821 generic mechanisms MUST continue to be supported. 823 Within the context of recovery in MPLS-TP networks, the optimization 824 criteria considered in ring topologies are as follows: 826 a. Minimize the number of OAM MEs that are needed to trigger the 827 recovery operation - less than are required by other recovery 828 mechanisms. 830 b. Minimize the number of elements of recovery in the ring - less 831 than are required by other recovery mechanisms. 833 c. Minimize the number of labels required for the protection paths 834 across the ring - less than are required by other recovery 835 mechanisms. 837 d. Minimize the amount of management plane transactions during a 838 maintenance operation (e.g., ring upgrade) - less than are 839 required by other recovery mechanisms. 841 It may be observed that this list is fully compatible with the 842 generic requirements expressed above, and that no requirements that 843 are specific to ring topologies have been identified. [Editors' 844 Note: This statement is to be confirmed at the end of the work and 845 may be removed if it does not hold.] 847 In the list of requirements below, those requirements that are 848 generic are marked "[G]"; those that are Ring-specific are marked 849 "[R]". [Editors' Note: Still need to mark up the requirements below 850 as [R] and [G].] 852 85 MPLS-TP MUST include recovery mechanisms that operate in any 853 single ring supported in MPLS-TP, and continue to operate within 854 the single rings even when the rings are interconnected. 856 86 When a network is constructed from interconnected rings, MPLS-TP 857 MUST support recovery mechanisms that protect user data that 858 traverses more than one ring. This includes the possibility of 859 failure of the ring-interconnect nodes and links. 861 87 MPLS-TP recovery in a ring MUST protect unidirectional and 862 bidirectional P2P transport paths. 864 88 MPLS-TP recovery in a ring MUST protect unidirectional P2MP 865 transport paths. 867 89 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching 868 time within 50 ms from the moment of fault detection in a network 869 with a 16 nodes ring with less than 1200 km of fiber. This is 870 NOT REQUIRED when extra traffic is present. 872 [Editor note: the opinion of some people in the T103 room in Geneva 873 is that support for extra traffic is NOT REQUIRED in ring topologies. 874 It may be further NOT REQUIRED in any topology. This is for further 875 discussion especially with respect to G.8131.] 877 90 The protection switching time in a ring MUST be independent of 878 the number of LSPs crossing the ring. 880 91 Recovery actions in a ring MUST be data plane functions 881 triggered by different elements of control. The triggers are 882 configured by management or control planes and are subject to 883 configurable policy. 885 92 The configuration and operation of recovery mechanisms in a ring 886 MUST scale well with: 888 A. the number of transport paths (must be better than linear 889 scaling) 891 B. the number of nodes on the ring (must be at least as good as 892 linear scaling) 894 C. the number of ring interconnects (must be at least as good 895 as linear scaling) 897 93 MPLS-TP recovery in ring topologies MAY support multiple 898 failures without reconfiguring the protection actions. 900 94 Recovery techniques used in a ring MUST NOT prevent the ring 901 from being connected to a general MPLS-TP network in any 902 arbitrary way, and MUST NOT prevent the operation of recovery 903 techniques in the rest of the network. 905 95 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally 906 applicable in physical and logical rings. 908 96 Recovery techniques in a ring SHOULD be identical to those in 909 general networks to simplify implementation. However, this MUST 910 NOT override any other requirement. 912 97 Recovery techniques in logical and physical rings SHOULD be 913 identical to simplify implementation and operation. However, 914 this MUST NOT override any other requirement. 916 98 The default recovery scheme in a ring MUST be bidirectional 917 recovery in order to simplify the recovery operation. 919 99 The recovery mechanism in a ring MUST support revertive 920 switching, which MUST be the default behaviour. This allows 921 optimization of the use of the ring resources, and restores the 922 preferred quality conditions for normal traffic (e.g., delay) 923 when the recovery mechanism is no longer needed. 925 100 The recovery mechanisms in a ring MUST support ways to allow 926 administrative protection switching, to be distinguished from 927 protection switching initiated by other triggers. 929 101 It MUST be possible to disable protection mechanisms on selected 930 links in a ring (depending on operator's need). 932 [Editor note: This requirement was originated from ITU-T Q9/15 and 933 needs further clarification. If it means that a lockout is required 934 for use on specific spans, then this is already covered by a general 935 requirement, and this requirement could be deleted or rewritten for 936 clarity. On the other hand, there may be another meaning in which 937 case the requirement needs to be rewritten.] 939 102 MPLS-TP recovery mechanisms in a ring MUST include a mechanism 940 to allow an implementation to handle coexisting requests (i.e., 941 multiple requests - not necessarily arriving simultaneously) for 942 protection switching based on priority. 944 103 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a 945 way to prevent frequent operation of recovery in the event of an 946 intermittent defect. 948 104 MPLS-TP MUST support the sharing of protection bandwidth in a 949 ring by allowing best effort traffic. 951 105 MPLS-TP MUST support sharing of ring protection resources such 952 that protection paths that are known not to be required 953 concurrently can share the same resources. 955 106 MUST support the coordination of triggers caused by events at 956 different locations in a ring. Note that this is the ring 957 equivalent of the definition of shared protection groups. 959 2.9. QoS requirements 961 Carriers require advanced traffic management capabilities to enforce 962 and guarantee the QoS parameters of customers' SLAs. 964 Quality of service mechanisms are REQUIRED in an MPLS-TP network to 965 ensure: 967 107 Support for differentiated services and different traffic types 968 with traffic class separation associated with different traffic. 970 108 Prioritization of critical services. 972 109 Enabling the provisioning and the guarantee of Service Level 973 Specifications (SLS), with support for hard and relative end-to- 974 end bandwidth guaranteed. 976 110 Support of services, which are sensitive to jitter and delay. 978 111 Guarantee of fair access, within a particular class, to shared 979 resources. 981 112 Guaranteed resources for in-band control and management plane 982 traffic regardless of the amount of data plane traffic. 984 113 Carriers are provided with the capability to efficiently support 985 service demands over the MPLS-TP network. This MUST include 986 support for a flexible bandwidth allocation scheme. 988 [Editors' Note: Should we refer here to the requirements specified in 989 RFC 2702?] 991 2.10. Security requirements 993 For a description of the security threats relevant in the context of 994 MPLS and GMPLS and the defensive techniques to combat those threats 995 see the Security Framework for MPLS & GMPLS Networks 996 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]. 998 3. IANA Considerations 1000 This document makes no request of IANA. 1002 Note to RFC Editor: this section may be removed on publication as an 1003 RFC. 1005 4. Security Considerations 1007 For a description of the security threats relevant in the context of 1008 MPLS and GMPLS and the defensive techniques to combat those threats 1009 see the Security Framework for MPLS & GMPLS Networks 1010 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]. 1012 5. Acknowledgements 1014 The authors would like to thank all members of the teams (the Joint 1015 Working Team, the MPLS Interoperability Design Team in the IETF, and 1016 the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and 1017 specification of MPLS Transport Profile. 1019 The authors would also like to thank Loa Andersson, Lou Berger, Italo 1020 Busi, John Drake, Adrian Farrel, Neil Harrison, Wataru Imajuku, 1021 Julien Meuric, Tom Nadeau, Hiroshi Ohta and Tomonori Takeda for their 1022 comments and enhancements to the text. 1024 An ad hoc discussion group consisting of Stewart Bryant, Italo Busi, 1025 Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, 1026 Feng Huang, Harald Kullman, Han Li, Hao Long and Nurit Sprecher 1027 provided valuable input to the requirements for deployment and 1028 survivability in ring topologies. 1030 6. References 1032 6.1. Normative References 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, March 1997. 1037 [I-D.gray-mpls-tp-nm-req] 1038 Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network 1039 Management Requirements", draft-gray-mpls-tp-nm-req-01 1040 (work in progress), July 2008. 1042 [I-D.vigoureux-mpls-tp-oam-requirements] 1043 Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1044 OAM in MPLS Transport Networks", 1045 draft-vigoureux-mpls-tp-oam-requirements-00 (work in 1046 progress), July 2008. 1048 6.2. Informative References 1050 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1051 Label Switching Architecture", RFC 3031, January 2001. 1053 [RFC3473] Berger, L., "Multiprotocol Label Switching Architecture", 1054 RFC 3473, January 2003. 1056 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1057 Edge (PWE3) Architecture", RFC 3985, March 2005. 1059 [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. 1060 Ong, "Requirements for Generalized MPLS (GMPLS) Signaling 1061 Usage and Extensions for Automatically Switched Optical 1062 Network (ASON)", RFC 4139, July 2005. 1064 [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol 1065 Label Switching (GMPLS) Routing for the Automatically 1066 Switched Optical Network (ASON)", RFC 4258, November 2005. 1068 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1069 Restoration) Terminology for Generalized Multi-Protocol 1070 Label Switching (GMPLS)", RFC 4427, March 2006. 1072 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1073 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 1074 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 1075 July 2008. 1077 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1078 Label Assignment and Context-Specific Label Space", 1079 RFC 5331, August 2008. 1081 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework] 1082 Fang, L. and M. Behringer, "Security Framework for MPLS 1083 and GMPLS Networks", 1084 draft-ietf-mpls-mpls-and-gmpls-security-framework-03 (work 1085 in progress), July 2008. 1087 [ITU.Y2611.2006] 1088 International Telecommunications Union, "High-level 1089 architecture of future packet-based networks", ITU- 1090 T Recommendation Y.2611, December 2006. 1092 [ITU.Y1401.2008] 1093 International Telecommunications Union, "Principles of 1094 interworking", ITU-T Recommendation Y.1401, February 2008. 1096 [ITU.G805.2000] 1097 International Telecommunications Union, "Generic 1098 functional architecture of transport networks", ITU- 1099 T Recommendation G.805, March 2000. 1101 Authors' Addresses 1103 Ben Niven-Jenkins (editor) 1104 BT 1105 208 Callisto House, Adastral Park 1106 Ipswich, Suffolk IP5 3RE 1107 UK 1109 Email: benjamin.niven-jenkins@bt.com 1111 Deborah Brungard (editor) 1112 AT&T 1113 Rm. D1-3C22 - 200 S. Laurel Ave. 1114 Middletown, NJ 07748 1115 USA 1117 Email: dbrungard@att.com 1119 Malcolm Betts (editor) 1120 Nortel Networks 1121 3500 Carling Avenue 1122 Ottawa, Ontario K2H 8E9 1123 Canada 1125 Email: betts01@nortel.com 1127 Nurit Sprecher 1128 Nokia Siemens Networks 1129 3 Hanagar St. Neve Ne'eman B 1130 Hod Hasharon, 45241 1131 Israel 1133 Email: nurit.sprecher@nsn.com 1134 Satoshi Ueno 1135 NTT 1137 Email: satoshi.ueno@ntt.com