idnits 2.17.1 draft-tissa-trill-oam-fm-02.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 (May 28, 2013) is 3957 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) -- Possible downref: Non-RFC (?) normative reference: ref. '8021Q' -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working group Tissa Senevirathne 2 Internet Draft Norman Finn 3 Intended status: Standard Track Samer Salam 4 Deepak Kumar 5 CISCO 7 Donald Eastlake 8 Sam Aldrin 9 Yizhou Li 10 Huawei 12 May 28, 2013 13 Expires: November 2013 15 TRILL Fault Management 16 draft-tissa-trill-oam-fm-02.txt 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on November 28, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Abstract 58 TRILL OAM Fault Management specification is presented in this 59 document. Methods in this document follow the IEEE 802.1 CFM 60 framework and reuse OAM tools where possible. Additional messages and 61 TLVs are defined for TRILL specific applications or where a different 62 set of information is required other than IEEE 802.1 CFM. 64 Table of Contents 66 1. Introduction...................................................4 67 2. Conventions used in this document..............................4 68 3. General Format of TRILL OAM frames.............................5 69 3.1. Identification of TRILL OAM frames........................7 70 3.2. Use of TRILL OAM Flag.....................................7 71 3.2.1. Handling of TRILL frames with the "A" Flag...........8 72 3.3. Backwards Compatibility Method............................8 73 3.4. OAM Capability Announcement..............................10 74 4. TRILL OAM Layering vs. IEEE Layering..........................11 75 4.1. Processing at ISS Layer..................................12 76 4.1.1. Receive Processing..................................12 77 4.1.2. Transmit Processing.................................12 78 4.2. End Station VLAN and Priority Processing.................12 79 4.2.1. Receive Processing..................................12 80 4.2.2. Transmit Procession.................................12 81 4.3. TRILL Encapsulation and De-capsulation Layer.............13 82 4.3.1. Receive Processing for Unicast packets..............13 83 4.3.2. Transmit Processing for unicast packets.............13 84 4.3.3. Receive Processing for Multicast packets............14 85 4.3.4. Transmit Processing of Multicast packets............15 86 4.4. TRILL OAM Layer Processing...............................16 87 5. Maintenance Associations (MA) in TRILL........................17 88 6. MEP Addressing................................................18 89 6.1. Use of MIP in TRILL......................................21 90 7. Approach for Backwards Compatibility..........................23 91 8. Continuity Check Message (CCM)................................24 92 9. TRILL OAM Message Channel.....................................26 93 9.1. TRILL OAM Message header.................................26 94 9.2. TRILL OAM Opcodes........................................27 95 9.3. Format of TRILL OAM TLV..................................27 96 9.4. TRILL OAM TLVs...........................................28 97 9.4.1. Common TLVs between 802.1ag and TRILL...............28 98 9.4.2. TRILL OAM Specific TLVs.............................29 99 9.4.3. TRILL OAM Application Identifier TLV................29 100 9.4.4. Out Of Band Reply Address TLV.......................31 101 9.4.5. Diagnostics Label TLV...............................31 102 9.4.6. Original Data Payload TLV...........................32 103 9.4.7. RBridge scope TLV...................................33 104 9.4.8. Previous RBridge nickname TLV.......................33 105 9.4.9. Next Hop RBridge List TLV...........................34 106 9.4.10. Multicast Receiver Port count TLV..................35 107 9.4.11. Flow Identifier (flow-id) TLV......................35 108 10. Loopback Message.............................................37 109 10.1. Loopback OAM Message format.............................37 110 10.2. Theory of Operation.....................................37 111 10.2.1. Originator RBridge.................................37 112 10.2.2. Intermediate RBridge...............................38 113 10.2.3. Destination RBridge................................38 114 11. Path Trace Message...........................................39 115 11.1. Theory of Operation.....................................39 116 11.1.1. Originator RBridge.................................39 117 11.1.2. Intermediate RBridge...............................40 118 11.1.3. Destination RBridge................................41 119 12. Multi-Destination Tree Verification (MTV) Message............41 120 12.1. Multi-Destination Tree Verification (MTV) OAM Message Format 121 ..............................................................42 122 12.2. Theory of Operation.....................................42 123 12.2.1. Originator RBridge.................................42 124 12.2.2. Receiving RBridge..................................44 125 12.2.3. In scope RBridges..................................44 126 13. Application of Continuity Check Message (CCM) in TRILL.......45 127 13.1. CCM Error Notification..................................45 128 13.2. Theory of Operation.....................................47 129 13.2.1. Originator RBridge.................................47 130 13.2.2. Intermediate RBridge...............................47 131 13.2.3. Destination RBridge................................47 132 14. Fragmented Reply.............................................48 133 15. Security Considerations......................................48 134 16. IEEE Allocation Considerations...............................48 135 17. IANA Considerations..........................................49 136 18. References...................................................49 137 18.1. Normative References....................................49 138 18.2. Informative References..................................49 140 19. Acknowledgments..............................................50 141 Appendix A. Unicast MAC Request..................................51 143 1. Introduction 145 The general structure of TRILL OAM messages is presented in 146 [TRLOAMFRM]. According to [TRLOAMFRM], TRILL OAM messages consist of 147 five parts: link header, TRILL header, flow entropy, OAM message 148 channel, and link trailer. 150 The OAM message channel allows defining various control information 151 and carrying OAM related data between TRILL switches, also known as 152 RBridges or Routing Bridges. 154 A common OAM message channel representation can be shared between 155 different technologies. This enables consistency between different 156 OAM technologies and promotes nested fault monitoring and isolation 157 between technologies that share the same OAM framework. 159 This document uses the message format defined in IEEE 802.1ag 160 Connectivity Fault Management (CFM) [8021Q] as the basis for the 161 TRILL OAM message channel. 163 The ITU-T Y.1731 [Y1731] standard utilizes the same messaging format 164 as [8021Q] and OAM messages where applicable. This documenttake a 165 similar stance and propose reusing [8021Q] in TRILL OAM. It is 166 assumed readers are familiar with [8021Q] and [Y1731]. Readers who 167 are not familiar with these documents are encouraged to review them. 169 2. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC-2119 [RFC2119]. 175 Acronyms used in the document include the following: 177 MP - Maintenance Point [TRLOAMFRM] 179 MEP - Maintenance End Point [TRLOAMFRM] [8021Q] 181 MIP - Maintenance Intermediate Point [TRLOAMFRM] [8021Q] 183 MA - Maintenance Association [8021Q] [TRLOAMFRM] 185 MD - Maintenance Domain [8021Q] 186 CCM - Continuity Check Message [8021Q] 188 LBM - Loop Back Message [8021Q] 190 PTM - Path Trace Message 192 MTV - Multi-destination Tree Verification Message 194 OAM - Operations, Administration, and Maintenance [RFC6291] 196 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 198 FGL - Fine Grained Label [RFCfgl] 200 ECMP - Equal Cost Multipath 202 ISS - Internal Sub Layer Service [8021Q] 204 3. General Format of TRILL OAM frames 206 The TRILL forwarding paradigm allows an implementation to select a 207 path from a set of equal cost paths to forward a unicast TRILL Data 208 packet. For multi-destination TRILL Data packets, a distribution tree 209 is chosen by the TRILL switch that ingresses or creates the packet. 210 Selection of the path of choice is implementation dependent at each 211 hop for unicast and at the ingress for multi-destination. However, it 212 is a common practice to utilize Layer 2 through Layer 4 information 213 in the frame payload for path selection. 215 For accurate monitoring and/or diagnostics, OAM Messages are required 216 to follow the same path as corresponding data packets. [TRLOAMFRM] 217 proposes a high-level format of the OAM messages. The details of the 218 TRILL OAM frame format are defined in this document. 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | | 222 . Link Header . (variable) 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 + TRILL Header + 8 or more bytes 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 . Flow Entropy . 96 bytes 231 . . 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | OAM Ether Type | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 . OAM Message Channel . Variable 238 . . 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Link Trailer | Variable 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 1 Format of TRILL OAM Messages 246 Link Header: Media-dependent header. For Ethernet, this includes 247 Destination MAC, Source MAC, VLAN (optional) and EtherType fields. 249 TRILL Header: Minimum of 8 bytes when the Extended Header is not 250 included [RFC6325] 252 Flow Entropy: This is a 96-byte fixed size field. The least 253 significant bits of the field MUST be padded with zeros, up to 96 254 bytes, when the flow entropy is less than 96 bytes. Flow entropy 255 enables emulation of the forwarding behavior of the desired data 256 packets. The Flow Entropy field starts with the Inner.MacDA. The 257 offset of the Inner.MacDA depends on whether extensions are included 258 or not as specified in [TRILLEXT] and [RFC6325]. 260 OAM Ether Type: OAM Ether Type is 16-bit EtherType that identifies 261 the OAM Message channel that follows. This document specifies using 262 the EtherType allocated for 802.1ag for this purpose. Identifying the 263 OAM Message Channel with a dedicated EtherType allows the easy 264 identification of the beginning of the OAM message channel across 265 multiple standards. 267 OAM Message Channel: This is a variable size section that carries OAM 268 related information. Message format defined in [8021Q] will be reused 269 for TRILL OAM. 271 Link Trailer: Media-dependent trailer. For Ethernet, this is the FCS 272 (Frame Check Sequence). 274 3.1. Identification of TRILL OAM frames 276 TRILL, as originally specified in [RFC6325], did not have a specific 277 flag or a method to identify OAM frames. This document updates 278 [RFC6325] to include specific methods to identify TRILL OAM frames. 279 Section 3.2. below explains the details of the method. However, it is 280 important, for backwards compatibility reasons, to define methods of 281 identifying TRILL OAM frames without using these extensions. Section 282 3.3. presents a set of possible methods for identifying OAM frames 283 without using the proposed extensions of section 3.2. The methods 284 defined in section 3.3. impose limitations on the construction of the 285 flow entropy field of the OAM frames but MUST be used when backward 286 compatibility is required with TRILL switches not supporting the 287 method specified in Section 3.2. 289 3.2. Use of TRILL OAM Flag 291 The TRILL Header, as defined in [RFC6325], has two reserved bits that 292 are currently unused. RBridges are currently required to ignore these 293 fields. This document specifies use of the reserved bit next to 294 Version field in the TRILL header as the Alert flag. Alert flag will 295 be denoted by "A". 297 Implementations that support the extension of using the "A" flag to 298 identify frames MUST use that flag and the methods specified in 299 section 3.2.1. The "A" flag MUST NOT be utilized for forwarding 300 decisions such as the selection of which ECMP path or multi- 301 destination tree to use. 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | V |A|R|M|Op-Length| Hop Count | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Egress RBridge Nickname | Ingress RBridge Nickname | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Options... 309 +-+-+-+-+-+-+-+-+-+-+-+- 311 Figure 2 TRILL Header 313 A (1 bit) - Indicates this is a possible OAM frame and is subject to 314 specific handling as specified in this document. 316 All other fields carry the same meaning as defined in RFC6325. 318 3.2.1. Handling of TRILL frames with the "A" Flag 320 Value "1" in the A flag indicates TRILL frames that may qualify as 321 OAM frames. Implementations are further required to validate such 322 frames by comparing the value at the OAM Ether Type (Figure 1) 323 location with the CFM EtherType "0x8902" [8021Q]. If the value 324 matches, such frames are identified as TRILL OAM frames and SHOULD be 325 processed as discussed in Section 4. 327 3.3. Backwards Compatibility Method 329 Backward compatibility method presented in this section defines 330 methods to identify OAM frames when implementations do not have 331 capabilities to utilize TRILL OAM Alert flag presented earlier. It is 332 assumed ECMP path selection of non-IP flows utilize MAC DA, MAC SA 333 and VLAN, IP Flows utilize IP DA, IP SA and TCP/UDP port numbers and 334 other Layer 3 and Layer 4 information. The well-known fields to 335 identify OAM flows are chosen such that, they mimic the ECMP 336 selection of the actual data along the path. However, it is important 337 to note that, there may be implementations that would utilize these 338 well-known fields for ECMP selections. Hence, implementations that 339 support OAM SHOULD move to utilizing TRILL OAM Flag, as soon as 340 possible and methods presented here SHOULD be used only as an interim 341 solution. 343 Identification methods are divided in to 4 broader groups. 345 Identification of Unicast non-IP OAM Flows, 346 Identification of Multicast non-IP OAM Flows, 348 Identification of Unicast IP OAM Flows and 350 Identification of Multicast IP OAM Flows 352 As presented in the table below, based on the flow type (as defined 353 above), implementations are required to use a well-known value in 354 either the source MAC field or Ethertype field to identify OAM flows. 356 Receiving RBridges identifies OAM flows based on the presence of the 357 well-known values in the specified fields, AND additionally, for 358 unicast flows, egress RBRdige nickname of the packet MUST match that 359 of the local RBRidge or for multicast flows, TRILL header mutlicast 360 flag MUST be set. 362 Unicast OAM flows that qualify for local processing MUST be 363 redirected to the OAM process and MUST NOT be forward along (that to 364 prevent leaking of the packet out of the TRILL campus). 366 A copy of Multicast OAM flows that qualify for local processing MUST 367 be sent to the OAM process and packet MUST be forwarded along the 368 normal path. Additionally, methods MUST be in place to prevent 369 multicast packets leaking out of the TRILL campus. 371 The following table summarizes the identification of different OAM 372 frames from data frames. 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |Flow Entropy |Inner |OAM Ether|Egress | 376 | |MacSA |Type |nickname | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |unicast no IP | N/A |Match |Match | 379 | | | | | 380 |Multicast no IP| N/A |Match |N/A | 381 | | | | | 382 |Unicast IP | Match |N/A |Match | 383 | | | | | 384 |Multicast IP | Match |N/A |N/A | 385 | | | | | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 3 Identification of TRILL OAM Frames 390 3.4. OAM Capability Announcement 392 Any given TRILL RBridge can be (1) OAM incapable or (2) OAM capable 393 with new extensions or (3) OAM capable with backwards-compatible 394 method. The OAM request originator, prior to origination of the 395 request is required to identify the OAM capability of the target and 396 generate the appropriate OAM message. 398 Capability flags defined in TRILL version sub-TLV (TRILL-VER) 399 [rfc6326bis] will be utilized for announcing OAM capabilities. The 400 following OAM related Flags are defined: 402 O - OAM Capable 404 B - Backwards Compatible. 406 A capability announcement, with O Flag set to 1 and B flag set to 1, 407 indicates that the implementation is OAM capable but utilize 408 backwards compatible method defined in section 3.3. A capability 409 announcement, with O Flag set to 1 and B flag set to 0, indicates 410 that the implementation is OAM capable and utilizes the method 411 specified in section 3.2. 413 When O Flag is set to 0, the announcing implementation is considered 414 not capable of OAM and in this case the B flag is ignored. 416 +-+-+-+-+-+-+-+-+ 417 | Type | (1 byte) 418 +-+-+-+-+-+-+-+-+ 419 | Length | (1 byte) 420 +-+-+-+-+-+-+-+-+ 421 | Max-version | (1 byte) 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 423 |A|O|B|Other Capabilities and Header Flags| (4 bytes) 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ 425 0 1 3 426 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 428 Figure 4 TRILL-VER sub-TLV [rfc6326bis] with O and B flags 430 NOTE: Bit position of O and B flags in the TRILL-VER sub-TLV are 431 presented above as an example. Actual positions of the flags will be 432 determined by TRILL WG and IANA and future revision of this document 433 will be updated to include the allocations. 435 4. TRILL OAM Layering vs. IEEE Layering 437 This section presents the placement of the TRILL OAM shim within the 438 IEEE 802.1 layers. The processing of both the Transmit and Receive 439 directions is explained. 441 +-+-+-+-+-+-+-+-+-+-+ 442 | RBridge Layer | 443 | Processing | 444 +-+-+-+-+-+-+-+-+-+-+ 445 | 446 | 447 +-+-+-+-+-+-+ 448 | TRILL OAM | UP MEP 449 | Layer | MIP 450 +-+-+-+-+-+-+ Down MEP 451 | 452 | 453 +-+-+-+-+-+-+ 454 (3)--------> | TRILL | 455 | Encap/Decap 456 +-+-+-+-+-+-+ 457 | 458 +-+-+-+-+-+-+ 459 (2)--------> |End station| 460 | VLAN & priority Processing 461 +-+-+-+-+-+-+ 462 | 463 +-+-+-+-+-+-+ 464 (1)--------> |ISS | 465 |Processing | 466 +-+-+-+-+-+-+ 467 | 468 | 469 | 471 Figure 5 Placement of TRILL MP within IEEE 802.1 473 [RFC6325] Section 4.6 provides a detailed explanation of frame 474 processing. Please refer to [RFC6325] for processing scenarios not 475 covered herein. 477 Sections 4.1 and 4.2 below apply to links using a broadcast LAN 478 technology such as Ethernet. 480 On links using an inherently point-to-point technology, such as PPP 481 [RFC6361], there is no Outer.MacDA, Outer.MacSA, our Outer.VLAN 482 because these are part of the link for Ethernet. Point-to-point links 483 typically have link headers without these fields. These fields are 484 primarily significant for native frames from and/or to end stations. 486 4.1. Processing at ISS Layer 488 4.1.1. Receive Processing 490 The ISS Layer receives an indication from the port. It extracts DA, 491 SA and marks the remainder of the payload as M1. ISS Layer passes on 492 (DA,SA,M1) as an indication to the higher layer. 494 For TRILL Ethernet frames, this is Outer.MacDA and Outer.MacSA. M1 is 495 the remainder of the packet. 497 4.1.2. Transmit Processing 499 The ISS layer receives an indication from the higher layer that 500 contains (DA, SA, M1). It constructs an Ethernet frame and passes 501 down to the port. 503 4.2. End Station VLAN and Priority Processing 505 4.2.1. Receive Processing 507 Receives (DA, SA, M1) indication from ISS Layer. Extracts the VLAN ID 508 an priority from the M1 part of the received indication and 509 constructs (DA, SA, VLAN, PRI, M2). VLAN+PRI+M2 map to M1 in the 510 received indication. Pass (DA, SA, VLAN, PRI, M2) to the TRILL 511 encap/decap procession layer. 513 4.2.2. Transmit Procession 515 Receive (DA, SA, VLAN, PRI, M2) indication from TRILL encap/decap 516 processing layer. Merge VLAN, M2 to form M1. Pass down (DA, SA, M1) 517 to the ISS processing Layer. 519 4.3. TRILL Encapsulation and De-capsulation Layer 521 4.3.1. Receive Processing for Unicast packets 523 Receive indication (DA, SA, VLAN,PRI,M2) from End Station VLAN and 524 Priority Processing Layer. 526 o If DA matches port Local DA and Frame is of TRILL EtherType 528 . Discard DA, SA, VLAN, PRI. From M2, derive (TRILL-HDR, iDA, 529 iSA, i-VL, M3) 531 . If TRILL nickname is Local and TRILL-OAM Flag is set 533 Pass on to OAM processing 535 . Else pass on (TRILL-HDR, iDA, iSA, i-VL, M3) to RBridge 536 Layer 538 o If DA matches port Local DA and EtherType is RBridge-Channel 539 [Channel] 541 . Process as a possible unicast native RBridge Channel packet 543 o If DA matches port Local DA and EtherType is neither TRILL nor 544 RBridge-Channel 546 . Discard packet 548 o If DA does not match and port is Appointed Forwarder for VLAN and 549 EtherType is not TRILL or RBridge-Channel 551 . Insert TRILL-Hdr and send (TRILL-HDR, iDA, iSA,i-VL, M3) 552 indication to RBridge Layer <- This is the ingress function 554 4.3.2. Transmit Processing for unicast packets 556 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from RBridge 557 Layer 559 o If egress TRILL nickname is local 561 o If port is Appointed Forwarder for iVL and the port is not 562 configured as a trunk or p2p port and (TRILL Alert Flag set 563 and OAM EtherType present) then 565 . Strip TRILL-HDR and construct (DA, SA, VLAN, M2) 567 o Else 569 . Discard packet 571 o If egress TRILL nickname is not local 573 o Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, TRILL EtherType 574 and construct (DA,SA,VLAN,M2). Where M2 is (TRILL-HDR, iDA, 575 iSA, iVL, M) 577 o Forward (DA,SA,V,M2) to the VLAN End Station processing Layer. 579 4.3.3. Receive Processing for Multicast packets 581 o Receive (DA,SA,V,M2) from VLAN aware end station processing 582 layer 584 o If the DA is All-RBridges and the EtherType is TRILL 586 o Strip DA,SA and V. From M2, extract (TRILL-HDR, iDA, iSA, 587 iVL and M3). 589 o If TRILL OAM Flag is set and OAM EtherType is present at the 590 end of Flow entropy 592 . Perform OAM Processing 594 o Else extract the TRILL header, inner MAC addresses and inner 595 VLAN and pass indication (TRILL-HDR, iDA, iSA, iVL and M3) 596 to TRILL RBridge Layer 598 o If the DA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS 599 then pass frame up to TRILL IS-IS processing 601 o If the DA is All-RBridges or All-IS-IS-RBridges but Ethertype 602 is not TRILL or L2-IS-IS respectively 604 o Discard the packet 606 o If the EtherType is TRILL but the multicast DA is not All- 607 RBridge or if the EtherType is L2-IS-IS but the multicast Da is 608 not All-IS-IS-RBridges 610 o Discard the packet 612 o If DA is All-Edge-RBridges and EtherType is RBridge-Channel 613 [Channel] 614 o Process as a possible multicast native RBridge Channel 615 packet 617 o If the DA is in the initial bridging/link protocols block (01- 618 80-C2-00-00-00 to 01-80-C2-00-00-0F) or is in the TRILL block 619 and not assigned for Outer.MacDA use (01-80-C2-00-00-42 to 01- 620 80-C2-00-00-4F) then 622 o The frame is not propagated through an RBridge although some 623 special processing may be done at the port as specified in 624 [RFC6325] and the frame may be dispatched to Layer 2 625 processing at the port if certain protocols are supported 626 by that port (examples: Link Aggregation Protocol, Link 627 Layer Discovery Protocol). 629 o If the DA is some other multicast value 631 o Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA, IVL, 632 M3) 634 o Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to RBridge Layer 636 4.3.4. Transmit Processing of Multicast packets 638 The following ignores the case of transmitting TRILL IS-IS packets. 640 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from RBridge 641 layer. 643 o If TRILL-HDR multicast flag set and TRILL-HDR Alert flag set 644 and OAM EtherType present then: 646 o (DA,SA,V,M2) by inserting TRILL Outer.MacDA of All- 647 RBridges, Outer.MacSA, Outer.VL and TRILL EtherType. M2 648 here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, M) 650 NOTE: Second copy of native format is not made. 652 o Else If TRILL-HDR multicast flag set and Alert flag not set 654 o If the port is appointed Forwarder for iVL and the port is 655 not configured as a trunk port or a p2p port, Strip TRILL- 656 HDR, iSA, iDA, iVL and construct (DA,SA,V,M2) for native 657 format. 659 o Make a second copy (DA,SA,V,M2) by inserting TRILL 660 Outer.MacDA, Outer.MacSA, Outer.VL and TRILL EtherType. M2 661 here is (EtherType TRILL, TRILL-HDR, iDA, iSA, iVL, M) 663 o Pass the indication (DA,SA,V,M2) to End Station VLAN processing 664 layer. 666 4.4. TRILL OAM Layer Processing 668 TRILL OAM Processing Layer is located between the TRILL Encapsulation 669 / De-capsulation layer and RBridge Layer. It performs 1. 670 Identification of OAM frames that need local processing 2. Perform 671 OAM processing or redirect to the CPU for OAM processing. 673 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from RBridge 674 layer. 676 o If the TRILL Multicast Flag is set and TRILL Alert Flag is set 677 and TRILL OAM EtherType is present then 678 o If MEP or MIP is configured on the Inner.VLAN of the packet 679 then 680 . discard packets that have MD-LEVEL Less than that of 681 the MEP or packets that do not have MD-LEVEL present 682 (e.g due to packet truncation). 683 . If MD-LEVEL matches MD-LEVEL of the MEP then 684 . Re-direct to OAM Processing (Do not forward 685 further) 686 . If MD-LEVEL matches MD-LEVEL of MIP then 687 . Make a Copy for OAM processing and continue 689 o Else if TRILL Alert Flag is set and TRILL OAM EtherType is 690 present then 691 o If MEP or MIP is configured on the Inner.VLAN of the packet 692 then 693 . discard packets that have MD-LEVEL not present or MD- 694 LEVEL is Less than that of the MEP. 695 . If MD-LEVEL matches MD-LEVEL of the MEP then 696 . Re-direct to OAM Processing (Do not forward 697 further) 698 . If MD-LEVEL matches MD-LEVEL of MIP then 699 . Make a Copy for OAM processing and continue 701 o Else // Non OAM l Packet 702 o Continue 704 o Pass the indication (DA,SA,V,M2) to End Station VLAN processing 705 layer. 707 NOTE: In the Received path, processing above compares against Down 708 MEP and MIP Half functions. In the transmit processing it compares 709 against Up MEP and MIP Half functions. 711 Appointed Forwarder is a Functionality that TRILL Encap/De-Cap layer 712 performs. The TRILL Encap/De-cap Layer is responsible for prevention 713 of leaking of OAM packets as native frames. 715 5. Maintenance Associations (MA) in TRILL 717 [8021Q] defines a maintenance association as a logical relationship 718 between a group of nodes. Each Maintenance Association (MA) is 719 identified with a unique MAID of 48 bytes [8021Q]. CCM and other 720 related OAM functions operate within the scope of an MA. The 721 definition of MA is technology independent. Similarly it is encoded 722 within the OAM message, not in the technology dependent portion of 723 the packet. Hence the MAID as defined in [8021Q] can be utilized for 724 TRILL OAM, without modifications. This also allows us to utilize CCM 725 and LBM messages defined in [8021Q], as is. 727 In TRILL, an MA may contain two or more RBridges (MEPs). For unicast, 728 it is likely that the MA contains exactly two MEPs that are the two 729 end-points of the flow. For multicast, the MA may contain two or more 730 MEPs. 732 For TRILL, in addition to all of the standard 802.ag MIB definitions, 733 each MEP's MIB contains one or more flow entropy definitions 734 corresponding to the set of flows that the MEP monitors. 736 [8021Q] MIB is augmented to add the TRILL specific information. 737 Figure 6, below depicts the augmentation of the CFM MIB to add the 738 TRILL specific Flow Entropy. 740 MA--- 741 | 742 --- MEP 743 | 744 . - Remote MEP List 745 . 746 | 747 --- MEP-A 748 | 749 --- MEP-B 750 . 752 | 753 . - Flow Entropy List { Augments IEEE8021-CFM-MIB} 755 | 756 --- (Flow Entropy-1) 757 | 758 --- (Flow-entropy-2) 759 | 760 . --- ( Flow Entropy n) 761 | 762 Other MIB entries 764 Figure 6 Correlation of TRILL augmented MIB 766 6. MEP Addressing 768 In IEEE 802.1ag [8021Q], OAM messages address the target MEP by 769 utilizing a unique MAC address. In TRILL MEP is addressed by 770 combination of the egress RBridge nickname and the Inner VLAN/FGL. 772 At the MEP, OAM packets go through a hierarchy of op-code de- 773 multiplexers. The op-code de-multiplexers channel the incoming OAM 774 packets to the appropriate message processor (e.g. LBM) The reader 775 may refer to Figure 7 below for a visual depiction of these different 776 de-multiplexers. 778 1. Identify the packets that need OAM processing at the Local RBridge 779 as specifies in Section 4. 781 a. Identify the MEP that is associated with the Inner.VLAN. 783 2. The MEP first validates the MD-LEVEL and then 785 a. Redirect to MD-LEVEL De-multiplexer 787 3. MD-LEVEL de-multiplexer compares the MD-Level of the packet 788 against the MD level of the local MEPs of a given MD-Level on the 789 port (Note: there can be more than one MEP at the same MD-Level 790 but belonging to different MAs) 792 a. If the packet MD-LEVEL is equal to the configured MD-LEVEL 793 of the MEP, then pass to the Opcode de-multiplexer 795 b. If the packet MD-LEVEL is less than the configured MD-LEVEL 796 of the MEP, discard the packet 798 c. If the packer MD-LEVEL is greater than the configured MD- 799 LEVEL of the MEP, then pass on to the next higher MD-LEVEL 800 de-multiplexer, if available. Otherwise, if no such higher 801 MD-LEVEL de-multiplexer exists, then forward the packet as 802 normal data. 804 4. Opcode De-multiplexer compares the opcode in the packet with 805 supported opcodes 807 a. If Op-code is CCM, LBM, LBR, PTM, PTR, MTVM, MTVR, then pass 808 on to the correct Processor 810 b. If Op-code is Unknown, then discard. 812 | 813 .CCM LBM PTM MTV 814 | | | | 815 +-+-+-+-+-+-+-+-+-+-+-+-+ 816 | OP Code DE-Mux |--- Unknown 817 +-+-+-+-+-+-+-+-+-+-+-+-+ 818 ^ ^ ^ 819 MD==Li | | | 820 +-+-+ +-+-+ +-+-+ 821 | L |-->|L2 |-.- |Ln |---- > 822 +-+-+ +-+-+ +-+-+ | 823 | ^ | | | 824 MD
  • | T |----------------- >| M |--- > 831 + TRILL OAM ---- + pass through OAM ---- 833 Figure 7 OAM De-Multiplexers at MEP for active SAP 835 T : Denotes Tap, that identifies OAM frames that need local 836 processing. These are the packets with OAM flag set AND OAM 837 Ether type is present after the flow entropy of the packet 839 M : Is the post processing merge, merges data and OAM messages 840 that are pass through. Additionally, Merge the component 841 ensures, as explained earlier, that OAM packets are not 842 forwarded out as native frames. 844 L : Denotes MD-Level processing. Packets with MD-Level less than 845 the Level will be dropped. Packets with equal MD-Level are 846 passed on to the opcode de-multiplexer. Others are passed on to 847 the next level MD processors or eventually to the merge point 848 (M). 850 NOTE: LBM, MTV and PT are not subject to MA de-multiplexers. 851 These packets do not have an MA encoded in the packet. Adequate 852 response can be generated to these packets, without loss of 853 functionality, by any of the MEPs present on that interface or 854 an entity within the RBridge. 856 6.1. Use of MIP in TRILL 858 Maintenance Intermediate Points (MIP) are mainly used for fault 859 isolation. Link Trace Messages in [8021Q] utilize a well-known 860 multicast MAC address and MIPs generate responses to Link Trace 861 messages. Response to Link Trace messages or lack thereof can be used 862 for fault isolation in TRILL. 864 As explained in section 11. , hop-count expiry approach will be 865 utilized for fault isolation and path tracing. The approach is very 866 similar to the well-known IP trace-route approach. Hence, explicit 867 addressing of MIPs is not required for the purpose of fault 868 isolation. 870 Any given RBridge can have multiple MIPs located within an interface. 871 As such, a mechanism is required to identify which MIP should respond 872 to an incoming OAM message. 874 Similar approach as presented above for MEPs can be used for MIP 875 processing. It is important to note that "M", the merge block of a 876 MIP, does not prevent OAM packets leaking out as native frames. On 877 edge interfaces, MEPs MUST be configured to prevent the leaking of 878 TRILL OAM packets out of the TRILL Campus. 880 PT MTV 881 | | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | OP Code De-Mux |-> Unknown 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 ^ ^ ^ 886 MD==Li | | | 887 +-+-+ +-+-+ +-+-+ 888 | L |- >|L2 |-.- |Ln |------+ 889 +-+-+ +-+-+ +-+-+ | 890 ^ | 891 | | 892 Drop | | 893 MD not --- |TRILL OAM | 894 Present | | 895 | v 896 TRILL Data ---- TRILL Data ----- 897 ------- >| T |------------------ >| M |----> 898 + TRILL OAM ---- ---- 900 Figure 8 OAM De-Multiplexers at MIP for active SAP 902 T: TAP processing for MIP. All packets with OAM flag set are 903 captured. 905 L : MD Level Processing, Packet with matching MD Level are "copied" 906 to the Opcode de-multiplexer and original packet is passed on to the 907 next MD level processor. Other packets are simply passed on to the 908 next MD level processor, without copying to the OP code de- 909 multiplexer. 911 M : Merge processor, merge OAM packets to be forwarded along with the 912 data flow. 914 Packets that carry Path Trace Message (PTM) or Multi-destination Tree 915 Verification (MTV) OpCode are passed on to the respective processors. 917 Packets with unknown OpCodes are counted and discarded. 919 7. Approach for Backwards Compatibility 921 Methodology presented above in this document is in-line with the 922 [8021Q] framework for providing fault management coverage. However, 923 in practice, some platforms may not have the required capabilities to 924 support some of the proposed techniques. In this section, we present 925 a method that allows RBridges, which do not have the required 926 hardware capabilities, to participate in the proposed OAM solution. 928 For backwards compatibility, MEPs and MIPs are located in the CPU. 929 This will be referred to as the "central brain" model as opposed to 930 "port brain" model. 932 In the "central brain" model, an RBridge using either ACLs or some 933 other method, forwards qualifying OAM messages to the CPU. The CPU 934 then performs the required processing and multiplexing to the correct 935 MP (Maintenance Point). 937 Additionally, RBridges MUST have the capability to prevent the 938 leaking of OAM packets, as specified in [RFC6905] and in the 939 Transmission processing in Figure 9. 941 Receiver Processing: 943 If (M==1 && F==1) then 944 Copy to CPU and Forward normally as defined in [RFC6325] 945 Else if (M==0 && F==1 && egress nickname is the processing RBridge) 946 then 947 Forward to CPU BUT DO NOT forward along the data plane 949 Else 950 Forward as defined in [RFC6325] 951 End; 953 Transmit Processing: 955 If (F==1) then 956 Forward as defined in [RFC6325] BUT Do not de-capsulate and forward 957 as a native frame 958 Else 959 Forward as defined in [RFC6325] 961 Figure 9 Pseudo code for Backward compatible Processing 963 [8021Q] requires that the MEP filters or pass through OAM messages 964 based on the MD-Level. The MD-Level is embedded deep in the OAM 965 message. Hence, conventional methods of frame filtering may not be 966 able to filter frames based on the MD-Level. As a result, OAM 967 messages that must be dropped due to MD level mismatch may leak in to 968 a TRILL domain with different MD-Level. 970 This leaking may not cause any functionality loss. The receiving 971 MEP/MIP is required to validate the MD-level prior to acting on the 972 message. Any frames received with an incorrect MD-Level will be 973 dropped. 975 Generally, TRILL campuses are managed by a single operator, hence 976 there is no risk of security exposure. However, in the event of multi 977 operator deployments, operators should be aware of possible exposure 978 of device specific information and appropriate measures must be 979 taken. 981 It is also important to note that the MPLS OAM [RFC4379] framework 982 does not include the concept of domains and OAM filtering based on 983 operators. It is our opinion that the lack of OAM frame filtering 984 based on domains does not introduce significant functional deficiency 985 or security risk. 987 8. Continuity Check Message (CCM) 989 CCMs are used to monitor connectivity and configuration errors. 990 [8021Q] monitors connectivity by listening to periodic CCM messages 991 received from its remote MEP partners in the MA. An [8021Q] MEP 992 identifies cross-connect errors by comparing the MAID in the received 993 CCM message with the MEP's local MAID. The MAID [8021Q] is a 48 byte 994 field that is technology independent. Similarly, the MEPID is a 2 995 byte field that is independent of the technology. Given this generic 996 definition of CCM fields, CCM as defined in [8021Q] can be utilized 997 in TRILL with no changes. TRILL specific information may be carried 998 in CCMs when encoded using TRILL specific TLVs or sub-TLVs. This is 999 possible since CCMs may carry optional TLVs. 1001 Unlike classical Ethernet environments, TRILL contains multipath 1002 forwarding. The path taken by a packet depends on the payload of the 1003 packet. The Maintenance Association identifies the interested end- 1004 points (MEPs) of a given monitored path. For unicast there are only 1005 two MEPs per MA. For multicast there can be two or more MEPs in the 1006 MA. The entropy values of the monitored flows is defined within the 1007 MA. CCM transmit logic will utilize these flow entropy values when 1008 constructing the CCM packets. Please see section 13. below for the 1009 theory of operation of CCM. 1011 The MIB of [8021Q] is augmented with the definition of flow-entropy. 1012 Please see [TRILLOAMMIB] for definition of these and other TRILL 1013 related OAM MIB definitions. Below Figure depicts the correlation 1014 between MA, CCM and proposed flow-entropy. 1016 MA--- 1017 | 1018 --- MEP 1019 | 1020 . - Remote MEP List 1021 . 1022 | 1023 --- MEP-A 1024 | 1025 --- MEP-B 1026 . 1028 | 1029 . - Flow Entropy List {Augments IEEE8021-CFM-MIB} 1031 | 1032 --- (Flow Entropy-1) {note we have to define 1033 | destination nickname with 1034 --- (Flow-entropy-2) the flow entropy discuss} 1035 | 1036 . ---(Flow Entropy n) 1037 | 1038 . - CCM 1039 | 1040 --- (standard 8021ag entries) 1041 | 1042 --- (hop-count) { Augments IEEE8021-CFM-MIB} 1043 | 1044 --- (Other TBD TRILL OAM specific entries) 1045 {Augmented} 1046 | 1047 . 1048 | 1049 - Other MIB entries 1050 Figure 10Augmentation of CCM MIB in TRILL 1052 In a multi-pathing environment, a Flow - by definition - is 1053 unidirectional. A question may arise as to what flow entropy should 1054 be used in the response. CCMs are unidirectional and have no explicit 1055 reply; as such, the issue of the response flow entropy does not 1056 arise. In the transmitted CCM, each MEP reports local status using 1057 the Remote Defect Indication (RDI) flag. Additionally, a MEP may 1058 raise SNMP TRAPs [TRILLOAMMIB] as Alarms when a connectivity failure 1059 occurs. 1061 9. TRILL OAM Message Channel 1063 The TRILL OAM Message Channel can be divided into two parts: TRILL 1064 OAM Message header and TRILL OAM Message TLVs. Every OAM Message MUST 1065 contain a single TRILL OAM message header and a set of one or more 1066 specified OAM Message TLVs. 1068 9.1. TRILL OAM Message header 1070 As discussed earlier, a common messaging framework between [8021Q], 1071 TRILL, and other similar standards such as Y.1731 can be accomplished 1072 by re-using the OAM message header defined in [8021Q]. 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 |MD-L | Version | OpCode | Flags |FirstTLVOffset | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | | 1078 . Opcode Specific Information . 1079 | | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | | 1082 . TLVs . 1083 | | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Figure 11OAM Message Format 1088 o MD-L: Maintenance Domain Level (3 bits). Identifies the 1089 maintenance domain level. For TRILL, in general, this field is 1090 set to zero. However, extension of TRILL, for example to support 1091 multilevel, may create different MD-LEVELs and MD-L field must 1092 be appropriately set in those scenarios. (Please refer to 1093 [8021Q] for the definition of MD-Level) 1095 o Version: Indicates the version (5 bits). As specified in 1096 [8021Q]. This document does not propose to change the Version 1097 defined in [8021Q]. 1099 o Flags: Includes operational flags (1 byte). The definition of 1100 flags is Opcode-specific and is covered in the applicable 1101 sections. 1103 o FirstTLVOffset: Defines the location of the first TLV, in 1104 bytes, starting from the end of the FirstTLVOffset field (1 1105 byte). (Refer to [8021Q] for the definition of the 1106 FirstTLVOffset.) 1108 MD-L, Version, Opcode, Flags and FirstTLVOffset fields collectively 1109 are referred to as the OAM Message Header. 1111 The Opcode specific information section of the OAM Message may 1112 contain Session Identification number, time-stamp, etc. 1114 9.2. TRILL OAM Opcodes 1116 The following Opcodes are defined for TRILL. Each of the Opcodes 1117 indicates a separate type of TRILL OAM message. Details of the 1118 messages are presented in the related sections. 1120 TRILL OAM Message Opcodes: 1122 TBD-64 : Path Trace Reply 1123 TBD-65 : Path Trace Message 1124 TBD-66 : Multicast Tree Verification Reply 1125 TBD-67 : Multicast Tree Verification Message 1127 9.3. Format of TRILL OAM TLV 1129 The same TLV format as defined in section 21.5.1 of [8021Q] is used 1130 for TRILL OAM. The following figure depicts the general format of a 1131 TRILL OAM TLV: 1133 0 1 2 1134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Type | Length | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | | 1139 . Value(variable) . 1140 | | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 Figure 12 TRILL OAM TLV 1145 Type (1 octet) : Specifies the Type of the TLV (see sections 9.4. 1146 for TLV types). 1148 Length (2 octets) : Specifies the length of the 'Value' field in 1149 octets. Length of the 'Value' field can be either zero or more 1150 octets. 1152 Value (variable): The length and the content of this field depend on 1153 the type of the TLV. Please refer to applicable TLV definitions for 1154 the details. 1156 Semantics and usage of Type values allocated for TRILL OAM purpose 1157 are defined by this document and other future related documents. 1159 9.4. TRILL OAM TLVs 1161 TRILL related TLVs are defined in this section. [8021Q] defined TLVs 1162 are reused, where applicable. Types 32-63 are reserved for ITU-T 1163 Y.1731. We propose to reserve Types 64-95 for TRILL OAM TLVs. 1165 9.4.1. Common TLVs between 802.1ag and TRILL 1167 The following TLVs are defined in [8021Q]. We propose to re-use them 1168 where applicable. The format and semantics of the TLVs are as defined 1169 in [8021Q]. 1171 Type Name of TLV in [8021Q] 1172 ---- ------------- 1173 0 End TLV 1174 1 Sender ID TLV 1175 2 Port Status TLV 1176 3 Data TLV 1177 4 Interface Status TLV 1178 5 Reply Ingress TLV 1179 6 Reply Egress TLV 1180 7 LTM Egress Identifier TLV 1181 8 LTR Egress Identifier TLV 1182 9-30 Reserved 1183 31 Organization Specific TLV 1185 9.4.2. TRILL OAM Specific TLVs 1187 As indicated above, Types 64-95 will be requested to be reserved for 1188 TRILL OAM purposes. Listed below is a summary of TRILL OAM TLVs and 1189 their corresponding codes. Format and semantics of TRILL OAM TLVs are 1190 defined in subsequent sections. 1192 Type TLV Name 1193 ----------- ---------------------- 1194 TBD-TLV-64 TRILL OAM Application Identifier 1195 TBD-TLV-65 Out of Band IP Address 1196 TBD-TLV-66 Diagnostic VLAN 1197 TBD-TLV-67 RBridge Scope 1198 TBD-TLV-68 Original Payload 1199 TBD-TLV-69 Previous RBridge Nickname 1200 TBD-TLV-70 RILL Next Hop RBridge List (ECMP) 1201 TBD-TLV-71 Multicast Receiver Availability 1202 TBD-TLV-72 Flow Identifier 1203 TBD-TLV-73 to TBD-TLV-95 Reserved 1205 9.4.3. TRILL OAM Application Identifier TLV 1207 TRILL OAM Application Identifier TLV carries TRILL OAM application 1208 specific information. The TRILL OAM Application Identifier TLV MUST 1209 always be present and MUST be the first TLV in TRILL OAM messages. 1210 Messages that do not include the TRILL OAM Application Identifier TLV 1211 as the first TLV MUST be discarded by an RBridge, unless that RBridge 1212 is also running Ethernet CFM. 1214 1 2 3 1215 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 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Type | Length | Version | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Return Code |Return sub-code| Reserved |F|C|O|I| 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 Figure 13TRILL OAM Message TLV 1224 Type (1 octet) = 64 indicate that this is the TRILL OAM Version 1226 Length (2 octets) = 6 1228 TRILL OAM Version (1 Octet), currently set to zero. Indicates the 1229 TRILL OAM version. TRILL OAM version can be different than the 1230 [8021Q] version. 1232 Return Code (1 Octet): Set to zero on requests. Set to an appropriate 1233 value in response messages. 1235 Return sub-code (1 Octet): Return sub-code is set to zero on 1236 transmission of request message. Return sub-code identifies 1237 categories within a specific Return code. Return sub-code MUST be 1238 interpreted within a Return code. 1240 Reserved: set to zero on transmission and ignored on reception. 1242 F (1 bit) : Final flag, when set, indicates this is the last 1243 response. 1245 C (1 bit ): Label error (VLAN/Label mapping error), if set indicates 1246 that the label (VLAN/FGL) in the flow entropy is different than the 1247 label included in the diagnostic TLV. This field is ignored in 1248 request messages and MUST only be interpreted in response messages. 1250 O (1 bit) : If set, indicates, OAM out-of-band response requested. 1252 I (1 bit) : If set, indicates, OAM in-band response requested. 1254 NOTE: When both O and I bits are set to zero, indicates that no 1255 response is required (silent mode). User MAY specify both O and I or 1256 one of them or none. When both O and I bits are set response is sent 1257 both in-band and out-of-band. 1259 9.4.4. Out Of Band Reply Address TLV 1261 Out of Band Reply Address TLV specifies the address to which an out 1262 of band OAM reply message MUST be sent. When O bit in the TRILL 1263 Version TLV is not set, Out of Band Reply Address TLV is ignored. 1265 1 2 3 1266 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 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Type | Length | Address Type | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Addr Length | | 1271 +-+-+-+-+-+-+-+-+ | 1272 | | 1273 . Reply Address . 1274 | | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 Figure 14Out of Band IP Address TLV 1279 Type (1 octet) = 64 1281 Length (2 octets) = Variable. Minimum length is 2. 1283 Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge 1284 nickname. All other values reserved. 1286 Addr Length (1 Octet). 4 - IPv4. 16 - IPv6, 2 - TRILL RBRidge 1287 nickname. 1289 Reply Address (variable): Address where the reply needed to be sent. 1290 Length depends on the address specification. 1292 9.4.5. Diagnostics Label TLV 1294 Diagnostic label specifies the data label (VLAN or FGL) in which the 1295 OAM messages are generated. Receiving RBridge MUST compare the data 1296 label of the Flow entropy to the data label specified in the 1297 Diagnostic Label TLV. Label Error Flag in the response (TRILL OAM 1298 Message Version TLV) MUST be set when the two VLANs do not match. 1300 1 2 3 1301 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 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Type | Length | L-Type | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Reserved | Label(VLAN) | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 Figure 15Diagnostic VLAN TLV 1310 Type (1 octet) = 65 indicates that this is the TRILL Diagnostic VLAN 1311 TLV 1313 Length (2 octets) = 5 1315 L-Type (Label type, 1 octet) 1317 0- indicate 802.1Q 12 bit VLAN. 1319 1 - indicate TRILL 24 bit fine grain label 1321 Label (24 bits): Either 12 bit VLAN or 24 bit fine grain label. 1323 RBridges do not perform Label error checking when Label TLV is not 1324 included in the OAM message. In certain deployments intermediate 1325 devices may perform label (VLAN) translation. In such scenarios, 1326 originator should not include the diagnostic Label TLV in OAM 1327 messages. Inclusion of diagnostic TLV will generate unwanted label 1328 error notifications. 1330 9.4.6. Original Data Payload TLV 1332 1 2 3 1333 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 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Type | Length | | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1337 | | 1338 . Original Payload . 1339 | | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Figure 16Original Data Payload TLV 1344 Length (2 octets) = variable 1346 9.4.7. RBridge scope TLV 1348 RBridge scope TLV identifies nicknames of RBridges from which a 1349 response is required. The RBridge scope TLV is only applicable to 1350 Multicast Tree Verification messages. This TLV SHOULD NOT be included 1351 in other messages. Receiving RBridges MUST ignore this TLV on 1352 messages other than Multicast Verification Message. 1354 Each TLV can contain up to 255 nicknames of in scope RBridges. A 1355 Multicast Verification Message may contain multiple "RBridge scope 1356 TLVs", in the event that more than 255 in scope RBridges need to be 1357 specified. 1359 Absence of the "RBridge scope TLV" indicates that a response is 1360 needed from all the RBridges. Please see section 12. for details. 1362 1 2 3 1363 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 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Type | Length | nOfnicknames | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | nickname-1 | nickname-2 | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 . . 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | | nickname-n | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 Figure 17RBridge Scope TLV 1376 Type (1 octet) = 67 indicates that this is the "RBridge scope TLV" 1378 Length (2 octets) = variable. Minimum value is 2. 1380 Nickname (2 octets) = 16 bit RBridge nickname. 1382 9.4.8. Previous RBridge nickname TLV 1384 "Previous RBridge nickname TLV" identifies the nickname or nicknames 1385 of the upstream RBridge. [RFC6325] allows a given RBridge to hold 1386 multiple nicknames. 1388 "Upstream RBridge nickname TLV" is an optional TLV. Multiple 1389 instances of this TLV MAY be included when an upstream RBridge is 1390 represented by more than 255 nicknames (highly unlikely). 1392 1 2 3 1393 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 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | Type | Length | Reserved | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | Reserved | nickname | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 Figure 18Upstream RBridge nickname TLV 1402 Type (1 octet) = 69 indicates that this is the "Upstream RBridge 1403 nickname" 1405 Length (2 octets) = 4. 1407 Nickname (2 octets) = 16 bit RBridge nickname. 1409 9.4.9. Next Hop RBridge List TLV 1411 "Next Hop RBridge List TLV" identifies the nickname or nicknames of 1412 the downstream next hop RBridges. [RFC6325] allows a given RBridge to 1413 have multiple Equal Cost Paths to a specified destination. Each next 1414 hop RBridge is represented by one of its nicknames. 1416 "Next Hop RBridge List TLV" is an optional TLV. Multiple instances of 1417 this TLV MAY be included when there are more than 255 Equal Cost 1418 Paths to the destination. 1420 1 2 3 1421 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 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | Type | Length | nOfnicknames | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | nickname-1 | nickname-2 | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 . . 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | | nickname-n | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Figure 19Next Hop RBridge List TLV 1434 Type (1 octet) = 70 indicates that this is the "Next nickname" 1436 Length (2 octets) = variable. Minimum value is 2. 1438 Nickname (2 octets) = 16 bit RBridge nickname. 1440 9.4.10. Multicast Receiver Port count TLV 1442 "Multicast Receiver Port Count TLV" identifies the number of ports 1443 interested in receiving the specified multicast stream within the 1444 responding RBridge on the VLAN specified by the Diagnostic VLAN TLV. 1446 Multicast Receiver Port count is an Optional TLV. 1448 1 2 3 1449 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 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Type | Length | Reserved | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | number of Receivers | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 Figure 20Multicast Receiver Availability TLV 1458 Type (1 octet) = 71 indicates that this is the "Multicast 1459 Availability TLV" 1461 Length (2 octets) = 5. 1463 Number of Receivers (4 octets) = Indicates the number of Multicast 1464 receivers available on the responding RBridge on the VLAN specified 1465 by the diagnostic VLAN. 1467 9.4.11. Flow Identifier (flow-id) TLV 1469 Flow Identifier (flow-id) uniquely identifies a specific flow. The 1470 flow-id value is unique per MEP and needs to be interpreted as such. 1472 1 2 3 1473 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 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 | Type | Length | Reserved | 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | MEP-ID | flow-id | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 Figure 21Out of Band IP Address TLV 1482 Type (1 octet) = 72 1484 Length (2 octets) = 5. 1486 Reserved (1 octet) set to 0 on transmission and ignored on reception. 1488 MEP-ID (2 octets) = MEP-ID of the originator [8021Q]. 1490 Flow-id (2 octets) = uniquely identifies the flow per MEP. Different 1491 MEPs may allocate the same flow-id value. The {MEP-ID, flow-id} pair 1492 is globally unique. 1494 Inclusion of the MEP-ID in the flow-id TLV allows inclusion of MEP-ID 1495 for messages that do not contain MEP-ID in OAM header. Applications 1496 may use MEP-ID information for different types of troubleshooting. 1498 10. Loopback Message 1500 10.1. Loopback OAM Message format 1502 1 2 3 1503 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 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 |MD-L | Version | OpCode | Flags |FirstTLVOffset | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Loopback Transaction Identifier | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | | 1510 . TLVs . 1511 | | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 Figure 22Loopback OAM Message Format 1516 The above figure depicts the format of the Loopback Request and 1517 response messages as defined in [8021Q]. The Opcode for Loopback 1518 Message is set to 65 and the Opcode for the Reply Message is set to 1519 64. The Session Identification Number is a 32-bit integer that allows 1520 the requesting RBridge to uniquely identify the corresponding 1521 session. Responding RBridges, without modification, MUST echo the 1522 received "Loopback Transaction Identifier" number.. 1524 10.2. Theory of Operation 1526 10.2.1. Originator RBridge 1528 Identifies the destination RBridge nickname based on user 1529 specification or based on the specified destination MAC or IP 1530 address. 1532 Constructs the flow entropy based on user specified parameters or 1533 implementation specific default parameters. 1535 Constructs the TRILL OAM header: sets the opcode to Loopback message 1536 type (3). Assign applicable Loopback Transaction Identifier number 1537 for the request. 1539 The TRILL OAM Version TLV MUST be included and with the flags set to 1540 applicable values. 1542 Include following OAM TLVs, where applicable 1544 o Out-of-band Reply address TLV 1546 o Diagnostic Label TLV 1548 o Sender ID TLV 1550 Specify the Hop count of the TRILL data frame per user specification 1551 or utilize an applicable Hop count value. 1553 Dispatch the OAM frame for transmission. 1555 RBridge may continue to retransmit the request at periodic intervals, 1556 until a response is received or the re-transmission count expires. At 1557 each transmission Session Identification number MUST be incremented. 1559 10.2.2. Intermediate RBridge 1561 Intermediate RBridges forward the frame as a normal data frame and no 1562 special handling is required. 1564 10.2.3. Destination RBridge 1566 If the Loopback message is addressed to the local RBridge and 1567 satisfies the OAM identification criteria specified in section 3.1. 1568 then, the RBridge data plane forwards the message to the CPU for 1569 further processing. 1571 The TRILL OAM application layer further validates the received OAM 1572 frame by checking for the presence of OAM-Ethertype at the end of the 1573 flow entropy and the MD Level. Frames that do not contain OAM- 1574 Ethertype at the end of the flow entropy MUST be discarded. 1576 Construction of the TRILL OAM response: 1578 TRILL OAM application encodes the received TRILL header and flow 1579 entropy in the Original payload TLV and includes it in the OAM 1580 message. 1582 Set the Return Code and Return sub code to applicable values. Update 1583 the TRILL OAM opcode to 2 (Loopback Message Reply) 1585 Optionally, if the VLAN/FGL identifier value of the received flow 1586 entropy differs from the value specified in the diagnostic Label, set 1587 the Label Error Flag on TRILL OAM Application Identifier TLV. 1589 Include the sender ID TLV (1) 1591 If in-band response was requested, dispatch the frame to the TRILL 1592 data plane with request-originator RBridge nickname as the egress 1593 RBridge nickname. 1595 If out-of-band response was requested, dispatch the frame to the IP 1596 forwarding process. 1598 11. Path Trace Message 1600 The primary use of the Path Trace Message is for fault isolation. It 1601 may also be used for plotting the path taken from a given RBridge to 1602 another RBridge. 1604 [8021Q] accomplishes the objectives of the TRILL Path Trace Message 1605 using Link Trace Messages. Link Trace Messages utilize a well-known 1606 multicast MAC address. This works for [8021Q], because for 802.1 both 1607 the unicast and multicast paths are congruent. However, TRILL is 1608 multicast and unicast incongruent. Hence, TRILL OAM is required to 1609 utilize a new message format: the Path Trace message. 1611 The Path Trace Message has the same format as Loopback Message. 1612 Opcode for Path Trace Reply Message is 65 and Request 64 1614 Operation of the Path Trace message is identical to the Loopback 1615 message except that it is first transmitted with a TRILL Hop count 1616 field value of 1. The sending RBridge expects a Time Expiry Return- 1617 Code from the next hop or a successful response. If a Time Expiry 1618 Return-code is received as the response, the originator RBridge 1619 records the information received from intermediate node that 1620 generated the Time Expiry message and resends the message by 1621 incrementing the previous Hop count value by 1. This process is 1622 continued until, a response is received from the destination RBridge 1623 or Path Trace process timeout occur or Hop count reaches a configured 1624 maximum value. 1626 11.1. Theory of Operation 1628 11.1.1. Originator RBridge 1630 Identify the destination RBridge based on user specification or based 1631 on location of the specified MAC address. 1633 Construct the flow entropy based on user specified parameters or 1634 implementation specific default parameters. 1636 Construct the TRILL OAM header: Set the opcode to Path Trace Request 1637 message type (65). Assign an applicable Session Identification number 1638 for the request. Return-code and sub-code MUST be set to zero. 1640 The TRILL OAM Application Identifier TLV MUST be included and set the 1641 flags to applicable values. 1643 Include following OAM TLVs, where applicable 1645 o Out-of-band IP address TLV 1647 o Diagnostic Label TLV 1649 o Include the Sender ID TLV 1651 Specify the Hop count of the TRILL data frame as 1 for the first 1652 request. 1654 Dispatch the OAM frame to the TRILL data plane for transmission. 1656 An RBridge may continue to retransmit the request at periodic 1657 intervals, until a response is received or the re-transmission count 1658 expires. At each new re-transmission, the Session Identification 1659 number MUST be incremented. Additionally, for responses received from 1660 intermediate RBridges, the RBridge nickname and interface information 1661 MUST be recorded. 1663 11.1.2. Intermediate RBridge 1665 Path Trace Messages transit through Intermediate RBridges 1666 transparently, unless Hop-count has expired. 1668 TRILL OAM application layer further validates the received OAM frame 1669 by examining the presence of TRILL OAM Flag and OAM-Ethertype at the 1670 end of the flow entropy and by examining the MD Level. Frames that do 1671 not contain OAM-Ethertype at the end of the flow entropy MUST be 1672 discarded. 1674 Construction of the TRILL OAM response: 1676 TRILL OAM application encodes the received TRILL header and flow 1677 entropy in the Original payload TLV and include it in the OAM 1678 message. 1680 Set the Return Code to (2) "Time Expired" and Return sub code to zero 1681 (0). Update the TRILL OAM opcode to 64 (Path Trace Message Reply). 1683 If the VLAN/FGL identifier value of the received flow entropy differs 1684 from the value specified in the diagnostic Label, set the Label Error 1685 Flag on TRILL OAM Application Identifier TLV. 1687 Include following TLVs 1689 Upstream RBridge nickname TLV (69) 1691 Reply Ingress TLV (5) 1693 Reply Egress TLV (6) 1695 Interface Status TLV (4) 1697 TRILL Next Hop RBridge (Repeat for each ECMP) (70) 1699 Sender ID TLV (1) 1701 If Label error detected, set C flag (Label error detected) in the 1702 version. 1704 If in-band response was requested, dispatch the frame to the TRILL 1705 data plane with request-originator RBRidge nickname as the egress 1706 RBridge nickname. 1708 If out-of-band response was requested, dispatch the frame to the 1709 standard IP forwarding process. 1711 11.1.3. Destination RBridge 1713 Processing is identical to section 11.1.2. With the exception that 1714 TRILL OAM Opcode is set to Path Trace Reply (64). 1716 12. Multi-Destination Tree Verification (MTV) Message 1718 Multi-Destination Tree Verification messages allow verifying TRILL 1719 distribution tree integrity and pruning. TRILL VLAN/FGL and multicast 1720 pruning are described in [RFC6325] [RFCclcorrect] and [RFCfgl]. 1722 Multi-destination tree verification and Multicast group verification 1723 messages are designed to detect pruning defects. Additionally, these 1724 tools can be used for plotting a given multicast tree within the 1725 TRILL campus. 1727 Multi-Destination tree verification OAM frames are copied to the CPU 1728 of every intermediate RBridge that is part of the distribution tree 1729 being verified. The originator of the Multi-destination Tree 1730 verification message specifies the scope of RBridges from which a 1731 response is required. Only the RBridges listed in the scope field 1732 respond to the request. Other RBridges silently discard the request. 1733 Inclusion of the scope parameter is required to prevent receiving an 1734 excessive number of responses. The typical scenario of distribution 1735 tree verification or group verification, involves verifying multicast 1736 connectivity to a selected set of end-nodes as opposed to the entire 1737 network. Availability of the scope facilitates narrowing down the 1738 focus to only the RBridges of interest. 1740 Implementations MAY choose to rate-limit CPU bound multicast traffic. 1741 As a result of rate-limiting or due to other congestion conditions, 1742 MTV messages may be discarded from time to time by the intermediate 1743 RBRidges and the requester may be required to retransmit the request. 1744 Implementations SHOULD narrow the embedded scope of retransmission 1745 request only to RBRidges that have failed to respond. 1747 12.1. Multi-Destination Tree Verification (MTV) OAM Message Format 1749 Format of MTV OAM Message format is identical to that of Loopback 1750 Message format defined in section 10. with the exception that the 1751 Loopback Transaction Identifier, in section 10.1. , is replaced with 1752 the Session Identifier. 1754 12.2. Theory of Operation 1756 12.2.1. Originator RBridge 1758 The user is required at a minimum to specify either the distribution 1759 trees that need to be verified, or the Multicast MAC address and 1760 VLAN/FGL, or VLAN/FGL and Multicast destination IP address. 1761 Alternatively, for more specific multicast flow verification, the 1762 user MAY specify more information e.g. source MAC address, VLAN/FGL, 1763 Destination and Source IP addresses. Implementations, at a minimum, 1764 must allow the user to specify a choice of distribution trees, 1765 Destination Multicast MAC address and VLAN/FGL that needed to be 1766 verified. Although, it is not mandatory, it is highly desired to 1767 provide an option to specify the scope. It should be noted that the 1768 source MAC address and some other parameters may not be specified if 1769 the Backwards Compatibility Method of section 3.2 is used to identify 1770 the OAM frames. 1772 Default parameters MUST be used for unspecified parameters. Flow 1773 entropy is constructed based on user specified parameters and/or 1774 default parameters. 1776 Based on user specified parameters, the originating RBridge 1777 identifies the nickname that represents the multicast tree. 1779 Obtain the applicable Hop count value for the selected multicast 1780 tree. 1782 Construct TRILL OAM message header and include Session Identification 1783 number. Session Identification number facilitate the originator to 1784 map the response to the correct request. 1786 TRILL OAM Application Identifier TLV MUST be included. 1788 Op-Code MUST be specified as Multicast Tree Verification Message (70) 1790 Include RBridge scope TLV (67) 1792 Optionally, include following TLV, where applicable 1794 o Out-of-band IP address 1796 o Diagnostic Label 1798 o Sender ID TLV (1) 1800 Specify the Hop count of the TRILL data frame per user specification 1801 or alternatively utilize the applicable Hop count value if TRILL Hop 1802 count is not being specified by the user. 1804 Dispatch the OAM frame to the TRILL data plane to be ingressed for 1805 transmission. 1807 The RBridge may continue to retransmit the request at a periodic 1808 interval until either a response is received or the re-transmission 1809 count expires. At each new re-transmission, the Session 1810 Identification number MUST be incremented. At each re-transmission, 1811 the RBridge may further reduce the scope to the RBridges that it has 1812 not received a response from. 1814 12.2.2. Receiving RBridge 1816 Receiving RBridges identify multicast verification frames per the 1817 procedure explained in sections 3.2. 1819 CPU of the RBridge validates the frame and analyzes the scope RBridge 1820 list. If the RBridge scope TLV is present and the local RBridge 1821 nickname is not specified in the scope list, it will silently discard 1822 the frame. If the local RBridge is specified in the scope list OR 1823 RBridge scope TLV is absent, the receiving RBridge proceeds with 1824 further processing as defined in section 12.2.3. 1826 12.2.3. In scope RBridges 1828 Construction of the TRILL OAM response: 1830 TRILL OAM application encodes the received TRILL header and flow 1831 entropy in the Original payload TLV and includes them in the OAM 1832 message. 1834 Set the Return Code to (0) and Return sub code to zero (0). Update 1835 the TRILL OAM opcode to 66 (Multicast Tree Verification Reply). 1837 Include following TLVs: 1839 Upstream RBridge nickname TLV (69) 1841 Reply Ingress TLV (5) 1843 Interface Status TLV (4) 1845 TRILL Next Hop RBridge (Repeat for each downstream RBridge) (70) 1847 Sender ID TLV (1) 1849 Multicast Receiver Availability TLV (71) 1851 If VLAN cross connect error detected, set C flag (Cross connect error 1852 detected) in the version. 1854 If in-band response was requested, dispatch the frame to the TRILL 1855 data plane with request-originator RBridge nickname as the egress 1856 RBridge nickname. 1858 If out-of-band response was requested, dispatch the frame to the 1859 standard IP forwarding process. 1861 13. Application of Continuity Check Message (CCM) in TRILL 1863 Section 8. provides an overview of CCM Messages defined in [8021Q] 1864 and how they can be used within the TRILL OAM. This section, 1865 presents the application and Theory of Operations of CCM within the 1866 TRILL OAM framework. Readers are referred to [8021Q] for CCM message 1867 format and applicable TLV definitions and usages. Only the TRILL 1868 specific aspects are explained below. 1870 In TRILL, between any two given MEPs there can be multiple potential 1871 paths. Whereas in [8021Q], there is always a single path between any 1872 two MEPs at any given time. [RFC6905] requires solutions to have the 1873 ability to monitor continuity over one or more paths. 1875 CCM Messages are uni-directional, such that there is no explicit 1876 response to a received CCM message. Connectivity status is indicated 1877 by setting the applicable flags (e.g. RDI) of the CCM messages 1878 transmitted by an MEP. 1880 It is important that the proposed solution accomplishes the 1881 requirements specified in [RFC6905] within the framework of [8021Q] 1882 in a straightforward manner and with minimum changes. Section 8, 1883 above proposed to define multiple flows within the CCM object, each 1884 corresponding to a flow that a given MEP wishes to monitor. 1886 Receiving MEPs do not cross check whether a received CCM belongs to a 1887 specific flow from the originating RBridge. Any attempt to track 1888 status of individual flows may explode the amount of state 1889 information that any given RBridge has to maintain. 1891 The obvious question arises: How does the originating RBridge know 1892 which flow or flows are at fault? 1894 13.1. CCM Error Notification 1896 This is accomplished with a combination of the RDI flag in the CCM 1897 header, flow-id TLV, and SNMP Notifications (Traps). 1899 Each MEP transmits 4 CCM messages per each flow. ([8021Q] detects CCM 1900 fault when 3 consecutive CCM messages are lost). Each CCM Message has 1901 a unique sequence number and unique flow-identifier. The flow 1902 identifier is included in the OAM message via flow-id TLV. 1904 When an MEP notices a CCM timeout from a remote MEP ( MEP-A), it sets 1905 the RDI flag on the next CCM message it generates. Additionally, it 1906 logs and sends SNMP notification that contain the remote MEP 1907 Identification, flow-id and the Sequence Number of the last CCM 1908 message it received and if available, the flow-id and the Sequence 1909 Number of the first CCM message it received after the failure. Each 1910 MEP maintains a unique flow-id per each flow, hence the operator can 1911 easily identify flows that correspond to the specific flow-id. 1913 The following example illustrates the above. 1915 Assume there are two MEPs, MEP-A and MEP-B. 1917 Assume there are 3 flows between MEP-A and MEP-B. 1919 Let,s assume MEP-A allocates sequence numbers as follows 1921 Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-id=(1) 1923 Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-id=(2) 1925 Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-id=(3) 1927 Let's Assume Flow-2 is at fault. 1929 MEP-B, receives CCM from MEP-A with sequence numbers 1,2,3,4, but did 1930 not receive 5,6,7,8. CCM timeout is set to 3 CCM intervals in 1931 [8021Q]. Hence MEP-B detects the error at the 8'th CCM message. At 1932 this time the sequence number of the last good CCM message MEP-B has 1933 received from MEP-A is 4 and flow-id of the last good CCM Message is 1934 (1). Hence MEP-B will generate a CCM error SNMP notification with 1935 MEP-A and Last good flow-id (1) and sequence number 4. 1937 When MEP-A switches to flow-3 after transmitting flow-2, MEP-B will 1938 start receiving CCM messages. In the foregoing example it will be CCM 1939 message with Sequence Numbers 9,10,11,12,21 and so on. When in 1940 receipt of a new CCM message from a specific MEP, after a CCM 1941 timeout, the TRILL OAM will generate an SNMP Notification of CCM 1942 resume with remote MEP-ID and the first valid flow-id and the 1943 Sequence number after the CCM timeout. In the foregoing example, it 1944 is MEP-A, flow-id (1) and Sequence Number 9. 1946 The remote MEP list under the CCM MIB Object is augmented to contain 1947 "Last Sequence Number", flow-id and "CCM Timeout" variables. Last 1948 Sequence Number and flow-id are updated every time a CCM is received 1949 from a remote MEP. CCM Timeout variable is set when the CCM timeout 1950 occurs and is cleared when a CCM is received. 1952 13.2. Theory of Operation 1954 13.2.1. Originator RBridge 1956 Derive the flow entropy based on flow entropy specified in the CCM 1957 Management object. 1959 Construct the TRILL CCM OAM header as specified in [8021Q]. 1961 TRILL OAM Version TLV MUST be included as the first TLV and set the 1962 flags to applicable values. 1964 Include other TLVs specified in [8021Q] 1966 Include the following optional TRILL OAM TLVs, where applicable 1968 o Sender ID TLV 1970 Specify the Hop count of the TRILL data frame per user specification 1971 or utilize an applicable Hop count value. 1973 Dispatch the OAM frame to the TRILL data plane for transmission. 1975 An RBridge transmits a total of 4 requests, each at CCM 1976 retransmission interval. At each transmission the Session 1977 Identification number MUST be incremented by one. 1979 At the 5'th retransmission interval, flow entropy of the CCM packet 1980 is updated to the next flow entropy specified in the CCM Management 1981 Object. If current flow entropy is the last flow entropy specified, 1982 move to the first flow entropy specified and continue the process. 1984 13.2.2. Intermediate RBridge 1986 Intermediate RBridges forward the frame as a normal data frame and no 1987 special handling is required. 1989 13.2.3. Destination RBridge 1991 If the CCM Message is addressed to the local RBridge or multicast and 1992 satisfies OAM identification methods specified in sections 3.2. then 1993 the RBridge data plane forwards the message to the CPU for further 1994 processing. 1996 The TRILL OAM application layer further validates the received OAM 1997 frame by examining the presence of OAM-Ethertype at the end of the 1998 flow entropy. Frames that do not contain OAM-Ethertype at the end of 1999 the flow entropy MUST be discarded. 2001 Validate the MD-LEVEL and pass the packet to the Opcode de- 2002 multiplexer. The Opcode de-multiplexer delivers CCM packets to the 2003 CCM process. 2005 The CCM Process performs processing specified in [8021Q]. 2007 Additionally the CCM process updates the CCM Management Object with 2008 the sequence number of the received CCM packet. Note: The last 2009 received CCM sequence number and CCM timeout are tracked per each 2010 remote MEP. 2012 If the CCM timeout is true for the sending remote MEP, then clear the 2013 CCM timeout in the CCM Management object and generate the SNMP 2014 notification as specified above. 2016 14. Fragmented Reply 2018 The response Message allow Fragmented Replies.. In case of Fragmented 2019 Replies, all messages MUST follow the procedure defined in this 2020 section. 2022 All Reply Messages MUST be encoded as described in this document. 2024 The same session Identification Number MUST be included in all 2025 related fragments of the same message. 2027 The TRILL OAM Application Identifier TLV MUST be included with the 2028 appropriate Final Flag field. The Final Flag, MUST, only be set on 2029 the final fragment of the reply. 2031 15. Security Considerations 2033 For general TRILL related security considerations, please refer to 2034 [RFC6325]. Specific security considerations related methods presented 2035 in this document are currently under investigation. 2037 16. IEEE Allocation Considerations 2039 The IEEE 802.1 Working Group is requested to allocate a separate 2040 opcode and TLV space within 802.1QCFM messages for TRILL purpose. 2042 17. IANA Considerations 2044 - IANA is requested to allocate a multicast MAC address from the 2045 block assigned to TRILL [RFC6325]. 2047 - Set up sub-registry within the TRILL Parameters registry for block 2048 of TRILL "OAM OpCodes" (Section 9.2. )- 2050 - Set up sub-registry within the TRILL Parameters registry for TRILL 2051 "OAM TLV Types" (Section 9.4. )- 2053 - Request a unicast MAC addressed, reserved for identification of 2054 OAM packets discussed in backward compatibility method (Section 3.3. 2055 ) See Appendix A. 2057 18. References 2059 18.1. Normative References 2061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2062 Requirement Levels", BCP 14, RFC 2119, March 1997. 2064 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 2065 Protocol Specification", RFC 6325, July 2011. 2067 [RFCfgl] D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 2068 "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine- 2069 labeling, work in progress. 2071 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged 2072 Local Area Networks", IEEE Std 802.1Q-2011, August, 2011. 2074 18.2. Informative References 2076 [RFC4379] Kompella, K. et.al, "Detecting Multi-Protocol Label 2077 Switched (MPLS) Data Plane Failures", RFC 4379, February 2078 2006. 2080 [RFC6291] Andersson, L., et.al., "Guidelines f