idnits 2.17.1 draft-ietf-ccamp-rsvp-te-eth-oam-ext-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2014) is 3694 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: 'ESP-MAC DA' is mentioned on line 147, but not defined == Missing Reference: 'ESP-MAC SA' is mentioned on line 147, but not defined == Missing Reference: 'ESP-VID' is mentioned on line 147, but not defined == Missing Reference: 'ESP-MAC B' is mentioned on line 300, but not defined == Missing Reference: 'ESP-MAC A' is mentioned on line 300, but not defined == Missing Reference: 'ESP-VID2' is mentioned on line 300, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802.1Q-2011' -- Possible downref: Non-RFC (?) normative reference: ref. 'OAM-CONF-FWK' Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Takacs 3 Internet-Draft B. Gero 4 Intended status: Standards Track Ericsson 5 Expires: September 2, 2014 H. Long 6 Huawei 7 March 2014 9 GMPLS RSVP-TE Extensions for Ethernet OAM Configuration 10 draft-ietf-ccamp-rsvp-te-eth-oam-ext-11 12 Abstract 14 The GMPLS controlled Ethernet Label Switching (GELS) work extended 15 GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE 16 Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM 17 flow to check connectivity in Ethernet networks. CFM can be also 18 used with Ethernet LSPs for fault detection and triggering recovery 19 mechanisms. The ITU-T Y.1731 specification builds on CFM and 20 specifies additional OAM mechanisms, including Performance 21 Monitoring, for Ethernet networks. This document specifies 22 extensions of GMPLS RSVP-TE protocol to support the setup of the 23 associated Ethernet OAM entities of Ethernet LSPs, and defines the 24 Ethernet technology specific TLVs based on the GMPLS OAM 25 Configuration Framework. This document supports, but does not 26 modify, the IEEE and ITU-T OAM mechanisms. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 2, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Overview of Ethernet OAM operation . . . . . . . . . . . . . 3 69 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . 5 70 3.1. Operation overview . . . . . . . . . . . . . . . . . . . 5 71 3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7 72 3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . 7 73 3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 8 74 3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 9 75 3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . 10 76 3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 11 77 3.4. Pro-active Performance Monitoring . . . . . . . . . . . . 11 78 3.5. Summary of Ethernet OAM configuration errors . . . . . . 12 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 4.1. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 13 81 4.2. Ethernet Sub-TLVs Sub-Registry . . . . . . . . . . . . . 13 82 4.3. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 14 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 8.2. Informative References . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Background 93 Provider Backbone Bridging - Traffic Engineering (PBB-TE) 94 [IEEE.802.1Q-2011] decouples the Ethernet data and control planes, 95 and allows external control and management mechanisms to create 96 explicitly routed Ethernet connections. In addition, PBB-TE defines 97 mechanisms for protection switching of bidirectional Ethernet 98 connections. Ethernet Connectivity Fault Management (CFM) defines an 99 adjunct connectivity monitoring OAM flow to check the liveliness of 100 Ethernet networks [IEEE.802.1Q-2011], including the monitoring of 101 specific explicitly routed Ethernet connections. The ITU-T 102 Recommendation Y.1731 [ITU-T.Y.1731-2011] extended CFM and specified 103 additional OAM functionality. 105 In IETF, the GMPLS controlled Ethernet Label Switching (GELS) work 106 extended the GMPLS control plane to support the establishment of 107 explicitly routed Ethernet connections [RFC5828][RFC6060]. We refer 108 to GMPLS established Ethernet connections as Ethernet LSPs. GELS 109 enables the application of MPLS-TE and GMPLS provisioning and 110 recovery features in Ethernet networks. 112 The use of GMPLS RSVP-TE to support the establishment and 113 configuration of OAM entities with LSP signaling is defined in a 114 technology agnostic way in [OAM-CONF-FWK]. The purpose of this 115 document is to specify the additional technology specific OAM 116 entities to support Ethernet connections. 118 2. Overview of Ethernet OAM operation 120 For the purposes of this document, we only discuss Ethernet OAM 121 aspects that are relevant for proactive connectivity monitoring of 122 Ethernet LSPs. On-demand OAM functions for the purposes of this 123 document will be supported by Management Plane operations. 125 PBB-TE defines point-to-point Ethernet Switched Paths (ESPs) as a 126 provisioned traffic engineered unidirectional connectivity, 127 identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-VID], where 128 the ESP-MAC DA is the destination address of the ESP, the ESP-MAC SA 129 is the source address of the ESP, and the ESP-VID is a VLAN 130 identifier allocated for explicitly routed connections. To form a 131 bidirectional PBB-TE connection, two co-routed point-to-point ESPs 132 are combined. The combined ESPs must have the same ESP-MAC addresses 133 but may have different ESP-VIDs. 135 Note that although it would be possible to use GMPLS to setup a 136 single unidirectional ESP, the Ethernet OAM mechanisms are only fully 137 functional when bidirectional connections are established with co- 138 routed ESPs. Therefore, the scope of this document only covers 139 bidirectional point-to-point PBB-TE connections. 141 At both ends of the bidirectional point-to-point PBB-TE connection, 142 one Maintenance Endpoint (MEP) is configured. The MEPs monitoring a 143 PBB-TE connection must be configured with the same Maintenance Domain 144 Level (MD Level) and Maintenance Association Identifier (MAID). Each 145 MEP has a unique identifier, the MEP ID. Besides these identifiers, 146 a MEP monitoring a PBB-TE connection must be provisioned with the 147 3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs. 149 In the case of point-to-point VLAN connections, the connection may be 150 identified with a single VLAN, or with two VLANs, one for each 151 direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs, 152 MEPs must be provisioned with the proper VLAN identifiers. 154 MEPs exchange Connectivity Check Messages (CCMs) periodically with 155 fixed intervals. Eight distinct intervals are defined in 156 [IEEE.802.1Q-2011]: 158 +---+--------------------+----------------+ 159 | # | CCM Interval (CCI) | 3 bit encoding | 160 +---+--------------------+----------------+ 161 | 0 | Reserved | 000 | 162 | | | | 163 | 1 | 3 1/3 ms | 001 | 164 | | | | 165 | 2 | 10 ms | 010 | 166 | | | | 167 | 3 | 100 ms | 011 | 168 | | | | 169 | 4 | 1 s | 100 | 170 | | | | 171 | 5 | 10 s | 101 | 172 | | | | 173 | 6 | 1 min | 110 | 174 | | | | 175 | 7 | 10 min | 111 | 176 +---+--------------------+----------------+ 178 Table 1: CCM Interval encoding 180 If 3 consecutive CCM messages are lost; connectivity failure is 181 declared. The MEP detecting the failure will signal the defect to 182 the remote MEP in the subsequent CCM messages it emits, by setting 183 the Remote Defect Indicator (RDI) bit in the CCM message. If a MEP 184 receives a CCM message with RDI bit set it immediately declares 185 failure. The detection of a failure may trigger protection switching 186 mechanisms or may be signaled to a management system. 188 At each transit node, Maintenance Intermediate Points (MIPs) may be 189 established to help failure localization, e.g., using link trace and 190 loop back functions. MIPs need to be provisioned with a subset of 191 the MEP identification parameters described above. 193 3. GMPLS RSVP-TE Extensions 195 3.1. Operation overview 197 To simplify the configuration of connectivity monitoring, when an 198 Ethernet LSP is signaled, the associated MEPs should be automatically 199 established. To monitor an Ethernet LSP, a set of parameters must be 200 provided to setup a Maintenance Association and related MEPs. 201 Optionally, MIPs may be created at the transit nodes of the Ethernet 202 LSP. The LSP Attributes Flags: "OAM MEP entities desired" and "OAM 203 MIP entities desired", as described in [OAM-CONF-FWK], are used to 204 signal that the respective OAM entities must be established. An OAM 205 Configuration TLV, as described in [OAM-CONF-FWK], is added to the 206 LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Objects specifying that 207 Ethernet OAM is to be setup for the LSP. Ethernet OAM specific 208 information, as described below, is carried in the new Ethernet OAM 209 Configuration Sub-TLV (see Section 3.3) within the OAM Configuration 210 TLV. 212 o A unique MAID must be allocated for the PBB-TE connection and both 213 MEPs must be configured with the same information. The MAID 214 consists of an optional Maintenance Domain Name (MD Name) and a 215 mandatory Short Maintenance Association Name (Short MA Name). 216 Various formatting rules for these names have been defined in 217 [IEEE.802.1Q-2011]. Since this information is also carried in all 218 CCM messages, the combined length of the Names is limited to 44 219 bytes. How these parameters are determined is out of scope of 220 this document. 222 o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely 223 identifies a given MEP within a Maintenance Association. That is, 224 the combination of MAID and MEP ID must uniquely identify a MEP. 225 How the value of the MEP ID is determined is out of scope of this 226 document. 228 o The Maintenance Domain Level (MD Level) allows hierarchical 229 separation of monitoring entities. [IEEE.802.1Q-2011] allows 230 differentiation of 8 levels. How the value of the MD Level is 231 determined is out of scope of this document. Note that probably 232 for all Ethernet LSPs a single (default) MD Level will be used 233 within a network domain. 235 o The desired CCM Interval must be specified by the management 236 system based on service requirements or operator policy. The same 237 CCM Interval must be set in each of the MEPs monitoring a given 238 Ethernet LSP. How the value of the CCM Interval is determined is 239 out of scope of this document. 241 o The desired forwarding priority to be set by MEPs for the CCM 242 frames can be specified. The same CCM priority must be set in 243 each of the MEPs monitoring a given Ethernet LSP. How CCM 244 priority is determined is out of scope of this document. Note 245 that the highest priority should be used as the default CCM 246 priority. 248 o MEPs must be aware of their own and the reachability parameters of 249 the remote MEP. In the case of bidirectional point-to-point PBB- 250 TE connections, this requires that the 3-tuples [ESP-MAC A, ESP- 251 MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are 252 configured in each MEP, where the ESP-MAC A is the same as the 253 local MEP's MAC address and ESP-MAC B is the same as remote MEP's 254 MAC address. The GMPLS Ethernet Label format, as defined in 255 [RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence the 256 necessary reachability parameters for the MEPs can be obtained 257 from the Ethernet Labels (i.e., carried in the downstream and 258 upstream labels). In the case of point-to-point VLAN connections, 259 MEPs need to be provisioned with the VLAN identifiers only, which 260 can be derived similarly from the Ethernet Labels. 262 Based on the procedures described in [RFC6060] for bidirectional PBB- 263 TE Ethernet LSP establishment, the Ethernet OAM configuration 264 procedures are as follows: 266 When the RSVP-TE signaling is initiated for the bidirectional 267 Ethernet LSP the local node generates a Path message and: 269 o Allocates an Upstream Label formed by combining its MAC address 270 (ESP-MAC A) and locally selected VID (ESP-VID1), which will be 271 used to receive traffic; 273 o MUST include the OAM Configuration TLV with OAM Type set to 274 Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 275 Object; 277 o MUST include the OAM Function Flags Sub-TLV in the OAM 278 Configuration TLV and set the OAM function flags as needed; 280 o MUST include an Ethernet OAM Configuration Sub-TLV in the OAM 281 Configuration TLV that specifies the CCM Interval and MD Level; 283 o MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name 284 Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV, that 285 will unambiguously identify a Maintenance Association for this 286 specific PBB-TE connection. Note that values for these parameters 287 may be derived from the GMPLS LSP identification parameters; 289 o MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration 290 Sub-TLV and select two distinct integer values to identify the 291 local and remote MEPs within the Maintenance Association created 292 for monitoring of the point-to-point PBB-TE connection. 294 Once the remote node receives the Path message, it can use the 295 UPSTREAM_LABEL to extract the reachability information of the 296 initiator. Then it allocates a Label by selecting a local MAC 297 address (ESP-MAC B) and VID (ESP-VID2) that will be used to receive 298 traffic. These parameters determine the reachability information of 299 the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP- 300 VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the 301 Ethernet Labels. In addition, the information received in the 302 Ethernet OAM Configuration TLV is used to configure the local MEP. 304 Once the Resv message successfully arrives to the initiator, this end 305 can extract the remote side's reachability information from the Label 306 Object and therefore it has all the information needed to properly 307 configure its local MEP. 309 3.2. OAM Configuration TLV 311 This TLV is specified in [OAM-CONF-FWK] and is used to select which 312 OAM technology/method should be used for the LSP. In this document, 313 a new OAM Type: Ethernet OAM is defined. IANA is requested to 314 allocate OAM Type 1 for Ethernet OAM in the RSVP-TE OAM Configuration 315 Registry. 317 RSVP-TE OAM Configuration Registry 319 OAM Type Description 320 ------------ ------------------ 321 TBA1 Ethernet OAM 323 The receiving node, when the Ethernet OAM Type is requested, should 324 look for the corresponding technology specific Ethernet OAM 325 Configuration Sub-TLV. 327 3.3. Ethernet OAM Configuration Sub-TLV 329 The Ethernet OAM Configuration Sub-TLV (depicted below) is defined 330 for Ethernet OAM specific configuration parameters. The Ethernet OAM 331 Configuration Sub-TLV, when used, MUST be carried in the OAM 332 Configuration TLV. This new sub-TLV accommodates Ethernet OAM 333 information and carries sub-TLVs. 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type (TBA2) (IANA) | Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Version |MD L.| Reserved (set to all 0s) | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 ~ sub TLVs ~ 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Type: indicates a new type: the Ethernet OAM Configuration Sub-TLV. 348 IANA is requested to assign a value from the "Sub-TLV" space in the 349 "RSVP-TE OAM Configuration Registry". 351 Length: indicates the total length of the TLV including padding and 352 including the Type and Length fields. 354 Version: identifies the CFM protocol version according to 355 [IEEE.802.1Q-2011]. If a node does not support a specific CFM 356 version an error MUST be generated: "OAM Problem/Unsupported OAM 357 Version" 359 MD L. (MD Level): indicates the desired MD Level. Possible values 360 are defined according to [IEEE.802.1Q-2011]. If a node does not 361 support a specific MD Level an error MUST be generated: "OAM Problem/ 362 Unsupported MD Level". 364 3.3.1. MD Name Sub-TLV 366 The optional MD Name Sub-TLV is depicted below, it MAY be used for MD 367 naming. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type (1) (IANA) | Length | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Format | Name Length | Reserved (set to all 0s) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 ~ MD Name ~ 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Type: 1, MD Name Sub-TLV. IANA is requested to maintain an Ethernet 381 TLV Type space in the "RSVP-TE OAM Configuration Registry" for the 382 sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. 384 Length: indicates the total length of the TLV including padding and 385 including the Type and Length fields. 387 Format: according to [IEEE.802.1Q-2011]. 389 Name Length: the length of the MD Name field in bytes. This is 390 necessary to allow non 4 byte padded MD Name lengths. 392 MD Name: variable length field, formatted according to the format 393 specified in the Format field. 395 If an undefined Format is specified an error MUST be generated: "OAM 396 Problem/Unknown MD Name Format". Also the combined length of MD Name 397 and Short MA Name MUST be less or equal to 44bytes, if this is 398 violated an error MUST be generated: "OAM Problem/Name Length 399 Problem". Note it is allowed to have no MD Name, therefore the MD 400 Name Sub-TLV is optional. In this case the MA Name must uniquely 401 identify a Maintenance Association. 403 3.3.2. Short MA Name Sub-TLV 405 The Short MA Name Sub-TLV is depicted below, this sub-TLV MUST be 406 present in the Ethernet OAM Configuration Sub-TLV. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type (2) (IANA) | Length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Format | Name Length | Reserved (set to all 0s) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 ~ Short MA Name ~ 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Type: 2, Short MA Name Sub-TLV. IANA is requested to maintain an 421 Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" 422 for the sub-TLV types carried in the Ethernet OAM Configuration Sub- 423 TLV. 425 Length: indicates the total length of the TLV including padding and 426 including the Type and Length fields. 428 Format: according to [IEEE.802.1Q-2011]. 430 Name Length: the length of the MA Name field in bytes. This is 431 necessary to allow non 4 byte padded MA Name lengths. 433 Short MA Name: variable length field formatted according to the 434 format specified in the Format field. 436 If an undefined Format is specified an error MUST be generated: "OAM 437 Problem/Unknown MA Name Format". Also the combined length of MD Name 438 and Short MA Name MUST be less or equal to 44bytes, if this is 439 violated an error MUST be generated: "OAM Problem/Name Length 440 Problem". Note it is allowed to have no MD Name, in this case the MA 441 Name MUST uniquely identify a Maintenance Association. 443 3.3.3. MEP ID Sub-TLV 445 The MEP ID Sub-TLV is depicted below, this sub-TLV MUST be present in 446 the Ethernet OAM Configuration Sub-TLV. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type (3) (IANA) | Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Local MEP ID |T|R| Reserved | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Remote MEP ID |T|R| Reserved | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Type: 3, MEP ID Sub-TLV. IANA is requested to maintain an Ethernet 459 TLV Type space in the "RSVP-TE OAM Configuration Registry" for the 460 sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. 462 Length: indicates the total length of the TLV including padding and 463 including the Type and Length fields. 465 Local MEP ID: a 16 bit integer value in the range 1-8191 of the MEP 466 ID on the initiator side. 468 Remote MEP ID: a 16 bit integer value in the range 1-8191 of the MEP 469 ID to be set for the MEP established at the receiving side. This 470 value is determined by the initiator node. This is possible, since a 471 new MAID is assigned to each PBB-TE connection, and MEP IDs must be 472 only unique within the scope of the MAID. 474 Two flags are defined Transmit (T) and Receive (R). When T is set 475 the corresponding MEP MUST send OAM packets. When R is set the 476 corresponding MEP MUST expect to receive OAM packets. These flags 477 are used to configure the role of MEPs. 479 3.3.4. Continuity Check (CC) Sub-TLV 481 The Continuity Check (CC) Sub-TLV is depicted below, this sub-TLV 482 MUST be present in the Ethernet OAM Configuration Sub-TLV. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type (4) (IANA) | Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Prio | CCM I | Reserved (set to all 0s) | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Type: 4, Continuity Check (CC) Sub-TLV. IANA is requested to 493 maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration 494 Registry" for the sub-TLV types carried in the Ethernet OAM 495 Configuration Sub-TLV. 497 Length: indicates the total length of the TLV including padding and 498 including the Type and Length fields. 500 Prio: Indicates the priority to be set for CCM frames. In Ethernet, 501 3 bits carried in VLAN TAGs identify priority information. Setting 502 the priority is optional. If the most significant bit is set to 503 zero, the subsequent 3 priority bits will be ignored, and priority 504 bits of the Ethernet CCM frame will be set based on default values 505 specified in the Ethernet nodes. If the most significant bit is set 506 to 1, the subsequent 3 bits will be used to set the priority bits of 507 the Ethernet CCM frame. 509 CCM I (CCM Interval): CCM Interval, it MUST be set according to the 3 510 bit encoding [IEEE.802.1Q-2011] shown in Table 1. As a consequence 511 the most significant bit will be set to 0. Four bits are allocated 512 to support the configuration of CCM intervals that may be specified 513 in the future. If a node does not support the requested CCM Interval 514 an error MUST be generated: "OAM Problem/Unsupported CC Interval". 516 3.4. Pro-active Performance Monitoring 518 Ethernet OAM functions for Performance Monitoring (PM) allow 519 measurements of different performance parameters including Frame Loss 520 Ratio, Frame Delay and Frame Delay variation as defined in 521 [ITU-T.Y.1731-2011]. Only a subset of PM functions are operated in a 522 pro-active fashion to monitor the performance of the connection 523 continuously. Pro-active PM supports Fault Management functions, by 524 providing an indication of decreased service performance and as such 525 may provide triggers to initiate recovery procedures. 527 While on demand PM functions are, for the purposes of this document, 528 always initiated by management commands, for pro-active PM, it may be 529 desirable to utilize the control plane for configuration and 530 activation together with Fault Management functions such as the 531 Continuity Check. 533 [ITU-T.Y.1731-2011] defines dual-ended Loss Measurement as pro-active 534 OAM for performance monitoring and as a PM function applicable to 535 fault management. For dual-ended Loss Measurement each MEP piggy- 536 backs transmitted and received frame counters on CC messages; to 537 support and synchronize bidirectional Loss Measurements at the MEPs. 538 Dual-ended Loss Measurement is supported by setting the Performance 539 Monitoring/Loss OAM Function Flag and the Continuity Check Flag in 540 the OAM Function Flags Sub-TLV [OAM-CONF-FWK], and configuring the 541 Continuity Check functionality by including the Ethernet OAM 542 Configuration Sub-TLV. No additional configuration is required for 543 this type of Loss Measurement. 545 3.5. Summary of Ethernet OAM configuration errors 547 In addition to error values specified in [OAM-CONF-FWK] this document 548 defines the following values for the "OAM Problem" Error Code. 550 o If a node does not support a specific CFM version, an error MUST 551 be generated: "OAM Problem/Unsupported OAM Version". 553 o If a node does not support a specific MD Level, an error MUST be 554 generated: "OAM Problem/Unsupported MD Level". 556 o If an undefined MD name format is specified, an error MUST be 557 generated: "OAM Problem/Unknown MD Name Format". 559 o If an undefined MA name format is specified, an error MUST be 560 generated: "OAM Problem/Unknown MA Name Format". 562 o The combined length of MD Name and Short MA Name must be less or 563 equal to 44bytes, if this is violated an error MUST be generated: 564 "OAM Problem/Name Length Problem". 566 o If a node does not support the requested CCM Interval, an error 567 MUST be generated: "OAM Problem/Unsupported CC Interval". 569 4. IANA Considerations 571 4.1. RSVP-TE OAM Configuration Registry 573 [OAM-CONF-FWK] includes a request for IANA to create the "RSVP-TE OAM 574 Configuration Registry". IANA is requested to assign an "OAM Type" 575 from this registry as follows. Allocate the value TBA1 for "Ethernet 576 OAM" from the "OAM Type Sub-Registry" of the "RSVP-TE OAM 577 Configuration Registry". Allocate type TBA2 for the "Ethernet OAM 578 Configuration Sub-TLV" from the technology-specific range of the "OAM 579 Sub-TLVs Sub-Registry" of the "RSVP-TE OAM Configuration Registry". 581 RSVP-TE OAM Configuration Registry 583 OAM Types Sub-Registry 585 OAM Type Number | Description | Reference 586 ------------------------------------------------- 587 TBA1 | Ethernet OAM | [This.ID] 589 OAM Sub-TLVs Sub-Registry 591 Sub-TLV Type | Description | Ref. 592 ---------------------------------------------------------- 593 TBA2 |Ethernet OAM Configuration Sub-TLV|[This.ID] 595 The value of 1 is suggested for TBA1. The value of 32 is suggested 596 for TBA2. 598 4.2. Ethernet Sub-TLVs Sub-Registry 600 IANA is requested to maintain an Ethernet Sub-TLVs Sub-Registry in 601 the "RSVP-TE OAM Configuration Registry" for the sub-TLV types 602 carried in the Ethernet OAM Configuration Sub-TLV. This document 603 defines the following types. 605 Ethernet Sub-TLVs Sub-Registry 607 Range | Registration Procedures 608 ------------+---------------------------- 609 0-65534 | IETF Review 610 65535-65536 | Experimental 612 Sub-TLV Type | Description | Ref. 613 --------------------------------------------------- 614 0 | Reserved | [This.ID] 615 1 | MD Name Sub-TLV | [This.ID] 616 2 | Short MA Name Sub-TLV | [This.ID] 617 3 | MEP ID Sub-TLV | [This.ID] 618 4 | Continuity Check Sub-TLV | [This.ID] 619 5-65536 | Unassigned | [This.ID] 621 4.3. RSVP Error Code 623 [OAM-CONF-FWK] includes a request for IANA to allocate a new Error 624 Code, "OAM Problem" in the "Error Codes and Globally-Defined Error 625 Value Sub-Codes" sub-registry of the "Resource Reservation Protocol 626 (RSVP) Parameters" registry. [OAM-CONF-FWK] defines a set of Error 627 Value sub-codes for the "OAM Problem" Error Code. This document 628 defines additional Error Values sub-codes for the "OAM Problem" Error 629 Code as defined below. 631 Value | Description | Reference 632 -------+---------------------------+-------------- 633 TBA | Unsupported OAM Version | [This.ID] 634 TBA | Unsupported MD Level | [This.ID] 635 TBA | Unknown MD Name Format | [This.ID] 636 TBA | Unknown MA Name Format | [This.ID] 637 TBA | Name Length Problem | [This.ID] 638 TBA | Unsupported CC Interval | [This.ID] 640 5. Security Considerations 642 This document does not introduce any additional security issue to 643 those discussed in [OAM-CONF-FWK] and [RFC6060]. 645 6. Acknowledgements 647 The authors would like to thank Francesco Fondelli, Adrian Farrel, 648 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 649 comments. 651 7. Contributors 653 - Don Fedyk 654 - Dinesh Mohan 656 8. References 658 8.1. Normative References 660 [IEEE.802.1Q-2011] 661 IEEE, "IEEE Standard for Local and metropolitan area 662 networks -- Media Access Control (MAC) Bridges and Virtual 663 Bridged Local Area Networks", IEEE Std 802.1Q, 2011. 665 [OAM-CONF-FWK] 666 Attila Takacs, Don Fedyk, and Jia He, "OAM Configuration 667 Framework for GMPLS RSVP-TE", Internet Draft, work in 668 progress, 2014. 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 674 "Generalized Multiprotocol Label Switching (GMPLS) Control 675 of Ethernet Provider Backbone Traffic Engineering (PBB- 676 TE)", RFC 6060, March 2011. 678 8.2. Informative References 680 [ITU-T.Y.1731-2011] 681 ITU, "ITU-T Recommendation Y.1731: OAM functions and 682 mechanisms for Ethernet based networks", ITU-T 683 Recommendation Y.1731, 2011. 685 [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized 686 Multiprotocol Label Switching (GMPLS) Ethernet Label 687 Switching Architecture and Framework", RFC 5828, March 688 2010. 690 Authors' Addresses 692 Attila Takacs 693 Ericsson 694 Konyves Kalman krt. 11. 695 Budapest 1097 696 Hungary 698 Email: attila.takacs@ericsson.com 699 Balazs Peter Gero 700 Ericsson 701 Konyves Kalman krt. 11. 702 Budapest 1097 703 Hungary 705 Email: balazs.peter.gero@ericsson.com 707 Hao Long 708 Huawei 710 Email: lonho@huawei.com