idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-04.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 OAM functions MUST operate and be c...' RFC 2119 keyword, line 190: '... Conversely, it SHOULD be possible to...' RFC 2119 keyword, line 192: '...ctivity management, and it SHOULD also...' RFC 2119 keyword, line 196: '...TP control plane MUST support the conf...' RFC 2119 keyword, line 218: '... MUST be able to configure and contr...' (47 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 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 (October 25, 2010) is 4925 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 751, 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: April 28, 2011 Alcatel-Lucent 6 J. He 7 Huawei 8 October 25, 2010 10 GMPLS RSVP-TE extensions for OAM Configuration 11 draft-ietf-ccamp-oam-configuration-fwk-04 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 April 28, 2011. 48 Copyright Notice 50 Copyright (c) 2010 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 . . . . . . . . . . . . . . . 8 68 3.1. Establishment of OAM Entities and Functions . . . . . . . 8 69 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10 70 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10 71 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 12 72 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 12 73 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 13 74 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 14 75 4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 14 76 4.3. Administrative Status Information . . . . . . . . . . . . 15 77 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15 78 4.5. Considerations on Point-to-Multipoint OAM Configuration . 16 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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 OAM functions MUST operate and be configurable even in the absence 190 of a control plane. Conversely, it SHOULD be possible to 191 configure as well as enable/disable the capability to operate OAM 192 functions as part of connectivity management, and it SHOULD also 193 be possible to configure as well as enable/disable the capability 194 to operate OAM functions after connectivity has been established. 196 o The MPLS-TP control plane MUST support the configuration and 197 modification of OAM maintenance points as well as the activation/ 198 deactivation of OAM when the transport path or transport service 199 is established or modified. 201 Ethernet Connectivity Fault Management (CFM) defines an adjunct 202 connectivity monitoring OAM flow to check the liveliness of Ethernet 203 networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will 204 support explicitly-routed Ethernet connections. CFM can be used to 205 track the liveliness of PBB-TE connections and detect data plane 206 failures. In IETF the GMPLS controlled Ethernet Label Switching 207 (GELS) (see [RFC5828] and [GMPLS-PBBTE]) work is extending the GMPLS 208 control plane to support the establishment of point-to-point PBB-TE 209 data plane connections. Without control plane support separate 210 management commands would be needed to configure and start CFM. 212 GMPLS based OAM configuration and control should be general to be 213 applicable to a wide range of data plane technologies and OAM 214 solutions. There are three typical data plane technologies used for 215 transport application, which are wavelength based such as WSON, TDM 216 based such as SDH/SONET, packet based such as MPLS-TP [RFC5921] and 217 Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the operator 218 MUST be able to configure and control the following OAM functions. 220 o It MUST be possible to explicitly request the setup of OAM 221 entities for the signaled LSP and provide specific information for 222 the setup if this is required by the technology. 224 o Control of alarms is important to avoid false alarm indications 225 and reporting to the management system. It MUST be possible to 226 enable/disable alarms generated by OAM functions. In some cases 227 selective alarm control may be desirable when, for instance, the 228 operator is only concerned about critical alarms thus the non- 229 service affecting alarms should be inhibited. 231 o When periodic messages are used for liveliness check (continuity 232 check) of LSPs it MUST be possible to set the frequency of 233 messages allowing proper configuration for fulfilling the 234 requirements of the service and/or meeting the detection time 235 boundaries posed by possible congruent connectivity check 236 operations of higher layer applications. For a network operator 237 to be able to balance the trade-off in fast failure detection and 238 overhead it is beneficial to configure the frequency of continuity 239 check messages on a per LSP basis. 241 o Pro-active Performance Monitoring (PM) functions are continuously 242 collecting information about specific characteristics of the 243 connection. For consistent measurement of Service Level 244 Agreements (SLAs) it may be required that measurement points agree 245 on a common probing rate to avoid measurement problems. 247 o The extensions MUST allow the operator to use only a minimal set 248 of OAM configuration and control features if the data plane 249 technology, the OAM solution or network management policy allows. 250 The extensions must be reusable as much as reasonably possible. 251 That is generic OAM parameters and data plane or OAM technology 252 specific parameters must be separated. 254 3. RSVP-TE based OAM Configuration 256 In general, two types of Maintenance Points (MPs) can be 257 distinguished: Maintenance End Points (MEPs) and Maintenance 258 Intermediate Points (MIPs). MEPs reside at the ends of an LSP and 259 are capable of initiating and terminating OAM messages for Fault 260 Management (FM) and Performance Monitoring (PM). MIPs on the other 261 hand are located at transit nodes of an LSP and are capable of 262 reacting to some OAM messages but otherwise do not initiate messages. 263 Maintenance Entity (ME) refers to an association of MEPs and MIPs 264 that are provisioned to monitor an LSP. The ME association is 265 achieved by configuring MPs to belong to the same ME. 267 When an LSP is signaled, forwarding association is established 268 between endpoints and transit nodes via label bindings. This 269 association creates a context for the OAM entities monitoring the 270 LSP. On top of this association OAM entities may be configured to 271 unambigously identify MPs and MEs. 273 In addition to MP and ME identification parameters pro-active OAM 274 functions (e.g., Continuity Check (CC), Performance Monitoring) may 275 have specific parameters requiring configuration as well. In 276 particular, the frequency of periodic CC packets and the measurement 277 interval for loss and delay measurements may need to be configured. 279 In some cases all the above parameters may be either derived form 280 some exiting information or pre-configured default values can be 281 used. In the simplest case the control plane needs to provide 282 information whether or not OAM entities need to be setup for the 283 signaled LSP. If OAM entities are created signaling must provide 284 means to activate/deactivate OAM message flows and 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. The 290 OAM configuration framework allows selecting a specific OAM solution 291 to be used for the signaled LSP and provides technology specific TLVs 292 to carry further detailed configuration information. 294 3.1. Establishment of OAM Entities and Functions 296 In order to avoid spurious alarms OAM functions must be setup and 297 enabled in the appropriate order. When using the GMPLS control 298 plane, establishment and enabling of OAM functions must be bound to 299 RSVP-TE message exchanges. 301 An LSP may be signaled and established without OAM configuration 302 first, and OAM entities may be added later with a subsequent re- 303 signaling of the LSP. Alternatively, the LSP may be setup with OAM 304 entities right with the first signaling of the LSP. The below 305 procedures apply to both cases. 307 Before the initiator first sends a Path messages with OAM 308 Configuration information, it MUST establish and configure the 309 corresponding OAM entities locally, however OAM source functions MUST 310 NOT start sending any OAM messages. In the case of bidirectional 311 connections, the initiator node MUST setup the OAM sink function to 312 be prepared to receive OAM messages but MUST suppress any OAM alarms 313 (e.g., due to missing or unidentified OAM messages). The Path 314 message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag 315 cleared, i.e, data plane OAM alarms are suppressed. 317 When the Path message arrives at the receiver, the remote end MUST 318 establish and configure OAM entities according to the OAM information 319 provided in Path message. If this is not possible a PathErr SHOULD 320 be sent and neither the OAM entities nor the LSP SHOULD be 321 established. If OAM entities are established successfully, the OAM 322 sink function MUST be prepared to receive OAM messages but MUST not 323 generate any OAM alarms (e.g., due to missing or unidentified OAM 324 messages). In the case of bidirectional connections, an OAM source 325 function MUST be setup and, according to the requested configuration, 326 the OAM source function MUST start sending OAM messages. Then a Resv 327 message is sent back, including the OAM Configuration TLV that 328 corresponds to the actually established and configured OAM entities 329 and functions. Depending on the OAM technology, some elements of the 330 OAM Configuration TLV MAY be updated/changed; i.e., if the remote end 331 is not supporting a certain OAM configuration it may suggest an 332 alternative setting, which may or may not be accepted by the 333 initiator of the Path message. If it is accepted, the initiator will 334 reconfigure its OAM functions according to the information received 335 in the Resv message. If the alternate setting is not acceptable a 336 ResvErr may be sent tearing down the LSP. Details of this operation 337 are technology specific and should be described in accompanying 338 technology specific documents. 340 When the initiating side receives the Resv message it completes any 341 pending OAM configuration and enables the OAM source function to send 342 OAM messages. 344 After this round, OAM entities are established and configured for the 345 LSP and OAM messages are already exchanged. OAM alarms can now be 346 enabled. The initiator, while still keeping OAM alarms disabled 347 sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set. 348 The receiving node enables the OAM alarms after processing the Path 349 message. The initiator enables OAM alarms after it receives the Resv 350 message. Data plane OAM is now fully functional. 352 3.2. Adjustment of OAM Parameters 354 There may be a need to change the parameters of an already 355 established and configured OAM function during the lifetime of the 356 LSP. To do so the LSP needs to be re-signaled with the updated 357 parameters. OAM parameters influence the content and timing of OAM 358 messages and identify the way OAM defects and alarms are derived and 359 generated. Hence, to avoid spurious alarms, it is important that 360 both sides, OAM sink and source, are updated in a synchronized way. 361 First, the alarms of the OAM sink function should be suppressed and 362 only then should expected OAM parameters be adjusted. Subsequently, 363 the parameters of the OAM source function can be updated. Finally, 364 the alarms of the OAM sink side can be enabled again. 366 In accordance with the above operation, the LSP MUST first be re- 367 signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared and 368 including the updated OAM Configuration TLV corresponding to the new 369 parameter settings. The initiator MUST keep its OAM sink and source 370 functions running unmodified, but it MUST suppress OAM alarms after 371 the updated Path message is sent. The receiver MUST first disable 372 all OAM alarms, then update the OAM paramaters according to the 373 information in the Path message and reply with a Resv message 374 acknowledging the changes by including the OAM Configuration TLV. 375 Note that the receiving side has the possibility to adjust the 376 requested OAM configuration parameters and reply with and updated OAM 377 Configuration TLV in the Resv message, reflecting the actually 378 configured values. However, in order to avoid an extensive 379 negotiation phase, in the case of adjusting already configured OAM 380 functions, the receiving side SHOULD NOT update the parameters 381 requested in the Path message to an extent that would provide lower 382 performance than what has been configured previously. 384 The initiator MUST only update its OAM sink and source functions 385 after it received the Resv message. After this Path/Resv message 386 exchange (in both unidirectional and bidirectional LSP cases) the OAM 387 parameters are updated and OAM is running according the new parameter 388 settings. However OAM alarms are still disabled. A subsequent Path/ 389 Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set 390 is needed to enable OAM alarms again. 392 3.3. Deleting OAM Entities 394 In some cases it may be useful to remove some or all OAM entities and 395 functions from an LSP without actually tearing down the connection. 397 To avoid any spurious alarm, first the LSP SHOULD be re-signaled with 398 "OAM Alarms" ADMIN_STATUS flag cleared but unchanged OAM 399 configuration. Subsequently, the LSP is re-signaled with "OAM MEP 400 Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags 401 cleared, and without the OAM Configuration TLV, this MUST result in 402 the deletion of all OAM entities associated with the LSP. All 403 control and data plane resources in use by the OAM entities and 404 functions SHOULD be freed up. Alternatively, if only some OAM 405 functions need to be removed, the LSP is re-signalled with the 406 updated OAM Configuration TLV. Changes between the contents of the 407 previously signalled OAM Configuration TLV and the currently received 408 TLV represent which functions SHOULD be removed/added. 410 First, OAM source functions SHOULD be deleted and only after that 411 SHOULD the associated OAM sink functions be removed, this will ensure 412 that OAM messages do not leak outside the LSP. To this end the 413 initiator, before sending the Path message, SHOULD remove the OAM 414 source, hence terminating the OAM message flow associated to the 415 downstream direction. In the case of a bidirectional connection, it 416 SHOULD leave in place the OAM sink functions associated to the 417 upstream direction. The remote end, after receiving the Path 418 message, SHOULD remove all associated OAM entities and functions and 419 reply with a Resv message without an OAM Configuration TLV. The 420 initiator completely removes OAM entities and functions after the 421 Resv message arrived. 423 4. RSVP-TE Extensions 425 4.1. LSP Attributes Flags 427 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 428 indicate options and attributes of the LSP. The Flags field has 8 429 bits and hence is limited to differentiate only 8 options. [RFC5420] 430 defines new objects for RSVP-TE messages to allow the signaling of 431 arbitrary attribute parameters making RSVP-TE easily extensible to 432 support new applications. Furthermore, [RFC5420] allows options and 433 attributes that do not need to be acted on by all Label Switched 434 Routers (LSRs) along the path of the LSP. In particular, these 435 options and attributes may apply only to key LSRs on the path such as 436 the ingress LSR and egress LSR. Options and attributes can be 437 signaled transparently, and only examined at those points that need 438 to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES 439 objects are defined in [RFC5420] to provide means to signal LSP 440 attributes and options in the form of TLVs. Options and attributes 441 signaled in the LSP_ATTRIBUTES object can be passed transparently 442 through LSRs not supporting a particular option or attribute, while 443 the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined 444 and processed by each LSR. One TLV is defined in [RFC5420]: the 445 Attributes Flags TLV. 447 One bit (10 IANA to assign): "OAM MEP entities desired" is allocated 448 in the LSP Attributes Flags TLV. If the "OAM MEP entities desired" 449 bit is set it is indicating that the establishment of OAM MEP 450 entities are required at the endpoints of the signaled LSP. If the 451 establishment of MEPs is not supported an error must be generated: 452 "OAM Problem/MEP establishment not supported". 454 If the "OAM MEP entities desired" bit is set but additional 455 parameters need also to be configured, an OAM Configuration TLV MAY 456 be included in the LSP_ATTRIBUTES Object. 458 One bit (11 IANA to assign): "OAM MIP entities desired" is allocated 459 in the LSP Attributes Flags TLV. This bit can only be set if the 460 "OAM MEP entities desired" bit is set. If the "OAM MIP entities 461 desired" bit is set in the LSP_ATTRIBUTES Flags TLV in the 462 LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the 463 establishment of OAM MIP entities is required at every transit node 464 of the signalled LSP. If the establishment of a MIP is not supported 465 an error must be generated: "OAM Problem/MIP establishment not 466 supported". 468 4.2. OAM Configuration TLV 470 This TLV provides information about which OAM technology/method 471 should be used and carries sub-TLVs for any additional OAM 472 configuration information. The OAM Configuration TLV may be carried 473 in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and 474 Resv messages. 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Type (3) (IANA) | Length | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | OAM Type | Reserved | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 ~ sub-TLVs ~ 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Type: indicates a new type: the OAM Configuration TLV (3) (IANA to 489 assign). 491 OAM Type: specifies the technology specific OAM method. If the 492 requested OAM method is not supported an error must be generated: 493 "OAM Problem/Unsupported OAM Type". 495 OAM Type Description 496 ------------ -------------------- 497 0-255 Reserved 499 This document defines no types. IANA is requested to maintain the 500 values in a new "RSVP-TE OAM Configuration Registry". 502 The receiving node based on the OAM Type will check if a 503 corresponding technology specific OAM configuration sub-TLV is 504 included. If the included technology specific OAM configuration sub- 505 TLV is different than what is specified in the OAM Type an error must 506 be generated: "OAM Problem/OAM Type Mismatch". 508 Note that there is a hierarchical dependency in between the OAM 509 configuration elements. First, the "OAM MEP (and MIP) entities 510 desired" flag needs to be set. Only when that is set MAY an "OAM 511 Configuration TLV" be included in the LSP_ATTRIBUTES or 512 LSP_REQUIRED_ATTRIBUTES Object. When this TLV is present, based on 513 the "OAM Type" field, it MAY carry a technology specific OAM 514 configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP 515 entities desired" flag is not set but an OAM Configuration TLV is 516 present) an error MUST be generated: "OAM Problem/Configuration 517 Error". 519 4.2.1. OAM Function Flags Sub-TLV 521 As the first sub-TLV one "OAM Function Flags sub-TLV" MUST be always 522 included in the "OAM Configuration TLV". "OAM Function Flags" 523 specifies which pro-active OAM functions (e.g., connectivity 524 monitoring, loss and delay measurement) and which fault management 525 signals MUST be established and configured. If the selected OAM 526 Function(s) is(are) not supported, an error MUST be generated: "OAM 527 Problem/Unsupported OAM Function". 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Type (1) (IANA) | Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | | 535 ~ OAM Function Flags ~ 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 OAM Function Flags is bitmap with extensible length based on the 540 Lenght field of the TLV. Bits are numbered from left to right as 541 shown in the figure. This document defines the following flags. 543 OAM Function Flag bit# Description 544 --------------------- --------------------------- 545 0 Continuity Check (CC) 546 1 Connectivity Verification (CV) 547 2 Performance Monitoring/Loss (PM/Loss) 548 3 Performance Monitoring/Delay (PM/Delay) 550 4.2.2. Technology Specific sub-TLVs 552 One technology specific sub-TLV SHOULD be defined for each "OAM 553 Type". This sub-TLV MUST contain any further OAM configuration 554 information for that specific "OAM Type". The technology specific 555 sub-TLV, when used, MUST be carried within the OAM Configuration TLV. 557 4.3. Administrative Status Information 559 Administrative Status Information is carried in the ADMIN_STATUS 560 Object. The Administrative Status Information is described in 561 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 562 [RFC3473]. 564 Two bits are allocated for the administrative control of OAM 565 monitoring. In addition to the Reflect (R) bit, 7 bits are currently 566 occupied (assigned by IANA or temporarily blocked by work in progress 567 Internet drafts). As the 24th and 25th bits (IANA to assign) this 568 draft introduces the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" 569 (O) bits. When the "OAM Flows Enabled" bit is set, OAM packets are 570 sent if it is cleared no OAM packets are emitted. When the "OAM 571 Alarms Enabled" bit is set OAM triggered alarms are enabled and 572 associated consequent actions are executed including the notification 573 of the management system. When this bit is cleared, alarms are 574 suppressed and no action is executed and the management system is not 575 notified. 577 4.4. Handling OAM Configuration Errors 579 To handle OAM configuration errors a new Error Code (IANA to assign) 580 "OAM Problem" is introduced. To refer to specific problems a set of 581 Error Values is defined. 583 If a node does not support the establishment of OAM MEP or MIP 584 entities it must use the error value (IANA to assign): "MEP 585 establishment not supported" or "MIP establishment not supported" 586 respectively in the PathErr message. 588 If a node does not support a specific OAM technology/solution it must 589 use the error value (IANA to assign): "Unsupported OAM Type" in the 590 PathErr message. 592 If a different technology specific OAM configuration TLV is included 593 than what was specified in the OAM Type an error must be generated 594 with error value: "OAM Type Mismatch" in the PathErr message. 596 There is a hierarchy in between the OAM configuration elements. If 597 this hierarchy is broken the error value: "Configuration Error" must 598 be used in the PathErr message. 600 If a node does not support a specific OAM Function it must use the 601 error value: "Unsupported OAM Function" in the PathErr message. 603 4.5. Considerations on Point-to-Multipoint OAM Configuration 605 RSVP-TE extensions for the establishment of point-to-multipoint 606 (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of 607 multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set 608 up between the ingress and egress LSRs and are appropriately combined 609 by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. 610 One Path message may signal one or multiple S2L sub-LSPs for a single 611 P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be 612 signaled using one Path message or split across multiple Path 613 messages. 615 P2MP OAM mechanisms are very specific to the data plane technology, 616 hence in this document we only highlight basic operations for P2MP 617 OAM configuration. We consider only the configuration of the root to 618 leaves OAM flows of P2MP LSPs and as such aspects of any return path 619 are outside the scope of our discussions. We also limit our 620 consideration to cases where all leaves must successfully establish 621 OAM entities in order a P2MP OAM is successfully established. In any 622 case, the discussion set forth below provides only guidelines for 623 P2MP OAM configuration, details SHOULD be specified in technology 624 specific documents. 626 The root node may select if it uses a single Path message or multiple 627 Path messages to setup the whole P2MP tree. In the case when 628 multiple Path messages are used the root node is responsible also to 629 keep the OAM Configuration information consistent in each of the sent 630 Path messages, i.e., the same information MUST be included in all 631 Path messages used to construct the multicast tree. Each branching 632 node will propagate the Path message downstream on each of the 633 branches, when constructing a Path message the OAM Configuration 634 information MUST be copied unchanged from the received Path message, 635 including the related ADMIN_STATUS bits, LSP Attribute Flags and the 636 OAM Configuration TLV. The latter two also imply that the 637 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES Object MUST be copied for 638 the upstream Path message to the subsequent downstream Path messages. 640 Leaves MUST create and configure OAM sink functions according to the 641 parameters received in the Path message, for P2MP OAM configuration 642 there is no possibility for parameter negotiation on a per leaf 643 basis. This is due to the fact that the only OAM source function, 644 residing in the root of the tree, can only operate with a single 645 configuration which must be obeyed by all leaves. If a leaf cannot 646 accept the OAM parameters it MUST use the RRO Attributes sub-object 647 [RFC5420] to notify the root of the problem. In particular, if the 648 OAM configuration was successful the leaf would set the "OAM MEP 649 entities desired" flag in the RRO Attributes sub-object in the Resv 650 message, while, if due to any reason, OAM entities could not be 651 established the Resv message should be sent with the "OAM MEP 652 entities desired" bit cleared in the RRO Attributes sub-object. 653 Branching nodes should collect and merge the received RROs according 654 to the procedures described in [RFC4875]. This way, the root when 655 receiving the Resv message (or messages if multiple Path messages 656 were used to setup the tree) will have a clear information on which 657 of the leaves could the OAM sink functions be established. If all 658 leaves established OAM entities successfully, the root can enable the 659 OAM message flow. On the other hand, if at some leaves the 660 establishment was unsuccessful additional actions will be needed 661 before the OAM message flow can be enabled. Such action could be to 662 setup two independent P2MP LSPs. One with OAM Configuration 663 information towards leaves which successfully setup OAM. This can be 664 done by prunning the leaves which failed to setup OAM of the 665 previously signalled P2MP LSP. The other P2MP LSP could be 666 constructed for leaves without OAM entities. What exact procedures 667 are needed are technology specific and should be described in 668 technology specific documents. 670 5. IANA Considerations 672 Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs 673 to be allocated in the ADMIN_STATUS Object. 675 Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") 676 needs to be allocated in the LSP Attributes Flags Registry. 678 This document specifies one new TLV to be carried in the 679 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv 680 messages: OAM Configuration TLV. 682 One new Error Code: "OAM Problem" and a set of new values: "MEP 683 establishment not supported", "MIP establishment not supported", 684 "Unsupported OAM Type", "Configuration Error" and "Unsupported OAM 685 Function" needs to be assigned. 687 IANA is requested to open a new registry: "RSVP-TE OAM Configuration 688 Registry" that maintains the "OAM Type" code points, an associated 689 sub-TLV space, and the allocations of "OAM Function Flags" within the 690 OAM Configuration TLV. 692 6. Security Considerations 694 The signaling of OAM related parameters and the automatic 695 establishment of OAM entities based on RSVP-TE messages adds a new 696 aspect to the security considerations discussed in [RFC3473]. In 697 particular, a network element could be overloaded, if a remote 698 attacker could request liveliness monitoring, with frequent periodic 699 messages, for a high number of LSPs, targeting a single network 700 element. Such an attack can efficiently be prevented when mechanisms 701 for message integrity and node authentication are deployed. Since 702 the OAM configuratiuon extensions rely on the hop-by-hop exchange of 703 exiting RSVP-TE messages, procedures specified for RSVP message 704 security in [RFC2747] can be used to mitigate possible attacks. 706 For a more comprehensive discussion on GMPLS security please see the 707 Security Framework for MPLS and GMPLS Networks [RFC5920]. 708 Cryptography can be used to protect against many attacks described in 709 [RFC5920]. 711 7. Acknowledgements 713 The authors would like to thank Francesco Fondelli, Adrian Farrel, 714 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 715 comments. 717 8. References 719 8.1. Normative References 721 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 722 Signaling Functional Description", RFC 3471, January 2003. 724 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 725 Signaling Resource ReserVation Protocol-Traffic 726 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 728 [RFC5420] "Encoding of Attributes for Multiprotocol Label Switching 729 (MPLS) Label Switched Path (LSP) Establishment Using 730 Resource ReserVation Protocol-Traffic Engineering 731 (RSVP-TE)", RFC 5420, February 2009. 733 8.2. Informative References 735 [GMPLS-PBBTE] 736 "Generalized Multiprotocol Label Switching (GMPLS) control 737 of Ethernet Provider Backbone Traffic Engineering 738 (PBB-TE)", Internet Draft, work in progress. 740 [IEEE-CFM] 741 "IEEE 802.1ag, Draft Standard for Connectivity Fault 742 Management", work in progress. 744 [IEEE-PBBTE] 745 "IEEE 802.1Qay Draft Standard for Provider Backbone 746 Bridging Traffic Engineering", work in progress. 748 [RFC2747] "RSVP Cryptographic Authentication", RFC 2747, 749 January 2000. 751 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 752 Recovery", RFC 3469, February 2003. 754 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 755 Protocol Label Switched (MPLS) Networks", RFC 4377, 756 February 2006. 758 [RFC4379] "Detecting Multi-Protocol Label Switched (MPLS) Data Plane 759 Failures", RFC 4379, February 2006. 761 [RFC4875] "Extensions to Resource Reservation Protocol - Traffic 762 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 763 Switched Paths (LSPs)", RFC 4875, May 2007. 765 [RFC5654] "Requirements of an MPLS Transport Profile", RFC 5654, 766 September 2009. 768 [RFC5828] "GMPLS Ethernet Label Switching Architecture and 769 Framework", RFC 5828, March 2010. 771 [RFC5860] "Requirements for OAM in MPLS Transport Networks", 772 RFC 5860, May 2010. 774 [RFC5920] "Security Framework for MPLS and GMPLS Networks", 775 RFC 5920, July 2010. 777 [RFC5921] "A Framework for MPLS in Transport Networks", RFC 5921, 778 July 2010. 780 Authors' Addresses 782 Attila Takacs 783 Ericsson 784 Laborc u. 1. 785 Budapest, 1037 786 Hungary 788 Email: attila.takacs@ericsson.com 790 Don Fedyk 791 Alcatel-Lucent 792 Groton, MA 01450 793 USA 795 Email: donald.fedyk@alcatel-lucent.com 797 Jia He 798 Huawei 800 Email: hejia@huawei.com