idnits 2.17.1 draft-ietf-trill-rbridge-channel-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 15, 2012) is 4364 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) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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: November 14, 2012 May 15, 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 Acknowledgments...........................................25 82 Authors' Addresses........................................25 84 1. Introduction 86 RBridge campuses provide transparent least-cost path forwarding using 87 the TRILL (TRansparent Interconnection of Lots of Links) protocol 88 that builds on IS-IS (Intermediate System to Intermediate System) 89 routing [IS-IS] [RFC1195] [RFC6326bis]. Devices that implement TRILL 90 are called RBridges (Routing Bridges) or TRILL Switches. However, the 91 TRILL base protocol standard [RFC6325] provides only for TRILL Data 92 messages and TRILL IS-IS messages. 94 This document specifies a general channel mechanism for the 95 transmission of other messages within an RBridge campus, such as BFD 96 (Bidirectional Forwarding Detection, [RFC5880]) messages, (1) between 97 RBridges and end stations that are directly connected on the same 98 link and (2) between RBridges. This mechanism supports a requirement 99 to be able to operate with minimal configuration. 101 Familiarity with [RFC6325] and [RFC6327] is assumed in this document. 103 1.1 RBridge Channel Requirements 105 It is anticipated that various protocols operating at the TRILL level 106 will be desired in RBridge campuses. For example, there is a need for 107 rapid response continuity checking with a protocol such as BFD 108 [RFC5880] [RFC5882] and for a variety of optional reporting. 110 To avoid the requirement to design and specify a way to carry each 111 such protocol, this document specifies a general channel for sending 112 messages between RBridges in a campus at the TRILL level by extending 113 the TRILL protocol. To accommodate a wide variety of protocols, this 114 RBridge Channel facility accommodates all the regular modes of TRILL 115 Data transmission including single and multiple hop unicast as well 116 as VLAN scoped multi-destination distribution. 118 To minimize any unnecessary burden on transit RBridges and to provide 119 a more realistic test of network continuity and the like, RBridge 120 Channel messages are designed to look like TRILL Data frames and, in 121 the case of multi-hop messages, can normally be handled by transit 122 RBridges as if they were TRILL Data frames; however, to enable 123 processing at transit RBridges when required by particular messages, 124 they may optionally use the RBridge Channel Alert TRILL extended 125 header flags [RFCext] that causes a transit RBridge implementing the 126 flag to more closely examine a flagged frame. 128 This document also specifies a format for sending RBridge Channel 129 messages between RBridges and end stations that are directly 130 connected over a link, in either direction, when provided for by the 131 protocol involved. For the most part, this format is the same as the 132 format that is TRILL Data encapsulated for inter-RBridge channel 133 messages. 135 Each particular protocol using the RBridge Channel facility will 136 likely use only a subset of the facilities specified herein. 138 1.2 Relation to the MPLS Generic Channel 140 The RBridge Channel is similar to the MPLS Generic Channel specified 141 in [RFC5586]. Instead of using a special MPLS label to indicate a 142 special channel message, an RBridge Channel message is indicated by a 143 special multicast Inner.MacDA and inner Ethertype. 145 1.3 Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 The terminology and acronyms of [RFC6325] are used in this document 152 with the additions listed below. 154 BFD - Bidirectional Forwarding Detection 156 CHV - Channel Header Version 158 MH - Multi-Hop 160 NA - Native 162 SL - Silent 164 2. Inter-RBridge Channel Messages 166 Channel messages between RBridges are transmitted as TRILL Data 167 frames. (For information on channel messages that can be transmitted 168 between RBridges and end stations that are directly connected by a 169 link, see Section 4.) Inter-RBridge Channel messages are identified 170 as such by their Inner.MacDA, which is the All-Egress-RBridges 171 multicast address, together with their Inner Ethertype, which is the 172 RBridge-Channel Ethertype. This Ethertype is part of and starts the 173 RBridge Channel Header. 175 The diagram below shows the overall structure of a RBridge Channel 176 Message frame on a link between two RBridges: 178 Frame Structure Section of This Document 179 ------------------------ 180 +--------------------------------+ 181 | Link Header | Section 2.3 if Ethernet Link 182 +--------------------------------+ 183 | TRILL Header | Section 2.2 184 +--------------------------------+ 185 | Inner Ethernet Header | Section 2.1.2 186 +--------------------------------+ 187 | RBridge Channel Header | Section 2.1.1 188 +--------------------------------+ 189 | Protocol Specific Payload | See specific channel protocol 190 +--------------------------------+ 191 | Link Trailer (FCS if Ethernet) | 192 +--------------------------------+ 194 Optionally, some channel messages may require examination of the 195 frame by transit RBridges that support the RBridge Channel feature, 196 to determine if they need to take any action. To indicate this, such 197 messages use a RBridge Channel Alert extended TRILL header flag as 198 further described in Section 3 below. 200 The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL 201 Header for frames sent in an RBridge Channel. As always, the Outer 202 link header and trailer are whatever is needed to get a TRILL Data 203 frame to the next hop RBridge, depending on the technology of the 204 link, and can change with each hop for multi-hop messages. Section 205 2.3 describes the outer Link Header for Ethernet. And Section 2.4 206 discusses some special considerations for the first hop transmission 207 of RBridge Channel messages. 209 Section 3 describes some details of RBridge Channel message 210 processing. Section 4 provides the specifications for native RBridge 211 Channel frames between RBridges and end stations that are directly 212 connected over a link. 214 2.1 The RBridge Channel Message Inner Frame 216 The encapsulated inner frame within an RBridge Channel message frame 217 is as shown below. 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 The Channel Protocol Specific Data contains the information related 242 to the specific channel protocol used in the channel message. Details 243 of that data are outside the scope of this document, except in the 244 case of the RBridge Channel Error protocol specified below. 246 2.1.1 RBridge Channel Header 248 As shown in the diagram above, the RBridge Channel header starts with 249 the RBridge-Channel Ethertype (see Section 6.2). Following that is a 250 four-byte quantity with four sub-fields as follows: 252 CHV: A 4-bit field that gives the RBridge Channel Header Version. 253 This document species version zero. 255 Channel Protocol: A 12-bit unsigned integer that specifies the 256 particular RBridge Channel protocol to which the message 257 applies. 259 Flags: Provides 12 bits of flags described below. 261 ERR: A 4-bit unsigned integer used in connection with error 262 reporting at the RBridge Channel level as described in 263 Section 3. 265 The flag bits are numbered from 0 to 11 as shown below. 267 0 1 2 3 4 5 6 7 8 9 10 11 268 +--+--+--+--+--+--+--+--+--+--+--+--+ 269 |SL|MH|NA| Reserved | 270 +--+--+--+--+--+--+--+--+--+--+--+--+ 272 Bit 0, which is the high order bit in network order, is defined as 273 the SL or Silent bit. If it is a one, it suppresses RBridge 274 Channel Error messages (see Section 3). 276 Bit 1 is the MH or Multi-Hop bit. It is used to inform the 277 destination RBridge protocol that the message may be multi-hop 278 (MH=1) or was intended to be one-hop only (MH=0). 280 Bit 2 is the NA or Native bit. It is used as described in Section 4 281 below. 283 Reserved: Bits reserved for future specification that MUST be sent as 284 zero and ignored on receipt. 286 The RBridge Channel Protocol field specifies the protocol that the 287 channel message relates to. The initial defined value is listed 288 below. See Section 6 for IANA Considerations. 290 Protocol Name - Section of this Document 291 -------- ------------------------------- 293 0x001 RBridge Channel Error - Section 3 295 2.1.2 Inner Ethernet Header 297 The special Inner.MacDA is the All-Egress-RBridges multicast MAC 298 address to signal that the frame is intended for the egress 299 (decapsulating) RBridge itself (or the egress RBridges themselves if 300 the frame is multi-destination). (This address is called the All- 301 ESADI-RBridges address in [RFC6325].) The RBridge-Channel Ethertype 302 indicates that the frame is an RBridge Channel message. The only 303 other Ethertype currently specified for use with the All-Egress- 304 RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI frame 305 [RFC6325]. In the future additional Ethertypes may be specified for 306 use with the All-Egress-RBridges multicast address. 308 The RBridge originating the channel message selects the Inner.MacSA. 310 The Inner.MacSA MUST be set by the originating RBridge to a MAC 311 address unique within the campus owned by the originating RBridge. 312 This MAC address can be considered, in effect, the MAC address of a 313 virtual internal end station that handles the RBridge Channel frames 314 originated by or destined for that RBridge. It MAY be the same as the 315 Inner.MacSA used by the RBridge when it originates ESADI frames 316 [RFC6325]. 318 2.1.3 Inner.VLAN Tag 320 As with all frames formatted to be processed as a TRILL Data frame, 321 an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than 322 0x8100 or stacked tags is beyond the scope of this document but is an 323 obvious extension. 325 Multi-destination RBridge Channel messages are, like all multi- 326 destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID 327 MUST be set to the VLAN of interest. To the extent that distribution 328 tree pruning is in effect in the campus, such channel messages may 329 only reach RBridges advertising that they have connectivity to that 330 VLAN. 332 For channel messages sent as known unicast TRILL Data frames the 333 default value for the Inner.VLAN ID is VLAN 1 but particular RBridge 334 Channel protocols MAY specify other values. 336 The Inner.VLAN also specifies a three-bit frame priority for which 337 the following recommendations apply: 339 1. For one-hop channel messages critical to network connectivity, 340 such as one-hop BFD for rapid link failure detection in support 341 of TRILL IS-IS, the RECOMMENDED priority is 7. 343 2. For single and multi-hop known unicast channel messages 344 important to network operation but not critical for 345 connectivity, the RECOMMENDED priority is 6. 347 3. For other known unicast channel messages and all multi- 348 destination channel messages, it is RECOMMENDED that the 349 default priority zero be used. In any case, priorities higher 350 than 5 SHOULD NOT be used for such frames. 352 There is one additional bit in a VLAN tag value between the 12-bit 353 VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI, 354 [ClearCorrect]). It is RECOMMENDED that this bit be zero for the 355 first two categories of channel messages listed immediately above. 356 The setting of this bit for channel messages in the third category 357 may be dependent on the channel protocol and no general 358 recommendation is made for that case. 360 2.2 The TRILL Header for RBridge Channel Messages 362 After the outer Link Header (that, for Ethernet, ends with the TRILL 363 Ethertype) and before the encapsulated frame, the channel message's 364 TRILL Header initially appears as follows: 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 |V=0| R |M| Op-Len | Hop Count | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Egress Nickname | Ingress Nickname | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 The TRILL Header version V MUST be zero, the R bits are reserved, the 373 M bit is set appropriately as the channel message is to be forwarded 374 as known unicast (M=0) or multi-destination (M=1) regardless of the 375 fact that the Inner.MacDA is always the All-Egress-RBridges multicast 376 address, and Op-Len is set appropriately for the length of the TRILL 377 Header extensions area, if any, all as specified in [RFC6325]. 379 When an RBridge Channel message is originated, the Hop Count field 380 defaults to the maximum value, 0x3F, but particular RBridge Channel 381 protocols MAY specify other values. For messages sent a known number 382 of hops, such as one-hop messages or a two-hop self-addressed message 383 intended to loop back through an immediate neighbor RBridge, setting 384 the Hops field to the maximum value and checking the Hop Count field 385 on receipt provides an additional validity check as discussed in 386 [RFC5082]. 388 The RBridge originating a channel message places a nickname that it 389 holds into the ingress nickname field. 391 There are several cases for the egress nickname field. If the channel 392 message is multi-destination, then the egress nickname designates the 393 distribution tree to use. If the channel message is a multi-hop 394 unicast message, then the egress nickname is a nickname of the target 395 RBridge; this includes the special case of a message intended to loop 396 back from an immediate neighbor where the originator places one of 397 its own nicknames in both the ingress and egress nickname fields. If 398 the channel message is a one-hop unicast message, there are two 399 possibilities for the egress nickname. 401 o The egress nickname can be set to a nickname of the target 402 neighbor RBridge. 404 o The special nickname Any-RBridge may be used. RBridges supporting 405 the RBridge Channel facility MUST recognize the Any-RBridge 406 special nickname and accept TRILL Data frames having that value in 407 the egress nickname field as being sent to them as the egress. 408 Thus, for such RBridges, using this egress nickname guarantees 409 processing by an immediate neighbor regardless of the state of 410 nicknames. 412 2.3 Ethernet Link Header and Trailer 414 An RBridge Channel frame has the usual link header and trailer for a 415 TRILL Data frame depending on the type of link on which it is sent. 417 For an Ethernet link [RFC6325] the Outer.MacSA is the MAC address of 418 the port from which the frame is sent. The Outer.MacDA is the MAC 419 address of the next-hop RBridge port for unicast RBridge Channel 420 messages or the All-RBridges multicast address for multi-destination 421 RBridge Channel messages. The Outer.VLAN tag specifies the Designated 422 VLAN for that hop and the priority should be the same as in the 423 Inner.VLAN tag; however, the output port may have been configured to 424 strip VLAN tags, in which case no Outer.VLAN tag appears on the wire. 425 And the link trailer is the Ethernet FCS. 427 2.4 Special Transmission and Rate Considerations 429 If a multi-hop RBridge Channel message is received by an RBridge, the 430 criteria and method of forwarding it are the same as for any TRILL 431 Data frame. If it is so forwarded, it will be on a link that was 432 included in the routing topology because it was in the Report state 433 as specified in [RFC6327]. 435 However, special considerations apply to single hop messages because, 436 for some RBridge Channel protocols, it may be desirable to send 437 RBridge Channel messages over a link that is not yet fully up. In 438 particular, it is permissible, if specified by the particular channel 439 protocol, for the source RBridge that has created an RBridge Channel 440 message to attempt to transmit it to a next hop RBridge when the link 441 is in the Detect or Two-Way states, as specified in [RFC6327], as 442 well as when it is in the Report state. Such messages can also be 443 sent on point-to-point links that are not in the Up state. 445 RBridge Channel messages represent a burden on the RBridges and links 446 in a campus and should be rate limited, especially if they are sent 447 as high priority, multi-destination, or multi-hop frames or have an 448 RBridge Channel Alert extended header flag set. 450 3. Processing RBridge Channel TRILL Data Messages 452 RBridge Channel TRILL Data messages are designed to look like and, to 453 the extent practical, be forwarded as regular TRILL Data frames. On 454 receiving a channel message, the initial tests on the Outer.MacDA, 455 Outer Ethertype, TRILL Header V and Hop Count fields and the Reverse 456 Path Forwarding Check if the frame is multi-destination, are all 457 performed as usual. The forwarding and/or decapsulation decisions are 458 the same as for a regular TRILL Data frame with following exceptions 459 for RBridges implementing the RBridge Channel facility: 461 1. An RBridge implementing the RBridge Channel facility MUST 462 recognize the Any-RBridge egress nickname in TRILL Data frames, 463 decapsulating such frames if they meet other checks. (Such a 464 frame cannot be a valid multi-destination frame because the 465 Any-RBridge nickname is not a valid distribution tree root.) 467 2. If an RBridge Channel Alert extended header flag is set, then 468 the RBridge MUST process the RBridge Channel message as 469 described below even if it is not egressing the frame. If it is 470 egressing the frame, then no additional processing beyond 471 egress processing is needed even if an RBridge Channel Alert 472 flag is set. 474 3. On decapsulation, the special Inner.MacDA value of All-Egress- 475 RBridges MUST be recognized to trigger checking the 476 Inner.Ethertype and processing as an RBridge Channel message if 477 that Ethertype is RBridge-Channel. 479 RBridge Channel messages SHOULD only be sent to RBridges that 480 advertise support for the channel protocol involved as described in 481 Section 5. 483 All RBridges supporting the RBridge Channel facility MUST recognize 484 the RBridge-Channel inner Ethertype. 486 3.1 Processing the RBridge Channel Header 488 Knowing that it has an RBridge Channel message, the egress RBridge, 489 and any transit RBridge if an RBridge Channel Alert bit is set in the 490 TRILL Header, looks at the CHV (RBridge Channel Header Version) and 491 Channel Protocol fields. 493 If any of the following conditions occur at an egress RBridge, the 494 frame is not processed, an error may be generated as specified in 495 Section 3.2, and the frame is discarded. The behavior is the same if 496 the frame is being processed at a transit RBridge because the 497 critical RBridge Channel Alert flag is set [RFCext]. However, if 498 these conditions are detected at a transit RBridge examining the 499 message because the non-critical RBridge Channel Alert flag is set 500 [RFCext] but the critical flag is not set, no error is generated and 501 the frame is still forwarded normally. 503 Error Conditions: 505 1. The Ethertype is not RBridge-Channel and not any other 506 Ethertype known to the RBridge as usable with the All-Egress- 507 RBridges Inner.MacDA, or the frame is so short that the 508 Ethertype is truncated. 510 2. The CHV field is non-zero or the frame is so short that the 511 version zero Channel Header is truncated. 513 3. The Channel Protocol field is a reserved value or a value 514 unknown to the processing RBridge. 516 4. The ERR field is non-zero and Channel Protocol is a value other 517 than 0x001. 519 5. The RBridge Channel Header NA flag is set to one indicating 520 that the frame should have been received as a native frame 521 rather than a TRILL Data frame. 523 If the CHV field and NA flag are zero and the processing RBridge 524 recognizes the Channel Protocol value, it processes the message in 525 accordance with that channel protocol. The processing model is as if 526 the received frame starting with and including the TRILL Header is 527 delivered to the Channel protocol along with a flag indicating 528 whether this is (a) transit RBridge processing due to an RBridge 529 Channel Alert flag being set or (b) egress processing. 531 Errors within a recognized Channel Protocol are handled by that 532 channel protocol itself and do not produce RBridge Channel Error 533 frames. 535 3.2 RBridge Channel Errors 537 A variety of problems at the RBridge Channel level cause the return 538 of an RBridge Channel Error frame unless one of the following apply: 539 (a) the "SL" (Silent) flag is a one in the channel message for which 540 the problem was detected, (b) the processing is due to the non- 541 critical RBridge Channel Alert bit being set, (c) the frame in error 542 appears, itself, to be an RBridge Channel error frame (has a non-zero 543 ERR field or a Channel Protocol of 0x001), or (d) the error is 544 suppressed due to rate limiting. 546 An RBridge Channel Error frame is a multi-hop unicast RBridge Channel 547 message with the ingress nickname set to the nickname of the RBridge 548 detecting the error, and the egress nickname set to the value of the 549 ingress nickname in the channel message for which the error was 550 detected. No per-hop transit processing is specified for such error 551 frames, so the RBridge Channel Alert extended header flags SHOULD, if 552 an extension is present, be set to zero. The SL and MH flags SHOULD 553 be set to one, the NA flag MUST be zero, and the ERR field MUST be 554 non-zero as described below. For the protocol specific data area, an 555 RBridge Channel Message Error frame has at least the first 256 bytes 556 (or less if less are available) of the erroneous decapsulated channel 557 message starting with the TRILL Header. (Note: The TRILL Header does 558 not include the TRILL Ethertype that is part of the Link Header on 559 Ethernet Links.) 561 The following values for ERR are specified: 563 ERR Meaning 564 --- ------- 565 0 - Not an RBridge Channel error frame. 566 1 Frame too short (truncated Ethertype or RBridge Channel Header) 567 2 Unrecognized Ethertype 568 3 Unimplemented value of CHV 569 4 Wrong value of NA flag 570 5 Channel Protocol is reserved or unimplemented 571 6-14 - Available for allocation, see Section 6. 572 15 Reserved 574 All RBridges implementing the RBridge Channel feature MUST recognize 575 the RBridge Channel Error protocol value (0x001). They MUST NOT 576 generate an RBridge Channel Error message in response to a RBridge 577 Channel Error message, that is, a channel message with a protocol 578 value of 0x001 or with a non-zero ERR field. 580 4. Native RBridge Channel Frames 582 Other sections of this document specify non-native RBridge Channel 583 messages and their processing, that is, RBridge Channel messages 584 formatted as TRILL Data frames and sent between RBridges. This 585 section specifies the differences for native RBridge Channel 586 messages. 588 If provided for by the channel protocol involved, native RBridge 589 channel messages may be sent between end-stations and RBridges that 590 are directly connected over a link, in either direction. On an 591 Ethernet link, such native frames have the RBridge-Channel Ethertype 592 and are like the encapsulated frame inside an RBridge Channel message 593 except as follows: 595 1. TRILL does not require the presence of a VLAN tag on such 596 native RBridge channel frames. However, port configuration, 597 link characteristics, or the channel protocol involved may 598 require such tagging. 600 2. If the frame is unicast, the destination MAC address is the 601 unicast MAC address of the RBridge or end-station port that is 602 its intended destination. If the frame is multicast by an end 603 station to all the RBridges on a link that support an RBridge 604 Channel protocol that uses this transport, the destination MAC 605 address is the All-Edge-RBridges multicast address (see Section 606 6). A native RBridge Channel frame received at an ingress 607 RBridge with a destination MAC address that is a unicast 608 address different from that of the port or multicast address 609 different from All-Edge-RBridges, is discarded. If the frame is 610 multicast by an RBridge to all the devices that TRILL considers 611 to be end stations on a link that support an RBridge Channel 612 protocol that uses this transport, the destination MAC address 613 is the TRILL-End-Stations multicast address (see Section 6). A 614 native RBridge Channel frame received at an end station with a 615 destination MAC address that is a unicast address different 616 from that of the port or multicast address different from 617 TRILL-End-Stations, is discarded. 619 3. The RBridge-Channel outer Ethertype must be present. In the 620 future there may be other protocols using the All-Edge-RBridges 621 and/or TRILL-End-Stations multicast addresses on native frames 622 distinguished by different Ethertypes. 624 4. The NA or native bit in the RBridge Channel Header flags must 625 be a one. 627 5. There might be additional tags present between the Outer.MacDA, 628 Outer.MacSA pair and the RBridge-Channel Ethertype. 630 The RBridge Channel protocol number space for native RBridge Channel 631 messages and TRILL Data formatted RBridge Channel messages is the 632 same. If provided for by the channel protocol involved, the receipt 633 of a native RBridge Channel frame MAY lead to the generation and 634 transmission of one or more Inter-RBridge Channel frames. The 635 decapsulation and processing of a TRILL Data RBridge Channel frame 636 MAY, if provided for by the channel protocol involved, result in the 637 sending of one or more native RBridge channel frames to one or more 638 end stations. Thus, there could be an RBridge Channel protocol that 639 involved an RBridge Channel message sent from an origin RBridge where 640 the message is created, through one or more transit RBridges and from 641 the last as a native RBridge channel message to and end station or 642 the reverse of such a path; however, to do this the RBridge channel 643 protocol involved must be implemented at the RBridge where the 644 channel message is changed between a native frame and a TRILL Data 645 format frame and must change the channel message itself, at a minimum 646 complementing the NA flag in the Channel Header and making 647 appropriate MAC address changes. 649 An erroneous native channel message results in a native RBridge 650 channel error message under the same conditions for which an TRILL 651 Data RBridge Channel message would result in a TRILL Data RBridge 652 channel error message. However, in a native RBridge Channel error 653 message, the NA flag MUST be one. Also, since there is no TRILL 654 Header in native RBridge Channel protocol frames, the beginning part 655 of the frame in which the error was detected that is included in 656 native RBridge Channel error frames starts with the RBridge Channel 657 Header (including the RBridge-Channel Ethertype). The destination MAC 658 address of such error messages is set to the source MAC address of 659 the native RBridge Channel message that was in error. 661 5. Indicating Support for RBridge Channel Protocols 663 Support for RBridge Channel protocols is indicated by the presence of 664 one or more TLVs and/or sub-TLVs in an RBridge's LSP as documented in 665 [RFC6326bis]. 667 RBridge Channel protocols 0 and 0xFFF are reserved and protocol 1, 668 the RBridge Channel error protocol, MUST be implemented as part of 669 the RBridge Channel feature. Thus, if an RBridge supports the RBridge 670 Channel feature, it should be advertising support for protocol 1 and 671 not advertising support for protocols 0 or 0xFFF in its LSP. 672 However, indication of support or non-support for RBridge Channel 673 protocol 1 is ignored on receipt and support for it is always 674 assumed, if support for any RBridge Channel is indicated in the 675 RBridge's LSP. 677 6. Allocation Considerations 679 The following subsections give IANA and IEEE allocation 680 considerations. In this document, the allocation procedure 681 specifications are as defined in [RFC5226]. 683 6.1 IANA Considerations 685 IANA is requested to allocate a previously unassigned TRILL Nickname 686 as follows: 688 Any-RBridge TBD (0xFFCO suggested) 690 IANA is requested to add "All-Egress-RBridges" to the TRILL Parameter 691 Registry as an alternative name for the "All-ESADI-RBridges" 692 multicast address. 694 IANA is requested to allocate two previously unassigned TRILL 695 Multicast address as follows: 697 TRILL-End-Stations TBD (01-80-C2-00-00-45 suggested) 698 All-Edge-RBridges TBD (01-80-C2-00-00-46 suggested) 700 IANA is requested to create an additional sub-registry in the TRILL 701 Parameter Registry for RBridge Channel Protocols, with initial 702 contents as follows: 704 Protocol Description Reference 705 -------- ----------- --------- 707 0x000 Reserved (This document) 708 0x001 RBridge Channel Error (This document) 709 0x002-0x0FF Available (1) 710 0x100-0xFF7 Available (2) 711 0xFF8-0xFFE Private Use 712 0xFFF Reserved (This document) 714 (1) RBridge Channel protocol code points from 0x002 to 0x0FF require 715 a Standards Action, as modified by [RFC4020], for allocation. 717 (2) RBridge Channel protocol code points from 0x100 to 0xFF7 require 718 RFC Publication to allocate a single value or IETF Review to allocate 719 multiple values. 721 IANA is requested to create an additional sub-registry in the TRILL 722 Parameter Registry for RBridge Channel Header Flags with initial 723 contents as follows: 725 Flag Bit Mnemonic Allocation 726 -------- -------- ---------- 728 0 SL Silent 729 1 MH Multi-hop 730 2 NA Native 731 3-11 - Available for allocation 733 Allocation of an RBridge Channel Header Flag is based on Standards 734 Action as modified by [RFC4020]. 736 IANA is requested to create an additional sub-registry in the TRILL 737 Parameter Registry for RBridge Channel Error codes with initial 738 contents as listed in Section 3.2 above and with available values 739 allocated by Standards Action as modified by [RFC4020]. 741 6.2 IEEE Registration Authority Considerations 743 The IEEE Registration Authority has assigned the Ethertype for 744 RBridge-Channel. 746 7. Security Considerations 748 See [RFC6325] for general TRILL Security Considerations. 750 No general integrity, authentication, or encryption mechanisms are 751 provided herein for RBridge Channel messages. If these services are 752 required for a particular RBridge Channel protocol, they must be 753 supplied by that channel protocol. See, for example, the BFD 754 Authentication mechanism [RFC5880]. 756 If indication of RBridge Channel Protocol support are improperly 757 absent from an RBridge's LSP, it could deny all RBridge Channel 758 services, for example some BFD services, for the RBridge in question. 759 If a particular RBridge channel protocol is incorrectly not 760 advertised as supported, it would deny the service of that channel 761 protocol to the RBridge in question. 763 Incorrect presence of indication of RBridge Channel Protocol support 764 or incorrect assertion of support for a channel protocol could 765 encourage RBridge channel messages to be sent to an RBridge that does 766 not support the channel feature or the particular channel protocol 767 used. The inner frame of such messages could be decapsulated and that 768 inner frame could be sent out all ports that are appointed forwarders 769 for the frame's Inner.VLAN. However, this is unlikely to cause much 770 harm; in particular, there are two possibilities as follows: (a) If 771 end stations do not recognize the RBridge-Channel Ethertype of the 772 frame, they will drop it. (b) If end stations do recognize the 773 RBridge-Channel Ethertype and the channel protocol indicated in the 774 frame, they should refuse to process the frame due to an incorrect 775 value of the RBridge Channel Header NA flag. 777 No protection is provided against forging of the ingress nickname in 778 a TRILL Data formatted channel message or the Outer.MacSA in a native 779 RBridge Channel frame. This may result in misdirected return 780 responses or error messages. 782 8. References 784 The following sections list normative and informative references for 785 this document. 787 8.1 Normative References 789 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 790 Intermediate System Intra-Domain Routing Exchange Protocol for 791 use in Conjunction with the Protocol for Providing the 792 Connectionless-mode Network Service (ISO 8473)", 2002. 794 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 795 dual environments", RFC 1195, December 1990. 797 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997 800 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 801 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 803 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 804 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 805 2008. 807 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 808 Ghanwani, "Routing Bridges (RBridges): Base Protocol 809 Specification", RFC 6325, July 2011. 811 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 812 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 813 6327, July 2011. 815 [RFCext] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. Bestler, 816 "TRILL: TRILL Header Extension", draft-ietf-trill-rbridge- 817 extension, work in progress. 819 [RFC6326bis] - Eastlake, D., A. Banerjee, D. Dutt, A. Ghanwani, R. 820 Perlman, "TRILL Use of IS-IS", draft-eastlake-isis-rfc6326bis, 821 work in progress. 823 8.2 Informative References 825 [RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 826 Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 827 5082, October 2007 829 [RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 830 "MPLS Generic Associated Channel", RFC 5586, June 2009. 832 [RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection 833 (BFD)", June 2010. 835 [RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional 836 Forwarding Detection (BFD)", June 2010. 838 [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V. 839 Manral, "TRILL: Clarifications, Corrections, and Updates", 840 draft-ietf-trill-clear-correct, work in progress. 842 Appendix: Change History 844 RFC Editor: please delete this appendix before publication. 846 Changes from -00 to -01 848 1. Spell out more acronyms. 850 2. Add reference to "Guidelines for the Use of OAM" draft. 852 3. Move definition of Alert flag to draft-ietf-trill-rbridge-options 853 and refer to it as an extended header flag. 855 4. Change name of "Egress-RBridges" multicast address to "All-Egress- 856 RBridges". Merge with All-ESADI-RBridges (i.e., they are two names 857 for the same MAC address). 859 5. Add detailed bit vector description for indicating support of 860 RBridge channel protocols. Add GENAPP and an APPsub-TLV to hold 861 one or more bit vectors. 863 6. Assorted editorial changes. 865 Changes from -01 to -02 867 1. Update for drafts that have been issued as RFCs. 869 2. Change to specification of Inner.VLAN in RBridge channel messages. 871 3. Remove GENAPP and move RBridge Channels supported information to 872 another document. 874 4. Clarify native RBridge Channel error messages. 876 5. Assorted editorial changes. 878 Changes from -02 to -03 880 1. Liberalize restrictions on RBridge acceptance of native RBridge 881 Channel messages. These are typically messages and should 882 generally be accepted unless in a VLAN not enabled at the port or 883 the like. 885 2. Change multi-cast address used by end stations in sending a native 886 RBridge Channel message to all RBridges on the link from All- 887 Egress-RBridges to All-Edge-RBridges to avoid possible confusion 888 if such a frame were encapsulated resulting in an All-Egress- 889 RBridges Inner.MacDA. 891 3. Reword references to "two-hop echo" and the like for clarity. 892 (This meant an echo frame that went to an immediate neighbor and 893 back.) 895 4. Add reference to and move some material to the RFC 6326bis draft. 897 5. Assorted editorial changes. 899 Changes from -03 to -04 901 1. Update for the replacement of the CFI bit by the DEI bit (see 902 [ClearCorrect]). 904 2. Update for the existence of both critical and non-critical RBridge 905 Channel alert flags. 907 3. Update author information. 909 4. Assorted editorial changes. 911 Changes from -04 to -05 913 1. Clarify the distinction between native and non-native RBridge 914 Channel messages and that native channel messages are only 915 intended to be transmitted between RBridge and end stations on the 916 same link. 918 2. Add a paragraph to the Security Considerations section about 919 forged ingress nicknames / source MAC addresses in channel 920 messages. 922 3. Add acknowledgements section. 924 4. Replace "OAM" references with "BFD" references in Abstract and 925 Introduction. 927 5. Very minor editorial changes. 929 Changes from -05 to -06 931 1. Improve wording in 2.1.1 re CHV values. 933 2. Revert "Ext-Len" to "Op-Len". 935 3. Fix typos and make minor editorial changes. 937 Acknowledgments 939 The authors gratefully acknowledge the comments and contributions of 940 the follows, listed is alphabetic order: Somnath Chatterjee, Anoop 941 Ghanwani, Rakesh Kumar, and Tissa Senevirathne. 943 Authors' Addresses 945 Donald Eastlake 3rd 946 Huawei R&D USA 947 155 Beaver Street 948 Milford, MA 01757 USA 950 Tel: +1-508-333-2270 951 EMail: d3e3e3@gmail.com 953 Vishwas Manral 954 HP Networking 955 19111 Pruneridge Avenue 956 Cupertino, CA 95014 USA 958 Tel: +1-408-477-0000 959 EMail: vishwas.manral@hp.com 961 Yizhou Li 962 Huawei Technologies 963 101 Software Avenue, 964 Nanjing 210012, China 966 Phone: +86-25-56622310 967 Email: liyizhou@huawei.com 969 Sam Aldrin 970 Huawei Technologies 971 2330 Central Expressway 972 Santa Clara, CA 95050 USA 974 Phone: +1-408-330-5000 975 Email: sam.aldrin@huawei.com 977 Dave Ward 978 Cisco Systems 979 170 W. Tasman Drive 980 San Jose, CA 95134 USA 981 EMail: dward@cisco.com 983 Copyright, Disclaimer, and Additional IPR Provisions 985 Copyright (c) 2012 IETF Trust and the persons identified as the 986 document authors. All rights reserved. 988 This document is subject to BCP 78 and the IETF Trust's Legal 989 Provisions Relating to IETF Documents 990 (http://trustee.ietf.org/license-info) in effect on the date of 991 publication of this document. Please review these documents 992 carefully, as they describe your rights and restrictions with respect 993 to this document. Code Components extracted from this document must 994 include Simplified BSD License text as described in Section 4.e of 995 the Trust Legal Provisions and are provided without warranty as 996 described in the Simplified BSD License. The definitive version of 997 an IETF Document is that published by, or under the auspices of, the 998 IETF. Versions of IETF Documents that are published by third parties, 999 including those that are translated into other languages, should not 1000 be considered to be definitive versions of IETF Documents. The 1001 definitive version of these Legal Provisions is that published by, or 1002 under the auspices of, the IETF. Versions of these Legal Provisions 1003 that are published by third parties, including those that are 1004 translated into other languages, should not be considered to be 1005 definitive versions of these Legal Provisions. For the avoidance of 1006 doubt, each Contributor to the IETF Standards Process licenses each 1007 Contribution that he or she makes as part of the IETF Standards 1008 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1009 language to the contrary, or terms, conditions or rights that differ 1010 from or are inconsistent with the rights and licenses granted under 1011 RFC 5378, shall have any effect and shall be null and void, whether 1012 published or posted by such Contributor, or included with or in such 1013 Contribution.