idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 25, 2014) is 3685 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Takacs 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. Fedyk 5 Expires: August 29, 2014 Hewlett-Packard Company 6 J. He 7 Huawei 8 February 25, 2014 10 GMPLS RSVP-TE extensions for OAM Configuration 11 draft-ietf-ccamp-oam-configuration-fwk-13 13 Abstract 15 Operations, Administration and Maintenance (OAM) is an integral part 16 of transport connections, hence it is required that OAM functions are 17 activated/deactivated in sync with connection commissioning/ 18 decommissioning; avoiding spurious alarms and ensuring consistent 19 operation. In certain technologies, OAM entities are inherently 20 established once the connection is set up, while other technologies 21 require extra configuration to establish and configure OAM entities. 22 This document specifies extensions to RSVP-TE to support the 23 establishment and configuration of OAM entities along with Label 24 Switched Path signaling. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 29, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6 69 3.1. Establishment of OAM Entities and Functions . . . . . . . 8 70 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . 9 71 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10 72 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . 11 73 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 11 74 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12 75 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . 14 76 4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . 14 77 4.3. Administrative Status Information . . . . . . . . . . . . 15 78 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15 79 4.5. Considerations on Point-to-Multipoint OAM Configuration . 16 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 17 82 5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 17 83 5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 18 84 5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 18 85 5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 19 86 5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 19 87 5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 19 88 5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 20 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 93 8.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 GMPLS is designed as an out-of-band control plane supporting dynamic 99 connection provisioning for any suitable data plane technology; 100 including spatial switching (e.g., incoming port or fiber to outgoing 101 port or fiber), wavelength-division multiplexing (e.g., Dense 102 Wavelength Division Multiplexing (DWDM)), time-division multiplexing 103 (e.g., SONET/SDH, G.709), and Ethernet Provider Backbone Bridging - 104 Traffic Engineering (PBB-TE) and MPLS. In most of these 105 technologies, there are Operations, Administration and Maintenance 106 (OAM) functions employed to monitor the health and performance of the 107 connections and to trigger data plane (DP) recovery mechanisms. 108 Similar to connection provisioning, OAM functions follow general 109 principles, but also have some technology specific characteristics. 111 OAM is an integral part of transport connections. Therefore it is 112 required that OAM functions are activated/deactivated in sync with 113 connection commissioning/decommissioning; avoiding spurious alarms 114 and ensuring consistent operation. In certain technologies, OAM 115 entities are inherently established once the connection is set up, 116 while other technologies require extra configuration to establish and 117 configure OAM entities. In some situations the use of OAM functions, 118 such as Fault Management (FM) and Performance Management (PM), may be 119 optional (based on network management policies). Hence, the network 120 operator must be able to choose which set of OAM functions to apply 121 to specific connections and which parameters should be configured and 122 activated. To achieve this objective, OAM entities and specific 123 functions must be selectively configurable. 125 In general, it is required that the management plane and control 126 plane connection establishment mechanisms are synchronized with OAM 127 establishment and activation. In particular, if the GMPLS control 128 plane is employed, it is desirable to bind OAM setup and 129 configuration to connection establishment signaling to avoid two 130 separate management/configuration steps (connection setup followed by 131 OAM configuration) which increases delay, processing, and more 132 importantly may be prone to misconfiguration errors. Once OAM 133 entities are setup and configured, pro-active as well as on-demand 134 OAM functions can be activated via the management plane. On the 135 other hand, it should be possible to activate/deactivate pro-active 136 OAM functions via the GMPLS control plane as well. In some 137 situations it may be possible to use the GMPLS control plane to 138 control on-demand OAM functions too. 140 This document describes requirements for OAM configuration and 141 control via Resource Reservation Protocol - Traffic Engineering 142 (RSVP-TE). Extensions to the RSVP-TE protocol are specified 143 providing a framework to configure and control OAM entities along 144 with the capability to carry technology specific information. 145 Extensions can be grouped into: generic elements that are applicable 146 to any OAM solution; and technology specific elements that provide 147 additional configuration parameters, which may only be needed for a 148 specific OAM technology. This document specifies the technology 149 agnostic elements and specifies the way additional technology 150 specific OAM parameters are provided. 152 This document addresses end-to-end OAM configuration, that is, the 153 setup of OAM entities bound to an end-to-end Label-Switched Path 154 (LSP), and configuration and control of OAM functions running end-to- 155 end in the LSP. Configuration of OAM entities for LSP segments and 156 tandem connections are out of the scope of this document. 158 The mechanisms described in this document provide an additional 159 option for bootstrapping OAM that is not intended to replace or 160 deprecate the use of other technology specific OAM bootstrapping 161 techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The 162 procedures specified in this document are intended only for use in 163 environments where RSVP-TE signaling is used to set up the LSPs that 164 are to be monitored using OAM. 166 2. Requirements 168 This section summarizes various technology-specific OAM requirements 169 which can be used as a basis for an OAM configuration framework. 171 MPLS OAM requirements are described in [RFC4377], which provides 172 requirements to create consistent OAM functionality for MPLS 173 networks. The following list is an excerpt of MPLS OAM requirements 174 documented in [RFC4377] that bear a direct relevance to the 175 discussion set forth in this document. 177 o It is desired to support the automation of LSP defect detection. 178 It is especially important in cases where large numbers of LSPs 179 might be tested. 181 o In particular some LSPs may require automated ingress-LSR to 182 egress-LSR testing functionality, while others may not. 184 o Mechanisms are required to coordinate network responses to 185 defects. Such mechanisms may include alarm suppression, 186 translating defect signals at technology boundaries, and 187 synchronizing defect detection times by setting appropriately 188 bounded detection time frames. 190 MPLS-TP defines a profile of MPLS targeted at transport applications 191 [RFC5921]. This profile specifies the specific MPLS characteristics 192 and extensions required to meet transport requirements, including 193 providing additional OAM, survivability, and other maintenance 194 functions not currently supported by MPLS. Specific OAM requirements 195 for MPLS-TP are specified in [RFC5654] and [RFC5860]. MPLS-TP poses 196 the following requirements on the control plane to configure and 197 control OAM entities: 199 o From [RFC5860]: OAM functions MUST operate and be configurable 200 even in the absence of a control plane. Conversely, it SHOULD be 201 possible to configure as well as enable/disable the capability to 202 operate OAM functions as part of connectivity management, and it 203 SHOULD also be possible to configure as well as enable/disable the 204 capability to operate OAM functions after connectivity has been 205 established. 207 o From [RFC5654]: The MPLS-TP control plane MUST support the 208 configuration and modification of OAM maintenance points as well 209 as the activation/ deactivation of OAM when the transport path or 210 transport service is established or modified. 212 Ethernet Connectivity Fault Management (CFM) defines an adjunct 213 connectivity monitoring OAM flow to check the liveliness of Ethernet 214 networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011] Ethernet 215 networks support explicitly-routed Ethernet connections. CFM can be 216 used to track the liveliness of PBB-TE connections and detect data 217 plane failures. In the IETF, the GMPLS controlled Ethernet Label 218 Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the 219 GMPLS control plane to support the establishment of PBB-TE data plane 220 connections. Without control plane support separate management 221 commands would be needed to configure and start CFM. 223 GMPLS based OAM configuration and control needs to provide a general 224 framework to be applicable to a wide range of data plane technologies 225 and OAM solutions. There are three typical data plane technologies 226 used for transport applications: wavelength based such as Wavelength 227 Switched Optical Networks (WSON), Time-Division Multiplexing (TDM) 228 based such as Synchronous Digital Hierarchy (SDH) and Synchronous 229 Optical Networking (SONET), and packet based such as MPLS-TP 230 [RFC5921] and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data 231 planes, the operator MUST be able to configure and control the 232 following OAM functions: 234 o It MUST be possible to explicitly request the setup of OAM 235 entities for the signaled LSP and provide specific information for 236 the setup if this is required by the technology. 238 o Control of alarms is important to avoid false alarm indications 239 and reporting to the management system. It MUST be possible to 240 enable/disable alarms generated by OAM functions. In some cases, 241 selective alarm control may be desirable when, for instance, the 242 operator is only concerned about critical alarms. Therefore the 243 non-service affecting alarms should be inhibited. 245 o When periodic messages are used for liveliness check (continuity 246 check) of LSPs, it MUST be possible to set the frequency of 247 messages. This allows proper configuration for fulfilling the 248 requirements of the service and/or meeting the detection time 249 boundaries posed by possible congruent connectivity check 250 operations of higher layer applications. For a network operator 251 to be able to balance the trade-off between fast failure detection 252 and data overhead, it is beneficial to configure the frequency of 253 continuity check messages on a per LSP basis. 255 o Pro-active Performance Monitoring (PM) functions are used to 256 continuously collect information about specific characteristics of 257 the connection. For consistent measurement of Service Level 258 Agreements (SLAs), it MUST be possible to set common configuration 259 parameters for the LSP. 261 o The extensions MUST allow the operator to use only a minimal set 262 of OAM configuration and control features if supported by the OAM 263 solution or network management policy. Generic OAM parameters and 264 data plane or OAM technology specific parameters MUST be 265 supported. 267 3. RSVP-TE based OAM Configuration 269 In general, two types of maintenance points can be distinguished: 270 Maintenance Entity Group End Points (MEPs) and Maintenance Entity 271 Group Intermediate Points (MIPs). MEPs reside at the ends of an LSP 272 and are capable of initiating and terminating OAM messages for Fault 273 Management (FM) and Performance Monitoring (PM). MIPs on the other 274 hand, are located at transit nodes of an LSP and are capable of 275 reacting to some OAM messages but otherwise do not initiate messages. 276 Maintenance Entity (ME) refers to an association of MEPs and MIPs 277 that are provisioned to monitor an LSP. 279 When an LSP is signaled, a forwarding association is established 280 between endpoints and transit nodes via label bindings. This 281 association creates a context for the OAM entities monitoring the 282 LSP. On top of this association, OAM entities may be configured to 283 unambiguously identify MEs. 285 In addition to ME identification parameters, pro-active OAM functions 286 (e.g., Continuity Check (CC) and Performance Monitoring (PM)) may 287 have additional parameters that require configuration as well. In 288 particular, the frequency of periodic CC packets and the measurement 289 interval for loss and delay measurements may need to be configured. 291 The above parameters may be either derived from LSP provisioning 292 information, or alternatively, pre-configured default values can be 293 used. In the simplest case, the control plane MAY provide 294 information on whether or not OAM entities need to be setup for the 295 signaled LSP. If OAM entities are created, control plane signaling 296 MUST also provide a means to activate/deactivate OAM message flows 297 and associated alarms. 299 OAM identifiers, as well as the configuration of OAM functions, are 300 technology specific (i.e., vary depending on the data plane 301 technology and the chosen OAM solution). In addition, for any given 302 data plane technology, a set of OAM solutions may be applicable. 303 Therefore, the OAM configuration framework allows selecting a 304 specific OAM solution to be used for the signaled LSP and provides 305 means to carry detailed OAM configuration information in technology 306 specific TLVs. 308 Administrative Status Information is carried in the ADMIN_STATUS 309 Object. The Administrative Status Information is described in 310 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 311 [RFC3473]. Two bits are allocated for the administrative control of 312 OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" 313 (O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms 314 MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled. 315 When the "OAM Alarms Enabled" bit is set OAM triggered alarms are 316 enabled and associated consequent actions MUST be executed including 317 the notification to the management system. When this bit is cleared, 318 alarms are suppressed and no action SHOULD be executed and the 319 management system SHOULD NOT be notified. 321 The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES objects are 322 defined in [RFC5420] to provide means to signal LSP attributes and 323 options in the form of TLVs. Options and attributes signaled in the 324 LSP_ATTRIBUTES object can be passed transparently through LSRs not 325 supporting a particular option or attribute, while the contents of 326 the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by 327 each LSR. One bit "OAM MEP entities desired" is allocated in the LSP 328 Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. If the 329 "OAM MEP entities desired" bit is set it is indicating that the 330 establishment of OAM MEP entities are required at the endpoints of 331 the signaled LSP. One bit "OAM MIP entities desired" is allocated in 332 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or 333 LSP_REQUIRED_ATTRIBUES objects. If the "OAM MIP entities desired" 334 bit is set in the LSP_ATTRIBUTES Flags TLV in the 335 LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the 336 establishment of OAM MIP entities is required at every transit node 337 of the signaled LSP. 339 3.1. Establishment of OAM Entities and Functions 341 In order to avoid spurious alarms, OAM functions should be setup and 342 enabled in the appropriate order. When using the GMPLS control plane 343 for both LSP establishment and to enable OAM functions on the LSPs, 344 the control of both processes is bound to RSVP-TE message exchanges. 346 An LSP may be signaled and established without OAM configuration 347 first, and OAM entities may be added later with a subsequent re- 348 signaling of the LSP. Alternatively, the LSP may be setup with OAM 349 entities with the first signaling of the LSP. The below procedures 350 apply to both cases. 352 Before initiating a Path message with OAM Configuration information, 353 an initiating node MUST establish and configure the corresponding OAM 354 entities locally. But until the LSP is established, OAM source 355 functions MUST NOT start sending any OAM messages. In the case of 356 bidirectional connections, in addition to the OAM source function, 357 the initiator node MUST set up the OAM sink function and prepare it 358 to receive OAM messages. During this time the OAM alarms MUST be 359 suppressed (e.g., due to missing or unidentified OAM messages). To 360 achieve OAM alarm suppression, Path message MUST be sent with the 361 "OAM Alarms Enabled" ADMIN_STATUS flag cleared. 363 When the Path message arrives at the receiver, the remote end MUST 364 establish and configure OAM entities according to the OAM information 365 provided in the Path message. If this is not possible, a PathErr 366 message SHOULD be sent and neither the OAM entities nor the LSP 367 SHOULD be established. If OAM entities are established successfully, 368 the OAM sink function MUST be prepared to receive OAM messages, but 369 MUST NOT generate any OAM alarms (e.g., due to missing or 370 unidentified OAM messages). In the case of bidirectional 371 connections, in addition to the OAM sink function, an OAM source 372 function MUST be set up and, according to the requested 373 configuration, the OAM source function MUST start sending OAM 374 messages. Then a Resv message MUST be sent back, including the 375 LSP_Attributes Flags TLV, with the appropriate setting of the "OAM 376 MEP entities desired" and "OAM MIP entities desired" flags, and the 377 OAM Configuration TLV that corresponds to the established and 378 configured OAM entities and functions. Depending on the OAM 379 technology, some elements of the OAM Configuration TLV MAY be updated 380 /changed; i.e., if the remote end is not supporting a certain OAM 381 configuration it may suggest an alternative setting, which may or may 382 not be accepted by the initiator of the Path message. If it is 383 accepted, the initiator will reconfigure its OAM functions according 384 to the information received in the Resv message. If the alternate 385 setting is not acceptable a ResvErr message MAY be sent tearing down 386 the LSP. Details of this operation are technology specific and 387 should be described in accompanying technology specific documents. 389 When the initiating side receives the Resv message, it completes any 390 pending OAM configuration and enables the OAM source function to send 391 OAM messages. 393 After this exchange, OAM entities are established and configured for 394 the LSP and OAM messages are exchanged. OAM alarms can now be 395 enabled. The initiator, during the period when OAM alarms are 396 disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS 397 flag set. The receiving node enables the OAM alarms after processing 398 the Path message. The initiator enables OAM alarms after it receives 399 the Resv message. Data plane OAM is now fully functional. 401 In case an egress LSR does not support the extensions defined in this 402 document, according to [RFC5420], it will silently ignore the new LSP 403 Attributes Flags as well as the TLVs carrying additional OAM 404 configuration information, and therefore no error will be raised that 405 would notify the ingress LSR about the missing OAM configuration 406 actions on the egress side. However, as described above, an egress 407 LSR conformant to the specification of this document will set the LSP 408 Attributes Flags and include the OAM Configuration TLV in the Resv 409 message indicating the configuration of the OAM mechanisms, therefore 410 an ingress LSR by detecting the missing information in the Resv 411 message will be able to recognize that the remote end does not 412 support the OAM configuration functionality and therefore it SHOULD 413 tear down the LSP, and if appropriate, signal the LSP without any OAM 414 configuration information. 416 3.2. Adjustment of OAM Parameters 418 There may be a need to change the parameters of an already 419 established and configured OAM function during the lifetime of the 420 LSP. To do so the LSP needs to be re-signaled with the updated 421 parameters. OAM parameters influence the content and timing of OAM 422 messages and identify the way OAM defects and alarms are derived and 423 generated. Hence, to avoid spurious alarms, it is important that 424 both sides, OAM sink and source, are updated in a synchronized way. 425 First, the alarms of the OAM sink function should be suppressed and 426 only then should expected OAM parameters be adjusted. Subsequently, 427 the parameters of the OAM source function can be updated. Finally, 428 the alarms of the OAM sink side can be enabled again. 430 In accordance with the above operation, the LSP MUST first be re- 431 signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared, 432 including the updated OAM Configuration TLV corresponding to the new 433 parameter settings. The initiator MUST keep its OAM sink and source 434 functions running unmodified, but it MUST suppress OAM alarms after 435 the updated Path message is sent. The receiver MUST first disable 436 all OAM alarms, then update the OAM parameters according to the 437 information in the Path message and reply with a Resv message 438 acknowledging the changes by including the OAM Configuration TLV. 439 Note that the receiving side has the possibility to adjust the 440 requested OAM configuration parameters and reply with an updated OAM 441 Configuration TLV in the Resv message, reflecting the actually 442 configured values. However, in order to avoid an extensive 443 negotiation phase, in the case of adjusting already configured OAM 444 functions, the receiving side SHOULD NOT update the parameters 445 requested in the Path message to an extent that would provide lower 446 performance (e.g., lower frequency of monitoring packets) than what 447 has been in operation previously. 449 The initiator MUST only update its OAM sink and source functions 450 after it received the Resv message. After this Path/Resv message 451 exchange (in both unidirectional and bidirectional LSP cases) the OAM 452 parameters are updated and OAM is running according the new parameter 453 settings. However, OAM alarms are still disabled. A subsequent Path 454 /Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag 455 set is needed to enable OAM alarms again. 457 3.3. Deleting OAM Entities 459 In some cases it may be useful to remove some or all OAM entities and 460 functions from an LSP without actually tearing down the connection. 462 To avoid any spurious alarms, first the LSP MUST be re-signaled with 463 "OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM 464 configuration. Subsequently, the LSP is re-signaled with "OAM MEP 465 Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags 466 cleared, and without the OAM Configuration TLV, this MUST result in 467 the deletion of all OAM entities associated with the LSP. All 468 control and data plane resources in use by the OAM entities and 469 functions SHOULD be freed up. Alternatively, if only some OAM 470 functions need to be removed, the LSP is re-signaled with the updated 471 OAM Configuration TLV. Changes between the contents of the 472 previously signaled OAM Configuration TLV and the currently received 473 TLV represent which functions MUST be removed/added. 475 OAM source functions MUST be deleted first and only after the "OAM 476 Alarms Disabled" can the associated OAM sink functions be removed, 477 this will ensure that OAM messages do not leak outside the LSP. To 478 this end the initiator, before sending the Path message, MUST remove 479 the OAM source, hence terminating the OAM message flow associated to 480 the downstream direction. In the case of a bidirectional connection, 481 it MUST leave in place the OAM sink functions associated to the 482 upstream direction. The remote end, after receiving the Path 483 message, MUST remove all associated OAM entities and functions and 484 reply with a Resv message without an OAM Configuration TLV. The 485 initiator completely removes OAM entities and functions after the 486 Resv message arrived. 488 4. RSVP-TE Extensions 490 RFC Editor Note: remove/update "IANA" and "IANA to assign" notes in 491 the document once the assignments have been made. 493 4.1. LSP Attributes Flags 495 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 496 indicate options and attributes of the LSP. The Flags field has 8 497 bits and hence is limited to differentiate only 8 options. [RFC5420] 498 defines new objects for RSVP-TE messages to allow the signaling of 499 arbitrary attribute parameters making RSVP-TE easily extensible to 500 support new applications. Furthermore, [RFC5420] allows options and 501 attributes that do not need to be acted on by all Label Switched 502 Routers (LSRs) along the path of the LSP. In particular, these 503 options and attributes may apply only to key LSRs on the path such as 504 the ingress LSR and egress LSR. Options and attributes can be 505 signaled transparently, and only examined at those points that need 506 to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES 507 objects are defined in [RFC5420] to provide means to signal LSP 508 attributes and options in the form of TLVs. Options and attributes 509 signaled in the LSP_ATTRIBUTES object can be passed transparently 510 through LSRs not supporting a particular option or attribute, while 511 the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined 512 and processed by each LSR. One TLV is defined in [RFC5420]: the 513 Attributes Flags TLV. 515 One bit (IANA to assign): "OAM MEP entities desired" is allocated in 516 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. 517 If the "OAM MEP entities desired" bit is set it is indicating that 518 the establishment of OAM MEP entities are required at the endpoints 519 of the signaled LSP. If the establishment of MEPs is not supported 520 an error MUST be generated: "OAM Problem/MEP establishment not 521 supported". 523 If the "OAM MEP entities desired" bit is set and additional 524 parameters need to be configured, an OAM Configuration TLV MAY be 525 included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. 527 One bit (IANA to assign): "OAM MIP entities desired" is allocated in 528 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or 529 LSP_REQUIRED_ATTRIBUES objects. If the "OAM MEP entities desired" 530 bit is not set then this bit MUST NOT be set. If the "OAM MIP 531 entities desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the 532 LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the 533 establishment of OAM MIP entities is required at every transit node 534 of the signaled LSP. If the establishment of a MIP is not supported 535 an error MUST be generated: "OAM Problem/MIP establishment not 536 supported". If an intermediate LSR does not support the extensions 537 defined in this document it will not recognize the "OAM MIP entities 538 desired" flag and although the LSP_REQUIRED_ATTRIBUTES object was 539 used it will not configure MIP entities and will not raise any 540 errors. If LSRs that are not supporting this document are to be 541 assumed in the network, the ingress LSR SHOULD collect per-hop 542 information about the LSP Attributes utilizing the LSP Attributes 543 sub-object of the Record Route Object as defined in [RFC5420]. When 544 the Record Route object is received the ingress SHOULD check whether 545 all intermediate LSRs set the "OAM MIP entities desired" flag 546 indicating support of the function, if not, depending on operator 547 policy the LSP MAY need to be torn down. 549 4.2. OAM Configuration TLV 551 This TLV provides information about which OAM technology/method 552 should be used and carries sub-TLVs for any additional OAM 553 configuration information. One OAM Configuration TLV MAY be carried 554 in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and 555 Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, 556 it is indicating that intermediate nodes MUST recognize and react on 557 the OAM configuration information. 559 0 1 2 3 560 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type (IANA) | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | OAM Type | Reserved | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | | 567 ~ sub-TLVs ~ 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Type: indicates a new type: the OAM Configuration TLV (IANA to 572 assign). 574 OAM Type: specifies the technology specific OAM method. When carried 575 in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is 576 not supported at any given node an error MUST be generated: "OAM 577 Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES 578 Object, intermediate nodes not supporting the OAM Type pass the 579 object forward unchanged as specified in [RFC5420]. Ingress and 580 egress nodes that support the OAM Configuration TLV but that do not 581 support a specific OAM Type MUST respond with an error indicating 582 "OAM Problem/Unsupported OAM Type". 584 OAM Type Description 585 ------------ -------------------- 586 0-255 Reserved 588 This document defines no types. IANA is requested to maintain the 589 values in a new "RSVP-TE OAM Configuration Registry". 591 Length: indicates the total length of the TLV in octets. The TLV 592 MUST be zero-padded so that the TLV is four octet aligned. 594 Two groups of TLVs are defined: generic sub-TLVs and technology 595 specific sub-TLVs. Generic sub-TLVs carry information that are 596 applicable independent of the actual OAM technology, while technology 597 specific sub-TLVs are providing configuration parameters for specific 598 OAM technologies. This document defines one generic sub-TLV, see 599 Section 4.2.1, while it is foreseen that technology specific sub-TLVs 600 will be defined by separate documents. 602 The receiving node, based on the OAM Type, will check if a 603 corresponding technology specific OAM configuration sub-TLV is 604 included in the OAM Configuration TLV. If the included technology 605 specific OAM configuration sub-TLV is different from what is 606 specified in the OAM Type an error MUST be generated: "OAM Problem/ 607 OAM Type Mismatch". IANA is requested to maintain the sub-TLV space 608 in the new "RSVP-TE OAM Configuration Registry". 610 Sub-TLV Type Description 611 ------------ ------------------------------------ 612 0 Reserved 613 1 OAM Function Flags Sub-TLV 614 2-31 Reserved for generic Sub-TLVs 615 32- Reserved for technology specific Sub-TLVs 617 Note that there is a hierarchical dependency between the OAM 618 configuration elements. First, the "OAM MEP entities desired" flag 619 needs to be set. Only when that flag is set MAY an "OAM 620 Configuration TLV" be included in the LSP_ATTRIBUTES or 621 LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on 622 the "OAM Type" field, it MAY carry a technology specific OAM 623 configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP 624 entities desired" flag is not set but an OAM Configuration TLV is 625 present) an error MUST be generated: "OAM Problem/Configuration 626 Error". 628 4.2.1. OAM Function Flags Sub-TLV 630 The "OAM Configuration TLV" MUST always include a single instance of 631 the "OAM Function Flags Sub-TLV" and it MUST always be the first sub- 632 TLV. "OAM Function Flags" specifies which pro-active OAM functions 633 (e.g., connectivity monitoring, loss and delay measurement) and which 634 fault management signals MUST be established and configured. If the 635 selected OAM Function(s) is(are) not supported, an error MUST be 636 generated: "OAM Problem/Unsupported OAM Function". 638 0 1 2 3 639 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Type (1) (IANA) | Length | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | | 644 ~ OAM Function Flags ~ 645 | | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 OAM Function Flags is bitmap with extensible length based on the 649 Length field of the TLV. Bits are numbered from left to right. The 650 TLV is padded to 4-octet alignment. The Length field indicates the 651 size of the padded TLV in octets. IANA is requested to maintain the 652 OAM Function Flags in the new "RSVP-TE OAM Configuration Registry". 653 This document defines the following flags. 655 OAM Function Flag bit# Description 656 --------------------- --------------------------- 657 0 Continuity Check (CC) 658 1 Connectivity Verification (CV) 659 2 Fault Management Signal (FMS) 660 3 Performance Monitoring/Loss (PM/Loss) 661 4 Performance Monitoring/Delay (PM/Delay) 662 5 Performance Monitoring/Throughput Measurement 663 (PM/Throughput) 665 4.2.2. Technology Specific Sub-TLVs 667 If technology-specific configuration information is needed for a 668 specific "OAM Type", then this information is carried in a 669 technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM 670 Configuration TLV MUST NOT contain more than one technology- specific 671 sub-TLV. IANA is requested to maintain the OAM technology specific 672 sub-TLV space in the new "RSVP-TE OAM Configuration Registry". 674 4.3. Administrative Status Information 676 Administrative Status Information is carried in the ADMIN_STATUS 677 Object, which is specified for RSVP-TE in [RFC3473]. The 678 Administrative Status Information is described in [RFC3471]. 680 Two bits are allocated for the administrative control of OAM 681 monitoring. Two bits (IANA to assign) are allocated by this 682 document: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) 683 bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST 684 be enabled; if it is cleared, OAM mechanisms MUST be disabled. When 685 the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled 686 and associated consequent actions MUST be executed including the 687 notification to the management system. When this bit is cleared, 688 alarms are suppressed and no action SHOULD be executed and the 689 management system SHOULD NOT be notified. For a detailed description 690 of the use of these flags see Section 3. 692 4.4. Handling OAM Configuration Errors 694 To handle OAM configuration errors, a new Error Code (IANA to assign) 695 "OAM Problem" is introduced. To refer to specific problems, a set of 696 Error Values are defined under the "OAM Problem" error code. 698 If a node does not support the establishment of OAM MEP or MIP 699 entities it MUST use the error value: "MEP establishment not 700 supported" or "MIP establishment not supported" respectively in the 701 PathErr message. 703 If a node does not support a specific OAM technology/solution it MUST 704 use the error value: "Unsupported OAM Type" in the PathErr message. 706 If a different technology specific OAM configuration TLV is included 707 than what was specified in the OAM Type an error MUST be generated 708 with error value: "OAM Type Mismatch" in the PathErr message. 710 There is a hierarchy between the OAM configuration elements. If this 711 hierarchy is broken, the error value: "Configuration Error" MUST be 712 used in the PathErr message. 714 If a node does not support a specific OAM Function, it MUST use the 715 error value: "Unsupported OAM Function" in the PathErr message. 717 4.5. Considerations on Point-to-Multipoint OAM Configuration 719 RSVP-TE extensions for the establishment of point-to-multipoint 720 (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of 721 multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set 722 up between the ingress and egress LSRs, and are appropriately 723 combined by the branch LSRs using RSVP semantics to result in a P2MP 724 TE LSP. One Path message may signal one or multiple S2L sub-LSPs for 725 a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP 726 can be signaled using one Path message or split across multiple Path 727 messages. 729 P2MP OAM mechanisms are very specific to the data plane technology, 730 therefore in this document, we only highlight the basic principles of 731 P2MP OAM configuration. We consider only the root to leaf OAM flows, 732 and as such, aspects of the configuration of return paths are outside 733 the scope of our discussions. We also limit our consideration to the 734 case where all leaves must successfully establish OAM entities with 735 identical configuration in order the P2MP OAM is successfully 736 established. In any case, the discussion set forth below provides 737 only guidelines for P2MP OAM configuration. However at minimum the 738 below procedures SHOULD be specified for P2MP OAM configuration in a 739 technology specific document. 741 The root node may use a single Path message or multiple Path messages 742 to setup the whole P2MP tree. In the case when multiple Path 743 messages are used, the root node is responsible to keep the OAM 744 Configuration information consistent in each of the sent Path 745 messages, i.e., the same information MUST be included in all Path 746 messages used to construct the multicast tree. Each branching node 747 will propagate the Path message downstream on each of the branches, 748 when constructing a Path message the OAM Configuration information 749 MUST be copied unchanged from the received Path message, including 750 the related ADMIN_STATUS bits, LSP Attribute Flags and the OAM 751 Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES 752 and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for the upstream 753 Path message to the subsequent downstream Path messages. 755 Leaves MUST create and configure OAM sink functions according to the 756 parameters received in the Path message, for P2MP OAM configuration 757 there is no possibility for parameter negotiation on a per leaf 758 basis. This is due to the fact that the OAM source function, 759 residing in the root of the tree, will operate with a single 760 configuration, which then must be obeyed by all leaves. If a leaf 761 cannot accept the OAM parameters it MUST use the RRO Attributes sub- 762 object [RFC5420] to notify the root about the problem. In 763 particular, if the OAM configuration was successful, the leaf would 764 set the "OAM MEP entities desired" flag in the RRO Attributes sub- 765 object in the Resv message. On the other hand, if OAM entities could 766 not be established the Resv message should be sent with the "OAM MEP 767 entities desired" bit cleared in the RRO Attributes sub-object. 768 Branching nodes should collect and merge the received RROs according 769 to the procedures described in [RFC4875]. This way, the root when 770 receiving the Resv message (or messages if multiple Path messages 771 were used to set up the tree) will have a clear information about 772 which of the leaves could establish the OAM functions. If all leaves 773 established OAM entities successfully, the root can enable the OAM 774 message flow. On the other hand, if at some leaves the establishment 775 was unsuccessful additional actions will be needed before the OAM 776 message flow can be enabled. Such action could be to setup two 777 independent P2MP LSPs. One LSP with OAM Configuration information 778 towards leaves which could successfully setup the OAM function. This 779 can be done by pruning the leaves which failed to setup OAM of the 780 previously signaled P2MP LSP. The other P2MP LSP could be 781 constructed for leaves without OAM entities. The exact procedures 782 will be described in technology specific documents. 784 5. IANA Considerations 786 5.1. ADMIN_STATUS Object Bit Flags 788 IANA maintains a registry called "Generalized Multi-Protocol Label 789 Switching (GMPLS) Signaling Parameters" with a sub-registry called 790 "Administrative Status Information Flags". 792 IANA is requested to allocate two new flags as follows: 794 Bit Number | Hex Value | Name | Reference 795 -----------+------------+--------------------------+----------- 796 TBA | TBA | OAM Alarms Enabled (O) | [This.ID] 797 TBA | TBA | OAM Flows Enabled (M) | [This.ID] 799 5.2. LSP Attributes Flags 801 IANA maintains a registry called "Resource Reservation Protocol- 802 Traffic Engineering (RSVP-TE) Parameters" with a subregistry called 803 "Attribute Flags". 805 IANA is requested to allocate two new flags as follows: 807 Bit | Name | Attribute | Attribute | RRO | Reference 808 No | | Flags Path | Flags Resv | | 809 ----+------------------+------------+------------+-----+---------- 810 TBA | OAM MEP | | | | 811 | entities desired | Yes | Yes | Yes | [This.ID] 812 | | | | | 813 TBA | OAM MIP | | | | 814 | entities desired | Yes | Yes | Yes | [This.ID] 816 5.3. New LSP Attributes 818 IANA maintains a registry called "Resource Reservation Protocol- 819 Traffic Engineering (RSVP-TE) Parameters" with a subregistry called 820 "Attributes TLV Space" 822 IANA is requested to allocate one new TLV type as follows: 824 Type| Name |Allowed on |Allowed on |Reference 825 | |LSP_ATTRIBUTES|LSP_REQUIRED_| 826 | | |ATTRIBUTES | 827 ----+----------------------+--------------+-------------+--------- 828 TBA| OAM Configuration TLV| Yes | Yes |[This.ID] 830 5.4. RSVP Error Code 832 IANA maintains a registry called "Resource Reservation Protocol 833 (RSVP) Parameters" with a subregistry called "Error Codes and 834 Globally-Defined Error Value Sub-Codes". 836 IANA is requested to allocate one new Error Code as follows: 838 Error Code | Meaning | Reference 839 -----------+-------------+------------- 840 TBA | OAM Problem | [This.ID] 842 The value is to be selected from the range 0-239. 844 The following Error Value sub-codes are defined for this new Error 845 Code as follows: 847 Value | Description | Reference 848 --------+---------------------------------+-------------- 849 0 | Reserved | [This.ID] 850 1 | MEP establishment not supported | [This.ID] 851 2 | MIP establishment not supported | [This.ID] 852 3 | Unsupported OAM Type | [This.ID] 853 4 | Configuration Error | [This.ID] 854 5 | OAM Type Mismatch | [This.ID] 855 6 | Unsupported OAM Function | [This.ID] 856 7-32767 | Unassigned | 857 32768-65535| Reserved for Private Use | [This.ID] 859 5.5. RSVP-TE OAM Configuration Registry 861 IANA is requested to create a new registry called "RSVP-TE OAM 862 Configuration Registry". 864 IANA is requested to create sub-registries as defined in the 865 following subsections. The registration procedures specified are as 866 defined in [RFC5226]. 868 5.5.1. OAM Types Sub-Registry 870 IANA is requested to create the "OAM Types" sub-registry of the 871 "RSVP-TE OAM Configuration Registry" as follows: 873 Range | Registration Procedures 874 -------+------------------------- 875 0-255 | IETF Review 877 There are no initial values in this registry. IANA should show the 878 registry as follows: 880 OAM Type Number | OAM Type Description | Reference 881 ----------------+----------------------+-------------- 882 0-255 | Unassigned | 884 5.5.2. OAM Sub-TLVs Sub-Registry 886 IANA is requested to create the "OAM Sub-TLVs" sub-registry of the 887 "RSVP-TE OAM Configuration Registry" as follows: 889 Range | Purpose | Registration Procedures 890 ------------+------------------------------|------------------------ 891 0-31 | Generic Sub-TLVs | IETF Review 892 32-65534 | Technology-specific Sub-TLVs | IETF Review 893 65535-65536 | Experimental Sub-TLVs | Experimental 895 IANA is requested to populate the registry as follows: 897 Sub-TLV Type | Description | Reference 898 -------------+----------------------------+------- 899 0 | Reserved | [This.ID] 900 1 | OAM Function Flags Sub-TLV | [This.ID] 901 2-31 | Unassigned | 902 32-65534 | Unassigned | 904 5.5.3. OAM Function Flags Sub-Registry 906 IANA is requested to create the "OAM Function Flags Sub-Registry" 907 sub-registry of the "RSVP-TE OAM Configuration Registry". 909 New values in the registry are allocated by "IETF Review". There is 910 no top value to the range. Bits are counted from bit 0 as the first 911 bit transmitted. 913 IANA is requested to populate the registry as follows. 915 OAM Function Flag | Description 916 bit number | 917 ------------------+--------------------------------------------- 918 0 | Continuity Check (CC) 919 1 | Connectivity Verification (CV) 920 2 | Fault Management Signal (FMS) 921 3 | Performance Monitoring/Loss (PM/Loss) 922 4 | Performance Monitoring/Delay (PM/Delay) 923 5 | Performance Monitoring/Throughput Measurement 924 | (PM/Throughput) 925 6-... | Unassigned 927 6. Security Considerations 929 The signaling of OAM related parameters and the automatic 930 establishment of OAM entities based on RSVP-TE messages adds a new 931 aspect to the security considerations discussed in [RFC3473]. In 932 particular, a network element could be overloaded, if a remote 933 attacker could request liveliness monitoring, with frequent periodic 934 messages, for a high number of LSPs, targeting a single network 935 element. Such an attack can efficiently be prevented when mechanisms 936 for message integrity and node authentication are deployed. Since 937 the OAM configuration extensions rely on the hop-by-hop exchange of 938 exiting RSVP-TE messages, procedures specified for RSVP message 939 security in [RFC2747] can be used to mitigate possible attacks. 941 For a more comprehensive discussion of GMPLS security, and attack 942 mitigation techniques, please see the Security Framework for MPLS and 943 GMPLS Networks [RFC5920]. 945 7. Acknowledgements 947 The authors would like to thank Francesco Fondelli, Adrian Farrel, 948 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 949 comments. 951 8. References 953 8.1. Normative References 955 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 956 Requirement Levels", BCP 14, RFC 2119, March 1997. 958 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 959 (GMPLS) Signaling Functional Description", RFC 3471, 960 January 2003. 962 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 963 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 964 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 966 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 967 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 968 May 2008. 970 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 971 Ayyangarps, "Encoding of Attributes for MPLS LSP 972 Establishment Using Resource Reservation Protocol Traffic 973 Engineering (RSVP-TE)", RFC 5420, February 2009. 975 8.2. Informative References 977 [IEEE.802.1Q-2011] 978 IEEE, "IEEE Standard for Local and metropolitan area 979 networks -- Media Access Control (MAC) Bridges and Virtual 980 Bridged Local Area Networks", IEEE Std 802.1Q, 2011. 982 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 983 Authentication", RFC 2747, January 2000. 985 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 986 Matsushima, "Operations and Management (OAM) Requirements 987 for Multi-Protocol Label Switched (MPLS) Networks", RFC 988 4377, February 2006. 990 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 991 Label Switched (MPLS) Data Plane Failures", RFC 4379, 992 February 2006. 994 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 995 "Extensions to Resource Reservation Protocol - Traffic 996 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 997 Switched Paths (LSPs)", RFC 4875, May 2007. 999 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1000 and S. Ueno, "Requirements of an MPLS Transport Profile", 1001 RFC 5654, September 2009. 1003 [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized 1004 Multiprotocol Label Switching (GMPLS) Ethernet Label 1005 Switching Architecture and Framework", RFC 5828, March 1006 2010. 1008 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1009 Operations, Administration, and Maintenance (OAM) in MPLS 1010 Transport Networks", RFC 5860, May 2010. 1012 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1013 Networks", RFC 5920, July 2010. 1015 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1016 Berger, "A Framework for MPLS in Transport Networks", RFC 1017 5921, July 2010. 1019 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 1020 "Generalized Multiprotocol Label Switching (GMPLS) Control 1021 of Ethernet Provider Backbone Traffic Engineering (PBB- 1022 TE)", RFC 6060, March 2011. 1024 Authors' Addresses 1026 Attila Takacs 1027 Ericsson 1028 Konyves Kalman krt. 11. 1029 Budapest 1097 1030 Hungary 1032 Email: attila.takacs@ericsson.com 1033 Don Fedyk 1034 Hewlett-Packard Company 1035 153 Taylor Street 1036 Littleton, MA 01460 1037 USA 1039 Email: don.fedyk@hp.com 1041 Jia He 1042 Huawei 1044 Email: hejia@huawei.com