idnits 2.17.1 draft-ietf-ccamp-rsvp-te-eth-oam-ext-13.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 (July 22, 2014) is 3538 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 149, but not defined == Missing Reference: 'ESP-MAC SA' is mentioned on line 149, but not defined == Missing Reference: 'ESP-VID' is mentioned on line 149, but not defined == Missing Reference: 'ESP-MAC B' is mentioned on line 303, but not defined == Missing Reference: 'ESP-MAC A' is mentioned on line 303, but not defined == Missing Reference: 'ESP-VID2' is mentioned on line 303, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.802.1Q-2011' Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Takacs 3 Internet-Draft B. Gero 4 Intended status: Standards Track Ericsson 5 Expires: January 23, 2015 H. Long 6 Huawei 7 July 22, 2014 9 GMPLS RSVP-TE Extensions for Ethernet OAM Configuration 10 draft-ietf-ccamp-rsvp-te-eth-oam-ext-13 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 January 23, 2015. 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 . . . . . . . . . . . 8 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 . . . . . . . . . . . . 12 78 3.5. Summary of Ethernet OAM configuration errors . . . . . . 13 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 4.1. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 13 81 4.2. Ethernet Sub-TLVs Sub-Registry . . . . . . . . . . . . . 14 82 4.3. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 14 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 8.2. Informative References . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 [RFC7260]. The purpose of this document 115 is to specify the additional technology specific OAM entities to 116 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. The formed co-routed bidirectional 134 path is a path where the forward and backward directions follow the 135 same route (links and nodes) across the network. 137 Note that although it would be possible to use GMPLS to setup a 138 single unidirectional ESP, the Ethernet OAM mechanisms are only fully 139 functional when bidirectional connections are established with co- 140 routed ESPs. Therefore, the scope of this document only covers 141 bidirectional point-to-point PBB-TE connections. 143 At both ends of the bidirectional point-to-point PBB-TE connection, 144 one Maintenance Endpoint (MEP) is configured. The MEPs monitoring a 145 PBB-TE connection must be configured with the same Maintenance Domain 146 Level (MD Level) and Maintenance Association Identifier (MAID). Each 147 MEP has a unique identifier, the MEP ID. Besides these identifiers, 148 a MEP monitoring a PBB-TE connection must be provisioned with the 149 3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs. 151 In the case of point-to-point VLAN connections, the connection may be 152 identified with a single VLAN, or with two VLANs, one for each 153 direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs, 154 MEPs must be provisioned with the proper VLAN identifiers. 156 MEPs exchange Connectivity Check Messages (CCMs) periodically with 157 fixed intervals. Eight distinct intervals are defined in 158 [IEEE.802.1Q-2011]: 160 +---+--------------------+----------------+ 161 | # | CCM Interval (CCI) | 3 bit encoding | 162 +---+--------------------+----------------+ 163 | 0 | Reserved | 000 | 164 | | | | 165 | 1 | 3 1/3 ms | 001 | 166 | | | | 167 | 2 | 10 ms | 010 | 168 | | | | 169 | 3 | 100 ms | 011 | 170 | | | | 171 | 4 | 1 s | 100 | 172 | | | | 173 | 5 | 10 s | 101 | 174 | | | | 175 | 6 | 1 min | 110 | 176 | | | | 177 | 7 | 10 min | 111 | 178 +---+--------------------+----------------+ 180 Table 1: CCM Interval encoding 182 If 3 consecutive CCM messages are lost; connectivity failure is 183 declared. The MEP detecting the failure will signal the defect to 184 the remote MEP in the subsequent CCM messages it emits, by setting 185 the Remote Defect Indicator (RDI) bit in the CCM message. If a MEP 186 receives a CCM message with RDI bit set it immediately declares 187 failure. The detection of a failure may trigger protection switching 188 mechanisms or may be signaled to a management system. 190 At each transit node, Maintenance Intermediate Points (MIPs) may be 191 established to help failure localization, e.g., using link trace and 192 loop back functions. MIPs need to be provisioned with a subset of 193 the MEP identification parameters described above. 195 3. GMPLS RSVP-TE Extensions 197 3.1. Operation overview 199 To simplify the configuration of connectivity monitoring, when an 200 Ethernet LSP is signaled, the associated MEPs should be automatically 201 established. To monitor an Ethernet LSP, a set of parameters must be 202 provided to setup a Maintenance Association and related MEPs. 203 Optionally, MIPs may be created at the transit nodes of the Ethernet 204 LSP. The LSP Attribute Flags: "OAM MEP entities desired" and "OAM 205 MIP entities desired", as described in [RFC7260], are used to signal 206 that the respective OAM entities must be established. An OAM 207 Configuration TLV, as described in [RFC7260], is added to the 208 LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES Objects specifying that 209 Ethernet OAM is to be setup for the LSP. Ethernet OAM specific 210 information, as described below, is carried in the new Ethernet OAM 211 Configuration Sub-TLV (see Section 3.3) within the OAM Configuration 212 TLV. 214 o A unique MAID must be allocated for the PBB-TE connection and both 215 MEPs must be configured with the same information. The MAID 216 consists of an optional Maintenance Domain Name (MD Name) and a 217 mandatory Short Maintenance Association Name (Short MA Name). 218 Various formatting rules for these names have been defined in 219 [IEEE.802.1Q-2011]. Since this information is also carried in all 220 CCM messages, the combined length of the Names is limited to 44 221 bytes, see [IEEE.802.1Q-2011] for the details of the message 222 format. How these parameters are determined is out of scope of 223 this document. 225 o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely 226 identifies a given MEP within a Maintenance Association. That is, 227 the combination of MAID and MEP ID must uniquely identify a MEP. 228 How the value of the MEP ID is determined is out of scope of this 229 document. 231 o The Maintenance Domain Level (MD Level) allows hierarchical 232 separation of monitoring entities. [IEEE.802.1Q-2011] allows 233 differentiation of 8 levels. How the value of the MD Level is 234 determined is out of scope of this document. Note that probably 235 for all Ethernet LSPs a single (default) MD Level will be used 236 within a network domain. 238 o The desired CCM Interval must be specified by the management 239 system based on service requirements or operator policy. The same 240 CCM Interval must be set in each of the MEPs monitoring a given 241 Ethernet LSP. How the value of the CCM Interval is determined is 242 out of scope of this document. 244 o The desired forwarding priority to be set by MEPs for the CCM 245 frames may be specified. The same CCM priority must be set in 246 each of the MEPs monitoring a given Ethernet LSP. How CCM 247 priority is determined is out of scope of this document. Note 248 that the highest priority should be used as the default CCM 249 priority. 251 o MEPs must be aware of the reachability parameters of their own and 252 that of the remote MEP. In the case of bidirectional point-to- 253 point PBB-TE connections, this requires that the 3-tuples [ESP-MAC 254 A, ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are 255 configured in each MEP, where the ESP-MAC A is the same as the 256 local MEP's MAC address and ESP-MAC B is the same as remote MEP's 257 MAC address. The GMPLS Ethernet Label format, as defined in 258 [RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence the 259 necessary reachability parameters for the MEPs can be obtained 260 from the Ethernet Labels (i.e., carried in the downstream and 261 upstream labels). In the case of point-to-point VLAN connections, 262 MEPs need to be provisioned with the VLAN identifiers only, which 263 can be derived similarly from the Ethernet Labels. 265 Based on the procedures described in [RFC6060] for bidirectional PBB- 266 TE Ethernet LSP establishment, the Ethernet OAM configuration 267 procedures are as follows: 269 When the RSVP-TE signaling is initiated for the bidirectional 270 Ethernet LSP the local node generates a Path message and: 272 o Allocates an Upstream Label formed by combining its MAC address 273 (ESP-MAC A) and locally selected VID (ESP-VID1), which will be 274 used to receive traffic; 276 o MUST include the OAM Configuration TLV with OAM Type set to 277 Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES 278 Object; 280 o MUST include the OAM Function Flags Sub-TLV in the OAM 281 Configuration TLV and set the OAM function flags as needed; 283 o MUST include an Ethernet OAM Configuration Sub-TLV in the OAM 284 Configuration TLV that specifies the CCM Interval and MD Level; 286 o MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name 287 Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV, that 288 will unambiguously identify a Maintenance Association for this 289 specific PBB-TE connection. Note that values for these parameters 290 may be derived from the GMPLS LSP identification parameters; 292 o MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration 293 Sub-TLV and select two distinct integer values to identify the 294 local and remote MEPs within the Maintenance Association created 295 for monitoring of the point-to-point PBB-TE connection. 297 Once the remote node receives the Path message, it can use the 298 UPSTREAM_LABEL to extract the reachability information of the 299 initiator. Then it allocates a Label by selecting a local MAC 300 address (ESP-MAC B) and VID (ESP-VID2) that will be used to receive 301 traffic. These parameters determine the reachability information of 302 the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP- 303 VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the 304 Ethernet Labels. In addition, the information received in the 305 Ethernet OAM Configuration TLV is used to configure the local MEP. 307 Once the Resv message successfully arrives to the initiator, this end 308 can extract the remote side's reachability information from the Label 309 Object and therefore it has all the information needed to properly 310 configure its local MEP. 312 3.2. OAM Configuration TLV 314 This TLV is specified in [RFC7260] and is used to select which OAM 315 technology/method should be used for the LSP. In this document, a 316 new OAM Type: Ethernet OAM is defined. IANA is requested to allocate 317 OAM Type 1 for Ethernet OAM in the RSVP-TE OAM Configuration 318 Registry. 320 RSVP-TE OAM Configuration Registry 322 OAM Type Description 323 ------------ ------------------ 324 TBA1 Ethernet OAM 326 The receiving node, when the Ethernet OAM Type is requested, should 327 look for the corresponding technology specific Ethernet OAM 328 Configuration Sub-TLV. 330 3.3. Ethernet OAM Configuration Sub-TLV 332 The Ethernet OAM Configuration Sub-TLV (depicted below) is defined 333 for Ethernet OAM specific configuration parameters. The Ethernet OAM 334 Configuration Sub-TLV, when used, MUST be carried in the OAM 335 Configuration TLV. This new sub-TLV accommodates Ethernet OAM 336 information and carries sub-TLVs. 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type (TBA2) (IANA) | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Version |MD L.| Reserved (set to all 0s) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 ~ sub TLVs ~ 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Type: indicates a new type: the Ethernet OAM Configuration Sub-TLV. 351 IANA is requested to assign a value from the "Sub-TLV" space in the 352 "RSVP-TE OAM Configuration Registry". 354 Length: indicates the total length of the TLV including padding and 355 including the Type and Length fields. 357 Version: identifies the CFM protocol version according to 358 [IEEE.802.1Q-2011]. If a node does not support a specific CFM 359 version an error MUST be generated: "OAM Problem/Unsupported OAM 360 Version" 362 MD L. (MD Level): indicates the desired MD Level. Possible values 363 are defined according to [IEEE.802.1Q-2011]. If a node does not 364 support a specific MD Level an error MUST be generated: "OAM Problem/ 365 Unsupported MD Level". 367 3.3.1. MD Name Sub-TLV 369 The optional MD Name Sub-TLV is depicted below, it MAY be used for MD 370 naming. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type (1) (IANA) | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Format | Name Length | Reserved (set to all 0s) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 ~ MD Name ~ 381 | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Type: 1, MD Name Sub-TLV. IANA is requested to maintain an Ethernet 385 TLV Type space in the "RSVP-TE OAM Configuration Registry" for the 386 sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. 388 Length: indicates the total length of the TLV including padding and 389 including the Type and Length fields. 391 Format: according to [IEEE.802.1Q-2011]. 393 Name Length: the length of the MD Name field in bytes. This is 394 necessary to allow non 4 byte padded MD Name lengths. 396 MD Name: variable length field, formatted according to the format 397 specified in the Format field. 399 If an undefined Format is specified an error MUST be generated: "OAM 400 Problem/Unknown MD Name Format". Also the combined length of MD Name 401 and Short MA Name MUST be less or equal to 44bytes, if this is 402 violated an error MUST be generated: "OAM Problem/Name Length 403 Problem". Note it is allowed to have no MD Name, therefore the MD 404 Name Sub-TLV is optional. In this case the MA Name must uniquely 405 identify a Maintenance Association. 407 3.3.2. Short MA Name Sub-TLV 409 The Short MA Name Sub-TLV is depicted below. This sub-TLV MUST be 410 present in the Ethernet OAM Configuration Sub-TLV. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type (2) (IANA) | Length | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Format | Name Length | Reserved (set to all 0s) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | | 420 ~ Short MA Name ~ 421 | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 Type: 2, Short MA Name Sub-TLV. IANA is requested to maintain an 425 Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" 426 for the sub-TLV types carried in the Ethernet OAM Configuration Sub- 427 TLV. 429 Length: indicates the total length of the TLV including padding and 430 including the Type and Length fields. 432 Format: according to [IEEE.802.1Q-2011]. 434 Name Length: the length of the MA Name field in bytes. This is 435 necessary to allow non 4 byte padded MA Name lengths. 437 Short MA Name: variable length field formatted according to the 438 format specified in the Format field. 440 If an undefined Format is specified an error MUST be generated: "OAM 441 Problem/Unknown MA Name Format". Also the combined length of MD Name 442 and Short MA Name MUST be less or equal to 44bytes, if this is 443 violated an error MUST be generated: "OAM Problem/Name Length 444 Problem". Note it is allowed to have no MD Name, in this case the MA 445 Name MUST uniquely identify a Maintenance Association. 447 3.3.3. MEP ID Sub-TLV 449 The MEP ID Sub-TLV is depicted below. This sub-TLV MUST be present 450 in the Ethernet OAM Configuration Sub-TLV. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type (3) (IANA) | Length | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Local MEP ID |T|R| Reserved | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Remote MEP ID |T|R| Reserved | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Type: 3, MEP ID Sub-TLV. IANA is requested to maintain an Ethernet 463 TLV Type space in the "RSVP-TE OAM Configuration Registry" for the 464 sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. 466 Length: indicates the total length of the TLV including padding and 467 including the Type and Length fields. 469 Local MEP ID: a 16 bit integer value in the range 1-8191 of the MEP 470 ID on the initiator side. 472 Remote MEP ID: a 16 bit integer value in the range 1-8191 of the MEP 473 ID to be set for the MEP established at the receiving side. This 474 value is determined by the initiator node. This is possible, since a 475 new MAID is assigned to each PBB-TE connection, and MEP IDs must be 476 only unique within the scope of the MAID. 478 Two flags are defined Transmit (T) and Receive (R). When T is set 479 the corresponding MEP MUST send OAM packets. When R is set the 480 corresponding MEP MUST expect to receive OAM packets. These flags 481 are used to configure the role of MEPs. 483 3.3.4. Continuity Check (CC) Sub-TLV 485 The Continuity Check (CC) Sub-TLV is depicted below. This sub-TLV 486 MUST be present in the Ethernet OAM Configuration Sub-TLV. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type (4) (IANA) | Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Prio | CCM I | Reserved (set to all 0s) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Type: 4, Continuity Check (CC) Sub-TLV. IANA is requested to 497 maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration 498 Registry" for the sub-TLV types carried in the Ethernet OAM 499 Configuration Sub-TLV. 501 Length: indicates the total length of the TLV including padding and 502 including the Type and Length fields. 504 Prio: Indicates the priority to be set for CCM frames. In Ethernet, 505 3 bits carried in VLAN TAGs identify priority information. Setting 506 the priority is optional. If the most significant bit is set to 507 zero, the subsequent 3 priority bits will be ignored, and priority 508 bits of the Ethernet CCM frame will be set based on default values 509 specified in the Ethernet nodes. If the most significant bit is set 510 to 1, the subsequent 3 bits will be used to set the priority bits of 511 the Ethernet CCM frame. 513 CCM I (CCM Interval): CCM Interval, it MUST be set according to the 3 514 bit encoding [IEEE.802.1Q-2011] shown in Table 1. As a consequence 515 the most significant bit will be set to 0. Four bits are allocated 516 to support the configuration of CCM intervals that may be specified 517 in the future. If a node does not support the requested CCM Interval 518 an error MUST be generated: "OAM Problem/Unsupported CC Interval". 520 3.4. Pro-active Performance Monitoring 522 Ethernet OAM functions for Performance Monitoring (PM) allow 523 measurements of different performance parameters including Frame Loss 524 Ratio, Frame Delay and Frame Delay variation as defined in 525 [ITU-T.Y.1731-2011]. Only a subset of PM functions are operated in a 526 pro-active fashion to monitor the performance of the connection 527 continuously. Pro-active PM supports Fault Management functions, by 528 providing an indication of decreased service performance and as such 529 may provide triggers to initiate recovery procedures. 531 While on demand PM functions are, for the purposes of this document, 532 always initiated by management commands, for pro-active PM, it may be 533 desirable to utilize the control plane for configuration and 534 activation together with Fault Management functions such as the 535 Continuity Check. 537 [ITU-T.Y.1731-2011] defines dual-ended Loss Measurement as pro-active 538 OAM for performance monitoring and as a PM function applicable to 539 fault management. For dual-ended Loss Measurement each MEP piggy- 540 backs transmitted and received frame counters on CC messages; to 541 support and synchronize bidirectional Loss Measurements at the MEPs. 542 Dual-ended Loss Measurement is supported by setting the Performance 543 Monitoring/Loss OAM Function Flag and the Continuity Check Flag in 544 the OAM Function Flags Sub-TLV [RFC7260], and configuring the 545 Continuity Check functionality by including the Ethernet OAM 546 Configuration Sub-TLV. No additional configuration is required for 547 this type of Loss Measurement. 549 3.5. Summary of Ethernet OAM configuration errors 551 In addition to error values specified in [RFC7260] this document 552 defines the following values for the "OAM Problem" Error Code. 554 o If a node does not support a specific CFM version, an error MUST 555 be generated: "OAM Problem/Unsupported OAM Version". 557 o If a node does not support a specific MD Level, an error MUST be 558 generated: "OAM Problem/Unsupported MD Level". 560 o If an undefined MD name format is specified, an error MUST be 561 generated: "OAM Problem/Unknown MD Name Format". 563 o If an undefined MA name format is specified, an error MUST be 564 generated: "OAM Problem/Unknown MA Name Format". 566 o The combined length of MD Name and Short MA Name must be less or 567 equal to 44bytes, if this is violated an error MUST be generated: 568 "OAM Problem/Name Length Problem". 570 o If a node does not support the requested CCM Interval, an error 571 MUST be generated: "OAM Problem/Unsupported CC Interval". 573 4. IANA Considerations 575 4.1. RSVP-TE OAM Configuration Registry 577 IANA maintains the "RSVP-TE OAM Configuration Registry". IANA is 578 requested to assign an "OAM Type" from this registry as follows. 579 Allocate the value TBA1 for "Ethernet OAM" from the "OAM Type Sub- 580 Registry" of the "RSVP-TE OAM Configuration Registry". Allocate type 581 TBA2 for the "Ethernet OAM Configuration Sub-TLV" from the 582 technology-specific range of the "OAM Sub-TLVs Sub-Registry" of the 583 "RSVP-TE OAM Configuration Registry". 585 RSVP-TE OAM Configuration Registry 587 OAM Types Sub-Registry 589 OAM Type Number | Description | Reference 590 ------------------------------------------------- 591 TBA1 | Ethernet OAM | [This.ID] 593 OAM Sub-TLVs Sub-Registry 595 Sub-TLV Type | Description | Ref. 596 ---------------------------------------------------------- 597 TBA2 |Ethernet OAM Configuration Sub-TLV|[This.ID] 599 The value of 1 is suggested for TBA1. The value of 32 is suggested 600 for TBA2. 602 4.2. Ethernet Sub-TLVs Sub-Registry 604 IANA is requested to maintain an Ethernet Sub-TLVs Sub-Registry in 605 the "RSVP-TE OAM Configuration Registry" for the sub-TLV types 606 carried in the Ethernet OAM Configuration Sub-TLV. This document 607 defines the following types. 609 Ethernet Sub-TLVs Sub-Registry 611 Range | Registration Procedures 612 ------------+---------------------------- 613 0-65534 | IETF Review 614 65535-65536 | Experimental 616 Sub-TLV Type | Description | Ref. 617 --------------------------------------------------- 618 0 | Reserved | [This.ID] 619 1 | MD Name Sub-TLV | [This.ID] 620 2 | Short MA Name Sub-TLV | [This.ID] 621 3 | MEP ID Sub-TLV | [This.ID] 622 4 | Continuity Check Sub-TLV | [This.ID] 623 5-65536 | Unassigned | [This.ID] 625 4.3. RSVP Error Code 627 IANA maintains an Error Code, "OAM Problem" in the "Error Codes and 628 Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource 629 Reservation Protocol (RSVP) Parameters" registry. [RFC7260] defines 630 a set of Error Value sub-codes for the "OAM Problem" Error Code. 632 This document defines additional Error Values sub-codes for the "OAM 633 Problem" Error Code as summarized below. 635 Value | Description | Reference 636 -------+---------------------------+-------------- 637 TBA | Unsupported OAM Version | [This.ID] 638 TBA | Unsupported MD Level | [This.ID] 639 TBA | Unknown MD Name Format | [This.ID] 640 TBA | Unknown MA Name Format | [This.ID] 641 TBA | Name Length Problem | [This.ID] 642 TBA | Unsupported CC Interval | [This.ID] 644 5. Security Considerations 646 This document does not introduce any additional security issue to 647 those discussed in [RFC7260] and [RFC6060]. 649 The signaling of OAM-related parameters and the automatic 650 establishment of OAM entities based on RSVP-TE messages add a new 651 aspect to the security considerations discussed in [RFC3473]. In 652 particular, a network element could be overloaded if a remote 653 attacker targeted that element by sending frequent periodic messages 654 requesting liveliness monitoring of a high number of LSPs. Such an 655 attack can efficiently be prevented when mechanisms for message 656 integrity and node authentication are deployed. Since the OAM 657 configuration extensions rely on the hop-by-hop exchange of exiting 658 RSVP-TE messages, procedures specified for RSVP message security in 659 [RFC2747] can be used to mitigate possible attacks. 661 For a more comprehensive discussion of GMPLS security and attack 662 mitigation techniques, please see the Security Framework for MPLS and 663 GMPLS Networks [RFC5920]. 665 6. Acknowledgements 667 The authors would like to thank Francesco Fondelli, Adrian Farrel, 668 Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful 669 comments. 671 7. Contributors 673 - Don Fedyk, don.fedyk@hp.com 674 - Dinesh Mohan, dinmohan@hotmail.com 676 8. References 678 8.1. Normative References 680 [IEEE.802.1Q-2011] 681 IEEE, "IEEE Standard for Local and metropolitan area 682 networks -- Media Access Control (MAC) Bridges and Virtual 683 Bridged Local Area Networks", IEEE Std 802.1Q, 2011. 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, March 1997. 688 [RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, 689 "Generalized Multiprotocol Label Switching (GMPLS) Control 690 of Ethernet Provider Backbone Traffic Engineering (PBB- 691 TE)", RFC 6060, March 2011. 693 [RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE 694 Extensions for Operations, Administration, and Maintenance 695 (OAM) Configuration", RFC 7260, June 2014. 697 8.2. Informative References 699 [ITU-T.Y.1731-2011] 700 ITU, "ITU-T Recommendation Y.1731: OAM functions and 701 mechanisms for Ethernet based networks", ITU-T 702 Recommendation Y.1731, 2011. 704 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 705 Authentication", RFC 2747, January 2000. 707 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 708 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 709 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 711 [RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized 712 Multiprotocol Label Switching (GMPLS) Ethernet Label 713 Switching Architecture and Framework", RFC 5828, March 714 2010. 716 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 717 Networks", RFC 5920, July 2010. 719 Authors' Addresses 720 Attila Takacs 721 Ericsson 722 Konyves Kalman krt. 11. 723 Budapest 1097 724 Hungary 726 Email: attila.takacs@ericsson.com 728 Balazs Peter Gero 729 Ericsson 730 Konyves Kalman krt. 11. 731 Budapest 1097 732 Hungary 734 Email: balazs.peter.gero@ericsson.com 736 Hao Long 737 Huawei 738 PR China 740 Email: lonho@huawei.com