idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 194: '...of OAM functions SHOULD be optional fo...' RFC 2119 keyword, line 195: '...network operator SHOULD be able to cho...' RFC 2119 keyword, line 198: '...-TP control pane MUST support the conf...' RFC 2119 keyword, line 201: '.... OAM functions SHOULD be configurabl...' RFC 2119 keyword, line 221: '... operator MUST be able to configure ...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5525 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 154, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'RFC3469' is defined on line 591, 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 ** Obsolete normative reference: RFC 4420 (Obsoleted by RFC 5420) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 10, 2009 Nortel 6 J. He 7 Huawei 8 March 9, 2009 10 OAM Configuration Framework and Requirements for GMPLS RSVP-TE 11 draft-ietf-ccamp-oam-configuration-fwk-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 10, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Abstract 62 OAM is an integral part of transport connections, hence it is 63 required that OAM functions are activated/deactivated in sync with 64 connection commissioning/decommissioning; avoiding spurious alarms 65 and ensuring consistent operation. In certain technologies OAM 66 entities are inherently established once the connection is set up, 67 while other technologies require extra configuration to establish 68 and configure OAM entities. This document specifies extensions to 69 RSVP-TE to support the establishment and configuration of OAM 70 entities along with LSP signaling. 72 Requirements Language 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 10 83 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 10 84 3.2. LSP Attributes flags . . . . . . . . . . . . . . . . . . . 11 85 3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 12 86 3.4. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 13 87 3.5. OAM configuration errors . . . . . . . . . . . . . . . . . 13 88 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 18 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 Intellectual Property and Copyright Statements . . . . . . . . . . 22 96 1. Introduction 98 GMPLS is designed as an out-of-band control plane supporting dynamic 99 connection provisioning for any suitable data plane technology; 100 including spatial switching (e.g., incoming port or fiber to outgoing 101 port or fiber), wavelength-division multiplexing (e.g., DWDM), time- 102 division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet 103 Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS 104 Transport Profile (MPLS-TP). In most of these technologies there are 105 Operations and Management (OAM) functions employed to monitor the 106 health and performance of the connections and to trigger data plane 107 (DP) recovery mechanisms. Similarly to connections, OAM functions 108 follow general principles but also have some technology specific 109 characteristics. 111 OAM is an integral part of transport connections, hence it is 112 required that OAM functions are activated/deactivated in sync with 113 connection commissioning/decommissioning; avoiding spurious alarms 114 and ensuring consistent operation. In certain technologies OAM 115 entities are inherently established once the connection is set up, 116 while other technologies require extra configuration to establish 117 and configure OAM entities. In some situations the use of OAM 118 functions, like those of Fault- (FM) and Performance Management 119 (PM), may be optional confirming to actual network management 120 policies. Hence the network operator must be able to choose 121 which kind of OAM functions to apply to specific connections and 122 with what parameters the selected OAM functions should be configured 123 and operated. To achieve this objective OAM entities and specific 124 functions must be selectively configurable. 126 In general, it is required that the management plane and control 127 plane connection establishment mechanisms are synchronized with OAM 128 establishment and activation. In particular, if the GMPLS control 129 plane is employed it is desirable to bind OAM setup and configuration 130 to connection establishment signaling to avoid two separate 131 management/configuration steps (connection setup followed by OAM 132 configuration) which increases delay, processing and more importantly 133 may be prune to misconfiguration errors. Once OAM entities are setup 134 and configured pro-active as well as on-demand OAM functions can be 135 activated via the management plane. On the other hand, it should be 136 possible to activate/deactivate pro-active OAM functions via the 137 GMPLS control plane as well. 139 This document describes requirements on OAM configuration and control 140 via RSVP-TE, and specifies extensions to the RSVP-TE protocol 141 providing a framework to configure and control OAM entities along 142 with capability to carry technology specific information. Extensions 143 can be grouped into generic elements that are applicable to any OAM 144 solution and technology specific elements that provide additional 145 configuration parameters only needed for a specific OAM technology. 146 This document specifies the technology agnostic elements which alone 147 can be used to establish and control OAM entities in the case no 148 technology specific information is needed, and specifies the way 149 additional technology specific OAM parameters are provided. 151 The mechanisms described in this document provide an additional 152 option for bootstrapping OAM that is not intended to replace or 153 deprecate the use of other technology specific OAM bootstrapping 154 techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The 155 procedures specified in this document are intended only for use in 156 environments where RSVP-TE signaling is already in use to set up the 157 LSPs that are to be monitored using OAM. 159 2. Requirements 161 MPLS OAM requirements are described in [RFC4377]. It provides 162 requirements to create consistent OAM functionality for MPLS 163 networks. GMPLS OAM requirements are described in [GMPLS-OAM]. The 164 GMPLS OAM requirements are based on the MPLS OAM requirements 165 [RFC4377], in addition it also considers the existing OAM techniques 166 in non-packet networks. 168 The following list is an excerpt of MPLS OAM requirements documented 169 in [RFC4377]. Only a few requirements are discussed that bear a 170 direct relevance to the discussion set forth in this document. 172 o It is desired to support the automation of LSP defect detection. 173 It is especially important in cases where large numbers of LSPs 174 might be tested. 176 o In particular some LSPs may require automated ingress-LSR to 177 egress-LSR testing functionality, while others may not. 179 o Mechanisms are required to coordinate network responses to 180 defects. Such mechanisms may include alarm suppression, 181 translating defect signals at technology boundaries, and 182 synchronizing defect detection times by setting appropriately 183 bounded detection timeframes. 185 MPLS-TP defines a profile of MPLS targeted at transport applications 186 [MPLS-TP-FWK]. This profile specifies the specific MPLS 187 characteristics and extensions required to meet transport 188 requirements, including providing additional OAM, survivability and 189 other maintenance functions not currently supported by MPLS. 190 Specific OAM requirements for MPLS-TP are specified in 191 [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane 192 to configure and control OAM entities. 194 o The use of OAM functions SHOULD be optional for the operator. A 195 network operator SHOULD be able to choose which OAM functions to 196 use and which Maintenance Entity to apply them to. 198 o The MPLS-TP control pane MUST support the configuration and 199 modification of OAM maintenance points as well as the activation/ 200 deactivation of OAM when the transport path is established or 201 modified. OAM functions SHOULD be configurable as part of 202 connectivity (LSP or PW) management. 204 Ethernet Connectivity Fault Management (CFM) defines an adjunct 205 connectivity monitoring OAM flow to check the liveliness of Ethernet 206 networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will 207 support explicitly-routed Ethernet connections. CFM can be used to 208 track the liveliness of PBB-TE connections and detect data plane 209 failures. In IETF the GMPLS controlled Ethernet Label Switching 210 (GELS) [GELS-Framework] work is extending the GMPLS control plane to 211 support the establishment of point-to-point PBB-TE data plane 212 connections. Without control plane support separate management 213 commands would be needed to configure and start CFM. 215 GMPLS based OAM configuration and control should be general to be 216 applicable to a wide range of data plane technologies and OAM 217 solution. There are three typical data plane technologies used for 218 transport application, which are wavelength based such as WSON, TDM 219 based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK] 220 and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the 221 operator MUST be able to configure and control the following OAM 222 functions. 224 o It MUST be possible to explicitly request the setup of OAM 225 entities for the signaled LSP and provide specific information for 226 the setup if this is required by the technology. 228 o Control of alarms is important to avoid false alarm indications 229 and reporting to the management system. It MUST be possible to 230 enable/disable alarms generated by OAM functions. In some cases 231 selective alarm control may be desirable when, for instance, the 232 operator is only concerned about critical alarms thus the non- 233 service affecting alarms should be inhibited. 235 o When periodic messages are used for liveliness check (continuity 236 check) of LSPs it MUST be possible to set the frequency of 237 messages allowing proper configuration for fulfilling the 238 requirements of the service and/or meeting the detection time 239 boundaries posed by possible congruent connectivity check 240 operations of higher layer applications. For a network operator 241 to be able to balance the trade-off in fast failure detection and 242 overhead it is beneficial to configure the frequency of continuity 243 check messages on a per LSP basis. 245 o Pro-active Performance Monitoring (PM) functions are continuously 246 collecting information about specific characteristics of the 247 connection. For consistent measurement of Service Level 248 Agreements (SLAs) it may be required that measurement points agree 249 on a common probing rate to avoid measurement problems. 251 o The extensions must allow the operator to use only a minimal set 252 of OAM configuration and control features if the data plane 253 technology, the OAM solution or network management policy allows. 254 The extensions must be reusable as much as reasonably possible. 256 That is generic OAM parameters and data plane or OAM technology 257 specific parameters must be separated. 259 3. GMPLS RSVP-TE Extensions 261 3.1. Operation overview 263 In general, two types of Maintenance Poits (MPs) can be 264 distinguished: Maintenance End Points (MEPs) and Maintenance 265 Intermediate Points (MIPs). MEPs are located at the ends of an LSP 266 and are capable of initiating and terminating OAM messages for Fault 267 Management (FM) and Performance Monitoring (PM). MIPs on the other 268 hand are located at transit nodes of an LSP and are capable of 269 reacting to some OAM messages but otherwise do not initiate messages. 270 Maintenance Entity (ME) refers to an association of MEPs and MIPs 271 that are provisioned to monitor an LSP. The ME association is 272 achieved by configuring MPs of an ME with the same unique ME 273 Assocication ID (MA ID). Each MEP must have unique identification 274 (MEP ID) within a Maintenance Entity. 276 When an LSP is signaled forwarding association is established between 277 endpoints and transit nodes via label bindings. This association 278 creates a context for the OAM entities monitoring the LSP. On top of 279 this association OAM entities may be configured with an MA ID and MEP 280 IDs. The MA ID may be used to detect misconfiguration errors and 281 leaking OAM traffic. While the MEP ID can be used to demultiplex and 282 identify the originating MEP of OAM messages. Since MIPs do not 283 originate OAM packets, on top of the configuration of Maintenance 284 Entity associations, no specific configuration is required for them. 286 In addition to the MA and MEP identification parameters pro-active 287 OAM functions (e.g., Continuity Check (CC), Performance Monitoring) 288 may have specific parameters requiring configuration as well. In 289 particular, the frequency of periodic CC packets and the measurement 290 interval for loss and delay measurements may need to be configured. 292 MEP 293 +-------------+ 294 |OAM Functions| 295 | FM | PM | 296 +------+------+ 297 | MEP ID | 298 +-------------+ 299 | MA ID | 300 +-------------+ 301 +-------------+ 302 | connection | 303 +-------------+ 305 In some cases all the above parameters may be either derived form 306 some exiting information or pre-configured default values can be 307 used. In the simplest case the control plane needs to provide 308 information whether or not a MA with MPs need to be setup for the 309 signaled LSP. If OAM entities are created signaling must provide 310 means to activate/deactivate OAM message flows and associated alarms. 312 MA and MEP IDs as well as configuration of OAM functions are 313 technology specific, i.e., vary depending on the data plane 314 technology and the chosen OAM solution. In addition, for any given 315 data plane technology a set of OAM solutions may be applicable. The 316 OAM configuration framework allows selecting a specific OAM solution 317 to be used for the signaled LSP and provides technology specific TLVs 318 to carry further detailed configuration information. 320 3.2. LSP Attributes flags 322 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 323 indicate options and attributes of the LSP. The Flags field has 8 324 bits and hence is limited to differentiate only 8 options. [RFC4420] 325 defines a new object for RSVP-TE messages to allow the signaling of 326 arbitrary attribute parameters making RSVP-TE easily extensible to 327 support new applications. Furthermore, [RFC4420] allows options and 328 attributes that do not need to be acted on by all Label Switched 329 Routers (LSRs) along the path of the LSP. In particular, these 330 options and attributes may apply only to key LSRs on the path such as 331 the ingress LSR and egress LSR. Options and attributes can be 332 signaled transparently, and only examined at those points that need 333 to act on them. The LSP_ATTRIBUTES object and the 334 LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide 335 means to signal LSP attributes and options in the form of TLVs. 336 Options and attributes signaled in the LSP_ATTRIBUTES object can be 337 passed transparently through LSRs not supporting a particular option 338 or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES 339 object must be examined and processed by each LSR. One TLV is 340 defined in [RFC4420]: the Attributes Flags TLV. 342 One bit (10 IANA to assign): "OAM MEP entities desired" is allocated 343 in the LSP Attributes Flags TLV. If the "OAM MEP entities desired" 344 bit is set it is indicating that the establishment of OAM MEP 345 entities are required at the endpoints of the signaled LSP. If the 346 establishment of MEPs is not supported an error must be generated: 347 "OAM Problem/MEP establishment not supported". 349 If the "OAM MEP entities desired" bit is set and additional 350 parameters are needed to configure the OAM entities an OAM 351 Configuration TLV may be included in the LSP_ATTRIBUTES object. 353 One bit (11 IANA to assign): "OAM MIP entities desired" is allocated 354 in the LSP Attributes Flags TLV. If the "OAM MIP entities desired" 355 bit is set it is indicating that the establishment of OAM MIP 356 entities are required at the transit nodes of the signaled LSP. This 357 bit can only be set if the "OAM MEP entities desired" bit is set. If 358 the establishment of MIPs is not supported an error must be 359 generated: "OAM Problem/MIP establishment not supported". 361 One bit (12 IANA to assign): "Alarm indication desired" is allocated 362 in the LSP Attributes Flags TLV. If the "Alarm indication desired" 363 bit is set it is indicating that the OAM entities of the signaled LSP 364 should be notified of lower layer failures. In the case of 365 hierarchical LSPs this will create an association between the 366 underlying (server) LSP's OAM entities and the currently signaled 367 (client) LSP's OAM entities. 369 3.3. OAM Configuration TLV 371 This TLV specifies which OAM technology/method should be used for the 372 LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES 373 object in Path messages. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Type (2) (IANA) | Length | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | OAM Type | Reserved | OAM Function | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 ~ sub-TLVs ~ 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Type: indicates a new type: the OAM Configuration TLV (2) (IANA to 388 assign). 390 OAM Type: specifies the technology specify OAM method. If the 391 requested OAM method is not supported an error must be generated: 392 "OAM Problem/Unsupported OAM Type". 394 This document defines no types. The receiving node based on the OAM 395 Type will check if a corresponding technology specific OAM 396 configuration sub-TLV is included. If different technology specific 397 OAM configuration sub-TLV is included than what was specified in the 398 OAM Type an error must be generated: "OAM Problem/OAM Type Mismatch". 400 OAM Type Description 401 ------------ -------------------- 402 0-255 Reserved 404 There is a hierarchy in between the OAM configuration elements. 405 First, the "OAM MEP (and MIP) entities desired" flag needs to be set, 406 if it is set an "OAM Configuration TLV" may be included in the 407 LSP_ATTRIBUTES object, if this TLV is present based on the OAM Type a 408 technology specific OAM configuration sub-TLV may be present. If 409 this hierarchy is broken (e.g., "OAM MEP entities desired" flag is 410 not set but an OAM Configuration TLV is present an error must be 411 generated: "OAM Problem/Configuration Error". 413 OAM Function Flags: specifies pro-active OAM functions (e.g., 414 connectivity monitoring, loss and delay measurement) that should be 415 established and configured. If the selected OAM Function(s) is(are) 416 not supported an error must be generated: "OAM Problem/Unsupported 417 OAM Function". 419 This document defines the following flags. 421 OAM Function Flag Description 422 --------------------- --------------------------- 423 0 Connectivity Monitoring 424 1 Performance Monitoring/Loss 425 2 Performance Monitoring/Delay 427 3.4. Monitoring Disabled - Admin_Status bit 429 Administrative Status Information is carried in the ADMIN_STATUS 430 Object. The Administrative Status Information is described in 431 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 432 [RFC3473]. 434 One bit is allocated for the administrative control of OAM 435 monitoring. In addition to the Reflect (R) bit, 7 bits are currently 436 occupied (assigned by IANA or temporarily blocked by work in progress 437 Internet drafts). As the 24th bit (IANA to assign) this draft 438 introduces the Monitoring Disabled (M) bit. When this bit is set the 439 monitoring and OAM triggered alarms of the LSP are disabled (e.g., no 440 continuity check messages are sent, no AIS is generated). 442 3.5. OAM configuration errors 444 To handle OAM configuration errors a new Error Code (IANA to assign) 445 "OAM Problem" is introduced. To refer to specific problems a set of 446 Error Values is defined. 448 If a node does not support the establishment of OAM MEP or MIP 449 entities it must use the error value (IANA to assign): "MEP 450 establishment not supported" or "MIP establishment not supported" 451 respectively in the PathErr message. 453 If a node does not support a specific OAM technology/solution it must 454 use the error value (IANA to assign): "Unsupported OAM Type" in the 455 PathErr message. 457 If a different technology specific OAM configuration TLV is included 458 than what was specified in the OAM Type an error must be generated 459 with error value:"OAM Type Mismatch" in the PathErr message. 461 There is a hierarchy in between the OAM configuration elements. If 462 this hierarchy is broken an the error value: "OAM Problem/ 463 Configuration Error" must be used in the PathErr message. 465 If a node does not support a specific OAM Function it must use the 466 error value (IANA to assign): "Unsupported OAM Function" in the 467 PathErr message. 469 4. IANA Considerations 471 One bit (Monitoring Disabled (M)) needs to be allocated in the 472 ADMIN_STATUS Object. 474 One bit ("OAM entities desired") needs to be allocated in the LSP 475 Attributes Flag Registry. 477 This document specifies one new TLVs to be carried in the 478 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages: 479 OAM Configuration TLV. 481 One new Error Code: "OAM Problem" and three new values: "MEP 482 establishment not supported", "MIP establishment not supported", 483 "Unsupported OAM Type" and "Unsupported OAM Function" needs to be 484 assigned. 486 5. Security Considerations 488 The signaling of OAM related parameters and the automatic 489 establishment of OAM entities introduces additional security 490 considerations to those discussed in [RFC3473]. In particular, a 491 network element could be overloaded, if an attacker would request 492 liveliness monitoring, with frequent periodic messages, for a high 493 number of LSPs, targeting a single network element. 495 Security aspects will be covered in more detailed in subsequent 496 versions of this document. 498 6. Acknowledgements 500 The authors would like to thank Francesco Fondelli, Adrian Farrel, 501 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 502 comments. 504 Appendix A. Discussion on alternatives 506 This appendix summarizes the discussions after IETF-71 about the way 507 OAM configuration information should be carried in RSVP-TE. 509 The first question is how the requirement for OAM establishment is 510 signaled and how the operation of OAM is controlled. There is a 511 straightforward way to achieve these using existing objects and 512 fields: 514 o Use one or more OAM flags in the LSP Attributes Flag TLV within 515 the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that 516 OAM entities for the LSP need to be established. If for any 517 reason this cannot be done a notification is sent or an error is 518 raised. 520 o Once the LSP with the desired OAM entities is established OAM 521 operation may be controlled using one or more flags in the 522 ADMIN_STATUS object. For instance, the generation of connectivity 523 monitoring messages can be disabled/enabled by setting/clearing a 524 flag in the ADMIN_STATUS object. 526 However, there are two alternatives when it comes to signaling the 527 actual configuration parameters of OAM entities. 529 o Extension of the LSP_ATTRIBUTES object with new TLVs. 531 o Definition of a new RSVP-TE object to carry OAM information. 533 In the first case, a new OAM configuration TLV is defined in the 534 LSP_ATTRIBUTES object. This TLV would provide the detailed 535 information needed for LSPs with a set OAM flag in the LSP Attributes 536 Flag TLV. The rationale for this approach is that in addition to 537 setting flags the LSP_ATTRIBUTES object may carry complementary 538 information for all or some of the flags set. Furthermore, as top 539 level RSVP-TE objects may become scarce resources, it seems to be 540 beneficial not to allocate new RSVP-TE objects for the purpose of 541 providing detailed information for new LSP Attribute Flags. 542 Currently there is only one TLV, the Attributes Flag TLV, defined in 543 the LSP_ATTRIBUTES object. Defining a new TLV associated with one of 544 the flags would make a precedence and possibly be a guideline for 545 similar future extensions. 547 The other alternative would be to allocate a dedicated object for OAM 548 configuration information. The rationale for this is that the 549 complex information that may be required for OAM configuration would 550 unnecessarily add complexity to LSP_ATTRIBUTES/ 551 LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms. 553 Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to 554 carry configuration information of data plane entities, thus a new 555 object like an "OAM_SPEC" may be a better fit to existing protocol 556 elements. 558 The authors of this document favor the first alternative (adding new 559 TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which 560 alternative to select for standardization is up for the working group 561 to decide. In any case, the information to be carried would be the 562 same or very similar for both alternatives. 564 7. References 566 [GELS-Framework] 567 "GMPLS Ethernet Label Switching Architecture and 568 Framework", Internet Draft, work in progress. 570 [GMPLS-OAM] 571 "OAM Requirements for Generalized Multi-Protocol Label 572 Switching (GMPLS) Networks", Internet Draft, work in 573 progress. 575 [IEEE-CFM] 576 "IEEE 802.1ag, Draft Standard for Connectivity Fault 577 Management", work in progress. 579 [IEEE-PBBTE] 580 "IEEE 802.1Qay Draft Standard for Provider Backbone 581 Bridging Traffic Engineering", work in progress. 583 [MPLS-TP-FWK] 584 "A Framework for MPLS in Transport Networks", Internet 585 Draft, work in progress. 587 [MPLS-TP-OAM-REQ] 588 "Requirements for OAM in MPLS Transport Networks", 589 Internet Draft, work in progress. 591 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 592 Recovery", RFC 3469, February 2003. 594 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 595 Signaling Functional Description", RFC 3471, January 2003. 597 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 598 Signaling Resource ReserVation Protocol-Traffic 599 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 601 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 602 Protocol Label Switched (MPLS) Networks", RFC 4377, 603 February 2006. 605 [RFC4420] "Encoding of Attributes for Multiprotocol Label Switching 606 (MPLS) Label Switched Path (LSP) Establishment Using 607 Resource ReserVation Protocol-Traffic Engineering 608 (RSVP-TE)", RFC 4420, February 2006. 610 Authors' Addresses 612 Attila Takacs 613 Ericsson 614 Laborc u. 1. 615 Budapest, 1037 616 Hungary 618 Email: attila.takacs@ericsson.com 620 Don Fedyk 621 Nortel 622 600 Technology Park Drive 623 Billerica, MA 01821 624 USA 626 Email: dwfedyk@nortel.com 628 Jia He 629 Huawei 631 Email: hejia@huawei.com