idnits 2.17.1 draft-ietf-trill-rbridge-channel-08.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 (July 13, 2012) is 4304 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: January 12, 2013 July 13, 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..........11 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 68 6. Congestion Considerations..............................18 70 7. Allocation Considerations..............................19 71 7.1 IANA Considerations...................................19 72 7.2 IEEE Registration Authority Considerations............20 74 8. Security Considerations................................21 76 9. References.............................................22 77 9.1 Normative References..................................22 78 9.2 Informative References................................23 80 Appendix: Change History..................................24 81 Acknowledgments...........................................27 83 1. Introduction 85 RBridge campuses provide transparent least-cost forwarding using the 86 TRILL (TRansparent Interconnection of Lots of Links) protocol that 87 builds on IS-IS (Intermediate System to Intermediate System) routing 88 [IS-IS] [RFC1195] [RFC6326bis]. Devices that implement TRILL are 89 called RBridges (Routing Bridges) or TRILL Switches. However, the 90 TRILL base protocol standard [RFC6325] provides only for TRILL Data 91 messages and TRILL IS-IS messages. 93 This document specifies a general channel mechanism for the 94 transmission of other messages within an RBridge campus, such as BFD 95 (Bidirectional Forwarding Detection, [RFC5880]) messages, (1) between 96 RBridges and end stations that are directly connected on the same 97 link and (2) between RBridges. This mechanism supports a requirement 98 to be able to operate with minimal configuration. 100 1.1 RBridge Channel Requirements 102 It is anticipated that various protocols operating at the TRILL layer 103 will be desired in RBridge campuses. For example, there is a need for 104 rapid response continuity checking with a protocol such as BFD 105 [RFC5880] [RFC5882] and for a variety of optional reporting. 107 To avoid the requirement to design and specify a way to carry each 108 such protocol, this document specifies a general channel for sending 109 messages between RBridges in a campus at the TRILL level by extending 110 the TRILL protocol. To accommodate a wide variety of protocols, this 111 RBridge Channel facility accommodates all the regular modes of TRILL 112 Data transmission including single and multiple hop unicast as well 113 as VLAN scoped multi-destination distribution. 115 To minimize any unnecessary burden on transit RBridges and to provide 116 a more realistic test of network continuity and the like, RBridge 117 Channel messages are designed to look like TRILL Data frames and, in 118 the case of multi-hop messages, can normally be handled by transit 119 RBridges as if they were TRILL Data frames; however, to enable 120 processing at transit RBridges when required by particular messages, 121 they may optionally use the RBridge Channel Alert TRILL extended 122 header flags [RFCext] that causes a transit RBridge implementing the 123 flag to more closely examine a flagged frame. 125 This document also specifies a format for sending RBridge Channel 126 messages between RBridges and end stations that are directly 127 connected over a link, in either direction, when provided for by the 128 protocol involved. For the most part, this format is the same as the 129 format that is TRILL Data encapsulated for inter-RBridge channel 130 messages. 132 Each particular protocol using the RBridge Channel facility will 133 likely use only a subset of the facilities specified herein. 135 1.2 Relation to the MPLS Generic Channel 137 The RBridge Channel is similar to the MPLS Generic Channel specified 138 in [RFC5586]. Instead of using a special MPLS label to indicate a 139 special channel message, an RBridge Channel message is indicated by a 140 special multicast Inner.MacDA and inner Ethertype (see Section 2.1). 142 1.3 Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 The terminology and acronyms of [RFC6325] are used in this document 149 with the additions listed below. 151 BFD - Bidirectional Forwarding Detection 153 CHV - Channel Header Version 155 MH - Multi-Hop 157 NA - Native 159 SL - Silent 161 2. Inter-RBridge Channel Messages 163 Channel messages between RBridges are transmitted as TRILL Data 164 frames. (For information on channel messages that can be transmitted 165 between RBridges and end stations that are directly connected by a 166 link, see Section 4.) Inter-RBridge Channel messages are identified 167 as such by their Inner.MacDA, which is the All-Egress-RBridges 168 multicast address, together with their Inner Ethertype, which is the 169 RBridge-Channel Ethertype. This Ethertype is part of and starts the 170 RBridge Channel Header. 172 The diagram below shows the overall structure of a RBridge Channel 173 Message frame on a link between two RBridges: 175 Frame Structure Section of This Document 176 ------------------------ 177 +--------------------------------+ 178 | Link Header | Section 2.3 if Ethernet Link 179 +--------------------------------+ 180 | TRILL Header | Section 2.2 181 +--------------------------------+ 182 | Inner Ethernet Header | Section 2.1.2 183 +--------------------------------+ 184 | RBridge Channel Header | Section 2.1.1 185 +--------------------------------+ 186 | Protocol Specific Payload | See specific channel protocol 187 +--------------------------------+ 188 | Link Trailer (FCS if Ethernet) | 189 +--------------------------------+ 191 Figure 1. RBridge Channel Frame Structure 193 Optionally, some channel messages may require examination of the 194 frame by transit RBridges that support the RBridge Channel feature, 195 to determine if they need to take any action. To indicate this, such 196 messages use a RBridge Channel Alert extended TRILL header flag as 197 further described in Section 3 below. 199 The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL 200 Header for frames sent in an RBridge Channel. As always, the Outer 201 link header and trailer are whatever is needed to get a TRILL Data 202 frame to the next hop RBridge, depending on the technology of the 203 link, and can change with each hop for multi-hop messages. Section 204 2.3 describes the outer Link Header for Ethernet links. And Section 205 2.4 discusses some special considerations for the first hop 206 transmission of RBridge Channel messages. 208 Section 3 describes some details of RBridge Channel message 209 processing. Section 4 provides the specifications for native RBridge 210 Channel frames between RBridges and end stations that are directly 211 connected over a link. Section 5 describes how support for RBridge 212 Channel protocols is indicated. And Sections 6, 7, and 8 give 213 congestion, allocation (IANA and IEEE), and security considerations 214 respectively. 216 2.1 The RBridge Channel Message Inner Frame 218 The encapsulated inner frame within an RBridge Channel message frame 219 is as shown below. 221 0 1 2 3 222 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 223 Inner Ethernet Header: 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Special Inner.MacDA = All-Egress-RBridges | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Special Inner.MacDA cont. | Inner.MacSA | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Inner.MacSA cont. | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | VLAN Tag Ethertype | Priority, DEI, VLAN ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 RBridge Channel Header: 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | RBridge-Channel Ethertype | CHV | Channel Protocol | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Flags | ERR | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 RBridge Channel Protocol Specific Information: 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 + Channel Protocol Specific Data 243 | ... 245 Figure 2. RBridge Channel Inner Frame Header Fields 247 The Channel Protocol Specific Data contains the information related 248 to the specific channel protocol used in the channel message. Details 249 of that data are outside the scope of this document, except in the 250 case of the RBridge Channel Error protocol specified below. 252 2.1.1 RBridge Channel Header 254 As shown in Figure 2, the RBridge Channel header starts with the 255 RBridge-Channel Ethertype (see Section 7.2). Following that is a 256 four-byte quantity with four sub-fields as follows: 258 CHV: A 4-bit field that gives the RBridge Channel Header Version. 259 This document specifies version zero. 261 Channel Protocol: A 12-bit unsigned integer that specifies the 262 particular RBridge Channel protocol to which the message 263 applies. 265 Flags: Provides 12 bits of flags described below. 267 ERR: A 4-bit unsigned integer used in connection with error 268 reporting at the RBridge Channel level as described in 269 Section 3. 271 The flag bits are numbered from 0 to 11 as shown below. 273 | 0 1 2 3 4 5 6 7 8 9 10 11| 274 +--+--+--+--+--+--+--+--+--+--+--+--+ 275 |SL|MH|NA| Reserved | 276 +--+--+--+--+--+--+--+--+--+--+--+--+ 278 Figure 3. Channel Header Flag Bits 280 Bit 0, which is the high order bit in network order, is defined as 281 the SL or Silent bit. If it is a one, it suppresses RBridge 282 Channel Error messages (see Section 3). 284 Bit 1 is the MH or Multi-Hop bit. It is used to inform the 285 destination RBridge protocol that the message may be multi-hop 286 (MH=1) or was intended to be one-hop only (MH=0). 288 Bit 2 is the NA or Native bit. It is used as described in Section 4 289 below. 291 Reserved: Bits reserved for future specification that MUST be sent as 292 zero and ignored on receipt. 294 The RBridge Channel Protocol field specifies the protocol that the 295 channel message relates to. The initial defined value is listed 296 below. 298 Protocol Name - Section of this Document 299 -------- ------------------------------- 301 0x001 RBridge Channel Error - Section 3 303 IANA Considerations for RBridge Channel protocol numbers are provided 304 in Section 7. These include provisions for Private Use protocol 305 numbers. Because different uses of Private Use RBridge Channel 306 protocol numbers may conflict, such use MUST be within a private 307 network. It is the responsibility of the private network manager to 308 avoid conflicting use of these code points and unacceptable burdens 309 within the private network from their use. 311 2.1.1 Inner Ethernet Header 313 The special Inner.MacDA is the All-Egress-RBridges multicast MAC 314 address to signal that the frame is intended for the egress 315 (decapsulating) RBridge itself (or the egress RBridges themselves if 316 the frame is multi-destination). (This address is called the All- 317 ESADI-RBridges address in [RFC6325].) The RBridge-Channel Ethertype 318 indicates that the frame is an RBridge Channel message. The only 319 other Ethertype currently specified for use with the All-Egress- 320 RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI frame 321 [RFC6325]. In the future additional Ethertypes may be specified for 322 use with the All-Egress-RBridges multicast address. 324 The RBridge originating the channel message selects the Inner.MacSA. 325 The Inner.MacSA MUST be set by the originating RBridge to a MAC 326 address unique within the campus owned by the originating RBridge. 327 This MAC address can be considered, in effect, the MAC address of a 328 virtual internal end station that handles the RBridge Channel frames 329 originated by or destined for that RBridge. It MAY be the same as the 330 Inner.MacSA used by the RBridge when it originates ESADI frames 331 [RFC6325]. 333 2.1.3 Inner.VLAN Tag 335 As with all frames formatted to be processed as a TRILL Data frame, 336 an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than 337 0x8100 or stacked tags is beyond the scope of this document but is an 338 obvious extension. 340 Multi-destination RBridge Channel messages are, like all multi- 341 destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID 342 MUST be set to the VLAN of interest. To the extent that distribution 343 tree pruning is in effect in the campus, such channel messages may 344 only reach RBridges advertising that they have connectivity to that 345 VLAN. 347 For channel messages sent as known unicast TRILL Data frames the 348 default value for the Inner.VLAN ID is VLAN 1 but particular RBridge 349 Channel protocols MAY specify other values. 351 The Inner.VLAN also specifies a three-bit frame priority for which 352 the following recommendations apply: 354 1. For one-hop channel messages critical to network connectivity, 355 such as one-hop BFD for rapid link failure detection in support 356 of TRILL IS-IS, the RECOMMENDED priority is 7. 358 2. For single and multi-hop unicast channel messages important to 359 network operation but not critical for connectivity, the 360 RECOMMENDED priority is 6. 362 3. For other unicast channel messages and all multi-destination 363 channel messages, it is RECOMMENDED that the default priority 364 zero be used. In any case, priorities higher than 5 SHOULD NOT 365 be used for such frames. 367 There is one additional bit in a VLAN tag value between the 12-bit 368 VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI, 369 [ClearCorrect]). It is RECOMMENDED that this bit be zero for the 370 first two categories of channel messages listed immediately above. 371 The setting of this bit for channel messages in the third category 372 may be dependent on the channel protocol and no general 373 recommendation is made for that case. 375 2.2 The TRILL Header for RBridge Channel Messages 377 After the outer Link Header (that, for an Ethernet link, ends with 378 the TRILL Ethertype) and before the encapsulated frame, the channel 379 message's TRILL Header initially appears as follows: 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 |V=0| R |M| Op-Len | Hop Count | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Egress Nickname | Ingress Nickname | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 4. RBridge Channel TRILL Header Fields 391 The TRILL Header version V MUST be zero, the R bits are reserved, the 392 M bit is set appropriately as the channel message is to be forwarded 393 as known destination unicast (M=0) or multi-destination (M=1) 394 regardless of the fact that the Inner.MacDA is always the All-Egress- 395 RBridges multicast address, and Op-Len is set appropriately for the 396 length of the TRILL Header extensions area, if any, all as specified 397 in [RFC6325]. 399 When an RBridge Channel message is originated, the Hop Count field 400 defaults to the maximum value, 0x3F, but particular RBridge Channel 401 protocols MAY specify other values. For messages sent a known number 402 of hops, such as one-hop messages or a two-hop self-addressed message 403 intended to loop back through an immediate neighbor RBridge, setting 404 the Hops field to the maximum value and checking the Hop Count field 405 on receipt provides an additional validity check as discussed in 406 [RFC5082]. 408 The RBridge originating a channel message places a nickname that it 409 holds into the ingress nickname field. 411 There are several cases for the egress nickname field. If the channel 412 message is multi-destination, then the egress nickname designates the 413 distribution tree to use. If the channel message is a multi-hop 414 unicast message, then the egress nickname is a nickname of the target 415 RBridge; this includes the special case of a message intended to loop 416 back from an immediate neighbor where the originator places one of 417 its own nicknames in both the ingress and egress nickname fields. If 418 the channel message is a one-hop unicast message, there are two 419 possibilities for the egress nickname. 421 o The egress nickname can be set to a nickname of the target 422 neighbor RBridge. 424 o The special nickname Any-RBridge may be used. RBridges supporting 425 the RBridge Channel facility MUST recognize the Any-RBridge 426 special nickname and accept TRILL Data frames having that value in 427 the egress nickname field as being sent to them as the egress. 428 Thus, for such RBridges, using this egress nickname guarantees 429 processing by an immediate neighbor regardless of the state of 430 nicknames. 432 2.3 Ethernet Link Header and Trailer 434 An RBridge Channel frame has the usual link header and trailer for a 435 TRILL Data frame depending on the type of link on which it is sent. 437 For an Ethernet link [RFC6325] the Outer.MacSA is the MAC address of 438 the port from which the frame is sent. The Outer.MacDA is the MAC 439 address of the next-hop RBridge port for unicast RBridge Channel 440 messages or the All-RBridges multicast address for multi-destination 441 RBridge Channel messages. The Outer.VLAN tag specifies the Designated 442 VLAN for that hop and the priority should be the same as in the 443 Inner.VLAN tag; however, the output port may have been configured to 444 strip VLAN tags, in which case no Outer.VLAN tag appears on the wire. 445 And the link trailer is the Ethernet FCS. 447 2.4 Special Transmission and Rate Considerations 449 If a multi-hop RBridge Channel message is received by an RBridge, the 450 criteria and method of forwarding it are the same as for any TRILL 451 Data frame. If it is so forwarded, it will be on a link that was 452 included in the routing topology because it was in the Report state 453 as specified in [RFC6327]. 455 However, special considerations apply to single hop messages because, 456 for some RBridge Channel protocols, it may be desirable to send 457 RBridge Channel messages over a link that is not yet fully up. In 458 particular, it is permissible, if specified by the particular channel 459 protocol, for the source RBridge that has created an RBridge Channel 460 message to attempt to transmit it to a next hop RBridge when the link 461 is in the Detect or Two-Way states, as specified in [RFC6327], as 462 well as when it is in the Report state. Such messages can also be 463 sent on point-to-point links that are not in the Up state. 465 RBridge Channel messages represent a burden on the RBridges and links 466 in a campus and should be rate limited, especially if they are sent 467 as high priority, multi-destination, or multi-hop frames or have an 468 RBridge Channel Alert extended header flag set. See Section 6, 469 Congestion Considerations. 471 3. Processing RBridge Channel TRILL Data Messages 473 RBridge Channel TRILL Data messages are designed to look like and, to 474 the extent practical, be forwarded as regular TRILL Data frames. On 475 receiving a channel message, an RBridge performs the usual initial 476 tests on the frame and makes the same forwarding and/or decapsulation 477 decisions as for a regular TRILL Data frame [RFC6325] with following 478 exceptions for RBridges implementing the RBridge Channel facility: 480 1. An RBridge implementing the RBridge Channel facility MUST 481 recognize the Any-RBridge egress nickname in TRILL Data frames, 482 decapsulating such frames if they meet other checks. (Such a 483 frame cannot be a valid multi-destination frame because the 484 Any-RBridge nickname is not a valid distribution tree root.) 486 2. If an RBridge Channel Alert extended header flag is set, then 487 the RBridge MUST process the RBridge Channel message as 488 described below even if it is not egressing the frame. If it is 489 egressing the frame, then no additional processing beyond 490 egress processing is needed even if an RBridge Channel Alert 491 flag is set. 493 3. On decapsulation, the special Inner.MacDA value of All-Egress- 494 RBridges MUST be recognized to trigger checking the 495 Inner.Ethertype and processing as an RBridge Channel message if 496 that Ethertype is RBridge-Channel. 498 RBridge Channel messages SHOULD only be sent to RBridges that 499 advertise support for the channel protocol involved as described in 500 Section 5. 502 All RBridges supporting the RBridge Channel facility MUST recognize 503 the RBridge-Channel inner Ethertype. 505 3.1 Processing the RBridge Channel Header 507 Knowing that it has an RBridge Channel message, the egress RBridge, 508 and any transit RBridge if an RBridge Channel Alert bit is set in the 509 TRILL Header, looks at the CHV (RBridge Channel Header Version) and 510 Channel Protocol fields. 512 If any of the following conditions occur at an egress RBridge, the 513 frame is not processed, an error may be generated as specified in 514 Section 3.2, and the frame is discarded. The behavior is the same if 515 the frame is being processed at a transit RBridge because the 516 critical RBridge Channel Alert flag is set [RFCext]. However, if 517 these conditions are detected at a transit RBridge examining the 518 message because the non-critical RBridge Channel Alert flag is set 520 [RFCext] but the critical RBridge Channel Alert flag is not set, no 521 error is generated and the frame is still forwarded normally. 523 Error Conditions: 525 1. The Ethertype is not RBridge-Channel and not any other 526 Ethertype known to the RBridge as usable with the All-Egress- 527 RBridges Inner.MacDA, or the frame is so short that the 528 Ethertype is truncated. 530 2. The CHV field is non-zero or the frame is so short that the 531 version zero Channel Header is truncated. 533 3. The Channel Protocol field is a reserved value or a value 534 unknown to the processing RBridge. 536 4. The ERR field is non-zero and Channel Protocol is a value other 537 than 0x001. 539 5. The RBridge Channel Header NA flag is set to one indicating 540 that the frame should have been received as a native frame 541 rather than a TRILL Data frame. 543 If the CHV field and NA flag are zero and the processing RBridge 544 recognizes the Channel Protocol value, it processes the message in 545 accordance with that channel protocol. The processing model is as if 546 the received frame starting with and including the TRILL Header is 547 delivered to the Channel protocol along with a flag indicating 548 whether this is (a) transit RBridge processing due to an RBridge 549 Channel Alert flag being set or (b) egress processing. 551 Errors within a recognized Channel Protocol are handled by that 552 channel protocol itself and do not produce RBridge Channel Error 553 frames. 555 3.2 RBridge Channel Errors 557 A variety of problems at the RBridge Channel level cause the return 558 of an RBridge Channel Error frame unless one of the following apply: 559 (a) the "SL" (Silent) flag is a one in the channel message for which 560 the problem was detected, (b) the processing is due to the non- 561 critical RBridge Channel Alert bit being set, (c) the frame in error 562 appears, itself, to be an RBridge Channel error frame (has a non-zero 563 ERR field or a Channel Protocol of 0x001), or (d) the error is 564 suppressed due to rate limiting. 566 An RBridge Channel Error frame is a multi-hop unicast RBridge Channel 567 message with the ingress nickname set to a nickname of the RBridge 568 detecting the error, and the egress nickname set to the value of the 569 ingress nickname in the channel message for which the error was 570 detected. No per-hop transit processing is specified for such error 571 frames, so the RBridge Channel Alert extended header flags SHOULD, if 572 an extension is present, be set to zero. The SL and MH flags SHOULD 573 be set to one, the NA flag MUST be zero, and the ERR field MUST be 574 non-zero as described below. For the protocol specific data area, an 575 RBridge Channel Message Error frame has at least the first 256 bytes 576 (or less if less are available) of the erroneous decapsulated channel 577 message starting with the TRILL Header. (Note: The TRILL Header does 578 not include the TRILL Ethertype that is part of the Link Header on 579 Ethernet Links.) 581 The following values for ERR are specified: 583 ERR RBridge Channel Error Code Meaning 584 --- ---------------------------------- 585 0 - No error 586 1 Frame too short (truncated Ethertype or Channel Header) 587 2 Unrecognized Ethertype 588 3 Unimplemented value of CHV 589 4 Wrong value of NA flag 590 5 Channel Protocol is reserved or unimplemented 591 6-14 - Available for allocation, see Section 7. 592 15 Reserved (see Note) 594 Note: Intended to be allocated by Standards Action for an error 595 code expansion feature when it appears likely that all other 596 available error codes are being allocated. 598 All RBridges implementing the RBridge Channel feature MUST recognize 599 the RBridge Channel Error protocol value (0x001). They MUST NOT 600 generate an RBridge Channel Error message in response to a RBridge 601 Channel Error message, that is, a channel message with a protocol 602 value of 0x001 or with a non-zero ERR field. 604 4. Native RBridge Channel Frames 606 Other sections of this document specify non-native RBridge Channel 607 messages and their processing, that is, RBridge Channel messages 608 formatted as TRILL Data frames and sent between RBridges. This 609 section specifies the differences for native RBridge Channel 610 messages. 612 If provided for by the channel protocol involved, native RBridge 613 channel messages may be sent between end-stations and RBridges that 614 are directly connected over a link, in either direction. On an 615 Ethernet link, such native frames have the RBridge-Channel Ethertype 616 and are like the encapsulated frame inside an RBridge Channel message 617 except as follows: 619 1. TRILL does not require the presence of a VLAN tag on such 620 native RBridge channel frames. However, port configuration, 621 link characteristics, or the channel protocol involved may 622 require such tagging. 624 2. If the frame is unicast, the destination MAC address is the 625 unicast MAC address of the RBridge or end-station port that is 626 its intended destination. If the frame is multicast by an end 627 station to all the RBridges on a link that support an RBridge 628 Channel protocol that uses this transport, the destination MAC 629 address is the All-Edge-RBridges multicast address (see Section 630 7). A native RBridge Channel frame received at an ingress 631 RBridge with a destination MAC address that is a unicast 632 address different from that of the port or multicast address 633 different from All-Edge-RBridges, is discarded. If the frame is 634 multicast by an RBridge to all the devices that TRILL considers 635 to be end stations on a link that support an RBridge Channel 636 protocol that uses this transport, the destination MAC address 637 is the TRILL-End-Stations multicast address (see Section 7). A 638 native RBridge Channel frame received at an end station with a 639 destination MAC address that is a unicast address different 640 from that of the port or multicast address different from 641 TRILL-End-Stations, is discarded. 643 3. The RBridge-Channel outer Ethertype must be present. In the 644 future there may be other protocols using the All-Edge-RBridges 645 and/or TRILL-End-Stations multicast addresses on native frames 646 distinguished by different Ethertypes. 648 4. The NA or native bit in the RBridge Channel Header flags MUST 649 be a one. 651 5. There might be additional tags present between the Outer.MacDA, 652 Outer.MacSA pair and the RBridge-Channel Ethertype. 654 The RBridge Channel protocol number space for native RBridge Channel 655 messages and TRILL Data formatted RBridge Channel messages is the 656 same. If provided for by the channel protocol involved, the receipt 657 of a native RBridge Channel frame MAY lead to the generation and 658 transmission of one or more Inter-RBridge Channel frames. The 659 decapsulation and processing of a TRILL Data RBridge Channel frame 660 MAY, if provided for by the channel protocol involved, result in the 661 sending of one or more native RBridge channel frames to one or more 662 end stations. Thus, there could be an RBridge Channel protocol that 663 involved an RBridge Channel message sent from an origin RBridge where 664 the message is created, through one or more transit RBridges and from 665 the last as a native RBridge channel message to and end station or 666 the reverse of such a path; however, to do this the RBridge channel 667 protocol involved must be implemented at the RBridge where the 668 channel message is changed between a native frame and a TRILL Data 669 format frame and that RBridge must change the channel message itself, 670 at a minimum complementing the NA flag in the Channel Header and 671 making appropriate MAC address changes. 673 An erroneous native channel message results in a native RBridge 674 channel error message under the same conditions for which an TRILL 675 Data RBridge Channel message would result in a TRILL Data RBridge 676 channel error message. However, in a native RBridge Channel error 677 message, the NA flag MUST be one. Also, since there is no TRILL 678 Header in native RBridge Channel protocol frames, the beginning part 679 of the frame in which the error was detected that is included in 680 native RBridge Channel error frames starts with the RBridge Channel 681 Header (including the RBridge-Channel Ethertype). The destination MAC 682 address of such error messages is set to the source MAC address of 683 the native RBridge Channel message that was in error. 685 There is no mechanism to stop end stations from directly exchanging 686 native RBridge Channel messages but such usage is beyond the scope of 687 this document. 689 5. Indicating Support for RBridge Channel Protocols 691 Support for RBridge Channel protocols is indicated by the presence of 692 one or more TLVs and/or sub-TLVs in an RBridge's LSP as documented in 693 [RFC6326bis]. 695 RBridge Channel protocols 0 and 0xFFF are reserved and protocol 1, 696 the RBridge Channel error protocol, MUST be implemented as part of 697 the RBridge Channel feature. Thus, if an RBridge supports the RBridge 698 Channel feature, it should be advertising support for protocol 1 and 699 not advertising support for protocols 0 or 0xFFF in its LSP. 700 However, indication of support or non-support for RBridge Channel 701 protocol 1 is ignored on receipt and support for it is always 702 assumed, if support for any RBridge Channel is indicated in the 703 RBridge's LSP. 705 6. Congestion Considerations 707 The bandwidth resources used by RBridge Channel protocols are 708 recommended to be small compared to the total bandwidth of the links 709 they traverse. When doing network planning, the bandwidth 710 requirements for TRILL data, TRILL IS-IS, the TRILL ESADI protocol, 711 RBridge Channel traffic, and any other link local traffic need to be 712 taken into account. 714 Specifications for particular RBridge Channel protocols MUST consider 715 congestion and bandwidth usage implications and provide guidance on 716 bandwidth or packet frequency management. RBridge Channel protocols 717 can have built-in bandwidth management in their protocols. Outgoing 718 channel messages SHOULD be rate-limited, by configuring the 719 underlying protocols or otherwise, to prevent aggressive connectivity 720 verification or other applications consuming excessive bandwidth, 721 causing congestion, or becoming denial-of-service attacks. 723 If these conditions cannot be followed, an adaptive loss-based scheme 724 SHOULD be applied to congestion-control outgoing RBridge Channel 725 traffic, so that it competes fairly, taking into account packet 726 priorities and drop eligibility as indicated in the Inner.VLAN, with 727 TCP or similar traffic within an order of magnitude. One method of 728 determining an acceptable bandwidth for RBridge Channel traffic is 729 described in [RFC5348]; other methods exist. For example, bandwidth 730 or packet frequency management can include any of the following: a 731 negotiation of transmission interval/rate such as that provided in 732 BFD [RFC5880], a throttled transmission rate on "congestion detected" 733 situations, a gradual ramp-up after shutdown due to congestion and 734 until basic connectivity is verified, and other mechanisms. 736 Connectivity chcking applications such as BFD [RFC5880] SHOULD be 737 rate-limited to below 5% of the bit-rate of the associated link or 738 links. For this purpose, the mean or sustained bit-rate of the link 739 or links is used. 741 Incoming RBridge Channel messages MAY be rate-limited as a protection 742 against denial-of-service attacks. This throttling of incoming 743 messages SHOULD honor packet priorities and drop eligibility 744 indications as indicate in the Inner.VLAN, preferentially discarding 745 drop eligible and lower priority packets. 747 7. Allocation Considerations 749 The following subsections give IANA and IEEE allocation 750 considerations. In this document, the allocation procedure 751 specifications are as defined in [RFC5226]. 753 7.1 IANA Considerations 755 IANA is requested to allocate a previously unassigned TRILL Nickname 756 as follows: 758 Any-RBridge TBD (0xFFCO suggested) 760 IANA is requested to add "All-Egress-RBridges" to the TRILL Parameter 761 Registry as an alternative name for the "All-ESADI-RBridges" 762 multicast address. 764 IANA is requested to allocate two previously unassigned TRILL 765 Multicast address as follows: 767 TRILL-End-Stations TBD (01-80-C2-00-00-45 suggested) 768 All-Edge-RBridges TBD (01-80-C2-00-00-46 suggested) 770 IANA is requested to create an additional sub-registry in the TRILL 771 Parameter Registry for RBridge Channel Protocols, with initial 772 contents as follows: 774 Protocol Description Reference 775 -------- ----------- --------- 777 0x000 Reserved, not to be allocated (This document) 778 0x001 RBridge Channel Error (This document) 779 0x002-0x0FF Available (1) 780 0x100-0xFF7 Available (2) 781 0xFF8-0xFFE Private Use 782 0xFFF Reserved, not to be allocated (This document) 784 (1) RBridge Channel protocol code points from 0x002 to 0x0FF require 785 a Standards Action, as modified by [RFC4020], for allocation. 787 (2) RBridge Channel protocol code points from 0x100 to 0xFF7 are RFC 788 Required to allocate a single value or IESG Approval to allocate 789 multiple values. 791 IANA is requested to create an additional sub-registry in the TRILL 792 Parameter Registry for RBridge Channel Header Flags with initial 793 contents as follows: 795 Flag Bit Mnemonic Allocation 796 -------- -------- ---------- 798 0 SL Silent 799 1 MH Multi-hop 800 2 NA Native 801 3-11 - Available for allocation 803 Allocation of an RBridge Channel Header Flag is based on IETF Review. 805 IANA is requested to create an additional sub-registry in the TRILL 806 Parameter Registry for RBridge Channel Error codes with initial 807 contents as listed in Section 3.2 above and with available values 808 allocated by Standards Action as modified by [RFC4020]. 810 7.2 IEEE Registration Authority Considerations 812 The IEEE Registration Authority has assigned the Ethertype for 813 RBridge-Channel. 815 8. Security Considerations 817 No general integrity, authentication, or encryption mechanisms are 818 provided herein for RBridge Channel messages. If these services are 819 required for a particular RBridge Channel protocol, they MUST be 820 supplied by that channel protocol. See, for example, the BFD 821 Authentication mechanism [RFC5880]. 823 See [RFC6325] for general TRILL Security Considerations. As stated 824 therein, no protection is provided by TRILL against forging of the 825 ingress nickname in a TRILL Data formatted channel message or the 826 Outer.MacSA in a native RBridge Channel frame on an Ethernet link. 827 This may result in misdirected return responses or error messages. 828 However, link level security protocols may be used to authenticate 829 the origin station on a link and protect against attacks on links. 830 See also Section 6 above concerning congestion. 832 If indication of RBridge Channel Protocol support are improperly 833 absent from an RBridge's LSP, it could deny all RBridge Channel 834 services, for example some BFD services, for the RBridge in question. 835 If a particular RBridge channel protocol is incorrectly not 836 advertised as supported, it could deny the service of that channel 837 protocol to the RBridge in question. 839 Incorrect indication of RBridge Channel Protocol support or incorrect 840 assertion of support for a channel protocol could encourage RBridge 841 channel messages to be sent to an RBridge that does not support the 842 channel feature or the particular channel protocol used. The inner 843 frame of such messages could be decapsulated and that inner frame 844 could be sent out all ports that are appointed forwarders for the 845 frame's Inner.VLAN. However, this is unlikely to cause much harm; in 846 particular, there are two possibilities as follows: (a) If end 847 stations do not recognize the RBridge-Channel Ethertype of the frame, 848 they will drop it. (b) If end stations do recognize the RBridge- 849 Channel Ethertype and the channel protocol indicated in the frame, 850 they should refuse to process the frame due to an incorrect value of 851 the RBridge Channel Header NA flag. 853 9. References 855 The following sections list normative and informative references for 856 this document. 858 9.1 Normative References 860 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 861 Intermediate System Intra-Domain Routing Exchange Protocol for 862 use in Conjunction with the Protocol for Providing the 863 Connectionless-mode Network Service (ISO 8473)", 2002. 865 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 866 dual environments", RFC 1195, December 1990. 868 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, March 1997. 871 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 872 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 874 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 875 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 876 2008. 878 [RFC5348] - Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 879 Friendly Rate Control (TFRC): Protocol Specification", RFC 880 5348, September 2008. 882 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 883 Ghanwani, "Routing Bridges (RBridges): Base Protocol 884 Specification", RFC 6325, July 2011. 886 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 887 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 888 6327, July 2011. 890 [RFCext] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. Bestler, 891 "TRILL: TRILL Header Extension", draft-ietf-trill-rbridge- 892 extension, in RFC Editor's queue. 894 [RFC6326bis] - Eastlake, D., A. Banerjee, D. Dutt, A. Ghanwani, R. 895 Perlman, "TRILL Use of IS-IS", draft-eastlake-isis-rfc6326bis, 896 work in progress. 898 9.2 Informative References 900 [RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 901 Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 902 5082, October 2007 904 [RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 905 "MPLS Generic Associated Channel", RFC 5586, June 2009. 907 [RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection 908 (BFD)", June 2010. 910 [RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional 911 Forwarding Detection (BFD)", June 2010. 913 [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V. 914 Manral, "TRILL: Clarifications, Corrections, and Updates", 915 draft-ietf-trill-clear-correct, work in progress. 917 Appendix: Change History 919 RFC Editor: please delete this appendix before publication. 921 Changes from -00 to -01 923 1. Spell out more acronyms. 925 2. Add reference to "Guidelines for the Use of OAM" draft. 927 3. Move definition of Alert flag to draft-ietf-trill-rbridge-options 928 and refer to it as an extended header flag. 930 4. Change name of "Egress-RBridges" multicast address to "All-Egress- 931 RBridges". Merge with All-ESADI-RBridges (i.e., they are two names 932 for the same MAC address). 934 5. Add detailed bit vector description for indicating support of 935 RBridge channel protocols. Add GENAPP and an APPsub-TLV to hold 936 one or more bit vectors. 938 6. Assorted editorial changes. 940 Changes from -01 to -02 942 1. Update for drafts that have been issued as RFCs. 944 2. Change to specification of Inner.VLAN in RBridge channel messages. 946 3. Remove GENAPP and move RBridge Channels supported information to 947 another document. 949 4. Clarify native RBridge Channel error messages. 951 5. Assorted editorial changes. 953 Changes from -02 to -03 955 1. Liberalize restrictions on RBridge acceptance of native RBridge 956 Channel messages. These are typically messages and should 957 generally be accepted unless in a VLAN not enabled at the port or 958 the like. 960 2. Change multi-cast address used by end stations in sending a native 961 RBridge Channel message to all RBridges on the link from All- 962 Egress-RBridges to All-Edge-RBridges to avoid possible confusion 963 if such a frame were encapsulated resulting in an All-Egress- 964 RBridges Inner.MacDA. 966 3. Reword references to "two-hop echo" and the like for clarity. 967 (This meant an echo frame that went to an immediate neighbor and 968 back.) 970 4. Add reference to and move some material to the RFC 6326bis draft. 972 5. Assorted editorial changes. 974 Changes from -03 to -04 976 1. Update for the replacement of the CFI bit by the DEI bit (see 977 [ClearCorrect]). 979 2. Update for the existence of both critical and non-critical RBridge 980 Channel alert flags. 982 3. Update author information. 984 4. Assorted editorial changes. 986 Changes from -04 to -05 988 1. Clarify the distinction between native and non-native RBridge 989 Channel messages and that native channel messages are only 990 intended to be transmitted between RBridge and end stations on the 991 same link. 993 2. Add a paragraph to the Security Considerations section about 994 forged ingress nicknames / source MAC addresses in channel 995 messages. 997 3. Add acknowledgements section. 999 4. Replace "OAM" references with "BFD" references in Abstract and 1000 Introduction. 1002 5. Very minor editorial changes. 1004 Changes from -05 to -06 1006 1. Improve wording in 2.1.1 re CHV values. 1008 2. Revert "Ext-Len" to "Op-Len". 1010 3. Fix typos and make minor editorial changes. 1012 Changes from -06 to -07 1014 1. Add bit numbers at top of figures where they were missing. 1016 2. Add figure numbers and captions. 1018 3. Add text to Section 2.1.1 concerning Private Use RBridge Channel 1019 protocol numbers. 1021 4. Change IANA Considerations for the allocation of multiple RBridge 1022 Channel protocol numbers in the 0x100 to 0xFF7 range from IETF 1023 Review to IESG Approval. 1025 5. Add text that the intended use for ERR code 15 is for some future 1026 error code expansion feature should more error codes be required 1027 and indicate that protocol numbers 0x000 and 0xFFF are not to be 1028 allocated. 1030 6. Captialize the first occurrence of "must" in Section 7. 1032 7. Add statement that directly connected end-stations are not blocked 1033 from communicating with each other using channel messages but such 1034 messages are beyond the scope of this document. 1036 8. Re-order and add some references to the Securty Considertions 1037 section. 1039 9. Typo fixes and various editorial changes. 1041 Changes from -07 to -08 1043 1. Add congestion considerations section. 1045 2. Minor editorial changes. 1047 Acknowledgments 1049 The authors gratefully acknowledge the comments and contributions of 1050 the follows, listed is alphabetic order: Stewart Bryant, Somnath 1051 Chatterjee, Adrian Farrel, Stephen Farrell, Miguel A. Garcia, Anoop 1052 Ghanwani, Brian Haberman, Rakesh Kumar, Barry Leiba, and Tissa 1053 Senevirathne. 1055 This document was prepared with raw nroff. All macros used were 1056 defined in the document source files. 1058 Authors' Addresses 1060 Donald Eastlake 3rd 1061 Huawei R&D USA 1062 155 Beaver Street 1063 Milford, MA 01757 USA 1065 Tel: +1-508-333-2270 1066 EMail: d3e3e3@gmail.com 1068 Vishwas Manral 1069 HP Networking 1070 19111 Pruneridge Avenue 1071 Cupertino, CA 95014 USA 1073 Tel: +1-408-477-0000 1074 EMail: vishwas.manral@hp.com 1076 Yizhou Li 1077 Huawei Technologies 1078 101 Software Avenue, 1079 Nanjing 210012, China 1081 Phone: +86-25-56622310 1082 Email: liyizhou@huawei.com 1084 Sam Aldrin 1085 Huawei Technologies 1086 2330 Central Expressway 1087 Santa Clara, CA 95050 USA 1089 Phone: +1-408-330-5000 1090 Email: sam.aldrin@huawei.com 1091 Dave Ward 1092 Cisco Systems 1093 170 W. Tasman Drive 1094 San Jose, CA 95134 USA 1096 EMail: dward@cisco.com 1098 Copyright, Disclaimer, and Additional IPR Provisions 1100 Copyright (c) 2012 IETF Trust and the persons identified as the 1101 document authors. All rights reserved. 1103 This document is subject to BCP 78 and the IETF Trust's Legal 1104 Provisions Relating to IETF Documents 1105 (http://trustee.ietf.org/license-info) in effect on the date of 1106 publication of this document. Please review these documents 1107 carefully, as they describe your rights and restrictions with respect 1108 to this document. Code Components extracted from this document must 1109 include Simplified BSD License text as described in Section 4.e of 1110 the Trust Legal Provisions and are provided without warranty as 1111 described in the Simplified BSD License. The definitive version of 1112 an IETF Document is that published by, or under the auspices of, the 1113 IETF. Versions of IETF Documents that are published by third parties, 1114 including those that are translated into other languages, should not 1115 be considered to be definitive versions of IETF Documents. The 1116 definitive version of these Legal Provisions is that published by, or 1117 under the auspices of, the IETF. Versions of these Legal Provisions 1118 that are published by third parties, including those that are 1119 translated into other languages, should not be considered to be 1120 definitive versions of these Legal Provisions. For the avoidance of 1121 doubt, each Contributor to the IETF Standards Process licenses each 1122 Contribution that he or she makes as part of the IETF Standards 1123 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1124 language to the contrary, or terms, conditions or rights that differ 1125 from or are inconsistent with the rights and licenses granted under 1126 RFC 5378, shall have any effect and shall be null and void, whether 1127 published or posted by such Contributor, or included with or in such 1128 Contribution.