idnits 2.17.00 (12 Aug 2021) /tmp/idnits375/draft-ietf-trill-rbridge-channel-07.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 (June 26, 2012) is 3615 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: December 25, 2012 June 26, 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. The list of Internet-Draft 43 Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 1. Introduction............................................3 49 1.1 RBridge Channel Requirements...........................3 50 1.2 Relation to the MPLS Generic Channel...................4 51 1.3 Terminology............................................4 53 2. Inter-RBridge Channel Messages..........................5 54 2.1 The RBridge Channel Message Inner Frame................6 55 2.1.1 RBridge Channel Header...............................6 56 2.1.1 Inner Ethernet Header................................8 57 2.1.3 Inner.VLAN Tag.......................................8 58 2.2 The TRILL Header for RBridge Channel Messages..........9 59 2.3 Ethernet Link Header and Trailer......................10 60 2.4 Special Transmission and Rate Considerations..........10 62 3. Processing RBridge Channel TRILL Data Messages.........12 63 3.1 Processing the RBridge Channel Header.................12 64 3.2 RBridge Channel Errors................................13 66 4. Native RBridge Channel Frames..........................15 67 5. Indicating Support for RBridge Channel Protocols.......17 69 6. Allocation Considerations..............................18 70 6.1 IANA Considerations...................................18 71 6.2 IEEE Registration Authority Considerations............19 73 7. Security Considerations................................20 75 8. References.............................................21 76 8.1 Normative References..................................21 77 8.2 Informative References................................21 79 Appendix: Change History..................................23 80 Acknowledgments...........................................26 82 1. Introduction 84 RBridge campuses provide transparent least-cost forwarding using the 85 TRILL (TRansparent Interconnection of Lots of Links) protocol that 86 builds on IS-IS (Intermediate System to Intermediate System) routing 87 [IS-IS] [RFC1195] [RFC6326bis]. Devices that implement TRILL are 88 called RBridges (Routing Bridges) or TRILL Switches. However, the 89 TRILL base protocol standard [RFC6325] provides only for TRILL Data 90 messages and TRILL IS-IS messages. 92 This document specifies a general channel mechanism for the 93 transmission of other messages within an RBridge campus, such as BFD 94 (Bidirectional Forwarding Detection, [RFC5880]) messages, (1) between 95 RBridges and end stations that are directly connected on the same 96 link and (2) between RBridges. This mechanism supports a requirement 97 to be able to operate with minimal configuration. 99 1.1 RBridge Channel Requirements 101 It is anticipated that various protocols operating at the TRILL layer 102 will be desired in RBridge campuses. For example, there is a need for 103 rapid response continuity checking with a protocol such as BFD 104 [RFC5880] [RFC5882] and for a variety of optional reporting. 106 To avoid the requirement to design and specify a way to carry each 107 such protocol, this document specifies a general channel for sending 108 messages between RBridges in a campus at the TRILL level by extending 109 the TRILL protocol. To accommodate a wide variety of protocols, this 110 RBridge Channel facility accommodates all the regular modes of TRILL 111 Data transmission including single and multiple hop unicast as well 112 as VLAN scoped multi-destination distribution. 114 To minimize any unnecessary burden on transit RBridges and to provide 115 a more realistic test of network continuity and the like, RBridge 116 Channel messages are designed to look like TRILL Data frames and, in 117 the case of multi-hop messages, can normally be handled by transit 118 RBridges as if they were TRILL Data frames; however, to enable 119 processing at transit RBridges when required by particular messages, 120 they may optionally use the RBridge Channel Alert TRILL extended 121 header flags [RFCext] that causes a transit RBridge implementing the 122 flag to more closely examine a flagged frame. 124 This document also specifies a format for sending RBridge Channel 125 messages between RBridges and end stations that are directly 126 connected over a link, in either direction, when provided for by the 127 protocol involved. For the most part, this format is the same as the 128 format that is TRILL Data encapsulated for inter-RBridge channel 129 messages. 131 Each particular protocol using the RBridge Channel facility will 132 likely use only a subset of the facilities specified herein. 134 1.2 Relation to the MPLS Generic Channel 136 The RBridge Channel is similar to the MPLS Generic Channel specified 137 in [RFC5586]. Instead of using a special MPLS label to indicate a 138 special channel message, an RBridge Channel message is indicated by a 139 special multicast Inner.MacDA and inner Ethertype (see Section 2.1). 141 1.3 Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 The terminology and acronyms of [RFC6325] are used in this document 148 with the additions listed below. 150 BFD - Bidirectional Forwarding Detection 152 CHV - Channel Header Version 154 MH - Multi-Hop 156 NA - Native 158 SL - Silent 160 2. Inter-RBridge Channel Messages 162 Channel messages between RBridges are transmitted as TRILL Data 163 frames. (For information on channel messages that can be transmitted 164 between RBridges and end stations that are directly connected by a 165 link, see Section 4.) Inter-RBridge Channel messages are identified 166 as such by their Inner.MacDA, which is the All-Egress-RBridges 167 multicast address, together with their Inner Ethertype, which is the 168 RBridge-Channel Ethertype. This Ethertype is part of and starts the 169 RBridge Channel Header. 171 The diagram below shows the overall structure of a RBridge Channel 172 Message frame on a link between two RBridges: 174 Frame Structure Section of This Document 175 ------------------------ 176 +--------------------------------+ 177 | Link Header | Section 2.3 if Ethernet Link 178 +--------------------------------+ 179 | TRILL Header | Section 2.2 180 +--------------------------------+ 181 | Inner Ethernet Header | Section 2.1.2 182 +--------------------------------+ 183 | RBridge Channel Header | Section 2.1.1 184 +--------------------------------+ 185 | Protocol Specific Payload | See specific channel protocol 186 +--------------------------------+ 187 | Link Trailer (FCS if Ethernet) | 188 +--------------------------------+ 190 Figure 1. RBridge Channel Frame Structure 192 Optionally, some channel messages may require examination of the 193 frame by transit RBridges that support the RBridge Channel feature, 194 to determine if they need to take any action. To indicate this, such 195 messages use a RBridge Channel Alert extended TRILL header flag as 196 further described in Section 3 below. 198 The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL 199 Header for frames sent in an RBridge Channel. As always, the Outer 200 link header and trailer are whatever is needed to get a TRILL Data 201 frame to the next hop RBridge, depending on the technology of the 202 link, and can change with each hop for multi-hop messages. Section 203 2.3 describes the outer Link Header for Ethernet links. And Section 204 2.4 discusses some special considerations for the first hop 205 transmission of RBridge Channel messages. 207 Section 3 describes some details of RBridge Channel message 208 processing. Section 4 provides the specifications for native RBridge 209 Channel frames between RBridges and end stations that are directly 210 connected over a link. 212 2.1 The RBridge Channel Message Inner Frame 214 The encapsulated inner frame within an RBridge Channel message frame 215 is as shown below. 217 0 1 2 3 218 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 219 Inner Ethernet Header: 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Special Inner.MacDA = All-Egress-RBridges | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Special Inner.MacDA cont. | Inner.MacSA | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Inner.MacSA cont. | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | VLAN Tag Ethertype | Priority, DEI, VLAN ID | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 RBridge Channel Header: 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | RBridge-Channel Ethertype | CHV | Channel Protocol | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Flags | ERR | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 RBridge Channel Protocol Specific Information: 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 + Channel Protocol Specific Data 239 | ... 241 Figure 2. RBridge Channel Inner Frame Header Fields 243 The Channel Protocol Specific Data contains the information related 244 to the specific channel protocol used in the channel message. Details 245 of that data are outside the scope of this document, except in the 246 case of the RBridge Channel Error protocol specified below. 248 2.1.1 RBridge Channel Header 250 As shown in Figure 2, the RBridge Channel header starts with the 251 RBridge-Channel Ethertype (see Section 6.2). Following that is a 252 four-byte quantity with four sub-fields as follows: 254 CHV: A 4-bit field that gives the RBridge Channel Header Version. 255 This document specifies version zero. 257 Channel Protocol: A 12-bit unsigned integer that specifies the 258 particular RBridge Channel protocol to which the message 259 applies. 261 Flags: Provides 12 bits of flags described below. 263 ERR: A 4-bit unsigned integer used in connection with error 264 reporting at the RBridge Channel level as described in 265 Section 3. 267 The flag bits are numbered from 0 to 11 as shown below. 269 | 0 1 2 3 4 5 6 7 8 9 10 11| 270 +--+--+--+--+--+--+--+--+--+--+--+--+ 271 |SL|MH|NA| Reserved | 272 +--+--+--+--+--+--+--+--+--+--+--+--+ 274 Figure 3. Channel Header Flag Bits 276 Bit 0, which is the high order bit in network order, is defined as 277 the SL or Silent bit. If it is a one, it suppresses RBridge 278 Channel Error messages (see Section 3). 280 Bit 1 is the MH or Multi-Hop bit. It is used to inform the 281 destination RBridge protocol that the message may be multi-hop 282 (MH=1) or was intended to be one-hop only (MH=0). 284 Bit 2 is the NA or Native bit. It is used as described in Section 4 285 below. 287 Reserved: Bits reserved for future specification that MUST be sent as 288 zero and ignored on receipt. 290 The RBridge Channel Protocol field specifies the protocol that the 291 channel message relates to. The initial defined value is listed 292 below. 294 Protocol Name - Section of this Document 295 -------- ------------------------------- 297 0x001 RBridge Channel Error - Section 3 299 IANA Considerations for RBridge Channel protocol numbers are provided 300 in Section 6. These include provisions for Private Use protocol 301 numbers. Because different uses of Private Use RBridge Channel 302 protocol numbers may conflict, such use MUST be within a private 303 network. It is the responsibility of the private network manager to 304 avoid conflicting use of these code points and unacceptable burdens 305 within the private network from their use. 307 2.1.1 Inner Ethernet Header 309 The special Inner.MacDA is the All-Egress-RBridges multicast MAC 310 address to signal that the frame is intended for the egress 311 (decapsulating) RBridge itself (or the egress RBridges themselves if 312 the frame is multi-destination). (This address is called the All- 313 ESADI-RBridges address in [RFC6325].) The RBridge-Channel Ethertype 314 indicates that the frame is an RBridge Channel message. The only 315 other Ethertype currently specified for use with the All-Egress- 316 RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI frame 317 [RFC6325]. In the future additional Ethertypes may be specified for 318 use with the All-Egress-RBridges multicast address. 320 The RBridge originating the channel message selects the Inner.MacSA. 321 The Inner.MacSA MUST be set by the originating RBridge to a MAC 322 address unique within the campus owned by the originating RBridge. 323 This MAC address can be considered, in effect, the MAC address of a 324 virtual internal end station that handles the RBridge Channel frames 325 originated by or destined for that RBridge. It MAY be the same as the 326 Inner.MacSA used by the RBridge when it originates ESADI frames 327 [RFC6325]. 329 2.1.3 Inner.VLAN Tag 331 As with all frames formatted to be processed as a TRILL Data frame, 332 an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than 333 0x8100 or stacked tags is beyond the scope of this document but is an 334 obvious extension. 336 Multi-destination RBridge Channel messages are, like all multi- 337 destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID 338 MUST be set to the VLAN of interest. To the extent that distribution 339 tree pruning is in effect in the campus, such channel messages may 340 only reach RBridges advertising that they have connectivity to that 341 VLAN. 343 For channel messages sent as known unicast TRILL Data frames the 344 default value for the Inner.VLAN ID is VLAN 1 but particular RBridge 345 Channel protocols MAY specify other values. 347 The Inner.VLAN also specifies a three-bit frame priority for which 348 the following recommendations apply: 350 1. For one-hop channel messages critical to network connectivity, 351 such as one-hop BFD for rapid link failure detection in support 352 of TRILL IS-IS, the RECOMMENDED priority is 7. 354 2. For single and multi-hop unicast channel messages important to 355 network operation but not critical for connectivity, the 356 RECOMMENDED priority is 6. 358 3. For other unicast channel messages and all multi-destination 359 channel messages, it is RECOMMENDED that the default priority 360 zero be used. In any case, priorities higher than 5 SHOULD NOT 361 be used for such frames. 363 There is one additional bit in a VLAN tag value between the 12-bit 364 VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI, 365 [ClearCorrect]). It is RECOMMENDED that this bit be zero for the 366 first two categories of channel messages listed immediately above. 367 The setting of this bit for channel messages in the third category 368 may be dependent on the channel protocol and no general 369 recommendation is made for that case. 371 2.2 The TRILL Header for RBridge Channel Messages 373 After the outer Link Header (that, for an Ethernet link, ends with 374 the TRILL Ethertype) and before the encapsulated frame, the channel 375 message's TRILL Header initially appears as follows: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |V=0| R |M| Op-Len | Hop Count | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Egress Nickname | Ingress Nickname | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 4. RBridge Channel TRILL Header Fields 387 The TRILL Header version V MUST be zero, the R bits are reserved, the 388 M bit is set appropriately as the channel message is to be forwarded 389 as known destination unicast (M=0) or multi-destination (M=1) 390 regardless of the fact that the Inner.MacDA is always the All-Egress- 391 RBridges multicast address, and Op-Len is set appropriately for the 392 length of the TRILL Header extensions area, if any, all as specified 393 in [RFC6325]. 395 When an RBridge Channel message is originated, the Hop Count field 396 defaults to the maximum value, 0x3F, but particular RBridge Channel 397 protocols MAY specify other values. For messages sent a known number 398 of hops, such as one-hop messages or a two-hop self-addressed message 399 intended to loop back through an immediate neighbor RBridge, setting 400 the Hops field to the maximum value and checking the Hop Count field 401 on receipt provides an additional validity check as discussed in 402 [RFC5082]. 404 The RBridge originating a channel message places a nickname that it 405 holds into the ingress nickname field. 407 There are several cases for the egress nickname field. If the channel 408 message is multi-destination, then the egress nickname designates the 409 distribution tree to use. If the channel message is a multi-hop 410 unicast message, then the egress nickname is a nickname of the target 411 RBridge; this includes the special case of a message intended to loop 412 back from an immediate neighbor where the originator places one of 413 its own nicknames in both the ingress and egress nickname fields. If 414 the channel message is a one-hop unicast message, there are two 415 possibilities for the egress nickname. 417 o The egress nickname can be set to a nickname of the target 418 neighbor RBridge. 420 o The special nickname Any-RBridge may be used. RBridges supporting 421 the RBridge Channel facility MUST recognize the Any-RBridge 422 special nickname and accept TRILL Data frames having that value in 423 the egress nickname field as being sent to them as the egress. 424 Thus, for such RBridges, using this egress nickname guarantees 425 processing by an immediate neighbor regardless of the state of 426 nicknames. 428 2.3 Ethernet Link Header and Trailer 430 An RBridge Channel frame has the usual link header and trailer for a 431 TRILL Data frame depending on the type of link on which it is sent. 433 For an Ethernet link [RFC6325] the Outer.MacSA is the MAC address of 434 the port from which the frame is sent. The Outer.MacDA is the MAC 435 address of the next-hop RBridge port for unicast RBridge Channel 436 messages or the All-RBridges multicast address for multi-destination 437 RBridge Channel messages. The Outer.VLAN tag specifies the Designated 438 VLAN for that hop and the priority should be the same as in the 439 Inner.VLAN tag; however, the output port may have been configured to 440 strip VLAN tags, in which case no Outer.VLAN tag appears on the wire. 441 And the link trailer is the Ethernet FCS. 443 2.4 Special Transmission and Rate Considerations 445 If a multi-hop RBridge Channel message is received by an RBridge, the 446 criteria and method of forwarding it are the same as for any TRILL 447 Data frame. If it is so forwarded, it will be on a link that was 448 included in the routing topology because it was in the Report state 449 as specified in [RFC6327]. 451 However, special considerations apply to single hop messages because, 452 for some RBridge Channel protocols, it may be desirable to send 453 RBridge Channel messages over a link that is not yet fully up. In 454 particular, it is permissible, if specified by the particular channel 455 protocol, for the source RBridge that has created an RBridge Channel 456 message to attempt to transmit it to a next hop RBridge when the link 457 is in the Detect or Two-Way states, as specified in [RFC6327], as 458 well as when it is in the Report state. Such messages can also be 459 sent on point-to-point links that are not in the Up state. 461 RBridge Channel messages represent a burden on the RBridges and links 462 in a campus and should be rate limited, especially if they are sent 463 as high priority, multi-destination, or multi-hop frames or have an 464 RBridge Channel Alert extended header flag set. 466 3. Processing RBridge Channel TRILL Data Messages 468 RBridge Channel TRILL Data messages are designed to look like and, to 469 the extent practical, be forwarded as regular TRILL Data frames. On 470 receiving a channel message, an RBridge performs the usual initial 471 tests on the frame and makes the same forwarding and/or decapsulation 472 decisions as for a regular TRILL Data frame [RFC6325] with following 473 exceptions for RBridges implementing the RBridge Channel facility: 475 1. An RBridge implementing the RBridge Channel facility MUST 476 recognize the Any-RBridge egress nickname in TRILL Data frames, 477 decapsulating such frames if they meet other checks. (Such a 478 frame cannot be a valid multi-destination frame because the 479 Any-RBridge nickname is not a valid distribution tree root.) 481 2. If an RBridge Channel Alert extended header flag is set, then 482 the RBridge MUST process the RBridge Channel message as 483 described below even if it is not egressing the frame. If it is 484 egressing the frame, then no additional processing beyond 485 egress processing is needed even if an RBridge Channel Alert 486 flag is set. 488 3. On decapsulation, the special Inner.MacDA value of All-Egress- 489 RBridges MUST be recognized to trigger checking the 490 Inner.Ethertype and processing as an RBridge Channel message if 491 that Ethertype is RBridge-Channel. 493 RBridge Channel messages SHOULD only be sent to RBridges that 494 advertise support for the channel protocol involved as described in 495 Section 5. 497 All RBridges supporting the RBridge Channel facility MUST recognize 498 the RBridge-Channel inner Ethertype. 500 3.1 Processing the RBridge Channel Header 502 Knowing that it has an RBridge Channel message, the egress RBridge, 503 and any transit RBridge if an RBridge Channel Alert bit is set in the 504 TRILL Header, looks at the CHV (RBridge Channel Header Version) and 505 Channel Protocol fields. 507 If any of the following conditions occur at an egress RBridge, the 508 frame is not processed, an error may be generated as specified in 509 Section 3.2, and the frame is discarded. The behavior is the same if 510 the frame is being processed at a transit RBridge because the 511 critical RBridge Channel Alert flag is set [RFCext]. However, if 512 these conditions are detected at a transit RBridge examining the 513 message because the non-critical RBridge Channel Alert flag is set 515 [RFCext] but the critical flag is not set, no error is generated and 516 the frame is still forwarded normally. 518 Error Conditions: 520 1. The Ethertype is not RBridge-Channel and not any other 521 Ethertype known to the RBridge as usable with the All-Egress- 522 RBridges Inner.MacDA, or the frame is so short that the 523 Ethertype is truncated. 525 2. The CHV field is non-zero or the frame is so short that the 526 version zero Channel Header is truncated. 528 3. The Channel Protocol field is a reserved value or a value 529 unknown to the processing RBridge. 531 4. The ERR field is non-zero and Channel Protocol is a value other 532 than 0x001. 534 5. The RBridge Channel Header NA flag is set to one indicating 535 that the frame should have been received as a native frame 536 rather than a TRILL Data frame. 538 If the CHV field and NA flag are zero and the processing RBridge 539 recognizes the Channel Protocol value, it processes the message in 540 accordance with that channel protocol. The processing model is as if 541 the received frame starting with and including the TRILL Header is 542 delivered to the Channel protocol along with a flag indicating 543 whether this is (a) transit RBridge processing due to an RBridge 544 Channel Alert flag being set or (b) egress processing. 546 Errors within a recognized Channel Protocol are handled by that 547 channel protocol itself and do not produce RBridge Channel Error 548 frames. 550 3.2 RBridge Channel Errors 552 A variety of problems at the RBridge Channel level cause the return 553 of an RBridge Channel Error frame unless one of the following apply: 554 (a) the "SL" (Silent) flag is a one in the channel message for which 555 the problem was detected, (b) the processing is due to the non- 556 critical RBridge Channel Alert bit being set, (c) the frame in error 557 appears, itself, to be an RBridge Channel error frame (has a non-zero 558 ERR field or a Channel Protocol of 0x001), or (d) the error is 559 suppressed due to rate limiting. 561 An RBridge Channel Error frame is a multi-hop unicast RBridge Channel 562 message with the ingress nickname set to a nickname of the RBridge 563 detecting the error, and the egress nickname set to the value of the 564 ingress nickname in the channel message for which the error was 565 detected. No per-hop transit processing is specified for such error 566 frames, so the RBridge Channel Alert extended header flags SHOULD, if 567 an extension is present, be set to zero. The SL and MH flags SHOULD 568 be set to one, the NA flag MUST be zero, and the ERR field MUST be 569 non-zero as described below. For the protocol specific data area, an 570 RBridge Channel Message Error frame has at least the first 256 bytes 571 (or less if less are available) of the erroneous decapsulated channel 572 message starting with the TRILL Header. (Note: The TRILL Header does 573 not include the TRILL Ethertype that is part of the Link Header on 574 Ethernet Links.) 576 The following values for ERR are specified: 578 ERR RBridge Channel Error Code Meaning 579 --- ---------------------------------- 580 0 - No error 581 1 Frame too short (truncated Ethertype or Channel Header) 582 2 Unrecognized Ethertype 583 3 Unimplemented value of CHV 584 4 Wrong value of NA flag 585 5 Channel Protocol is reserved or unimplemented 586 6-14 - Available for allocation, see Section 6. 587 15 Reserved (see Note) 589 Note: Intended to be allocated by Standards Action for an error 590 code expansion feature when it appears likely that all other 591 available error codes are being allocated. 593 All RBridges implementing the RBridge Channel feature MUST recognize 594 the RBridge Channel Error protocol value (0x001). They MUST NOT 595 generate an RBridge Channel Error message in response to a RBridge 596 Channel Error message, that is, a channel message with a protocol 597 value of 0x001 or with a non-zero ERR field. 599 4. Native RBridge Channel Frames 601 Other sections of this document specify non-native RBridge Channel 602 messages and their processing, that is, RBridge Channel messages 603 formatted as TRILL Data frames and sent between RBridges. This 604 section specifies the differences for native RBridge Channel 605 messages. 607 If provided for by the channel protocol involved, native RBridge 608 channel messages may be sent between end-stations and RBridges that 609 are directly connected over a link, in either direction. On an 610 Ethernet link, such native frames have the RBridge-Channel Ethertype 611 and are like the encapsulated frame inside an RBridge Channel message 612 except as follows: 614 1. TRILL does not require the presence of a VLAN tag on such 615 native RBridge channel frames. However, port configuration, 616 link characteristics, or the channel protocol involved may 617 require such tagging. 619 2. If the frame is unicast, the destination MAC address is the 620 unicast MAC address of the RBridge or end-station port that is 621 its intended destination. If the frame is multicast by an end 622 station to all the RBridges on a link that support an RBridge 623 Channel protocol that uses this transport, the destination MAC 624 address is the All-Edge-RBridges multicast address (see Section 625 6). A native RBridge Channel frame received at an ingress 626 RBridge with a destination MAC address that is a unicast 627 address different from that of the port or multicast address 628 different from All-Edge-RBridges, is discarded. If the frame is 629 multicast by an RBridge to all the devices that TRILL considers 630 to be end stations on a link that support an RBridge Channel 631 protocol that uses this transport, the destination MAC address 632 is the TRILL-End-Stations multicast address (see Section 6). A 633 native RBridge Channel frame received at an end station with a 634 destination MAC address that is a unicast address different 635 from that of the port or multicast address different from 636 TRILL-End-Stations, is discarded. 638 3. The RBridge-Channel outer Ethertype must be present. In the 639 future there may be other protocols using the All-Edge-RBridges 640 and/or TRILL-End-Stations multicast addresses on native frames 641 distinguished by different Ethertypes. 643 4. The NA or native bit in the RBridge Channel Header flags must 644 be a one. 646 5. There might be additional tags present between the Outer.MacDA, 647 Outer.MacSA pair and the RBridge-Channel Ethertype. 649 The RBridge Channel protocol number space for native RBridge Channel 650 messages and TRILL Data formatted RBridge Channel messages is the 651 same. If provided for by the channel protocol involved, the receipt 652 of a native RBridge Channel frame MAY lead to the generation and 653 transmission of one or more Inter-RBridge Channel frames. The 654 decapsulation and processing of a TRILL Data RBridge Channel frame 655 MAY, if provided for by the channel protocol involved, result in the 656 sending of one or more native RBridge channel frames to one or more 657 end stations. Thus, there could be an RBridge Channel protocol that 658 involved an RBridge Channel message sent from an origin RBridge where 659 the message is created, through one or more transit RBridges and from 660 the last as a native RBridge channel message to and end station or 661 the reverse of such a path; however, to do this the RBridge channel 662 protocol involved must be implemented at the RBridge where the 663 channel message is changed between a native frame and a TRILL Data 664 format frame and must change the channel message itself, at a minimum 665 complementing the NA flag in the Channel Header and making 666 appropriate MAC address changes. 668 An erroneous native channel message results in a native RBridge 669 channel error message under the same conditions for which an TRILL 670 Data RBridge Channel message would result in a TRILL Data RBridge 671 channel error message. However, in a native RBridge Channel error 672 message, the NA flag MUST be one. Also, since there is no TRILL 673 Header in native RBridge Channel protocol frames, the beginning part 674 of the frame in which the error was detected that is included in 675 native RBridge Channel error frames starts with the RBridge Channel 676 Header (including the RBridge-Channel Ethertype). The destination MAC 677 address of such error messages is set to the source MAC address of 678 the native RBridge Channel message that was in error. 680 There is no mechanism to stop end stations from exchanging native 681 RBridge Channel messages but such usage is beyond the scope of this 682 document. 684 5. Indicating Support for RBridge Channel Protocols 686 Support for RBridge Channel protocols is indicated by the presence of 687 one or more TLVs and/or sub-TLVs in an RBridge's LSP as documented in 688 [RFC6326bis]. 690 RBridge Channel protocols 0 and 0xFFF are reserved and protocol 1, 691 the RBridge Channel error protocol, MUST be implemented as part of 692 the RBridge Channel feature. Thus, if an RBridge supports the RBridge 693 Channel feature, it should be advertising support for protocol 1 and 694 not advertising support for protocols 0 or 0xFFF in its LSP. 695 However, indication of support or non-support for RBridge Channel 696 protocol 1 is ignored on receipt and support for it is always 697 assumed, if support for any RBridge Channel is indicated in the 698 RBridge's LSP. 700 6. Allocation Considerations 702 The following subsections give IANA and IEEE allocation 703 considerations. In this document, the allocation procedure 704 specifications are as defined in [RFC5226]. 706 6.1 IANA Considerations 708 IANA is requested to allocate a previously unassigned TRILL Nickname 709 as follows: 711 Any-RBridge TBD (0xFFCO suggested) 713 IANA is requested to add "All-Egress-RBridges" to the TRILL Parameter 714 Registry as an alternative name for the "All-ESADI-RBridges" 715 multicast address. 717 IANA is requested to allocate two previously unassigned TRILL 718 Multicast address as follows: 720 TRILL-End-Stations TBD (01-80-C2-00-00-45 suggested) 721 All-Edge-RBridges TBD (01-80-C2-00-00-46 suggested) 723 IANA is requested to create an additional sub-registry in the TRILL 724 Parameter Registry for RBridge Channel Protocols, with initial 725 contents as follows: 727 Protocol Description Reference 728 -------- ----------- --------- 730 0x000 Reserved, not to be allocated (This document) 731 0x001 RBridge Channel Error (This document) 732 0x002-0x0FF Available (1) 733 0x100-0xFF7 Available (2) 734 0xFF8-0xFFE Private Use 735 0xFFF Reserved, not to be allocated (This document) 737 (1) RBridge Channel protocol code points from 0x002 to 0x0FF require 738 a Standards Action, as modified by [RFC4020], for allocation. 740 (2) RBridge Channel protocol code points from 0x100 to 0xFF7 are RFC 741 Required to allocate a single value or IESG Approval to allocate 742 multiple values. 744 IANA is requested to create an additional sub-registry in the TRILL 745 Parameter Registry for RBridge Channel Header Flags with initial 746 contents as follows: 748 Flag Bit Mnemonic Allocation 749 -------- -------- ---------- 751 0 SL Silent 752 1 MH Multi-hop 753 2 NA Native 754 3-11 - Available for allocation 756 Allocation of an RBridge Channel Header Flag is based on IETF Review. 758 IANA is requested to create an additional sub-registry in the TRILL 759 Parameter Registry for RBridge Channel Error codes with initial 760 contents as listed in Section 3.2 above and with available values 761 allocated by Standards Action as modified by [RFC4020]. 763 6.2 IEEE Registration Authority Considerations 765 The IEEE Registration Authority has assigned the Ethertype for 766 RBridge-Channel. 768 7. Security Considerations 770 No general integrity, authentication, or encryption mechanisms are 771 provided herein for RBridge Channel messages. If these services are 772 required for a particular RBridge Channel protocol, they MUST be 773 supplied by that channel protocol. See, for example, the BFD 774 Authentication mechanism [RFC5880]. 776 See [RFC6325] for general TRILL Security Considerations. As stated 777 therein, no protection is provided by TRILL against forging of the 778 ingress nickname in a TRILL Data formatted channel message or the 779 Outer.MacSA in a native RBridge Channel frame on an Ethernet link. 780 This may result in misdirected return responses or error messages. 781 However, link level security protocols may be used to authenticate 782 the origin station on a link and protect against attacks on links. 783 See also Section 2.4 above concerning congestion. 785 If indication of RBridge Channel Protocol support are improperly 786 absent from an RBridge's LSP, it could deny all RBridge Channel 787 services, for example some BFD services, for the RBridge in question. 788 If a particular RBridge channel protocol is incorrectly not 789 advertised as supported, it could deny the service of that channel 790 protocol to the RBridge in question. 792 Incorrect presence of indication of RBridge Channel Protocol support 793 or incorrect assertion of support for a channel protocol could 794 encourage RBridge channel messages to be sent to an RBridge that does 795 not support the channel feature or the particular channel protocol 796 used. The inner frame of such messages could be decapsulated and that 797 inner frame could be sent out all ports that are appointed forwarders 798 for the frame's Inner.VLAN. However, this is unlikely to cause much 799 harm; in particular, there are two possibilities as follows: (a) If 800 end stations do not recognize the RBridge-Channel Ethertype of the 801 frame, they will drop it. (b) If end stations do recognize the 802 RBridge-Channel Ethertype and the channel protocol indicated in the 803 frame, they should refuse to process the frame due to an incorrect 804 value of the RBridge Channel Header NA flag. 806 8. References 808 The following sections list normative and informative references for 809 this document. 811 8.1 Normative References 813 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 814 Intermediate System Intra-Domain Routing Exchange Protocol for 815 use in Conjunction with the Protocol for Providing the 816 Connectionless-mode Network Service (ISO 8473)", 2002. 818 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 819 dual environments", RFC 1195, December 1990. 821 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, March 1997 824 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 825 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 827 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 828 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 829 2008. 831 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 832 Ghanwani, "Routing Bridges (RBridges): Base Protocol 833 Specification", RFC 6325, July 2011. 835 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 836 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 837 6327, July 2011. 839 [RFCext] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. Bestler, 840 "TRILL: TRILL Header Extension", draft-ietf-trill-rbridge- 841 extension, work in progress. 843 [RFC6326bis] - Eastlake, D., A. Banerjee, D. Dutt, A. Ghanwani, R. 844 Perlman, "TRILL Use of IS-IS", draft-eastlake-isis-rfc6326bis, 845 work in progress. 847 8.2 Informative References 849 [RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 850 Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 851 5082, October 2007 853 [RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 854 "MPLS Generic Associated Channel", RFC 5586, June 2009. 856 [RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection 857 (BFD)", June 2010. 859 [RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional 860 Forwarding Detection (BFD)", June 2010. 862 [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V. 863 Manral, "TRILL: Clarifications, Corrections, and Updates", 864 draft-ietf-trill-clear-correct, work in progress. 866 Appendix: Change History 868 RFC Editor: please delete this appendix before publication. 870 Changes from -00 to -01 872 1. Spell out more acronyms. 874 2. Add reference to "Guidelines for the Use of OAM" draft. 876 3. Move definition of Alert flag to draft-ietf-trill-rbridge-options 877 and refer to it as an extended header flag. 879 4. Change name of "Egress-RBridges" multicast address to "All-Egress- 880 RBridges". Merge with All-ESADI-RBridges (i.e., they are two names 881 for the same MAC address). 883 5. Add detailed bit vector description for indicating support of 884 RBridge channel protocols. Add GENAPP and an APPsub-TLV to hold 885 one or more bit vectors. 887 6. Assorted editorial changes. 889 Changes from -01 to -02 891 1. Update for drafts that have been issued as RFCs. 893 2. Change to specification of Inner.VLAN in RBridge channel messages. 895 3. Remove GENAPP and move RBridge Channels supported information to 896 another document. 898 4. Clarify native RBridge Channel error messages. 900 5. Assorted editorial changes. 902 Changes from -02 to -03 904 1. Liberalize restrictions on RBridge acceptance of native RBridge 905 Channel messages. These are typically messages and should 906 generally be accepted unless in a VLAN not enabled at the port or 907 the like. 909 2. Change multi-cast address used by end stations in sending a native 910 RBridge Channel message to all RBridges on the link from All- 911 Egress-RBridges to All-Edge-RBridges to avoid possible confusion 912 if such a frame were encapsulated resulting in an All-Egress- 913 RBridges Inner.MacDA. 915 3. Reword references to "two-hop echo" and the like for clarity. 916 (This meant an echo frame that went to an immediate neighbor and 917 back.) 919 4. Add reference to and move some material to the RFC 6326bis draft. 921 5. Assorted editorial changes. 923 Changes from -03 to -04 925 1. Update for the replacement of the CFI bit by the DEI bit (see 926 [ClearCorrect]). 928 2. Update for the existence of both critical and non-critical RBridge 929 Channel alert flags. 931 3. Update author information. 933 4. Assorted editorial changes. 935 Changes from -04 to -05 937 1. Clarify the distinction between native and non-native RBridge 938 Channel messages and that native channel messages are only 939 intended to be transmitted between RBridge and end stations on the 940 same link. 942 2. Add a paragraph to the Security Considerations section about 943 forged ingress nicknames / source MAC addresses in channel 944 messages. 946 3. Add acknowledgements section. 948 4. Replace "OAM" references with "BFD" references in Abstract and 949 Introduction. 951 5. Very minor editorial changes. 953 Changes from -05 to -06 955 1. Improve wording in 2.1.1 re CHV values. 957 2. Revert "Ext-Len" to "Op-Len". 959 3. Fix typos and make minor editorial changes. 961 Changes from -06 to -07 963 1. Add bit numbers at top of figures where they were missing. 965 2. Add figure numbers and captions. 967 3. Add text to Section 2.1.1 concerning Private Use RBridge Channel 968 protocol numbers. 970 4. Change IANA Considerations for the allocation of multiple RBridge 971 Channel protocol numbers in the 0x100 to 0xFF7 range from IETF 972 Review to IESG Approval. 974 5. Add text that the intended use for ERR code 15 is for some future 975 error code expansion feature should more error codes be required 976 and indicate that protocol numbers 0x000 and 0xFFF are not to be 977 allocated. 979 6. Captialize the first occurrence of "must" in Section 7. 981 7. Add statement that directly connected end-stations are not blocked 982 from communicating with each other using channel messages but such 983 messages are beyond the scope of this document. 985 8. Re-order and add some references to the Securty Considertions 986 section. 988 9. Typo fixes and various editorial changes. 990 Acknowledgments 992 The authors gratefully acknowledge the comments and contributions of 993 the follows, listed is alphabetic order: Stewart Bryant, Somnath 994 Chatterjee, Adrian Farrel, Stephen Farrell, Miguel A. Garcia, Anoop 995 Ghanwani, Brian Haberman, Rakesh Kumar, Barry Leiba, and Tissa 996 Senevirathne. 998 This document was prepared with raw nroff. All macros used were 999 defined in the document source files. 1001 Authors' Addresses 1003 Donald Eastlake 3rd 1004 Huawei R&D USA 1005 155 Beaver Street 1006 Milford, MA 01757 USA 1008 Tel: +1-508-333-2270 1009 EMail: d3e3e3@gmail.com 1011 Vishwas Manral 1012 HP Networking 1013 19111 Pruneridge Avenue 1014 Cupertino, CA 95014 USA 1016 Tel: +1-408-477-0000 1017 EMail: vishwas.manral@hp.com 1019 Yizhou Li 1020 Huawei Technologies 1021 101 Software Avenue, 1022 Nanjing 210012, China 1024 Phone: +86-25-56622310 1025 Email: liyizhou@huawei.com 1027 Sam Aldrin 1028 Huawei Technologies 1029 2330 Central Expressway 1030 Santa Clara, CA 95050 USA 1032 Phone: +1-408-330-5000 1033 Email: sam.aldrin@huawei.com 1034 Dave Ward 1035 Cisco Systems 1036 170 W. Tasman Drive 1037 San Jose, CA 95134 USA 1039 EMail: dward@cisco.com 1041 Copyright, Disclaimer, and Additional IPR Provisions 1043 Copyright (c) 2012 IETF Trust and the persons identified as the 1044 document authors. All rights reserved. 1046 This document is subject to BCP 78 and the IETF Trust's Legal 1047 Provisions Relating to IETF Documents 1048 (http://trustee.ietf.org/license-info) in effect on the date of 1049 publication of this document. Please review these documents 1050 carefully, as they describe your rights and restrictions with respect 1051 to this document. Code Components extracted from this document must 1052 include Simplified BSD License text as described in Section 4.e of 1053 the Trust Legal Provisions and are provided without warranty as 1054 described in the Simplified BSD License. The definitive version of 1055 an IETF Document is that published by, or under the auspices of, the 1056 IETF. Versions of IETF Documents that are published by third parties, 1057 including those that are translated into other languages, should not 1058 be considered to be definitive versions of IETF Documents. The 1059 definitive version of these Legal Provisions is that published by, or 1060 under the auspices of, the IETF. Versions of these Legal Provisions 1061 that are published by third parties, including those that are 1062 translated into other languages, should not be considered to be 1063 definitive versions of these Legal Provisions. For the avoidance of 1064 doubt, each Contributor to the IETF Standards Process licenses each 1065 Contribution that he or she makes as part of the IETF Standards 1066 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1067 language to the contrary, or terms, conditions or rights that differ 1068 from or are inconsistent with the rights and licenses granted under 1069 RFC 5378, shall have any effect and shall be null and void, whether 1070 published or posted by such Contributor, or included with or in such 1071 Contribution.