RFC 7178
Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support
RFC 7178: Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support 🎀
Okay bestie, this one is a Standards Track doc from May 2014 (ISSN 2070-1721) that came out of the Internet Engineering Task Force (IETF) 💅. The authors are D. Eastlake 3rd (Huawei), V. Manral (Ionos Corp.), Y. Li (Huawei), S. Aldrin (Huawei), and D. Ward (Cisco). Nothing is listed as obsoleted or updated in the header, so it's a fresh standard. ✨
Abstract 🌸
This doc spells out a general channel mechanism for sending messages, like Bidirectional Forwarding Detection (BFD) messages 🦋, between Routing Bridges (RBridges), and between RBridges and end stations inside an RBridge campus. It works through extensions to the Transparent Interconnection of Lots of Links (TRILL) protocol. 💜
Status of This Memo 🧚
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7178. 🍓
Copyright Notice 🔥
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at http://trustee.ietf.org/license-info, as they were in effect when this was published. Please actually read those, bestie, because they explain your rights and restrictions for this doc. 🙈
Any Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License. 👑
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. RBridge Channel Requirements ...............................3
1.2. Relation to the MPLS Generic Associated Channel ............4
1.3. Terminology ................................................4
2. Inter-RBridge Channel Messages ..................................4
2.1. RBridge Channel Message Inner Frame ........................6
2.1.1. RBridge Channel Header ..............................6
2.1.2. Inner Ethernet Header ...............................8
2.1.3. Inner.VLAN Tag ......................................8
2.2. TRILL Header for RBridge Channel Messages ..................9
2.3. Ethernet Link Header and Trailer ..........................10
2.4. Special Transmission and Rate Considerations ..............10
3. Processing RBridge Channel TRILL Data Messages .................11
3.1. Processing the RBridge Channel Header .....................12
3.2. RBridge Channel Errors ....................................13
4. Native RBridge Channel Frames ..................................14
5. Indicating Support for RBridge Channel Protocols ...............16
6. Congestion Considerations ......................................16
7. Allocation Considerations ......................................17
7.1. IANA Considerations .......................................17
7.2. IEEE Registration Authority Considerations ................18
8. Security Considerations ........................................18
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
10. Acknowledgments ...............................................201. Introduction ✨
RBridge campuses give you transparent least-cost forwarding using the TRILL protocol, which is built on Intermediate System to Intermediate System (IS-IS) routing [IS-IS] [RFC1195] [RFC7176]. 💖 Devices that implement TRILL are called Routing Bridges (RBridges) or TRILL Switches. The TRILL base protocol standard [RFC6325] only covers TRILL Data messages and TRILL IS-IS messages, though. 🤷♀️
This doc specifies a general channel mechanism for sending other messages inside an RBridge campus, like BFD [RFC5880] messages, (1) between RBridges and end stations directly connected on the same link, and (2) between RBridges. This mechanism supports the requirement to operate with minimal configuration. 🫶
1.1. RBridge Channel Requirements
Lots of different protocols running at the TRILL layer are going to be wanted in RBridge campuses. For example, there's a need for rapid-response continuity checking with a protocol like BFD [RFC5880] [RFC5882], plus a bunch of optional reporting. 📊
Instead of designing and specifying a separate way to carry each of those protocols, this doc specifies one general channel for sending messages between RBridges in a campus at the TRILL level, by extending the TRILL protocol. 🧠 To fit a wide variety of protocols, this RBridge Channel facility supports all the regular modes of TRILL Data transmission, including single- and multiple-hop unicast, as well as VLAN-scoped multi-destination distribution. 🌈
To keep the burden on transit RBridges low, and to give a more realistic test of network continuity and the like, RBridge Channel messages are designed to look like TRILL Data frames. In the multi-hop case, transit RBridges can normally handle them as if they were TRILL Data frames. 🦋 If a particular message needs processing at transit RBridges, it may optionally use the RBridge Channel Alert TRILL extended header flags [RFC7179], which make a transit RBridge that implements the flag look more closely at the flagged frame. 👀
This doc also specifies a format for sending RBridge Channel messages between RBridges and end stations that are directly connected over a link, in either direction, when the protocol involved provides for it. Mostly, this format is the same as the format that TRILL Data encapsulates for inter-RBridge Channel messages. 💜
Each protocol that uses the RBridge Channel facility will probably only use a subset of the facilities specified here. 🍰
1.2. Relation to the MPLS Generic Associated Channel
The RBridge Channel is similar to the MPLS Generic Associated Channel specified in [RFC5586]. Instead of using a special MPLS label to flag a special channel message, an RBridge Channel message is flagged by a special multicast Inner.MacDA and an inner Ethertype (see Section 2.1). 🧚♀️
1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 📖
The terminology and acronyms of [RFC6325] are used in this document, plus the additions below. 💅
BFD - Bidirectional Forwarding Detection
CHV - Channel Header Version
MH - Multi-Hop
NA - Native
SL - Silent2. Inter-RBridge Channel Messages 🦋
Channel messages between RBridges are sent as TRILL Data frames. (For info on channel messages that can go between RBridges and end stations directly connected by a link, see Section 4. 👀) Inter-RBridge Channel messages are identified by their Inner.MacDA, which is the All-Egress-RBridges multicast address, together with their inner Ethertype, which is the RBridge-Channel Ethertype. That Ethertype is part of the RBridge Channel Header and starts it. 💖
Here's the overall structure of an RBridge Channel Message frame on a link between two RBridges:
Frame Structure Section of This Document
------------------------
+--------------------------------+
| Link Header | Section 2.3 if Ethernet link
+--------------------------------+
| TRILL Header | Section 2.2
+--------------------------------+
| Inner Ethernet Header | Section 2.1.2
+--------------------------------+
| RBridge Channel Header | Section 2.1.1
+--------------------------------+
| Protocol-Specific Payload | See specific channel protocol
+--------------------------------+
| Link Trailer (FCS if Ethernet) |
+--------------------------------+
Figure 1: RBridge Channel Frame StructureOptionally, some channel messages may need transit RBridges that support the RBridge Channel feature to examine the frame, so they can decide whether to take any action. To flag this, those messages use the RBridge Channel Alert extended TRILL Header flag, which Section 3 below covers in more detail. 🚩
Sections 2.1 and 2.2 describe the inner frame and the TRILL Header for frames sent in an RBridge Channel. As always, the outer Link Header and Link Trailer are whatever it takes to get a TRILL Data frame to the next-hop RBridge, depending on the link's technology, and they can change at each hop for multi-hop messages. Section 2.3 describes the outer Link Header for Ethernet links, and Section 2.4 talks about some special considerations for the first-hop transmission of RBridge Channel messages. 🌷
Section 3 covers details of RBridge Channel message processing. Section 4 has the specs for native RBridge Channel frames between RBridges and end stations directly connected over a link. Section 5 explains how support for RBridge Channel protocols gets indicated. And Sections 6, 7, and 8 cover congestion, allocation (IANA and IEEE), and security considerations, respectively. 🎀
2.1. RBridge Channel Message Inner Frame ✨
okay bestie, this is the inside frame that rides along in an RBridge Channel message, and it's giving layered 🎀
0 1 2 3
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
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA cont. | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype | Priority, DEI, VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel Ethertype | CHV | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Information specific to the RBridge Channel Protocol:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Channel-Protocol-Specific Data
| ...
Figure 2: RBridge Channel Inner Frame Header FieldsThe Channel-Protocol-Specific Data is where the info for whichever channel protocol is in use lives 🧚 Details of that data are outside the scope of this document, except in the case of the RBridge Channel Error protocol specified in Section 3.2.
2.1.1. RBridge Channel Header 🌸
As shown in Figure 2, the RBridge Channel Header starts with the RBridge-Channel Ethertype (see Section 7.2). After that comes a four-byte quantity with four sub-fields, and here they are:
- CHV: A 4-bit field that gives the RBridge Channel Header Version. This document specifies version zero.
- Channel Protocol: A 12-bit unsigned integer that specifies the particular RBridge Channel protocol to which the message applies.
- Flags: Provides 12 bits of flags as described below.
- ERR: A 4-bit unsigned integer used in connection with error reporting at the RBridge Channel level as described in Section 3.
The flag bits are numbered from 0 to 11, as shown here:
| 0 1 2 3 4 5 6 7 8 9 10 11|
+--+--+--+--+--+--+--+--+--+--+--+--+
|SL|MH|NA| Reserved |
+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: Channel Header Flag Bits- Bit 0: The SL or Silent bit, the high-order bit in network order. If it is a one, it suppresses RBridge Channel Error messages (see Section 3).
- Bit 1: The MH or Multi-Hop bit. It is used to inform the destination RBridge protocol that the message may be multi-hop (MH=1) or was intended to be one-hop only (MH=0).
- Bit 2: The NA or Native bit. It is used as described in Section 4.
- Reserved: Bits reserved for future specification that MUST be sent as zero and ignored on receipt.
The RBridge Channel Protocol field tells you which protocol the channel message relates to. The initial defined value is listed below:
Protocol Name - Section of This Document
-------- -------------------------------
0x001 RBridge Channel Error - Section 3IANA Considerations for RBridge Channel protocol numbers are provided in Section 7, and those include provisions for Private Use protocol numbers 🦋 Because different uses of Private Use RBridge Channel protocol numbers may conflict, such use MUST be within a private network. It is the responsibility of the private network manager to avoid conflicting use of these code points and unacceptable burdens within the private network from their use.
2.1.2. Inner Ethernet Header 💖
The special Inner.MacDA is the All-Egress-RBridges multicast Media Access Control (MAC) address. It signals that the frame is intended for the egress (decapsulating) RBridge itself, or for the egress RBridges themselves if the frame is multi-destination. (This address is called the All-ESADI-RBridges address in [RFC6325].) The RBridge-Channel Ethertype indicates that the frame is an RBridge Channel message. The only other Ethertype currently specified for use with the All-Egress-RBridges Inner.MacDA is L2-IS-IS, to indicate an ESADI frame [RFC6325]. In the future, additional Ethertypes may be specified for use with the All-Egress-RBridges multicast address.
The RBridge originating the channel message selects the Inner.MacSA. The Inner.MacSA MUST be set by the originating RBridge to a MAC address unique within the campus owned by the originating RBridge. This MAC address can be considered, in effect, the MAC address of a virtual internal end station that handles the RBridge Channel frames originated by or destined for that RBridge. It MAY be the same as the Inner.MacSA used by the RBridge when it originates ESADI frames [RFC6325].
2.1.3. Inner.VLAN Tag 🍓
As with all frames formatted to be processed as a TRILL Data frame, an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than 0x8100 or stacked tags is beyond the scope of this document, but is an obvious extension.
Multi-destination RBridge Channel messages are, like all multi-destination TRILL Data messages, VLAN scoped, so the Inner.VLAN ID MUST be set to the VLAN of interest. To the extent that distribution tree pruning is in effect in the campus, such channel messages may only reach RBridges advertising that they have connectivity to that VLAN.
For channel messages sent as known unicast TRILL Data frames, the default value for the Inner.VLAN ID is VLAN 1, but particular RBridge Channel protocols MAY specify other values.
The Inner.VLAN also specifies a three-bit frame priority, and the following recommendations apply to it 👑
- For one-hop channel messages critical to network connectivity, such as one-hop BFD for rapid link-failure detection in support of TRILL IS-IS, the RECOMMENDED priority is 7.
- For single and multi-hop unicast channel messages important to network operation but not critical for connectivity, the RECOMMENDED priority is 6.
- For other unicast channel messages and all multi-destination channel messages, it is RECOMMENDED that the default priority zero be used. In any case, priorities higher than 5 SHOULD NOT be used for such frames.
There is one additional bit in a VLAN tag value between the 12-bit VLAN ID and 3-bit priority: the Drop Eligibility Indicator (DEI) [RFC7180]. It is RECOMMENDED that this bit be zero for the first two categories of channel messages listed immediately above. The setting of this bit for channel messages in the third category may be dependent on the channel protocol, and no general recommendation is made for that case.
2.2. TRILL Header for RBridge Channel Messages 🧚♀️
After the outer Link Header (which, for an Ethernet link, ends with the TRILL Ethertype) and before the encapsulated frame, the channel message's TRILL Header initially appears as follows:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0| R |M| Op-Len | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RBridge Channel TRILL Header FieldsThe TRILL Header version (V) MUST be zero. The R bits are reserved. The M bit is set appropriately, as the channel message is to be forwarded as known destination unicast (M=0) or multi-destination (M=1), regardless of the fact that the Inner.MacDA is always the All-Egress-RBridges multicast address. Op-Len is set appropriately for the length of the TRILL Header extensions area, if any, all as specified in [RFC6325].
When an RBridge Channel message is originated, the Hop Count field defaults to the maximum value, 0x3F, but particular RBridge Channel protocols MAY specify other values. For messages sent a known number of hops, such as one-hop messages or a two-hop self-addressed message intended to loop back through an immediate neighbor RBridge, setting the Hop Count field in the TRILL Header to the maximum value and checking its value on receipt provides an additional validity check, as discussed in [RFC5082], where this type of field is referred to as "TTL" or "Hop Limit".
The RBridge originating a channel message places a nickname that it holds in the Ingress Nickname field.
There are several cases for the Egress Nickname field. If the channel message is multi-destination, then the Egress Nickname designates the distribution tree to use. If the channel message is a multi-hop unicast message, then the Egress Nickname is a nickname of the target RBridge. This includes the special case of a message intended to loop back from an immediate neighbor, where the originator places one of its own nicknames in both the Ingress Nickname and Egress Nickname fields. If the channel message is a one-hop unicast message, there are two possibilities for the Egress Nickname:
- The Egress Nickname can be set to a nickname of the target neighbor RBridge.
- The special nickname Any-RBridge may be used. RBridges supporting the RBridge Channel facility MUST recognize the Any-RBridge special nickname and accept TRILL Data frames having that value in the Egress Nickname field as being sent to them as the egress. Thus, for such RBridges, using this egress nickname guarantees processing by an immediate neighbor regardless of the state of nicknames.
2.3. Ethernet Link Header and Trailer 🌈
An RBridge Channel frame has the usual Link Header and Link Trailer for a TRILL Data frame, depending on the type of link on which it is sent.
For an Ethernet link [RFC6325], the Outer.MacSA is the MAC address of the port from which the frame is sent. The Outer.MacDA is the MAC address of the next-hop RBridge port for unicast RBridge Channel messages, or the All-RBridges multicast address for multi-destination RBridge Channel messages. The Outer.VLAN tag specifies the designated VLAN for that hop, and the priority should be the same as in the Inner.VLAN tag. However, the output port may have been configured to strip VLAN tags, in which case no Outer.VLAN tag appears on the wire. And the Link Trailer is the Ethernet FCS.
2.4. Special Transmission and Rate Considerations
okay so if a multi-hop RBridge Channel message hits an RBridge, it gets forwarded the exact same way as any TRILL Data frame 💅. And if it gets forwarded, it's going over a link that already made it into the routing topology because it was in the Report state, per [RFC7177]. iconic consistency 🦋
BUT single-hop messages get their own special treatment 👀 because some channel protocols want to send RBridge Channel messages over a link that isn't fully up yet. So if the channel protocol says it's allowed, the source RBridge that made the message can try sending it to a next-hop RBridge while the link is in the Detect or 2-Way state (see [RFC7177]), and also when it's in the Report state. These messages can also go over point-to-point links that aren't in the Up state. the flexibility is giving 🌈
Real talk though, RBridge Channel messages are a burden on the RBridges and the links in a campus 🥺 so they should be rate limited, especially if they're sent as high priority, multi-destination, or multi-hop frames, or if they have an RBridge Channel Alert extended header flag set. Check out Section 6, "Congestion Considerations" 🫶
3. Processing RBridge Channel TRILL Data Messages
RBridge Channel TRILL Data messages are built to look like regular TRILL Data frames and, as much as practical, get forwarded like them ✨ So when a channel message shows up, an RBridge does the usual first checks and makes the same forwarding and/or decapsulation decisions it would for a regular TRILL Data frame [RFC6325], with the following exceptions for RBridges implementing the RBridge Channel facility 🎀
- An RBridge implementing the RBridge Channel facility MUST recognize the
Any-RBridgeegress nickname in TRILL Data frames, decapsulating such frames if they pass the other checks. (Such a frame can't be a valid multi-destination frame because theAny-RBridgenickname isn't a valid distribution tree root 🙈) - If an RBridge Channel Alert extended header flag is set, then the RBridge MUST process the RBridge Channel message as described below, even if it isn't egressing the frame. If it is egressing the frame, then no extra processing beyond egress processing is needed, even if an RBridge Channel Alert flag is set 💜
- On decapsulation, the special
Inner.MacDAvalue ofAll-Egress-RBridgesMUST be recognized to trigger checking theInner.Ethertypeand processing as an RBridge Channel message if that Ethertype isRBridge-Channel🧚
RBridge Channel messages SHOULD only be sent to RBridges that advertise support for the channel protocol involved, as described in Section 5 🍓
All RBridges supporting the RBridge Channel facility MUST recognize the RBridge-Channel inner Ethertype. no exceptions bestie 💖
3.1. Processing the RBridge Channel Header
So once an RBridge knows it has an RBridge Channel message, the egress RBridge (and any transit RBridge if an RBridge Channel Alert bit is set in the TRILL Header) looks at the CHV (RBridge Channel Header Version) and Channel Protocol fields 👀
If any of the following conditions happen at an egress RBridge, the frame is not processed, an error may be generated as specified in Section 3.2, and the frame is discarded 💀 Same goes for a transit RBridge if the RBridge Critical Channel Alert flag is set [RFC7179]. BUT, if these conditions are detected at a transit RBridge that's examining the message because the RBridge Non-critical Channel Alert flag is set [RFC7179] and the RBridge Critical Channel Alert flag is not set, no error is generated and the frame still gets forwarded normally. chill energy 🌸
Error Conditions:
- The Ethertype is not
RBridge-Channeland not any other Ethertype the RBridge knows is usable with theAll-Egress-RBridgesInner.MacDA, or the frame is so short that the Ethertype is truncated. - The
CHVfield is non-zero, or the frame is so short that the version zero Channel Header is truncated. - The Channel Protocol field is a reserved value or a value unknown to the processing RBridge.
- The
ERRfield is non-zero, and Channel Protocol is a value other than0x001. - The RBridge Channel Header
NAflag is set to one, indicating that the frame should have been received as a native frame rather than a TRILL Data frame.
If the CHV field and NA flag are zero and the processing RBridge recognizes the Channel Protocol value, it processes the message according to that channel protocol ✨ The processing model is basically: the received frame, starting with and including the TRILL Header, gets delivered to the Channel protocol, along with a flag saying whether this is (a) transit RBridge processing because an RBridge Channel Alert flag was set, or (b) egress processing 🦋
Errors inside a recognized Channel Protocol are handled by that channel protocol itself and do not produce RBridge Channel Error frames. the channel protocol handles its own drama 💅
3.2. RBridge Channel Errors
A bunch of problems at the RBridge Channel level cause an RBridge Channel Error frame to get sent back, unless one of these applies: (a) the "SL" (Silent) flag is a one in the channel message where the problem was detected, (b) the processing is happening because the RBridge Non-critical Channel Alert flag is set, (c) the frame in error seems to be an RBridge Channel Error frame itself (it has a non-zero ERR field or a Channel Protocol of 0x001), or (d) the error is suppressed because of rate limiting 🙈
An RBridge Channel Error frame is a multi-hop unicast RBridge Channel message with the Ingress Nickname set to a nickname of the RBridge that detected the error, and the Egress Nickname set to the value of the Ingress Nickname in the channel message where the error was detected 🎀 No per-hop transit processing is specified for these error frames, so the RBridge Channel Alert extended header flags SHOULD, if an extension is present, be set to zero. The SL and MH flags SHOULD be set to one, the NA flag MUST be zero, and the ERR field MUST be non-zero as described below 🌈 For the protocol-specific data area, an RBridge Channel Message Error frame has at least the first 256 bytes (or less, if less are available) of the erroneous decapsulated channel message, starting with the TRILL Header. (Note: the TRILL Header doesn't include the TRILL Ethertype that's part of the Link Header on Ethernet links 🧚)
These are the ERR values that are specified:
ERR RBridge Channel Error Code Meaning
--- ----------------------------------
0 No error
1 Frame too short (truncated Ethertype or Channel Header)
2 Unrecognized Ethertype
3 Unimplemented value of CHV
4 Wrong value of NA flag
5 Channel Protocol is reserved or unimplemented
6-14 Unassigned (see Section 7)
15 Reserved (see Note)
Note: Intended to be allocated by Standards Action for an error
code expansion feature when it appears likely that all
other available error codes are being allocated.All RBridges implementing the RBridge Channel feature MUST recognize the RBridge Channel Error protocol value (0x001). They MUST NOT generate an RBridge Channel Error message in response to an RBridge Channel Error message, that is, a channel message with a protocol value of 0x001 or with a non-zero ERR field 🛑💖 errors don't get to make more errors, periodt 👑
4. Native RBridge Channel Frames ✨
okay so the other parts of this doc cover the non-native RBridge Channel messages, the ones dressed up as TRILL Data frames and zipping between RBridges 🦋. this section is about the native ones and what's actually different about them bestie 💅
if the channel protocol involved allows it, native RBridge Channel messages can go between end stations and RBridges that are directly connected over a link, in either direction 🫶. on an Ethernet link, these native frames wear the RBridge-Channel Ethertype and look basically like the encapsulated frame inside an RBridge Channel message, except for these differences:
- TRILL doesn't need a VLAN tag on native RBridge Channel frames 🎀. port configuration, link characteristics, or the channel protocol involved might still require tagging though.
- if the frame is unicast, the destination MAC address is the unicast MAC address of the RBridge or end-station port it's meant for. if an end station multicasts to all the RBridges on a link that support an RBridge Channel protocol using this transport, the destination MAC address is the All-Edge-RBridges multicast address (see Section 7). a native RBridge Channel frame received at an ingress RBridge gets discarded if its destination MAC address is neither the unicast address of the port nor the multicast address All-Edge-RBridges. if an RBridge multicasts to all the devices TRILL considers to be end stations on a link that support an RBridge Channel protocol using this transport, the destination MAC address is the TRILL-End-Stations multicast address (see Section 7). a native RBridge Channel frame received at an end station gets discarded if its destination MAC address is neither the unicast address of the port nor the multicast address TRILL-End-Stations 🙈
- the RBridge-Channel outer Ethertype must be present. in the future, other protocols might use the All-Edge-RBridges and/or TRILL-End-Stations multicast addresses on native frames distinguished by different Ethertypes ✨
- the NA or Native bit in the RBridge Channel Header flags MUST be a one 👑
- there might be additional tags present between the Outer.MacDA, Outer.MacSA pair, and the RBridge-Channel Ethertype.
the RBridge Channel protocol number space for native RBridge Channel messages and TRILL Data formatted RBridge Channel messages is the same 🌈. if the channel protocol involved provides for it, receiving a native RBridge Channel frame MAY lead to the generation and transmission of one or more Inter-RBridge Channel frames. decapsulating and processing a TRILL Data RBridge Channel frame MAY, if the channel protocol involved provides for it, result in sending one or more native RBridge Channel frames to one or more end stations. so there could be an RBridge Channel protocol where a message is sent (1) from an origin RBridge where it's created, (2) through one or more transit RBridges, and (3) from a final RBridge as a native RBridge Channel message to an end station (or the reverse of that three-part path) 🧚 however, to pull this off, the RBridge Channel protocol involved must be implemented at the RBridge where the channel message changes between a native frame and a TRILL Data format frame, and that RBridge must change the channel message itself. at a minimum, it complements the NA flag in the Channel Header and makes appropriate MAC address changes.
an erroneous native channel message results in a native RBridge Channel Error message under the same conditions where a TRILL Data RBridge Channel message would result in a TRILL Data RBridge Channel Error message 💀 but in a native RBridge Channel Error message, the NA flag MUST be one. also, since native RBridge Channel protocol frames don't have a TRILL Header, the beginning part of the frame where the error was detected, which gets included in native RBridge Channel Error frames, starts with the RBridge Channel Header (including the RBridge-Channel Ethertype). the destination MAC address of these error messages is set to the source MAC address of the native RBridge Channel message that was in error.
there's no mechanism to stop end stations from directly exchanging native RBridge Channel messages, but that usage is beyond the scope of this document 🍓
5. Indicating Support for RBridge Channel Protocols
support for RBridge Channel protocols is indicated by the presence of one or more TLVs and/or sub-TLVs in an RBridge's Link State PDU (LSP) as documented in [RFC7176] 📜
RBridge Channel protocols 0 and 0xFFF are reserved. protocol 1, the RBridge Channel Error protocol, MUST be implemented as part of the RBridge Channel feature ✨ so if an RBridge supports the RBridge Channel feature, it should be advertising support for protocol 1 and not advertising support for protocols 0 or 0xFFF in its LSP. however, indication of support or non-support for RBridge Channel protocol 1 is ignored on receipt, and support for it is always assumed if support for any RBridge Channel is indicated in the RBridge's LSP 🌸
6. Congestion Considerations
the bandwidth resources used by RBridge Channel protocols are recommended to be small compared to the total bandwidth of the links they traverse 🌊 when doing network planning, you need to account for the bandwidth requirements of TRILL Data, TRILL IS-IS, TRILL ESADI, RBridge Channel protocol traffic, and any other link-local traffic.
specifications for particular RBridge Channel protocols MUST consider congestion and bandwidth usage implications and provide guidance on bandwidth or packet-frequency management 💅 RBridge Channel protocols can have built-in bandwidth management in their protocols. outgoing channel messages SHOULD be rate-limited, by configuring the underlying protocols or otherwise, so that aggressive connectivity verification or other applications don't eat up excessive bandwidth, cause congestion, or turn into denial-of-service attacks 🚫
if these conditions can't be followed, an adaptive loss-based scheme SHOULD be applied to congestion-control outgoing RBridge Channel traffic. it should compete fairly, taking into account packet priorities and drop eligibility as indicated in the Inner.VLAN, with TCP or similar traffic within an order of magnitude 🦋 one method of determining an acceptable bandwidth for RBridge Channel traffic is described in [RFC5348], and other methods exist. for example, bandwidth or packet-frequency management can include any of the following: a negotiation of transmission interval/rate such as the one provided in BFD [RFC5880], a throttled transmission rate on "congestion detected" situations, a gradual ramp-up after shutdown due to congestion and until basic connectivity is verified, and other mechanisms 🎀
connectivity-checking applications such as BFD [RFC5880] SHOULD be rate-limited to below 5% of the bitrate of the associated link or links. for this purpose, the mean or sustained bitrate of the link or links is used 📊
incoming RBridge Channel messages MAY be rate-limited as protection against denial-of-service attacks 🛡️ this throttling of incoming messages SHOULD honor packet priorities and drop eligibility indications as indicated in the Inner.VLAN, preferentially discarding drop-eligible and lower-priority packets 🫶
7. Allocation Considerations
the following subsections give IANA and IEEE allocation considerations 🌈 in this document, the allocation procedure specifications are as defined in [RFC5226].
7.1. IANA Considerations
IANA has allocated a previously unassigned TRILL Nickname as follows:
Any-RBridge 0xFFC0IANA has added "All-Egress-RBridges" to the TRILL Parameter Registry as an alternative name for the "All-ESADI-RBridges" multicast address 🧚
IANA has allocated two previously unassigned TRILL multicast addresses as follows:
TRILL-End-Stations 01-80-C2-00-00-45
All-Edge-RBridges 01-80-C2-00-00-46IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Protocols, with initial contents as follows:
Protocol Description Reference
-------- ----------- ---------
0x000 Reserved; not to be allocated (This document)
0x001 RBridge Channel Error (This document)
0x002-0x0FF Unassigned (1)
0x100-0xFF7 Unassigned (2)
0xFF8-0xFFE Reserved for Private Use
0xFFF Reserved; not to be allocated (This document)(1) RBridge Channel protocol code points from 0x002 to 0x0FF require a Standards Action, as modified by [RFC7120], for allocation.
(2) RBridge Channel protocol code points from 0x100 to 0xFF7 are RFC Required to allocate a single value, or IESG Approval to allocate multiple values.
IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Header Flags with initial contents as follows:
Flag Bit Mnemonic Allocation
-------- -------- ----------
0 SL Silent
1 MH Multi-hop
2 NA Native
3-11 - Unassignedallocation of an RBridge Channel Header Flag is based on IETF Review 🔥
IANA has created an additional sub-registry in the TRILL Parameter Registry for RBridge Channel Error Codes, with initial contents as listed in Section 3.2 above and with available values allocated by Standards Action, as modified by [RFC7120] 💜
7.2. IEEE Registration Authority Considerations
the IEEE Registration Authority has assigned the Ethertype 0x8946 for TRILL RBridge Channel 👑
8. Security Considerations 🔐
okay bestie, let's talk security 🫶 No general integrity, authentication, or encryption mechanisms are provided here for RBridge Channel messages 💀. If a particular RBridge Channel protocol needs those services, that channel protocol MUST supply them itself ✨. The BFD Authentication mechanism [RFC5880] is one example of how that works.
See [RFC6325] for the general TRILL security considerations 🦋. As that doc explains, TRILL doesn't protect against forging the Ingress Nickname in a TRILL Data formatted channel message, or the Outer.MacSA in a native RBridge Channel frame on an Ethernet link 😭. That can lead to misdirected return responses or error messages 🙈. Link-level security protocols can be used to authenticate the origin station on a link and protect against attacks on links 🔥. Also check out Section 6 for the congestion stuff 🌸.
If indications of RBridge Channel Protocol support are improperly absent from an RBridge's LSP, it could deny all RBridge Channel services to that RBridge, like some BFD services 💔. And if a particular RBridge Channel protocol is incorrectly not advertised as supported, it could deny that channel protocol's service to the RBridge in question 😤.
Incorrect indication of RBridge Channel Protocol support, or incorrectly asserting support for a channel protocol, could encourage RBridge Channel messages to be sent to an RBridge that doesn't support the channel feature or the particular channel protocol used 👀. The inner frame of those messages could get decapsulated, and then that inner frame could be sent out all ports that are Appointed Forwarders for the frame's Inner.VLAN 🫠. But honestly, this is unlikely to cause much harm 💅. There are two possibilities:
- (a) if end stations don't recognize the
RBridge-Channel Ethertypeof the frame, they'll drop it ✨ - (b) if end stations recognize the
RBridge-Channel Ethertypeand the channel protocol indicated in the frame, they should refuse to process the frame due to an incorrect value of theRBridge Channel Header NA flag🌈
9. References
9.1. Normative References
[IS-IS] International Organization for Standardization,
"Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", Second
Edition, November 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", RFC
5348, September 2008.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, January 2014.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, May 2014.
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C.
Bestler, "Transparent Interconnection of Lots of Links
(TRILL): Header Extension", RFC 7179, May 2014.9.2. Informative References
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5882] Katz, D. and D. Ward, "Generic Application of
Bidirectional Forwarding Detection (BFD)", RFC 5882, June
2010.
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
A. Banerjee, "Transparent Interconnection of Lots of Links
(TRILL): Clarifications, Corrections, and Updates", RFC
7180, May 2014.10. Acknowledgments 🫶
The authors gratefully acknowledge the comments and contributions of the follows, listed in alphabetic order: Stewart Bryant, Somnath Chatterjee, Adrian Farrel, Stephen Farrell, Miguel A. Garcia, Anoop Ghanwani, Brian Haberman, Rakesh Kumar, Barry Leiba, and Tissa Senevirathne 💖.
Authors' Addresses 📮
Donald Eastlake 3rd
Huawei R&D USA
155 Beaver Street
Milford, MA 01757
USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Vishwas Manral
Ionos Corp.
4100 Moorpark Ave.
San Jose, CA 95117
USA
EMail: vishwas@ionosnetworks.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56622310
EMail: liyizhou@huawei.com
Sam Aldrin
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1-408-330-5000
EMail: sam.aldrin@huawei.com
Dave Ward
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
EMail: dward@cisco.com📦 where this page comes from
- ietf: rfc7178 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms