idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-05.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 : ---------------------------------------------------------------------------- ** 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...' (46 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 (March 14, 2011) is 4793 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 754, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 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: September 15, 2011 Alcatel-Lucent 6 J. He 7 Huawei 8 March 14, 2011 10 GMPLS RSVP-TE extensions for OAM Configuration 11 draft-ietf-ccamp-oam-configuration-fwk-05 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 September 15, 2011. 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 lately Ethernet 94 Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS 95 Transport Profile (MPLS-TP). In most of these technologies there are 96 Operations and Management (OAM) functions employed to monitor the 97 health and performance of the connections and to trigger data plane 98 (DP) recovery mechanisms. Similarly to connections, OAM functions 99 follow 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, only needed for a specific OAM 137 technology. This document specifies the technology agnostic 138 elements, which alone can be used to establish and control OAM 139 entities in the case no technology specific information is needed, 140 and specifies the way additional technology specific OAM parameters 141 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 form 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 must 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 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. If the "OAM MEP entities desired" bit 450 is set it is indicating that the establishment of OAM MEP entities 451 are required at the endpoints of the signaled LSP. If the 452 establishment of MEPs is not supported an error must be generated: 453 "OAM Problem/MEP establishment not supported". 455 If the "OAM MEP entities desired" bit is set but additional 456 parameters need also to be configured, an OAM Configuration TLV MAY 457 be included in the LSP_ATTRIBUTES Object. 459 One bit (IANA to assign): "OAM MIP entities desired" is allocated in 460 the LSP Attributes Flags TLV. This bit can only be set if the "OAM 461 MEP entities desired" bit is set. If the "OAM MIP entities desired" 462 bit is set in the LSP_ATTRIBUTES Flags TLV in the 463 LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the 464 establishment of OAM MIP entities is required at every transit node 465 of the signalled LSP. If the establishment of a MIP is not supported 466 an error must be generated: "OAM Problem/MIP establishment not 467 supported". 469 4.2. OAM Configuration TLV 471 This TLV provides information about which OAM technology/method 472 should be used and carries sub-TLVs for any additional OAM 473 configuration information. The OAM Configuration TLV may be carried 474 in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and 475 Resv messages. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type (IANA) | Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | OAM Type | Reserved | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 ~ sub-TLVs ~ 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Type: indicates a new type: the OAM Configuration TLV (3) (IANA to 490 assign). 492 OAM Type: specifies the technology specific OAM method. When carried 493 in the LSP_REQUIRED_ATTRIBUTES Object, if the requested OAM method is 494 not supported at a given node an error must be generated: "OAM 495 Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES 496 Object, intermediate nodes not supporting the OAM Type pass the 497 object forward unchanged as specified in [RFC5420] only Label Edge 498 Nodes must generate the error if the OAM Type is not supported. 500 OAM Type Description 501 ------------ -------------------- 502 0-255 Reserved 504 This document defines no types. IANA is requested to maintain the 505 values in a new "RSVP-TE OAM Configuration Registry". 507 The receiving node based on the OAM Type will check if a 508 corresponding technology specific OAM configuration sub-TLV is 509 included. If the included technology specific OAM configuration sub- 510 TLV is different than what is specified in the OAM Type an error must 511 be generated: "OAM Problem/OAM Type Mismatch". IANA is requested to 512 maintain the sub-TLV space in the new "RSVP-TE OAM Configuration 513 Registry". 515 Note that there is a hierarchical dependency in between the OAM 516 configuration elements. First, the "OAM MEP (and MIP) entities 517 desired" flag needs to be set. Only when that is set MAY an "OAM 518 Configuration TLV" be included in the LSP_ATTRIBUTES or 519 LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on 520 the "OAM Type" field, it MAY carry a technology specific OAM 521 configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP 522 entities desired" flag is not set but an OAM Configuration TLV is 523 present) an error MUST be generated: "OAM Problem/Configuration 524 Error". 526 4.2.1. OAM Function Flags Sub-TLV 528 As the first sub-TLV the "OAM Function Flags sub-TLV" MUST be always 529 included in the "OAM Configuration TLV". "OAM Function Flags" 530 specifies which pro-active OAM functions (e.g., connectivity 531 monitoring, loss and delay measurement) and which fault management 532 signals MUST be established and configured. If the selected OAM 533 Function(s) is(are) not supported, an error MUST be generated: "OAM 534 Problem/Unsupported OAM Function". 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Type (1) (IANA) | Length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | 542 ~ OAM Function Flags ~ 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 OAM Function Flags is bitmap with extensible length based on the 547 Lenght field of the TLV. Bits are numbered from left to right. IANA 548 is requested to maintain the OAM Function Flags in the new "RSVP-TE 549 OAM Configuration Registry". This document defines the following 550 flags. 552 OAM Function Flag bit# Description 553 --------------------- --------------------------- 554 0 Continuity Check (CC) 555 1 Connectivity Verification (CV) 556 2 Performance Monitoring/Loss (PM/Loss) 557 3 Performance Monitoring/Delay (PM/Delay) 559 4.2.2. Technology Specific sub-TLVs 561 One technology specific sub-TLV MAY be defined for each "OAM Type". 562 This sub-TLV MUST contain any further OAM configuration information 563 for that specific "OAM Type". The technology specific sub-TLV, when 564 used, MUST be carried within the OAM Configuration TLV. IANA is 565 requested to maintain the sub-TLV space in the new "RSVP-TE OAM 566 Configuration Registry". 568 4.3. Administrative Status Information 570 Administrative Status Information is carried in the ADMIN_STATUS 571 Object. The Administrative Status Information is described in 572 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 573 [RFC3473]. 575 Two bits are allocated for the administrative control of OAM 576 monitoring. Two bits (IANA to assign) are allocated by this draft: 577 the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When 578 the "OAM Flows Enabled" bit is set, OAM packets are sent if it is 579 cleared no OAM packets are emitted. When the "OAM Alarms Enabled" 580 bit is set OAM triggered alarms are enabled and associated consequent 581 actions are executed including the notification of the management 582 system. When this bit is cleared, alarms are suppressed and no 583 action is executed and the management system is not notified. 585 4.4. Handling OAM Configuration Errors 587 To handle OAM configuration errors a new Error Code (IANA to assign) 588 "OAM Problem" is introduced. To refer to specific problems a set of 589 Error Values is defined. 591 If a node does not support the establishment of OAM MEP or MIP 592 entities it must use the error value (IANA to assign): "MEP 593 establishment not supported" or "MIP establishment not supported" 594 respectively in the PathErr message. 596 If a node does not support a specific OAM technology/solution it must 597 use the error value (IANA to assign): "Unsupported OAM Type" in the 598 PathErr message. 600 If a different technology specific OAM configuration TLV is included 601 than what was specified in the OAM Type an error must be generated 602 with error value: "OAM Type Mismatch" in the PathErr message. 604 There is a hierarchy in between the OAM configuration elements. If 605 this hierarchy is broken the error value: "Configuration Error" must 606 be used in the PathErr message. 608 If a node does not support a specific OAM Function it must use the 609 error value: "Unsupported OAM Function" in the PathErr message. 611 4.5. Considerations on Point-to-Multipoint OAM Configuration 613 RSVP-TE extensions for the establishment of point-to-multipoint 614 (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of 615 multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set 616 up between the ingress and egress LSRs and are appropriately combined 617 by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. 618 One Path message may signal one or multiple S2L sub-LSPs for a single 619 P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be 620 signaled using one Path message or split across multiple Path 621 messages. 623 P2MP OAM mechanisms are very specific to the data plane technology, 624 hence in this document we only highlight basic operations for P2MP 625 OAM configuration. We consider only the configuration of the root to 626 leaves OAM flows of P2MP LSPs and as such aspects of any return path 627 are outside the scope of our discussions. We also limit our 628 consideration to cases where all leaves must successfully establish 629 OAM entities in order a P2MP OAM is successfully established. In any 630 case, the discussion set forth below provides only guidelines for 631 P2MP OAM configuration, details SHOULD be specified in technology 632 specific documents. 634 The root node may select if it uses a single Path message or multiple 635 Path messages to setup the whole P2MP tree. In the case when 636 multiple Path messages are used the root node is responsible also to 637 keep the OAM Configuration information consistent in each of the sent 638 Path messages, i.e., the same information MUST be included in all 639 Path messages used to construct the multicast tree. Each branching 640 node will propagate the Path message downstream on each of the 641 branches, when constructing a Path message the OAM Configuration 642 information MUST be copied unchanged from the received Path message, 643 including the related ADMIN_STATUS bits, LSP Attribute Flags and the 644 OAM Configuration TLV. The latter two also imply that the 645 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for 646 the upstream Path message to the subsequent downstream Path messages. 648 Leaves MUST create and configure OAM sink functions according to the 649 parameters received in the Path message, for P2MP OAM configuration 650 there is no possibility for parameter negotiation on a per leaf 651 basis. This is due to the fact that the only OAM source function, 652 residing in the root of the tree, can only operate with a single 653 configuration which must be obeyed by all leaves. If a leaf cannot 654 accept the OAM parameters it MUST use the RRO Attributes sub-object 655 [RFC5420] to notify the root of the problem. In particular, if the 656 OAM configuration was successful the leaf would set the "OAM MEP 657 entities desired" flag in the RRO Attributes sub-object in the Resv 658 message, while, if due to any reason, OAM entities could not be 659 established the Resv message should be sent with the "OAM MEP 660 entities desired" bit cleared in the RRO Attributes sub-object. 661 Branching nodes should collect and merge the received RROs according 662 to the procedures described in [RFC4875]. This way, the root when 663 receiving the Resv message (or messages if multiple Path messages 664 were used to setup the tree) will have a clear information on which 665 of the leaves could the OAM sink functions be established. If all 666 leaves established OAM entities successfully, the root can enable the 667 OAM message flow. On the other hand, if at some leaves the 668 establishment was unsuccessful additional actions will be needed 669 before the OAM message flow can be enabled. Such action could be to 670 setup two independent P2MP LSPs. One with OAM Configuration 671 information towards leaves which successfully setup OAM. This can be 672 done by prunning the leaves which failed to setup OAM of the 673 previously signalled P2MP LSP. The other P2MP LSP could be 674 constructed for leaves without OAM entities. What exact procedures 675 are needed are technology specific and should be described in 676 technology specific documents. 678 5. IANA Considerations 680 Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs 681 to be allocated in the ADMIN_STATUS Object. 683 Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") 684 needs to be allocated in the LSP Attributes Flags Registry. 686 This document specifies one new TLV to be carried in the 687 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv 688 messages: OAM Configuration TLV. 690 One new Error Code: "OAM Problem" and a set of new values: "MEP 691 establishment not supported", "MIP establishment not supported", 692 "Unsupported OAM Type", "Configuration Error" and "Unsupported OAM 693 Function" needs to be assigned. 695 IANA is requested to open a new registry: "RSVP-TE OAM Configuration 696 Registry" that maintains the "OAM Type" code points, an associated 697 sub-TLV space, and the allocations of "OAM Function Flags" within the 698 OAM Configuration TLV. 700 6. Security Considerations 702 The signaling of OAM related parameters and the automatic 703 establishment of OAM entities based on RSVP-TE messages adds a new 704 aspect to the security considerations discussed in [RFC3473]. In 705 particular, a network element could be overloaded, if a remote 706 attacker could request liveliness monitoring, with frequent periodic 707 messages, for a high number of LSPs, targeting a single network 708 element. Such an attack can efficiently be prevented when mechanisms 709 for message integrity and node authentication are deployed. Since 710 the OAM configuratiuon extensions rely on the hop-by-hop exchange of 711 exiting RSVP-TE messages, procedures specified for RSVP message 712 security in [RFC2747] can be used to mitigate possible attacks. 714 For a more comprehensive discussion on GMPLS security please see the 715 Security Framework for MPLS and GMPLS Networks [RFC5920]. 716 Cryptography can be used to protect against many attacks described in 717 [RFC5920]. 719 7. Acknowledgements 721 The authors would like to thank Francesco Fondelli, Adrian Farrel, 722 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 723 comments. 725 8. References 727 8.1. Normative References 729 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 730 Signaling Functional Description", RFC 3471, January 2003. 732 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 733 Signaling Resource ReserVation Protocol-Traffic 734 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 736 [RFC5420] "Encoding of Attributes for Multiprotocol Label Switching 737 (MPLS) Label Switched Path (LSP) Establishment Using 738 Resource ReserVation Protocol-Traffic Engineering 739 (RSVP-TE)", RFC 5420, February 2009. 741 8.2. Informative References 743 [IEEE-CFM] 744 "IEEE 802.1ag, Draft Standard for Connectivity Fault 745 Management", work in progress. 747 [IEEE-PBBTE] 748 "IEEE 802.1Qay Draft Standard for Provider Backbone 749 Bridging Traffic Engineering", work in progress. 751 [RFC2747] "RSVP Cryptographic Authentication", RFC 2747, 752 January 2000. 754 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 755 Recovery", RFC 3469, February 2003. 757 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 758 Protocol Label Switched (MPLS) Networks", RFC 4377, 759 February 2006. 761 [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data Plane 762 Failures", RFC 4379, February 2006. 764 [RFC4875] "Extensions to Resource Reservation Protocol - Traffic 765 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 766 Switched Paths (LSPs)", RFC 4875, May 2007. 768 [RFC5654] "Requirements of an MPLS Transport Profile", RFC 5654, 769 September 2009. 771 [RFC5828] "GMPLS Ethernet Label Switching Architecture and 772 Framework", RFC 5828, March 2010. 774 [RFC5860] "Requirements for OAM in MPLS Transport Networks", 775 RFC 5860, May 2010. 777 [RFC5920] "Security Framework for MPLS and GMPLS Networks", 778 RFC 5920, July 2010. 780 [RFC5921] "A Framework for MPLS in Transport Networks", RFC 5921, 781 July 2010. 783 [RFC6060] "Generalized Multiprotocol Label Switching (GMPLS) Control 784 of Ethernet Provider Backbone Traffic Engineering 785 (PBB-TE)", RFC 6060. 787 Authors' Addresses 789 Attila Takacs 790 Ericsson 791 Laborc u. 1. 792 Budapest, 1037 793 Hungary 795 Email: attila.takacs@ericsson.com 797 Don Fedyk 798 Alcatel-Lucent 799 Groton, MA 01450 800 USA 802 Email: donald.fedyk@alcatel-lucent.com 804 Jia He 805 Huawei 807 Email: hejia@huawei.com