idnits 2.17.1 draft-jenkins-mpls-mpls-tp-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 839. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 03, 2008) is 5769 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF' is mentioned on line 545, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 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: January 4, 2009 AT&T 6 M. Betts, Ed. 7 Nortel Networks 8 N. Sprecher 9 Nokia Siemens Networks 10 July 03, 2008 12 MPLS-TP Requirements 13 draft-jenkins-mpls-mpls-tp-requirements-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of 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 January 4, 2009. 40 Abstract 42 This document specifies the requirements for a MPLS Transport Profile 43 (MPLS-TP). This document is a product of a joint ITU-IETF effort to 44 include a MPLS Transport Profile within the IETF MPLS architecture to 45 support the capabilities and functionalities of a packet transport 46 network as defined by ITU-T. 48 This work is based on two sources of requirements, MPLS architecture 49 as defined by IETF and packet transport networks as defined by ITU-T. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Transport network overview . . . . . . . . . . . . . . . . 5 62 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 6 63 2.1. General requirements . . . . . . . . . . . . . . . . . . . 6 64 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 7 65 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 8 66 2.4. Control plane requirements . . . . . . . . . . . . . . . . 9 67 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 68 2.6. OAM requirements . . . . . . . . . . . . . . . . . . . . . 12 69 2.7. Network performance management (PM) requirements . . . . . 12 70 2.8. Protection & Survivability requirements . . . . . . . . . 12 71 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 15 72 2.10. Security requirements . . . . . . . . . . . . . . . . . . 16 73 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 76 6. Informative References . . . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 78 Intellectual Property and Copyright Statements . . . . . . . . . . 19 80 1. Introduction 82 For many years, SONET/SDH has provided service providers with a high 83 benchmark for reliability and operational simplicity. With the 84 accelerating growth of packet-based services (such as Ethernet, VoIP, 85 L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in 86 need of capabilities to efficiently support packet-based services on 87 their transport networks. The need to increase their revenue while 88 remaining competitive forces operators to look for the lowest network 89 Total Cost of Ownership (TCO). Investment in both Capital 90 Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. 92 Carriers are considering migrating to packet transport networks in 93 order to reduce their costs and to improve their ability to support 94 services with guaranteed SLAs. Migrating from SONET/SDH to packet 95 transport networks should not involve dramatic changes in network 96 operation, should not necessitate extensive retraining, and should 97 not require major changes to existing work practices. The aim is to 98 preserve the look-and-feel to which carriers have become accustomed 99 in deploying their SONET/SDH networks, while providing common, multi- 100 layer operations, resiliency, control and management for packet, 101 circuit and lambda transport networks. 103 Service providers require control and deterministic usage of network 104 resources. They need end-to-end control to engineer network paths 105 and to efficiently utilize network resources. They require 106 capabilities to support static (OSS based) or dynamic (control plane) 107 provisioning of deterministic, protected and secured services and 108 their associated resources as well as alternative control-plane 109 options. 111 Carriers will still need to cope with legacy networks (which are 112 composed of many layers and technologies), thus the packet transport 113 network should interwork with other packet and transport networks 114 (both horizontally and vertically). Vertical interworking is also 115 known as client/server or network interworking. Horizontal 116 interworking is also known as peer-partition or service interworking. 117 For more details on each type of interworking and some of the issues 118 that may arise (especially with horizontal interworking) see 119 [ITU.Y1401.2008]. 121 MPLS is a maturing packet technology and it is already playing an 122 important role in transport networks and services. However, not all 123 of MPLS's capabilities and mechanisms are needed and/or consistent 124 with transport network operations. There is therefore the need to 125 define an MPLS Transport Profile (MPLS-TP) in order to support the 126 capabilities and functionalities needed for packet transport network 127 services and operations through combining the packet experience of 128 MPLS with the operational experience of SONET/SDH. 130 MPLS-TP will enable the migration of SONET/SDH networks to a packet- 131 based network that will easily scale to support packet services in a 132 simple and cost effective way. MPLS-TP needs to combine the 133 necessary existing capabilities of MPLS with additional minimal 134 mechanisms in order that it can be used in a transport role. 136 This document specifies the requirements for a MPLS Transport Profile 137 (MPLS-TP). This document is a product of a joint ITU-IETF effort to 138 include a MPLS Transport Profile within the IETF MPLS architecture to 139 support the capabilities and functionalities of a packet transport 140 network as defined by ITU-T. 142 This work is based on two sources of requirements, MPLS architecture 143 as defined by IETF and packet transport networks as defined by ITU-T. 144 The requirements of MPLS-TP are provided below. 146 Although both static and dynamic configuration of MPLS-TP transport 147 paths (including OAM and protection capabilities) is required by this 148 document, it MUST be possible for operators to be able to completely 149 operate (including OAM) an MPLS-TP network in the absence of any 150 control plane protocols for dynamic configuration. 152 1.1. Terminology 154 Section: A section is a network segment between two LSRs that are 155 immediately adjacent at the MPLS-TP layer. 157 Service layer: A network layer in which transport paths are used to 158 carry a customer's (individual or bundled) service (may be point-to- 159 point, point-to-multipoint or multipoint-to-multipoint services). 161 Tandem Connection: A tandem connection corresponds to a segment of a 162 path. This may be either a segment of an LSP (i.e. a sub-path), or 163 one or more segment(s) of a PW. 165 Transport path: A connection as define in G.805 [ITU.G805.2000]. 167 Transport path layer: A network layer which provides point-to-point 168 or point-to-multipoint transport paths which are used to carry 169 aggregates of the network service layer. 171 Transmission media layer: A network layer which provides sections 172 (two-port point-to-point connections) to carry the aggregate of 173 network transport path or network service layers on various physical 174 media. 176 1.2. Transport network overview 178 The connectivity service is the basic service provided by a transport 179 network. The purpose of a transport network is to transparently 180 carry its clients (i.e. the stream of client PDUs or client bits) 181 between endpoints in the network (typically over several intermediate 182 nodes). These endpoints may be service switching points or service 183 terminating points. The connectivity services offered to customers 184 are aggregated into large transport paths with long-holding times, 185 which enable the efficient and reliable operation of the transport 186 network. These transport paths are modified infrequently. 188 Aggregation and hierarchy are beneficial for achieving scalability 189 and security since: 191 1. They reduce the number of provisioning and forwarding states in 192 the network core. 194 2. They reduce load and the cost of implementing service assurance 195 and fault management. 197 3. Client signals are completely encapsulated and isolated from each 198 other. This also allows complete isolation of customer traffic 199 from carrier operations. 201 An important attribute of a transport network is its ability to 202 function independently from both its client and server (transmission 203 media) layer networks. It should be capable of transmitting over any 204 media. Another key characteristic of transport networks is the 205 capability to maintain the integrity of the client across the 206 transport network. A transport network must provide the means to 207 commit quality of service objectives to clients. This is achieved by 208 providing a mechanism for client network service demarcation for the 209 network path together with an associated network resiliency 210 mechanism. A transport network must also provide a method of service 211 monitoring in order to verify the delivery of an agreed quality of 212 service. This is enabled by means of carrier-grade OAM tools. 214 Client signals are first transparently encapsulated. These 215 encapsulated client signals are then aggregated for transport through 216 the network in order to optimize network management. Server layer 217 OAM is used to monitor the transport integrity of the client layer 218 aggregate. At any hop, the aggregated signals may be further 219 aggregated in lower layer transport network paths for transport 220 across intermediate shared links. The encapsulated client signals 221 are extracted at the edges of aggregation domains, and are either 222 delivered to the client or forwarded to another domain. In the core 223 of the network, only the server layer aggregated signals are 224 monitored; individual client signals are monitored at the network 225 boundary in the client layer network. 227 Quality-of-service mechanisms are required in the packet transport 228 network to ensure the prioritization of critical services, to 229 guarantee BW and to control jitter and delay. 231 2. MPLS-TP Requirements 233 2.1. General requirements 235 o MPLS-TP MUST offer as much commonality as possible with the MPLS 236 data plane as defined by IETF. When MPLS offers multiple options 237 in this respect, MPLS-TP SHOULD select the minimum sub-set 238 (necessary and sufficient subset) applicable to a transport 239 network application. 241 o Any new functionality that is defined to fulfil the requirements 242 for MPLS-TP MUST be agreed within IETF and re-use (as far as 243 practically possible) existing MPLS standards. 245 o Mechanisms and capabilities MUST be able to interoperate with 246 existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and 247 data planes where appropriate. 249 o MPLS-TP MUST support a connection-oriented packet switching 250 paradigm with traffic engineering capabilities that allow 251 deterministic control of the use of network resources. 253 o MPLS-TP MUST support the logical separation of the control and 254 management planes from the data plane. 256 o MPLS-TP MUST allow the physical separation of the control and 257 management planes from the data plane. 259 o MPLS-TP MUST support point to point (P2P) or point to multipoint 260 (P2MP) transport paths. 262 o MPLS-TP MUST support static provisioning of transport paths via an 263 NMS/OSS (i.e. via the management plane). 265 o Static provisioning MUST NOT depend on routing or signaling 266 protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). 268 o MPLS-TP MUST support the capability for network operation 269 (including OAM) via an NMS/OSS (without the use of any control 270 plane protocols). 272 o MPLS-TP MUST support dynamic provisioning of transport paths via a 273 control plane. 275 o The MPLS-TP data plane MUST be capable of functioning 276 independently of the control or management plane used to operate 277 the MPLS-TP layer network. That is the MPLS-TP data plane 278 operation MUST continue to operate normally if the management 279 plane or control plane that configured the transport paths fails. 281 o MPLS-TP MUST support any network topology and be able to support 282 increasing bandwidth demands, topology, number of customers or 283 number of services incrementally. 285 o MPLS-TP SHOULD support mechanisms to safeguard against the 286 provisioning of transport paths which contain forwarding loops. 288 2.2. Layering requirements 290 o An MPLS-TP network MUST operate in a multiple layer network 291 environment consisting of independent service, transport path and 292 transmission media layers. 294 MPLS-TP may be used as the service layer (for P2P and P2MP services) 295 and/or as the transport path layer within a packet transport network. 297 o An MPLS-TP layer network MUST support the transparent transport of 298 MPLS-TP and non MPLS-TP client layer networks. 300 o An MPLS-TP layer network MUST be able to be transparently carried 301 over MPLS-TP and non MPLS-TP server layer networks (such as 302 Ethernet, OTN, etc.) 304 o It MUST be possible to operate the MPLS-TP layer network 305 independently of other layer networks (either MPLS-TP or non 306 MPLS-TP). 308 The above are not only technology requirements, but also operational. 309 Different administrative groups may be responsible for the same layer 310 network or different layer networks, and require the capability for 311 autonomous network operations. 313 o It MUST be possible to hide MPLS-TP layer network addressing and 314 other information (e.g. topology) from client layers. 316 2.3. Data plane requirements 318 o The identification of each transport path within its aggregate 319 MUST be supported. 321 o A label in a particular section MUST uniquely identify the 322 transport path. 324 o A transport path's source MUST be identifiable at its destination. 326 Transport paths can be aggregated into trunks by pushing and de- 327 aggregated by popping labels. MPLS-TP labels are swapped within a 328 transport path in a layer network instance when the traffic is 329 forwarded from one MPLS-TP link to another MPLS-TP link. 331 o Labeling MUST make use of the MPLS label and label stack entry as 332 defined in RFC3032. 334 o It MUST be possible to operate and configure the MPLS-TP data 335 (transport) plane without any IP functionality. 337 o MPLS-TP MUST support both unidirectional and bi-directional point- 338 to-point transport paths. 340 o The forward and backward directions of a bi-directional transport 341 path MUST be capable of following the same path within the MPLS-TP 342 network. 344 o The intermediate nodes MUST be aware about the pairing 345 relationship of the forward and the backward directions belonging 346 to the same bi-directional transport path. 348 o MPLS-TP MUST support unidirectional point-to-multipoint transport 349 paths. 351 o MPLS-TP transport paths MUST NOT perform merging in a way that 352 prevents the unique identification of the source at the 353 destination (e.g. no use of LDP mp2p signaling in order to avoid 354 losing LSP head-end information, no use of PHP, etc). 356 o MPLS-TP MUST support transport paths through a single domain. 358 o MPLS-TP MUST support transport paths through multiple domains. 360 o MPLS-TP MUST be able to accommodate new traffic types. 362 o MPLS-TP SHOULD support mechanisms to minimize traffic impact 363 during network reconfiguration. 365 o MPLS-TP SHOULD support mechanisms which ensure the integrity of 366 the transported customer's service traffic. 368 o MPLS-TP MUST support an unambiguous and reliable means of 369 distinguishing users' (client) packets from MPLS-TP control 370 packets (e.g. control plane, management plane, OAM and protection 371 switching packets). 373 2.4. Control plane requirements 375 o A distributed control plane MAY be supported to enable fast, 376 dynamic and reliable service provisioning in multi-vendor and 377 multi-domain environments using standardized protocols that 378 guarantee interoperability. 380 o If a control plane is used for configuration of MPLS-TP transport 381 paths then: 383 * Failure of the control plane MUST NOT impact the MPLS-TP data 384 plane. 386 * Recovery of the control plane MUST NOT impact the MPLS-TP data 387 plane any more than is necessary to re-establish the control 388 plane. 390 * It MUST support the setup, modification, and release of MPLS-TP 391 transport paths and protection paths. 393 * It MUST support mechanisms to provide traffic engineering, 394 constraint-based routing and explicit path control. 396 * It MUST provide mechanisms to address QoS and performance 397 requirements (such as throughput, delay, packet loss, etc.) 398 while utilizing network resources efficiently and reliably. 400 o MPLS-TP SHOULD support off-path (out-of-band) control and 401 management planes. 403 o The MPLS-TP control plane MUST be able to be operated independent 404 of any particular client or server layer control plane. 406 o The control plane SHOULD facilitate the implementation of the 407 service by providing end-to-end seamless connectivity and service 408 assurance. 410 o The MPLS-TP control plane MUST support establishing all the 411 connectivity patterns defined for the MPLS-TP data plane (e.g., 412 uni-directional and bidirectional P2P, uni-directional P2MP, etc.) 413 including configuration of protection functions and any associated 414 maintenance functions. 416 o The MPLS-TP control pane MUST support the configuration and 417 modification of OAM maintenance points as well as the activation/ 418 deactivation of OAM when the transport path is established or 419 modified. 421 o An MPLS-TP control plane MUST support topology hiding and address 422 independence between domains. 424 o At the boundary of a domain an MPLS-TP control plane MUST support 425 unique control plane identifiers or addresses identifying boundary 426 points to be interconnected. 428 o At the boundary of a domain an MPLS-TP control plane MUST support 429 group control plane identifiers or addresses identifying sets of 430 boundary points to be interconnected. 432 o MPLS-TP data plane layer network access points (or connection 433 points that proxy for access points) SHOULD be able to be assigned 434 control plane identifiers which are available to clients to 435 identify endpoints in call or connection requests. 437 o An MPLS-TP control plane MUST support translation between 438 externally visible endpoint control plane identifiers and internal 439 network addresses. 441 o An MPLS-TP control plane MUST support constraint-based route 442 calculation. 444 o An MPLS-TP control plane MUST support provisioning and application 445 of routing constraint policies. 447 o An MPLS-TP control plane MUST support pre-provisioned path 448 protection. 450 In some situations it is impractical to expect acceptable recovery 451 performance to be achieved using dynamic recalculation of transport 452 path routes. For this reason, it is necessary to allow for pre- 453 planning of protection routes for selected transport paths. 455 o The MPLS-TP control plane MUST support fast restoration. 457 o An MPLS-TP control plane MUST scale gracefully to support a large 458 number of transport paths. 460 o An MPLS-TP control plane MUST clearly distinguish resources 461 belonging to the MPLS-TP layer network from those in other layer 462 networks that may also be under control plane control. 464 o An MPLS-TP control plane MUST support the independent unique 465 identification of control plane elements as needed to support 466 interoperability. 468 o It MUST be possible to identify and provision these elements 469 independently, in order to reorganize the control plane components 470 without impacting the data plane services and vice-versa. 472 Architecturally distinct elements in a control plane include: nodes 473 and links, control plane functional components, protocol controllers, 474 etc. 476 o An MPLS-TP control plane SHOULD provide a common control mechanism 477 for architecturally similar operations. 479 o An MPLS-TP control plane MUST support mechanisms for partitioning 480 the network under control into separate peer or hierarchical 481 control domains. 483 o To enable the deployment of a unified control plane aimed at 484 controlling the set of transport technologies used in a transport 485 network, the MPLS-TP control plane MUST also be applicable to 486 other transport layer networks and provide common operations 487 across multiple layers. In order to maintain independence between 488 MPLS-TP and its respective client and server layer networks, the 489 capability to support separate control plane instances SHOULD be 490 possible for control of transport multilayer networks. 492 o MPLS-TP SHOULD detect and recover from control plane failures and 493 degradations using graceful operations. 495 2.5. Network Management (NM) requirements 497 o MPLS-TP MUST operate under a common operation, control and 498 management paradigm with respect to other transport technologies 499 (e.g. SDH, OTN or WDM). 501 o An MPLS-TP network MUST be able to be operated with a centralized 502 NMS system. 504 o An MPLS-TP network SHOULD be able to be operated by a centralized 505 NMS system with the support of a distributed control plane. 507 o The MPLS-TP management plane MUST be able to operate independently 508 of any particular client or server layer management plane. 510 o The MPLS-TP management plane MUST support the configuration and 511 modification of OAM maintenance points as well as the activation/ 512 deactivation of OAM when the transport path is established or 513 modified. 515 For the complete set of requirements related to NM functionality for 516 MPLS-TP, see the MPLS-TP NM requirements document [REF]. 518 2.6. OAM requirements 520 o MPLS-TP SHOULD provide a comprehensive set of capabilities (that 521 are independent of and agnostic to the transmitted client 522 services) to support fault management (e.g. fault detection and 523 localization), performance monitoring (e.g. signal quality 524 measurement) of the MPLS-TP network and the services) and 525 protection switching. 527 o OAM mechanisms SHOULD detect and trigger recovery actions in case 528 of facility and equipment failures and performance degradations 529 according to the requirements of the service. 531 o MPLS-TP OAM and data MUST share the same fate. 533 o MPLS-TP OAM MUST be able to operate without IP functionality and 534 without relying on control and/or management planes. When MPLS-TP 535 is run with IP functionality, all existing IP-MPLS OAM 536 functionality, e.g. LSP-Ping, BFD and VCCV, MUST be able to 537 operate seamlessly. 539 For the complete set of requirements related to OAM functionality for 540 MPLS-TP, see the MPLS-TP OAM requirements document [REF]. 542 2.7. Network performance management (PM) requirements 544 For the complete set of requirements related to PM functionality for 545 MPLS-TP, see the MPLS-TP OAM requirements document [REF]. 547 2.8. Protection & Survivability requirements 549 Network survivability plays a critical factor in the delivery of 550 reliable services. Network availability is a significant contributor 551 to revenue and profit. Service guarantees in the form of SLAs 552 require a resilient network that rapidly detects facility or node 553 failures and restores network operation in accordance with the terms 554 of the SLA. 556 The requirements in this section use the recovery terminology defined 557 in RFC 4427 [RFC4427]. 559 o MPLS-TP MUST support transport network style protection switching 560 mechanisms (tandem network connection protection, LSP protection 561 and PW protection) to provide the appropriate recovery time 562 required to maintain customer SLAs when potentially thousands of 563 services are simultaneously affected by a single failure. 565 o MPLS-TP recovery mechanisms SHOULD be applicable at various levels 566 throughout the network including support for span, tandem 567 connection and end-to-end recovery. 569 o MPLS-TP MUST support network restoration mechanisms controlled by 570 a distributed control plane and MUST support network restoration 571 mechanisms controlled by a management plane. 573 * The restoration resources MAY be pre-planned and selected a 574 priori, or computed after failure occurrence. 576 * MPLS-TP MAY support shared-mesh restoration. 578 * MPLS-TP SHOULD support soft LSP restoration. 580 * MPLS-TP MAY support hard LSP restoration. 582 * The restoration mechanism MUST be applicable to any topology. 584 * Restoration priority MAY be implemented to determine the order 585 in which transport paths should be restored (to minimize 586 service restoration time as well as to gain access to available 587 spare capacity on the best paths). Preemption priority MAY be 588 used in the event that not all transport paths can be restored, 589 in which case transport paths with lower preemption priority 590 should be released. When preemption is supported, its use MUST 591 be operator configurable. 593 * The restoration mechanism SHOULD operate in synergy with other 594 transport network technologies (SDH, OTN, WDM). 596 o MPLS-TP MUST support data plane driven protection mechanisms 597 (without any dependency on a control plane or IP protocols) to 598 enable fast recovery from failure. 600 o If protection is supported then: 602 * MPLS-TP protection mechanisms SHOULD be applied to LSPs and 603 PWs. 605 * MPLS-TP MUST support mechanisms that rapidly detect, locate, 606 notify and remedy network faults. 608 * MPLS-TP MAY support 1:1 bidirectional protection switching. If 609 bi-directional 1:1 protection switching is activated then the 610 protection state of both ends of the protected entity MUST be 611 synchronized. 613 * MPLS-TP MAY support 1+1 unidirectional protection switching. 615 * MPLS-TP protection mechanisms MUST be applicable to point-to- 616 point and SHOULD be applicable to point-to-multipoint transport 617 paths. 619 * Protection ratio MUST be of 100%, i.e. 100% of impaired working 620 traffic MUST be protected for a failure on the working path. 621 Additionally: 623 + The QoS objectives defined by the operator MUST also be met 624 along the protection path. 626 + In the case of 1:1 protection mechanisms, the bandwidth 627 reserved for the protection path MAY be available for other 628 traffic when the working path is operational. 630 * Operator requests for manual control of protection switching 631 such as clear, lockout of protection, forced-switch and manual- 632 switch commands MUST be supported. Prioritized protection 633 between Signal Fail (SF), Signal Degradation (SD) and operator 634 switch requests MUST be supported. 636 * MPLS-TP protection mechanisms MUST support revertive and non- 637 revertive behaviour. 639 * MPLS-TP protection switching mechanisms MUST prevent frequent 640 operation of the protection switch due to an intermittent 641 defect. 643 * MPLS-TP protection mechanisms MUST ensure co-ordination of 644 timing of protection switches at multiple layers to avoid races 645 and to allow the protection switching mechanism of the server 646 layer to fix the problem before switching at the MPLS-TP layer. 648 * MPLS-TP MAY support mechanisms that are optimized for specific 649 network topologies (Ring, Mesh) in order to handle protection 650 switching in an efficient manner. 652 2.9. QoS requirements 654 Service providers require advanced traffic management capabilities to 655 enforce and guarantee the QoS parameters of customers' SLAs. 657 Quality of service mechanisms are required to ensure: 659 o Support for differentiated services and different traffic types 660 with traffic class separation associated with different traffic. 662 o Prioritization of critical services. 664 o Enabling the provisioning and the guarantee of Service Level 665 Specifications (SLS), with support for hard and relative end-to- 666 end BW guaranteed. 668 o Controlled jitter and delay. 670 o Guarantee of fair access to shared resources in an MPLS-TP 671 network. 673 o Resources for control and management plane packets so that data 674 plane traffic, regardless of the amount, will not cause control 675 and management functions to become inoperative. 677 MPLS-TP: 679 o MUST be able to deliver the same degree of QoS that has been 680 delivered by SDH/SONET systems. 682 o MUST support a method to offer packet loss objectives comparable 683 to those in TDM transport networks (only due to bit errors). 685 o SHOULD support transport and QoS mechanisms that can deliver 686 statistical multiplexing gain. Packets exceeding the agreed 687 traffic profile may be marked or discarded by the traffic 688 conditioning at the ingress of the MPLS-TP network. 690 o MUST support transport bandwidth allocation to any granularity 691 without any restrictions based on a circuit-switched multiplexing 692 hierarchy. This will provide service providers with the 693 capability to efficiently support service demands over the MPLS-TP 694 network. 696 [Should we refer here to the requirements specified in RFC 2702?] 698 2.10. Security requirements 700 o MPLS-TP MUST ensure that the network and services are secured. 702 o Traffic flows from different users MUST NOT be intermingled, but 703 if this does occur then this MUST be detectable and the 704 appropriate consequent actions taken. 706 o MPLS-TP MUST ensure the separation of customer (client) and 707 provider (server and peer network) addressing and other 708 information. 710 o MPLS-TP MUST ensure that the control and management planes as well 711 as OAM traffic are secure from external attack. 713 o MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network 714 remains secure and stable under situations of extreme stress. 716 Examples of attacks and situations of extreme stress include (but are 717 not limited to) classical security attacks (e.g., hijacking, privacy, 718 non-repudiation, etc.) and attacks on network availability (e.g., 719 denial of service (DoS) attacks). 721 3. IANA Considerations 723 This document makes no request of IANA. 725 Note to RFC Editor: this section may be removed on publication as an 726 RFC. 728 4. Security Considerations 730 This document does not by itself raise any particular security 731 considerations. 733 5. Acknowledgements 735 The authors would like to thank all members of the teams (the Joint 736 Working Team, the MPLS Interoperability Design Team in IETF and the 737 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 738 specification of MPLS Transport Profile. 740 The authors would also like to thank Italo Busi, Neil Harrison, 741 Julien Meuric, Tom Nadeau, Hiroshi Ohta and Tomonori Takeda for their 742 comments and enhancements to the text. 744 6. Informative References 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, March 1997. 749 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 750 Restoration) Terminology for Generalized Multi-Protocol 751 Label Switching (GMPLS)", RFC 4427, March 2006. 753 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 754 Label Switching Architecture", RFC 3031, January 2001. 756 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 757 Edge (PWE3) Architecture", RFC 3985, March 2005. 759 [ITU.Y1401.2008] 760 International Telecommunications Union, "Principles of 761 interworking", ITU-T Recommendation Y.1401, February 2008. 763 [ITU.G805.2000] 764 International Telecommunications Union, "Generic 765 functional architecture of transport networks", ITU- 766 T Recommendation G.805, March 2000. 768 Authors' Addresses 770 Ben Niven-Jenkins (editor) 771 BT 772 208 Callisto House, Adastral Park 773 Ipswich, Suffolk IP5 3RE 774 UK 776 Email: benjamin.niven-jenkins@bt.com 778 Deborah Brungard (editor) 779 AT&T 780 Rm. D1-3C22 - 200 S. Laurel Ave. 781 Middletown, NJ 07748 782 USA 784 Email: dbrungard@att.com 785 Malcolm Betts (editor) 786 Nortel Networks 787 3500 Carling Avenue 788 Ottawa, Ontario K2H 8E9 789 Canada 791 Email: betts01@nortel.com 793 Nurit Sprecher 794 Nokia Siemens Networks 795 3 Hanagar St. Neve Ne'eman B 796 Hod Hasharon, 45241 797 Israel 799 Email: nurit.sprecher@nsn.com 801 Full Copyright Statement 803 Copyright (C) The IETF Trust (2008). 805 This document is subject to the rights, licenses and restrictions 806 contained in BCP 78, and except as set forth therein, the authors 807 retain all their rights. 809 This document and the information contained herein are provided on an 810 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 811 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 812 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 813 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 814 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 815 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 817 Intellectual Property 819 The IETF takes no position regarding the validity or scope of any 820 Intellectual Property Rights or other rights that might be claimed to 821 pertain to the implementation or use of the technology described in 822 this document or the extent to which any license under such rights 823 might or might not be available; nor does it represent that it has 824 made any independent effort to identify any such rights. Information 825 on the procedures with respect to rights in RFC documents can be 826 found in BCP 78 and BCP 79. 828 Copies of IPR disclosures made to the IETF Secretariat and any 829 assurances of licenses to be made available, or the result of an 830 attempt made to obtain a general license or permission for the use of 831 such proprietary rights by implementers or users of this 832 specification can be obtained from the IETF on-line IPR repository at 833 http://www.ietf.org/ipr. 835 The IETF invites any interested party to bring to its attention any 836 copyrights, patents or patent applications, or other proprietary 837 rights that may cover technology that may be required to implement 838 this standard. Please address the information to the IETF at 839 ietf-ipr@ietf.org.