idnits 2.17.00 (12 Aug 2021) /tmp/idnits65041/draft-ietf-trill-rbridge-channel-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2012) is 3742 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) == Outdated reference: draft-ietf-trill-rbridge-extension has been published as RFC 7179 == Outdated reference: draft-ietf-trill-clear-correct has been published as RFC 7180 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Intended status: Proposed Standard Vishwas Manral 4 HP Networking 5 Li Yizhou 6 Sam Aldrin 7 Huawei 8 Dave Ward 9 Cisco 10 Expires: August 19, 2012 February 20, 2012 12 TRILL: RBridge Channel Support 13 15 Abstract 17 This document specifies a general channel mechanism for sending 18 messages, such as BFD (Bidirectional Forwarding Detection) messages, 19 between RBridges (Routing Bridges) and between RBridges and end 20 stations in an RBridge campus through extensions to the TRILL 21 (TRansparent Interconnection of Lots of Links) protocol. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the TRILL working group mailing list. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Table of Contents 49 1. Introduction............................................3 50 1.1 RBridge Channel Requirements...........................3 51 1.2 Relation to the MPLS Generic Channel...................4 52 1.3 Terminology............................................4 54 2. Inter-RBridge Channel Messages..........................5 55 2.1 The RBridge Channel Message Inner Frame................6 56 2.1.1 RBridge Channel Header...............................6 57 2.1.2 Inner Ethernet Header................................7 58 2.1.3 Inner.VLAN Tag.......................................8 59 2.2 The TRILL Header for RBridge Channel Messages..........9 60 2.3 Ethernet Link Header and Trailer......................10 61 2.4 Special Transmission and Rate Considerations..........10 63 3. Processing RBridge Channel TRILL Data Messages.........11 64 3.1 Processing the RBridge Channel Header.................11 65 3.2 RBridge Channel Errors................................12 67 4. Native RBridge Channel Frames..........................14 68 5. Indicating Support for RBridge Channel Protocols.......16 70 6. Allocation Considerations..............................17 71 6.1 IANA Considerations...................................17 72 6.2 IEEE Registration Authority Considerations............18 74 7. Security Considerations................................19 76 8. References.............................................20 77 8.1 Normative References..................................20 78 8.2 Informative References................................20 80 Appendix: Change History..................................22 81 Acknowledgmnts............................................24 83 1. Introduction 85 RBridge campuses provide transparent least-cost path forwarding using 86 the TRILL (TRansparent Interconnection of Lots of Links) protocol 87 that builds on IS-IS (Intermediate System to Intermediate System) 88 routing [IS-IS] [RFC1195] [RFC6326bis]. Devices that implement TRILL 89 are called RBridges (Routing Bridges) or TRILL Switches. However, the 90 TRILL base protocol standard [RFC6325] provides only for TRILL Data 91 messages and TRILL IS-IS messages. 93 This document specifies a general channel mechanism for the 94 transmission of other messages within an RBridge campus, such as BFD 95 (Bidirectional Forwarding Detection, [RFC5880]) messages, between 96 RBridges and end stations that are directly connected on the same 97 link and between RBridges. This mechanism supports a requirement to 98 be able to operate with minimal configuration. 100 Familiarity with [RFC6325] and [RFC6327] is assumed in this document. 102 1.1 RBridge Channel Requirements 104 It is anticipated that various protocols operating at the TRILL level 105 will be desired in RBridge campuses. For example, there is a need for 106 rapid response continuity checking with a protocol such as BFD 107 [RFC5880] [RFC5882] and for a variety of optional reporting. 109 To avoid the requirement to design and specify a way to carry each 110 such protocol, this document specifies a general channel for sending 111 messages between RBridges in a campus at the TRILL level by extending 112 the TRILL protocol. To accommodate a wide variety of protocols, this 113 RBridge Channel facility accommodates all the regular modes of TRILL 114 Data transmission including single and multiple hop unicast as well 115 as VLAN scoped multi-destination distribution. 117 To minimize any unnecessary burden on transit RBridges and to provide 118 a more realistic test of network continuity and the like, RBridge 119 Channel messages are designed to look like TRILL Data frames and, in 120 the case of multi-hop messages, can normally be handled by transit 121 RBridges as if they were TRILL Data frames; however, to enable 122 processing at transit RBridges when required by particular messages, 123 they may optionally use the RBridge Channel Alert TRILL extended 124 header flags [RFCext] that causes a transit RBridge implementing the 125 flag to more closely examine a flagged frame. 127 This document also specifies a format for sending RBridge Channel 128 messages between RBridges and end stations that are directly 129 connected over a link, in either direction, when provided for by the 130 protocol involved. For the most part, this format is the same as the 131 format that is TRILL Data encapsulated for inter-RBridge channel 132 messages. 134 Each particular protocol using the RBridge Channel facility will 135 likely use only a subset of the facilities specified herein. 137 1.2 Relation to the MPLS Generic Channel 139 The RBridge Channel is similar to the MPLS Generic Channel specified 140 in [RFC5586]. Instead of using a special MPLS label to indicate a 141 special channel message, an RBridge Channel message is indicated by a 142 special multicast Inner.MacDA and inner Ethertype. 144 1.3 Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 The terminology and acronyms of [RFC6325] are used in this document 151 with the additions listed below. 153 BFD - Bidirectional Forwarding Detection 155 CHV - Channel Header Version 157 MH - Multi-Hop 159 NA - Native 161 SL - Silent 163 2. Inter-RBridge Channel Messages 165 Channel messages between RBridges are transmitted as TRILL Data 166 frames. (For information on channel messages that can be transmitted 167 between RBridges and end stations that are directly connected by a 168 link, see Section 4.) Inter-RBridge Channel messages are identified 169 as such by their Inner.MacDA, which is the All-Egress-RBridges 170 multicast address, together with their Inner Ethertype, which is the 171 RBridge-Channel Ethertype. This Ethertype is part of and starts the 172 RBridge Channel Header. 174 The diagram below shows the overall structure of a RBridge Channel 175 Message frame on a link between two RBridges: 177 Frame Structure Section of This Document 178 ------------------------ 179 +--------------------------------+ 180 | Link Header | Section 2.3 if Ethernet Link 181 +--------------------------------+ 182 | TRILL Header | Section 2.2 183 +--------------------------------+ 184 | Inner Ethernet Header | Section 2.1.2 185 +--------------------------------+ 186 | RBridge Channel Header | Section 2.1.1 187 +--------------------------------+ 188 | Protocol Specific Payload | See specific channel protocol 189 +--------------------------------+ 190 | Link Trailer (FCS if Ethernet) | 191 +--------------------------------+ 193 Optionally, some channel messages may require examination of the 194 frame by transit RBridges that support the RBridge Channel feature, 195 to determine if they need to take any action. To indicate this, such 196 messages use a RBridge Channel Alert extended TRILL header flags as 197 further described in Section 3 below. 199 The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL 200 Header for frames sent in an RBridge Channel. As always, the Outer 201 link header and trailer are whatever is needed to get a TRILL Data 202 frame to the next hop RBridge, depending on the technology of the 203 link, and can change with each hop for multi-hop messages. Section 204 2.3 describes the outer Link Header for Ethernet. And Section 2.4 205 discusses some special considerations for the first hop transmission 206 of RBridge Channel messages. 208 Section 3 describes some details of RBridge Channel message 209 processing. Section 4 provides the specifications for native RBridge 210 Channel frames between RBridges and end stations that are directly 211 connected over a link. 213 2.1 The RBridge Channel Message Inner Frame 215 The encapsulated inner frame within an RBridge Channel message frame 216 is as shown below. 218 Inner Ethernet Header: 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Special Inner.MacDA = All-Egress-RBridges | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Special Inner.MacDA cont. | Inner.MacSA | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Inner.MacSA cont. | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | VLAN Tag Ethertype | Priority, DEI, VLAN ID | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 RBridge Channel Header: 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | RBridge-Channel Ethertype | CHV | Channel Protocol | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Flags | ERR | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 RBridge Channel Protocol Specific Information: 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 + Channel Protocol Specific Data 238 | ... 240 The Channel Protocol Specific Data contains the information related 241 to the specific channel protocol used in the channel message. Details 242 of that data are outside the scope of this document, except in the 243 case of the RBridge Channel Error protocol specified below. 245 2.1.1 RBridge Channel Header 247 As shown in the diagram above, the RBridge Channel header starts with 248 the RBridge-Channel Ethertype (see Section 6.2). Following that is a 249 four-byte quantity with four sub-fields as follows: 251 CHV: A 4-bit field that gives the RBridge Channel Header Version 252 and MUST be zero. 254 Channel Protocol: A 12-bit unsigned integer that specifies the 255 particular RBridge Channel protocol to which the message 256 applies. 258 Flags: Provides 12 bits of flags described below. 260 ERR: A 4-bit unsigned integer used in connection with error 261 reporting at the RBridge Channel level as described in 262 Section 3. 264 The flag bits are numbered from 0 to 11 as shown below. 266 0 1 2 3 4 5 6 7 8 9 10 11 267 +--+--+--+--+--+--+--+--+--+--+--+--+ 268 |SL|MH|NA| Reserved | 269 +--+--+--+--+--+--+--+--+--+--+--+--+ 271 Bit 0, which is the high order bit in network order, is defined as 272 the SL or Silent bit. If it is a one, it suppresses RBridge 273 Channel Error messages (see Section 3). 275 Bit 1 is the MH or Multi-Hop bit. It is used to inform the 276 destination RBridge protocol that the message may be multi-hop 277 (MH=1) or was intended to be one-hop only (MH=0). 279 Bit 2 is the NA or Native bit. It is used as described in Section 4 280 below. 282 Reserved: Bits reserved for future specification that MUST be sent as 283 zero and ignored on receipt. 285 The RBridge Channel Protocol field specifies the protocol that the 286 channel message relates to. The initial defined value is listed 287 below. See Section 6 for IANA Considerations. 289 Protocol Name - Section of this Document 290 -------- ------------------------------- 292 0x001 RBridge Channel Error - Section 3 294 2.1.2 Inner Ethernet Header 296 The special Inner.MacDA is the All-Egress-RBridges multicast MAC 297 address to signal that the frame is intended for the egress 298 (decapsulating) RBridge itself (or the egress RBridges themselves if 299 the frame is multi-destination). (This address is called the All- 300 ESADI-RBridges address in [RFC6325].) The RBridge-Channel Ethertype 301 indicates that the frame is an RBridge Channel message. The only 302 other Ethertype currently specified for use with the All-Egress- 303 RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI frame 304 [RFC6325]. In the future additional Ethertypes may be specified for 305 use with the All-Egress-RBridges multicast address. 307 The RBridge originating the channel message selects the Inner.MacSA. 309 The Inner.MacSA MUST be set by the originating RBridge to a MAC 310 address unique within the campus owned by the originating RBridge. 311 This MAC address can be considered, in effect, the MAC address of a 312 virtual internal end station that handles the RBridge Channel frames 313 originated by or destined for that RBridge. It MAY be the same as the 314 Inner.MacSA used by the RBridge when it originates ESADI frames 315 [RFC6325]. 317 2.1.3 Inner.VLAN Tag 319 As with all frames formatted to be processed as a TRILL Data frame, 320 an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than 321 0x8100 or stacked tags is beyond the scope of this document but is an 322 obvious extension. 324 Multi-destination RBridge Channel messages are, like all multi- 325 destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID 326 MUST be set to the VLAN of interest. To the extent that distribution 327 tree pruning is in effect in the campus, such channel messages may 328 only reach RBridges advertising that they have connectivity to that 329 VLAN. 331 For channel messages sent as known unicast TRILL Data frames the 332 default value for the Inner.VLAN ID is VLAN 1 but particular RBridge 333 Channel protocols MAY specify other values. 335 The Inner.VLAN also specifies a three-bit frame priority for which 336 the following recommendations apply: 338 1. For one-hop channel messages critical to network connectivity, 339 such as one-hop BFD for rapid link failure detection in support 340 of TRILL IS-IS, the RECOMMENDED priority is 7. 342 2. For single and multi-hop known unicast channel messages 343 important to network operation but not critical for 344 connectivity, the RECOMMENDED priority is 6. 346 3. For other known unicast channel messages and all multi- 347 destination channel messages, it is RECOMMENDED that the 348 default priority zero be used. In any case, priorities higher 349 than 5 SHOULD NOT be used for such frames. 351 There is one additional bit in a VLAN tag value between the 12-bit 352 VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI, 353 [ClearCorrect]). It is RECOMMENDED that this bit be zero for the 354 first two categories of channel messages listed immediately above. 355 The setting of this bit for channel messages in the third category 356 may be dependent on the channel protocol and no general 357 recommendation is made for that case. 359 2.2 The TRILL Header for RBridge Channel Messages 361 After the outer Link Header (that, for Ethernet, ends with the TRILL 362 Ethertype) and before the encapsulated frame, the channel message's 363 TRILL Header initially appears as follows: 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |V=0| R |M| Ext-Len | Hop Count | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Egress Nickname | Ingress Nickname | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 The TRILL Header version V MUST be zero, the R bits are reserved, the 372 M bit is set appropriately as the channel message is to be forwarded 373 as known unicast (M=0) or multi-destination (M=1) regardless of the 374 fact that the Inner.MacDA is always the All-Egress-RBridges multicast 375 address, and Ext-Len is set appropriately for the length of the TRILL 376 Header extensions area, if any, all as specified in [RFC6325] (where 377 the extensions area is referred to as the options area and this field 378 as Op-Len). 380 When an RBridge Channel message is originated, the Hop Count field 381 defaults to the maximum value, 0x3F, but particular RBridge Channel 382 protocols MAY specify other values. For messages sent a known number 383 of hops, such as one-hop messages or a two-hop self-addressed message 384 intended to loop back through an immediate neighbor RBridge, setting 385 the Hops field to the maximum value and checking the Hop Count field 386 on receipt provides an additional validity check as discussed in 387 [RFC5082]. 389 The RBridge originating a channel message places a nickname that it 390 holds into the ingress nickname field. 392 There are several cases for the egress nickname field. If the channel 393 message is multi-destination, then the egress nickname designates the 394 distribution tree to use. If the channel message is a multi-hop 395 unicast message, then the egress nickname is a nickname of the target 396 RBridge; this includes the special case of a message intended to loop 397 back from an immediate neighbor where the originator places one of 398 its own nicknames in both the ingress and egress nickname fields. If 399 the channel message is a one-hop unicast message, there are two 400 possibilities for the egress nickname. 402 o The egress nickname can be set to a nickname of the target 403 neighbor RBridge. 405 o The special nickname Any-RBridge may be used. RBridges supporting 406 the RBridge Channel facility MUST recognize the Any-RBridge 407 special nickname and accept TRILL Data frames having that value in 408 the egress nickname field as being sent to them as the egress. 409 Thus, for such RBridges, using this egress nickname guarantees 410 processing by an immediate neighbor regardless of the state of 411 nicknames. 413 2.3 Ethernet Link Header and Trailer 415 An RBridge Channel frame has the usual link header and trailer 416 depending on the type of link on which it is sent. 418 For an Ethernet link [RFC6325] the Outer.MacSA is the MAC address of 419 the port from which the frame is sent. The Outer.MacDA is the MAC 420 address of the next-hop RBridge port for unicast RBridge Channel 421 messages or the All-RBridges multicast address for multi-destination 422 RBridge Channel messages. The Outer.VLAN tag specifies the Designated 423 VLAN for that hop and the priority should be the same as in the 424 Inner.VLAN tag; however, the output port may have been configured to 425 strip VLAN tags, in which case no Outer.VLAN tag appears on the wire. 426 And the link trailer is the Ethernet FCS. 428 2.4 Special Transmission and Rate Considerations 430 If a multi-hop RBridge Channel message is received by an RBridge, the 431 criteria and method of forwarding it are the same as for any TRILL 432 Data frame. If it is so forwarded, it will be on a link that was 433 included in the routing topology because it was in the Report state 434 as specified in [RFC6327]. 436 However, special considerations apply to single hop messages because, 437 for some RBridge Channel protocols, it may be desirable to send 438 RBridge Channel messages over a link that is not yet fully up. In 439 particular, it is permissible, if specified by the particular channel 440 protocol, for the source RBridge that has created an RBridge Channel 441 message to attempt to transmit it to a next hop RBridge when the link 442 is in the Detect or Two-Way states, as specified in [RFC6327], as 443 well as when it is in the Report state. Such messages can also be 444 sent on point-to-point links that are not in the Up state. 446 RBridge Channel messages represent a burden on the RBridges and links 447 in a campus and should be rate limited, especially if they are sent 448 as high priority, multi-destination, or multi-hop frames or have an 449 RBridge Channel Alert extended header flag set. 451 3. Processing RBridge Channel TRILL Data Messages 453 RBridge Channel TRILL Data messages are designed to look like and, to 454 the extent practical, be forwarded as regular TRILL Data frames. On 455 receiving a channel message, the initial tests on the Outer.MacDA, 456 Outer Ethertype, TRILL Header V and Hop Count fields and the Reverse 457 Path Forwarding Check if the frame is multi-destination, are all 458 performed as usual. The forwarding and/or decapsulation decisions are 459 the same as for a regular TRILL Data frame with following exceptions 460 for RBridges implementing the RBridge Channel facility: 462 1. An RBridge implementing the RBridge Channel facility MUST 463 recognize the Any-RBridge egress nickname in TRILL Data frames, 464 decapsulating such frames if they meet other checks. (Such a 465 frame cannot be a valid multi-destination frame because the 466 Any-RBridge nickname is not a valid distribution tree root.) 468 2. If an RBridge Channel Alert extended header flag is set, then 469 the RBridge MUST process the RBridge Channel message as 470 described below even if it is not egressing the frame. If it is 471 egressing the frame, then no additional processing beyond 472 egress processing is needed even if an RBridge Channel Alert 473 flag is set. 475 3. On decapsulation, the special Inner.MacDA value of All-Egress- 476 RBridges MUST be recognized to trigger checking the 477 Inner.Ethertype and processing as an RBridge Channel message if 478 that Ethertype is RBridge-Channel. 480 RBridge Channel messages SHOULD only be sent to RBridges that 481 advertise support for the channel protocol involved as described in 482 Section 5. 484 All RBridges supporting the RBridge Channel facility MUST recognize 485 the RBridge-Channel inner Ethertype. 487 3.1 Processing the RBridge Channel Header 489 Knowing that it has an RBridge Channel message, the egress RBridge, 490 and any transit RBridge if an RBridge Channel Alert bit is set in the 491 TRILL Header, looks at the CHV (RBridge Channel Header Version) and 492 Channel Protocol fields. 494 If any of the following conditions occur at an egress RBridge, the 495 frame is not processed, an error may be generated as specified in 496 Section 3.2, and the frame is discarded. The behavior is the same if 497 the frame is being processed at a transit RBridge because the 498 critical RBridge Channel Alert flag is set [RFCext]. However, if 499 these conditions are detected at a transit RBridge examining the 500 message because the non-critical RBridge Channel Alert flag is set 501 [RFCext] but the critical flag is not set, no error is generated and 502 the frame is still forwarded normally. 504 1. The Ethertype is not RBridge-Channel and not any other 505 Ethertype known to the RBridge as usable with the All-Egress- 506 RBridges Inner.MacDA, or the frame is so short that the 507 Ethertype is truncated. 509 2. The CHV field is non-zero or the frame is so short that the 510 version zero Channel Header is truncated. 512 3. The Channel Protocol field is a reserved value or a value 513 unknown to the processing RBridge. 515 4. The ERR field is non-zero and Channel Protocol is a value other 516 than 0x001. 518 5. The RBridge Channel Header NA flag is set to one indicating 519 that the frame should have been received as a native frame 520 rather than a TRILL Data frame. 522 If the CHV field and NA flag are zero and the processing RBridge 523 recognizes the Channel Protocol value, it processes the message in 524 accordance with that channel protocol. The processing model is as if 525 the received frame starting with and including the TRILL Header is 526 delivered to the Channel protocol along with a flag indicating 527 whether this is (a) transit RBridge processing due to an RBridge 528 Channel Alert flag being set or (b) egress processing. 530 Errors within a recognized Channel Protocol are handled by that 531 channel protocol itself and do not produce RBridge Channel Error 532 frames. 534 3.2 RBridge Channel Errors 536 A variety of problems at the RBridge Channel level cause the return 537 of an RBridge Channel Error frame unless (a) the "SL" (Silent) flag 538 is a one in the channel message for which the problem was detected, 539 (b) the processing is due to the non-critical RBridge Channel Alert 540 bit being set, (c) the frame in error appears, itself, to be an 541 RBridge Channel error frame (has a non-zero ERR field or a Channel 542 Protocol of 0x001), or (d) the error is suppressed due to rate 543 limiting. 545 An RBridge Channel Error frame is a multi-hop unicast RBridge Channel 546 message with the ingress nickname set to the nickname of the RBridge 547 detecting the error, and the egress nickname set to the value of the 548 ingress nickname in the channel message for which the error was 549 detected. No per-hop transit processing is specified for such error 550 frames, so the RBridge Channel Alert extended header flags SHOULD, if 551 an extension is present, be set to zero. The SL and MH flags SHOULD 552 be set to one, the NA flag MUST be zero, and the ERR field MUST be 553 non-zero as described below. For the protocol specific data area, an 554 RBridge Channel Message Error frame has at least the first 256 bytes 555 (or less if less are available) of the erroneous decapsulated channel 556 message starting with the TRILL Header. (Note: The TRILL Header does 557 not include the TRILL Ethertype that is part of the Link Header on 558 Ethernet Links.) 560 The following values for ERR are specified: 562 ERR Meaning 563 --- ------- 564 0 - Not an RBridge Channel error frame. 565 1 Frame too short (truncated Ethertype or RBridge Channel Header) 566 2 Unrecognized Ethertype 567 3 Unimplemented value of CHV 568 4 Wrong value of NA flag 569 5 Channel Protocol is reserved or unimplemented 570 6-14 - Available for allocation, see Section 6. 571 15 Reserved 573 All RBridges implementing the RBridge Channel feature MUST recognize 574 the RBridge Channel Error protocol value (0x001). They MUST NOT 575 generate an RBridge Channel Error message in response to a RBridge 576 Channel Error message, that is, a channel message with a protocol 577 value of 0x001 or with a non-zero ERR field. 579 4. Native RBridge Channel Frames 581 Other sections of this document specify non-native RBridge Channel 582 messages and their processing, that is, RBridge Channel messages 583 formatted as TRILL Data frames and sent between RBridges. This 584 section specifies the differences for native RBridge Channel 585 messages. 587 If provided for by the channel protocol involved, native RBridge 588 channel messages may be sent between end-stations and RBridges that 589 are directly connected over a link, in either direction. On an 590 Ethernet link, such native frames have the RBridge-Channel Ethertype 591 and are like the encapsulated frame inside an RBridge Channel message 592 except as follows: 594 1. TRILL does not require the presence of a VLAN tag on such 595 native RBridge channel frames. However, port configuration, 596 link characteristics, or the channel protocol involved may 597 require such tagging. 599 2. If the frame is unicast, the destination MAC address is the 600 unicast MAC address of the RBridge or end-station port that is 601 its intended destination. If the frame is multicast by an end 602 station to all the RBridges on a link that support an RBridge 603 Channel protocol that uses this transport, the destination MAC 604 address is the All-Edge-RBridges multicast address (see Section 605 6). A native RBridge Channel frame received at an ingress 606 RBridge with a destination MAC address that is a unicast 607 address different from that of the port or multicast address 608 different from All-Edge-RBridges, is discarded. If the frame is 609 multicast by an RBridge to all the devices that TRILL considers 610 to be end stations on a link that support an RBridge Channel 611 protocol that uses this transport, the destination MAC address 612 is the TRILL-End-Stations multicast address (see Section 6). A 613 native RBridge Channel frame received at an end station with a 614 destination MAC address that is a unicast address different 615 from that of the port or multicast address different from 616 TRILL-End-Stations, is discarded. 618 3. The RBridge-Channel outer Ethertype must be present. In the 619 future there may be other protocols using the All-Edge-RBridges 620 and/or TRILL-End-Stations multicast addresses on native frames 621 distinguished by different Ethertypes. 623 4. The NA or native bit in the RBridge Channel Header flags must 624 be a one. 626 5. There might be additional tags present between the Outer.MacDA, 627 Outer.MacSA pair and the RBridge-Channel Ethertype. 629 The RBridge Channel protocol number space for native RBridge Channel 630 messages and TRILL Data formatted RBridge Channel messages is the 631 same. If provided for by the channel protocol involved, the receipt 632 of a native RBridge Channel frame MAY lead to the generation and 633 transmission of one or more Inter-RBridge Channel frames. The 634 decapsulation and processing of a TRILL Data RBridge Channel frame 635 MAY, if provided for by the channel protocol involved, result in the 636 sending of one or more native RBridge channel frames to one or more 637 end stations. Thus, there could be an RBridge Channel protocol that 638 involved an RBridge Channel message sent from an origin RBridge where 639 the message is created, through one or more other RBridges and from 640 the last as a native RBridge channel message to and end station or 641 the reverse of such a path; however, to do this the RBridge channel 642 protocol involved must be implemented at the RBridge where the 643 channel message is changed between a native frame and a TRILL Data 644 format frame and must change the channel message itself, at a minimum 645 complementing the NA flag in the Channel Header and making 646 appropriate MAC address changes. 648 An erroneous native channel message results in a native RBridge 649 channel error message under the same conditions for which an TRILL 650 Data RBridge Channel message would result in a TRILL Data RBridge 651 channel error message. However, in a native RBridge Channel error 652 message, the NA flag MUST be one. Also, since there is no TRILL 653 Header in native RBridge Channel protocol frames, the beginning part 654 of the frame in which the error was detected that is included in 655 native RBridge Channel error frames starts with the RBridge Channel 656 Header (including the RBridge-Channel Ethertype). The destination MAC 657 address of such error messages is set to the source MAC address of 658 the native RBridge Channel message that was in error. 660 5. Indicating Support for RBridge Channel Protocols 662 Support for RBridge Channel protocols is indicated by the presence of 663 one or more TLVs and/or sub-TLVs in an RBridge's LSP as documented in 664 [RFC6326bis]. 666 RBridge Channel protocols 0 and 0xFFF are reserved and protocol 1, 667 the RBridge Channel error protocol, MUST be implemented as part of 668 the RBridge Channel feature. Thus, if an RBridge supports the RBridge 669 Channel feature, it should be advertising support for protocol 1 and 670 not advertising support for protocols 0 or 0xFFF in its LSP. 671 However, indication of support or non-support for RBridge Channel 672 protocol 1 is ignored on receipt and support for it is always 673 assumed, if support for any RBridge Channel is indicated in the 674 RBridge's LSP. 676 6. Allocation Considerations 678 The following subsections give IANA and IEEE allocation 679 considerations. In this document, the allocation procedure 680 specifications are as defined in [RFC5226]. 682 6.1 IANA Considerations 684 IANA is requested to allocate a previously unassigned TRILL Nickname 685 as follows: 687 Any-RBridge TBD (0xFFCO suggested) 689 IANA is requested to add "All-Egress-RBridges" to the TRILL Parameter 690 Registry as an alternative name for the "All-ESADI-RBridges" 691 multicast address. 693 IANA is requested to allocate two previously unassigned TRILL 694 Multicast address as follows: 696 TRILL-End-Stations TBD (01-80-C2-00-00-45 suggested) 697 All-Edge-RBridges TBD (01-80-C2-00-00-46 suggested) 699 IANA is requested to create an additional sub-registry in the TRILL 700 Parameter Registry for RBridge Channel Protocols, with initial 701 contents as follows: 703 Protocol Description Reference 704 -------- ----------- --------- 706 0x000 Reserved (This document) 707 0x001 RBridge Channel Error (This document) 708 0x002-0x0FF Available (1) 709 0x100-0xFF7 Available (2) 710 0xFF8-0xFFE Private Use 711 0xFFF Reserved (This document) 713 (1) RBridge Channel protocol code points from 0x002 to 0x0FF require 714 a Standards Action, as modified by [RFC4020], for allocation. 716 (2) RBridge Channel protocol code points from 0x100 to 0xFF7 require 717 RFC Publication to allocate a single value or IETF Review to allocate 718 multiple values. 720 IANA is requested to create an additional sub-registry in the TRILL 721 Parameter Registry for RBridge Channel Header Flags with initial 722 contents as follows: 724 Flag Bit Mnemonic Allocation 725 -------- -------- ---------- 727 0 SL Silent 728 1 MH Multi-hop 729 2 NA Native 730 3-11 - Available for allocation 732 Allocation of an RBridge Channel Header Flag is based on Standards 733 Action as modified by [RFC4020]. 735 IANA is requested to create an additional sub-registry in the TRILL 736 Parameter Registry for RBridge Channel Error codes with initial 737 contents as listed in Section 3.2 above and with available values 738 allocated by Standards Action as modified by [RFC4020]. 740 6.2 IEEE Registration Authority Considerations 742 The IEEE Registration Authority has been assigned the Ethertype 743 for RBridge-Channel. 745 7. Security Considerations 747 See [RFC6325] for general TRILL Security Considerations. 749 No general integrity, authentication, or encryption mechanisms are 750 provided herein for RBridge Channel messages. If these services are 751 required for a particular RBridge Channel protocol, they must be 752 supplied by that channel protocol. See, for example, the BFD 753 Authentication mechanism [RFC5880]. 755 If indication of RBridge Channel Protocol support are improperly 756 absent from an RBridge's LSP, it could deny all RBridge Channel 757 services, for example some BFD services, for the RBridge in question. 758 If a particular RBridge channel protocol is incorrectly not 759 advertised as supported, it would deny the service of that channel 760 protocol to the RBridge in question. 762 Incorrect presence of indication of RBridge Channel Protocol support 763 or incorrect assertion of support for a channel protocol could 764 encourage RBridge channel messages to be sent to an RBridge that does 765 not support the channel feature or the particular channel protocol 766 used. The inner frame of such messages could be decapsulated and that 767 inner frame could be sent out all ports that are appointed forwarders 768 for the frame's Inner.VLAN. However, this is unlikely to cause much 769 harm; in particuclar, there are two possibilities as follows: (a) If 770 end stations do not recognize the RBridge-Channel Ethertype of the 771 frame, they will drop it. (b) If end stations do recognize the 772 RBridge-Channel Ethertype and the channel protocol indicated in the 773 frame, they should refuse to process the frame due to an incorrect 774 value of the RBridge Channel Header NA flag. 776 No protection is provided against forging or the ingress nickname in 777 a TRILL Data formatted channel message or the Outer.MacSA in a native 778 RBridge Channel frame. This may result in misdirected return 779 responses or error messages. 781 8. References 783 The following sections list normative and informative references for 784 this document. 786 8.1 Normative References 788 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 789 Intermediate System Intra-Domain Routing Exchange Protocol for 790 use in Conjunction with the Protocol for Providing the 791 Connectionless-mode Network Service (ISO 8473)", 2002. 793 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 794 dual environments", RFC 1195, December 1990. 796 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 797 Requirement Levels", BCP 14, RFC 2119, March 1997 799 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 800 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 802 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 803 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 804 2008. 806 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 807 Ghanwani, "Routing Bridges (RBridges): Base Protocol 808 Specification", RFC 6325, July 2011. 810 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 811 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 812 6327, July 2011. 814 [RFCext] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. Bestler, 815 "TRILL: TRILL Header Extension", draft-ietf-trill-rbridge- 816 extension, work in progress. 818 [RFC6326bis] - Eastlake, D., A. Banerjee, D. Dutt, A. Ghanwani, R. 819 Perlman, "TRILL Use of IS-IS", draft-eastlake-isis-rfc6326bis, 820 work in progress. 822 8.2 Informative References 824 [RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 825 Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 826 5082, October 2007 828 [RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 829 "MPLS Generic Associated Channel", RFC 5586, June 2009. 831 [RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection 832 (BFD)", June 2010. 834 [RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional 835 Forwarding Detection (BFD)", June 2010. 837 [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V. 838 Manral, "TRILL: Clarifications, Corrections, and Updates", 839 draft-ietf-trill-clear-correct, work in progress. 841 Appendix: Change History 843 RFC Editor: please delete this appendix before publication. 845 Changes from -00 to -01 847 1. Spell out more acronyms. 849 2. Add reference to "Guidelines for the Use of OAM" draft. 851 3. Move definition of Alert flag to draft-ietf-trill-rbridge-options 852 and refer to it as an extended header flag. 854 4. Change name of "Egress-RBridges" multicast address to "All-Egress- 855 RBridges". Merge with All-ESADI-RBridges (i.e., they are two names 856 for the same MAC address). 858 5. Add detailed bit vector description for indicating support of 859 RBridge channel protocols. Add GENAPP and an APPsub-TLV to hold 860 one or more bit vectors. 862 6. Assorted editorial changes. 864 Changes from -01 to -02 866 1. Update for drafts that have been issued as RFCs. 868 2. Change to specification of Inner.VLAN in RBridge channel messages. 870 3. Remove GENAPP and move RBridge Channels supported information to 871 another document. 873 4. Clarify native RBridge Channel error messages. 875 5. Assorted editorial changes. 877 Changes from -02 to -03 879 1. Liberalize restrictions on RBridge acceptance of native RBridge 880 Channel messages. These are typically messages and should 881 generally be accepted unless in a VLAN not enabled at the port or 882 the like. 884 2. Change multi-cast address used by end stations in sending a native 885 RBridge Channel message to all RBridges on the link from All- 886 Egress-RBridges to All-Edge-RBridges to avoid possible confusion 887 if such a frame were encapsulated resulting in an All-Egress- 888 RBridges Inner.MacDA. 890 3. Reword references to "two-hop echo" and the like for clarity. 891 (This meant an echo frame that went to an immediate neighbor and 892 back.) 894 4. Add reference to and move some material to the RFC 6326bis draft. 896 5. Assorted editorial changes. 898 Changes from -03 to -04 900 1. Update for the replacement of the CFI bit by the DEI bit (see 901 [ClearCorrect]). 903 2. Update for the existence of both critical and non-critical RBridge 904 Channel alert flags. 906 3. Update author information. 908 4. Assorted editorial changes. 910 Changes from -04 to -05 912 1. Clarify the distinction between native and non-native RBridge 913 Channel messages and that native channel messages are only 914 intended to be transmitted between RBridge and end stations on the 915 same link. 917 2. Add a paragraph to the Security Considerations section about 918 forged ingress nicknames / source MAC addresses in channel 919 messages. 921 3. Add acknowledgements section. 923 4. Replace "OAM" references with "BFD" references in Abstract and 924 Introduction. 926 5. Very minor editorial changes. 928 Acknowledgmnts 930 The authors gratefully acknowledge the comments and contributions of 931 the follows, listed is alphabetic order: Somnath Chatterjee, Anoop 932 Ghanwani, Raksh Kumar, and Tissa Senevirathne. 934 Authors' Addresses 936 Donald Eastlake 3rd 937 Huawei R&D USA 938 155 Beaver Street 939 Milford, MA 01757 USA 941 Tel: +1-508-333-2270 942 EMail: d3e3e3@gmail.com 944 Vishwas Manral 945 HP Networking 946 19111 Pruneridge Avenue 947 Cupertino, CA 95014 USA 949 Tel: +1-408-477-0000 950 EMail: vishwa.manral@hp.com 952 Yizhou Li 953 Huawei Technologies 954 101 Software Avenue, 955 Nanjing 210012, China 957 Phone: +86-25-56622310 958 Email: liyizhou@huawei.com 960 Sam Aldrin 961 Huawei Technologies 962 2330 Central Expressway 963 Santa Clara, CA 95050 USA 965 Phone: +1-408-330-5000 966 Email: sam.aldrin@huawei.com 968 Dave Ward 969 Cisco Systems 970 170 W. Tasman Drive 971 San Jose, CA 95134 USA 972 EMail: dward@cisco.com 974 Copyright, Disclaimer, and Additional IPR Provisions 976 Copyright (c) 2012 IETF Trust and the persons identified as the 977 document authors. All rights reserved. 979 This document is subject to BCP 78 and the IETF Trust's Legal 980 Provisions Relating to IETF Documents 981 (http://trustee.ietf.org/license-info) in effect on the date of 982 publication of this document. Please review these documents 983 carefully, as they describe your rights and restrictions with respect 984 to this document. Code Components extracted from this document must 985 include Simplified BSD License text as described in Section 4.e of 986 the Trust Legal Provisions and are provided without warranty as 987 described in the Simplified BSD License. The definitive version of 988 an IETF Document is that published by, or under the auspices of, the 989 IETF. Versions of IETF Documents that are published by third parties, 990 including those that are translated into other languages, should not 991 be considered to be definitive versions of IETF Documents. The 992 definitive version of these Legal Provisions is that published by, or 993 under the auspices of, the IETF. Versions of these Legal Provisions 994 that are published by third parties, including those that are 995 translated into other languages, should not be considered to be 996 definitive versions of these Legal Provisions. For the avoidance of 997 doubt, each Contributor to the IETF Standards Process licenses each 998 Contribution that he or she makes as part of the IETF Standards 999 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1000 language to the contrary, or terms, conditions or rights that differ 1001 from or are inconsistent with the rights and licenses granted under 1002 RFC 5378, shall have any effect and shall be null and void, whether 1003 published or posted by such Contributor, or included with or in such 1004 Contribution.