idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 193: '...of OAM functions SHOULD be optional fo...' RFC 2119 keyword, line 194: '...network operator SHOULD be able to cho...' RFC 2119 keyword, line 197: '...TP control plane MUST support the conf...' RFC 2119 keyword, line 200: '.... OAM functions SHOULD be configurabl...' RFC 2119 keyword, line 209: '... operator MUST be able to configure ...' (36 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, it 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 (January 28, 2010) is 5201 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) == Missing Reference: 'RFC4379' is mentioned on line 156, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'GELS-Framework' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'GMPLS-OAM' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'IEEE-CFM' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC3469' is defined on line 718, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GELS-Framework' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OAM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-CFM' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-PBBTE' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-TP-FWK' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-TP-OAM-REQ' ** Downref: Normative reference to an Informational RFC: RFC 3469 ** Downref: Normative reference to an Informational RFC: RFC 4377 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: August 1, 2010 Alcatel-Lucent 6 J. He 7 Huawei 8 January 28, 2010 10 OAM Configuration Framework and Requirements for GMPLS RSVP-TE 11 draft-ietf-ccamp-oam-configuration-fwk-03 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 to IETF 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), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 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 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on August 1, 2010. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. GMPLS based OAM Configuration . . . . . . . . . . . . . . . . 8 74 3.1. Establishment of OAM Entities and Functions . . . . . . . 8 75 3.2. Adjustment of OAM Parameters . . . . . . . . . . . . . . . 10 76 3.3. Deleting OAM Entities . . . . . . . . . . . . . . . . . . 10 77 4. RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 12 78 4.1. LSP Attributes Flags . . . . . . . . . . . . . . . . . . . 12 79 4.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12 80 4.2.1. OAM Function Flags Sub-TLV . . . . . . . . . . . . . . 14 81 4.2.2. Technology Specific sub-TLVs . . . . . . . . . . . . . 14 82 4.3. Administrative Status Information . . . . . . . . . . . . 14 83 4.4. Handling OAM Configuration Errors . . . . . . . . . . . . 15 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 87 Appendix A. Discussion on Alternatives . . . . . . . . . . . . . 19 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 91 1. Introduction 93 GMPLS is designed as an out-of-band control plane supporting dynamic 94 connection provisioning for any suitable data plane technology; 95 including spatial switching (e.g., incoming port or fiber to outgoing 96 port or fiber), wavelength-division multiplexing (e.g., DWDM), time- 97 division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet 98 Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS 99 Transport Profile (MPLS-TP). In most of these technologies there are 100 Operations and Management (OAM) functions employed to monitor the 101 health and performance of the connections and to trigger data plane 102 (DP) recovery mechanisms. Similarly to connections, OAM functions 103 follow general principles but also have some technology specific 104 characteristics. 106 OAM is an integral part of transport connections, hence it is 107 required that OAM functions are activated/deactivated in sync with 108 connection commissioning/decommissioning; avoiding spurious alarms 109 and ensuring consistent operation. In certain technologies OAM 110 entities are inherently established once the connection is set up, 111 while other technologies require extra configuration to establish and 112 configure OAM entities. In some situations the use of OAM functions, 113 like those of Fault- (FM) and Performance Management (PM), may be 114 optional confirming to actual network management policies. Hence the 115 network operator must be able to choose which kind of OAM functions 116 to apply to specific connections and with what parameters the 117 selected OAM functions should be configured and operated. To achieve 118 this objective OAM entities and specific functions must be 119 selectively configurable. 121 In general, it is required that the management plane and control 122 plane connection establishment mechanisms are synchronized with OAM 123 establishment and activation. In particular, if the GMPLS control 124 plane is employed it is desirable to bind OAM setup and configuration 125 to connection establishment signaling to avoid two separate 126 management/configuration steps (connection setup followed by OAM 127 configuration) which increases delay, processing and more importantly 128 may be prune to misconfiguration errors. Once OAM entities are setup 129 and configured, pro-active as well as on-demand OAM functions can be 130 activated via the management plane. On the other hand, it should be 131 possible to activate/deactivate pro-active OAM functions via the 132 GMPLS control plane as well. 134 This document describes requirements on OAM configuration and control 135 via RSVP-TE, and specifies extensions to the RSVP-TE protocol 136 providing a framework to configure and control OAM entities along 137 with the capability to carry technology specific information. 138 Extensions can be grouped into generic elements that are applicable 139 to any OAM solution and technology specific elements that provide 140 additional configuration parameters, only needed for a specific OAM 141 technology. This document specifies the technology agnostic 142 elements, which alone can be used to establish and control OAM 143 entities in the case no technology specific information is needed, 144 and specifies the way additional technology specific OAM parameters 145 are provided. 147 This document addresses end-to-end OAM configuration, that is, the 148 setup of OAM entities bound to an end-to-end LSP, and configuration 149 and control of OAM functions running end-to-end in the LSP. 150 Configuration of OAM entities for LSP segments and tandem connections 151 are out of the scope of this document. 153 The mechanisms described in this document provide an additional 154 option for bootstrapping OAM that is not intended to replace or 155 deprecate the use of other technology specific OAM bootstrapping 156 techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The 157 procedures specified in this document are intended only for use in 158 environments where RSVP-TE signaling is already in use to set up the 159 LSPs that are to be monitored using OAM. 161 2. Requirements 163 MPLS OAM requirements are described in [RFC4377], which provides 164 requirements to create consistent OAM functionality for MPLS 165 networks. 167 The following list is an excerpt of MPLS OAM requirements documented 168 in [RFC4377]. Only a few requirements are discussed that bear a 169 direct relevance to the discussion set forth in this document. 171 o It is desired to support the automation of LSP defect detection. 172 It is especially important in cases where large numbers of LSPs 173 might be tested. 175 o In particular some LSPs may require automated ingress-LSR to 176 egress-LSR testing functionality, while others may not. 178 o Mechanisms are required to coordinate network responses to 179 defects. Such mechanisms may include alarm suppression, 180 translating defect signals at technology boundaries, and 181 synchronizing defect detection times by setting appropriately 182 bounded detection timeframes. 184 MPLS-TP defines a profile of MPLS targeted at transport applications 185 [MPLS-TP-FWK]. This profile specifies the specific MPLS 186 characteristics and extensions required to meet transport 187 requirements, including providing additional OAM, survivability and 188 other maintenance functions not currently supported by MPLS. 189 Specific OAM requirements for MPLS-TP are specified in 190 [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane 191 to configure and control OAM entities: 193 o The use of OAM functions SHOULD be optional for the operator. A 194 network operator SHOULD be able to choose which OAM functions to 195 use and which Maintenance Entity to apply them to. 197 o The MPLS-TP control plane MUST support the configuration and 198 modification of OAM maintenance points as well as the activation/ 199 deactivation of OAM when the transport path is established or 200 modified. OAM functions SHOULD be configurable as part of 201 connectivity (LSP or PW) management. 203 GMPLS based OAM configuration and control should be general to be 204 applicable to a wide range of data plane technologies and OAM 205 solutions. There are three typical data plane technologies used for 206 transport application, which are wavelength based such as WSON, TDM 207 based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK] 208 and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the 209 operator MUST be able to configure and control the following OAM 210 functions. 212 o It MUST be possible to explicitly request the setup of OAM 213 entities for the signaled LSP and provide specific information for 214 the setup if this is required by the technology. 216 o Control of alarms is important to avoid false alarm indications 217 and reporting to the management system. It MUST be possible to 218 enable/disable alarms generated by OAM functions. In some cases 219 selective alarm control may be desirable when, for instance, the 220 operator is only concerned about critical alarms thus the non- 221 service affecting alarms should be inhibited. 223 o When periodic messages are used for liveliness check (continuity 224 check) of LSPs it MUST be possible to set the frequency of 225 messages allowing proper configuration for fulfilling the 226 requirements of the service and/or meeting the detection time 227 boundaries posed by possible congruent connectivity check 228 operations of higher layer applications. For a network operator 229 to be able to balance the trade-off in fast failure detection and 230 overhead it is beneficial to configure the frequency of continuity 231 check messages on a per LSP basis. 233 o Pro-active Performance Monitoring (PM) functions are continuously 234 collecting information about specific characteristics of the 235 connection. For consistent measurement of Service Level 236 Agreements (SLAs) it may be required that measurement points agree 237 on a common probing rate to avoid measurement problems. 239 o The extensions MUST allow the operator to use only a minimal set 240 of OAM configuration and control features if the data plane 241 technology, the OAM solution or network management policy allows. 242 The extensions must be reusable as much as reasonably possible. 243 That is generic OAM parameters and data plane or OAM technology 244 specific parameters must be separated. 246 3. GMPLS based OAM Configuration 248 In general, two types of Maintenance Poits (MPs) can be 249 distinguished: Maintenance End Points (MEPs) and Maintenance 250 Intermediate Points (MIPs). MEPs reside at the ends of an LSP and 251 are capable of initiating and terminating OAM messages for Fault 252 Management (FM) and Performance Monitoring (PM). MIPs on the other 253 hand are located at transit nodes of an LSP and are capable of 254 reacting to some OAM messages but otherwise do not initiate messages. 255 Maintenance Entity (ME) refers to an association of MEPs and MIPs 256 that are provisioned to monitor an LSP. The ME association is 257 achieved by configuring MPs to belong to the same ME. 259 When an LSP is signaled, forwarding association is established 260 between endpoints and transit nodes via label bindings. This 261 association creates a context for the OAM entities monitoring the 262 LSP. On top of this association OAM entities may be configured to 263 unambigously identify MPs and MEs. 265 In addition to MP and ME identification parameters pro-active OAM 266 functions (e.g., Continuity Check (CC), Performance Monitoring) may 267 have specific parameters requiring configuration as well. In 268 particular, the frequency of periodic CC packets and the measurement 269 interval for loss and delay measurements may need to be configured. 271 In some cases all the above parameters may be either derived form 272 some exiting information or pre-configured default values can be 273 used. In the simplest case the control plane needs to provide 274 information whether or not OAM entities need to be setup for the 275 signaled LSP. If OAM entities are created signaling must provide 276 means to activate/deactivate OAM message flows and associated alarms. 278 OAM identifiers as well as the configuration of OAM functions are 279 technology specific, i.e., vary depending on the data plane 280 technology and the chosen OAM solution. In addition, for any given 281 data plane technology a set of OAM solutions may be applicable. The 282 OAM configuration framework allows selecting a specific OAM solution 283 to be used for the signaled LSP and provides technology specific TLVs 284 to carry further detailed configuration information. 286 3.1. Establishment of OAM Entities and Functions 288 In order to avoid spurious alarms OAM functions must be setup and 289 enabled in the appropriate order. When using the GMPLS control 290 plane, establishment and enabling of OAM functions must be bound to 291 RSVP-TE message exchanges. 293 An LSP may be signaled and established without OAM configuration 294 first, and OAM entities may be added later with a subsequent re- 295 signaling of the LSP. Alternatively, the LSP may be setup with OAM 296 entities right with the first signaling of the LSP. The below 297 procedures apply to both cases. 299 Before the initiator first sends a Path messages with OAM 300 Configuration information, it MUST establish and configure the 301 corresponding OAM entities locally, however OAM source functions MUST 302 NOT start sending any OAM messages. In the case of bidirectional 303 connections, the initiator node MUST setup the OAM sink function to 304 be prepared to receive OAM messages but MUST suppress any OAM alarms 305 (e.g., due to missing or unidentified OAM messages). The Path 306 message MUST be sent with the "OAM Alarms Enabled" ADMIN_STATUS flag 307 cleared, i.e, data plane OAM alarms are suppressed. 309 When the Path message arrives at the receiver, the remote end MUST 310 establish and configure OAM entities according to the OAM information 311 provided in Path message. If this is not possible a PathErr SHOULD 312 be sent and neither the OAM entities nor the LSP SHOULD be 313 established. If OAM entities are established successfully, the OAM 314 sink function MUST be prepared to receive OAM messages but MUST not 315 generate any OAM alarms (e.g., due to missing or unidentified OAM 316 messages). In the case of bidirectional connections, an OAM source 317 function MUST be setup and, according to the requested configuration, 318 it MUST start sending OAM messages. Then a Resv message is sent 319 back, including the OAM Configuration TLV that corresponds to the 320 actually established and configured OAM entities and functions. 321 Depending on the OAM technology, some elements of the OAM 322 Configuration TLV MAY be updated/changed; i.e., if the remote end is 323 not supporting a certain OAM configuration it may suggest an 324 alternative setting, which may or may not be accepted by the 325 initiator of the Path message. If it is accepted, the initiator will 326 reconfigure its OAM functions according to the information received 327 in the Resv message. If the alternate setting is not acceptable a 328 ResvErr may be sent tearing down the LSP. Details of this operation 329 are technology specific and should be described in accompanying 330 technology specific documents. 332 When the initiating side receives the Resv message it completes any 333 pending OAM configuration and enables the OAM source function to send 334 OAM messages. 336 After this round, OAM entities are established and configured for the 337 LSP and OAM messages MAY already be exchanged. OAM alarms can now be 338 enabled. The initiator, while still keeping OAM alarms disabled 339 sends a Path message with "OAM Alarms Enabled" ADMIN_STATUS flag set. 340 The receiving node enables the OAM alarms after processing the Path 341 message. The initiator enables OAM alarms after it receives the Resv 342 message. Data plane OAM is now fully functional. 344 3.2. Adjustment of OAM Parameters 346 There may be a need to change the parameters of an already 347 established and configured OAM function during the lifetime of the 348 LSP. To do so the LSP needs to be re-signaled with the updated 349 parameters. OAM parameters influence the content and timing of OAM 350 messages and identify the way OAM defects and alarms are derived and 351 generated. Hence, to avoid spurious alarms, it is important that 352 both sides, OAM sink and source, are updated in a synchronized way. 353 First, the alarms of the OAM sink function should be suppressed and 354 only then should expected OAM parameters be adjusted. Subsequently, 355 the parameters of the OAM source function can be updated. Finally, 356 the alarms of the OAM sink side can be enabled again. 358 In accordance with the above operation, the LSP MUST first be re- 359 signaled with "OAM Alarms Enabled" ADMIN_STATUS flag cleared and 360 including the updated OAM Configuration TLV corresponding to the new 361 parameter settings. The initiator MUST keep its OAM sink and source 362 functions running unmodified, but it MUST suppress OAM alarms after 363 the updated Path message is sent. The receiver MUST first disable 364 all OAM alarms, then update the OAM paramaters according to the 365 information in the Path message and reply with a Resv message 366 acknowledging the changes by including the OAM Configuration TLV. 367 Note that the receiving side has the possibility to adjust the 368 requested OAM configuration parameters and reply with and updated OAM 369 Configuration TLV in the Resv message, reflecting the actually 370 configured values. However, in order to avoid an extensive 371 negotiation phase, in the case of adjusting already configured OAM 372 functions, the receiving side SHOULD NOT update the parameters 373 requested in the Path message to an extent that would provide lower 374 performance than what has been configured previously. 376 The initiator MUST only update its OAM sink and source functions 377 after it received the Resv message. After this Path/Resv message 378 exchange (in both unidirectional and bidirectional LSP cases) the OAM 379 parameters are updated and OAM is running according the new parameter 380 settings. However OAM alarms are still disabled. A subsequent Path/ 381 Resv message exchange with "OAM Alarms Enabled" ADMIN_STATUS flag set 382 is needed to enable OAM alarms again. 384 3.3. Deleting OAM Entities 386 In some cases it may be useful to remove some or all OAM entities and 387 functions from an LSP without actually tearing down the connection. 389 To avoid any spurious alarm, first the LSP SHOULD be re-signaled with 390 "OAM Alarms" ADMIN_STATUS flag cleared but unchanged OAM 391 configuration. Subsequently, the LSP is re-signaled with "OAM MEP 392 Entities desired" and "OAM MIP Entities desired" LSP ATTRIBUTES flags 393 cleared, and without the OAM Configuration TLV, this MUST result in 394 the deletion of all OAM entities associated with the LSP. All 395 control and data plane resources in use by the OAM entities and 396 functions SHOULD be freed up. Alternatively, if only some OAM 397 functions need to be removed, the LSP is re-signalled with the 398 updated OAM Configuration TLV. Changes between the contents of the 399 previously signalled OAM Configuration TLV and the currently received 400 TLV represent which functions SHOULD be removed/added. 402 First, OAM source functions SHOULD be deleted and only after that 403 SHOULD the associated OAM sink functions be removed, this will ensure 404 that OAM messages do not leak outside the LSP. To this end the 405 initiator, before sending the Path message, SHOULD remove the OAM 406 source, hence terminating the OAM message flow associated to the 407 downstream direction. In the case of a bidirectional connection, it 408 SHOULD leave in place the OAM sink functions associated to the 409 upstream direction. The remote end, after receiving the Path 410 message, SHOULD remove all associated OAM entities and functions and 411 reply with a Resv message without an OAM Configuration TLV. The 412 initiator completely removes OAM entities and functions after the 413 Resv message arrived. 415 4. RSVP-TE Extensions 417 4.1. LSP Attributes Flags 419 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 420 indicate options and attributes of the LSP. The Flags field has 8 421 bits and hence is limited to differentiate only 8 options. [RFC5420] 422 defines new objects for RSVP-TE messages to allow the signaling of 423 arbitrary attribute parameters making RSVP-TE easily extensible to 424 support new applications. Furthermore, [RFC5420] allows options and 425 attributes that do not need to be acted on by all Label Switched 426 Routers (LSRs) along the path of the LSP. In particular, these 427 options and attributes may apply only to key LSRs on the path such as 428 the ingress LSR and egress LSR. Options and attributes can be 429 signaled transparently, and only examined at those points that need 430 to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES 431 objects are defined in [RFC5420] to provide means to signal LSP 432 attributes and options in the form of TLVs. Options and attributes 433 signaled in the LSP_ATTRIBUTES object can be passed transparently 434 through LSRs not supporting a particular option or attribute, while 435 the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined 436 and processed by each LSR. One TLV is defined in [RFC5420]: the 437 Attributes Flags TLV. 439 One bit (10 IANA to assign): "OAM MEP entities desired" is allocated 440 in the LSP Attributes Flags TLV. If the "OAM MEP entities desired" 441 bit is set it is indicating that the establishment of OAM MEP 442 entities are required at the endpoints of the signaled LSP. If the 443 establishment of MEPs is not supported an error must be generated: 444 "OAM Problem/MEP establishment not supported". 446 If the "OAM MEP entities desired" bit is set and additional 447 parameters are needed to be configured the OAM entities an OAM 448 Configuration TLV may be included in the LSP_ATTRIBUTES object. 450 One bit (11 IANA to assign): "OAM MIP entities desired" is allocated 451 in the LSP Attributes Flags TLV. This bit can only be set if the 452 "OAM MEP entities desired" bit is set. If the "OAM MIP entities 453 desired" bit is set in the LSP_ATTRIBUTES Flags TLV, it is indicating 454 that the establishment of OAM MIP entities is required at every 455 transit node of the signalled LSP. If the establishment of a MIP is 456 not supported an error must be generated: "OAM Problem/MIP 457 establishment not supported". 459 4.2. OAM Configuration TLV 461 This TLV provides information about which OAM technology/method 462 should be used and carries sub-TLVs for any additional OAM 463 configuration information. The OAM Configuration TLV may be carried 464 in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and 465 Resv messages. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Type (2) (IANA) | Length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | OAM Type | Reserved | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | 475 ~ sub-TLVs ~ 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Type: indicates a new type: the OAM Configuration TLV (2) (IANA to 480 assign). 482 OAM Type: specifies the technology specific OAM method. If the 483 requested OAM method is not supported an error must be generated: 484 "OAM Problem/Unsupported OAM Type". 486 OAM Type Description 487 ------------ -------------------- 488 0-255 Reserved 490 This document defines no types. IANA is requests to maintain the 491 values in a new "RSVP-TE OAM Configuration Registry". 493 The receiving node based on the OAM Type will check if a 494 corresponding technology specific OAM configuration sub-TLV is 495 included. If the included technology specific OAM configuration sub- 496 TLV is different than what is specified in the OAM Type an error must 497 be generated: "OAM Problem/OAM Type Mismatch". 499 Note that there is a hierarchical dependency in between the OAM 500 configuration elements. First, the "OAM MEP (and MIP) entities 501 desired" flag needs to be set. When it is set an "OAM Configuration 502 TLV" may be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 503 Object. When this TLV is present, based on the "OAM Type" field, it 504 may carry a technology specific OAM configuration sub-TLV. If this 505 hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set 506 but an OAM Configuration TLV is present) an error must be generated: 507 "OAM Problem/Configuration Error". 509 4.2.1. OAM Function Flags Sub-TLV 511 As the first sub-TLV one "OAM Function Flags sub-TLV" MUST be always 512 included in the "OAM Configuration TLV". "OAM Function Flags" 513 specifies which pro-active OAM functions (e.g., connectivity 514 monitoring, loss and delay measurement) and which fault management 515 signals MUST be established and configured. If the selected OAM 516 Function(s) is(are) not supported, an error must be generated: "OAM 517 Problem/Unsupported OAM Function". 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Type (1) (IANA) | Length | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 ~ OAM Function Flags ~ 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 This document defines the following flags. 531 OAM Function Flag Description 532 --------------------- --------------------------- 533 0 Continuity Check (CC) 534 1 Connectivity Verification (CV) 535 2 Performance Monitoring/Loss (PM/Loss) 536 3 Performance Monitoring/Delay (PM/Delay) 538 4.2.2. Technology Specific sub-TLVs 540 One technology specific sub-TLV SHOULD be defined for each "OAM 541 Type". This sub-TLV MUST contain any further OAM configuration 542 information for that specific "OAM Type". The technology specific 543 sub-TLV may be carried within the OAM Configuration TLV. 545 4.3. Administrative Status Information 547 Administrative Status Information is carried in the ADMIN_STATUS 548 Object. The Administrative Status Information is described in 549 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 550 [RFC3473]. 552 Two bits are allocated for the administrative control of OAM 553 monitoring. In addition to the Reflect (R) bit, 7 bits are currently 554 occupied (assigned by IANA or temporarily blocked by work in progress 555 Internet drafts). As the 24th and 25th bits (IANA to assign) this 556 draft introduces the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" 557 (O) bits. When the "OAM Flows Enabled" bit is set, OAM packets are 558 sent if it is cleared no OAM packets are emitted. When the "OAM 559 Alarms Enabled" bit is set OAM triggered alarms are enabled and 560 associated consequent actions are executed including the notification 561 of the management system. When this bit is cleared, alarms are 562 suppressed and no action is executed and the management system is not 563 notified. 565 4.4. Handling OAM Configuration Errors 567 To handle OAM configuration errors a new Error Code (IANA to assign) 568 "OAM Problem" is introduced. To refer to specific problems a set of 569 Error Values is defined. 571 If a node does not support the establishment of OAM MEP or MIP 572 entities it must use the error value (IANA to assign): "MEP 573 establishment not supported" or "MIP establishment not supported" 574 respectively in the PathErr message. 576 If a node does not support a specific OAM technology/solution it must 577 use the error value (IANA to assign): "Unsupported OAM Type" in the 578 PathErr message. 580 If a different technology specific OAM configuration TLV is included 581 than what was specified in the OAM Type an error must be generated 582 with error value: "OAM Type Mismatch" in the PathErr message. 584 There is a hierarchy in between the OAM configuration elements. If 585 this hierarchy is broken the error value: "Configuration Error" must 586 be used in the PathErr message. 588 If a node does not support a specific OAM Function it must use the 589 error value: "Unsupported OAM Function" in the PathErr message. 591 5. IANA Considerations 593 Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs 594 to be allocated in the ADMIN_STATUS Object. 596 Two bits ("OAM MEP entities desired" and "OAM MIP entities desired") 597 needs to be allocated in the LSP Attributes Flags Registry. 599 This document specifies one new TLV to be carried in the 600 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv 601 messages: OAM Configuration TLV. 603 One new Error Code: "OAM Problem" and a set of new values: "MEP 604 establishment not supported", "MIP establishment not supported", 605 "Unsupported OAM Type", "Configuration Error" and "Unsupported OAM 606 Function" needs to be assigned. 608 The IANA is requested to open a new registry: "RSVP-TE OAM 609 Configuration Registry" that maintains the "OAM Type" code points and 610 the allocations of "OAM Function Flags" within the OAM Configuration 611 TLV. 613 6. Security Considerations 615 The signaling of OAM related parameters and the automatic 616 establishment of OAM entities introduces additional security 617 considerations to those discussed in [RFC3473]. In particular, a 618 network element could be overloaded, if an attacker would request 619 liveliness monitoring, with frequent periodic messages, for a high 620 number of LSPs, targeting a single network element. 622 Security aspects will be covered in more detailed in subsequent 623 versions of this document. 625 7. Acknowledgements 627 The authors would like to thank Francesco Fondelli, Adrian Farrel, 628 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 629 comments. 631 Appendix A. Discussion on Alternatives 633 This appendix summarizes the discussions after IETF-71 about the way 634 OAM configuration information should be carried in RSVP-TE. 636 The first question is how the requirement for OAM establishment is 637 signaled and how the operation of OAM is controlled. There is a 638 straightforward way to achieve these using existing objects and 639 fields: 641 o Use one or more OAM flags in the LSP Attributes Flag TLV within 642 the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that 643 OAM entities for the LSP need to be established. If for any 644 reason this cannot be done a notification is sent or an error is 645 raised. 647 o Once the LSP with the desired OAM entities is established OAM 648 operation may be controlled using one or more flags in the 649 ADMIN_STATUS object. For instance, the generation of connectivity 650 monitoring messages can be disabled/enabled by setting/clearing a 651 flag in the ADMIN_STATUS object. 653 However, there are two alternatives when it comes to signaling the 654 actual configuration parameters of OAM entities. 656 o Extension of the LSP_ATTRIBUTES object with new TLVs. 658 o Definition of a new RSVP-TE object to carry OAM information. 660 In the first case, a new OAM configuration TLV is defined in the 661 LSP_ATTRIBUTES object. This TLV would provide the detailed 662 information needed for LSPs with a set OAM flag in the LSP Attributes 663 Flag TLV. The rationale for this approach is that in addition to 664 setting flags the LSP_ATTRIBUTES object may carry complementary 665 information for all or some of the flags set. Furthermore, as top 666 level RSVP-TE objects may become scarce resources, it seems to be 667 beneficial not to allocate new RSVP-TE objects for the purpose of 668 providing detailed information for new LSP Attribute Flags. 669 Currently there is only one TLV, the Attributes Flag TLV, defined in 670 the LSP_ATTRIBUTES object. Defining a new TLV associated with one of 671 the flags would make a precedence and possibly be a guideline for 672 similar future extensions. 674 The other alternative would be to allocate a dedicated object for OAM 675 configuration information. The rationale for this is that the 676 complex information that may be required for OAM configuration would 677 unnecessarily add complexity to LSP_ATTRIBUTES/ 678 LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms. 680 Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to 681 carry configuration information of data plane entities, thus a new 682 object like an "OAM_SPEC" may be a better fit to existing protocol 683 elements. 685 The authors of this document favor the first alternative (adding new 686 TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which 687 alternative to select for standardization is up for the working group 688 to decide. In any case, the information to be carried would be the 689 same or very similar for both alternatives. 691 8. References 693 [GELS-Framework] 694 "GMPLS Ethernet Label Switching Architecture and 695 Framework", Internet Draft, work in progress. 697 [GMPLS-OAM] 698 "OAM Requirements for Generalized Multi-Protocol Label 699 Switching (GMPLS) Networks", Internet Draft, work in 700 progress. 702 [IEEE-CFM] 703 "IEEE 802.1ag, Draft Standard for Connectivity Fault 704 Management", work in progress. 706 [IEEE-PBBTE] 707 "IEEE 802.1Qay Draft Standard for Provider Backbone 708 Bridging Traffic Engineering", work in progress. 710 [MPLS-TP-FWK] 711 "A Framework for MPLS in Transport Networks", Internet 712 Draft, work in progress. 714 [MPLS-TP-OAM-REQ] 715 "Requirements for OAM in MPLS Transport Networks", 716 Internet Draft, work in progress. 718 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 719 Recovery", RFC 3469, February 2003. 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 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 729 Protocol Label Switched (MPLS) Networks", RFC 4377, 730 February 2006. 732 [RFC5420] "Encoding of Attributes for Multiprotocol Label Switching 733 (MPLS) Label Switched Path (LSP) Establishment Using 734 Resource ReserVation Protocol-Traffic Engineering 735 (RSVP-TE)", RFC 5420, February 2009. 737 Authors' Addresses 739 Attila Takacs 740 Ericsson 741 Laborc u. 1. 742 Budapest, 1037 743 Hungary 745 Email: attila.takacs@ericsson.com 747 Don Fedyk 748 Alcatel-Lucent 749 Groton, MA 01450 750 USA 752 Email: donald.fedyk@alcatel-lucent.com 754 Jia He 755 Huawei 757 Email: hejia@huawei.com