idnits 2.17.1 draft-ietf-mpls-tp-requirements-04.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 document date (February 5, 2009) is 5559 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-gray-mpls-tp-nm-req-02 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 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: August 9, 2009 AT&T 6 M. Betts, Ed. 7 Nortel Networks 8 N. Sprecher 9 Nokia Siemens Networks 10 S. Ueno 11 NTT 12 February 5, 2009 14 MPLS-TP Requirements 15 draft-ietf-mpls-tp-requirements-04 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 August 9, 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 RFC 2119. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 81 1.2. Transport network overview . . . . . . . . . . . . . . . . 8 82 1.3. Layer network overview . . . . . . . . . . . . . . . . . . 10 83 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 10 84 2.1. General requirements . . . . . . . . . . . . . . . . . . . 11 85 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 12 86 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 13 87 2.4. Control plane requirements . . . . . . . . . . . . . . . . 15 88 2.5. Network Management (NM) requirements . . . . . . . . . . . 15 89 2.6. Operation, Administration and Maintenance (OAM) 90 requirements . . . . . . . . . . . . . . . . . . . . . . . 15 91 2.7. Network performance management (PM) requirements . . . . . 16 92 2.8. Recovery & Survivability requirements . . . . . . . . . . 16 93 2.8.1. Data plane behavior requirements . . . . . . . . . . . 17 94 2.8.2. Triggers for protection, restoration, and reversion . 18 95 2.8.3. Management plane operation of protection and 96 restoration . . . . . . . . . . . . . . . . . . . . . 19 97 2.8.4. Control plane and in-band OAM operation of recovery . 19 98 2.8.5. Topology-specific recovery mechanisms . . . . . . . . 20 99 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 23 100 2.10. Security requirements . . . . . . . . . . . . . . . . . . 24 101 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 102 4. Security Considerations . . . . . . . . . . . . . . . . . . . 24 103 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 104 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 6.1. Normative References . . . . . . . . . . . . . . . . . . . 25 106 6.2. Informative References . . . . . . . . . . . . . . . . . . 25 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 109 1. Introduction 111 For many years, transport networks (e.g. Synchronous Optical 112 Networking (SONET)/Synchronous Digital hierarchy (SDH)) have provided 113 carriers with a high benchmark for reliability and operational 114 simplicity. With the accelerating growth and penetration of: 116 o Packet-based services such as Ethernet, Voice over IP (VoIP), 117 Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP 118 Television (IPTV), Radio Access Network (RAN) backhauling, etc. 120 o Applications with various bandwidth and QoS requirements. 122 Carriers are in need of technologies capable of efficiently 123 supporting packet-based services and applications on their transport 124 networks. The need to increase their revenue while remaining 125 competitive forces operators to look for the lowest network Total 126 Cost of Ownership (TCO). Investment in equipment and facilities 127 (Capital Expenditure (CAPEX)) and Operational Expenditure (OPEX) 128 should be minimized. 130 Carriers are considering migrating or evolving to packet transport 131 networks in order to reduce their costs and to improve their ability 132 to support services with guaranteed Service Level Agreements (SLAs). 133 For carriers it is important that migrating from their existing 134 transport networks to packet transport networks should not involve 135 dramatic changes in network operation, should not necessitate 136 extensive retraining, and should not require major changes to 137 existing work practices. The aim is to preserve the look-and-feel to 138 which carriers have become accustomed in deploying their transport 139 networks, while providing common, multi-layer operations, resiliency, 140 control and management for packet, circuit and lambda transport 141 networks. 143 Transport carriers require control and deterministic usage of network 144 resources. They need end-to-end control to engineer network paths 145 and to efficiently utilize network resources. They require 146 capabilities to support static (Operations Support System (OSS) 147 based) or dynamic (control plane) provisioning of deterministic, 148 protected and secured services and their associated resources. 150 Carriers will still need to cope with legacy networks (which are 151 composed of many layers and technologies), thus the packet transport 152 network should interwork as appropriate with other packet and 153 transport networks (both horizontally and vertically). Vertical 154 interworking is also known as client/server or network interworking. 155 Horizontal interworking is also known as peer-partition or service 156 interworking. For more details on each type of interworking and some 157 of the issues that may arise (especially with horizontal 158 interworking) see Y.1401 [ITU.Y1401.2008]. 160 MPLS is a maturing packet technology and it is already playing an 161 important role in transport networks and services. However, not all 162 of MPLS's capabilities and mechanisms are needed and/or consistent 163 with transport network operations. There is therefore the need to 164 define an MPLS Transport Profile (MPLS-TP) in order to support the 165 capabilities and functionalities needed for packet transport network 166 services and operations through combining the packet experience of 167 MPLS with the operational experience of existing transport networks. 169 MPLS-TP will enable the migration of transport networks to a packet- 170 based network that will efficiently scale to support packet services 171 in a simple and cost effective way. MPLS-TP needs to combine the 172 necessary existing capabilities of MPLS with additional minimal 173 mechanisms in order that it can be used in a transport role. 175 This document specifies the requirements of an MPLS Transport Profile 176 (MPLS-TP). The requirements are for the the behavior of the protocol 177 mechanisms and procedures that constitute building blocks out of 178 which the MPLS transport profile is constructed. That is, the 179 requirements indicate what features are to be available in the MPLS 180 toolkit for use by MPLS-TP. The requirements in this document do not 181 describe what functions an MPLS-TP implementation supports. The 182 purpose of this document is to identify the toolkit and any new 183 protocol work that is required. 185 Although this document is not a protocol specification, the key words 186 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 187 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are used as 188 described in [RFC2119] and are to be interpreted as instructions to 189 the protocol designers producing solutions that satisfy the 190 requirements set out in this document. 192 This document is a product of a joint ITU-IETF effort to include an 193 MPLS Transport Profile within the IETF MPLS architecture to support 194 the capabilities and functionalities of a packet transport network as 195 defined by ITU-T. 197 This work is based on two sources of requirements, MPLS architecture 198 as defined by IETF and packet transport networks as defined by ITU-T. 199 The requirements of MPLS-TP are provided below. The relevant 200 functions of MPLS are included in MPLS-TP, except where explicitly 201 excluded. 203 Although both static and dynamic configuration of MPLS-TP transport 204 paths (including Operations, Administration and Maintenance (OAM) and 205 protection capabilities) is required by this document, it MUST be 206 possible for operators to be able to completely operate (including 207 OAM and protection capabilities) an MPLS-TP network in the absence of 208 any control plane protocols for dynamic configuration. 210 1.1. Terminology 212 Note: Mapping between the terms in this section and ITU-T terminology 213 will be described in a subsequent document. 215 Note: The definition of segment in a GMPLS/ASON context (i.e. as 216 defined in RFC4397 [RFC4397]) encompasses both segment and 217 concatenated segment as defined in this document. 219 Associated bidirectional path: A path that supports traffic flow in 220 both directions but which is constructed from a pair of 221 unidirectional paths (one for each direction) which are associated 222 with one another at the path's ingress/egress points. The forward 223 and backward directions may or may not follow the same route (links 224 and nodes) across the network. 226 Bidirectional path: A path where the forward and backward directions 227 follow the same route (links and nodes) across the network. 229 Concatenated Segment: A serial-compound link connection as defined in 230 G.805 [ITU.G805.2000]. A concatenated segment is a contiguous part 231 of an LSP or multi-segment PW that comprises a set of segments and 232 their interconnecting nodes in sequence. 234 Co-routed bidirectional path: A bidirectional path where the forward 235 and backward directions follow the same route (links and nodes) 236 across its layer network. 238 Domain: A domain represents a collection of entities (for example 239 network elements) that are grouped for a particular purpose, examples 240 of which are administrative and/or managerial responsibilities, trust 241 relationships, addressing schemes, infrastructure capabilities, 242 aggregation, survivability techniques, distributions of control 243 functionality, etc. Examples of such domains include IGP areas and 244 Autonomous Systems. 246 Layer network: Layer network is defined in G.805 [ITU.G805.2000]. A 247 layer network provides for the transfer of client information and 248 independent operation of the client OAM. A Layer Network may be 249 described in a service context as follows: one layer network may 250 provide a (transport) service to higher client layer network and may, 251 in turn, be a client to a lower layer network. A layer network is a 252 logical construction somewhat independent of arrangement or 253 composition of physical network elements. A particular physical 254 network element may topologically belong to more than one layer 255 network, depending on the actions it takes on the encapsulation(s) 256 associated with the logical layers (e.g. the label stack), and thus 257 could be modeled as multiple logical elements. A layer network may 258 consist of zero or more sublayers. For additional explanation of how 259 layer networks relate to the OSI concept of layering see Appendix I 260 of Y.2611 [ITU.Y2611.2006]. 262 Link: A physical or logical connection between a pair of LSRs that 263 are adjacent at the (sub)layer network under consideration. A link 264 may carry zero, one or more LSPs or PWs. A packet entering a link 265 will emerge with the same label stack entry values. 267 Logical Ring: An MPLS-TP logical ring is constructed from a set of 268 LSRs and logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 269 pseudowires) and physical data links that form a ring topology. 271 Path: See Transport path. 273 Physical Ring: An MPLS-TP physical ring is constructed from a set of 274 LSRs and physical data links that form a ring topology. 276 Ring Topology: In an MPLS-TP ring topology each LSR is connected to 277 exactly two other LSRs, each via a single point-to-point 278 bidirectional MPLS-TP capable data link. A ring may also be 279 constructed from only two LSRs where there are also exactly two 280 links. Rings may be connected to other LSRs to form a larger 281 network. Traffic originating or terminating outside the ring may be 282 carried over the ring. Client network nodes (such as CEs) may be 283 connected directly to an LSR in the ring. 285 Section: A section is a server layer (which may be MPLS-TP or a 286 different technology) which provides for encapsulation and OAM of a 287 MPLS-TP transport path client layer. A section layer may provide for 288 aggregation of multiple MPLS-TP clients. Note that G.805 289 [ITU.G805.2000] defines the section layer as one of the two layer 290 networks in a transmission media layer network. The other layer 291 network is the physical media layer network. 293 Segment: A link connection as defined in G.805 [ITU.G805.2000]. A 294 segment is the part of an LSP that traverses a single link or the 295 part of a PW that traverses a single link (i.e. that connects a pair 296 of adjacent {S|T}-PEs). 298 Sublayer: Sublayer is defined in G.805 [ITU.G805.2000]. The 299 distinction between a layer network and a sublayer is that a sublayer 300 is not directly accessible to clients outside of its encapsulating 301 layer network and offers no direct transport service for a higher 302 layer (client) network. 304 Tandem Connection: A tandem connection is an arbitrary part of a 305 transport path that can be monitored (via OAM) independently from the 306 end-to-end monitoring (OAM). It may be a monitored segment, a 307 monitored concatenated segment or any other monitored ordered 308 sequence of contiguous hops and/or segments (and their 309 interconnecting nodes) of a transport path. 311 Transport path: A network connection as defined in G.805 312 [ITU.G805.2000]. In an MPLS-TP environment a transport path 313 corresponds to an LSP or a PW. 315 Transport path layer: A layer network which provides point-to-point 316 or point-to-multipoint transport paths which are used to carry a 317 higher (client) layer network or aggregates of higher (client) layer 318 networks, for example the transport service layer. It provides for 319 independent OAM (of the client OAM) in the transport of the clients. 321 Transport service layer: A layer network in which transport paths are 322 used to carry a customer's (individual or bundled) service (may be 323 point-to-point, point-to-multipoint or multipoint-to-multipoint 324 services). 326 Transmission media layer: A layer network which provides sections 327 (two-port point-to-point connections) to carry the aggregate of 328 network transport path or network service layers on various physical 329 media. 331 Unidirectional path: A path that supports traffic flow in only one 332 direction. 334 1.2. Transport network overview 336 The connection (or transport path) service is the basic service 337 provided by a transport network. The purpose of a transport network 338 is to carry its clients (i.e. the stream of client PDUs or client 339 bits) between endpoints in the network (typically over several 340 intermediate nodes). These endpoints may be service switching points 341 or service terminating points. The connection services offered to 342 customers are aggregated into large transport paths with long-holding 343 times and independent OAM (of the client OAM), which contribute to 344 enabling the efficient and reliable operation of the transport 345 network. These transport paths are modified infrequently. 347 Aggregation and hierarchy are beneficial for achieving scalability 348 and security since: 350 1. They reduce the number of provisioning and forwarding states in 351 the network core. 353 2. They reduce load and the cost of implementing service assurance 354 and fault management. 356 3. Clients are encapsulated and layer associated OAM overhead is 357 added. This allows complete isolation of customer traffic and 358 its management from carrier operations. 360 An important attribute of a transport network is that it is able to 361 function regardless of which clients are using its connection service 362 or over which transmission media it is running. The client, 363 transport network and server layers are from a functional and 364 operations point of view independent layer networks. Another key 365 characteristic of transport networks is the capability to maintain 366 the integrity of the client across the transport network. A 367 transport network must provide the means to commit quality of service 368 objectives to clients. This is achieved by providing a mechanism for 369 client network service demarcation for the network path together with 370 an associated network resiliency mechanism. A transport network must 371 also provide a method of service monitoring in order to verify the 372 delivery of an agreed quality of service. This is enabled by means 373 of carrier-grade OAM tools. 375 Clients are first encapsulated. These encapsulated client signals 376 may then be aggregated into a connection for transport through the 377 network in order to optimize network management. Server layer OAM is 378 used to monitor the transport integrity of the client layer or client 379 aggregate. At any hop, the aggregated signals may be further 380 aggregated in lower layer transport network paths for transport 381 across intermediate shared links. The encapsulated client signals 382 are extracted at the edges of aggregation domains, and are either 383 delivered to the client or forwarded to another domain. In the core 384 of the network, only the server layer aggregated signals are 385 monitored; individual client signals are monitored at the network 386 boundary in the client layer network. Although the connectivity of 387 the client of the transport path layer may be point-to-point, point- 388 to-multipoint or multipoint-to-multipoint, the transport path layer 389 itself only provides point-to-point or point-to-multipoint transport 390 paths which are used to carry the client. 392 Quality-of-service mechanisms are required in the packet transport 393 network to ensure the prioritization of critical services, to 394 guarantee BW and to control jitter and delay. 396 1.3. Layer network overview 398 A layer network provides its clients with a transport service and the 399 operation of the layer network is independent of whatever client 400 happens to use the layer network. Information that passes between 401 any client to the layer network is common to all clients and is the 402 minimum needed to be consistent with the definition of the transport 403 service offered. The client layer network can be connectionless, 404 connection oriented packet switched, or circuit switched. The 405 transport service transfers a payload (individual packet payload for 406 connectionless networks, a sequence of packets payloads in the case 407 of connection oriented packet switched networks, and a deterministic 408 schedule of payloads in the case of circuit switched networks) such 409 that the client can populate the payload without affecting any 410 operation within the serving layer network. 412 The operations within a layer network that are independent of the 413 clients include the control of forwarding, the control of resource 414 reservation, the control of traffic demerging, and the OAM of the 415 transport service. All of these operations are internal to a layer 416 network. By definition, a layer network does not rely on any client 417 information to perform these operations and therefore all information 418 required to perform these operations is independent of whatever 419 client is using the layer network. 421 A layer network will have common features in order to support the 422 control of forwarding, resource reservation, and OAM. For example, a 423 layer network will have a common addressing scheme for the end points 424 of the transport service and a common set of transport descriptors 425 for the transport service. However, a client may use a different 426 addressing scheme or different traffic descriptors (consistent with 427 performance inheritance). 429 It is sometimes useful to independently monitor a smaller domain 430 within a layer network (or the transport services as the traverse 431 this smaller domain) but the control of forwarding or the control of 432 resource reservation involved retain their common elements. These 433 smaller monitored domains are sublayers. 435 It is sometimes useful to independently control forwarding within 436 smaller domain within a layer network but the control of resource 437 reservation and OAM retain their common elements. These smaller 438 domains are partitions of the layer network. 440 2. MPLS-TP Requirements 441 2.1. General requirements 443 1 The MPLS-TP data plane MUST be a subset of the MPLS data plane as 444 defined by the IETF. When MPLS offers multiple options in this 445 respect, MPLS-TP SHOULD select the minimum sub-set (necessary and 446 sufficient subset) applicable to a transport network application. 448 2 Any new functionality that is defined to fulfil the requirements 449 for MPLS-TP MUST be agreed within the IETF through the IETF 450 consensus process and MUST re-use (as far as practically 451 possible) existing MPLS standards. 453 3 Mechanisms and capabilities MUST be able to interoperate, without 454 a gateway function, with existing IETF MPLS [RFC3031] and IETF 455 PWE3 [RFC3985] control and data planes where appropriate. 457 4 MPLS-TP and its interfaces, both internal and external, MUST be 458 sufficiently well-defined that interworking equipment supplied by 459 multiple vendors will be possible both within a single network, 460 and between networks. 462 5 MPLS-TP MUST be a connection-oriented packet switching model with 463 traffic engineering capabilities that allow deterministic control 464 of the use of network resources. 466 6 MPLS-TP MUST support traffic engineered point to point (P2P) and 467 point to multipoint (P2MP) transport paths. 469 7 MPLS-TP MUST support the logical separation of the control and 470 management planes from the data plane. 472 8 MPLS-TP MUST allow the physical separation of the control and 473 management planes from the data plane. 475 9 MPLS-TP MUST support static provisioning of transport paths via 476 an OSS, i.e. via the management plane. 478 10 Mechanisms in an MPLS-TP network that satisfy functional 479 requirements that are common to general transport networks (i.e., 480 independent of technology) SHOULD be operable in a way that is 481 similar to the way the equivalent mechanisms are operated in 482 other transport networks. 484 11 Static provisioning MUST NOT depend on the presence of any 485 element of a control plane. 487 12 MPLS-TP MUST support the capability for network operation 488 (including OAM and recovery) via the management plane (without 489 the use of any control plane protocols). 491 13 A solution MUST be provided to support dynamic provisioning of 492 MPLS-TP transport paths via a control plane. 494 14 The MPLS-TP data plane MUST be capable of forwarding data and 495 taking recovery actions independently of the control or 496 management plane used to operate the MPLS-TP layer network. That 497 is, the MPLS-TP data plane MUST continue to operate normally if 498 the management plane or control plane that configured the 499 transport paths fails. 501 15 MPLS-TP MUST support mechanisms to avoid or minimize traffic 502 impact (e.g. packet delay, reordering and loss) during network 503 reconfiguration. 505 16 MPLS-TP MUST support transport paths through multiple homogeneous 506 domains. 508 17 MPLS-TP MUST NOT dictate the deployment of any particular network 509 topology either physical or logical, however: 511 A. It MUST be possible to deploy MPLS-TP in rings. 513 B. It MUST be possible to deploy MPLS-TP in arbitrarily 514 interconnected rings with one or two points of 515 interconnection. 517 C. MPLS-TP MUST support rings of at least 16 nodes in order to 518 support the upgrade of existing TDM rings to MPLS-TP. 519 MPLS-TP SHOULD support rings with more than 16 nodes. 521 18 MPLS-TP MUST be able to scale at least as well as existing 522 transport technologies with growing and increasingly complex 523 network topologies as well as with increasing bandwidth demands, 524 number of customers, and number of services. 526 19 MPLS-TP SHOULD support mechanisms to safeguard against the 527 provisioning of transport paths which contain forwarding loops. 529 2.2. Layering requirements 530 20 A generic and extensible solution MUST be provided to support the 531 transport of one or more client layer networks (e.g. MPLS-TP, 532 Ethernet, ATM, FR, etc.) over an MPLS-TP layer network. 534 21 A solution MUST be provided to support the transport of MPLS-TP 535 transport paths over one or more server layer networks (such as 536 MPLS-TP, Ethernet, SONET/SDH, OTN, etc.). Requirements for 537 bandwidth management within a server layer network are outside 538 the scope of this document. 540 22 In an environment where an MPLS-TP layer network is supporting a 541 client network, and the MPLS-TP layer network is supported by a 542 server layer network then operation of the MPLS-TP layer network 543 MUST be possible without any dependencies on the server or client 544 network. 546 23 It MUST be possible to operate the layers of a multi-layer 547 network that includes an MPLS-TP layer autonomously. 549 The above are not only technology requirements, but also operational. 550 Different administrative groups may be responsible for the same layer 551 network or different layer networks. 553 24 It MUST be possible to hide MPLS-TP layer network addressing and 554 other information (e.g. topology) from client layers. 556 2.3. Data plane requirements 558 25 The identification of each transport path within its aggregate 559 MUST be supported. 561 26 A label in a particular link MUST uniquely identify the transport 562 path within that link. 564 27 A transport path's source MUST be identifiable at its destination 565 within its layer network. 567 28 MPLS-TP MUST be capable of using P2MP server (sub-)layer 568 capabilities when supporting P2MP MPLS-TP transport paths (for 569 example context-specific labels [RFC5331]). 571 29 It MUST be possible to operate and configure the MPLS-TP data 572 (transport) plane without any IP forwarding capability in the 573 MPLS-TP data plane. 575 30 MPLS-TP MUST support unidirectional, bidirectional and co-routed 576 bidirectional point-to-point transport paths. 578 31 The forward and backward directions of a co-routed bidirectional 579 transport path MUST follow the same links and nodes within its 580 (sub-)layer network. 582 32 The intermediate nodes at each (sub-)layer MUST be aware about 583 the pairing relationship of the forward and the backward 584 directions belonging to the same bidirectional transport path. 586 33 MPLS-TP MAY support transport paths with asymmetric bandwidth 587 requirements, i.e. the amount of reserved bandwidth differs 588 between the forward and backward directions. 590 34 MPLS-TP MUST support unidirectional point-to-multipoint transport 591 paths. 593 35 MPLS-TP MUST be extensible in order to accommodate new types of 594 client networks and services. 596 36 MPLS-TP SHOULD support mechanisms to enable the reserved 597 bandwidth associated with a transport path to be increased 598 without impacting the existing traffic on that transport path 600 37 MPLS-TP SHOULD support mechanisms to enable the reserved 601 bandwidth of a transport path to be decreased without impacting 602 the existing traffic on that transport path, provided that the 603 level of existing traffic is smaller than the reserved bandwidth 604 following the decrease. 606 38 MPLS-TP MUST support mechanisms which ensure the integrity of the 607 transported customer's service traffic as required by its 608 associated SLA. Loss of integrity may be defined as packet 609 corruption, re-ordering or loss during normal network conditions. 611 39 MPLS-TP MUST support mechanisms to detect when loss of integrity 612 of the transported customer's service traffic has occurred. 614 40 MPLS-TP MUST support an unambiguous and reliable means of 615 distinguishing users' (client) packets from MPLS-TP control 616 packets (e.g. control plane, management plane, OAM and protection 617 switching packets). 619 2.4. Control plane requirements 621 This section defines the requirements that apply to MPLS-TP when a 622 control plane is deployed. 624 The ITU-T has defined an architecture for Automatically Switched 625 Optical and Transport Networks (ASON/ASTN) in G.8080 626 [ITU.G8080.2006]. The control plane for MPLS-TP MUST fit within the 627 ASON/ASTN architecture. 629 An interpretation of the ASON/ASTN control plane requirements in the 630 context of GMPLS can be found in [RFC4139] and [RFC4258]. 632 Additionally: 634 41 The MPLS-TP control pane SHOULD support control plane topology 635 and data plane topology independence. 637 42 The MPLS-TP control plane MUST be able to be operated independent 638 of any particular client or server layer control plane. 640 43 The MPLS-TP control plane MUST support establishing all the 641 connectivity patterns defined for the MPLS-TP data plane (e.g., 642 unidirectional and bidirectional P2P, unidirectional P2MP, etc.) 643 including configuration of protection functions and any 644 associated maintenance functions. 646 44 The MPLS-TP control pane MUST support the configuration and 647 modification of OAM maintenance points as well as the activation/ 648 deactivation of OAM when the transport path or transport service 649 is established or modified. 651 45 An MPLS-TP control plane MUST support operation of the recovery 652 functions described in Section 2.8. 654 46 An MPLS-TP control plane MUST scale gracefully to support a large 655 number of transport paths, nodes and links. 657 2.5. Network Management (NM) requirements 659 For requirements related to NM functionality (Management Plane in 660 ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements 661 document [I-D.gray-mpls-tp-nm-req]. 663 2.6. Operation, Administration and Maintenance (OAM) requirements 665 For requirements related to OAM functionality for MPLS-TP, see the 666 MPLS-TP OAM requirements document 668 [I-D.ietf-mpls-tp-oam-requirements]. 670 2.7. Network performance management (PM) requirements 672 For requirements related to PM functionality for MPLS-TP, see the 673 MPLS-TP OAM requirements document 674 [I-D.ietf-mpls-tp-oam-requirements]. 676 2.8. Recovery & Survivability requirements 678 Network survivability plays a critical role in the delivery of 679 reliable services. Network availability is a significant contributor 680 to revenue and profit. Service guarantees in the form of SLAs 681 require a resilient network that rapidly detects facility or node 682 failures and restores network operation in accordance with the terms 683 of the SLA. 685 The requirements in this section use the recovery terminology defined 686 in RFC 4427 [RFC4427]. 688 47 MPLS-TP MUST provide protection and restoration mechanisms. 690 A. Recovery techniques used for P2P and P2MP SHOULD be identical 691 to simplify implementation and operation. However, this MUST 692 NOT override any other requirement. 694 48 MPLS-TP recovery mechanisms MUST be applicable at various levels 695 throughout the network including support for link, path segment 696 and end-to-end path, and pseudowire segment, and end-to-end 697 pseudowire recovery. 699 49 MPLS-TP recovery paths MUST meet the SLA protection objectives of 700 the service. 702 A. MPLS-TP MUST provide mechanisms to guarantee 50ms recovery 703 times from the moment of fault detection in networks with 704 spans less than 1200 km. 706 B. For protection it MUST be possible to require protection of 707 100% of the traffic on the protected path. 709 C. Recovery objectives SHOULD be configurable per transport 710 path, and SHOULD include bandwidth and QoS. 712 50 The recovery mechanisms MUST all be applicable to any topology. 714 51 The recovery mechanisms MUST operate in synergy with (including 715 coordination of timing) the recovery mechanisms present in any 716 underlying server transport network (for example, Ethernet, SDH, 717 OTN, WDM) to avoid race conditions between the layers. 719 52 MPLS-TP protection mechanisms MUST support priority logic to 720 negotiate and accommodate coexisting requests (i.e., multiple 721 requests) for protection switching (e.g., administrative requests 722 and requests due to link/node failures). 724 53 MPLS-TP recovery and reversion mechanisms MUST prevent frequent 725 operation of recovery in the event of an intermittent defect. 727 2.8.1. Data plane behavior requirements 729 General protection and survivability requirements are expressed in 730 terms of the behavior in the data plane. 732 2.8.1.1. Protection 734 54 MPLS-TP MUST support 1+1 protection. 736 A. MPLS-TP 1+1 support MUST include bidirectional protection 737 switching for P2P connectivity, and this SHOULD be the 738 default behavior for 1+1 protection. 740 B. Unidirectional 1+1 protection for P2MP connectivity MUST be 741 supported. 743 C. Unidirectional 1+1 protection for P2P connectivity is not 744 required. 746 55 MPLS-TP MUST support 1:n protection (including 1:1 protection). 748 A. MPLS-TP 1:n support MUST include bidirectional protection 749 switching for P2P connectivity, and this SHOULD be the 750 default behavior for 1:n protection. 752 B. Unidirectional 1:n protection for P2MP connectivity MUST be 753 supported. 755 C. Unidirectional 1:n protection for P2P connectivity is not 756 required. 758 D. The action of protection switching MUST NOT cause user data 759 to loop. Backtracking is allowed. 761 Note: Support for extra traffic (as defined in G.870 [ITU.G870.2008]) 762 is not required in MPLS-TP. 764 2.8.1.2. Restoration 766 56 The restoration LSP MUST be able to share resources with the LSP 767 being replaced (sometimes known as soft rerouting). 769 57 Restoration priority MUST be supported so that an implementation 770 can determine the order in which transport paths should be 771 restored (to minimize service restoration time as well as to gain 772 access to available spare capacity on the best paths). 774 58 Preemption priority MUST be supported to allow restoration to 775 displace other transport paths in the event of resource 776 constraint. 778 2.8.1.3. Sharing of protection resources 780 59 MPLS-TP SHOULD support 1:n (including 1:1) shared mesh 781 restoration. 783 60 MPLS-TP MUST support the sharing of protection bandwidth by 784 allowing best effort traffic. 786 61 MPLS-TP MUST support the definition of shared protection groups 787 to allow the coordination of protection actions resulting from 788 triggers caused by events at different locations in the network. 790 62 MPLS-TP MUST support sharing of protection resources such that 791 protection paths that are known not to be required concurrently 792 can share the same resources. 794 2.8.1.4. Reversion 796 63 MPLS-TP protection mechanisms MUST support revertive and non- 797 revertive behavior. Reversion MUST be the default behavior. 799 64 MPLS-TP restoration mechanisms MAY support revertive and non- 800 revertive behavior. 802 2.8.2. Triggers for protection, restoration, and reversion 804 Recovery actions may be triggered from different places as follows: 806 65 MPLS-TP MUST support physical layer fault indication triggers. 808 66 MPLS-TP MUST support OAM-based triggers. 810 67 MPLS-TP MUST support management plane triggers (e.g., forced 811 switch, etc.). 813 68 There MUST be a mechanism to allow administrative recovery 814 actions to be distinguished from recovery actions initiated by 815 other triggers. 817 69 Where a control plane is present, MPLS-TP SHOULD support control 818 plane triggers. 820 2.8.3. Management plane operation of protection and restoration 822 All functions described here are for control by the operator. 824 70 It MUST be possible to configure of protection paths and 825 protection-to-working path relationships (sometimes known as 826 protection groups). 828 71 There MUST be support for pre-calculation of recovery paths. 830 72 There MUST be support for pre-provisioning of recovery paths. 832 73 The external controls as defined in [RFC4427] MUST be supported. 834 74 There MUST be support for the configuration of timers used for 835 recovery operation. 837 75 Restoration resources MAY be pre-planned and selected a priori, 838 or computed after failure occurrence. 840 76 When preemption is supported for recovery purposes, it MUST be 841 possible for the operator to configure it. 843 77 The management plane MUST provide indications of protection 844 events and triggers. 846 78 The management plane MUST allow the current protection status of 847 all transport paths to be determined. 849 2.8.4. Control plane and in-band OAM operation of recovery 850 79 The MPLS-TP control plane (which is not mandatory in an MPLS-TP 851 implementation) MUST support: 853 A. establishment and maintenance of all recovery entities and 854 functions 856 B. signaling of administrative control 858 C. protection state coordination (PSC) 860 80 In-band OAM MAY be used for: 862 A. signaling of administrative control 864 B. protection state coordination 866 2.8.5. Topology-specific recovery mechanisms 868 81 MPLS-TP MAY support recovery mechanisms that are optimized for 869 specific network topologies. These mechanisms MUST be 870 interoperable with the mechanisms defined for arbitrary topology 871 (mesh) networks to enable protection of end-to-end transport 872 paths. 874 Note that topology-specific recovery mechanisms are subject to the 875 development of requirements using the normal IETF process. 877 2.8.5.1. Ring protection 879 Several service providers have expressed a high level of interest in 880 operating MPLS-TP in ring topologies and require a high level of 881 survivability function in these topologies. The requirements listed 882 below have been collected from these service providers and from the 883 ITU-T. 885 The main objective in considering a specific topology (such as a 886 ring) is to determine whether it is possible to optimize any 887 mechanisms such that the performance of those mechanisms within the 888 topology is significantly better than the performance of the generic 889 mechanisms in the same topology. The benefits of such optimizations 890 are traded against the costs of developing, implementing, deploying, 891 and operating the additional optimized mechanisms noting that the 892 generic mechanisms MUST continue to be supported. 894 Within the context of recovery in MPLS-TP networks, the optimization 895 criteria considered in ring topologies are as follows: 897 a. Minimize the number of OAM MEs that are needed to trigger the 898 recovery operation - less than are required by other recovery 899 mechanisms. 901 b. Minimize the number of elements of recovery in the ring - less 902 than are required by other recovery mechanisms. 904 c. Minimize the number of labels required for the protection paths 905 across the ring - less than are required by other recovery 906 mechanisms. 908 d. Minimize the amount of management plane transactions during a 909 maintenance operation (e.g., ring upgrade) - less than are 910 required by other recovery mechanisms. 912 It may be observed that the requirements in this section are fully 913 compatible with the generic requirements expressed above, and that no 914 requirements that are specific to ring topologies have been 915 identified. 917 82 MPLS-TP MUST include recovery mechanisms that operate in any 918 single ring supported in MPLS-TP, and continue to operate within 919 the single rings even when the rings are interconnected. 921 83 When a network is constructed from interconnected rings, MPLS-TP 922 MUST support recovery mechanisms that protect user data that 923 traverses more than one ring. This includes the possibility of 924 failure of the ring-interconnect nodes and links. 926 84 MPLS-TP recovery in a ring MUST protect unidirectional and 927 bidirectional P2P transport paths. 929 85 MPLS-TP recovery in a ring MUST protect unidirectional P2MP 930 transport paths. 932 86 MPLS-TP 1+1 and 1:1 protection in a ring MUST support switching 933 time within 50 ms from the moment of fault detection in a network 934 with a 16 nodes ring with less than 1200 km of fiber. 936 87 The protection switching time in a ring MUST be independent of 937 the number of LSPs crossing the ring. 939 88 Recovery actions in a ring MUST be data plane functions triggered 940 by different elements of control. The triggers are configured by 941 management or control planes and are subject to configurable 942 policy. 944 89 The configuration and operation of recovery mechanisms in a ring 945 MUST scale well with: 947 A. the number of transport paths (must be better than linear 948 scaling) 950 B. the number of nodes on the ring (must be at least as good as 951 linear scaling) 953 C. the number of ring interconnects (must be at least as good as 954 linear scaling) 956 90 MPLS-TP recovery in ring topologies MAY support multiple failures 957 without reconfiguring the protection actions. 959 91 Recovery techniques used in a ring MUST NOT prevent the ring from 960 being connected to a general MPLS-TP network in any arbitrary 961 way, and MUST NOT prevent the operation of recovery techniques in 962 the rest of the network. 964 92 MPLS-TP Recovery mechanisms applicable to a ring MUST be equally 965 applicable in physical and logical rings. 967 93 Recovery techniques in a ring SHOULD be identical to those in 968 general networks to simplify implementation. However, this MUST 969 NOT override any other requirement. 971 94 Recovery techniques in logical and physical rings SHOULD be 972 identical to simplify implementation and operation. However, 973 this MUST NOT override any other requirement. 975 95 The default recovery scheme in a ring MUST be bidirectional 976 recovery in order to simplify the recovery operation. 978 96 The recovery mechanism in a ring MUST support revertive 979 switching, which MUST be the default behaviour. This allows 980 optimization of the use of the ring resources, and restores the 981 preferred quality conditions for normal traffic (e.g., delay) 982 when the recovery mechanism is no longer needed. 984 97 The recovery mechanisms in a ring MUST support ways to allow 985 administrative protection switching, to be distinguished from 986 protection switching initiated by other triggers. 988 98 It MUST be possible to lockout (disable) protection mechanisms on 989 selected links (spans) in a ring (depending on operator's need). 990 This may require lockout mechanisms to be applied to intermediate 991 nodes within a transport path. 993 99 MPLS-TP recovery mechanisms in a ring MUST include a mechanism 994 to allow an implementation to handle coexisting requests (i.e., 995 multiple requests - not necessarily arriving simultaneously) for 996 protection switching based on priority. 998 100 MPLS-TP recovery and reversion mechanisms in a ring MUST offer a 999 way to prevent frequent operation of recovery in the event of an 1000 intermittent defect. 1002 101 MPLS-TP MUST support the sharing of protection bandwidth in a 1003 ring by allowing best effort traffic. 1005 102 MPLS-TP MUST support sharing of ring protection resources such 1006 that protection paths that are known not to be required 1007 concurrently can share the same resources. 1009 103 MUST support the coordination of triggers caused by events at 1010 different locations in a ring. Note that this is the ring 1011 equivalent of the definition of shared protection groups. 1013 2.9. QoS requirements 1015 Carriers require advanced traffic management capabilities to enforce 1016 and guarantee the QoS parameters of customers' SLAs. 1018 Quality of service mechanisms are REQUIRED in an MPLS-TP network to 1019 ensure: 1021 104 Support for differentiated services and different traffic types 1022 with traffic class separation associated with different traffic. 1024 105 Prioritization of critical services. 1026 106 Enabling the provisioning and the guarantee of Service Level 1027 Specifications (SLS), with support for hard and relative end-to- 1028 end bandwidth guaranteed. 1030 107 Support of services, which are sensitive to jitter and delay. 1032 108 Guarantee of fair access, within a particular class, to shared 1033 resources. 1035 109 Guaranteed resources for in-band control and management plane 1036 traffic regardless of the amount of data plane traffic. 1038 110 Carriers are provided with the capability to efficiently support 1039 service demands over the MPLS-TP network. This MUST include 1040 support for a flexible bandwidth allocation scheme. 1042 2.10. Security requirements 1044 For a description of the security threats relevant in the context of 1045 MPLS and GMPLS and the defensive techniques to combat those threats 1046 see the Security Framework for MPLS & GMPLS Networks 1047 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]. 1049 3. IANA Considerations 1051 This document makes no request of IANA. 1053 Note to RFC Editor: this section may be removed on publication as an 1054 RFC. 1056 4. Security Considerations 1058 For a description of the security threats relevant in the context of 1059 MPLS and GMPLS and the defensive techniques to combat those threats 1060 see the Security Framework for MPLS & GMPLS Networks 1061 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]. 1063 5. Acknowledgements 1065 The authors would like to thank all members of the teams (the Joint 1066 Working Team, the MPLS Interoperability Design Team in the IETF, and 1067 the T-MPLS Ad Hoc Group in the ITU-T) involved in the definition and 1068 specification of MPLS Transport Profile. 1070 The authors would also like to thank Loa Andersson, Lou Berger, Italo 1071 Busi, John Drake, Adrian Farrel, Eric Gray, Neil Harrison, Huub van 1072 Helvoort, Wataru Imajuku, Julien Meuric, Tom Nadeau, Hiroshi Ohta, 1073 George Swallow, Tomonori Takeda and Maarten Vissers for their 1074 comments and enhancements to the text. 1076 An ad hoc discussion group consisting of Stewart Bryant, Italo Busi, 1077 Andrea Digiglio, Li Fang, Adrian Farrel, Jia He, Huub van Helvoort, 1078 Feng Huang, Harald Kullman, Han Li, Hao Long and Nurit Sprecher 1079 provided valuable input to the requirements for deployment and 1080 survivability in ring topologies. 1082 6. References 1084 6.1. Normative References 1086 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1087 Requirement Levels", BCP 14, RFC 2119, March 1997. 1089 [I-D.gray-mpls-tp-nm-req] 1090 Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network 1091 Management Requirements", draft-gray-mpls-tp-nm-req-02 1092 (work in progress), January 2009. 1094 [I-D.ietf-mpls-tp-oam-requirements] 1095 Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1096 OAM in MPLS Transport Networks", 1097 draft-ietf-mpls-tp-oam-requirements-00 (work in progress), 1098 November 2008. 1100 6.2. Informative References 1102 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1103 Label Switching Architecture", RFC 3031, January 2001. 1105 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1106 Edge (PWE3) Architecture", RFC 3985, March 2005. 1108 [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. 1109 Ong, "Requirements for Generalized MPLS (GMPLS) Signaling 1110 Usage and Extensions for Automatically Switched Optical 1111 Network (ASON)", RFC 4139, July 2005. 1113 [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol 1114 Label Switching (GMPLS) Routing for the Automatically 1115 Switched Optical Network (ASON)", RFC 4258, November 2005. 1117 [RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the 1118 Interpretation of Generalized Multiprotocol Label 1119 Switching (GMPLS) Terminology within the Context of the 1120 ITU-T's Automatically Switched Optical Network (ASON) 1121 Architecture", RFC 4397, February 2006. 1123 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 1124 Restoration) Terminology for Generalized Multi-Protocol 1125 Label Switching (GMPLS)", RFC 4427, March 2006. 1127 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1128 Label Assignment and Context-Specific Label Space", 1129 RFC 5331, August 2008. 1131 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework] 1132 Fang, L. and M. Behringer, "Security Framework for MPLS 1133 and GMPLS Networks", 1134 draft-ietf-mpls-mpls-and-gmpls-security-framework-04 (work 1135 in progress), November 2008. 1137 [ITU.Y2611.2006] 1138 International Telecommunications Union, "High-level 1139 architecture of future packet-based networks", ITU- 1140 T Recommendation Y.2611, December 2006. 1142 [ITU.Y1401.2008] 1143 International Telecommunications Union, "Principles of 1144 interworking", ITU-T Recommendation Y.1401, February 2008. 1146 [ITU.G805.2000] 1147 International Telecommunications Union, "Generic 1148 functional architecture of transport networks", ITU- 1149 T Recommendation G.805, March 2000. 1151 [ITU.G870.2008] 1152 International Telecommunications Union, "Terms and 1153 definitions for optical transport networks (OTN)", ITU- 1154 T Recommendation G.870, March 2008. 1156 [ITU.G8080.2006] 1157 International Telecommunications Union, "Architecture for 1158 the automatically switched optical network (ASON)", ITU- 1159 T Recommendation G.8080, June 2006. 1161 Authors' Addresses 1163 Ben Niven-Jenkins (editor) 1164 BT 1165 208 Callisto House, Adastral Park 1166 Ipswich, Suffolk IP5 3RE 1167 UK 1169 Email: benjamin.niven-jenkins@bt.com 1170 Deborah Brungard (editor) 1171 AT&T 1172 Rm. D1-3C22 - 200 S. Laurel Ave. 1173 Middletown, NJ 07748 1174 USA 1176 Email: dbrungard@att.com 1178 Malcolm Betts (editor) 1179 Nortel Networks 1180 3500 Carling Avenue 1181 Ottawa, Ontario K2H 8E9 1182 Canada 1184 Email: betts01@nortel.com 1186 Nurit Sprecher 1187 Nokia Siemens Networks 1188 3 Hanagar St. Neve Ne'eman B 1189 Hod Hasharon, 45241 1190 Israel 1192 Email: nurit.sprecher@nsn.com 1194 Satoshi Ueno 1195 NTT 1197 Email: satoshi.ueno@ntt.com