idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-10.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 (June 15, 2013) is 3968 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: December 17, 2013 Alcatel-Lucent 6 J. He 7 Huawei 8 June 15, 2013 10 GMPLS RSVP-TE extensions for OAM Configuration 11 draft-ietf-ccamp-oam-configuration-fwk-10 13 Abstract 15 OAM is an integral part of transport connections, hence it is 16 required that OAM functions are activated/deactivated in sync with 17 connection commissioning/decommissioning; avoiding spurious alarms 18 and ensuring consistent operation. In certain technologies, OAM 19 entities are inherently established once the connection is set up, 20 while other technologies require extra configuration to establish and 21 configure OAM entities. This document specifies extensions to 22 RSVP-TE to support the establishment and configuration of OAM 23 entities along with LSP signaling. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 17, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 6 67 3.1. Establishment of OAM Entities and Functions . . . . . . . 7 68 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 8 69 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 9 70 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 10 72 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 73 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 12 74 4.2.2. Technology Specific Sub-TLVs . . . . . . . . . . . . . 13 75 4.3. Administrative Status Information . . . . . . . . . . . . 13 76 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 14 77 4.5. Considerations on Point-to-Multipoint OAM Configuration . 14 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 GMPLS is designed as an out-of-band control plane supporting dynamic 89 connection provisioning for any suitable data plane technology; 90 including spatial switching (e.g., incoming port or fiber to outgoing 91 port or fiber), wavelength-division multiplexing (e.g., DWDM), time- 92 division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider 93 Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most 94 of these technologies, there are Operations, Administration and 95 Maintenance (OAM) functions employed to monitor the health and 96 performance of the connections and to trigger data plane (DP) 97 recovery mechanisms. Similar to connection provisioning, OAM 98 functions follow general principles, but also have some technology 99 specific characteristics. 101 OAM is an integral part of transport connections. Therefore it is 102 required that OAM functions are activated/deactivated in sync with 103 connection commissioning/decommissioning; avoiding spurious alarms 104 and ensuring consistent operation. In certain technologies, OAM 105 entities are inherently established once the connection is set up, 106 while other technologies require extra configuration to establish and 107 configure OAM entities. In some situations the use of OAM functions, 108 such as Fault Management (FM) and Performance Management (PM), may be 109 optional (based on network management policies). Hence, the network 110 operator must be able to choose which set of OAM functions to apply 111 to specific connections and which parameters should be configured and 112 activated. To achieve this objective, OAM entities and specific 113 functions must be selectively configurable. 115 In general, it is required that the management plane and control 116 plane connection establishment mechanisms are synchronized with OAM 117 establishment and activation. In particular, if the GMPLS control 118 plane is employed, it is desirable to bind OAM setup and 119 configuration to connection establishment signaling to avoid two 120 separate management/configuration steps (connection setup followed by 121 OAM configuration) which increases delay, processing, and more 122 importantly may be prone to misconfiguration errors. Once OAM 123 entities are setup and configured, pro-active as well as on-demand 124 OAM functions can be activated via the management plane. On the 125 other hand, it should be possible to activate/deactivate pro-active 126 OAM functions via the GMPLS control plane as well. In some 127 situations it may be possible to use the GMPLS control plane to 128 control on-demand OAM functions too. 130 This document describes requirements for OAM configuration and 131 control via RSVP-TE. Extensions to the RSVP-TE protocol are 132 specified providing a framework to configure and control OAM entities 133 along with the capability to carry technology specific information. 135 Extensions can be grouped into: generic elements that are applicable 136 to any OAM solution; and technology specific elements that provide 137 additional configuration parameters, which may only be needed for a 138 specific OAM technology. This document specifies the technology 139 agnostic elements and specifies the way additional technology 140 specific OAM parameters are provided. 142 This document addresses end-to-end OAM configuration, that is, the 143 setup of OAM entities bound to an end-to-end LSP, and configuration 144 and control of OAM functions running end-to-end in the LSP. 145 Configuration of OAM entities for LSP segments and tandem connections 146 are out of the scope of this document. 148 The mechanisms described in this document provide an additional 149 option for bootstrapping OAM that is not intended to replace or 150 deprecate the use of other technology specific OAM bootstrapping 151 techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The 152 procedures specified in this document are intended only for use in 153 environments where RSVP-TE signaling is used to set up the LSPs that 154 are to be monitored using OAM. 156 2. Requirements 158 This section summarizes various technology-specific OAM requirements 159 which can be used as a basis for an OAM configuration framework. 161 MPLS OAM requirements are described in [RFC4377], which provides 162 requirements to create consistent OAM functionality for MPLS 163 networks. The following list is an excerpt of MPLS OAM requirements 164 documented in [RFC4377] that bear a direct relevance to the 165 discussion set forth in this document. 167 o It is desired to support the automation of LSP defect detection. 168 It is especially important in cases where large numbers of LSPs 169 might be tested. 171 o In particular some LSPs may require automated ingress-LSR to 172 egress-LSR testing functionality, while others may not. 174 o Mechanisms are required to coordinate network responses to 175 defects. Such mechanisms may include alarm suppression, 176 translating defect signals at technology boundaries, and 177 synchronizing defect detection times by setting appropriately 178 bounded detection time frames. 180 MPLS-TP defines a profile of MPLS targeted at transport applications 181 [RFC5921]. This profile specifies the specific MPLS characteristics 182 and extensions required to meet transport requirements, including 183 providing additional OAM, survivability, and other maintenance 184 functions not currently supported by MPLS. Specific OAM requirements 185 for MPLS-TP are specified in [RFC5654] and [RFC5860]. MPLS-TP poses 186 the following requirements on the control plane to configure and 187 control OAM entities: 189 o From [RFC5860]: OAM functions MUST operate and be configurable 190 even in the absence of a control plane. Conversely, it SHOULD be 191 possible to configure as well as enable/disable the capability to 192 operate OAM functions as part of connectivity management, and it 193 SHOULD also be possible to configure as well as enable/disable the 194 capability to operate OAM functions after connectivity has been 195 established. 197 o From [RFC5654]: The MPLS-TP control plane MUST support the 198 configuration and modification of OAM maintenance points as well 199 as the activation/ deactivation of OAM when the transport path or 200 transport service is established or modified. 202 Ethernet Connectivity Fault Management (CFM) defines an adjunct 203 connectivity monitoring OAM flow to check the liveliness of Ethernet 204 networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011] Ethernet 205 networks support explicitly-routed Ethernet connections. CFM can be 206 used to track the liveliness of PBB-TE connections and detect data 207 plane failures. In IETF, the GMPLS controlled Ethernet Label 208 Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the 209 GMPLS control plane to support the establishment of PBB-TE data plane 210 connections. Without control plane support, separate management 211 commands would be needed to configure and start CFM. 213 GMPLS based OAM configuration and control, needs to provide a general 214 framework to be applicable to a wide range of data plane technologies 215 and OAM solutions. There are three typical data plane technologies 216 used for transport applications: wavelength based such as WSON, TDM 217 based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921] 218 and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes, 219 the operator MUST be able to configure and control the following OAM 220 functions: 222 o It MUST be possible to explicitly request the setup of OAM 223 entities for the signaled LSP and provide specific information for 224 the setup if this is required by the technology. 226 o Control of alarms is important to avoid false alarm indications 227 and reporting to the management system. It MUST be possible to 228 enable/disable alarms generated by OAM functions. In some cases, 229 selective alarm control may be desirable when, for instance, the 230 operator is only concerned about critical alarms. Therefore the 231 non-service affecting alarms should be inhibited. 233 o When periodic messages are used for liveliness check (continuity 234 check) of LSPs, it MUST be possible to set the frequency of 235 messages. This allows proper configuration for fulfilling the 236 requirements of the service and/or meeting the detection time 237 boundaries posed by possible congruent connectivity check 238 operations of higher layer applications. For a network operator 239 to be able to balance the trade-off between fast failure detection 240 and data overhead, it is beneficial to configure the frequency of 241 continuity check messages on a per LSP basis. 243 o Pro-active Performance Monitoring (PM) functions are used to 244 continuously collect information about specific characteristics of 245 the connection. For consistent measurement of Service Level 246 Agreements (SLAs), it MUST be possible to set common configuration 247 parameters for the LSP. 249 o The extensions MUST allow the operator to use only a minimal set 250 of OAM configuration and control features if supported by the OAM 251 solution or network management policy. Generic OAM parameters and 252 data plane or OAM technology specific parameters MUST be 253 supported. 255 3. RSVP-TE based OAM Configuration 257 In general, two types of Maintenance Points (MPs) can be 258 distinguished: Maintenance End Points (MEPs) and Maintenance 259 Intermediate Points (MIPs). MEPs reside at the ends of an LSP and 260 are capable of initiating and terminating OAM messages for Fault 261 Management (FM) and Performance Monitoring (PM). MIPs on the other 262 hand, are located at transit nodes of an LSP and are capable of 263 reacting to some OAM messages but otherwise do not initiate messages. 264 Maintenance Entity (ME) refers to an association of MEPs and MIPs 265 that are provisioned to monitor an LSP. The ME association is 266 achieved by configuring MPs to belong to the same ME. 268 When an LSP is signaled, a forwarding association is established 269 between endpoints and transit nodes via label bindings. This 270 association creates a context for the OAM entities monitoring the 271 LSP. On top of this association, OAM entities may be configured to 272 unambiguously identify MPs and MEs. 274 In addition to MP and ME identification parameters, pro-active OAM 275 functions (e.g., Continuity Check (CC) and Performance Monitoring 276 (PM)) may have additional parameters that require configuration as 277 well. In particular, the frequency of periodic CC packets and the 278 measurement interval for loss and delay measurements may need to be 279 configured. 281 The above parameters may be either derived from LSP provisioning 282 information, or alternatively, pre-configured default values can be 283 used. In the simplest case, the control plane MAY provide 284 information on whether or not OAM entities need to be setup for the 285 signaled LSP. If OAM entities are created, control plane signaling 286 MUST also provide a means to activate/deactivate OAM message flows 287 and associated alarms. 289 OAM identifiers, as well as the configuration of OAM functions, are 290 technology specific (i.e., vary depending on the data plane 291 technology and the chosen OAM solution). In addition, for any given 292 data plane technology, a set of OAM solutions may be applicable. 293 Therefore, the OAM configuration framework allows selecting a 294 specific OAM solution to be used for the signaled LSP and provides 295 means to carry detailed OAM configuration information in technology 296 specific TLVs. 298 3.1. Establishment of OAM Entities and Functions 300 In order to avoid spurious alarms, OAM functions should be setup and 301 enabled in the appropriate order. When using the GMPLS control 302 plane, establishment and enabling of OAM functions MUST be bound to 303 RSVP-TE message exchanges. 305 An LSP may be signaled and established without OAM configuration 306 first, and OAM entities may be added later with a subsequent re- 307 signaling of the LSP. Alternatively, the LSP may be setup with OAM 308 entities with the first signaling of the LSP. The below procedures 309 apply to both cases. 311 Before initiating a Path message with OAM Configuration information, 312 an initiating node MUST establish and configure the corresponding OAM 313 entities locally. But until the LSP is established, OAM source 314 functions MUST NOT start sending any OAM messages. In the case of 315 bidirectional connections, in addition to the OAM source function, 316 the initiator node MUST set up the OAM sink function and prepare it 317 to receive OAM messages. During this time the OAM alarms MUST be 318 suppressed (e.g., due to missing or unidentified OAM messages). To 319 achieve OAM alarm suppression, Path message MUST be sent with the 320 "OAM Alarms Enabled" ADMIN_STATUS flag cleared. 322 When the Path message arrives at the receiver, the remote end MUST 323 establish and configure OAM entities according to the OAM information 324 provided in the Path message. If this is not possible, a PathErr 325 SHOULD be sent and neither the OAM entities nor the LSP SHOULD be 326 established. If OAM entities are established successfully, the OAM 327 sink function MUST be prepared to receive OAM messages, but MUST NOT 328 generate any OAM alarms (e.g., due to missing or unidentified OAM 329 messages). In the case of bidirectional connections, in addition to 330 the OAM sink function, an OAM source function MUST be set up and, 331 according to the requested configuration, the OAM source function 332 MUST start sending OAM messages. Then a Resv message is sent back, 333 including the OAM Configuration TLV that corresponds to the 334 established and configured OAM entities and functions. Depending on 335 the OAM technology, some elements of the OAM Configuration TLV MAY be 336 updated/changed; i.e., if the remote end is not supporting a certain 337 OAM configuration it may suggest an alternative setting, which may or 338 may not be accepted by the initiator of the Path message. If it is 339 accepted, the initiator will reconfigure its OAM functions according 340 to the information received in the Resv message. If the alternate 341 setting is not acceptable a ResvErr may be sent tearing down the LSP. 342 Details of this operation are technology specific and should be 343 described in accompanying technology specific documents. 345 When the initiating side receives the Resv message, it completes any 346 pending OAM configuration and enables the OAM source function to send 347 OAM messages. 349 After this exchange, OAM entities are established and configured for 350 the LSP and OAM messages are exchanged. OAM alarms can now be 351 enabled. The initiator, during the period when OAM alarms are 352 disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS 353 flag set. The receiving node enables the OAM alarms after processing 354 the Path message. The initiator enables OAM alarms after it receives 355 the Resv message. Data plane OAM is now fully functional. 357 3.2. Adjustment of OAM Parameters 359 There may be a need to change the parameters of an already 360 established and configured OAM function during the lifetime of the 361 LSP. To do so the LSP needs to be re-signaled with the updated 362 parameters. OAM parameters influence the content and timing of OAM 363 messages and identify the way OAM defects and alarms are derived and 364 generated. Hence, to avoid spurious alarms, it is important that 365 both sides, OAM sink and source, are updated in a synchronized way. 366 First, the alarms of the OAM sink function should be suppressed and 367 only then should expected OAM parameters be adjusted. Subsequently, 368 the parameters of the OAM source function can be updated. Finally, 369 the alarms of the OAM sink side can be enabled again. 371 In accordance with the above operation, the LSP MUST first be re- 372 signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared, 373 including the updated OAM Configuration TLV corresponding to the new 374 parameter settings. The initiator MUST keep its OAM sink and source 375 functions running unmodified, but it MUST suppress OAM alarms after 376 the updated Path message is sent. The receiver MUST first disable 377 all OAM alarms, then update the OAM parameters according to the 378 information in the Path message and reply with a Resv message 379 acknowledging the changes by including the OAM Configuration TLV. 380 Note that the receiving side has the possibility to adjust the 381 requested OAM configuration parameters and reply with an updated OAM 382 Configuration TLV in the Resv message, reflecting the actually 383 configured values. However, in order to avoid an extensive 384 negotiation phase, in the case of adjusting already configured OAM 385 functions, the receiving side SHOULD NOT update the parameters 386 requested in the Path message to an extent that would provide lower 387 performance (e.g., lower frequency of monitoring packets) than what 388 has been in operation previously. 390 The initiator MUST only update its OAM sink and source functions 391 after it received the Resv message. After this Path/Resv message 392 exchange (in both unidirectional and bidirectional LSP cases) the OAM 393 parameters are updated and OAM is running according the new parameter 394 settings. However, OAM alarms are still disabled. A subsequent 395 Path/Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS 396 flag set is needed to enable OAM alarms again. 398 3.3. Deleting OAM Entities 400 In some cases it may be useful to remove some or all OAM entities and 401 functions from an LSP without actually tearing down the connection. 403 To avoid any spurious alarms, first the LSP MUST be re-signaled with 404 "OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM 405 configuration. Subsequently, the LSP is re-signaled with "OAM MEP 406 Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags 407 cleared, and without the OAM Configuration TLV, this MUST result in 408 the deletion of all OAM entities associated with the LSP. All 409 control and data plane resources in use by the OAM entities and 410 functions SHOULD be freed up. Alternatively, if only some OAM 411 functions need to be removed, the LSP is re-signaled with the updated 412 OAM Configuration TLV. Changes between the contents of the 413 previously signaled OAM Configuration TLV and the currently received 414 TLV represent which functions MUST be removed/added. 416 OAM source functions MUST be deleted first and only after the "OAM 417 Alarms Disabled" can the associated OAM sink functions be removed, 418 this will ensure that OAM messages do not leak outside the LSP. To 419 this end the initiator, before sending the Path message, MUST remove 420 the OAM source, hence terminating the OAM message flow associated to 421 the downstream direction. In the case of a bidirectional connection, 422 it MUST leave in place the OAM sink functions associated to the 423 upstream direction. The remote end, after receiving the Path 424 message, MUST remove all associated OAM entities and functions and 425 reply with a Resv message without an OAM Configuration TLV. The 426 initiator completely removes OAM entities and functions after the 427 Resv message arrived. 429 4. RSVP-TE Extensions 431 4.1. LSP Attributes Flags 433 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 434 indicate options and attributes of the LSP. The Flags field has 8 435 bits and hence is limited to differentiate only 8 options. [RFC5420] 436 defines new objects for RSVP-TE messages to allow the signaling of 437 arbitrary attribute parameters making RSVP-TE easily extensible to 438 support new applications. Furthermore, [RFC5420] allows options and 439 attributes that do not need to be acted on by all Label Switched 440 Routers (LSRs) along the path of the LSP. In particular, these 441 options and attributes may apply only to key LSRs on the path such as 442 the ingress LSR and egress LSR. Options and attributes can be 443 signaled transparently, and only examined at those points that need 444 to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES 445 objects are defined in [RFC5420] to provide means to signal LSP 446 attributes and options in the form of TLVs. Options and attributes 447 signaled in the LSP_ATTRIBUTES object can be passed transparently 448 through LSRs not supporting a particular option or attribute, while 449 the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined 450 and processed by each LSR. One TLV is defined in [RFC5420]: the 451 Attributes Flags TLV. 453 One bit (IANA to assign): "OAM MEP entities desired" is allocated in 454 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. 455 If the "OAM MEP entities desired" bit is set it is indicating that 456 the establishment of OAM MEP entities are required at the endpoints 457 of the signaled LSP. If the establishment of MEPs is not supported 458 an error MUST be generated: "OAM Problem/MEP establishment not 459 supported". 461 If the "OAM MEP entities desired" bit is set and additional 462 parameters need to be configured, an OAM Configuration TLV MAY be 463 included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. 465 One bit (IANA to assign): "OAM MIP entities desired" is allocated in 466 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or 467 LSP_REQUIRED_ATTRIBUES objects. This bit MUST only be set if the 468 "OAM MEP entities desired" bit is set. If the "OAM MIP entities 469 desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the 470 LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the 471 establishment of OAM MIP entities is required at every transit node 472 of the signaled LSP. If the establishment of a MIP is not supported 473 an error MUST be generated: "OAM Problem/MIP establishment not 474 supported". 476 4.2. OAM Configuration TLV 478 This TLV provides information about which OAM technology/method 479 should be used and carries sub-TLVs for any additional OAM 480 configuration information. The OAM Configuration TLV MAY be carried 481 in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and 482 Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, 483 it is indicating that intermediate nodes MUST recognize and react on 484 the OAM configuration information. 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type (IANA) | Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | OAM Type | Reserved | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | 494 ~ sub-TLVs ~ 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Type: indicates a new type: the OAM Configuration TLV (3) (IANA to 499 assign). 501 OAM Type: specifies the technology specific OAM method. When carried 502 in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is 503 not supported at any given node an error MUST be generated: "OAM 504 Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES 505 Object, intermediate nodes not supporting the OAM Type pass the 506 object forward unchanged as specified in [RFC5420], and only Label 507 Edge Nodes MUST generate an error if the OAM Type is not supported at 508 the LSP end-point. 510 OAM Type Description 511 ------------ -------------------- 512 0-255 Reserved 514 This document defines no types. IANA is requested to maintain the 515 values in a new "RSVP-TE OAM Configuration Registry". 517 The receiving node, based on the OAM Type, will check if a 518 corresponding technology specific OAM configuration sub-TLV is 519 included in the OAM Configuration TLV. If the included technology 520 specific OAM configuration sub-TLV is different from what is 521 specified in the OAM Type an error MUST be generated: "OAM Problem/ 522 OAM Type Mismatch". IANA is requested to maintain the sub-TLV space 523 in the new "RSVP-TE OAM Configuration Registry". 525 Sub-TLV Type Description 526 ------------ ------------------------------------ 527 0 Reserved 528 1 OAM Function Flags Sub-TLV 529 2-31 Reserved for generic Sub-TLVs 530 32- Reserved for technology specific Sub-TLVs 532 Note that there is a hierarchical dependency between the OAM 533 configuration elements. First, the "OAM MEP entities desired" flag 534 needs to be set. Only when that flag is set MAY an "OAM 535 Configuration TLV" be included in the LSP_ATTRIBUTES or 536 LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on 537 the "OAM Type" field, it MAY carry a technology specific OAM 538 configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP 539 entities desired" flag is not set but an OAM Configuration TLV is 540 present) an error MUST be generated: "OAM Problem/Configuration 541 Error". 543 4.2.1. OAM Function Flags Sub-TLV 545 As the first sub-TLV the "OAM Function Flags Sub-TLV" MUST always be 546 included in the "OAM Configuration TLV". "OAM Function Flags" 547 specifies which pro-active OAM functions (e.g., connectivity 548 monitoring, loss and delay measurement) and which fault management 549 signals MUST be established and configured. If the selected OAM 550 Function(s) is(are) not supported, an error MUST be generated: "OAM 551 Problem/Unsupported OAM Function". 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Type (1) (IANA) | Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | 559 ~ OAM Function Flags ~ 560 | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 OAM Function Flags is bitmap with extensible length based on the 564 Length field of the TLV. Bits are numbered from left to right. IANA 565 is requested to maintain the OAM Function Flags in the new "RSVP-TE 566 OAM Configuration Registry". This document defines the following 567 flags. 569 OAM Function Flag bit# Description 570 --------------------- --------------------------- 571 0 Continuity Check (CC) 572 1 Connectivity Verification (CV) 573 2 Fault Management Signal (FMS) 574 3 Performance Monitoring/Loss (PM/Loss) 575 4 Performance Monitoring/Delay (PM/Delay) 576 5 Performance Monitoring/Throughput Measurement 577 (PM/Throughput) 579 4.2.2. Technology Specific Sub-TLVs 581 One technology specific sub-TLV MAY be defined for each "OAM Type". 582 This sub-TLV MUST contain any further OAM configuration information 583 for that specific "OAM Type". The technology specific sub-TLV, when 584 used, MUST be carried within the OAM Configuration TLV. IANA is 585 requested to maintain the OAM technology specific sub-TLV space in 586 the new "RSVP-TE OAM Configuration Registry". 588 4.3. Administrative Status Information 590 Administrative Status Information is carried in the ADMIN_STATUS 591 Object. The Administrative Status Information is described in 592 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 593 [RFC3473]. 595 Two bits are allocated for the administrative control of OAM 596 monitoring. Two bits (IANA to assign) are allocated by this draft: 597 the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When 598 the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is 599 cleared, no OAM packets are emitted. When the "OAM Alarms Enabled" 600 bit is set OAM triggered alarms are enabled and associated consequent 601 actions are executed including the notification to the management 602 system. When this bit is cleared, alarms are suppressed and no 603 action is executed and the management system is not notified. 605 4.4. Handling OAM Configuration Errors 607 To handle OAM configuration errors, a new Error Code (IANA to assign) 608 "OAM Problem" is introduced. To refer to specific problems, a set of 609 Error Values are defined under the "OAM Problem" error code. 611 If a node does not support the establishment of OAM MEP or MIP 612 entities it MUST use the error value: "MEP establishment not 613 supported" or "MIP establishment not supported" respectively in the 614 PathErr message. 616 If a node does not support a specific OAM technology/solution it MUST 617 use the error value: "Unsupported OAM Type" in the PathErr message. 619 If a different technology specific OAM configuration TLV is included 620 than what was specified in the OAM Type an error MUST be generated 621 with error value: "OAM Type Mismatch" in the PathErr message. 623 There is a hierarchy between the OAM configuration elements. If this 624 hierarchy is broken, the error value: "Configuration Error" MUST be 625 used in the PathErr message. 627 If a node does not support a specific OAM Function, it MUST use the 628 error value: "Unsupported OAM Function" in the PathErr message. 630 4.5. Considerations on Point-to-Multipoint OAM Configuration 632 RSVP-TE extensions for the establishment of point-to-multipoint 633 (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of 634 multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set 635 up between the ingress and egress LSRs, and are appropriately 636 combined by the branch LSRs using RSVP semantics to result in a P2MP 637 TE LSP. One Path message may signal one or multiple S2L sub-LSPs for 638 a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP 639 can be signaled using one Path message or split across multiple Path 640 messages. 642 P2MP OAM mechanisms are very specific to the data plane technology, 643 therefore in this document, we only highlight the basic principles of 644 P2MP OAM configuration. We consider only the root to leaf OAM flows, 645 and as such, aspects of the configuration of return paths are outside 646 the scope of our discussions. We also limit our consideration to the 647 case where all leaves must successfully establish OAM entities with 648 identical configuration in order the P2MP OAM is successfully 649 established. In any case, the discussion set forth below provides 650 only guidelines for P2MP OAM configuration, details will be specified 651 in technology specific documents. 653 The root node may use a single Path message or multiple Path messages 654 to setup the whole P2MP tree. In the case when multiple Path 655 messages are used, the root node is responsible to keep the OAM 656 Configuration information consistent in each of the sent Path 657 messages, i.e., the same information MUST be included in all Path 658 messages used to construct the multicast tree. Each branching node 659 will propagate the Path message downstream on each of the branches, 660 when constructing a Path message the OAM Configuration information 661 MUST be copied unchanged from the received Path message, including 662 the related ADMIN_STATUS bits, LSP Attribute Flags and the OAM 663 Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES 664 and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for the upstream 665 Path message to the subsequent downstream Path messages. 667 Leaves MUST create and configure OAM sink functions according to the 668 parameters received in the Path message, for P2MP OAM configuration 669 there is no possibility for parameter negotiation on a per leaf 670 basis. This is due to the fact that the OAM source function, 671 residing in the root of the tree, will operate with a single 672 configuration, which then must be obeyed by all leaves. If a leaf 673 cannot accept the OAM parameters it MUST use the RRO Attributes sub- 674 object [RFC5420] to notify the root about the problem. In 675 particular, if the OAM configuration was successful, the leaf would 676 set the "OAM MEP entities desired" flag in the RRO Attributes sub- 677 object in the Resv message. On the other hand, if OAM entities could 678 not be established the Resv message should be sent with the "OAM MEP 679 entities desired" bit cleared in the RRO Attributes sub-object. 680 Branching nodes should collect and merge the received RROs according 681 to the procedures described in [RFC4875]. This way, the root when 682 receiving the Resv message (or messages if multiple Path messages 683 were used to set up the tree) will have a clear information about 684 which of the leaves could establish the OAM functions. If all leaves 685 established OAM entities successfully, the root can enable the OAM 686 message flow. On the other hand, if at some leaves the establishment 687 was unsuccessful additional actions will be needed before the OAM 688 message flow can be enabled. Such action could be to setup two 689 independent P2MP LSPs. One LSP with OAM Configuration information 690 towards leaves which could successfully setup the OAM function. This 691 can be done by pruning the leaves which failed to setup OAM of the 692 previously signaled P2MP LSP. The other P2MP LSP could be 693 constructed for leaves without OAM entities. The exact procedures 694 will be described in technology specific documents. 696 5. IANA Considerations 698 Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs 699 to be allocated in the ADMIN_STATUS Object. 701 Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") 702 needs to be allocated in the LSP Attributes Flags Registry. 704 This document specifies one new TLV to be carried in the 705 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv 706 messages: OAM Configuration TLV. 708 One new Error Code: "OAM Problem" and a set of new values: "MEP 709 establishment not supported", "MIP establishment not supported", 710 "Unsupported OAM Type", "Configuration Error", "OAM Type Mismatch" 711 and "Unsupported OAM Function" needs to be assigned. 713 IANA is requested to open a new registry: "RSVP-TE OAM Configuration 714 Registry" that maintains the "OAM Type" code points, an associated 715 sub-TLV space, and the allocations of "OAM Function Flags" within the 716 OAM Configuration TLV. 718 RSVP-TE OAM Configuration Registry 720 OAM Type Description 721 ------------ ------------------ 722 0-255 Reserved 724 Sub-TLV Type Description 725 ------------ ------------------------------------ 726 0 Reserved 727 1 OAM Function Flags Sub-TLV 728 2-31 Reserved for generic Sub-TLVs 729 32- Reserved for technology specific Sub-TLVs 731 OAM Function Flag bit# Description 732 ---------------------- ------------------------------- 733 0 Continuity Check (CC) 734 1 Connectivity Verification (CV) 735 2 Fault Management Signal (FMS) 736 3 Performance Monitoring/Loss (PM/Loss) 737 4 Performance Monitoring/Delay (PM/Delay) 738 5 Performance Monitoring/Throughput Measurement 739 (PM/Throughput) 740 6- Reserved 742 6. Security Considerations 744 The signaling of OAM related parameters and the automatic 745 establishment of OAM entities based on RSVP-TE messages adds a new 746 aspect to the security considerations discussed in [RFC3473]. In 747 particular, a network element could be overloaded, if a remote 748 attacker could request liveliness monitoring, with frequent periodic 749 messages, for a high number of LSPs, targeting a single network 750 element. Such an attack can efficiently be prevented when mechanisms 751 for message integrity and node authentication are deployed. Since 752 the OAM configuration extensions rely on the hop-by-hop exchange of 753 exiting RSVP-TE messages, procedures specified for RSVP message 754 security in [RFC2747] can be used to mitigate possible attacks. 756 For a more comprehensive discussion on GMPLS security, please see the 757 Security Framework for MPLS and GMPLS Networks [RFC5920]. 758 Cryptography can be used to protect against many attacks described in 759 [RFC5920]. 761 7. Acknowledgements 763 The authors would like to thank Francesco Fondelli, Adrian Farrel, 764 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 765 comments. 767 8. References 769 8.1. Normative References 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", BCP 14, RFC 2119, March 1997. 774 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 775 (GMPLS) Signaling Functional Description", RFC 3471, 776 January 2003. 778 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 779 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 780 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 782 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 783 Ayyangarps, "Encoding of Attributes for MPLS LSP 784 Establishment Using Resource Reservation Protocol Traffic 785 Engineering (RSVP-TE)", RFC 5420, February 2009. 787 8.2. Informative References 789 [IEEE.802.1Q-2011] 790 IEEE, "IEEE Standard for Local and metropolitan area 791 networks -- Media Access Control (MAC) Bridges and Virtual 792 Bridged Local Area Networks", IEEE Std 802.1Q, 2011. 794 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 795 Authentication", RFC 2747, January 2000. 797 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 798 Matsushima, "Operations and Management (OAM) Requirements 799 for Multi-Protocol Label Switched (MPLS) Networks", 800 RFC 4377, February 2006. 802 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 803 Label Switched (MPLS) Data Plane Failures", RFC 4379, 804 February 2006. 806 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 807 "Extensions to Resource Reservation Protocol - Traffic 808 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 809 Switched Paths (LSPs)", RFC 4875, May 2007. 811 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 812 and S. Ueno, "Requirements of an MPLS Transport Profile", 813 RFC 5654, September 2009. 815 [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized 816 Multiprotocol Label Switching (GMPLS) Ethernet Label 817 Switching Architecture and Framework", RFC 5828, 818 March 2010. 820 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 821 Operations, Administration, and Maintenance (OAM) in MPLS 822 Transport Networks", RFC 5860, May 2010. 824 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 825 Networks", RFC 5920, July 2010. 827 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 828 Berger, "A Framework for MPLS in Transport Networks", 829 RFC 5921, July 2010. 831 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 832 "Generalized Multiprotocol Label Switching (GMPLS) Control 833 of Ethernet Provider Backbone Traffic Engineering 834 (PBB-TE)", RFC 6060, March 2011. 836 Authors' Addresses 838 Attila Takacs 839 Ericsson 840 Konyves Kalman krt. 11. 841 Budapest, 1097 842 Hungary 844 Email: attila.takacs@ericsson.com 846 Don Fedyk 847 Alcatel-Lucent 848 Groton, MA 01450 849 USA 851 Email: donald.fedyk@alcatel-lucent.com 853 Jia He 854 Huawei 856 Email: hejia@huawei.com