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