idnits 2.17.1 draft-ietf-ccamp-oam-configuration-fwk-02.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 182: '...of OAM functions SHOULD be optional fo...' RFC 2119 keyword, line 183: '...network operator SHOULD be able to cho...' RFC 2119 keyword, line 186: '...TP control plane MUST support the conf...' RFC 2119 keyword, line 189: '.... OAM functions SHOULD be configurabl...' RFC 2119 keyword, line 209: '... 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 date (October 26, 2009) is 5289 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 142, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'RFC3469' is defined on line 737, 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 (~~), 3 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: April 29, 2010 Alcatel-Lucent 6 J. He 7 Huawei 8 October 26, 2009 10 OAM Configuration Framework and Requirements for GMPLS RSVP-TE 11 draft-ietf-ccamp-oam-configuration-fwk-02 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 April 29, 2010. 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 in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 OAM is an integral part of transport connections, hence it is 50 required that OAM functions are activated/deactivated in sync with 51 connection commissioning/decommissioning; avoiding spurious alarms 52 and ensuring consistent operation. In certain technologies OAM 53 entities are inherently established once the connection is set up, 54 while other technologies require extra configuration to establish and 55 configure OAM entities. This document specifies extensions to 56 RSVP-TE to support the establishment and configuration of OAM 57 entities along with LSP signaling. 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 9 70 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 9 71 3.2. LSP Attributes flags . . . . . . . . . . . . . . . . . . . 10 72 3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 73 3.4. TCME Configuration TLV . . . . . . . . . . . . . . . . . . 13 74 3.5. NIME Configuration TLV . . . . . . . . . . . . . . . . . . 14 75 3.6. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 15 76 3.7. OAM configuration errors . . . . . . . . . . . . . . . . . 15 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 80 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 20 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 84 1. Introduction 86 GMPLS is designed as an out-of-band control plane supporting dynamic 87 connection provisioning for any suitable data plane technology; 88 including spatial switching (e.g., incoming port or fiber to outgoing 89 port or fiber), wavelength-division multiplexing (e.g., DWDM), time- 90 division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet 91 Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS 92 Transport Profile (MPLS-TP). In most of these technologies there are 93 Operations and Management (OAM) functions employed to monitor the 94 health and performance of the connections and to trigger data plane 95 (DP) recovery mechanisms. Similarly to connections, OAM functions 96 follow general principles but also have some technology specific 97 characteristics. 99 OAM is an integral part of transport connections, hence it is 100 required that OAM functions are activated/deactivated in sync with 101 connection commissioning/decommissioning; avoiding spurious alarms 102 and ensuring consistent operation. In certain technologies OAM 103 entities are inherently established once the connection is set up, 104 while other technologies require extra configuration to establish and 105 configure OAM entities. In some situations the use of OAM functions, 106 like those of Fault- (FM) and Performance Management (PM), may be 107 optional confirming to actual network management policies. Hence the 108 network operator must be able to choose which kind of OAM functions 109 to apply to specific connections and with what parameters the 110 selected OAM functions should be configured and operated. To achieve 111 this objective OAM entities and specific functions must be 112 selectively configurable. 114 In general, it is required that the management plane and control 115 plane connection establishment mechanisms are synchronized with OAM 116 establishment and activation. In particular, if the GMPLS control 117 plane is employed it is desirable to bind OAM setup and configuration 118 to connection establishment signaling to avoid two separate 119 management/configuration steps (connection setup followed by OAM 120 configuration) which increases delay, processing and more importantly 121 may be prune to misconfiguration errors. Once OAM entities are setup 122 and configured pro-active as well as on-demand OAM functions can be 123 activated via the management plane. On the other hand, it should be 124 possible to activate/deactivate pro-active OAM functions via the 125 GMPLS control plane as well. 127 This document describes requirements on OAM configuration and control 128 via RSVP-TE, and specifies extensions to the RSVP-TE protocol 129 providing a framework to configure and control OAM entities along 130 with capability to carry technology specific information. Extensions 131 can be grouped into generic elements that are applicable to any OAM 132 solution and technology specific elements that provide additional 133 configuration parameters only needed for a specific OAM technology. 134 This document specifies the technology agnostic elements which alone 135 can be used to establish and control OAM entities in the case no 136 technology specific information is needed, and specifies the way 137 additional technology specific OAM parameters are provided. 139 The mechanisms described in this document provide an additional 140 option for bootstrapping OAM that is not intended to replace or 141 deprecate the use of other technology specific OAM bootstrapping 142 techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The 143 procedures specified in this document are intended only for use in 144 environments where RSVP-TE signaling is already in use to set up the 145 LSPs that are to be monitored using OAM. 147 2. Requirements 149 MPLS OAM requirements are described in [RFC4377]. It provides 150 requirements to create consistent OAM functionality for MPLS 151 networks. GMPLS OAM requirements are described in [GMPLS-OAM]. The 152 GMPLS OAM requirements are based on the MPLS OAM requirements 153 [RFC4377], in addition it also considers the existing OAM techniques 154 in non-packet networks. 156 The following list is an excerpt of MPLS OAM requirements documented 157 in [RFC4377]. Only a few requirements are discussed that bear a 158 direct relevance to the discussion set forth in this document. 160 o It is desired to support the automation of LSP defect detection. 161 It is especially important in cases where large numbers of LSPs 162 might be tested. 164 o In particular some LSPs may require automated ingress-LSR to 165 egress-LSR testing functionality, while others may not. 167 o Mechanisms are required to coordinate network responses to 168 defects. Such mechanisms may include alarm suppression, 169 translating defect signals at technology boundaries, and 170 synchronizing defect detection times by setting appropriately 171 bounded detection timeframes. 173 MPLS-TP defines a profile of MPLS targeted at transport applications 174 [MPLS-TP-FWK]. This profile specifies the specific MPLS 175 characteristics and extensions required to meet transport 176 requirements, including providing additional OAM, survivability and 177 other maintenance functions not currently supported by MPLS. 178 Specific OAM requirements for MPLS-TP are specified in 179 [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane 180 to configure and control OAM entities. 182 o The use of OAM functions SHOULD be optional for the operator. A 183 network operator SHOULD be able to choose which OAM functions to 184 use and which Maintenance Entity to apply them to. 186 o The MPLS-TP control plane MUST support the configuration and 187 modification of OAM maintenance points as well as the activation/ 188 deactivation of OAM when the transport path is established or 189 modified. OAM functions SHOULD be configurable as part of 190 connectivity (LSP or PW) management. 192 Ethernet Connectivity Fault Management (CFM) defines an adjunct 193 connectivity monitoring OAM flow to check the liveliness of Ethernet 194 networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will 195 support explicitly-routed Ethernet connections. CFM can be used to 196 track the liveliness of PBB-TE connections and detect data plane 197 failures. In IETF the GMPLS controlled Ethernet Label Switching 198 (GELS) [GELS-Framework] work is extending the GMPLS control plane to 199 support the establishment of point-to-point PBB-TE data plane 200 connections. Without control plane support separate management 201 commands would be needed to configure and start CFM. 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 solution. 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. 244 That is generic OAM parameters and data plane or OAM technology 245 specific parameters must be separated. 247 3. GMPLS RSVP-TE Extensions 249 3.1. Operation overview 251 In general, two types of Maintenance Poits (MPs) can be 252 distinguished: Maintenance End Points (MEPs) and Maintenance 253 Intermediate Points (MIPs). MEPs are capable of initiating and 254 terminating OAM messages for Fault Management (FM) and Performance 255 Monitoring (PM). MIPs on the other hand are located at transit nodes 256 of an LSP and are capable of reacting to some OAM messages but 257 otherwise do not initiate messages. Maintenance Entity (ME) refers 258 to an association of MEPs and MIPs that are provisioned to monitor an 259 LSP. The ME association is achieved by configuring MPs of an ME with 260 the same unique ME Assocication ID (MA ID). Each MEP must have 261 unique identification (MEP ID) within a Maintenance Entity. 263 When an LSP is signaled forwarding association is established between 264 endpoints and transit nodes via label bindings. This association 265 creates a context for the OAM entities monitoring the LSP. On top of 266 this association OAM entities may be configured with an MA ID and MEP 267 IDs. The MA ID may be used to detect misconfiguration errors and 268 leaking OAM traffic. While the MEP ID can be used to demultiplex and 269 identify the originating MEP of OAM messages. Since MIPs do not 270 originate OAM packets, on top of the configuration of Maintenance 271 Entity associations, no specific configuration is required for them. 273 Along the LSP several Tandem Connections may be provisioned and 274 associated to the end-to-end connection. These Tandem Connections 275 may implement their own OAM monitoring entities. The Tandem 276 Connection Maintenance Entities (TCMEs) provide the same monitoring 277 capabilities for a segment of a connection as what is possible on an 278 end-to-end basis. As the endpoints of a TCME may be (and usually 279 are) intermediate nodes of an end-to-end LSP, the placement of TCME 280 ingress and egress endpoints must be explicitly identified. 282 Altough provisioned together with the end-to-end connection, each 283 TCME defines a new context for the OAM entities, which is independent 284 from the end-to-end connection. The MA ID and MEP IDs for a TCME are 285 within this new context. 287 When an LSP is signaled Non-Intrusive Maintenance Elements (NIME) may 288 be deployed along the path. These elements differ from the MIPs as 289 they implemetn egress MEP functions: they not only process OAM 290 messages but they can also trigger consequent actions, for instance, 291 initiate segment protection switching. The NIMEs belong to the OAM 292 entity context of the end-to-end LSP and, thus, the same MA ID is 293 applied. As the NIMEs are placed at intermediate nodes, their 294 placement must be explicitly indicated. 296 In addition to the MA and MEP identification parameters pro-active 297 OAM functions (e.g., Continuity Check (CC), Performance Monitoring) 298 may have specific parameters requiring configuration as well. In 299 particular, the frequency of periodic CC packets and the measurement 300 interval for loss and delay measurements may need to be configured. 302 MEP 303 +-------------+ 304 |OAM Functions| 305 | FM | PM | 306 +------+------+ 307 | MEP ID | 308 +-------------+ 309 | MA ID | 310 +-------------+ 311 +-------------+ 312 | connection | 313 +-------------+ 315 In some cases all the above parameters may be either derived form 316 some exiting information or pre-configured default values can be 317 used. In the simplest case the control plane needs to provide 318 information whether or not a MA with MPs need to be setup for the 319 signaled LSP. If OAM entities are created signaling must provide 320 means to activate/deactivate OAM message flows and associated alarms. 322 MA and MEP IDs as well as configuration of OAM functions are 323 technology specific, i.e., vary depending on the data plane 324 technology and the chosen OAM solution. In addition, for any given 325 data plane technology a set of OAM solutions may be applicable. The 326 OAM configuration framework allows selecting a specific OAM solution 327 to be used for the signaled LSP and provides technology specific TLVs 328 to carry further detailed configuration information. 330 3.2. LSP Attributes flags 332 In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to 333 indicate options and attributes of the LSP. The Flags field has 8 334 bits and hence is limited to differentiate only 8 options. [RFC4420] 335 defines new objects for RSVP-TE messages to allow the signaling of 336 arbitrary attribute parameters making RSVP-TE easily extensible to 337 support new applications. Furthermore, [RFC4420] allows options and 338 attributes that do not need to be acted on by all Label Switched 339 Routers (LSRs) along the path of the LSP. In particular, these 340 options and attributes may apply only to key LSRs on the path such as 341 the ingress LSR and egress LSR. Options and attributes can be 342 signaled transparently, and only examined at those points that need 343 to act on them. The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES 344 objects are defined in [RFC4420] to provide means to signal LSP 345 attributes and options in the form of TLVs. Options and attributes 346 signaled in the LSP_ATTRIBUTES object can be passed transparently 347 through LSRs not supporting a particular option or attribute, while 348 the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined 349 and processed by each LSR. One TLV is defined in [RFC4420]: the 350 Attributes Flags TLV. 352 One bit (10 IANA to assign): "OAM MEP entities desired" is allocated 353 in the LSP Attributes Flags TLV. If the "OAM MEP entities desired" 354 bit is set it is indicating that the establishment of OAM MEP 355 entities are required at the endpoints of the signaled LSP. If the 356 establishment of MEPs is not supported an error must be generated: 357 "OAM Problem/MEP establishment not supported". 359 If the "OAM MEP entities desired" bit is set and additional 360 parameters are needed to configure the OAM entities an OAM 361 Configuration TLV may be included in the LSP_ATTRIBUTES object. 363 One bit (11 IANA to assign): "OAM MIP entities desired" is allocated 364 in the LSP Attributes Flags TLV. If the "OAM MIP entities desired" 365 bit is set it is indicating that the establishment of OAM MIP 366 entities are required at the transit nodes of the signaled LSP. This 367 bit can only be set if the "OAM MEP entities desired" bit is set. If 368 the establishment of MIPs is not supported an error must be 369 generated: "OAM Problem/MIP establishment not supported". 371 One bit (12 IANA to assign): "Alarm indication desired" is allocated 372 in the LSP Attributes Flags TLV. If the "Alarm indication desired" 373 bit is set it is indicating that the OAM entities of the signaled LSP 374 should be notified of lower layer failures. In the case of 375 hierarchical LSPs this will create an association between the 376 underlying (server) LSP's OAM entities and the currently signaled 377 (client) LSP's OAM entities. 379 3.3. OAM Configuration TLV 381 This TLV specifies which OAM technology/method should be used for the 382 LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES 383 object in Path messages. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type (2) (IANA) | Length | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | OAM Type | Reserved | OAM Function | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | | 393 ~ sub-TLVs ~ 394 | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Type: indicates a new type: the OAM Configuration TLV (2) (IANA to 398 assign). 400 OAM Type: specifies the technology specific OAM method. If the 401 requested OAM method is not supported an error must be generated: 402 "OAM Problem/Unsupported OAM Type". 404 This document defines no types. The receiving node based on the OAM 405 Type will check if a corresponding technology specific OAM 406 configuration sub-TLV is included. If different technology specific 407 OAM configuration sub-TLV is included than what was specified in the 408 OAM Type an error must be generated: "OAM Problem/OAM Type Mismatch". 410 OAM Type Description 411 ------------ -------------------- 412 0-255 Reserved 414 There is a hierarchy in between the OAM configuration elements. 415 First, the "OAM MEP (and MIP) entities desired" flag needs to be set, 416 if it is set an "OAM Configuration TLV" may be included in the 417 LSP_ATTRIBUTES object, if this TLV is present based on the OAM Type a 418 technology specific OAM configuration sub-TLV may be present. If 419 this hierarchy is broken (e.g., "OAM MEP entities desired" flag is 420 not set but an OAM Configuration TLV is present an error must be 421 generated: "OAM Problem/Configuration Error". 423 OAM Function Flags: specifies pro-active OAM functions (e.g., 424 connectivity monitoring, loss and delay measurement) that should be 425 established and configured. If the selected OAM Function(s) is(are) 426 not supported an error must be generated: "OAM Problem/Unsupported 427 OAM Function". 429 This document defines the following flags. 431 OAM Function Flag Description 432 --------------------- --------------------------- 433 0 Connectivity Monitoring 434 1 Performance Monitoring/Loss 435 2 Performance Monitoring/Delay 437 3.4. TCME Configuration TLV 439 Two TCME Configuration TLVs together specify a Tandem Connection 440 Monitoring entity: they designate the TCM ingress and TCM egress 441 MEPs, respectively. TCME Configuration TLVs are carried in 442 HOP_ATTRIBUTES subobjects [HOP_ATTR] in the ERO, the corresponding 443 node in the ERO identifies where TCME MEP is placed. Both TCME 444 Configuration TLVs of the same TCME must specify the same OAM 445 technology and method. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type (2) (IANA) | Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | OAM Type |H|M| Level | OAM Functions | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | SUB TLVs | 455 ~ ~ 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Type: indicates a new type: the TCME Configuration TLV (2) (IANA to 459 assign). 461 OAM Type: specifies the technology specific OAM method. The OAM Type 462 values defined for OAM Configuration TLV are applied here. If the 463 requested OAM method is not supported an error must be generated: 464 "OAM Problem/Unsupported OAM Type". 466 One bit (Flag H) is allocated to indicate which endpoint of a TCME is 467 encoded by the TCME Configuration TLV. Setting this flag indicates 468 the ingress endpoints while clearing it indicates the egress one. 470 One bit (Flag M) "TCME MIP entities desired" is allocated. This flag 471 indicates if OAM MIP entities monitoring the TCME are required. If 472 this function is not supported an error must be generated: "OAM 473 Problem/TCME MIP establishment not supported". 475 Level provides a key for the ingress node to determine the egress of 476 the same TCME. Therefore, the same Level values must be set to the 477 ingress and egress endpoints of the same TCME. Overlapping 478 (including nesting) TCM entities must use different Level values, but 479 two entries not having common segments may use the same Level value. 480 Value 0 is reserved and must not be used to identify a TCM entity. 481 Futher technology specific constraints of the Level value may be 482 defined by accompying documents. 484 OAM Function Flags: specifies pro-active OAM functions (e.g., 485 connectivity monitoring, loss and delay measurement) that should be 486 established and configured. Same flags are applied as for OAM 487 Configuration TLV. 489 Both TLVs may contain technology sub-TLVs and the encoded sub-TLVs 490 are relevant to the referred monitoring endpoint. The TCM ingress 491 may update the OAM configuration of the egress point by changing 492 already defined sub-TLVs or by adding new sub-TLVs. 494 If the node, where TCME endpoint is to be configured, does not 495 support that feature, must generate an error: "OAM Problem/TCM not 496 supported". 498 Since a TCME Configuration TLV pair encodes a TCME, the ingress node 499 must check if a proper TCME Configuration TLV encoding the egress MEP 500 is included in the ERO. If no such TLV (i.e., the same Level value 501 is set and flag H is cleared) is found an error must be generated: 502 "OAM Problem/TCM Egress is not properly configured". 504 The above check ensures that a TCM egress will not be configured 505 without peering TCM ingress. Therefore, there is no need TCME 506 ingress checking procedure at the TCME egress. 508 3.5. NIME Configuration TLV 510 Inserting a NIME Configuration TLV into a HOP_ATTRIBUTES object 511 [HOP_ATTR] indicates that a non-intrusive monitoring element is to be 512 configured. Futhermore, it encodes what OAM technology and method 513 should be used at that entity. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Type (3) (IANA) | Length | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | OAM Type |D|U| Level | OAM Functions | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | SUB TLVs | 523 ~ ~ 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Type: indicates a new type: the NIM OAM Configuration TLV (3) (IANA 526 to assign). 528 OAM Type: specifies the technology specify OAM method. If the 529 requested OAM method is not supported an error must be generated: 530 "OAM Problem/Unsupported OAM Type". The same OAM type values to be 531 used as for OAM Configuration TLV. 533 Level value indicates which OAM flow of the connection is monitored: 534 the end-to-end OAM flow (Level = 0) or TCM entity associated to the 535 connection (Level > 0). 537 Two bits (Flags D,U) indicates the direction of the monitored entity. 538 The downstream traffic is monitored if flag D is set, while setting 539 flag U means monitoring the upstream direction. Both directions are 540 monitored if both flags are set. When both flags are cleared or the 541 flag U is set but the LSP is not bidirectional an error must be 542 generated: "OAM Problem/Invalid NIM direction defined". 544 OAM Function Flags: specifies pro-active OAM functions (e.g., 545 connectivity monitoring, loss and delay measurement) that should be 546 established and configured. Same procedures and flags applied as for 547 OAM Configuration TLV. 549 3.6. Monitoring Disabled - Admin_Status bit 551 Administrative Status Information is carried in the ADMIN_STATUS 552 Object. The Administrative Status Information is described in 553 [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in 554 [RFC3473]. 556 One bit is allocated for the administrative control of OAM 557 monitoring. In addition to the Reflect (R) bit, 7 bits are currently 558 occupied (assigned by IANA or temporarily blocked by work in progress 559 Internet drafts). As the 24th bit (IANA to assign) this draft 560 introduces the Monitoring Disabled (M) bit. When this bit is set the 561 monitoring and OAM triggered alarms of the LSP are disabled (e.g., no 562 continuity check messages are sent, no AIS is generated). 564 3.7. OAM configuration errors 566 To handle OAM configuration errors a new Error Code (IANA to assign) 567 "OAM Problem" is introduced. To refer to specific problems a set of 568 Error Values is defined. 570 If a node does not support the establishment of OAM MEP or MIP 571 entities it must use the error value (IANA to assign): "MEP 572 establishment not supported" or "MIP establishment not supported" 573 respectively in the PathErr message. 575 If a node does not support a specific OAM technology/solution it must 576 use the error value (IANA to assign): "Unsupported OAM Type" in the 577 PathErr message. 579 If a different technology specific OAM configuration TLV is included 580 than what was specified in the OAM Type an error must be generated 581 with error value:"OAM Type Mismatch" in the PathErr message. 583 There is a hierarchy in between the OAM configuration elements. If 584 this hierarchy is broken an the error value: "OAM Problem/ 585 Configuration Error" must be used in the PathErr message. 587 If a node does not support a specific OAM Function it must use the 588 error value (IANA to assign): "Unsupported OAM Function" in the 589 PathErr message. 591 If an intermediate node is configured as a TCM ingress node, but no 592 egress node for the same TCM entity is encoded in the ERO it must use 593 "OAM Problem/TCM Egress is not properly configured" error value in 594 the PathErr message 596 If the node, where TCME endpoint is to be configured, does not 597 support that feature, must generate an error: "OAM Problem/TCM not 598 supported". 600 If the technology does not support deploying MIPs monitoring a TCME 601 an error must be generated by the TCME ingress: "OAM Problem/TCME MIP 602 establishment not supported". 604 If an intermediate node is configured as a non-intrusive monitoring 605 node, but direction flags encode an invalid direction (both flags are 606 set to 0 or flag "U" is set in the case of an unidirectional LSP) the 607 node must issue a PathErr message with "OAM Problem/invalid NIM 608 direction defined". 610 4. IANA Considerations 612 One bit (Monitoring Disabled (M)) needs to be allocated in the 613 ADMIN_STATUS Object. 615 One bit ("OAM entities desired") needs to be allocated in the LSP 616 Attributes Flag Registry. 618 This document specifies one new TLVs to be carried in the 619 LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages: 620 OAM Configuration TLV. 622 One new Error Code: "OAM Problem" and three new values: "MEP 623 establishment not supported", "MIP establishment not supported", 624 "Unsupported OAM Type" and "Unsupported OAM Function" needs to be 625 assigned. 627 5. Security Considerations 629 The signaling of OAM related parameters and the automatic 630 establishment of OAM entities introduces additional security 631 considerations to those discussed in [RFC3473]. In particular, a 632 network element could be overloaded, if an attacker would request 633 liveliness monitoring, with frequent periodic messages, for a high 634 number of LSPs, targeting a single network element. 636 Security aspects will be covered in more detailed in subsequent 637 versions of this document. 639 6. Acknowledgements 641 The authors would like to thank Francesco Fondelli, Adrian Farrel, 642 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 643 comments. 645 Appendix A. Discussion on alternatives 647 This appendix summarizes the discussions after IETF-71 about the way 648 OAM configuration information should be carried in RSVP-TE. 650 The first question is how the requirement for OAM establishment is 651 signaled and how the operation of OAM is controlled. There is a 652 straightforward way to achieve these using existing objects and 653 fields: 655 o Use one or more OAM flags in the LSP Attributes Flag TLV within 656 the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that 657 OAM entities for the LSP need to be established. If for any 658 reason this cannot be done a notification is sent or an error is 659 raised. 661 o Once the LSP with the desired OAM entities is established OAM 662 operation may be controlled using one or more flags in the 663 ADMIN_STATUS object. For instance, the generation of connectivity 664 monitoring messages can be disabled/enabled by setting/clearing a 665 flag in the ADMIN_STATUS object. 667 However, there are two alternatives when it comes to signaling the 668 actual configuration parameters of OAM entities. 670 o Extension of the LSP_ATTRIBUTES object with new TLVs. 672 o Definition of a new RSVP-TE object to carry OAM information. 674 In the first case, a new OAM configuration TLV is defined in the 675 LSP_ATTRIBUTES object. This TLV would provide the detailed 676 information needed for LSPs with a set OAM flag in the LSP Attributes 677 Flag TLV. The rationale for this approach is that in addition to 678 setting flags the LSP_ATTRIBUTES object may carry complementary 679 information for all or some of the flags set. Furthermore, as top 680 level RSVP-TE objects may become scarce resources, it seems to be 681 beneficial not to allocate new RSVP-TE objects for the purpose of 682 providing detailed information for new LSP Attribute Flags. 683 Currently there is only one TLV, the Attributes Flag TLV, defined in 684 the LSP_ATTRIBUTES object. Defining a new TLV associated with one of 685 the flags would make a precedence and possibly be a guideline for 686 similar future extensions. 688 The other alternative would be to allocate a dedicated object for OAM 689 configuration information. The rationale for this is that the 690 complex information that may be required for OAM configuration would 691 unnecessarily add complexity to LSP_ATTRIBUTES/ 692 LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms. 694 Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to 695 carry configuration information of data plane entities, thus a new 696 object like an "OAM_SPEC" may be a better fit to existing protocol 697 elements. 699 The authors of this document favor the first alternative (adding new 700 TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which 701 alternative to select for standardization is up for the working group 702 to decide. In any case, the information to be carried would be the 703 same or very similar for both alternatives. 705 7. References 707 [GELS-Framework] 708 "GMPLS Ethernet Label Switching Architecture and 709 Framework", Internet Draft, work in progress. 711 [GMPLS-OAM] 712 "OAM Requirements for Generalized Multi-Protocol Label 713 Switching (GMPLS) Networks", Internet Draft, work in 714 progress. 716 [HOP_ATTR] 717 Kern, A. and A. Takacs, "Encoding of Attributes of LSP 718 hops using RSVP-TE", Internet-draft Work in progress, 719 October 2009. 721 [IEEE-CFM] 722 "IEEE 802.1ag, Draft Standard for Connectivity Fault 723 Management", work in progress. 725 [IEEE-PBBTE] 726 "IEEE 802.1Qay Draft Standard for Provider Backbone 727 Bridging Traffic Engineering", work in progress. 729 [MPLS-TP-FWK] 730 "A Framework for MPLS in Transport Networks", Internet 731 Draft, work in progress. 733 [MPLS-TP-OAM-REQ] 734 "Requirements for OAM in MPLS Transport Networks", 735 Internet Draft, work in progress. 737 [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based 738 Recovery", RFC 3469, February 2003. 740 [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) 741 Signaling Functional Description", RFC 3471, January 2003. 743 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 744 Signaling Resource ReserVation Protocol-Traffic 745 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 747 [RFC4377] "Operations and Management (OAM) Requirements for Multi- 748 Protocol Label Switched (MPLS) Networks", RFC 4377, 749 February 2006. 751 [RFC4420] "Encoding of Attributes for Multiprotocol Label Switching 752 (MPLS) Label Switched Path (LSP) Establishment Using 753 Resource ReserVation Protocol-Traffic Engineering 754 (RSVP-TE)", RFC 4420, February 2006. 756 Authors' Addresses 758 Attila Takacs 759 Ericsson 760 Laborc u. 1. 761 Budapest, 1037 762 Hungary 764 Email: attila.takacs@ericsson.com 766 Don Fedyk 767 Alcatel-Lucent 768 Groton, MA 01450 769 USA 771 Email: donald.fedyk@alcatel-lucent.com 773 Jia He 774 Huawei 776 Email: hejia@huawei.com