idnits 2.17.1 draft-ietf-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 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 800. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 806. 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 date (November 20, 2008) is 5635 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-01 == Outdated reference: A later version (-01) exists of draft-vigoureux-mpls-tp-oam-requirements-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 6 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: May 24, 2009 AT&T 6 M. Betts, Ed. 7 Nortel Networks 8 N. Sprecher 9 Nokia Siemens Networks 10 November 20, 2008 12 MPLS-TP Requirements 13 draft-ietf-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 May 24, 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 International 44 Telecommunications Union (ITU)-IETF effort to include a MPLS 45 Transport Profile within the IETF MPLS architecture to support the 46 capabilities and functionalities of a packet transport network as 47 defined by International Telecommunications Union - 48 Telecommunications Standardization Sector (ITU-T). 50 This work is based on two sources of requirements, MPLS architecture 51 as defined by IETF and packet transport networks as defined by ITU-T. 53 Requirements Language 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2. Transport network overview . . . . . . . . . . . . . . . . 5 64 2. MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . . 7 65 2.1. General requirements . . . . . . . . . . . . . . . . . . . 7 66 2.2. Layering requirements . . . . . . . . . . . . . . . . . . 8 67 2.3. Data plane requirements . . . . . . . . . . . . . . . . . 9 68 2.4. Control plane requirements . . . . . . . . . . . . . . . . 10 69 2.5. Network Management (NM) requirements . . . . . . . . . . . 11 70 2.6. Operation, Administration and Maintenance (OAM) 71 requirements . . . . . . . . . . . . . . . . . . . . . . . 11 72 2.7. Network performance management (PM) requirements . . . . . 11 73 2.8. Protection & Survivability requirements . . . . . . . . . 11 74 2.9. QoS requirements . . . . . . . . . . . . . . . . . . . . . 14 75 2.10. Security requirements . . . . . . . . . . . . . . . . . . 14 76 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 79 6. Informative References . . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Intellectual Property and Copyright Statements . . . . . . . . . . 18 83 1. Introduction 85 For many years, Synchronous Optical Networking (SONET)/Synchronous 86 Digital hierarchy (SDH) has provided carriers with a high benchmark 87 for reliability and operational simplicity. With the accelerating 88 growth of packet-based services (such as Ethernet, Voice over IP 89 (VoIP), Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP 90 Television (IPTV), Radio Access Network (RAN) backhauling, etc.), 91 carriers are in need of capabilities to efficiently support packet- 92 based services on their transport networks. The need to increase 93 their revenue while remaining competitive forces operators to look 94 for the lowest network Total Cost of Ownership (TCO). Investment in 95 equipment and facilities (Capital Expenditure (CAPEX)) and 96 Operational Expenditure (OPEX) should be minimized. 98 Carriers are considering migrating or evolving to packet transport 99 networks in order to reduce their costs and to improve their ability 100 to support services with guaranteed Service Level Agreements (SLAs). 101 For carriers it is important that migrating from SONET/SDH to packet 102 transport networks should not involve dramatic changes in network 103 operation, should not necessitate extensive retraining, and should 104 not require major changes to existing work practices. The aim is to 105 preserve the look-and-feel to which carriers have become accustomed 106 in deploying their SONET/SDH networks, while providing common, multi- 107 layer operations, resiliency, control and management for packet, 108 circuit and lambda transport networks. 110 Transport carriers require control and deterministic usage of network 111 resources. They need end-to-end control to engineer network paths 112 and to efficiently utilize network resources. They require 113 capabilities to support static (Operational Support System (OSS) 114 based) or dynamic (control plane) provisioning of deterministic, 115 protected and secured services and their associated resources. 117 Carriers will still need to cope with legacy networks (which are 118 composed of many layers and technologies), thus the packet transport 119 network should interwork with other packet and transport networks 120 (both horizontally and vertically). Vertical interworking is also 121 known as client/server or network interworking. Horizontal 122 interworking is also known as peer-partition or service interworking. 123 For more details on each type of interworking and some of the issues 124 that may arise (especially with horizontal interworking) see 125 [ITU.Y1401.2008]. 127 MPLS is a maturing packet technology and it is already playing an 128 important role in transport networks and services. However, not all 129 of MPLS's capabilities and mechanisms are needed and/or consistent 130 with transport network operations. There is therefore the need to 131 define an MPLS Transport Profile (MPLS-TP) in order to support the 132 capabilities and functionalities needed for packet transport network 133 services and operations through combining the packet experience of 134 MPLS with the operational experience of SONET/SDH. 136 MPLS-TP will enable the migration of SONET/SDH networks to a packet- 137 based network that will efficiently scale to support packet services 138 in a simple and cost effective way. MPLS-TP needs to combine the 139 necessary existing capabilities of MPLS with additional minimal 140 mechanisms in order that it can be used in a transport role. 142 This document specifies the requirements for a MPLS Transport Profile 143 (MPLS-TP). This document is a product of a joint ITU-IETF effort to 144 include a MPLS Transport Profile within the IETF MPLS architecture to 145 support the capabilities and functionalities of a packet transport 146 network as defined by ITU-T. 148 This work is based on two sources of requirements, MPLS architecture 149 as defined by IETF and packet transport networks as defined by ITU-T. 150 The requirements of MPLS-TP are provided below. The relevant 151 functions of MPLS are included in MPLS-TP, except where explicitly 152 excluded. 154 Although both static and dynamic configuration of MPLS-TP transport 155 paths (including Operations, Administration and Maintenance (OAM) and 156 protection capabilities) is required by this document, it MUST be 157 possible for operators to be able to completely operate (including 158 OAM and protection capabilities) an MPLS-TP network in the absence of 159 any control plane protocols for dynamic configuration. 161 1.1. Terminology 163 Domain: A domain represents a collection of entities (for example 164 network elements) that are grouped for a particular purpose, examples 165 of which are administrative and/or managerial responsibilities, trust 166 relationships, addressing schemes, infrastructure capabilities, 167 survivability techniques, distributions of control functionality, 168 etc. Examples of such domains include IGP areas and Autonomous 169 Systems. 171 Layer network: A layer network as defined in G.805 [ITU.G805.2000] 172 provides for the transfer of client information and independent 173 operations (OAM) of the client OAM. For an explanation of how a 174 layer network as described by G.805 relates to the OSI concept of 175 layering see Appendix I of Y.2611 [ITU.Y2611.2006]. 177 Link: A link as defined in G.805 [ITU.G805.2000] is used to describe 178 a fixed relationship between two ports. 180 Path: See Transport path. 182 Section: A section is a MPLS-TP network server layer which provides 183 for encapsulation and OAM of a MPLS-TP transport path client layer. 184 A section layer may provide for aggregation of multiple MPLS-TP 185 clients. 187 Segment: A segment corresponds to part of a path. A segment may be a 188 single link (hop) within a path, a series of adjacent links (hops) 189 within a path, or the entire end-to-end-path. 191 Service layer: A layer network in which transport paths are used to 192 carry a customer's (individual or bundled) service (may be point-to- 193 point, point-to-multipoint or multipoint-to-multipoint services). 195 Span: A span is synonymous with a link. 197 Tandem Connection: A tandem connection corresponds to a segment of a 198 path. This may be either a segment of an LSP (i.e. a sub-path), or 199 one or more segment(s) of a PW. 201 Transport path: A connection as defined in G.805 [ITU.G805.2000]. 202 The combination of a PW (Single Segment or Multi-Segment) and LSP 203 corresponds to an MPLS-TP transport path. 205 Transport path layer: A layer network which provides point-to-point 206 or point-to-multipoint transport paths which are used to carry a 207 higher (client) layer network or aggregates of higher (client) layer 208 networks, for example the network service layer. It provides for 209 independent OAM (of the client OAM) in the transport of the clients. 211 Transmission media layer: A layer network which provides sections 212 (two-port point-to-point connections) to carry the aggregate of 213 network transport path or network service layers on various physical 214 media. 216 1.2. Transport network overview 218 The connection (or transport path) service is the basic service 219 provided by a transport network. The purpose of a transport network 220 is to carry its clients (i.e. the stream of client PDUs or client 221 bits) between endpoints in the network (typically over several 222 intermediate nodes). These endpoints may be service switching points 223 or service terminating points. The connection services offered to 224 customers are aggregated into large transport paths with long-holding 225 times and independent OAM (of the client OAM), which contribute to 226 enabling the efficient and reliable operation of the transport 227 network. These transport paths are modified infrequently. 229 Aggregation and hierarchy are beneficial for achieving scalability 230 and security since: 232 1. They reduce the number of provisioning and forwarding states in 233 the network core. 235 2. They reduce load and the cost of implementing service assurance 236 and fault management. 238 3. Clients are encapsulated and layer associated OAM overhead is 239 added. This allows complete isolation of customer traffic and 240 its management from carrier operations. 242 An important attribute of a transport network is that it is able to 243 function regardless of which clients are using its connection service 244 or over which transmission media it is running. The client, 245 transport network and server layers are from a functional and 246 operations point of view independent layer networks. Another key 247 characteristic of transport networks is the capability to maintain 248 the integrity of the client across the transport network. A 249 transport network must provide the means to commit quality of service 250 objectives to clients. This is achieved by providing a mechanism for 251 client network service demarcation for the network path together with 252 an associated network resiliency mechanism. A transport network must 253 also provide a method of service monitoring in order to verify the 254 delivery of an agreed quality of service. This is enabled by means 255 of carrier-grade OAM tools. 257 Clients are first encapsulated. These encapsulated client signals 258 may then be aggregated into a connection for transport through the 259 network in order to optimize network management. Server layer OAM is 260 used to monitor the transport integrity of the client layer or client 261 aggregate. At any hop, the aggregated signals may be further 262 aggregated in lower layer transport network paths for transport 263 across intermediate shared links. The encapsulated client signals 264 are extracted at the edges of aggregation domains, and are either 265 delivered to the client or forwarded to another domain. In the core 266 of the network, only the server layer aggregated signals are 267 monitored; individual client signals are monitored at the network 268 boundary in the client layer network. 270 Quality-of-service mechanisms are required in the packet transport 271 network to ensure the prioritization of critical services, to 272 guarantee BW and to control jitter and delay. 274 2. MPLS-TP Requirements 276 2.1. General requirements 278 1 MPLS-TP MUST be compatible with the MPLS data plane as defined by 279 IETF. When MPLS offers multiple options in this respect, MPLS-TP 280 SHOULD select the minimum sub-set (necessary and sufficient 281 subset) applicable to a transport network application. 283 2 Any new functionality that is defined to fulfil the requirements 284 for MPLS-TP MUST be agreed within IETF and re-use (as far as 285 practically possible) existing MPLS standards. 287 3 Mechanisms and capabilities MUST be able to interoperate with 288 existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and 289 data planes where appropriate. 291 4 MPLS-TP MUST support a connection-oriented packet switching 292 paradigm with traffic engineering capabilities that allow 293 deterministic control of the use of network resources. 295 5 MPLS-TP MUST support traffic engineered point to point (P2P) or 296 point to multipoint (P2MP) transport paths. 298 6 MPLS-TP MUST support the logical separation of the control and 299 management planes from the data plane. 301 7 MPLS-TP MUST allow the physical separation of the control and 302 management planes from the data plane. 304 8 MPLS-TP MUST support static provisioning of transport paths via a 305 Network Management System (NMS) or OSS (i.e. via the management 306 plane). 308 9 Static provisioning MUST NOT depend on routing or signaling 309 protocols (e.g. Generalized Multiprotocol Label Switching 310 (GMPLS), Open Shortest Path First (OSPF), Intermediate System to 311 Intermediate Systems (ISIS), Resource Reservation Protocol 312 (RSVP), Border gateway Protocol (BGP), Label Distribution 313 Protocol (LDP) etc.). 315 10 MPLS-TP MUST support the capability for network operation 316 (including OAM) via an NMS/OSS (without the use of any control 317 plane protocols). 319 11 A solution MUST be provided to suppor dynamic provisioning of 320 MPLS-TP transport paths via a control plane. 322 12 The MPLS-TP data plane MUST be capable of functioning 323 independently of the control or management plane used to operate 324 the MPLS-TP layer network. That is the MPLS-TP data plane 325 operation MUST continue to operate normally if the management 326 plane or control plane that configured the transport paths fails. 328 13 MPLS-TP MUST support transport paths through multiple homogeneous 329 domains. 331 14 MPLS-TP MUST NOT dictate the deployment of any particular network 332 topology either physical or logical. 334 15 MPLS-TP MUST be able to scale with growing and increasingly 335 complex network topologies as well as increasing bandwidth 336 demands, number of customers or number of services. 338 16 MPLS-TP SHOULD support mechanisms to safeguard against the 339 provisioning of transport paths which contain forwarding loops. 341 2.2. Layering requirements 343 17 An MPLS-TP network MUST operate in a multiple layer network 344 environment consisting of independent service, transport path and 345 transmission media layers. 347 MPLS-TP may be used as the service layer (for P2P and P2MP services) 348 and/or as the transport path layer within a packet transport network. 350 18 A solution MUST be provided to support the transport of MPLS-TP 351 and non MPLS-TP client layer networks over an MPLS-TP layer 352 network. 354 19 A solution MUST be provided to support the transport of an 355 MPLS-TP layer network over MPLS-TP and non MPLS-TP server layer 356 networks (such as Ethernet, OTN, etc.) 358 20 In an environment where an MPLS-TP layer network is supporting a 359 client network, and the MPLS-TP layer network is supported by a 360 server layer network then operation of the MPLS-TP layer network 361 MUST be possible without any dependencies on the server or client 362 network. 364 The above are not only technology requirements, but also operational. 365 Different administrative groups may be responsible for the same layer 366 network or different layer networks, and require the capability for 367 autonomous network operations. 369 21 It MUST be possible to hide MPLS-TP layer network addressing and 370 other information (e.g. topology) from client layers. 372 2.3. Data plane requirements 374 22 The identification of each transport path within its aggregate 375 MUST be supported. 377 23 A label in a particular section MUST uniquely identify the 378 transport path. 380 24 A transport path's source MUST be identifiable at its 381 destination. 383 Transport paths can be aggregated by pushing and de-aggregated by 384 popping labels. MPLS-TP labels are swapped within a transport path 385 in a layer network instance when the traffic is forwarded from one 386 MPLS-TP link to another MPLS-TP link. 388 25 MPLS-TP MUST support MPLS labels that are assigned by the 389 downstream (with respect to data flow) node per [RFC3031] and 390 [RFC3473] and MAY support context-specific MPLS labels as defined 391 in [RFC5331]. 393 26 It MUST be possible to operate and configure the MPLS-TP data 394 (transport) plane without any IP forwarding capability in the 395 MPLS-TP data plane. 397 27 MPLS-TP MUST support both unidirectional and bi-directional 398 point-to-point transport paths. 400 28 An MPLS-TP network MUST require the forward and backward 401 directions of a bi-directional transport path to follow the same 402 path at each layer. 404 29 The intermediate nodes at each layer MUST be aware about the 405 pairing relationship of the forward and the backward directions 406 belonging to the same bi-directional transport path. 408 30 MPLS-TP MUST support unidirectional point-to-multipoint transport 409 paths. 411 31 MPLS-TP transport paths MUST NOT perform merging in a way that 412 prevents the unique identification of the source at the 413 destination (e.g. no use of LDP mp2p signaling in order to avoid 414 losing LSP head-end information, no use of PHP, etc). 416 32 MPLS-TP MUST be able to accommodate new types of client networks 417 and services. 419 33 MPLS-TP SHOULD support mechanisms to minimize traffic impact 420 during network reconfiguration. 422 34 MPLS-TP SHOULD support mechanisms which ensure the integrity of 423 the transported customer's service traffic. 425 35 MPLS-TP MUST support an unambiguous and reliable means of 426 distinguishing users' (client) packets from MPLS-TP control 427 packets (e.g. control plane, management plane, OAM and protection 428 switching packets). 430 2.4. Control plane requirements 432 The requirements for ASON signalling and routing and the requirements 433 for multi-region and multi-layer networks as specified in [RFC4139], 434 [RFC4258] and [RFC5212] respectively apply to MPLS-TP. 436 Additionally: 438 36 MPLS-TP SHOULD support control plane topologies that are 439 independent of the data plane topology. 441 37 The MPLS-TP control plane MUST be able to be operated independent 442 of any particular client or server layer control plane. 444 38 The MPLS-TP control plane MUST support establishing all the 445 connectivity patterns defined for the MPLS-TP data plane (e.g., 446 uni-directional and bidirectional P2P, uni-directional P2MP, 447 etc.) including configuration of protection functions and any 448 associated maintenance functions. 450 39 The MPLS-TP control pane MUST support the configuration and 451 modification of OAM maintenance points as well as the activation/ 452 deactivation of OAM when the transport path is established or 453 modified. 455 40 An MPLS-TP control plane MUST support pre-allocated path 456 protection. 458 In some situations it is impractical to expect acceptable recovery 459 performance to be achieved using dynamic recalculation of transport 460 path routes. For this reason, it is necessary to allow for pre- 461 planning of protection routes for selected transport paths. 463 41 An MPLS-TP control plane MUST scale gracefully to support a large 464 number of transport paths. 466 42 An MPLS-TP control plane SHOULD provide a common control 467 mechanism for architecturally similar operations. 469 2.5. Network Management (NM) requirements 471 For requirements related to NM functionality for MPLS-TP, see the 472 MPLS-TP NM requirements document [I-D.gray-mpls-tp-nm-req]. 474 2.6. Operation, Administration and Maintenance (OAM) requirements 476 For requirements related to OAM functionality for MPLS-TP, see the 477 MPLS-TP OAM requirements document 478 [I-D.vigoureux-mpls-tp-oam-requirements]. 480 2.7. Network performance management (PM) requirements 482 For requirements related to PM functionality for MPLS-TP, see the 483 MPLS-TP OAM requirements document 484 [I-D.vigoureux-mpls-tp-oam-requirements]. 486 2.8. Protection & Survivability requirements 488 Network survivability plays a critical factor in the delivery of 489 reliable services. Network availability is a significant contributor 490 to revenue and profit. Service guarantees in the form of SLAs 491 require a resilient network that rapidly detects facility or node 492 failures and restores network operation in accordance with the terms 493 of the SLA. 495 The requirements in this section use the recovery terminology defined 496 in RFC 4427 [RFC4427]. 498 43 MPLS-TP MUST support transport network style protection switching 499 mechanisms (tandem network connection protection, LSP protection 500 and PW protection) to provide the appropriate recovery time 501 required to maintain customer SLAs when potentially thousands of 502 services are simultaneously affected by a single failure. 504 44 MPLS-TP recovery mechanisms MUST be applicable at various levels 505 throughout the network including support for span, tandem 506 connection and end-to-end recovery. 508 45 MPLS-TP MUST support network restoration mechanisms controlled by 509 a distributed control plane and MUST support network restoration 510 mechanisms controlled by a management plane. 512 A. The restoration resources MAY be pre-planned and selected a 513 priori, or computed after failure occurrence. 515 B. MPLS-TP MAY support shared-mesh restoration. 517 C. MPLS-TP MUST support soft (make before break) LSP 518 restoration. 520 D. MPLS-TP MAY support hard (break before make) LSP restoration. 522 E. The restoration mechanism MUST be applicable to any topology. 524 F. Restoration priority MUST be implemented to determine the 525 order in which transport paths should be restored (to 526 minimize service restoration time as well as to gain access 527 to available spare capacity on the best paths). Preemption 528 priority MUST be supported, so that in the event that not all 529 transport paths can be restored transport paths with lower 530 preemption priority can be released. When preemption is 531 supported, its use MUST be operator configurable. 533 G. The restoration mechanism MUST operate in synergy with other 534 transport network technologies (SDH, OTN, WDM). 536 46 MPLS-TP MUST support inband OAM driven protection mechanisms 537 (without any dependency on a control plane) to enable fast 538 recovery from failure. 540 47 If protection is supported then: 542 A. MPLS-TP protection mechanisms MUST apply to LSPs and PWs. 544 B. MPLS-TP MUST support mechanisms that rapidly detect, locate, 545 notify and remedy network faults. 547 C. MPLS-TP MAY support 1:1 bidirectional protection switching. 548 If bi-directional 1:1 protection switching is activated then 549 the protection state of both ends of the protected entity 550 MUST be synchronized. 552 D. MPLS-TP MAY support 1+1 unidirectional protection switching. 554 E. MPLS-TP protection mechanisms MUST be applicable to point-to- 555 point and point-to-multipoint transport paths. 557 F. Protection ratio MUST be of 100%, i.e. 100% of impaired 558 working traffic MUST be protected for a failure on the 559 working path. Additionally: 561 1. The QoS objectives defined by the operator MUST also be 562 met along the protection path. 564 2. In the case of 1:1 protection mechanisms, the bandwidth 565 reserved for the protection path MAY be available for 566 other traffic when the working path is operational. 568 G. Operator requests for manual control of protection switching 569 such as clear, lockout of protection, forced-switch and 570 manual-switch commands MUST be supported. Prioritized 571 protection between Signal Fail (SF), Signal Degradation (SD) 572 and operator switch requests MUST be supported. 574 H. MPLS-TP protection mechanisms MUST support priority logic to 575 negotiate and accommodate coexisting requests (i.e. multiple 576 requests) for protection switching (e.g. "administrative" 577 requests and requests due to link/node failures). 579 I. MPLS-TP protection mechanisms MUST support revertive and non- 580 revertive behaviour. 582 J. MPLS-TP protection switching mechanisms MUST prevent frequent 583 operation of the protection switch due to an intermittent 584 defect. 586 K. MPLS-TP protection mechanisms MUST ensure co-ordination of 587 timing of protection switches at multiple layers to avoid 588 races and to allow the protection switching mechanism of the 589 server layer to fix the problem before switching at the 590 MPLS-TP layer. 592 L. MPLS-TP MAY support mechanisms that are optimized for 593 specific network topologies (e.g. ring). These mechanisms 594 MUST be interoperable with the mechanisms defined for 595 arbitrary topology (mesh) networks. 597 M. If optimised mechanisms for ring topologies are supported 598 then they MUST support switching times within 50 ms 599 (depending on CV rate configuration) assuming a reference 600 network of a 16 node ring with less than 1200 Km of fiber, as 601 defined by ITU SG15, Question 9. 603 2.9. QoS requirements 605 Carriers require advanced traffic management capabilities to enforce 606 and guarantee the QoS parameters of customers' SLAs. 608 Quality of service mechanisms are required to ensure: 610 48 Support for differentiated services and different traffic types 611 with traffic class separation associated with different traffic. 613 49 Prioritization of critical services. 615 50 Enabling the provisioning and the guarantee of Service Level 616 Specifications (SLS), with support for hard and relative end-to- 617 end BW guaranteed. 619 51 Controlled jitter and delay. 621 52 Guarantee of fair access to shared resources in an MPLS-TP 622 network. 624 53 Resources for control and management plane packets so that data 625 plane traffic, regardless of the amount, will not cause control 626 and management functions to become inoperative. 628 54 MPLS-TP MUST support a flexible bandwidth allocation scheme. 629 This will provide carriers with the capability to efficiently 630 support service demands over the MPLS-TP network. 632 [Should we refer here to the requirements specified in RFC 2702?] 634 2.10. Security requirements 636 For a description of the security threats relevant in the context of 637 MPLS and GMPLS and the defensive techniques to combat those threats 638 see the Security Framework for MPLS & GMPLS Networks 639 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]. 641 3. IANA Considerations 643 This document makes no request of IANA. 645 Note to RFC Editor: this section may be removed on publication as an 646 RFC. 648 4. Security Considerations 650 For a description of the security threats relevant in the context of 651 MPLS and GMPLS and the defensive techniques to combat those threats 652 see the Security Framework for MPLS & GMPLS Networks 653 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]. 655 5. Acknowledgements 657 The authors would like to thank all members of the teams (the Joint 658 Working Team, the MPLS Interoperability Design Team in IETF and the 659 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 660 specification of MPLS Transport Profile. 662 The authors would also like to thank Loa Andersson, Italo Busi, John 663 Drake, Neil Harrison, Wataru Imajuku, Julien Meuric, Tom Nadeau, 664 Hiroshi Ohta, Tomonori Takeda and Satoshi Ueno for their comments and 665 enhancements to the text. 667 6. Informative References 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, March 1997. 672 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 673 Label Switching Architecture", RFC 3031, January 2001. 675 [RFC3473] Berger, L., "Multiprotocol Label Switching Architecture", 676 RFC 3473, January 2003. 678 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 679 Edge (PWE3) Architecture", RFC 3985, March 2005. 681 [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L. 682 Ong, "Requirements for Generalized MPLS (GMPLS) Signaling 683 Usage and Extensions for Automatically Switched Optical 684 Network (ASON)", RFC 4139, July 2005. 686 [RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol 687 Label Switching (GMPLS) Routing for the Automatically 688 Switched Optical Network (ASON)", RFC 4258, November 2005. 690 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 691 Restoration) Terminology for Generalized Multi-Protocol 692 Label Switching (GMPLS)", RFC 4427, March 2006. 694 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 695 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 696 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 697 July 2008. 699 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 700 Label Assignment and Context-Specific Label Space", 701 RFC 5331, August 2008. 703 [I-D.gray-mpls-tp-nm-req] 704 Lam, H., Mansfield, S., and E. Gray, "MPLS TP Network 705 Management Requirements", draft-gray-mpls-tp-nm-req-01 706 (work in progress), July 2008. 708 [I-D.vigoureux-mpls-tp-oam-requirements] 709 Vigoureux, M., Ward, D., and M. Betts, "Requirements for 710 OAM in MPLS Transport Networks", 711 draft-vigoureux-mpls-tp-oam-requirements-00 (work in 712 progress), July 2008. 714 [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework] 715 Fang, L. and M. Behringer, "Security Framework for MPLS 716 and GMPLS Networks", 717 draft-ietf-mpls-mpls-and-gmpls-security-framework-03 (work 718 in progress), July 2008. 720 [ITU.Y2611.2006] 721 International Telecommunications Union, "High-level 722 architecture of future packet-based networks", ITU- 723 T Recommendation Y.2611, December 2006. 725 [ITU.Y1401.2008] 726 International Telecommunications Union, "Principles of 727 interworking", ITU-T Recommendation Y.1401, February 2008. 729 [ITU.G805.2000] 730 International Telecommunications Union, "Generic 731 functional architecture of transport networks", ITU- 732 T Recommendation G.805, March 2000. 734 Authors' Addresses 736 Ben Niven-Jenkins (editor) 737 BT 738 208 Callisto House, Adastral Park 739 Ipswich, Suffolk IP5 3RE 740 UK 742 Email: benjamin.niven-jenkins@bt.com 744 Deborah Brungard (editor) 745 AT&T 746 Rm. D1-3C22 - 200 S. Laurel Ave. 747 Middletown, NJ 07748 748 USA 750 Email: dbrungard@att.com 752 Malcolm Betts (editor) 753 Nortel Networks 754 3500 Carling Avenue 755 Ottawa, Ontario K2H 8E9 756 Canada 758 Email: betts01@nortel.com 760 Nurit Sprecher 761 Nokia Siemens Networks 762 3 Hanagar St. Neve Ne'eman B 763 Hod Hasharon, 45241 764 Israel 766 Email: nurit.sprecher@nsn.com 768 Full Copyright Statement 770 Copyright (C) The IETF Trust (2008). 772 This document is subject to the rights, licenses and restrictions 773 contained in BCP 78, and except as set forth therein, the authors 774 retain all their rights. 776 This document and the information contained herein are provided on an 777 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 778 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 779 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 780 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 781 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 782 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 784 Intellectual Property 786 The IETF takes no position regarding the validity or scope of any 787 Intellectual Property Rights or other rights that might be claimed to 788 pertain to the implementation or use of the technology described in 789 this document or the extent to which any license under such rights 790 might or might not be available; nor does it represent that it has 791 made any independent effort to identify any such rights. Information 792 on the procedures with respect to rights in RFC documents can be 793 found in BCP 78 and BCP 79. 795 Copies of IPR disclosures made to the IETF Secretariat and any 796 assurances of licenses to be made available, or the result of an 797 attempt made to obtain a general license or permission for the use of 798 such proprietary rights by implementers or users of this 799 specification can be obtained from the IETF on-line IPR repository at 800 http://www.ietf.org/ipr. 802 The IETF invites any interested party to bring to its attention any 803 copyrights, patents or patent applications, or other proprietary 804 rights that may cover technology that may be required to implement 805 this standard. Please address the information to the IETF at 806 ietf-ipr@ietf.org.