idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-11.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 (December 2, 2013) is 3791 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: June 5, 2014 Alcatel-Lucent 6 J. He 7 Huawei 8 December 2, 2013 10 GMPLS RSVP-TE extensions for OAM Configuration 11 draft-ietf-ccamp-oam-configuration-fwk-11 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 June 5, 2014. 50 Copyright Notice 52 Copyright (c) 2013 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 . . . . . . . 7 71 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . 9 72 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9 73 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . 10 74 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 10 75 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 76 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . 13 77 4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . 14 78 4.3. Administrative Status Information . . . . . . . . . . . . 14 79 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14 80 4.5. Considerations on Point-to-Multipoint OAM Configuration . 15 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 5.1. ADMIN_STATUS Object Bit Flags . . . . . . . . . . . . . . 16 83 5.2. LSP Attributes Flags . . . . . . . . . . . . . . . . . . 16 84 5.3. New LSP Attributes . . . . . . . . . . . . . . . . . . . 17 85 5.4. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 17 86 5.5. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 18 87 5.5.1. OAM Types Sub-Registry . . . . . . . . . . . . . . . 18 88 5.5.2. OAM Sub-TLVs Sub-Registry . . . . . . . . . . . . . . 18 89 5.5.3. OAM Function Flags Sub-Registry . . . . . . . . . . . 19 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 8.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 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 3.1. Establishment of OAM Entities and Functions 309 In order to avoid spurious alarms, OAM functions should be setup and 310 enabled in the appropriate order. When using the GMPLS control plane 311 for both LSP establishment and to enable OAM functions on the LSPs, 312 the control of both processes is bound to RSVP-TE message exchanges. 314 An LSP may be signaled and established without OAM configuration 315 first, and OAM entities may be added later with a subsequent re- 316 signaling of the LSP. Alternatively, the LSP may be setup with OAM 317 entities with the first signaling of the LSP. The below procedures 318 apply to both cases. 320 Before initiating a Path message with OAM Configuration information, 321 an initiating node MUST establish and configure the corresponding OAM 322 entities locally. But until the LSP is established, OAM source 323 functions MUST NOT start sending any OAM messages. In the case of 324 bidirectional connections, in addition to the OAM source function, 325 the initiator node MUST set up the OAM sink function and prepare it 326 to receive OAM messages. During this time the OAM alarms MUST be 327 suppressed (e.g., due to missing or unidentified OAM messages). To 328 achieve OAM alarm suppression, Path message MUST be sent with the 329 "OAM Alarms Enabled" ADMIN_STATUS flag cleared. 331 When the Path message arrives at the receiver, the remote end MUST 332 establish and configure OAM entities according to the OAM information 333 provided in the Path message. If this is not possible, a PathErr 334 SHOULD be sent and neither the OAM entities nor the LSP SHOULD be 335 established. If OAM entities are established successfully, the OAM 336 sink function MUST be prepared to receive OAM messages, but MUST NOT 337 generate any OAM alarms (e.g., due to missing or unidentified OAM 338 messages). In the case of bidirectional connections, in addition to 339 the OAM sink function, an OAM source function MUST be set up and, 340 according to the requested configuration, the OAM source function 341 MUST start sending OAM messages. Then a Resv message MUST be sent 342 back, including the LSP_Attributes Flags TLV, with the appropriate 343 setting of the "OAM MEP entities desired" and "OAM MIP entities 344 desired" flags, and the OAM Configuration TLV that corresponds to the 345 established and configured OAM entities and functions. Depending on 346 the OAM technology, some elements of the OAM Configuration TLV MAY be 347 updated/changed; i.e., if the remote end is not supporting a certain 348 OAM configuration it may suggest an alternative setting, which may or 349 may not be accepted by the initiator of the Path message. If it is 350 accepted, the initiator will reconfigure its OAM functions according 351 to the information received in the Resv message. If the alternate 352 setting is not acceptable a ResvErr may be sent tearing down the LSP. 353 Details of this operation are technology specific and should be 354 described in accompanying technology specific documents. 356 When the initiating side receives the Resv message, it completes any 357 pending OAM configuration and enables the OAM source function to send 358 OAM messages. 360 After this exchange, OAM entities are established and configured for 361 the LSP and OAM messages are exchanged. OAM alarms can now be 362 enabled. The initiator, during the period when OAM alarms are 363 disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS 364 flag set. The receiving node enables the OAM alarms after processing 365 the Path message. The initiator enables OAM alarms after it receives 366 the Resv message. Data plane OAM is now fully functional. 368 In case an egress LSR does not support the extensions defined in this 369 document, according to [RFC5420], it will silently ignore the new LSP 370 Attributes Flags as well as the TLVs carrying additional OAM 371 configuration information, and therefore no error will be raised that 372 would notify the ingress LSR about the missing OAM configuration 373 actions on the egress side. However, as described above, an egress 374 LSR conformant to the specification of this document will set the LSP 375 Attributes Flags and include the OAM Configuration TLV in the Resv 376 message indicating the configuration of the OAM mechanisms, therefore 377 an ingress LSR by detecting the missing information in the Resv 378 message will be able to recognize that the remote end does not 379 support the OAM configuration functionality and therefore it SHOULD 380 tear down the LSP, and if appropriate, signal the LSP without any OAM 381 configuration information. 383 3.2. Adjustment of OAM Parameters 385 There may be a need to change the parameters of an already 386 established and configured OAM function during the lifetime of the 387 LSP. To do so the LSP needs to be re-signaled with the updated 388 parameters. OAM parameters influence the content and timing of OAM 389 messages and identify the way OAM defects and alarms are derived and 390 generated. Hence, to avoid spurious alarms, it is important that 391 both sides, OAM sink and source, are updated in a synchronized way. 392 First, the alarms of the OAM sink function should be suppressed and 393 only then should expected OAM parameters be adjusted. Subsequently, 394 the parameters of the OAM source function can be updated. Finally, 395 the alarms of the OAM sink side can be enabled again. 397 In accordance with the above operation, the LSP MUST first be re- 398 signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared, 399 including the updated OAM Configuration TLV corresponding to the new 400 parameter settings. The initiator MUST keep its OAM sink and source 401 functions running unmodified, but it MUST suppress OAM alarms after 402 the updated Path message is sent. The receiver MUST first disable 403 all OAM alarms, then update the OAM parameters according to the 404 information in the Path message and reply with a Resv message 405 acknowledging the changes by including the OAM Configuration TLV. 406 Note that the receiving side has the possibility to adjust the 407 requested OAM configuration parameters and reply with an updated OAM 408 Configuration TLV in the Resv message, reflecting the actually 409 configured values. However, in order to avoid an extensive 410 negotiation phase, in the case of adjusting already configured OAM 411 functions, the receiving side SHOULD NOT update the parameters 412 requested in the Path message to an extent that would provide lower 413 performance (e.g., lower frequency of monitoring packets) than what 414 has been in operation previously. 416 The initiator MUST only update its OAM sink and source functions 417 after it received the Resv message. After this Path/Resv message 418 exchange (in both unidirectional and bidirectional LSP cases) the OAM 419 parameters are updated and OAM is running according the new parameter 420 settings. However, OAM alarms are still disabled. A subsequent Path 421 /Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag 422 set is needed to enable OAM alarms again. 424 3.3. Deleting OAM Entities 425 In some cases it may be useful to remove some or all OAM entities and 426 functions from an LSP without actually tearing down the connection. 428 To avoid any spurious alarms, first the LSP MUST be re-signaled with 429 "OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM 430 configuration. Subsequently, the LSP is re-signaled with "OAM MEP 431 Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags 432 cleared, and without the OAM Configuration TLV, this MUST result in 433 the deletion of all OAM entities associated with the LSP. All 434 control and data plane resources in use by the OAM entities and 435 functions SHOULD be freed up. Alternatively, if only some OAM 436 functions need to be removed, the LSP is re-signaled with the updated 437 OAM Configuration TLV. Changes between the contents of the 438 previously signaled OAM Configuration TLV and the currently received 439 TLV represent which functions MUST be removed/added. 441 OAM source functions MUST be deleted first and only after the "OAM 442 Alarms Disabled" can the associated OAM sink functions be removed, 443 this will ensure that OAM messages do not leak outside the LSP. To 444 this end the initiator, before sending the Path message, MUST remove 445 the OAM source, hence terminating the OAM message flow associated to 446 the downstream direction. In the case of a bidirectional connection, 447 it MUST leave in place the OAM sink functions associated to the 448 upstream direction. The remote end, after receiving the Path 449 message, MUST remove all associated OAM entities and functions and 450 reply with a Resv message without an OAM Configuration TLV. The 451 initiator completely removes OAM entities and functions after the 452 Resv message arrived. 454 4. RSVP-TE Extensions 456 4.1. LSP Attributes Flags 458 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 459 indicate options and attributes of the LSP. The Flags field has 8 460 bits and hence is limited to differentiate only 8 options. [RFC5420] 461 defines new objects for RSVP-TE messages to allow the signaling of 462 arbitrary attribute parameters making RSVP-TE easily extensible to 463 support new applications. Furthermore, [RFC5420] allows options and 464 attributes that do not need to be acted on by all Label Switched 465 Routers (LSRs) along the path of the LSP. In particular, these 466 options and attributes may apply only to key LSRs on the path such as 467 the ingress LSR and egress LSR. Options and attributes can be 468 signaled transparently, and only examined at those points that need 469 to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES 470 objects are defined in [RFC5420] to provide means to signal LSP 471 attributes and options in the form of TLVs. Options and attributes 472 signaled in the LSP_ATTRIBUTES object can be passed transparently 473 through LSRs not supporting a particular option or attribute, while 474 the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined 475 and processed by each LSR. One TLV is defined in [RFC5420]: the 476 Attributes Flags TLV. 478 One bit (IANA to assign): "OAM MEP entities desired" is allocated in 479 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. 480 If the "OAM MEP entities desired" bit is set it is indicating that 481 the establishment of OAM MEP entities are required at the endpoints 482 of the signaled LSP. If the establishment of MEPs is not supported 483 an error MUST be generated: "OAM Problem/MEP establishment not 484 supported". 486 If the "OAM MEP entities desired" bit is set and additional 487 parameters need to be configured, an OAM Configuration TLV MAY be 488 included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. 490 One bit (IANA to assign): "OAM MIP entities desired" is allocated in 491 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or 492 LSP_REQUIRED_ATTRIBUES objects. If the "OAM MEP entities desired" 493 bit is not set then this bit MUST NOT be set. If the "OAM MIP 494 entities desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the 495 LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the 496 establishment of OAM MIP entities is required at every transit node 497 of the signaled LSP. If the establishment of a MIP is not supported 498 an error MUST be generated: "OAM Problem/MIP establishment not 499 supported". If an intermediate LSR does not support the extensions 500 defined in this document it will not recognize the "OAM MIP entities 501 desired" flag and although the LSP_REQUIRED_ATTRIBUTES object was 502 used it will not configure MIP entities and will not raise any 503 errors. If LSRs that are not supporting this document are to be 504 assumed in the network, the ingress LSR SHOULD collect per-hop 505 information about the LSP Attributes utilizing the LSP Attributes 506 sub-object of the Record Route Object as defined in [RFC5420]. When 507 the Record Route object is received the ingress SHOULD check whether 508 all intermediate LSRs set the "OAM MIP entities desired" flag 509 indicating support of the function, if not, depending on operator 510 policy the LSP MAY need to be torn down. 512 4.2. OAM Configuration TLV 514 This TLV provides information about which OAM technology/method 515 should be used and carries sub-TLVs for any additional OAM 516 configuration information. One OAM Configuration TLV MAY be carried 517 in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and 518 Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, 519 it is indicating that intermediate nodes MUST recognize and react on 520 the OAM configuration information. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type (IANA) | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | OAM Type | Reserved | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 ~ sub-TLVs ~ 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Type: indicates a new type: the OAM Configuration TLV (IANA to 535 assign). 537 OAM Type: specifies the technology specific OAM method. When carried 538 in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is 539 not supported at any given node an error MUST be generated: "OAM 540 Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES 541 Object, intermediate nodes not supporting the OAM Type pass the 542 object forward unchanged as specified in [RFC5420]. Ingress and 543 egress nodes that support the OAM Configuration TLV but that do not 544 support a specific OAM Type MUST respond with an error indicating 545 "OAM Problem/Unsupported OAM Type". 547 OAM Type Description 548 ------------ -------------------- 549 0-255 Reserved 551 This document defines no types. IANA is requested to maintain the 552 values in a new "RSVP-TE OAM Configuration Registry". 554 Two groups of TLVs are defined: generic sub-TLVs and technology 555 specific sub-TLVs. Generic sub-TLVs carry information that are 556 applicable independent of the actual OAM technology, while technology 557 specific sub-TLVs are providing configuration parameters for specific 558 OAM technologies. This document defines one generic sub-TLV, see 559 Section 4.2.1, while it is foreseen that technology specific sub-TLVs 560 will be defined by separate documents. 562 The receiving node, based on the OAM Type, will check if a 563 corresponding technology specific OAM configuration sub-TLV is 564 included in the OAM Configuration TLV. If the included technology 565 specific OAM configuration sub-TLV is different from what is 566 specified in the OAM Type an error MUST be generated: "OAM Problem/ 567 OAM Type Mismatch". IANA is requested to maintain the sub-TLV space 568 in the new "RSVP-TE OAM Configuration Registry". 570 Sub-TLV Type Description 571 ------------ ------------------------------------ 572 0 Reserved 573 1 OAM Function Flags Sub-TLV 574 2-31 Reserved for generic Sub-TLVs 575 32- Reserved for technology specific Sub-TLVs 577 Note that there is a hierarchical dependency between the OAM 578 configuration elements. First, the "OAM MEP entities desired" flag 579 needs to be set. Only when that flag is set MAY an "OAM 580 Configuration TLV" be included in the LSP_ATTRIBUTES or 581 LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on 582 the "OAM Type" field, it MAY carry a technology specific OAM 583 configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP 584 entities desired" flag is not set but an OAM Configuration TLV is 585 present) an error MUST be generated: "OAM Problem/Configuration 586 Error". 588 4.2.1. OAM Function Flags Sub-TLV 590 The "OAM Configuration TLV" MUST always include a single instance of 591 the "OAM Function Flags Sub-TLV" and it MUST always be the first sub- 592 TLV. "OAM Function Flags" specifies which pro-active OAM functions 593 (e.g., connectivity monitoring, loss and delay measurement) and which 594 fault management signals MUST be established and configured. If the 595 selected OAM Function(s) is(are) not supported, an error MUST be 596 generated: "OAM Problem/Unsupported OAM Function". 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type (1) (IANA) | Length | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | | 604 ~ OAM Function Flags ~ 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 OAM Function Flags is bitmap with extensible length based on the 609 Length field of the TLV. Bits are numbered from left to right. The 610 TLV is padded to 4-octet alignment. The Length field indicates the 611 size of the padded TLV in octets. IANA is requested to maintain the 612 OAM Function Flags in the new "RSVP-TE OAM Configuration Registry". 613 This document defines the following flags. 615 OAM Function Flag bit# Description 616 --------------------- --------------------------- 617 0 Continuity Check (CC) 618 1 Connectivity Verification (CV) 619 2 Fault Management Signal (FMS) 620 3 Performance Monitoring/Loss (PM/Loss) 621 4 Performance Monitoring/Delay (PM/Delay) 622 5 Performance Monitoring/Throughput Measurement 623 (PM/Throughput) 625 4.2.2. Technology Specific Sub-TLVs 627 If technology-specific configuration information is needed for a 628 specific "OAM Type", then this information is carried in a 629 technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an OAM 630 Configuration TLV MUST NOT contain more than one technology- specific 631 sub-TLV. IANA is requested to maintain the OAM technology specific 632 sub-TLV space in the new "RSVP-TE OAM Configuration Registry". 634 4.3. Administrative Status Information 636 Administrative Status Information is carried in the ADMIN_STATUS 637 Object. The Administrative Status Information is described in 638 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 639 [RFC3473]. 641 Two bits are allocated for the administrative control of OAM 642 monitoring. Two bits (IANA to assign) are allocated by this 643 document: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) 644 bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST 645 be enabled; if it is cleared, OAM mechanisms MUST be disabled. When 646 the "OAM Alarms Enabled" bit is set OAM triggered alarms are enabled 647 and associated consequent actions MUST be executed including the 648 notification to the management system. When this bit is cleared, 649 alarms are suppressed and no action SHOULD be executed and the 650 management system SHOULD NOT be notified. For a detailed description 651 of the use of these flags see Section 3. 653 4.4. Handling OAM Configuration Errors 655 To handle OAM configuration errors, a new Error Code (IANA to assign) 656 "OAM Problem" is introduced. To refer to specific problems, a set of 657 Error Values are defined under the "OAM Problem" error code. 659 If a node does not support the establishment of OAM MEP or MIP 660 entities it MUST use the error value: "MEP establishment not 661 supported" or "MIP establishment not supported" respectively in the 662 PathErr message. 664 If a node does not support a specific OAM technology/solution it MUST 665 use the error value: "Unsupported OAM Type" in the PathErr message. 667 If a different technology specific OAM configuration TLV is included 668 than what was specified in the OAM Type an error MUST be generated 669 with error value: "OAM Type Mismatch" in the PathErr message. 671 There is a hierarchy between the OAM configuration elements. If this 672 hierarchy is broken, the error value: "Configuration Error" MUST be 673 used in the PathErr message. 675 If a node does not support a specific OAM Function, it MUST use the 676 error value: "Unsupported OAM Function" in the PathErr message. 678 4.5. Considerations on Point-to-Multipoint OAM Configuration 680 RSVP-TE extensions for the establishment of point-to-multipoint 681 (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of 682 multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set 683 up between the ingress and egress LSRs, and are appropriately 684 combined by the branch LSRs using RSVP semantics to result in a P2MP 685 TE LSP. One Path message may signal one or multiple S2L sub-LSPs for 686 a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP 687 can be signaled using one Path message or split across multiple Path 688 messages. 690 P2MP OAM mechanisms are very specific to the data plane technology, 691 therefore in this document, we only highlight the basic principles of 692 P2MP OAM configuration. We consider only the root to leaf OAM flows, 693 and as such, aspects of the configuration of return paths are outside 694 the scope of our discussions. We also limit our consideration to the 695 case where all leaves must successfully establish OAM entities with 696 identical configuration in order the P2MP OAM is successfully 697 established. In any case, the discussion set forth below provides 698 only guidelines for P2MP OAM configuration, details will be specified 699 in technology specific documents. 701 The root node may use a single Path message or multiple Path messages 702 to setup the whole P2MP tree. In the case when multiple Path 703 messages are used, the root node is responsible to keep the OAM 704 Configuration information consistent in each of the sent Path 705 messages, i.e., the same information MUST be included in all Path 706 messages used to construct the multicast tree. Each branching node 707 will propagate the Path message downstream on each of the branches, 708 when constructing a Path message the OAM Configuration information 709 MUST be copied unchanged from the received Path message, including 710 the related ADMIN_STATUS bits, LSP Attribute Flags and the OAM 711 Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES 712 and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for the upstream 713 Path message to the subsequent downstream Path messages. 715 Leaves MUST create and configure OAM sink functions according to the 716 parameters received in the Path message, for P2MP OAM configuration 717 there is no possibility for parameter negotiation on a per leaf 718 basis. This is due to the fact that the OAM source function, 719 residing in the root of the tree, will operate with a single 720 configuration, which then must be obeyed by all leaves. If a leaf 721 cannot accept the OAM parameters it MUST use the RRO Attributes sub- 722 object [RFC5420] to notify the root about the problem. In 723 particular, if the OAM configuration was successful, the leaf would 724 set the "OAM MEP entities desired" flag in the RRO Attributes sub- 725 object in the Resv message. On the other hand, if OAM entities could 726 not be established the Resv message should be sent with the "OAM MEP 727 entities desired" bit cleared in the RRO Attributes sub-object. 728 Branching nodes should collect and merge the received RROs according 729 to the procedures described in [RFC4875]. This way, the root when 730 receiving the Resv message (or messages if multiple Path messages 731 were used to set up the tree) will have a clear information about 732 which of the leaves could establish the OAM functions. If all leaves 733 established OAM entities successfully, the root can enable the OAM 734 message flow. On the other hand, if at some leaves the establishment 735 was unsuccessful additional actions will be needed before the OAM 736 message flow can be enabled. Such action could be to setup two 737 independent P2MP LSPs. One LSP with OAM Configuration information 738 towards leaves which could successfully setup the OAM function. This 739 can be done by pruning the leaves which failed to setup OAM of the 740 previously signaled P2MP LSP. The other P2MP LSP could be 741 constructed for leaves without OAM entities. The exact procedures 742 will be described in technology specific documents. 744 5. IANA Considerations 746 5.1. ADMIN_STATUS Object Bit Flags 748 IANA maintains a registry called "Generalized Multi-Protocol Label 749 Switching (GMPLS) Signaling Parameters" with a sub-registry called 750 "Administrative Status Information Flags". 752 IANA is requested to allocate two new flags as follows: 754 Bit Number | Hex Value | Name | Reference 755 -----------+------------+--------------------------+----------- 756 TBA | TBA | OAM Alarms Enabled (O) | [This.ID] 757 TBA | TBA | OAM Flows Enabled (M) | [This.ID] 759 5.2. LSP Attributes Flags 760 IANA maintains a registry called "Resource Reservation Protocol- 761 Traffic Engineering (RSVP-TE) Parameters" with a subregistry called 762 "Attribute Flags". 764 IANA is requested to allocate two new flags as follows: 766 Bit | Name | Attribute | Attribute | RRO | Reference 767 No | | Flags Path | Flags Resv | | 768 ----+------------------+------------+------------+-----+---------- 769 TBA | OAM MEP | | | | 770 | entities desired | Yes | Yes | Yes | [This.ID] 771 | | | | | 772 TBA | OAM MIP | | | | 773 | entities desired | Yes | Yes | Yes | [This.ID] 775 5.3. New LSP Attributes 777 IANA maintains a registry called "Resource Reservation Protocol- 778 Traffic Engineering (RSVP-TE) Parameters" with a subregistry called 779 "Attributes TLV Space" 781 IANA is requested to allocate one new TLV type as follows: 783 Type| Name |Allowed on |Allowed on |Reference 784 | |LSP_ATTRIBUTES|LSP_REQUIRED_| 785 | | |ATTRIBUTES | 786 ----+----------------------+--------------+-------------+--------- 787 TBA| OAM Configuration TLV| Yes | Yes |[This.ID] 789 5.4. RSVP Error Code 791 IANA maintains a registry called "Resource Reservation Protocol 792 (RSVP) Parameters" with a subregistry called "Error Codes and 793 Globally-Defined Error Value Sub-Codes". 795 IANA is requested to allocate one new Error Code as follows: 797 Error Code | Meaning | Reference 798 -----------+-------------+------------- 799 TBA | OAM Problem | [This.ID] 801 The value is to be selected from the range 0-239. 803 The following Error Value sub-codes are defined for this new Error 804 Code as follows: 806 Value | Description | Reference 807 ------+---------------------------------+-------------- 808 1 | MEP establishment not supported | [This.ID] 809 2 | MIP establishment not supported | [This.ID] 810 3 | Unsupported OAM Type | [This.ID] 811 4 | Configuration Error | [This.ID] 812 5 | OAM Type Mismatch | [This.ID] 813 6 | Unsupported OAM Function | [This.ID] 815 5.5. RSVP-TE OAM Configuration Registry 817 IANA is requested to create a new registry called "RSVP-TE OAM 818 Configuration Registry". 820 IANA is requested to create sub-registries as defined in the 821 following subsections: 823 5.5.1. OAM Types Sub-Registry 825 IANA is requested to create the "OAM Types" sub-registry of the 826 "RSVP-TE OAM Configuration Registry" as follows: 828 Range | Registration Procedures 829 -------+------------------------- 830 0-255 | IETF Review 832 There are no initial values in this registry. IANA should show the 833 registry as follows: 835 OAM Type Number | OAM Type Description | Reference 836 ----------------+----------------------+-------------- 837 0-255 | Not allocated | 839 5.5.2. OAM Sub-TLVs Sub-Registry 841 IANA is requested to create the "OAM Sub-TLVs" sub-registry of the 842 "RSVP-TE OAM Configuration Registry" as follows: 844 Range | Purpose | Registration Procedures 845 ------------+------------------------------|------------------------ 846 0-31 | Generic Sub-TLVs | IETF Review 847 32-65534 | Technology-specific Sub-TLVs | IETF Review 848 65535-65536 | Experimental Sub-TLVs | Experimental 850 IANA is requested to populate the registry as follows: 852 Sub-TLV Type | Description | Reference 853 -------------+----------------------------+------- 854 0 | Reserved | [This.ID] 855 1 | OAM Function Flags Sub-TLV | [This.ID] 856 2-31 | Not allocated | 857 32-65534 | Not allocated | 859 5.5.3. OAM Function Flags Sub-Registry 861 IANA is requested to create the "OAM Function Flags Sub-Registry" 862 sub-registry of the "RSVP-TE OAM Configuration Registry". 864 New values in the registry are allocated by "IETF Review". There is 865 no top value to the range. Bits are counted from bit 0 as the first 866 bit transmitted. 868 IANA is requested to populate the registry as follows. 870 OAM Function Flag | Description 871 bit number | 872 ------------------+--------------------------------------------- 873 0 | Continuity Check (CC) 874 1 | Connectivity Verification (CV) 875 2 | Fault Management Signal (FMS) 876 3 | Performance Monitoring/Loss (PM/Loss) 877 4 | Performance Monitoring/Delay (PM/Delay) 878 5 | Performance Monitoring/Throughput Measurement 879 | (PM/Throughput) 880 6-... | Not allocated 882 6. Security Considerations 884 The signaling of OAM related parameters and the automatic 885 establishment of OAM entities based on RSVP-TE messages adds a new 886 aspect to the security considerations discussed in [RFC3473]. In 887 particular, a network element could be overloaded, if a remote 888 attacker could request liveliness monitoring, with frequent periodic 889 messages, for a high number of LSPs, targeting a single network 890 element. Such an attack can efficiently be prevented when mechanisms 891 for message integrity and node authentication are deployed. Since 892 the OAM configuration extensions rely on the hop-by-hop exchange of 893 exiting RSVP-TE messages, procedures specified for RSVP message 894 security in [RFC2747] can be used to mitigate possible attacks. 896 For a more comprehensive discussion on GMPLS security, please see the 897 Security Framework for MPLS and GMPLS Networks [RFC5920]. 898 Cryptography can be used to protect against many attacks described in 899 [RFC5920]. 901 7. Acknowledgements 902 The authors would like to thank Francesco Fondelli, Adrian Farrel, 903 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 904 comments. 906 8. References 908 8.1. Normative References 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 914 (GMPLS) Signaling Functional Description", RFC 3471, 915 January 2003. 917 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 918 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 919 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 921 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 922 Ayyangarps, "Encoding of Attributes for MPLS LSP 923 Establishment Using Resource Reservation Protocol Traffic 924 Engineering (RSVP-TE)", RFC 5420, February 2009. 926 8.2. Informative References 928 [IEEE.802.1Q-2011] 929 IEEE, "IEEE Standard for Local and metropolitan area 930 networks -- Media Access Control (MAC) Bridges and Virtual 931 Bridged Local Area Networks", IEEE Std 802.1Q, 2011. 933 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 934 Authentication", RFC 2747, January 2000. 936 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 937 Matsushima, "Operations and Management (OAM) Requirements 938 for Multi-Protocol Label Switched (MPLS) Networks", RFC 939 4377, February 2006. 941 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 942 Label Switched (MPLS) Data Plane Failures", RFC 4379, 943 February 2006. 945 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 946 "Extensions to Resource Reservation Protocol - Traffic 947 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 948 Switched Paths (LSPs)", RFC 4875, May 2007. 950 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 951 and S. Ueno, "Requirements of an MPLS Transport Profile", 952 RFC 5654, September 2009. 954 [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized 955 Multiprotocol Label Switching (GMPLS) Ethernet Label 956 Switching Architecture and Framework", RFC 5828, March 957 2010. 959 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 960 Operations, Administration, and Maintenance (OAM) in MPLS 961 Transport Networks", RFC 5860, May 2010. 963 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 964 Networks", RFC 5920, July 2010. 966 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 967 Berger, "A Framework for MPLS in Transport Networks", RFC 968 5921, July 2010. 970 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 971 "Generalized Multiprotocol Label Switching (GMPLS) Control 972 of Ethernet Provider Backbone Traffic Engineering (PBB- 973 TE)", RFC 6060, March 2011. 975 Authors' Addresses 977 Attila Takacs 978 Ericsson 979 Konyves Kalman krt. 11. 980 Budapest 1097 981 Hungary 983 Email: attila.takacs@ericsson.com 985 Don Fedyk 986 Alcatel-Lucent 987 Groton, MA 01450 988 USA 990 Email: donald.fedyk@alcatel-lucent.com 992 Jia He 993 Huawei 995 Email: hejia@huawei.com