idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2013) is 4111 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Takacs 3 Internet-Draft Ericsson 4 Intended status: Standards Track D. Fedyk 5 Expires: July 26, 2013 Alcatel-Lucent 6 J. He 7 Huawei 8 January 22, 2013 10 GMPLS RSVP-TE extensions for OAM Configuration 11 draft-ietf-ccamp-oam-configuration-fwk-09 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 July 26, 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 . . . . . . . . . . . . 13 77 4.5. Considerations on Point-to-Multipoint OAM Configuration . 14 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 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. 128 This document describes requirements for OAM configuration and 129 control via RSVP-TE. Extensions to the RSVP-TE protocol are 130 specified providing a framework to configure and control OAM entities 131 along with the capability to carry technology specific information. 132 Extensions can be grouped into: generic elements that are applicable 133 to any OAM solution; and technology specific elements that provide 134 additional configuration parameters, which may only be needed for a 135 specific OAM technology. This document specifies the technology 136 agnostic elements and specifies the way additional technology 137 specific OAM parameters are provided. 139 This document addresses end-to-end OAM configuration, that is, the 140 setup of OAM entities bound to an end-to-end LSP, and configuration 141 and control of OAM functions running end-to-end in the LSP. 142 Configuration of OAM entities for LSP segments and tandem connections 143 are out of the scope of this document. 145 The mechanisms described in this document provide an additional 146 option for bootstrapping OAM that is not intended to replace or 147 deprecate the use of other technology specific OAM bootstrapping 148 techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The 149 procedures specified in this document are intended only for use in 150 environments where RSVP-TE signaling is used to set up the LSPs that 151 are to be monitored using OAM. 153 2. Requirements 155 This section summarizes various technology-specific OAM requirements 156 which can be used as a basis for an OAM configuration framework. 158 MPLS OAM requirements are described in [RFC4377], which provides 159 requirements to create consistent OAM functionality for MPLS 160 networks. The following list is an excerpt of MPLS OAM requirements 161 documented in [RFC4377] that bear a direct relevance to the 162 discussion set forth in this document. 164 o It is desired to support the automation of LSP defect detection. 165 It is especially important in cases where large numbers of LSPs 166 might be tested. 168 o In particular some LSPs may require automated ingress-LSR to 169 egress-LSR testing functionality, while others may not. 171 o Mechanisms are required to coordinate network responses to 172 defects. Such mechanisms may include alarm suppression, 173 translating defect signals at technology boundaries, and 174 synchronizing defect detection times by setting appropriately 175 bounded detection time frames. 177 MPLS-TP defines a profile of MPLS targeted at transport applications 178 [RFC5921]. This profile specifies the specific MPLS characteristics 179 and extensions required to meet transport requirements, including 180 providing additional OAM, survivability, and other maintenance 181 functions not currently supported by MPLS. Specific OAM requirements 182 for MPLS-TP are specified in [RFC5654] and [RFC5860]. MPLS-TP poses 183 the following requirements on the control plane to configure and 184 control OAM entities: 186 o From [RFC5860]: OAM functions MUST operate and be configurable 187 even in the absence of a control plane. Conversely, it SHOULD be 188 possible to configure as well as enable/disable the capability to 189 operate OAM functions as part of connectivity management, and it 190 SHOULD also be possible to configure as well as enable/disable the 191 capability to operate OAM functions after connectivity has been 192 established. 194 o From [RFC5654]: The MPLS-TP control plane MUST support the 195 configuration and modification of OAM maintenance points as well 196 as the activation/ deactivation of OAM when the transport path or 197 transport service is established or modified. 199 Ethernet Connectivity Fault Management (CFM) defines an adjunct 200 connectivity monitoring OAM flow to check the liveliness of Ethernet 201 networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011] Ethernet 202 networks support explicitly-routed Ethernet connections. CFM can be 203 used to track the liveliness of PBB-TE connections and detect data 204 plane failures. In IETF, the GMPLS controlled Ethernet Label 205 Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the 206 GMPLS control plane to support the establishment of PBB-TE data plane 207 connections. Without control plane support, separate management 208 commands would be needed to configure and start CFM. 210 GMPLS based OAM configuration and control, needs to provide a general 211 framework to be applicable to a wide range of data plane technologies 212 and OAM solutions. There are three typical data plane technologies 213 used for transport applications: wavelength based such as WSON, TDM 214 based such as SDH/SONET, and packet based such as MPLS-TP [RFC5921] 215 and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes, 216 the operator MUST be able to configure and control the following OAM 217 functions: 219 o It MUST be possible to explicitly request the setup of OAM 220 entities for the signaled LSP and provide specific information for 221 the setup if this is required by the technology. 223 o Control of alarms is important to avoid false alarm indications 224 and reporting to the management system. It MUST be possible to 225 enable/disable alarms generated by OAM functions. In some cases, 226 selective alarm control may be desirable when, for instance, the 227 operator is only concerned about critical alarms. Therefore the 228 non-service affecting alarms should be inhibited. 230 o When periodic messages are used for liveliness check (continuity 231 check) of LSPs, it MUST be possible to set the frequency of 232 messages. This allows proper configuration for fulfilling the 233 requirements of the service and/or meeting the detection time 234 boundaries posed by possible congruent connectivity check 235 operations of higher layer applications. For a network operator 236 to be able to balance the trade-off between fast failure detection 237 and data overhead, it is beneficial to configure the frequency of 238 continuity check messages on a per LSP basis. 240 o Pro-active Performance Monitoring (PM) functions are used to 241 continuously collect information about specific characteristics of 242 the connection. For consistent measurement of Service Level 243 Agreements (SLAs), it MUST be possible to set common configuration 244 parameters for the LSP. 246 o The extensions MUST allow the operator to use only a minimal set 247 of OAM configuration and control features if supported by the OAM 248 solution or network management policy. Generic OAM parameters and 249 data plane or OAM technology specific parameters MUST be 250 supported. 252 3. RSVP-TE based OAM Configuration 254 In general, two types of Maintenance Points (MPs) can be 255 distinguished: Maintenance End Points (MEPs) and Maintenance 256 Intermediate Points (MIPs). MEPs reside at the ends of an LSP and 257 are capable of initiating and terminating OAM messages for Fault 258 Management (FM) and Performance Monitoring (PM). MIPs on the other 259 hand, are located at transit nodes of an LSP and are capable of 260 reacting to some OAM messages but otherwise do not initiate messages. 261 Maintenance Entity (ME) refers to an association of MEPs and MIPs 262 that are provisioned to monitor an LSP. The ME association is 263 achieved by configuring MPs to belong to the same ME. 265 When an LSP is signaled, a forwarding association is established 266 between endpoints and transit nodes via label bindings. This 267 association creates a context for the OAM entities monitoring the 268 LSP. On top of this association, OAM entities may be configured to 269 unambiguously identify MPs and MEs. 271 In addition to MP and ME identification parameters, pro-active OAM 272 functions (e.g., Continuity Check (CC) and Performance Monitoring 273 (PM)) may have additional parameters that require configuration as 274 well. In particular, the frequency of periodic CC packets and the 275 measurement interval for loss and delay measurements may need to be 276 configured. 278 The above parameters may be either derived from LSP provisioning 279 information, or alternatively, pre-configured default values can be 280 used. In the simplest case, the control plane provides information 281 on whether or not OAM entities need to be setup for the signaled LSP. 282 If OAM entities are created, control plane signaling must also 283 provide a means to activate/deactivate OAM message flows and 284 associated alarms. 286 OAM identifiers, as well as the configuration of OAM functions, are 287 technology specific (i.e., vary depending on the data plane 288 technology and the chosen OAM solution). In addition, for any given 289 data plane technology, a set of OAM solutions may be applicable. 290 Therefore, the OAM configuration framework allows selecting a 291 specific OAM solution to be used for the signaled LSP and provides 292 means to carry detailed OAM configuration information in technology 293 specific TLVs. 295 3.1. Establishment of OAM Entities and Functions 297 In order to avoid spurious alarms, OAM functions should be setup and 298 enabled in the appropriate order. When using the GMPLS control 299 plane, establishment and enabling of OAM functions MUST be bound to 300 RSVP-TE message exchanges. 302 An LSP may be signaled and established without OAM configuration 303 first, and OAM entities may be added later with a subsequent re- 304 signaling of the LSP. Alternatively, the LSP may be setup with OAM 305 entities with the first signaling of the LSP. The below procedures 306 apply to both cases. 308 Before the initiating a Path message with OAM Configuration 309 information, an initiating node MUST establish and configure the 310 corresponding OAM entities locally. But until the LSP is 311 established, OAM source functions MUST NOT start sending any OAM 312 messages. In the case of bidirectional connections, in addition to 313 the OAM source function, the initiator node MUST set up the OAM sink 314 function and prepare it to receive OAM messages. During this time 315 the OAM alarms MUST be suppressed (e.g., due to missing or 316 unidentified OAM messages). To achieve OAM alarm suppression, Path 317 message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag 318 cleared. 320 When the Path message arrives at the receiver, the remote end MUST 321 establish and configure OAM entities according to the OAM information 322 provided in the Path message. If this is not possible, a PathErr 323 SHOULD be sent and neither the OAM entities nor the LSP SHOULD be 324 established. If OAM entities are established successfully, the OAM 325 sink function MUST be prepared to receive OAM messages, but MUST NOT 326 generate any OAM alarms (e.g., due to missing or unidentified OAM 327 messages). In the case of bidirectional connections, in addition to 328 the OAM sink function, an OAM source function MUST be set up and, 329 according to the requested configuration, the OAM source function 330 MUST start sending OAM messages. Then a Resv message is sent back, 331 including the OAM Configuration TLV that corresponds to the actually 332 established and configured OAM entities and functions. Depending on 333 the OAM technology, some elements of the OAM Configuration TLV MAY be 334 updated/changed; i.e., if the remote end is not supporting a certain 335 OAM configuration it may suggest an alternative setting, which may or 336 may not be accepted by the initiator of the Path message. If it is 337 accepted, the initiator will reconfigure its OAM functions according 338 to the information received in the Resv message. If the alternate 339 setting is not acceptable a ResvErr may be sent tearing down the LSP. 340 Details of this operation are technology specific and should be 341 described in accompanying technology specific documents. 343 When the initiating side receives the Resv message, it completes any 344 pending OAM configuration and enables the OAM source function to send 345 OAM messages. 347 After this exchange, OAM entities are established and configured for 348 the LSP and OAM messages are exchanged. OAM alarms can now be 349 enabled. The initiator, during the period when OAM alarms are 350 disabled, sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS 351 flag set. The receiving node enables the OAM alarms after processing 352 the Path message. The initiator enables OAM alarms after it receives 353 the Resv message. Data plane OAM is now fully functional. 355 3.2. Adjustment of OAM Parameters 357 There may be a need to change the parameters of an already 358 established and configured OAM function during the lifetime of the 359 LSP. To do so the LSP needs to be re-signaled with the updated 360 parameters. OAM parameters influence the content and timing of OAM 361 messages and identify the way OAM defects and alarms are derived and 362 generated. Hence, to avoid spurious alarms, it is important that 363 both sides, OAM sink and source, are updated in a synchronized way. 364 First, the alarms of the OAM sink function should be suppressed and 365 only then should expected OAM parameters be adjusted. Subsequently, 366 the parameters of the OAM source function can be updated. Finally, 367 the alarms of the OAM sink side can be enabled again. 369 In accordance with the above operation, the LSP MUST first be re- 370 signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared, 371 including the updated OAM Configuration TLV corresponding to the new 372 parameter settings. The initiator MUST keep its OAM sink and source 373 functions running unmodified, but it MUST suppress OAM alarms after 374 the updated Path message is sent. The receiver MUST first disable 375 all OAM alarms, then update the OAM parameters according to the 376 information in the Path message and reply with a Resv message 377 acknowledging the changes by including the OAM Configuration TLV. 378 Note that the receiving side has the possibility to adjust the 379 requested OAM configuration parameters and reply with an updated OAM 380 Configuration TLV in the Resv message, reflecting the actually 381 configured values. However, in order to avoid an extensive 382 negotiation phase, in the case of adjusting already configured OAM 383 functions, the receiving side SHOULD NOT update the parameters 384 requested in the Path message to an extent that would provide lower 385 performance (e.g., lower frequency of monitoring packets) than what 386 has been in operation previously. 388 The initiator MUST only update its OAM sink and source functions 389 after it received the Resv message. After this Path/Resv message 390 exchange (in both unidirectional and bidirectional LSP cases) the OAM 391 parameters are updated and OAM is running according the new parameter 392 settings. However, OAM alarms are still disabled. A subsequent 393 Path/Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS 394 flag set is needed to enable OAM alarms again. 396 3.3. Deleting OAM Entities 398 In some cases it may be useful to remove some or all OAM entities and 399 functions from an LSP without actually tearing down the connection. 401 To avoid any spurious alarms, first the LSP MUST be re-signaled with 402 "OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM 403 configuration. Subsequently, the LSP is re-signaled with "OAM MEP 404 Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags 405 cleared, and without the OAM Configuration TLV, this MUST result in 406 the deletion of all OAM entities associated with the LSP. All 407 control and data plane resources in use by the OAM entities and 408 functions SHOULD be freed up. Alternatively, if only some OAM 409 functions need to be removed, the LSP is re-signaled with the updated 410 OAM Configuration TLV. Changes between the contents of the 411 previously signaled OAM Configuration TLV and the currently received 412 TLV represent which functions MUST be removed/added. 414 OAM source functions MUST be deleted first and only after the "OAM 415 Alarms Disabled" can the associated OAM sink functions be removed, 416 this will ensure that OAM messages do not leak outside the LSP. To 417 this end the initiator, before sending the Path message, MUST remove 418 the OAM source, hence terminating the OAM message flow associated to 419 the downstream direction. In the case of a bidirectional connection, 420 it MUST leave in place the OAM sink functions associated to the 421 upstream direction. The remote end, after receiving the Path 422 message, MUST remove all associated OAM entities and functions and 423 reply with a Resv message without an OAM Configuration TLV. The 424 initiator completely removes OAM entities and functions after the 425 Resv message arrived. 427 4. RSVP-TE Extensions 429 4.1. LSP Attributes Flags 431 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 432 indicate options and attributes of the LSP. The Flags field has 8 433 bits and hence is limited to differentiate only 8 options. [RFC5420] 434 defines new objects for RSVP-TE messages to allow the signaling of 435 arbitrary attribute parameters making RSVP-TE easily extensible to 436 support new applications. Furthermore, [RFC5420] allows options and 437 attributes that do not need to be acted on by all Label Switched 438 Routers (LSRs) along the path of the LSP. In particular, these 439 options and attributes may apply only to key LSRs on the path such as 440 the ingress LSR and egress LSR. Options and attributes can be 441 signaled transparently, and only examined at those points that need 442 to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES 443 objects are defined in [RFC5420] to provide means to signal LSP 444 attributes and options in the form of TLVs. Options and attributes 445 signaled in the LSP_ATTRIBUTES object can be passed transparently 446 through LSRs not supporting a particular option or attribute, while 447 the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined 448 and processed by each LSR. One TLV is defined in [RFC5420]: the 449 Attributes Flags TLV. 451 One bit (IANA to assign): "OAM MEP entities desired" is allocated in 452 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. 453 If the "OAM MEP entities desired" bit is set it is indicating that 454 the establishment of OAM MEP entities are required at the endpoints 455 of the signaled LSP. If the establishment of MEPs is not supported 456 an error must be generated: "OAM Problem/MEP establishment not 457 supported". 459 If the "OAM MEP entities desired" bit is set and additional 460 parameters need to be configured, an OAM Configuration TLV MAY be 461 included in the LSP_ATTRIBUTES Object. 463 One bit (IANA to assign): "OAM MIP entities desired" is allocated in 464 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or 465 LSP_REQUIRED_ATTRIBUES objects. This bit can only be set if the "OAM 466 MEP entities desired" bit is set. If the "OAM MIP entities desired" 467 bit is set in the LSP_ATTRIBUTES Flags TLV in the 468 LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the 469 establishment of OAM MIP entities is required at every transit node 470 of the signaled LSP. If the establishment of a MIP is not supported 471 an error MUST be generated: "OAM Problem/MIP establishment not 472 supported". 474 4.2. OAM Configuration TLV 476 This TLV provides information about which OAM technology/method 477 should be used and carries sub-TLVs for any additional OAM 478 configuration information. The OAM Configuration TLV MAY be carried 479 in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and 480 Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, 481 it is indicating that intermediate nodes MUST recognize and 482 eventually react on the OAM configuration information. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type (IANA) | Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | OAM Type | Reserved | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 ~ sub-TLVs ~ 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Type: indicates a new type: the OAM Configuration TLV (3) (IANA to 497 assign). 499 OAM Type: specifies the technology specific OAM method. When carried 500 in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is 501 not supported at any given node an error MUST be generated: "OAM 502 Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES 503 Object, intermediate nodes not supporting the OAM Type pass the 504 object forward unchanged as specified in [RFC5420], and only Label 505 Edge Nodes MUST generate an error if the OAM Type is not supported at 506 the LSP end-point. 508 OAM Type Description 509 ------------ -------------------- 510 0-255 Reserved 512 This document defines no types. IANA is requested to maintain the 513 values in a new "RSVP-TE OAM Configuration Registry". 515 The receiving node, based on the OAM Type, will check if a 516 corresponding technology specific OAM configuration sub-TLV is 517 included in the OAM Configuration TLV. If the included technology 518 specific OAM configuration sub-TLV is different from what is 519 specified in the OAM Type an error MUST be generated: "OAM Problem/ 520 OAM Type Mismatch". IANA is requested to maintain the sub-TLV space 521 in the new "RSVP-TE OAM Configuration Registry". 523 Note that there is a hierarchical dependency in between the OAM 524 configuration elements. First, the "OAM MEP entities desired" flag 525 needs to be set. Only when that flag is set MAY an "OAM 526 Configuration TLV" be included in the LSP_ATTRIBUTES or 527 LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on 528 the "OAM Type" field, it MAY carry a technology specific OAM 529 configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP 530 entities desired" flag is not set but an OAM Configuration TLV is 531 present) an error MUST be generated: "OAM Problem/Configuration 532 Error". 534 4.2.1. OAM Function Flags Sub-TLV 536 As the first sub-TLV the "OAM Function Flags sub-TLV" MUST always be 537 included in the "OAM Configuration TLV". "OAM Function Flags" 538 specifies which pro-active OAM functions (e.g., connectivity 539 monitoring, loss and delay measurement) and which fault management 540 signals MUST be established and configured. If the selected OAM 541 Function(s) is(are) not supported, an error MUST be generated: "OAM 542 Problem/Unsupported OAM Function". 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type (1) (IANA) | Length | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | | 550 ~ OAM Function Flags ~ 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 OAM Function Flags is bitmap with extensible length based on the 555 Length field of the TLV. Bits are numbered from left to right. IANA 556 is requested to maintain the OAM Function Flags in the new "RSVP-TE 557 OAM Configuration Registry". This document defines the following 558 flags. 560 OAM Function Flag bit# Description 561 --------------------- --------------------------- 562 0 Continuity Check (CC) 563 1 Connectivity Verification (CV) 564 2 Fault Monitoring Signal (FMS) 565 3 Performance Monitoring/Loss (PM/Loss) 566 4 Performance Monitoring/Delay (PM/Delay) 567 5 Performance Monitoring/Throughput Measurement 568 (PM/Throughput) 570 4.2.2. Technology Specific sub-TLVs 572 One technology specific sub-TLV MAY be defined for each "OAM Type". 573 This sub-TLV MUST contain any further OAM configuration information 574 for that specific "OAM Type". The technology specific sub-TLV, when 575 used, MUST be carried within the OAM Configuration TLV. IANA is 576 requested to maintain the OAM technology specific sub-TLV space in 577 the new "RSVP-TE OAM Configuration Registry". 579 4.3. Administrative Status Information 581 Administrative Status Information is carried in the ADMIN_STATUS 582 Object. The Administrative Status Information is described in 583 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 584 [RFC3473]. 586 Two bits are allocated for the administrative control of OAM 587 monitoring. Two bits (IANA to assign) are allocated by this draft: 588 the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When 589 the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is 590 cleared, no OAM packets are emitted. When the "OAM Alarms Enabled" 591 bit is set OAM triggered alarms are enabled and associated consequent 592 actions are executed including the notification of the management 593 system. When this bit is cleared, alarms are suppressed and no 594 action is executed and the management system is not notified. 596 4.4. Handling OAM Configuration Errors 598 To handle OAM configuration errors a new Error Code (IANA to assign) 599 "OAM Problem" is introduced. To refer to specific problems, a set of 600 Error Values are defined under the "OAM Problem" error code. 602 If a node does not support the establishment of OAM MEP or MIP 603 entities it MUST use the error value: "MEP establishment not 604 supported" or "MIP establishment not supported" respectively in the 605 PathErr message. 607 If a node does not support a specific OAM technology/solution it MUST 608 use the error value: "Unsupported OAM Type" in the PathErr message. 610 If a different technology specific OAM configuration TLV is included 611 than what was specified in the OAM Type an error MUST be generated 612 with error value: "OAM Type Mismatch" in the PathErr message. 614 There is a hierarchy in between the OAM configuration elements. If 615 this hierarchy is broken the error value: "Configuration Error" MUST 616 be used in the PathErr message. 618 If a node does not support a specific OAM Function it MUST use the 619 error value: "Unsupported OAM Function" in the PathErr message. 621 4.5. Considerations on Point-to-Multipoint OAM Configuration 623 RSVP-TE extensions for the establishment of point-to-multipoint 624 (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of 625 multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set 626 up between the ingress and egress LSRs, and are appropriately 627 combined by the branch LSRs using RSVP semantics to result in a P2MP 628 TE LSP. One Path message may signal one or multiple S2L sub-LSPs for 629 a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP 630 can be signaled using one Path message or split across multiple Path 631 messages. 633 P2MP OAM mechanisms are very specific to the data plane technology, 634 therefore in this document we only highlight the basic principles of 635 P2MP OAM configuration. We consider only the root to leaf OAM flows, 636 and as such aspects of the configuration of return paths are outside 637 the scope of our discussions. We also limit our consideration to the 638 case where all leaves must successfully establish OAM entities with 639 identical configuration in order the P2MP OAM is successfully 640 established. In any case, the discussion set forth below provides 641 only guidelines for P2MP OAM configuration, details should be 642 specified in technology specific documents. 644 The root node may use a single Path message or multiple Path messages 645 to setup the whole P2MP tree. In the case when multiple Path 646 messages are used, the root node is responsible to keep the OAM 647 Configuration information consistent in each of the sent Path 648 messages, i.e., the same information MUST be included in all Path 649 messages used to construct the multicast tree. Each branching node 650 will propagate the Path message downstream on each of the branches, 651 when constructing a Path message the OAM Configuration information 652 MUST be copied unchanged from the received Path message, including 653 the related ADMIN_STATUS bits, LSP Attribute Flags and the OAM 654 Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES 655 and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for the upstream 656 Path message to the subsequent downstream Path messages. 658 Leaves MUST create and configure OAM sink functions according to the 659 parameters received in the Path message, for P2MP OAM configuration 660 there is no possibility for parameter negotiation on a per leaf 661 basis. This is due to the fact that the OAM source function, 662 residing in the root of the tree, will operate with a single 663 configuration, which then must be obeyed by all leaves. If a leaf 664 cannot accept the OAM parameters it MUST use the RRO Attributes sub- 665 object [RFC5420] to notify the root about the problem. In 666 particular, if the OAM configuration was successful, the leaf would 667 set the "OAM MEP entities desired" flag in the RRO Attributes sub- 668 object in the Resv message. On the other hand, if OAM entities could 669 not be established the Resv message should be sent with the "OAM MEP 670 entities desired" bit cleared in the RRO Attributes sub-object. 671 Branching nodes should collect and merge the received RROs according 672 to the procedures described in [RFC4875]. This way, the root when 673 receiving the Resv message (or messages if multiple Path messages 674 were used to set up the tree) will have a clear information about 675 which of the leaves could establish the OAM functions. If all leaves 676 established OAM entities successfully, the root can enable the OAM 677 message flow. On the other hand, if at some leaves the establishment 678 was unsuccessful additional actions will be needed before the OAM 679 message flow can be enabled. Such action could be to setup two 680 independent P2MP LSPs. One with OAM Configuration information 681 towards leaves which could successfully setup the OAM function. This 682 can be done by pruning the leaves which failed to setup OAM of the 683 previously signaled P2MP LSP. The other P2MP LSP could be 684 constructed for leaves without OAM entities. The exact procedures 685 SHOULD be described in technology specific documents. 687 5. IANA Considerations 689 Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs 690 to be allocated in the ADMIN_STATUS Object. 692 Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") 693 needs to be allocated in the LSP Attributes Flags Registry. 695 This document specifies one new TLV to be carried in the 696 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv 697 messages: OAM Configuration TLV. 699 One new Error Code: "OAM Problem" and a set of new values: "MEP 700 establishment not supported", "MIP establishment not supported", 701 "Unsupported OAM Type", "Configuration Error" and "Unsupported OAM 702 Function" needs to be assigned. 704 IANA is requested to open a new registry: "RSVP-TE OAM Configuration 705 Registry" that maintains the "OAM Type" code points, an associated 706 sub-TLV space, and the allocations of "OAM Function Flags" within the 707 OAM Configuration TLV. 709 6. Security Considerations 711 The signaling of OAM related parameters and the automatic 712 establishment of OAM entities based on RSVP-TE messages adds a new 713 aspect to the security considerations discussed in [RFC3473]. In 714 particular, a network element could be overloaded, if a remote 715 attacker could request liveliness monitoring, with frequent periodic 716 messages, for a high number of LSPs, targeting a single network 717 element. Such an attack can efficiently be prevented when mechanisms 718 for message integrity and node authentication are deployed. Since 719 the OAM configuration extensions rely on the hop-by-hop exchange of 720 exiting RSVP-TE messages, procedures specified for RSVP message 721 security in [RFC2747] can be used to mitigate possible attacks. 723 For a more comprehensive discussion on GMPLS security please see the 724 Security Framework for MPLS and GMPLS Networks [RFC5920]. 725 Cryptography can be used to protect against many attacks described in 726 [RFC5920]. 728 7. Acknowledgements 730 The authors would like to thank Francesco Fondelli, Adrian Farrel, 731 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 732 comments. 734 8. References 736 8.1. Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 742 (GMPLS) Signaling Functional Description", RFC 3471, 743 January 2003. 745 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 746 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 747 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 749 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 750 Ayyangarps, "Encoding of Attributes for MPLS LSP 751 Establishment Using Resource Reservation Protocol Traffic 752 Engineering (RSVP-TE)", RFC 5420, February 2009. 754 8.2. Informative References 756 [IEEE.802.1Q-2011] 757 IEEE, "IEEE Standard for Local and metropolitan area 758 networks -- Media Access Control (MAC) Bridges and Virtual 759 Bridged Local Area Networks", IEEE Std 802.1Q, 2011. 761 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 762 Authentication", RFC 2747, January 2000. 764 [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. 765 Matsushima, "Operations and Management (OAM) Requirements 766 for Multi-Protocol Label Switched (MPLS) Networks", 767 RFC 4377, February 2006. 769 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 770 Label Switched (MPLS) Data Plane Failures", RFC 4379, 771 February 2006. 773 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 774 "Extensions to Resource Reservation Protocol - Traffic 775 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 776 Switched Paths (LSPs)", RFC 4875, May 2007. 778 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 779 and S. Ueno, "Requirements of an MPLS Transport Profile", 780 RFC 5654, September 2009. 782 [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized 783 Multiprotocol Label Switching (GMPLS) Ethernet Label 784 Switching Architecture and Framework", RFC 5828, 785 March 2010. 787 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 788 Operations, Administration, and Maintenance (OAM) in MPLS 789 Transport Networks", RFC 5860, May 2010. 791 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 792 Networks", RFC 5920, July 2010. 794 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 795 Berger, "A Framework for MPLS in Transport Networks", 796 RFC 5921, July 2010. 798 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 799 "Generalized Multiprotocol Label Switching (GMPLS) Control 800 of Ethernet Provider Backbone Traffic Engineering 801 (PBB-TE)", RFC 6060, March 2011. 803 Authors' Addresses 805 Attila Takacs 806 Ericsson 807 Konyves Kalman krt. 11. 808 Budapest, 1097 809 Hungary 811 Email: attila.takacs@ericsson.com 813 Don Fedyk 814 Alcatel-Lucent 815 Groton, MA 01450 816 USA 818 Email: donald.fedyk@alcatel-lucent.com 820 Jia He 821 Huawei 823 Email: hejia@huawei.com