idnits 2.17.00 (12 Aug 2021) /tmp/idnits28140/draft-ietf-trill-oam-fm-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2014) is 2759 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) -- Looks like a reference, but probably isn't: '2' on line 2257 -- Looks like a reference, but probably isn't: '3' on line 2259 -- Looks like a reference, but probably isn't: '64' on line 2284 -- Looks like a reference, but probably isn't: '65' on line 2286 -- Looks like a reference, but probably isn't: '66' on line 2287 -- Looks like a reference, but probably isn't: '67' on line 2288 -- Looks like a reference, but probably isn't: '68' on line 2289 -- Looks like a reference, but probably isn't: '69' on line 2290 -- Looks like a reference, but probably isn't: '70' on line 2292 -- Looks like a reference, but probably isn't: '71' on line 2294 -- Looks like a reference, but probably isn't: '72' on line 2296 -- Looks like a reference, but probably isn't: '73' on line 2297 -- Looks like a reference, but probably isn't: '74' on line 2298 == Missing Reference: '00-00-5E-90-01-00' is mentioned on line 2538, but not defined == Missing Reference: '01-5E-90-01-00' is mentioned on line 2307, but not defined == Missing Reference: '01-00-5E-90-01-01' is mentioned on line 2539, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. '8021Q' -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 7180 (Obsoleted by RFC 7780) -- No information found for draft-karp-isis-analysis - is the name correct? Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 20 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 Updates: 6325 Deepak Kumar 5 CISCO 7 Donald Eastlake 8 Sam Aldrin 9 Yizhou Li 10 Huawei 12 October 24, 2014 13 Expires: April 2015 15 TRILL Fault Management 16 draft-ietf-trill-oam-fm-11.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 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work 32 in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on April 24, 2009. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided 55 without warranty as described in the Simplified BSD License. 57 Abstract 59 This document specifies TRILL OAM Fault Management. Methods in 60 this document follow the IEEE 802.1 CFM (Continuity Fault 61 Management) framework and reuse OAM tools where possible. 62 Additional messages and TLVs are defined for TRILL specific 63 applications or where a different set of information is required 64 other than IEEE 802.1 CFM. This document updates RFC 6325. 66 Table of Contents 68 1. Introduction ............................................... 4 69 2. Conventions used in this document .......................... 4 70 3. General Format of TRILL OAM Packets ........................ 5 71 3.1. Identification of TRILL OAM frames .................... 7 72 3.2. Use of TRILL OAM Alert Flag ........................... 7 73 3.2.1. Handling of TRILL frames with the "A" Flag ....... 8 74 3.3. OAM Capability Announcement ........................... 8 75 3.4. Identification of the OAM message .................... 10 76 4. TRILL OAM Layering vs. IEEE Layering ...................... 10 77 4.1. Processing at ISS Layer .............................. 12 78 4.1.1. Receive Processing .............................. 12 79 4.1.2. Transmit Processing ............................. 12 80 4.2. End Station VLAN and Priority Processing ............. 12 81 4.2.1. Receive Processing .............................. 12 82 4.2.2. Transmit Procession ............................. 12 83 4.3. TRILL Encapsulation and De-capsulation Layer ......... 12 84 4.3.1. Receive Processing for Unicast packets .......... 12 85 4.3.2. Transmit Processing for unicast packets ......... 13 86 4.3.3. Receive Processing for Multicast packets ........ 14 87 4.3.4. Transmit Processing of Multicast packets ........ 15 88 4.4. TRILL OAM Layer Processing ........................... 16 89 5. Maintenance Associations (MA) in TRILL .................... 17 90 6. MEP Addressing ............................................ 18 91 6.1. Use of MIP in TRILL .................................. 21 92 7. Continuity Check Message (CCM) ............................ 23 93 8. TRILL OAM Message Channel ................................. 25 94 8.1. TRILL OAM Message header ............................. 25 95 8.2. TRILL Specific OAM Opcodes ........................... 26 96 8.3. Format of TRILL OAM TLV .............................. 26 97 8.4. TRILL OAM TLVs ....................................... 27 98 8.4.1. Common TLVs between CFM and TRILL ............... 27 99 8.4.2. TRILL OAM Specific TLVs ......................... 28 100 8.4.3. TRILL OAM Application Identifier TLV ............ 28 101 8.4.4. Out Of Band Reply Address TLV ................... 30 102 8.4.5. Diagnostics Label TLV ........................... 31 103 8.4.6. Original Data Payload TLV ....................... 32 104 8.4.7. RBridge scope TLV ............................... 32 105 8.4.8. Previous RBridge nickname TLV ................... 33 106 8.4.9. Next Hop RBridge List TLV ....................... 34 107 8.4.10. Multicast Receiver Port count TLV .............. 35 108 8.4.11. Flow Identifier (flow-id) TLV .................. 35 109 8.4.12. Reflector Entropy TLV .......................... 36 110 8.4.13. Authentication TLV ............................. 37 111 9. Loopback Message .......................................... 39 112 9.1. Loopback OAM Message format .......................... 39 113 9.2. Theory of Operation .................................. 39 114 9.2.1. Actions by Originator RBridge ................... 39 115 9.2.2. Intermediate RBridge ............................ 40 116 9.2.3. Destination RBridge ............................. 40 117 10. Path Trace Message ....................................... 41 118 10.1. Theory of Operation ................................. 42 119 10.1.1. Action by Originator RBridge ................... 42 120 10.1.2. Intermediate RBridge ........................... 42 121 10.1.3. Destination RBridge ............................ 44 122 11. Multi-Destination Tree Verification Message (MTVM) ....... 44 123 11.1. Multi-Destination Tree Verification Message (MTVM) 124 Format .................................................... 44 125 11.2. Theory of Operation ................................. 45 126 11.2.1. Actions by Originator RBridge .................. 45 127 11.2.2. Receiving RBridge .............................. 46 128 11.2.3. In scope RBridges .............................. 46 129 12. Application of Continuity Check Message (CCM) in TRILL ... 47 130 12.1. CCM Error Notification .............................. 48 131 12.2. Theory of Operation ................................. 49 132 12.2.1. Actions by Originator RBridge .................. 49 133 12.2.2. Intermediate RBridge ........................... 50 134 12.2.3. Destination RBridge ............................ 50 135 13. Fragmented Reply ......................................... 51 136 14. Security Considerations .................................. 51 137 15. IANA Considerations ...................................... 53 138 15.1. OAM Capabilitiy Flags ............................... 53 139 15.2. CFM Code Points ..................................... 53 140 15.3. MAC Addresses ....................................... 54 141 15.4. Return codes and sub codes .......................... 54 142 15.5. TRILL RBridge Nickname Address Family ............... 55 143 16. References ............................................... 55 144 16.1. Normative References ................................ 55 145 16.2. Informative References .............................. 56 146 17. Acknowledgments .......................................... 57 147 Appendix A. Backwards Compatibility .......................... 58 148 Appendix B. Base Mode for TRILL OAM .......................... 61 149 Appendix C. MAC Addresses Request ............................ 63 151 1. Introduction 153 The general structure of TRILL OAM messages is presented in 154 [RFC7174]. TRILL OAM messages consist of five parts: link header, 155 TRILL header, flow entropy, OAM message channel, and link 156 trailer. 158 The OAM message channel carries various control information and 159 OAM related data between TRILL switches, also known as RBridges 160 or Routing Bridges. 162 A common OAM message channel representation can be shared between 163 different technologies. This consistency between different OAM 164 technologies promotes nested fault monitoring and isolation 165 between technologies that share the same OAM framework. 167 The TRILL OAM message channel is formatted as specified in IEEE 168 Connectivity Fault Management (CFM) [8021Q]. 170 The ITU-T Y.1731 [Y1731] standard utilizes the same messaging 171 format as [8021Q] OAM messages where applicable. This document 172 takes a similar stance and reuses [8021Q] in TRILL OAM. It is 173 assumed readers are familiar with [8021Q] and [Y1731]. Readers 174 who are not familiar with these documents are encouraged to 175 review them. 177 This document updates [RFC6325] as specified in Section 3.1. 179 2. Conventions used in this document 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 182 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in 184 RFC-2119 [RFC2119]. 186 Capitalized IANA Considerations terms such as "Standards Action" 187 are to be interpreted as described in [RFC5226]. 189 Acronyms used in the document include the following: 191 CCM - Continuity Check Message [8021Q] 193 ECMP - Equal Cost Multipath 195 ISS - Internal Sub Layer Service [8021Q] 197 LBM - Loop Back Message [8021Q] 199 LBR - Loop Back Reply Message [8021Q] 201 MP - Maintenance Point [RFC7174] 203 MEP - Maintenance End Point [RFC7174] [8021Q] 205 MIP - Maintenance Intermediate Point [RFC7174] [8021Q] 207 MA - Maintenance Association [8021Q] [RFC7174] 209 MD - Maintenance Domain [8021Q] 211 MTVM - Multi-destination Tree Verification Message 213 MTVR - Multi-destination Tree Verification Reply Message 215 OAM - Operations, Administration, and Maintenance [RFC6291] 217 PRI - Priority of Ethernet Frames [8021Q] 219 PTM - Path Trace Message 221 PTR - Path Trace Reply Message 223 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 225 SAP - Service Access Point [8021Q] 227 3. General Format of TRILL OAM Packets 228 The TRILL forwarding paradigm allows an implementation to select 229 a path from a set of equal cost paths to forward a unicast TRILL 230 Data packet. For multi-destination TRILL Data packets, a 231 distribution tree is chosen by the TRILL switch that ingresses or 232 creates the packet. Selection of the path of choice is 233 implementation dependent at each hop for unicast and at the 234 ingress for multi-destination. However, it is a common practice 235 to utilize Layer 2 through Layer 4 information in the frame 236 payload for path selection. 238 For accurate monitoring and/or diagnostics, OAM Messages are 239 required to follow the same path as corresponding data packets. 240 [RFC7174] presents the high-level format of the OAM messages. The 241 details of the TRILL OAM frame format are defined in this 242 document. 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 . Link Header . (variable) 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 + TRILL Header + 6 or more bytes 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | | 254 . Flow Entropy . 96 bytes 255 . . 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | OAM Ethertype | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 . OAM Message Channel . Variable 262 . . 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Link Trailer | Variable 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 1 Format of TRILL OAM Messages 270 Link Header: Media-dependent header. For Ethernet, this includes 271 Destination MAC, Source MAC, VLAN (optional) and Ethertype 272 fields. 274 TRILL Header: Fixed size of 6 bytes when the Extended Header is 275 not included [RFC6325] 277 Flow Entropy: This is a 96-byte fixed size field. The rightmost 278 bits of the field MUST be padded with zeros, up to 96 bytes, when 279 the flow entropy is less than 96 bytes. Flow entropy enables 280 emulation of the forwarding behavior of the desired data packets. 281 The Flow Entropy field starts with the Inner.MacDA. The offset of 282 the Inner.MacDA depends on whether extensions are included or not 283 as specified in [RFC7179] and [RFC6325]. Such extensions are not 284 commonly supported in current TRILL implementations. 286 OAM Ethertype: OAM Ethertype is 16-bit Ethertype that identifies 287 the OAM Message channel that follows. This document specifies 288 using the Ethertype 0x8902 allocated for CFM [8021Q]. OAM Message 289 Channel: This is a variable size section that carries OAM related 290 information. The message format is as specified in [8021Q]. 292 Link Trailer: Media-dependent trailer. For Ethernet, this is the 293 FCS (Frame Check Sequence). 295 3.1. Identification of TRILL OAM frames 297 TRILL, as originally specified in [RFC6325], did not have a 298 specific flag or a method to identify OAM frames. This document 299 updates [RFC6325] to include specific methods to identify TRILL 300 OAM frames. Section 3.2. below explains the details of the 301 method. 303 3.2. Use of TRILL OAM Alert Flag 305 The TRILL Header, as defined in [RFC6325], has two reserved bits. 306 This document specifies use of the reserved bit next to Version 307 field in the TRILL header as the Alert flag. Alert flag will be 308 denoted by "A". RBridges MUST NOT use the "A" flag for forwarding 309 decisions such as the selection of which ECMP path or multi- 310 destination tree to select. 312 Implementations that comply with this document MUST utilize "A" 313 flag and CFM Ethertype to identify TRILL OAM frames. 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | V |A|R|M|Op-Length| Hop Count | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Egress RBridge Nickname | Ingress RBridge Nickname | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Options... 321 +-+-+-+-+-+-+-+-+-+-+-+- 323 Figure 2 TRILL Header with the "A" Flag 325 A (1 bit) - Indicates this is a possible OAM frame and is subject 326 to specific handling as specified in this document. 328 All other TRILL Header fields carry the same meaning as defined 329 in RFC6325. 331 3.2.1. Handling of TRILL frames with the "A" Flag 333 Value "1" in the A flag indicates TRILL frames that may qualify 334 as OAM frames. Implementations are further REQUIRED to validate 335 such frames by comparing the value at the OAM Ethertype (Figure 336 1) location with the CFM Ethertype "0x8902" [8021Q]. If the value 337 matches, such frames are identified as TRILL OAM frames and 338 SHOULD be processed as discussed in Section 4. 340 Frames with the "A" flag set that do not contain CFM Ethertype 341 are not considered as OAM frames. Such frames MUST be silently 342 discarded. 344 OAM capable RBridges MUST NOT generate OAM frames to an RBridge 345 that is not OAM capable. 347 Intermediate RBridges, that are not OAM capable (i.e. do not 348 understand the "A" flag) follow the process defined in [RFC6325] 349 section 3.3 and forward OAM frames with "A" flag unaltered. 351 3.3. OAM Capability Announcement 353 Any given RBridge can be (1) OAM incapable or (2) OAM capable 354 with new extensions or (3) OAM capable with backwards-compatible 355 method. The OAM request originator, prior to origination of the 356 request is required to identify the OAM capability of the target 357 and generate the appropriate OAM message. 359 Capability flags defined in TRILL version sub-TLV (TRILL-VER) 360 [RFC7176] will be utilized for announcing OAM capabilities. The 361 following OAM related capability flags are defined: 363 O - OAM Capable 365 B - Backwards Compatible OAM 367 A capability announcement, with "O" Flag set to 1 and "B" flag 368 set to 1, indicates that the originating RBridge is OAM capable 369 but utilizes the backwards compatible method defined in Appendix 370 A. A capability announcement with "O" Flag set to 1 and "B" flag 371 set to 0, indicates that the originating RBridge is OAM capable 372 and utilizes the method specified in section 3.2. 374 When "O" Flag is set to 0, the announcing implementation is 375 considered not capable of OAM and the "B" flag is ignored. 377 +-+-+-+-+-+-+-+-+ 378 | Type | (1 byte) 379 +-+-+-+-+-+-+-+-+ 380 | Length | (1 byte) 381 +-+-+-+-+-+-+-+-+ 382 | Max-version | (1 byte) 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ 384 |A|F|O|B|Other Capabilities and Header Flags| (4 bytes) 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+ 386 0 1 3 387 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 389 Figure 3 TRILL-VER sub-TLV [RFC7176] with O and B flags 391 Capability flags "A" and "F" are defined by [RFC7176] and 392 [RFC7172]. "O" and "B" Flags are located after "F" flag in the 393 Capability and Header Flags field of TRILL-VER sub-TLV, as 394 depicted in Figure 3 above. Usage of "O" and "B" flags are as 395 discussed above. 397 Absence of TRILL-VER sub-TLV means the announcing RBridge is not 398 OAM capable. 400 3.4. Identification of the OAM message 402 The ingress RBridge nickname allows recipients to identify the 403 origin of the message in most cases. However, when an out of band 404 reply is generated, the responding RBridge nickname is not easy 405 to identify. 407 The [8021Q] Sender ID TLV (1) provides methods to identify the 408 device by including the chassis ID. Chassis ID allows different 409 addressing formats such as IANA Address Family enumerations. IANA 410 has allocated Address Family Number 16396 for TRILL RBridge 411 nickname. In TRILL OAM the Chassis ID subtype of Sender ID TLV is 412 set to 16396 and Chassis ID field contains the corresponding 413 TRILL RBridge nickname. 415 When the Sender ID TLV is present and chassis sub type is set to 416 16396, the sender RBridge nickname SHOULD be derived from the 417 nickname embedded in the Chassis ID. Otherwise, sender RBridge 418 nickname SHOULD be derived from the ingress RBridge nickname. 420 4. TRILL OAM Layering vs. IEEE Layering 422 This section presents the placement of the TRILL OAM shim within 423 the IEEE 802.1 layers. The Transmit and Receive processing are 424 explained. 426 +-+-+-+-+-+-+-+-+-+-+ 427 | RBridge Layer | 428 | Processing | 429 +-+-+-+-+-+-+-+-+-+-+ 430 | 431 | 432 +-+-+-+-+-+-+ 433 | TRILL OAM | UP MEP 434 | Layer | MIP 435 +-+-+-+-+-+-+ Down MEP 436 | 437 | 438 +-+-+-+-+-+-+ 439 (3)--------> | TRILL | 440 | Encap/Decap 441 +-+-+-+-+-+-+ 442 | 443 +-+-+-+-+-+-+ 444 (2)--------> |End station| 445 | VLAN & priority Processing 446 +-+-+-+-+-+-+ 447 | 448 +-+-+-+-+-+-+ 449 (1)--------> |ISS | 450 |Processing | 451 +-+-+-+-+-+-+ 452 | 453 | 454 | 456 Figure 4 Placement of TRILL MP within IEEE 802.1 458 [RFC6325] Section 4.6 as updated by [RFC7180] provides a detailed 459 explanation of frame processing. Please refer to those documents 460 for additional details and for processing scenarios not covered 461 herein. 463 Sections 4.1 and 4.2 below apply to links using a broadcast LAN 464 technology such as Ethernet. 466 On links using an inherently point-to-point technology, such as 467 PPP [RFC6361], there is no Outer.MacDA, Outer.MacSA, or 468 Outer.VLAN because these are part of the link header for 469 Ethernet. Point-to-point links typically have link headers 470 without these fields. 472 4.1. Processing at ISS Layer 474 4.1.1. Receive Processing 476 The ISS Layer receives an indication from the port. It extracts 477 DA, SA and marks the remainder of the payload as M1. ISS Layer 478 passes on (DA, SA, M1) as an indication to the higher layer. 480 For TRILL Ethernet frames, this is Outer.MacDA and Outer.MacSA. 481 M1 is the remainder of the packet. 483 4.1.2. Transmit Processing 485 The ISS layer receives an indication from the higher layer that 486 contains (DA, SA, M1). It constructs an Ethernet frame and passes 487 down to the port. 489 4.2. End Station VLAN and Priority Processing 491 4.2.1. Receive Processing 493 Receives (DA, SA, M1) indication from ISS Layer. Extracts the 494 VLAN ID and priority from the M1 part of the received indication 495 (or derive them from the port defaults or other default 496 parameters) and constructs (DA, SA, VLAN, PRI, M2). VLAN+PRI+M2 497 map to M1 in the received indication. Pass (DA, SA, VLAN, PRI, 498 M2) to the TRILL encap/decap procession layer. 500 4.2.2. Transmit Procession 502 Receive (DA, SA, VLAN, PRI, M2) indication from TRILL encap/decap 503 processing layer. Merge VLAN, PRI, M2 to form M1. Pass down (DA, 504 SA, M1) to the ISS processing Layer. 506 4.3. TRILL Encapsulation and De-capsulation Layer 508 4.3.1. Receive Processing for Unicast packets 510 Receive indication (DA, SA, VLAN, PRI, M2) from End Station VLAN 511 and Priority Processing Layer. 513 o If DA matches port Local DA and Frame is of TRILL Ethertype 514 . Discard DA, SA, VLAN, PRI. From M2, derive (TRILL-HDR, iDA, 515 iSA, i-VL, M3) 517 . If TRILL nickname is Local and TRILL-OAM Flag is set 519 Pass on to OAM processing 521 . Else pass on (TRILL-HDR, iDA, iSA, i-VL, M3) to RBridge 522 Layer 524 o If DA matches port Local DA and EtherType is RBridge-Channel 525 [RFC7178] 527 . Process as a possible unicast native RBridge Channel packet 529 o If DA matches port Local DA and Ethertype is neither TRILL 530 nor RBridge-Channel 532 . Discard packet 534 o If DA does not match and port is Appointed Forwarder for VLAN 535 and Ethertype is not TRILL or RBridge-Channel 537 . Insert TRILL-Hdr and send (TRILL-HDR, iDA, iSA,i-VL, M3) 538 indication to RBridge Layer <- This is the TRILL Ingress 539 Function. 541 4.3.2. Transmit Processing for unicast packets 543 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from 544 RBridge Layer 546 o If egress TRILL nickname is local 548 o If port is Appointed Forwarder for iVL and the port is 549 not configured as a trunk or p2p port and (TRILL Alert 550 Flag set and OAM Ethertype present) then 552 . Strip TRILL-HDR and construct (DA, SA, VLAN, M2) 553 <- This is the TRILL Egress Function. 555 o Else 557 . Discard packet 559 o If egress TRILL nickname is not local 560 o Insert Outer.MacDA, Outer.MacSA, Outer.VLAN, TRILL 561 Ethertype and construct (DA, SA, VLAN, M2). Where M2 is 562 (TRILL-HDR, iDA, iSA, iVL, M) 564 o Forward (DA, SA, V, M2) to the VLAN End Station processing 565 Layer. 567 4.3.3. Receive Processing for Multicast packets 569 o Receive (DA, SA, V, M2) from VLAN aware end station 570 processing layer 572 o If the DA is All-RBridges and the Ethertype is TRILL 574 o Strip DA, SA and V. From M2, extract (TRILL-HDR, iDA, 575 iSA, iVL and M3). 577 o If TRILL Alert Flag is set and OAM Ethertype is present 578 at the end of Flow entropy 580 . Perform OAM Processing 582 o Else extract the TRILL header, inner MAC addresses and 583 inner VLAN and pass indication (TRILL-HDR, iDA, iSA, 584 iVL and M3) to TRILL RBridge Layer 586 o If the DA is All-IS-IS-RBridges and the Ethertype is L2-IS- 587 IS then pass frame up to TRILL IS-IS processing 589 o If the DA is All-RBridges or All-IS-IS-RBridges but 590 Ethertype is not TRILL or L2-IS-IS respectively 592 o Discard the packet 594 o If the Ethertype is TRILL but the multicast DA is not All- 595 RBridges; or if the Ethertype is L2-IS-IS but the multicast 596 DA is not All-IS-IS-RBridges 598 o Discard the packet 600 o If DA is All-Edge-RBridges and Ethertype is RBridge-Channel 601 [RFC7178] 603 o Process as a possible multicast native RBridge 604 Channel packet 606 o If the DA is in the initial bridging/link protocols block 607 (01-80-C2-00-00-00 to 01-80-C2-00-00-0F) or is in the TRILL 608 block and not assigned for Outer.MacDA use (01-80-C2-00-00- 609 42 to 01-80-C2-00-00-4F) then 611 o The frame is not propagated through an RBridge although 612 some special processing may be done at the port as 613 specified in [RFC6325] and the frame may be dispatched 614 to Layer 2 processing at the port if certain protocols 615 are supported by that port (examples: Link Aggregation 616 Protocol, Link Layer Discovery Protocol). 618 o If the DA is some other multicast value 620 o Insert TRILL-HDR and construct (TRILL-HDR, iDA, iSA, 621 IVL, M3) 623 o Pass the (TRILL-HDR, iDA, iSA, IVL, M3) to RBridge Layer 625 4.3.4. Transmit Processing of Multicast packets 627 The following ignores the case of transmitting TRILL IS-IS 628 packets. 630 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from 631 RBridge layer. 633 o If TRILL-HDR multicast flag set and TRILL-HDR Alert flag 634 set and OAM Ethertype present then: 636 o (DA, SA, V, M2) by inserting TRILL Outer.MacDA of All- 637 RBridges, Outer.MacSA, Outer.VLAN and TRILL Ethertype. 638 M2 here is (Ethertype TRILL, TRILL-HDR, iDA, iSA, iVL, 639 M) 641 NOTE: Second copy of native format is not made. 643 o Else If TRILL-HDR multicast flag set and Alert flag not set 645 o If the port is appointed Forwarder for iVL and the port 646 is not configured as a trunk port or a p2p port, Strip 647 TRILL-HDR, iSA, iDA, iVL and construct (DA, SA, V, M2) 648 for native format. 650 o Make a second copy (DA, SA, V, M2) by inserting TRILL 651 Outer.MacDA, Outer.MacSA, Outer.VLAN and TRILL 652 Ethertype. M2 here is (Ethertype TRILL, TRILL-HDR, iDA, 653 iSA, iVL, M) 655 o Pass the indication (DA, SA, V, M2) to End Station VLAN 656 processing layer. 658 4.4. TRILL OAM Layer Processing 660 TRILL OAM Processing Layer is located between the TRILL 661 Encapsulation / De-capsulation layer and RBridge Layer. It 662 performs the following: 1. Identification of OAM frames that 663 need local processing and 2. performs OAM processing or redirect 664 to the CPU for OAM processing. 666 o Receive indication (TRILL-HDR, iDA, iSA, iVL, M3) from 667 RBridge layer. M3 is the payload after inner VLAN iVL. 669 o If the TRILL Multicast Flag is set and TRILL Alert Flag is 670 set and TRILL OAM Ethertype is present then 671 o If MEP or MIP is configured on the Inner.VLAN/FGL of the 672 packet then 673 . discard packets that have MD-LEVEL Less than that 674 of the MEP or packets that do not have MD-LEVEL 675 present (e.g., due to packet truncation). 676 . If MD-LEVEL matches MD-LEVEL of the MEP then 677 . Re-direct to OAM Processing (Do not forward 678 further) 679 . If MD-LEVEL matches MD-LEVEL of MIP then 680 . Make a Copy for OAM processing and continue 681 . If MD-LEVL matches MD-LEVEL of MEP then 682 . Redirect the OAM packet to OAM processing 683 and do not forward along or forward as a 684 native packet. 686 o Else if TRILL Alert Flag is set and TRILL OAM Ethertype is 687 present then 688 o If MEP or MIP is configured on the Inner.VLAN/FGL of the 689 packet then 690 . discard packets that have MD-LEVEL not present or 691 MD-LEVEL is Less than that of the MEP. 692 . If MD-LEVEL matches MD-LEVEL of the MEP then 693 . Re-direct to OAM Processing (Do not forward 694 further) 695 . If MD-LEVEL matches MD-LEVEL of MIP then 696 . Make a Copy for OAM processing and continue 698 o Else // Non-OAM Packet 699 o Continue 701 o Pass the indication (DA, SA, V, M2) to End Station VLAN 702 processing layer. 704 NOTE: In the Receive path, processing above compares against Down 705 MEP and MIP Half functions. In the transmit processing it 706 compares against Up MEP and MIP Half functions. 708 Appointed Forwarder is a function the TRILL Encap/De-Cap layer 709 performs. The TRILL Encap/De-cap Layer is responsible for 710 prevention of leaking of OAM packets as native frames. 712 5. Maintenance Associations (MA) in TRILL 714 [8021Q] defines a maintenance association as a logical 715 relationship between a group of nodes. Each Maintenance 716 Association (MA) is identified with a unique MAID of 48 bytes 717 [8021Q]. CCM and other related OAM functions operate within the 718 scope of an MA. The definition of MA is technology independent. 719 Similarly it is encoded within the OAM message, not in the 720 technology dependent portion of the packet. Hence the MAID as 721 defined in [8021Q] can be utilized for TRILL OAM, without 722 modifications. This also allows us to utilize CCM and LBM 723 messages defined in [8021Q], as is. 725 In TRILL, an MA may contain two or more RBridges (MEPs). For 726 unicast, it is likely that the MA contains exactly two MEPs that 727 are the two end-points of the flow. For multicast, the MA may 728 contain two or more MEPs. 730 For TRILL, in addition to all of the standard [8021Q] CFM MIB 731 definitions, each MEP's MIB contains one or more flow entropy 732 definitions corresponding to the set of flows that the MEP 733 monitors. 735 [8021Q] CFM MIB is augmented to add the TRILL specific 736 information. Figure 5, below depicts the augmentation of the CFM 737 MIB to add the TRILL specific Flow Entropy. 739 MA--- 740 | 741 --- MEP 742 | 743 . - Remote MEP List 744 . 745 | 746 --- MEP-A 747 | 748 --- MEP-B 749 . 751 | 752 . - Flow Entropy List { Augments IEEE8021-CFM-MIB} 754 | 755 --- (Flow Entropy-1) 756 | 757 --- (Flow-entropy-2) 758 | 759 . --- (Flow Entropy n) 760 | 761 Other MIB entries 763 Figure 5 Correlation of TRILL augmented MIB 765 The detailed TRILL OAM MIB will be specified in a separate 766 document [TRILLOAMMIB]. 768 6. MEP Addressing 770 In IEEE CFM [8021Q], OAM messages address the target MEP by 771 utilizing a unique MAC address. In TRILL a MEP is addressed by 772 combination of the egress RBridge nickname and the Inner 773 VLAN/FGL. 775 Additionally, MEPs are represented by 2 octet MEP-ID that is 776 independent of the underlying technology. In CFM [8021Q] the 777 value of MEP-ID is restricted to 1 to 8191. However, on CFM 778 [8021Q] packet, MEP-ID are encoded as a 2 octet field. In TRILL 779 Base Mode operation presented in Appendix B MEP-IDs are mapped 1 780 to 1 with the RBridge nicknames. Hence, In TRILL, MEP-ID MUST be 781 a number in the range from 1 to 65535. 783 At the MEP, OAM packets go through a hierarchy of op-code de- 784 multiplexers. The op-code de-multiplexers channel the incoming 785 OAM packets to the appropriate message processor (e.g. LBM) The 786 reader may refer to Figure 6 below for a visual depiction of 787 these different de-multiplexers. 789 1. Identify the packets that need OAM processing at the Local 790 RBridge as specified in Section 4. 792 a. Identify the MEP that is associated with the 793 Inner.VLAN/FGL. 795 2. The MEP first validates the MD-LEVEL and then 797 a. Redirect to MD-LEVEL De-multiplexer 799 3. MD-LEVEL de-multiplexer compares the MD-Level of the packet 800 against the MD level of the local MEPs of a given MD-Level on 801 the port (Note: there can be more than one MEP at the same MD- 802 Level but belonging to different MAs) 804 a. If the packet MD-LEVEL is equal to the configured MD- 805 LEVEL of the MEP, then pass to the Opcode de-multiplexer 807 b. If the packet MD-LEVEL is less than the configured MD- 808 LEVEL of the MEP, discard the packet 810 c. If the packer MD-LEVEL is greater than the configured 811 MD-LEVEL of the MEP, then pass on to the next higher MD- 812 LEVEL de-multiplexer, if available. Otherwise, if no such 813 higher MD-LEVEL de-multiplexer exists, then forward the 814 packet as normal data. 816 4. Opcode De-multiplexer compares the opcode in the packet with 817 supported opcodes 819 a. If Op-code is CCM, LBM, LBR, PTM, PTR, MTVM, MTVR, then 820 pass on to the correct Processor 822 b. If Op-code is Unknown, then discard. 824 | 825 .CCM LBM PTM MTVM . . 826 | | | | 827 +-+-+-+-+-+-+-+-+-+-+-+-+ 828 | OP Code DE-Mux |--- Unknown 829 +-+-+-+-+-+-+-+-+-+-+-+-+ 830 ^ ^ ^ 831 MD==Li | | | 832 +-+-+ +-+-+ +-+-+ 833 | L |-->|L2 |-.- |Ln |---- > 834 +-+-+ +-+-+ +-+-+ | 835 | ^ | | | 836 MD
  • | T |----------------- >| M |--- > 843 + TRILL OAM ---- + pass through OAM ---- 845 Figure 6 OAM De-Multiplexers at MEP for active SAP 847 T : Denotes Tap, that identifies OAM frames that need local 848 processing. These are the packets with Alert flag set and 849 OAM Ethertype is present after the flow entropy of the 850 packet 852 M : Is the post processing merge, merges data and OAM 853 messages that are passed through. Additionally, the Merge 854 component ensures, as explained earlier, that OAM packets 855 are not forwarded out as native frames. 857 L : Denotes MD-Level processing. Packets with MD-Level less 858 than the Level will be dropped. Packets with equal MD-Level 859 are passed on to the opcode de-multiplexer. Others are 860 passed on to the next level MD processors or eventually to 861 the merge point (M). 863 NOTE: LBM, LBR, MTVM, MTVR, PTM and PTR are not subject to 864 MA de-multiplexers. These packets do not have an MA encoded 865 in the packet. Adequate response can be generated to these 866 packets, without loss of functionality, by any of the MEPs 867 present on that interface or an entity within the RBridge. 869 6.1. Use of MIP in TRILL 871 Maintenance Intermediate Points (MIP) are mainly used for fault 872 isolation. Link Trace Messages in [8021Q] utilize a well-known 873 multicast MAC address and MIPs generate responses to Link Trace 874 messages. Response to Link Trace messages or lack thereof can be 875 used for fault isolation in TRILL. 877 As explained in section 10. , a hop-count expiry approach will be 878 utilized for fault isolation and path tracing. The approach is 879 very similar to the well-known IP trace-route approach. Hence, 880 explicit addressing of MIPs is not required for the purpose of 881 fault isolation. 883 Any given RBridge can have multiple MIPs located within an 884 interface. As such, a mechanism is required to identify which MIP 885 should respond to an incoming OAM message. Any MIP residing 886 within the ingress interface may reply to the incoming Path Trace 887 message without loss of functionality or information. As 888 specified in Section 3.4. , the address of the responding RBridge 889 can be identified by means of Sender ID TLV (1). The Reply 890 Ingress TLV (5) identifies the interface id. The combination of 891 these allows recipient of the response to uniquely identify the 892 responder. 894 A similar approach to that presented above for MEPs can be used 895 for MIP processing. It is important to note that "M", the merge 896 block of a MIP, does not prevent OAM packets leaking out as 897 native frames. On edge interfaces, MEPs MUST be configured to 898 prevent the leaking of TRILL OAM packets out of the TRILL Campus. 900 PTM PTR MTVM MTVR 901 | | | | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | OP Code De-Mux |-> Unknown 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 ^ ^ ^ 906 MD==Li | | | 907 +-+-+ +-+-+ +-+-+ 908 | L |- >|L2 |-.- |Ln |------+ 909 +-+-+ +-+-+ +-+-+ | 910 ^ | 911 | | 912 Drop | | 913 MD not --- |TRILL OAM | 914 Present | | 915 | v 916 TRILL Data ---- TRILL Data ----- 917 ------- >| T |------------------ >| M |----> 918 + TRILL OAM ---- ---- 920 Figure 7 OAM De-Multiplexers at MIP for active SAP 922 T: TAP processing for MIP. All packets with OAM flag set are 923 captured. 925 L : MD Level Processing, Packet with matching MD Level are 926 "copied" to the Opcode de-multiplexer and original packet is 927 passed on to the next MD level processor. Other packets are 928 simply passed on to the next MD level processor, without copying 929 to the OP code de-multiplexer. 931 M : Merge processor, merge OAM packets to be forwarded along with 932 the data flow. 934 Packets that carry Path Trace Message (PT) or Multi-destination 935 Tree Verification (MTVM) OpCodes are passed on to the respective 936 processors. 938 Packets with unknown OpCodes are counted and discarded. 940 7. Continuity Check Message (CCM) 942 CCMs are used to monitor connectivity and configuration errors. 943 [8021Q] monitors connectivity by listening to periodic CCM 944 messages received from its remote MEP partners in the MA. An 945 [8021Q] MEP identifies cross-connect errors by comparing the MAID 946 in the received CCM message with the MEP's local MAID. The MAID 947 [8021Q] is a 48-byte field that is technology independent. 948 Similarly, the MEPID is a 2-byte field that is independent of the 949 technology. Given this generic definition of CCM fields, CCM as 950 defined in [8021Q] can be utilized in TRILL with no changes. 951 TRILL specific information may be carried in CCMs when encoded 952 using TRILL specific TLVs or sub-TLVs. This is possible since 953 CCMs may carry optional TLVs. 955 Unlike classical Ethernet environments, TRILL contains multipath 956 forwarding. The path taken by a packet depends on the payload of 957 the packet. The Maintenance Association identifies the interested 958 end-points (MEPs) of a given monitored path. For unicast there 959 are only two MEPs per MA. For multicast there can be two or more 960 MEPs in the MA. The entropy values of the monitored flows are 961 defined within the MA. CCM transmit logic will utilize these flow 962 entropy values when constructing the CCM packets. Please see 963 section 12. below for the theory of operation of CCM. 965 The MIB of [8021Q] is augmented with the definition of flow- 966 entropy. Please see [TRILLOAMMIB] for definition of these and 967 other TRILL related OAM MIB definitions. The below Figure depicts 968 the correlation between MA, CCM and the flow-entropy. 970 MA--- 971 | 972 --- MEP 973 | 974 . - Remote MEP List 975 . 976 | 977 --- MEP-A 978 | 979 --- MEP-B 980 . 982 | 983 . - Flow Entropy List {Augments IEEE8021-CFM-MIB} 985 | 986 --- (Flow Entropy-1) 987 | 988 --- (Flow-entropy-2) 989 | 990 . ---(Flow Entropy n) 991 | 992 . - CCM 993 | 994 --- (standard 8021ag entries) 995 | 996 --- (hop-count) { Augments IEEE8021-CFM-MIB} 997 | 998 --- (Other TBD TRILL OAM specific entries) 999 {Augmented} 1000 | 1001 . 1002 | 1003 - Other MIB entries 1005 Figure 8 Augmentation of CCM MIB in TRILL 1007 In a multi-pathing environment, a Flow - by definition - is 1008 unidirectional. A question may arise as to what flow entropy 1009 should be used in the response. CCMs are unidirectional and have 1010 no explicit reply; as such, the issue of the response flow 1011 entropy does not arise. In the transmitted CCM, each MEP reports 1012 local status using the Remote Defect Indication (RDI) flag. 1013 Additionally, a MEP may raise SNMP TRAPs [TRILLOAMMIB] as Alarms 1014 when a connectivity failure occurs. 1016 8. TRILL OAM Message Channel 1018 The TRILL OAM Message Channel can be divided into two parts: 1019 TRILL OAM Message header and TRILL OAM Message TLVs. Every OAM 1020 Message MUST contain a single TRILL OAM message header and a set 1021 of one or more specified OAM Message TLVs. 1023 8.1. TRILL OAM Message header 1025 As discussed earlier, a common messaging framework between 1026 [8021Q], TRILL, and other similar standards such as Y.1731 is 1027 accomplished by re-using the OAM message header defined in 1028 [8021Q]. 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 |MD-L | Version | OpCode | Flags |FirstTLVOffset | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | | 1034 . Opcode Specific Information . 1035 | | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | | 1038 . TLVs . 1039 | | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 Figure 9 OAM Message Format 1044 o MD-L: Maintenance Domain Level (3 bits). Identifies the 1045 maintenance domain level. For TRILL, in general, this field 1046 is set to a single value across the TRILL campus. When using 1047 TRILL base mode as specified in Appendix B, MD-L is set to 1048 3. However, extension of TRILL, for example to support 1049 multilevel, may create different MD-LEVELs and MD-L field 1050 must be appropriately set in those scenarios. (Please refer 1051 to [8021Q] for the definition of MD-Level) 1053 o Version: Indicates the version (5 bits) as specified in 1054 [8021Q]. This document does not require changing the Version 1055 defined in [8021Q]. 1057 o OpCode: Operation Code (8 bits). Specifies the operation 1058 performed by the message. See Section 8.2. 1060 o Flags: Includes operational flags (1 byte). The definition 1061 of flags is Opcode-specific and is covered in the applicable 1062 sections. 1064 o FirstTLVOffset: Defines the location of the first TLV, in 1065 bytes, starting from the end of the FirstTLVOffset field (1 1066 byte). (Refer to [8021Q] for the definition of the 1067 FirstTLVOffset.) 1069 MD-L, Version, Opcode, Flags and FirstTLVOffset fields 1070 collectively are referred to as the OAM Message Header. 1072 The Opcode specific information section of the OAM Message may 1073 contain Session Identification number, time-stamp, etc. 1075 8.2. TRILL Specific OAM Opcodes 1077 The following TRILL specific CFM Opcodes are defined. Each of the 1078 Opcodes indicates a separate type of TRILL OAM message. Details 1079 of the messages are presented in the related sections. 1081 TRILL OAM Message Opcodes: 1083 TBD1: Path Trace Reply 1084 TBD2: Path Trace Message 1085 TBD3: Multicast Tree Verification Reply 1086 TBD4: Multicast Tree Verification Message 1088 Loopback and CCM Messages reuse the opcodes defined by [8021Q] 1090 8.3. Format of TRILL OAM TLV 1092 The same CFM TLV format as defined in [8021Q] is used for TRILL 1093 OAM. The following figure depicts the general format of a TRILL 1094 OAM TLV: 1096 0 1 2 1097 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type | Length | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | | 1102 . Value(variable) . 1103 | | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 Figure 10 TRILL OAM TLV 1108 Type (1 octet): Specifies the Type of the TLV (see sections 8.4. 1109 for TLV types). 1111 Length (2 octets): Specifies the length of the 'Value' field in 1112 octets. Length of the 'Value' field can be either zero or more 1113 octets. 1115 Value (variable): The length and the content of this field depend 1116 on the type of the TLV. Please refer to applicable TLV 1117 definitions for the details. 1119 Semantics and usage of Type values allocated for TRILL OAM 1120 purpose are defined by this document and other future related 1121 documents. 1123 8.4. TRILL OAM TLVs 1125 TRILL related TLVs are defined in this section. [8021Q] defined 1126 TLVs are reused, where applicable. 1128 8.4.1. Common TLVs between CFM and TRILL 1130 The following TLVs are defined in [8021Q]. We re-use them where 1131 applicable. The format and semantics of the TLVs are as defined 1132 in [8021Q]. 1134 Type Name of TLV in [8021Q] 1135 ---- ---------------------- 1136 0 End TLV 1137 1 Sender ID TLV 1138 2 Port Status TLV 1139 3 Data TLV 1140 4 Interface Status TLV 1141 5 Reply Ingress TLV 1142 6 Reply Egress TLV 1143 7 LTM Egress Identifier TLV 1144 8 LTR Egress Identifier TLV 1145 9-30 Reserved 1146 31 Organization Specific TLV 1148 8.4.2. TRILL OAM Specific TLVs 1150 Listed below is a summary of TRILL OAM TLVs and their 1151 corresponding codes. Format and semantics of TRILL OAM TLVs are 1152 defined in subsequent sections. 1154 Type TLV Name 1155 ----------- ---------------------- 1156 TBDa TRILL OAM Application Identifier TLV 1157 TBDb Out of Band Reply Address TLV 1158 TBDc Diagnostic Label TLV 1159 TBDd Original Data Payload TLV 1160 TBDe RBridge scope TLV 1161 TBDf Previous RBridge nickname TLV 1162 TBDg Next Hop RBridge List (ECMP) TLV 1163 TBDh Multicast Receiver Port count TLV 1164 TBDi Flow Identifier TLV 1165 TBDj Reflector Entropy TLV 1166 TBDk Authentication TLV 1168 The TRILL OAM Application Identifier TLV (TBDa) MUST be the first 1169 TLV. An End TLV (0) MUST be included as the last TLV. All other 1170 TLVs can be included in any order. 1172 8.4.3. TRILL OAM Application Identifier TLV 1174 The TRILL OAM Application Identifier TLV carries TRILL OAM 1175 application specific information. The TRILL OAM Application 1176 Identifier TLV MUST always be present and MUST be the first TLV 1177 in TRILL OAM messages. Messages that do not include the TRILL OAM 1178 Application Identifier TLV as the first TLV MUST be discarded by 1179 a TRILL MP. 1181 1 2 3 1182 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 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Type | Length | Version | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1186 | Reserved1 | Fragment-ID | 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Return Code |Return sub-code| Reserved2 |F|C|O|I| 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 Figure 11 TRILL OAM Application Identifier TLV 1193 Type (1 octet) = TBDa indicate that this is the TRILL OAM 1194 Application Identifier TLV. 1196 Length (2 octets) = 9. 1198 TRILL OAM Version (1 octet), currently set to zero. Indicates the 1199 TRILL OAM version. TRILL OAM version can be different than the 1200 [8021Q] version. 1202 Reserved1 (3 octets): set to zero on transmission and ignored on 1203 reception. 1205 Fragment-ID (1 octet): Indicates the fragment number of the 1206 current message. This applies only to reply messages; in request 1207 messages it must be set to zero on transmission and ignored on 1208 receipt. F flag defined below MUST be set with the final message 1209 whether it is the last fragment of the fragmented message or only 1210 message of the reply. Section 13. below provides more details on 1211 OAM Message fragmentation. 1213 Return Code (1 octet): Set to zero on requests. Set to an 1214 appropriate value in response messages. 1216 Return sub-code (1 Octet): Return sub-code is set to zero on 1217 transmission of request message. Return sub-code identifies 1218 categories within a specific Return code. Return sub-code MUST be 1219 interpreted within a Return code. 1221 Reserved2 (12 bits): Set to zero on transmission and ignored on 1222 reception. 1224 F (1 bit): Final flag, when set, indicates this is the last 1225 response. 1227 C (1 bit): Cross connect error flag(VLAN/Label mapping error), if 1228 set indicates that the label (VLAN/FGL) in the flow entropy is 1229 different than the label included in the diagnostic TLV. This 1230 field is ignored in request messages and MUST only be interpreted 1231 in response messages. 1233 O (1 bit): If set, indicates, OAM out-of-band response requested. 1235 I (1 bit): If set, indicates, OAM in-band response requested. 1237 NOTE: When both O and I bits are set to zero, indicates that no 1238 response is required (silent mode). User MAY specify both O and I 1239 or one of them or none. When both O and I bits are set response 1240 is sent both in-band and out-of-band. 1242 8.4.4. Out Of Band Reply Address TLV 1244 Out of Band Reply Address TLV specifies the address to which an 1245 out of band OAM reply message MUST be sent. When O bit in the 1246 TRILL Version TLV is not set, Out of Band Reply Address TLV is 1247 ignored. 1249 1 2 3 1250 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 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Type | Length | Address Type | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Addr Length | | 1255 +-+-+-+-+-+-+-+-+ | 1256 | | 1257 . Reply Address . 1258 | | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 Figure 12 Out of Band IP Address TLV 1263 Type (1 octet) = TBDb 1265 Length (2 octets) = Variable. Minimum length is 2 + the length 1266 (in octets) of the shortest address. Currently the minimum value 1267 of this field is 4, but this could change in the future if a new 1268 address shorter than the TRILL RBridge nickname is defined. 1270 Address Type (1 octet) = 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge 1271 nickname. All other values reserved. 1273 Addr Length (1 octet) = Depends on the Address Type. Currently 1274 defined values are: 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge 1275 nickname. Other lengths may be acceptable for future Address 1276 Types. 1278 Reply Address (variable): Address where the reply needed to be 1279 sent. Length depends on the address specification. 1281 8.4.5. Diagnostics Label TLV 1283 Diagnostic label specifies the data label (VLAN or FGL) in which 1284 the OAM messages are generated. Receiving RBridge MUST compare 1285 the data label of the Flow entropy to the data label specified in 1286 the Diagnostic Label TLV. Label Error Flag in the response (TRILL 1287 OAM Message Version TLV) MUST be set when the two VLANs do not 1288 match. 1290 1 2 3 1291 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 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Type | Length | L-Type | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Reserved | Label(VLAN) | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 Figure 13 Diagnostic VLAN TLV 1300 Type (1 octet) = TBDc indicates that this is the TRILL Diagnostic 1301 VLAN TLV 1303 Length (2 octets) = 5 1305 L-Type (Label type, 1 octet) 1307 0- indicate 802.1Q 12 bit VLAN. 1309 1 - indicate TRILL 24 bit fine grain label 1311 Reserved (1 octet) = set to zero on transmission and ignored on 1312 reception. 1314 Label (24 bits)= Either 12 bit VLAN or 24 bit fine grain label. 1316 RBridges do not perform Label error checking when the Label TLV 1317 is not included in the OAM message. In certain deployments 1318 intermediate devices may perform label translation. In such 1319 scenarios, originator should not include the diagnostic Label TLV 1320 in OAM messages. Inclusion of diagnostic TLV will generate 1321 unwanted label error notifications. 1323 8.4.6. Original Data Payload TLV 1325 1 2 3 1326 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 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | Type | Length | | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1330 | | 1331 . Original Payload . 1332 | | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 Figure 14 Original Data Payload TLV 1337 Type (1 octet) = TBDd 1339 Length (2 octets) = variable 1341 Original Payload: The original TRILL Header and Entropy. Used in 1342 constructing replies to the Loopback Message (see Section 9) and 1343 the Path Trace Message (see Section 10). 1345 8.4.7. RBridge scope TLV 1347 RBridge scope TLV identifies nicknames of RBridges from which a 1348 response is required. The RBridge scope TLV is only applicable to 1349 Multicast Tree Verification messages. This TLV SHOULD NOT be 1350 included in other messages. Receiving RBridges MUST ignore this 1351 TLV on messages other than Multicast Verification Message. 1353 Each TLV can contain up to 255 nicknames of in-scope RBridges. A 1354 Multicast Verification Message may contain multiple "RBridge 1355 scope TLVs", in the event that more than 255 in scope RBridges 1356 need to be specified. 1358 Absence of the "RBridge scope TLV" indicates that a response is 1359 needed from all the RBridges. Please see section 11. for details. 1361 1 2 3 1362 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 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Type | Length | nOfnicknames | 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 | nickname-1 | nickname-2 | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 . . 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | | nickname-n | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 Figure 15 RBridge Scope TLV 1375 Type (1 octet) = TBDe indicates that this is the "RBridge scope 1376 TLV" 1378 Length (2 octets) = variable. Minimum value is 1. 1380 nOfnicknames (1 octet) = indicates number of nicknames included 1381 in this TLV. Zero (0) indicates no nicknames are included in the 1382 TLV. When this field is set to zero (0), length field MUST be set 1383 to 1. 1385 Nickname (2 octets) = 16 bit RBridge nickname. 1387 8.4.8. Previous RBridge nickname TLV 1389 The "Previous RBridge nickname TLV" identifies the nickname or 1390 nicknames of the Previous RBridge. [RFC6325] allows a given 1391 RBridge to hold multiple nicknames. 1393 The "Previous RBridge nickname TLV" is an optional TLV. Multiple 1394 instances of this TLV MAY be included when an upstream RBridge is 1395 represented by more than 255 nicknames (highly unlikely). 1397 1 2 3 1398 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 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Type | Length | Reserved | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | Reserved (continued) | nickname | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 Figure 16 Previous RBridge nickname TLV 1407 Type (1 octet) = TBDf indicates that this is the "Previous 1408 RBridge nickname" 1410 Length (2 octets) = 5. 1412 Reserved (3 octet) = set to zero on transmission and ignored on 1413 reception. 1415 Nickname (2 octets) = RBridge nickname. 1417 8.4.9. Next Hop RBridge List TLV 1419 "Next Hop RBridge List TLV" identifies the nickname or nicknames 1420 of the downstream next hop RBridges. [RFC6325] allows a given 1421 RBridge to have multiple Equal Cost Paths to a specified 1422 destination. Each next hop RBridge is represented by one of its 1423 nicknames. 1425 "Next Hop RBridge List TLV" is an optional TLV. Multiple 1426 instances of this TLV MAY be included when there are more than 1427 255 Equal Cost Paths to the destination. 1429 1 2 3 1430 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 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Type | Length | nOfnicknames | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | nickname-1 | nickname-2 | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 . . 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | | nickname-n | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 Figure 17 Next Hop RBridge List TLV 1443 Type (1 octet) = TBDg indicates that this is the "Next nickname" 1445 Length (2 octets) = variable. Minimum value is 1. 1447 Nickname (2 octets) = 16 bit RBridge nickname. 1449 nOfnicknames (1 octet) = indicates number of nicknames included 1450 in this TLV. Zero (0) indicates no nicknames are included in the 1451 TLV. When this field is set to zero (0), length field MUST be set 1452 to 1. 1454 8.4.10. Multicast Receiver Port count TLV 1456 "Multicast Receiver Port Count TLV" identifies the number of 1457 ports interested in receiving the specified multicast stream 1458 within the responding RBridge on the label (VLAN or FGL) 1459 specified by the Diagnostic Label TLV. 1461 Multicast Receiver Port count is an Optional TLV. 1463 1 2 3 1464 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 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | Type | Length | Reserved | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | number of Receivers | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 Figure 18 Multicast Receiver Availability TLV 1473 Type (1 octet) = TBDh indicates that this is the "Multicast 1474 Availability TLV" 1476 Length (2 octets) = 5. 1478 Reserved (1 octet) = set to zero on transmission and ignored on 1479 reception. 1481 Number of Receivers (4 octets) = Indicates the number of 1482 Multicast receivers available on the responding RBridge on the 1483 label specified by the diagnostic label. 1485 8.4.11. Flow Identifier (flow-id) TLV 1487 Flow Identifier (flow-id) uniquely identifies a specific flow. 1488 The flow-id value is unique per MEP and needs to be interpreted 1489 as such. 1491 1 2 3 1492 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 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Type | Length | Reserved | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | MEP-ID | flow-id | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 Figure 19 Flow Identifier TLV 1501 Type (1 octet) = TBDi 1503 Length (2 octets) = 5. 1505 Reserved (1 octet) set to 0 on transmission and ignored on 1506 reception. 1508 MEP-ID (2 octets) = MEP-ID of the originator [8021Q]. In TRILL 1509 MEP-ID can take a value from 1 to 65535. 1511 Flow-id (2 octets) = uniquely identifies the flow per MEP. 1512 Different MEPs may allocate the same flow-id value. The {MEP-ID, 1513 flow-id} pair is globally unique. 1515 Inclusion of the MEP-ID in the flow-id TLV allows the inclusion 1516 of a MEP-ID for messages that do not contain a MEP-ID in their 1517 OAM header. Applications may use MEP-ID information for different 1518 types of troubleshooting. 1520 8.4.12. Reflector Entropy TLV 1522 Reflector Entropy TLV is an optional TLV. This TLV, when present, 1523 tells the responder to utilize the Reflector Entropy specified 1524 within the TLV as the flow-entropy of the response message. 1526 1 2 3 1527 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 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Type | Length | Reserved | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | | 1532 . Reflector Entropy . 1533 | | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 Figure 20 Reflector Entropy TLV 1538 Type (1 octet) = TBDj Reflector Entropy TLV. 1540 Length (2 octets) = 97. 1542 Reserved (1 octet) = set to zero on transmission and ignored by 1543 the recipient. 1545 Reflector Entropy (96-octet) = Flow Entropy to be used by the 1546 responder. May be padded with zero if the desired flow entropy is 1547 less than 96 octets. 1549 8.4.13. Authentication TLV 1551 The Authentication TLV is an optional TLV that can appear in any 1552 OAM Message or Reply in TRILL. 1554 1 2 3 1555 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 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Type | Length | Auth Type | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | | 1560 . Authentication Value . 1561 | | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 Type (1 octet) = TBDk Authentication TLV. 1566 Length (2 octets) = variable length 1567 The Auth Type and following Authentication Value are the same as 1568 the Auth Type and following value for the [IS-IS] Authentication 1569 TLV. It is RECOMMENDED that Auth Type 3 be used. Auth Types 0, 1, 1570 2, and 54 MUST NOT be used. With Type 3, the Authentication TLV 1571 is as follows: 1573 1 2 3 1574 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 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Type | Length | Auth Type = 3 | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Key ID | | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 1580 . Authentication Data (variable) . 1581 | | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 With Auth Type 3, the process is generally as specified in 1585 [RFC5310] using the same Key ID space as TRILL [IS-IS]. The area 1586 covered by the Authentication TLV is from the beginning of the 1587 TRILL Header to the end of the TRILL OAM Message Channel - the 1588 Link Header and Trailer are not included. The TRILL Header Alert 1589 and Reserved bit and Hop Count are treated as if zero for the 1590 purposes of computing and verifying the Authentication Data. 1592 Key distribution is out of scope for this document as the keying 1593 distributed for IS-IS is used. 1595 An RBridge supporting OAM authentication can be configured to 1596 either (1) ignore received OAM Authentication TLVs and not send 1597 them, (2) ignore received OAM Authentication TLVs but include 1598 them in all OAM packets sent, or (3) to include Authentication 1599 TLVs in all OAM messages sent and enforce authentication of OAM 1600 messages received. When an RBridge is enforcing authentication, 1601 it discards any OAM message subject to OAM processing that does 1602 not contain an Authentication TLV or if the Authentication TLV 1603 does not verify. 1605 9. Loopback Message 1607 9.1. Loopback OAM Message format 1609 1 2 3 1610 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 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 |MD-L | Version | OpCode | Flags |FirstTLVOffset | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | Loopback Transaction Identifier | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | | 1617 . TLVs . 1618 | | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 Figure 21 Loopback OAM Message Format 1623 The above figure depicts the format of the Loopback Request and 1624 response messages as defined in [8021Q]. The Opcode for Loopback 1625 Message is set to 3 and the Opcode for the Reply Message is set 1626 to 2 [8021Q]. The Loopback Transaction Identifier (commonly 1627 called the Session Identification Number or Session ID in this 1628 document) is a 32-bit integer that allows the requesting RBridge 1629 to uniquely identify the corresponding session. Responding 1630 RBridges, without modification, MUST echo the received "Loopback 1631 Transaction Identifier" number. 1633 9.2. Theory of Operation 1635 9.2.1. Actions by Originator RBridge 1637 The originator RBridge takes the following actions: 1639 Identifies the destination RBridge nickname based on user 1640 specification or based on the specified destination MAC or IP 1641 address. 1643 Constructs the flow entropy based on user specified parameters or 1644 implementation specific default parameters. 1646 Constructs the TRILL OAM header: sets the opcode to Loopback 1647 message type (3)[8021Q]. Assigns applicable Loopback Transaction 1648 Identifier number for the request. 1650 The TRILL OAM Application Identifier TLV MUST be included and 1651 with the flags set to applicable values. 1653 Include following OAM TLVs, where applicable 1655 o Out of Band Reply Address TLV 1657 o Diagnostic Label TLV 1659 o Sender ID TLV 1661 Specify the Hop count of the TRILL data frame per user 1662 specification or utilize an applicable Hop count value. 1664 Dispatch the OAM frame for transmission. 1666 RBridges may continue to retransmit the request at periodic 1667 intervals, until a response is received or the re-transmission 1668 count expires. At each transmission Session Identification number 1669 MUST be incremented. 1671 9.2.2. Intermediate RBridge 1673 Intermediate RBridges forward the frame as a normal data frame 1674 and no special handling is required. 1676 9.2.3. Destination RBridge 1678 If the Loopback message is addressed to the local RBridge and 1679 satisfies the OAM identification criteria specified in section 1680 3.1. then, the RBridge data plane forwards the message to the CPU 1681 for further processing. 1683 The TRILL OAM application layer further validates the received 1684 OAM frame by checking for the presence of OAM-Ethertype at the 1685 end of the flow entropy. Frames that do not contain OAM-Ethertype 1686 at the end of the flow entropy MUST be discarded. 1688 Construction of the TRILL OAM response: 1690 TRILL OAM application encodes the received TRILL header and flow 1691 entropy in the Original payload TLV and includes it in the OAM 1692 message. 1694 Set the Return Code to (1) "Reply" and Return sub code to zero 1695 (0) "Valid Response". Update the TRILL OAM opcode to 2 (Loopback 1696 Message Reply) 1697 Optionally, if the VLAN/FGL identifier value of the received flow 1698 entropy differs from the value specified in the diagnostic Label, 1699 set the Label Error Flag on TRILL OAM Application Identifier TLV. 1701 Include the sender ID TLV (1) 1703 If in-band response was requested, dispatch the frame to the 1704 TRILL data plane with request-originator RBridge nickname as the 1705 egress RBridge nickname. 1707 If out-of-band response was requested, dispatch the frame to the 1708 IP forwarding process. 1710 10. Path Trace Message 1712 The primary use of the Path Trace Message is for fault isolation. 1713 It may also be used for plotting the path taken from a given 1714 RBridge to another RBridge. 1716 [8021Q] accomplishes the objectives of the TRILL Path Trace 1717 Message using Link Trace Messages. Link Trace Messages utilize a 1718 well-known multicast MAC address. This works for [8021Q], because 1719 for 802.1 both the unicast and multicast paths are congruent. 1720 However, in TRILL multicast and unicast are not congruent. Hence, 1721 TRILL OAM uses a new message format: the Path Trace message. 1723 The Path Trace Message has the same format as Loopback Message. 1724 The Opcode for Path Trace Reply is TBD1 and for Path Trace 1725 Message is TBD2. 1727 Operation of the Path Trace message is identical to the Loopback 1728 message except that it is first transmitted with a TRILL Header 1729 Hop count field value of 1. The sending RBridge expects an 1730 "Intermediate RBridge" Return sub-code from the next hop or a 1731 "Valid response" Return sub-Code response from the destination 1732 RBridge. If an "Intermediate RBridge" Return sub-code is 1733 received in the response, the originator RBridge records the 1734 information received from intermediate node that generated the 1735 message and resends the message by incrementing the previous Hop 1736 count value by 1. This process is continued until, a response is 1737 received from the destination RBridge or Path Trace process 1738 timeout occur or Hop count reaches a configured maximum value. 1740 10.1. Theory of Operation 1742 10.1.1. Action by Originator RBridge 1744 Identify the destination RBridge based on user specification or 1745 based on location of the specified MAC address. 1747 Construct the flow entropy based on user specified parameters or 1748 implementation specific default parameters. 1750 Construct the TRILL OAM header: Set the opcode to Path Trace 1751 Request message type (TBD2). Assign an applicable Session 1752 Identification number for the request. Return-code and sub-code 1753 MUST be set to zero. 1755 The TRILL OAM Application Identifier TLV MUST be included and set 1756 the flags to applicable values. 1758 Include following OAM TLVs, where applicable 1760 o Out of Band Reply Address TLV 1762 o Diagnostic Label TLV 1764 o Include the Sender ID TLV 1766 Specify the Hop count of the TRILL data frame as 1 for the first 1767 request. 1769 Dispatch the OAM frame to the TRILL data plane for transmission. 1771 An RBridge may continue to retransmit the request at periodic 1772 intervals, until a response is received or the re-transmission 1773 count expires. At each new re-transmission, the Session 1774 Identification number MUST be incremented. Additionally, for 1775 responses received from intermediate RBridges, the RBridge 1776 nickname and interface information MUST be recorded. 1778 10.1.2. Intermediate RBridge 1780 Path Trace Messages transit through Intermediate RBridges 1781 transparently, unless Hop-count has expired. 1783 TRILL OAM application layer further validates the received OAM 1784 frame by examining the presence of TRILL Alert Flag and OAM- 1785 Ethertype at the end of the flow entropy and by examining the MD 1786 Level. Frames that do not contain OAM-Ethertype at the end of the 1787 flow entropy MUST be discarded. 1789 Construction of the TRILL OAM response: 1791 TRILL OAM application encodes the received TRILL header and flow 1792 entropy in the Original payload TLV and include it in the OAM 1793 message. 1795 Set the Return Code to (1) "Reply" and Return sub code to zero 1796 (2) "Intermediate RBridge". Update the TRILL OAM opcode to TBD1 1797 (Path Trace Reply). 1799 If the VLAN/FGL identifier value of the received flow entropy 1800 differs from the value specified in the diagnostic Label, set the 1801 Label Error Flag on TRILL OAM Application Identifier TLV. 1803 Include following TLVs 1805 Previous RBridge nickname TLV (69) 1807 Reply Ingress TLV (5) 1809 Reply Egress TLV (6) 1811 Interface Status TLV (4) 1813 TRILL Next Hop RBridge (Repeat for each ECMP) (70) 1815 Sender ID TLV (1) 1817 If Label error detected, set C flag (Label error detected) in the 1818 version. 1820 If in-band response was requested, dispatch the frame to the 1821 TRILL data plane with request-originator RBridge nickname as the 1822 egress RBridge nickname. 1824 If out-of-band response was requested, dispatch the frame to the 1825 standard IP forwarding process. 1827 10.1.3. Destination RBridge 1829 Processing is identical to section 10.1.2. With the exception 1830 that TRILL OAM Opcode is set to Path Trace Reply (TBD1). 1832 11. Multi-Destination Tree Verification Message (MTVM) 1834 Multi-Destination Tree Verification messages allow verifying 1835 TRILL distribution tree integrity and pruning. TRILL VLAN/FGL and 1836 multicast pruning are described in [RFC6325] [RFC7180] and 1837 [RFC7172]. Multi-destination tree verification and Multicast 1838 group verification messages are designed to detect pruning 1839 defects. Additionally, these tools can be used for plotting a 1840 given multicast tree within the TRILL campus. 1842 Multi-Destination tree verification OAM frames are copied to the 1843 CPU of every intermediate RBridge that is part of the 1844 distribution tree being verified. The originator of the Multi- 1845 destination Tree verification message specifies the scope of 1846 RBridges from which a response is required. Only the RBridges 1847 listed in the scope field respond to the request. Other RBridges 1848 silently discard the request. Inclusion of the scope parameter is 1849 required to prevent receiving an excessive number of responses. 1850 The typical scenario of distribution tree verification or group 1851 verification, involves verifying multicast connectivity to a 1852 selected set of end-nodes as opposed to the entire network. 1853 Availability of the scope facilitates narrowing down the focus to 1854 only the RBridges of interest. 1856 Implementations MAY choose to rate-limit CPU bound multicast 1857 traffic. As a result of rate-limiting or due to other congestion 1858 conditions, MTVM messages may be discarded from time to time by 1859 the intermediate RBRidges and the requester may be required to 1860 retransmit the request. Implementations SHOULD narrow the 1861 embedded scope of retransmission request only to RBridges that 1862 have failed to respond. 1864 11.1. Multi-Destination Tree Verification Message (MTVM) Format 1866 Format of MTVM is identical to that of Loopback Message format 1867 defined in section 9. with the exception that the Op-Code used is 1868 TBD4. 1870 11.2. Theory of Operation 1872 11.2.1. Actions by Originator RBridge 1874 The user is required at a minimum to specify either the 1875 distribution trees that need to be verified, or the Multicast MAC 1876 address and VLAN/FGL, or VLAN/FGL and Multicast destination IP 1877 address. Alternatively, for more specific multicast flow 1878 verification, the user MAY specify more information e.g. source 1879 MAC address, VLAN/FGL, Destination and Source IP addresses. 1880 Implementations, at a minimum, must allow the user to specify a 1881 choice of distribution trees, Destination Multicast MAC address 1882 and VLAN/FGL that needs to be verified. Although, it is not 1883 mandatory, it is highly desired to provide an option to specify 1884 the scope. It should be noted that the source MAC address and 1885 some other parameters may not be specified if the Backwards 1886 Compatibility Method of Appendix A is used to identify the OAM 1887 frames. 1889 Default parameters MUST be used for unspecified parameters. Flow 1890 entropy is constructed based on user specified parameters and/or 1891 default parameters. 1893 Based on user specified parameters, the originating RBridge does 1894 the following: 1896 Identifies the nickname that represents the multicast tree. 1898 Obtains the applicable Hop count value for the selected 1899 multicast tree. 1901 Constructs TRILL OAM message header and include Session 1902 Identification number. Session Identification number facilitate 1903 the originator mapping the response to the correct request. 1905 Includes TRILL OAM Application Identifier TLV, which MUST be 1906 included. 1908 Includes the Op-Code Multicast Tree Verification Message 1909 (TBD4) 1911 Includes RBridge scope TLV (TBDe) 1913 Optionally, include following TLV, where applicable 1915 o Out-of-band IP address (TBDb) 1916 o Diagnostic Label (TBDd) 1918 o Sender ID TLV (1) 1920 Specify the Hop count of the TRILL data frame per user 1921 specification or alternatively utilize the applicable Hop count 1922 value if TRILL Hop count is not being specified by the user; and 1924 Dispatch the OAM frame to the TRILL data plane to be ingressed 1925 for transmission. 1927 The RBridge may continue to retransmit the request at a periodic 1928 interval until either a response is received or the re- 1929 transmission count expires. At each new re-transmission, the 1930 Session Identification number MUST be incremented. At each re- 1931 transmission, the RBridge may further reduce the scope to the 1932 RBridges that it has not received a response from. 1934 11.2.2. Receiving RBridge 1936 Receiving RBridges identify multicast verification frames per the 1937 procedure explained in sections 3.2. 1939 The RBridge validates the frame and analyzes the scope RBridge 1940 list. If the RBridge scope TLV is present and the local RBridge 1941 nickname is not specified in the scope list, it will silently 1942 discard the frame. If the local RBridge is specified in the scope 1943 list OR RBridge scope TLV is absent, the receiving RBridge 1944 proceeds with further processing as defined in section 11.2.3. 1946 11.2.3. In scope RBridges 1948 Construction of the TRILL OAM response: 1950 TRILL OAM application encodes the received TRILL header and flow 1951 entropy in the Original payload TLV and includes them in the OAM 1952 message. 1954 Set the Return Code to (0) and Return sub code to zero (0). 1955 Update the TRILL OAM opcode to TBD3 (Multicast Tree Verification 1956 Reply). 1958 Include following TLVs: 1960 Previous RBridge nickname TLV (TBDf) 1962 Reply Ingress TLV (5) 1963 Interface Status TLV (4) 1965 TRILL Next Hop RBridge List (TBDg) 1967 Sender ID TLV (1) 1969 Multicast Receiver Availability TLV (TBDh) 1971 If a Label (VLAN or FGL) cross connect error is detected, set the 1972 C flag (Cross connect error detected) in the Application 1973 Identifier TLV. 1975 If in-band response was requested, dispatch the frame to the 1976 TRILL data plane with request-originator RBridge nickname as the 1977 egress RBridge nickname. 1979 If out-of-band response was requested, dispatch the frame to the 1980 standard IP forwarding process. 1982 12. Application of Continuity Check Message (CCM) in TRILL 1984 Section 7. provides an overview of CCM Messages defined in 1985 [8021Q] and how they can be used within the TRILL OAM. This 1986 section, presents the application and Theory of Operations of CCM 1987 within the TRILL OAM framework. Readers are referred to [8021Q] 1988 for CCM message format and applicable TLV definitions and usages. 1989 Only the TRILL specific aspects are explained below. 1991 In TRILL, between any two given MEPs there can be multiple 1992 potential paths. Whereas in [8021Q], there is always a single 1993 path between any two MEPs at any given time. [RFC6905] requires 1994 solutions to have the ability to monitor continuity over one or 1995 more paths. 1997 CCM Messages are uni-directional, such that there is no explicit 1998 response to a received CCM message. Connectivity status is 1999 indicated by setting the applicable flags (e.g. RDI) of the CCM 2000 messages transmitted by an MEP. 2002 It is important that the solution presented in this document 2003 accomplishes the requirements specified in [RFC6905] within the 2004 framework of [8021Q] in a straightforward manner and with minimum 2005 changes. Section 8 above defines multiple flows within the CCM 2006 object, each corresponding to a flow that a given MEP wishes to 2007 monitor. Hence, CCM, in multipath environments like TRILL, 2008 monitors per flow connectivity and cross connect errors. 2010 Receiving MEPs do not cross check whether a received CCM belongs 2011 to a specific flow from the originating RBridge. Any attempt to 2012 track status of individual flows may explode the amount of state 2013 information that any given RBridge has to maintain. 2015 The obvious question arises: How does the originating RBridge 2016 know which flow or flows are at fault? 2018 This is accomplished with a combination of the RDI flag in the 2019 CCM header, flow-id TLV, and SNMP Notifications (Traps). Section 2020 12.1. below discuss the procedure. 2022 12.1. CCM Error Notification 2024 Each MEP transmits 4 CCM messages per each flow. ([8021Q] detects 2025 CCM fault when 3 consecutive CCM messages are lost). Each CCM 2026 Message has a unique sequence number (Session ID) and unique 2027 flow-identifier. The flow identifier is included in the OAM 2028 message via flow-id TLV. 2030 When an MEP notices a CCM timeout from a remote MEP (MEP-A), it 2031 sets the RDI flag on the next CCM message it generates. 2032 Additionally, it logs and sends SNMP notification that contain 2033 the remote MEP Identification, flow-id and the Sequence Number of 2034 the last CCM message it received and if available, the flow-id 2035 and the Sequence Number of the first CCM message it received 2036 after the failure. Each MEP maintains a unique flow-id per each 2037 flow, hence the operator can easily identify flows that 2038 correspond to the specific flow-id. 2040 The following example illustrates the above. 2042 Assume there are two MEPs, MEP-A and MEP-B. 2044 Assume there are 3 flows between MEP-A and MEP-B. 2046 Let's assume MEP-A allocates sequence numbers as follows 2048 Flow-1 Sequence={1,2,3,4,13,14,15,16,.. } flow-id=(1) 2050 Flow-2 Sequence={5,6,7,8,17,18,19,20,.. } flow-id=(2) 2052 Flow-3 Sequence={9,10,12,11,21,22,23,24,.. } flow-id=(3) 2054 Let's Assume Flow-2 is at fault. 2056 MEP-B, receives CCM from MEP-A with sequence numbers 1,2,3,4, but 2057 did not receive 5,6,7,8. CCM timeout is set to 3 CCM intervals in 2058 [8021Q]. Hence MEP-B detects the error at the 8'th CCM message. 2059 At this time the sequence number of the last good CCM message 2060 MEP-B has received from MEP-A is 4 and flow-id of the last good 2061 CCM Message is (1). Hence MEP-B will generate a CCM error SNMP 2062 notification with MEP-A and Last good flow-id (1) and sequence 2063 number 4. 2065 When MEP-A switches to flow-3 after transmitting flow-2, MEP-B 2066 will start receiving CCM messages. In the foregoing example it 2067 will be CCM message with Sequence Numbers 9,10,11,12,21 and so 2068 on. When in receipt of a new CCM message from a specific MEP, 2069 after a CCM timeout, the TRILL OAM will generate an SNMP 2070 Notification of CCM resume with remote MEP-ID and the first valid 2071 flow-id and the Sequence number after the CCM timeout. In the 2072 foregoing example, it is MEP-A, flow-id (3) and Sequence Number 2073 9. 2075 The remote MEP list under the CCM MIB Object is augmented to 2076 contain "Last Sequence Number", flow-id and "CCM Timeout" 2077 variables. Last Sequence Number and flow-id are updated every 2078 time a CCM is received from a remote MEP. CCM Timeout variable is 2079 set when the CCM timeout occurs and is cleared when a CCM is 2080 received. 2082 12.2. Theory of Operation 2084 12.2.1. Actions by Originator RBridge 2086 Derive the flow entropy based on flow entropy specified in the 2087 CCM Management object. 2089 Construct the TRILL CCM OAM header as specified in [8021Q]. 2091 TRILL OAM Version TLV MUST be included as the first TLV and set 2092 the flags to applicable values. 2094 Include other TLVs specified in [8021Q] 2096 Include the following optional TLV, where applicable 2098 o Sender ID TLV (1) 2100 Specify the Hop count of the TRILL data frame per user 2101 specification or utilize an applicable Hop count value. 2103 Dispatch the OAM frame to the TRILL data plane for transmission. 2105 An RBridge transmits a total of 4 requests, each at CCM 2106 retransmission interval. At each transmission the Session 2107 Identification number MUST be incremented by one. 2109 At the 5'th retransmission interval, flow entropy of the CCM 2110 packet is updated to the next flow entropy specified in the CCM 2111 Management Object. If current flow entropy is the last flow 2112 entropy specified, move to the first flow entropy specified and 2113 continue the process. 2115 12.2.2. Intermediate RBridge 2117 Intermediate RBridges forward the frame as a normal data frame 2118 and no special handling is required. 2120 12.2.3. Destination RBridge 2122 If the CCM Message is addressed to the local RBridge or multicast 2123 and satisfies OAM identification methods specified in sections 2124 3.2. then the RBridge data plane forwards the message to the CPU 2125 for further processing. 2127 The TRILL OAM application layer further validates the received 2128 OAM frame by examining the presence of OAM-Ethertype at the end 2129 of the flow entropy. Frames that do not contain OAM-Ethertype at 2130 the end of the flow entropy MUST be discarded. 2132 Validate the MD-LEVEL and pass the packet to the Opcode de- 2133 multiplexer. The Opcode de-multiplexer delivers CCM packets to 2134 the CCM process. 2136 The CCM Process performs processing specified in [8021Q]. 2138 Additionally the CCM process updates the CCM Management Object 2139 with the sequence number of the received CCM packet. Note: The 2140 last received CCM sequence number and CCM timeout are tracked per 2141 each remote MEP. 2143 If the CCM timeout is true for the sending remote MEP, then clear 2144 the CCM timeout in the CCM Management object and generate the 2145 SNMP notification as specified above. 2147 13. Fragmented Reply 2149 TRILL OAM allows Fragmented reply messages. In case of Fragmented 2150 Replies, all part of the reply MUST follow the procedure defined 2151 in this section. 2153 The same session Identification Number MUST be included in all 2154 related fragments of the same message. 2156 The TRILL OAM Application Identifier TLV MUST be included, with 2157 fragment-ID field monotonically increasing with each fragment 2158 transmitted with the appropriate Final Flag field. The Final 2159 Flag, MUST, only be equal to one on the final fragment of the 2160 reply. 2162 On the receiver, process MUST order the fragments based on the 2163 fragment id. Any fragments received after final fragment MUST be 2164 discarded. Messages with incomplete fragments (i.e. messages with 2165 one or missing fragments after the receipt of the fragment with 2166 the final flag set) MUST be discarded as well. 2168 If number of fragments exceed the maximum supported fragments 2169 (255), then return code of MUST be set according to the message 2170 and return sub code MUST be set to 1 indicating fragment limit 2171 exceed. 2173 14. Security Considerations 2175 Forged OAM packets could cause false error or failure indications 2176 or mask actual errors or failures or be used for denial of 2177 service. Source addresses for messages can be forged and the Out 2178 of Band reply facility (Section 8.4.4) provides for explicitly 2179 supplying the address for replies. For protection against forged 2180 OAM packets, the Authentication TLV (see Section 8.4.13) can be 2181 used in an OAM message in TRILL. This TLV depends on IS-IS keying 2182 material and the current state of IS-IS keying and the use of the 2183 virtually identical IS-IS Authentication TLV is analyzed in 2184 [KARPISIS]. In particular, there is currently no standardized IS- 2185 IS automated key management. 2187 Of course, authentication is ineffective unless verified and 2188 ineffective against senders who have the keying material needed 2189 to produce OAM messages that will pass authentication checks. 2190 Implementations MUST implement rate-limiting functionality to 2191 protect against exploitation of OAM messages as a means of denial 2192 of service attacks. Aggressive rate limiting may trigger false 2193 positive errors against CCM and LBM based session monitoring. 2195 Even with authentication, replay of authenticated messages may be 2196 possible. There are four types of messages: Continuity Check 2197 (CCM), Loopback, Path Trace, and Multi-Destination Tree 2198 Verification (MTVM). In the case of CCM messages, sequence 2199 numbers are required (see Section 12.1) that can protect against 2200 replay. In the case of Loopback Messages (see Section 9.1), a 2201 Loopback Transaction Identifier is included that, as required by 2202 [8021Q], is incremented with each transmission and can detect 2203 replays. Path Trace Messages (see Section 10) and MTVM (see 2204 section 11.1) are specified to have the same format, although 2205 with a different OpCodes, as the Loopback Message and so also 2206 have an identifier increment with each transmission that can 2207 detect replays. Thus all TRILL OAM messages have a field that can 2208 be used for replay protection. 2210 For general TRILL related security considerations, please refer 2211 to [RFC6325]. 2213 [8021Q] requires that the MEP filters or pass through OAM 2214 messages based on the MD-Level. The MD-Level is embedded deep in 2215 the OAM message. Hence, conventional methods of frame filtering 2216 may not be able to filter frames based on the MD-Level. As a 2217 result, OAM messages that must be dropped due to MD level 2218 mismatch may leak into a TRILL domain with different MD-Level. 2220 This leaking may not cause any functionality loss. The receiving 2221 MEP/MIP is required to validate the MD-level prior to acting on 2222 the message. Any frames received with an incorrect MD-Level need 2223 to be dropped. 2225 Generally, a single operator manages each TRILL campus, hence 2226 there is no risk of security exposure. However, in the event of 2227 multi operator deployments, operators should be aware of possible 2228 exposure of device specific information and appropriate measures 2229 must be taken. 2231 It is also important to note that the MPLS OAM [RFC4379] 2232 framework does not include the concept of domains and OAM 2233 filtering based on operators. It is our opinion that the lack of 2234 OAM frame filtering based on domains does not introduce 2235 significant functional deficiency or security risk. 2237 It is possible to mandate requiring different credentials to use 2238 different OAM functions or capabilities within a specific OAM 2239 function. Implementations may consider grouping users to 2240 different security clearance levels and restricting functions and 2241 capabilities to different clearance levels. However, Exact 2242 implementation details of such a framework are outside the scope 2243 of this document. 2245 15. IANA Considerations 2247 IANA is requested to assign the following: 2249 15.1. OAM Capabilitiy Flags 2251 Assign two TRILL-VER sub-TLV Capability Flags (see Section 3.3) 2252 as follows: 2254 Bit Description Reference 2255 --- ----------- --------- 2257 TBD[2] OAM capable [this document] 2259 TBD[3] Backwards compatible OAM [this document] 2261 15.2. CFM Code Points 2263 IANA is requested to assign four Op-Codes from the CFM OAM IETF 2264 Op-Codes sub-registry as follows [suggested values in square 2265 brackets]: 2267 Value Assignment Reference 2268 ===== ========== ========= 2270 TBD1[64] Path Trace Reply [this document] 2271 TBD2[65] Path Trace Message [this document] 2272 TBD3[66] Multicast Tree Verification Reply 2273 [this document] 2274 TBD4[67] Multicast Tree Verification Message 2275 [this document] 2277 IANA is requested to assign eleven TLV Types from the CFM OAM 2278 IETF TLV Types sub-registry as follows [suggested values in square 2279 brackets]: 2281 Value Assignment Reference 2282 ===== ========== ========= 2284 TBDa[64] TRILL OAM Application Identifier TLV 2285 [this document] 2286 TBDb[65] Out of Band Reply Address TLV [this document] 2287 TBDc[66] Diagnostic Label TLV [this document] 2288 TBDd[67] Original Data Payload TLV [this document] 2289 TBDe[68] RBridge Scope TLV [this document] 2290 TBDf[69] Previous RBridge nickname TLV 2291 [this document] 2292 TBDg[70] Next Hop RBridge List TLV 2293 [this document] 2294 TBDh[71] Multicast Receiver Port count TLV 2295 [this document] 2296 TBDi[72] Flow Identifier TLV [this document] 2297 TBDj[73] Reflector Entropy TLV [this document] 2298 TBDk[74] Authentication TLV [this document] 2300 15.3. MAC Addresses 2302 IANA is requested to assigned a unicast and a multicast MAC 2303 address under the IANA OUI, for identification of OAM packets as 2304 discussed for the backward compatibility method (Appendix A, 2305 Section A.2) based on the request template in Appendix C. The 2306 assigned addresses are TBDmac1 [00-00-5E-90-01-00] (unicast) and 2307 TBDmac2 [01-5E-90-01-00] (multicast). 2309 15.4. Return codes and sub codes 2311 IANA is requested to create TRILL OAM Return Code registry within 2312 the TRILL Parameter Registry and, for each return code a separate 2313 sub code Sub-Registry as below: 2315 Registry: TRILL OAM Return Codes. 2316 Registration Procedure: Standards Action. 2318 Return Code Assignment References 2319 =========== ========== ========== 2320 0 Request message [this document] 2322 1 Reply message [this document] 2323 2-255 Unassigned [this document] 2325 Sub-Registry: Sub Codes for TRILL OAM Return Code 0. 2327 Registration Procedure: Standards Action. 2329 Sub Code Assignment References 2330 =========== ========== ========== 2331 0 Valid request [this document] 2332 1-255 Unassigned [this document] 2334 Sub-Registry: Sub Codes for TRILL OAM Return Code 1. 2336 Registration Procedure: Standards Action. 2338 Sub Code Assignment References 2339 =========== ========== ========== 2340 0 Valid response [this document] 2341 1 Fragment limit exceeded [this document] 2342 2 Intermediate RBridge [this document] 2343 3-255 Unassigned [this document] 2345 15.5. TRILL RBridge Nickname Address Family 2347 IANA has allocated 16396 as the Address Family Number for TRILL 2348 RBridge nicknames. 2350 16. References 2352 16.1. Normative References 2354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2355 Requirement Levels", BCP 14, RFC 2119, March 1997. 2357 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing 2358 an IANA Considerations Section in RFCs", BCP 26, RFC 2359 5226, May 2008. 2361 [RFC5310] Bhatia, M., "IS-IS Cryptographic Generic Cryptographic 2362 Authentication", RFC 5310, February 2009. 2364 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 2365 Protocol Specification", RFC 6325, July 2011. 2367 [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 2368 and D. Dutt, "Transparent Interconnection of Lots of 2369 Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2370 2014. 2372 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 2373 Bridged Local Area Networks", IEEE Std 802.1Q-2011, 2374 August, 2011. 2376 [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System 2377 to Intermediate System Intra-Domain Routing Exchange 2378 Protocol for use in Conjunction with the Protocol for 2379 Providing the Connectionless-mode Network Service (ISO 2380 8473)", 2002. 2382 16.2. Informative References 2384 [RFC4379] Kompella, K. et.al, "Detecting Multi-Protocol Label 2385 Switched (MPLS) Data Plane Failures", RFC 4379, 2386 February 2006. 2388 [RFC6291] Andersson, L., et.al., "Guidelines for the use of the 2389 "OAM" Acronym in the IETF" RFC 6291, June 2011. 2391 [RFC6361] Carlson, J. and Eastlake, D. "PPP Transparent 2392 Interconnection of Lots of Links (TRILL) Protocol 2393 Control Protocol", RFC 6361, August 201. 2395 [RFC6905] Senevirathne, T. et.al, "Requirements for Operations, 2396 Administration, and Maintenance (OAM) in Transparent 2397 Interconnection of Lots of Links (TRILL)", RFC 6905, 2398 March 2013. 2400 [RFC7176] Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt, D., 2401 and A. Banerjee, "Transparent Interconnection of Lots 2402 of Links (TRILL) Use of IS-IS", RFC 7176 May 2014. 2404 [RFC7180] Eastlake, Donald, et.al. "TRILL: Clarifications, 2405 Corrections, and Updates, RFC 7180 May 2014. 2407 [RFC7174] Salam, S., et.al., "TRILL OAM Framework", RFC 7174 , 2408 May 2014. 2410 [RFC7179] Eastlake, Donald, et.al. "TRILL: Header Extension", RFC 2411 7179, May 2014. 2413 [Y1731] ITU-T Recommendation Y.1731, "OAM functions and 2414 mechanisms for Ethernet based networks", ITU-T 2415 G.8013/Y.1731, July 2013. 2417 [RFC7178] D. Eastlake, et.al. , "TRILL: RBridge Channel Support", 2418 RFC 7178, May 2014. 2420 [TRILLOAMMIB] Deepak Kumar et.al, "TRILL OAM MIB", draft-deepak- 2421 trill-oam-mib, May 2013, work in progress. 2423 [KARPISIS] U. Chunduri, et.a., "KARP IS-IS security analysis", 2424 draft-karp-isis-analysis, September 2014, work in 2425 progress. 2427 17. Acknowledgments 2429 Work in this document was largely inspired by the directions 2430 provided by Stewart Bryant in finding a common OAM solution 2431 between SDOs. 2433 Acknowledgments are due for many who volunteered to review this 2434 document, notably, Jari Arkko, Adrian Farrel, Pete Resnick, 2435 Stephen Farrell, Dan Romascanu, Gayle Nobel and Tal Mizrahi. 2437 Special appreciations are due for Dinesh Dutt for his support and 2438 encouragement, especially during the initial discussion phase of 2439 TRILL OAM. 2441 This document was prepared using 2-Word-v2.0.template.dot. 2443 Appendix A. Backwards Compatibility 2445 Methodology presented above in this document is in-line with the 2446 [8021Q] framework for providing fault management coverage. 2447 However, in practice, some TRILL platforms may not have the 2448 capabilities to support some of the required techniques. In this 2449 section, we present a method that allows RBridges, which do not 2450 have the required hardware capabilities, to participate in the 2451 TRILL OAM solution. 2453 There are two broad areas to be considered; 1. Maintenance Point 2454 (MEP/MIP) Model 2. Data plane encoding and frame identification 2456 A.1 Maintenance Point (MEP/MIP) Model 2458 For backwards compatibility, MEPs and MIPs are located in the 2459 CPU. This will be referred to as the "central brain" model as 2460 opposed to "port brain" model. 2462 In the "central brain" model, an RBridge using either ACLs or 2463 some other method, forwards qualifying OAM messages to the CPU. 2464 The CPU then performs the required processing and multiplexing to 2465 the correct MP (Maintenance Point). 2467 Additionally, RBridges MUST have the capability to prevent the 2468 leaking of OAM packets, as specified in [RFC6905]. 2470 A.2 Data plane encoding and frame identification 2472 The backwards compatibility method presented in this section 2473 defines methods to identify OAM frames when implementations do 2474 not have capabilities to utilize TRILL OAM Alert flag presented 2475 earlier to identify OAM frames, in the hardware. 2477 It is assumed ECMP path selection of non-IP flows utilize MAC DA, 2478 MAC SA and VLAN, IP Flows utilize IP DA, IP SA and TCP/UDP port 2479 numbers and other Layer 3 and Layer 4 information. The well-known 2480 fields to identify OAM flows are chosen such that they mimic the 2481 ECMP selection of the actual data along the path. However, it is 2482 important to note that, there may be implementations that would 2483 utilize these well-known fields for ECMP selections. Hence, 2484 implementations that support OAM SHOULD move to utilizing TRILL 2485 Alert Flag, as soon as possible and methods presented here SHOULD 2486 be used only as an interim solution. 2488 Identification methods are divided in to 4 broader groups: 2490 1. Identification of Unicast non-IP OAM Flows, 2492 2. Identification of Multicast non-IP OAM Flows, 2494 3. Identification of Unicast IP OAM Flows and 2496 4. Identification of Multicast IP OAM Flows 2498 As presented in the table below, based on the flow type (as 2499 defined above), implementations are required to use a well-known 2500 value in either the Inner.MacSA field or OAM Ethertype field to 2501 identify OAM flows. 2503 Receiving RBridge identifies OAM flows based on the presence of 2504 the well-known values in the specified fields, and additionally, 2505 for unicast flows, egress RBridge nickname of the packet MUST 2506 match that of the local RBridge or for multicast flows, TRILL 2507 header mutlicast flag MUST be set. 2509 Unicast OAM flows that qualify for local processing MUST be 2510 redirected to the OAM process and MUST NOT be forwarded (that to 2511 prevent leaking of the packet out of the TRILL campus). 2513 A copy of Multicast OAM flows that qualify for local processing 2514 MUST be sent to the OAM process and packet MUST be forwarded 2515 along the normal path. Additionally, methods MUST be in place to 2516 prevent multicast packets leaking out of the TRILL campus. 2518 The following table summarizes the identification of different 2519 OAM frames from data frames. 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 |Flow Entropy |Inner |OAM Ether|Egress | 2523 | |MacSA |Type |nickname | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 |unicast no IP | N/A |Match |Match | 2526 | | | | | 2527 |Multicast no IP| N/A |Match |N/A | 2528 | | | | | 2529 |Unicast IP | Match |N/A |Match | 2530 | | | | | 2531 |Multicast IP | Match |N/A |N/A | 2532 | | | | | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 Figure 22 Identification of TRILL OAM Frames 2537 The unicast and multicast Inner.MacSAs used for the unicast and 2538 multicast IP cases, respectively, are TBDmac1 [00-00-5E-90-01-00] 2539 and TBDmac2 [01-00-5E-90-01-01] assigned by the request in 2540 Appendix C. 2542 It is important to note that all RBridges MUST generate OAM flows 2543 with "A" flag set and CFM EtherType "0x8902" at the flow entropy 2544 off-set. However, well-known values MUST be utilized as part of 2545 the flow-entropy when generating OAM messages destined for older 2546 RBridges that are compliant to the backwards compatibility method 2547 defined in this appendix. 2549 Appendix B. Base Mode for TRILL OAM 2551 CFM, as defined in [8021Q], requires configuration of several 2552 parameters before the protocol can be used. These parameters 2553 include MAID, Maintenance Domain Level (MD-LEVEL) and MEPIDs. The 2554 Base Mode for TRILL OAM defined here facilitates ease of use and 2555 provides out of the box plug-and-play capabilities, supporting 2556 the Operational and Manageability considerations described in 2557 Section 6 of [RFC7174]. 2559 All RBridges that support TRILL OAM MUST support Base Mode 2560 operation. 2562 All Rbridges MUST create a default MA with MAID as specified 2563 herein. 2565 MAID [8021Q] has a flexible format and includes two parts: 2566 Maintenance Domain Name and Short MA name. In the Based Mode of 2567 operation, the value of the Maintenance Domain Name must be the 2568 character string "TrillBaseMode" (excluding the quotes "). In 2569 Base Mode operation Short MA Name format is set to 2-octet 2570 integer format (value 3 in Short MA Format field) and Short MA 2571 name set to 65532 (0xFFFC). 2573 The Default MA belongs to MD-LEVEL 3. 2575 In the Base Mode of operation, each RBridge creates a single UP 2576 MEP associated with a virtual OAM port with no physical layer 2577 (NULL PHY). The MEPID associated with this MEP is the 2-octet 2578 RBridge Nickname. 2580 By default, all RBridges operating in the Base Mode for TRILL OAM 2581 are able to initiate LBM, PT and other OAM tools with no 2582 configuration. 2584 Implementations MAY provide default flow-entropy to be included 2585 in OAM messages. Content of the default flow-entropy is outside 2586 the scope of this document. 2588 Figure 23, below depicts encoding of MAID within CCM messages. 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 |Field Name |Size | 2592 | | | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2594 |Maintenance | 1 | 2595 |Domain Format | | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 |Maintenance | 2 | 2598 |Domain Length | | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2600 |Maintenance | variable| 2601 |Domain Name | | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 |Short MA | 1 | 2604 |Name Format | | 2605 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2606 |Short MA | 2 | 2607 |Name Length | | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 |Short MA | variable| 2610 |Name | | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 |Padding | Variable| 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 Figure 23 MAID structure as defined in [8021Q] 2617 Maintenance Domain Name Format is set to Value: 4 2619 Maintenance Domain Name Length is set to value: 13 2621 Maintenance Domain Name is set to: TrillBaseMode 2623 Short MA Name Format is set to value: 3 2625 Short MA Name Length is set to value: 2 2627 Short MA Name is set to: FFFC 2629 Padding: set of zero up to 48 octets of total length of the MAID. 2631 Please refer to [8021Q] for details. 2633 Appendix C. MAC Addresses Request 2635 Applicant Name: IETF TRILL Working Group 2637 Applicant Email: tsenevir@cisco.com 2639 Applicant Telephone: +1-408-853-2291 2641 Use Name: TRILL OAM 2643 Document: draft-tissa-trill-oam-fm 2645 Specify whether this is an application for EUI-48 or EUI-64 2647 identifiers: EUI-48 2649 Size of Block requested: 1 2651 Specify multicast, unicast, or both: Both 2653 Authors' Addresses 2655 Tissa Senevirathne 2656 CISCO Systems 2657 375 East Tasman Drive. 2658 San Jose, CA 95134 2659 USA. 2661 Phone: +1 408-853-2291 2662 Email: tsenevir@cisco.com 2664 Norman Finn 2665 CISCO Systems 2666 510 McCarthy Blvd 2667 Milpitas, CA 95035 2668 USA 2670 Email: nfinn@cisco.com 2672 Samer Salam 2673 CISCO Systems 2674 595 Burrard St. Suite 2123 2675 Vancouver, BC V7X 1J1, Canada 2677 Email: ssalam@cisco.com 2679 Deepak Kumar 2680 CISCO Systems 2681 510 McCarthy Blvd, 2682 Milpitas, CA 95035, USA 2684 Phone : +1 408-853-9760 2685 Email: dekumar@cisco.com 2687 Donald Eastlake 2688 Huawei Technologies 2689 155 Beaver Street 2690 Milford, MA 01757 2692 Phone: +1-508-333-2270 2693 Email: d3e3e3@gmail.com 2694 Sam Aldrin 2695 Huawei Technologies 2696 2330 Central Express Way 2697 Santa Clara, CA 95951 2698 USA 2700 Email: aldrin.ietf@gmail.com 2702 Yizhou Li 2703 Huawei Technologies 2704 101 Software Avenue, 2705 Nanjing 210012 2706 China 2708 Phone: +86-25-56625375 2709 Email: liyizhou@huawei.com