idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 189: '... o From [RFC5860]: OAM functions MUST operate and be configurable...' RFC 2119 keyword, line 190: '...ntrol plane. Conversely, it SHOULD be...' RFC 2119 keyword, line 193: '... SHOULD also be possible to confi...' RFC 2119 keyword, line 197: '... o From [RFC5654]: The MPLS-TP control plane MUST support the...' RFC 2119 keyword, line 219: '... MUST be able to configure and contr...' (54 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the Path message arrives at the receiver, the remote end MUST establish and configure OAM entities according to the OAM information provided in the Path message. If this is not possible a PathErr SHOULD be sent and neither the OAM entities nor the LSP SHOULD be established. If OAM entities are established successfully, the OAM sink function MUST be prepared to receive OAM messages but MUST not generate any OAM alarms (e.g., due to missing or unidentified OAM messages). In the case of bidirectional connections, an OAM source function MUST be setup and, according to the requested configuration, the OAM source function MUST start sending OAM messages. Then a Resv message is sent back, including the OAM Configuration TLV that corresponds to the actually established and configured OAM entities and functions. Depending on the OAM technology, some elements of the OAM Configuration TLV MAY be updated/changed; i.e., if the remote end is not supporting a certain OAM configuration it may suggest an alternative setting, which may or may not be accepted by the initiator of the Path message. If it is accepted, the initiator will reconfigure its OAM functions according to the information received in the Resv message. If the alternate setting is not acceptable a ResvErr may be sent tearing down the LSP. Details of this operation are technology specific and should be described in accompanying technology specific documents. -- The document date (July 11, 2011) is 4671 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) == Unused Reference: 'RFC3469' is defined on line 761, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 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: January 12, 2012 Alcatel-Lucent 6 J. He 7 Huawei 8 July 11, 2011 10 GMPLS RSVP-TE extensions for OAM Configuration 11 draft-ietf-ccamp-oam-configuration-fwk-06 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 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 January 12, 2012. 48 Copyright Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. RSVP-TE based OAM Configuration . . . . . . . . . . . . . . . 9 68 3.1. Establishment of OAM Entities and Functions . . . . . . . 9 69 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 11 70 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 11 71 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 13 72 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 13 73 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 14 74 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 15 75 4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 16 76 4.3. Administrative Status Information . . . . . . . . . . . . 16 77 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 16 78 4.5. Considerations on Point-to-Multipoint OAM Configuration . 17 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 87 1. Introduction 89 GMPLS is designed as an out-of-band control plane supporting dynamic 90 connection provisioning for any suitable data plane technology; 91 including spatial switching (e.g., incoming port or fiber to outgoing 92 port or fiber), wavelength-division multiplexing (e.g., DWDM), time- 93 division multiplexing (e.g., SONET/SDH, G.709), and Ethernet Provider 94 Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS. In most 95 of these technologies there are Operations, Administration and 96 Maintenance (OAM) functions employed to monitor the health and 97 performance of the connections and to trigger data plane (DP) 98 recovery mechanisms. Similarly to connections, OAM functions follow 99 general principles but also have some technology specific 100 characteristics. 102 OAM is an integral part of transport connections, hence it is 103 required that OAM functions are activated/deactivated in sync with 104 connection commissioning/decommissioning; avoiding spurious alarms 105 and ensuring consistent operation. In certain technologies OAM 106 entities are inherently established once the connection is set up, 107 while other technologies require extra configuration to establish and 108 configure OAM entities. In some situations the use of OAM functions, 109 like those of Fault- (FM) and Performance Management (PM), may be 110 optional confirming to actual network management policies. Hence the 111 network operator must be able to choose which kind of OAM functions 112 to apply to specific connections and with what parameters the 113 selected OAM functions should be configured and operated. To achieve 114 this objective OAM entities and specific functions must be 115 selectively configurable. 117 In general, it is required that the management plane and control 118 plane connection establishment mechanisms are synchronized with OAM 119 establishment and activation. In particular, if the GMPLS control 120 plane is employed it is desirable to bind OAM setup and configuration 121 to connection establishment signaling to avoid two separate 122 management/configuration steps (connection setup followed by OAM 123 configuration) which increases delay, processing and more importantly 124 may be prune to misconfiguration errors. Once OAM entities are setup 125 and configured, pro-active as well as on-demand OAM functions can be 126 activated via the management plane. On the other hand, it should be 127 possible to activate/deactivate pro-active OAM functions via the 128 GMPLS control plane as well. 130 This document describes requirements on OAM configuration and control 131 via RSVP-TE, and specifies extensions to the RSVP-TE protocol 132 providing a framework to configure and control OAM entities along 133 with the capability to carry technology specific information. 134 Extensions can be grouped into generic elements that are applicable 135 to any OAM solution and technology specific elements that provide 136 additional configuration parameters, which are only needed for a 137 specific OAM technology. This document specifies the technology 138 agnostic elements, which alone can be used to establish and control 139 OAM entities in the case no technology specific information is 140 needed, and specifies the way additional technology specific OAM 141 parameters are provided. 143 This document addresses end-to-end OAM configuration, that is, the 144 setup of OAM entities bound to an end-to-end LSP, and configuration 145 and control of OAM functions running end-to-end in the LSP. 146 Configuration of OAM entities for LSP segments and tandem connections 147 are out of the scope of this document. 149 The mechanisms described in this document provide an additional 150 option for bootstrapping OAM that is not intended to replace or 151 deprecate the use of other technology specific OAM bootstrapping 152 techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The 153 procedures specified in this document are intended only for use in 154 environments where RSVP-TE signaling is already in use to set up the 155 LSPs that are to be monitored using OAM. 157 2. Requirements 159 MPLS OAM requirements are described in [RFC4377], which provides 160 requirements to create consistent OAM functionality for MPLS 161 networks. 163 The following list is an excerpt of MPLS OAM requirements documented 164 in [RFC4377]. Only a few requirements are discussed that bear a 165 direct relevance to the 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 timeframes. 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] [RFC5860]. MPLS-TP poses 186 requirements on the control plane to configure and control OAM 187 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-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks 205 support explicitly-routed Ethernet connections. CFM can be used to 206 track the liveliness of PBB-TE connections and detect data plane 207 failures. In IETF the GMPLS controlled Ethernet Label Switching 208 (GELS) (see [RFC5828] and [RFC6060]) work extended the GMPLS control 209 plane to support the establishment of PBB-TE data plane connections. 210 Without control plane support separate management commands would be 211 needed to configure and start CFM. 213 GMPLS based OAM configuration and control should be general to be 214 applicable to a wide range of data plane technologies and OAM 215 solutions. There are three typical data plane technologies used for 216 transport application, which are wavelength based such as WSON, TDM 217 based such as SDH/SONET, packet based such as MPLS-TP [RFC5921] and 218 Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the operator 219 MUST be able to configure and control the following OAM functions. 221 o It MUST be possible to explicitly request the setup of OAM 222 entities for the signaled LSP and provide specific information for 223 the setup if this is required by the technology. 225 o Control of alarms is important to avoid false alarm indications 226 and reporting to the management system. It MUST be possible to 227 enable/disable alarms generated by OAM functions. In some cases 228 selective alarm control may be desirable when, for instance, the 229 operator is only concerned about critical alarms thus the non- 230 service affecting alarms should be inhibited. 232 o When periodic messages are used for liveliness check (continuity 233 check) of LSPs it MUST be possible to set the frequency of 234 messages allowing proper configuration for fulfilling the 235 requirements of the service and/or meeting the detection time 236 boundaries posed by possible congruent connectivity check 237 operations of higher layer applications. For a network operator 238 to be able to balance the trade-off in fast failure detection and 239 overhead it is beneficial to configure the frequency of continuity 240 check messages on a per LSP basis. 242 o Pro-active Performance Monitoring (PM) functions are continuously 243 collecting information about specific characteristics of the 244 connection. For consistent measurement of Service Level 245 Agreements (SLAs) measurement points must use common probing rate 246 to avoid measurement errors. 248 o The extensions MUST allow the operator to use only a minimal set 249 of OAM configuration and control features if the data plane 250 technology, the OAM solution or network management policy allows. 251 The extensions must be reusable as much as reasonably possible. 252 That is generic OAM parameters and data plane or OAM technology 253 specific parameters must be separated. 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, 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 unambigously identify MPs and MEs. 274 In addition to MP and ME identification parameters pro-active OAM 275 functions (e.g., Continuity Check (CC), Performance Monitoring) may 276 have specific parameters requiring configuration as well. In 277 particular, the frequency of periodic CC packets and the measurement 278 interval for loss and delay measurements may need to be configured. 280 In some cases all the above parameters may be either derived from 281 some exiting information or pre-configured default values can be 282 used. In the simplest case the control plane needs to provide 283 information whether or not OAM entities need to be setup for the 284 signaled LSP. If OAM entities are created signaling must provide 285 means to activate/deactivate OAM message flows and associated alarms. 287 OAM identifiers as well as the configuration of OAM functions are 288 technology specific, i.e., vary depending on the data plane 289 technology and the chosen OAM solution. In addition, for any given 290 data plane technology a set of OAM solutions may be applicable. The 291 OAM configuration framework allows selecting a specific OAM solution 292 to be used for the signaled LSP and provides technology specific TLVs 293 to carry further detailed configuration information. 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 can be signaled and established without OAM configuration 303 first, and OAM entities can be added later with a subsequent re- 304 signaling of the LSP. Alternatively, the LSP can be setup with OAM 305 entities right with the first signaling of the LSP. The below 306 procedures apply to both cases. 308 Before the initiator first sends a Path messages with OAM 309 Configuration information, it MUST establish and configure the 310 corresponding OAM entities locally, however OAM source functions MUST 311 NOT start sending any OAM messages. In the case of bidirectional 312 connections, the initiator node MUST setup the OAM sink function to 313 be prepared to receive OAM messages but MUST suppress any OAM alarms 314 (e.g., due to missing or unidentified OAM messages). The Path 315 message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag 316 cleared, i.e, data plane OAM alarms are suppressed. 318 When the Path message arrives at the receiver, the remote end MUST 319 establish and configure OAM entities according to the OAM information 320 provided in the Path message. If this is not possible a PathErr 321 SHOULD be sent and neither the OAM entities nor the LSP SHOULD be 322 established. If OAM entities are established successfully, the OAM 323 sink function MUST be prepared to receive OAM messages but MUST not 324 generate any OAM alarms (e.g., due to missing or unidentified OAM 325 messages). In the case of bidirectional connections, an OAM source 326 function MUST be setup and, according to the requested configuration, 327 the OAM source function MUST start sending OAM messages. Then a Resv 328 message is sent back, including the OAM Configuration TLV that 329 corresponds to the actually established and configured OAM entities 330 and functions. Depending on the OAM technology, some elements of the 331 OAM Configuration TLV MAY be updated/changed; i.e., if the remote end 332 is not supporting a certain OAM configuration it may suggest an 333 alternative setting, which may or may not be accepted by the 334 initiator of the Path message. If it is accepted, the initiator will 335 reconfigure its OAM functions according to the information received 336 in the Resv message. If the alternate setting is not acceptable a 337 ResvErr may be sent tearing down the LSP. Details of this operation 338 are technology specific and should be described in accompanying 339 technology specific documents. 341 When the initiating side receives the Resv message it completes any 342 pending OAM configuration and enables the OAM source function to send 343 OAM messages. 345 After this round, OAM entities are established and configured for the 346 LSP and OAM messages are already exchanged. OAM alarms can now be 347 enabled. The initiator, while still keeping OAM alarms disabled 348 sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set. 349 The receiving node enables the OAM alarms after processing the Path 350 message. The initiator enables OAM alarms after it receives the Resv 351 message. Data plane OAM is now fully functional. 353 3.2. Adjustment of OAM Parameters 355 There may be a need to change the parameters of an already 356 established and configured OAM function during the lifetime of the 357 LSP. To do so the LSP needs to be re-signaled with the updated 358 parameters. OAM parameters influence the content and timing of OAM 359 messages and identify the way OAM defects and alarms are derived and 360 generated. Hence, to avoid spurious alarms, it is important that 361 both sides, OAM sink and source, are updated in a synchronized way. 362 First, the alarms of the OAM sink function should be suppressed and 363 only then should expected OAM parameters be adjusted. Subsequently, 364 the parameters of the OAM source function can be updated. Finally, 365 the alarms of the OAM sink side can be enabled again. 367 In accordance with the above operation, the LSP MUST first be re- 368 signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared and 369 including the updated OAM Configuration TLV corresponding to the new 370 parameter settings. The initiator MUST keep its OAM sink and source 371 functions running unmodified, but it MUST suppress OAM alarms after 372 the updated Path message is sent. The receiver MUST first disable 373 all OAM alarms, then update the OAM paramaters according to the 374 information in the Path message and reply with a Resv message 375 acknowledging the changes by including the OAM Configuration TLV. 376 Note that the receiving side has the possibility to adjust the 377 requested OAM configuration parameters and reply with and updated OAM 378 Configuration TLV in the Resv message, reflecting the actually 379 configured values. However, in order to avoid an extensive 380 negotiation phase, in the case of adjusting already configured OAM 381 functions, the receiving side SHOULD NOT update the parameters 382 requested in the Path message to an extent that would provide lower 383 performance than what has been configured previously. 385 The initiator MUST only update its OAM sink and source functions 386 after it received the Resv message. After this Path/Resv message 387 exchange (in both unidirectional and bidirectional LSP cases) the OAM 388 parameters are updated and OAM is running according the new parameter 389 settings. However OAM alarms are still disabled. A subsequent Path/ 390 Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set 391 is needed to enable OAM alarms again. 393 3.3. Deleting OAM Entities 395 In some cases it may be useful to remove some or all OAM entities and 396 functions from an LSP without actually tearing down the connection. 398 To avoid any spurious alarm, first the LSP SHOULD be re-signaled with 399 "OAM Alarms Enabled" ADMIN_STATUS flag cleared but unchanged OAM 400 configuration. Subsequently, the LSP is re-signaled with "OAM MEP 401 Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags 402 cleared, and without the OAM Configuration TLV, this MUST result in 403 the deletion of all OAM entities associated with the LSP. All 404 control and data plane resources in use by the OAM entities and 405 functions SHOULD be freed up. Alternatively, if only some OAM 406 functions need to be removed, the LSP is re-signalled with the 407 updated OAM Configuration TLV. Changes between the contents of the 408 previously signalled OAM Configuration TLV and the currently received 409 TLV represent which functions SHOULD be removed/added. 411 First, OAM source functions SHOULD be deleted and only after that 412 SHOULD the associated OAM sink functions be removed, this will ensure 413 that OAM messages do not leak outside the LSP. To this end the 414 initiator, before sending the Path message, SHOULD remove the OAM 415 source, hence terminating the OAM message flow associated to the 416 downstream direction. In the case of a bidirectional connection, it 417 SHOULD leave in place the OAM sink functions associated to the 418 upstream direction. The remote end, after receiving the Path 419 message, SHOULD remove all associated OAM entities and functions and 420 reply with a Resv message without an OAM Configuration TLV. The 421 initiator completely removes OAM entities and functions after the 422 Resv message arrived. 424 4. RSVP-TE Extensions 426 4.1. LSP Attributes Flags 428 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 429 indicate options and attributes of the LSP. The Flags field has 8 430 bits and hence is limited to differentiate only 8 options. [RFC5420] 431 defines new objects for RSVP-TE messages to allow the signaling of 432 arbitrary attribute parameters making RSVP-TE easily extensible to 433 support new applications. Furthermore, [RFC5420] allows options and 434 attributes that do not need to be acted on by all Label Switched 435 Routers (LSRs) along the path of the LSP. In particular, these 436 options and attributes may apply only to key LSRs on the path such as 437 the ingress LSR and egress LSR. Options and attributes can be 438 signaled transparently, and only examined at those points that need 439 to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES 440 objects are defined in [RFC5420] to provide means to signal LSP 441 attributes and options in the form of TLVs. Options and attributes 442 signaled in the LSP_ATTRIBUTES object can be passed transparently 443 through LSRs not supporting a particular option or attribute, while 444 the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined 445 and processed by each LSR. One TLV is defined in [RFC5420]: the 446 Attributes Flags TLV. 448 One bit (IANA to assign): "OAM MEP entities desired" is allocated in 449 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES object. 450 If the "OAM MEP entities desired" bit is set it is indicating that 451 the establishment of OAM MEP entities are required at the endpoints 452 of the signaled LSP. If the establishment of MEPs is not supported 453 an error must be generated: "OAM Problem/MEP establishment not 454 supported". 456 If the "OAM MEP entities desired" bit is set and additional 457 parameters need to be configured, an OAM Configuration TLV MAY be 458 included in the LSP_ATTRIBUTES Object. 460 One bit (IANA to assign): "OAM MIP entities desired" is allocated in 461 the LSP Attributes Flags TLV to be used in the LSP_ATTRIBUTES or 462 LSP_REQUIRED_ATTRIBUES objects. This bit can only be set if the "OAM 463 MEP entities desired" bit is set in. If the "OAM MIP entities 464 desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the 465 LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the 466 establishment of OAM MIP entities is required at every transit node 467 of the signalled LSP. If the establishment of a MIP is not supported 468 an error MUST be generated: "OAM Problem/MIP establishment not 469 supported". 471 4.2. OAM Configuration TLV 473 This TLV provides information about which OAM technology/method 474 should be used and carries sub-TLVs for any additional OAM 475 configuration information. The OAM Configuration TLV MAY be carried 476 in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and 477 Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object it 478 is indicating that intermediate nodes MUST recognize and eventually 479 react on the OAM configuration onformation. 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type (IANA) | Length | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | OAM Type | Reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | | 489 ~ sub-TLVs ~ 490 | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Type: indicates a new type: the OAM Configuration TLV (3) (IANA to 494 assign). 496 OAM Type: specifies the technology specific OAM method. When carried 497 in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is 498 not supported at a given node an error MUST be generated: "OAM 499 Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES 500 Object, intermediate nodes not supporting the OAM Type pass the 501 object forward unchanged as specified in [RFC5420] only Label Edge 502 Nodes MUST generate the error if the OAM Type is not supported. 504 OAM Type Description 505 ------------ -------------------- 506 0-255 Reserved 508 This document defines no types. IANA is requested to maintain the 509 values in a new "RSVP-TE OAM Configuration Registry". 511 The receiving node based on the OAM Type will check if a 512 corresponding technology specific OAM configuration sub-TLV is 513 included. If the included technology specific OAM configuration sub- 514 TLV is different than what is specified in the OAM Type an error MUST 515 be generated: "OAM Problem/OAM Type Mismatch". IANA is requested to 516 maintain the sub-TLV space in the new "RSVP-TE OAM Configuration 517 Registry". 519 Note that there is a hierarchical dependency in between the OAM 520 configuration elements. First, the "OAM MEP (and MIP) entities 521 desired" flag needs to be set. Only when that is set MAY an "OAM 522 Configuration TLV" be included in the LSP_ATTRIBUTES or 523 LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on 524 the "OAM Type" field, it MAY carry a technology specific OAM 525 configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP 526 entities desired" flag is not set but an OAM Configuration TLV is 527 present) an error MUST be generated: "OAM Problem/Configuration 528 Error". 530 4.2.1. OAM Function Flags Sub-TLV 532 As the first sub-TLV the "OAM Function Flags sub-TLV" MUST be always 533 included in the "OAM Configuration TLV". "OAM Function Flags" 534 specifies which pro-active OAM functions (e.g., connectivity 535 monitoring, loss and delay measurement) and which fault management 536 signals MUST be established and configured. If the selected OAM 537 Function(s) is(are) not supported, an error MUST be generated: "OAM 538 Problem/Unsupported OAM Function". 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type (1) (IANA) | Length | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 ~ OAM Function Flags ~ 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 OAM Function Flags is bitmap with extensible length based on the 551 Lenght field of the TLV. Bits are numbered from left to right. IANA 552 is requested to maintain the OAM Function Flags in the new "RSVP-TE 553 OAM Configuration Registry". This document defines the following 554 flags. 556 OAM Function Flag bit# Description 557 --------------------- --------------------------- 558 0 Continuity Check (CC) 559 1 Connectivity Verification (CV) 560 2 Fault Monitoring Signal (FMS) 561 3 Performance Monitoring/Loss (PM/Loss) 562 4 Performance Monitoring/Delay (PM/Delay) 563 5 Performance Monitoring/Throughput Measurement 564 (PM/Throughput) 566 4.2.2. Technology Specific sub-TLVs 568 One technology specific sub-TLV MAY be defined for each "OAM Type". 569 This sub-TLV MUST contain any further OAM configuration information 570 for that specific "OAM Type". The technology specific sub-TLV, when 571 used, MUST be carried within the OAM Configuration TLV. IANA is 572 requested to maintain the sub-TLV space in the new "RSVP-TE OAM 573 Configuration Registry". 575 4.3. Administrative Status Information 577 Administrative Status Information is carried in the ADMIN_STATUS 578 Object. The Administrative Status Information is described in 579 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 580 [RFC3473]. 582 Two bits are allocated for the administrative control of OAM 583 monitoring. Two bits (IANA to assign) are allocated by this draft: 584 the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When 585 the "OAM Flows Enabled" bit is set, OAM packets are sent if it is 586 cleared no OAM packets are emitted. When the "OAM Alarms Enabled" 587 bit is set OAM triggered alarms are enabled and associated consequent 588 actions are executed including the notification of the management 589 system. When this bit is cleared, alarms are suppressed and no 590 action is executed and the management system is not notified. 592 4.4. Handling OAM Configuration Errors 594 To handle OAM configuration errors a new Error Code (IANA to assign) 595 "OAM Problem" is introduced. To refer to specific problems a set of 596 Error Values is defined. 598 If a node does not support the establishment of OAM MEP or MIP 599 entities it must use the error value (IANA to assign): "MEP 600 establishment not supported" or "MIP establishment not supported" 601 respectively in the PathErr message. 603 If a node does not support a specific OAM technology/solution it must 604 use the error value (IANA to assign): "Unsupported OAM Type" in the 605 PathErr message. 607 If a different technology specific OAM configuration TLV is included 608 than what was specified in the OAM Type an error must be generated 609 with error value: "OAM Type Mismatch" in the PathErr message. 611 There is a hierarchy in between the OAM configuration elements. If 612 this hierarchy is broken the error value: "Configuration Error" must 613 be used in the PathErr message. 615 If a node does not support a specific OAM Function it must use the 616 error value: "Unsupported OAM Function" in the PathErr message. 618 4.5. Considerations on Point-to-Multipoint OAM Configuration 620 RSVP-TE extensions for the establishment of point-to-multipoint 621 (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of 622 multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set 623 up between the ingress and egress LSRs and are appropriately combined 624 by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. 625 One Path message may signal one or multiple S2L sub-LSPs for a single 626 P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be 627 signaled using one Path message or split across multiple Path 628 messages. 630 P2MP OAM mechanisms are very specific to the data plane technology, 631 hence in this document we only highlight basic operations for P2MP 632 OAM configuration. We consider only the configuration of the root to 633 leaves OAM flows of P2MP LSPs and as such aspects of any return path 634 are outside the scope of our discussions. We also limit our 635 consideration to cases where all leaves must successfully establish 636 OAM entities in order a P2MP OAM is successfully established. In any 637 case, the discussion set forth below provides only guidelines for 638 P2MP OAM configuration, details SHOULD be specified in technology 639 specific documents. 641 The root node may select if it uses a single Path message or multiple 642 Path messages to setup the whole P2MP tree. In the case when 643 multiple Path messages are used the root node is responsible also to 644 keep the OAM Configuration information consistent in each of the sent 645 Path messages, i.e., the same information MUST be included in all 646 Path messages used to construct the multicast tree. Each branching 647 node will propagate the Path message downstream on each of the 648 branches, when constructing a Path message the OAM Configuration 649 information MUST be copied unchanged from the received Path message, 650 including the related ADMIN_STATUS bits, LSP Attribute Flags and the 651 OAM Configuration TLV. The latter two also imply that the 652 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for 653 the upstream Path message to the subsequent downstream Path messages. 655 Leaves MUST create and configure OAM sink functions according to the 656 parameters received in the Path message, for P2MP OAM configuration 657 there is no possibility for parameter negotiation on a per leaf 658 basis. This is due to the fact that the only OAM source function, 659 residing in the root of the tree, can only operate with a single 660 configuration which must be obeyed by all leaves. If a leaf cannot 661 accept the OAM parameters it MUST use the RRO Attributes sub-object 662 [RFC5420] to notify the root of the problem. In particular, if the 663 OAM configuration was successful the leaf would set the "OAM MEP 664 entities desired" flag in the RRO Attributes sub-object in the Resv 665 message, while, if due to any reason, OAM entities could not be 666 established the Resv message should be sent with the "OAM MEP 667 entities desired" bit cleared in the RRO Attributes sub-object. 668 Branching nodes should collect and merge the received RROs according 669 to the procedures described in [RFC4875]. This way, the root when 670 receiving the Resv message (or messages if multiple Path messages 671 were used to setup the tree) will have a clear information on which 672 of the leaves could the OAM sink functions be established. If all 673 leaves established OAM entities successfully, the root can enable the 674 OAM message flow. On the other hand, if at some leaves the 675 establishment was unsuccessful additional actions will be needed 676 before the OAM message flow can be enabled. Such action could be to 677 setup two independent P2MP LSPs. One with OAM Configuration 678 information towards leaves which successfully setup OAM. This can be 679 done by prunning the leaves which failed to setup OAM of the 680 previously signalled P2MP LSP. The other P2MP LSP could be 681 constructed for leaves without OAM entities. What exact procedures 682 are needed are technology specific and SHOULD be described in 683 technology specific documents. 685 5. IANA Considerations 687 Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs 688 to be allocated in the ADMIN_STATUS Object. 690 Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") 691 needs to be allocated in the LSP Attributes Flags Registry. 693 This document specifies one new TLV to be carried in the 694 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv 695 messages: OAM Configuration TLV. 697 One new Error Code: "OAM Problem" and a set of new values: "MEP 698 establishment not supported", "MIP establishment not supported", 699 "Unsupported OAM Type", "Configuration Error" and "Unsupported OAM 700 Function" needs to be assigned. 702 IANA is requested to open a new registry: "RSVP-TE OAM Configuration 703 Registry" that maintains the "OAM Type" code points, an associated 704 sub-TLV space, and the allocations of "OAM Function Flags" within the 705 OAM Configuration TLV. 707 6. Security Considerations 709 The signaling of OAM related parameters and the automatic 710 establishment of OAM entities based on RSVP-TE messages adds a new 711 aspect to the security considerations discussed in [RFC3473]. In 712 particular, a network element could be overloaded, if a remote 713 attacker could request liveliness monitoring, with frequent periodic 714 messages, for a high number of LSPs, targeting a single network 715 element. Such an attack can efficiently be prevented when mechanisms 716 for message integrity and node authentication are deployed. Since 717 the OAM configuratiuon extensions rely on the hop-by-hop exchange of 718 exiting RSVP-TE messages, procedures specified for RSVP message 719 security in [RFC2747] can be used to mitigate possible attacks. 721 For a more comprehensive discussion on GMPLS security please see the 722 Security Framework for MPLS and GMPLS Networks [RFC5920]. 723 Cryptography can be used to protect against many attacks described in 724 [RFC5920]. 726 7. Acknowledgements 728 The authors would like to thank Francesco Fondelli, Adrian Farrel, 729 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 730 comments. 732 8. References 734 8.1. Normative References 736 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 737 Signaling Functional Description", RFC 3471, January 2003. 739 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 740 Signaling Resource ReserVation Protocol-Traffic 741 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 743 [RFC5420] "Encoding of Attributes for Multiprotocol Label Switching 744 (MPLS) Label Switched Path (LSP) Establishment Using 745 Resource ReserVation Protocol-Traffic Engineering 746 (RSVP-TE)", RFC 5420, February 2009. 748 8.2. Informative References 750 [IEEE-CFM] 751 "IEEE 802.1ag, Draft Standard for Connectivity Fault 752 Management", work in progress. 754 [IEEE-PBBTE] 755 "IEEE 802.1Qay Draft Standard for Provider Backbone 756 Bridging Traffic Engineering", work in progress. 758 [RFC2747] "RSVP Cryptographic Authentication", RFC 2747, 759 January 2000. 761 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 762 Recovery", RFC 3469, February 2003. 764 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 765 Protocol Label Switched (MPLS) Networks", RFC 4377, 766 February 2006. 768 [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data Plane 769 Failures", RFC 4379, February 2006. 771 [RFC4875] "Extensions to Resource Reservation Protocol - Traffic 772 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 773 Switched Paths (LSPs)", RFC 4875, May 2007. 775 [RFC5654] "Requirements of an MPLS Transport Profile", RFC 5654, 776 September 2009. 778 [RFC5828] "GMPLS Ethernet Label Switching Architecture and 779 Framework", RFC 5828, March 2010. 781 [RFC5860] "Requirements for OAM in MPLS Transport Networks", 782 RFC 5860, May 2010. 784 [RFC5920] "Security Framework for MPLS and GMPLS Networks", 785 RFC 5920, July 2010. 787 [RFC5921] "A Framework for MPLS in Transport Networks", RFC 5921, 788 July 2010. 790 [RFC6060] "Generalized Multiprotocol Label Switching (GMPLS) Control 791 of Ethernet Provider Backbone Traffic Engineering 792 (PBB-TE)", RFC 6060. 794 Authors' Addresses 796 Attila Takacs 797 Ericsson 798 Konyves Kalman krt. 11. 799 Budapest, 1097 800 Hungary 802 Email: attila.takacs@ericsson.com 804 Don Fedyk 805 Alcatel-Lucent 806 Groton, MA 01450 807 USA 809 Email: donald.fedyk@alcatel-lucent.com 811 Jia He 812 Huawei 814 Email: hejia@huawei.com