RFC 8381

Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol

📅 published May 2018, from ietf

Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol 🦋

Bestie, the header is giving: this is IETF RFC 8381, published as a Standards Track document in May 2018 by the IETF, under ISSN 2070-1721. The authors are D. Eastlake 3rd, Y. Li, W. Hao, and A. Banerjee, with Huawei and Cisco listed as their affiliations. The header doesn't list anything it obsoletes or updates. ✨

Abstract 🌸

okay so TRILL (Transparent Interconnection of Lots of Links) is a protocol that runs on devices called TRILL switches, or RBridges (Routing Bridges). TRILL has a general mechanism called an RBridge Channel, which lets RBridges in the same campus, and RBridges plus end stations on the same link, send typed messages to each other. This document is the spec for sending vendor-specific messages over that RBridge Channel facility. 💅

Status of This Memo 🎀

This is an Internet Standards Track document. 🌈

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841. 🫶

For the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8381. 🔥

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🧚

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 💀

Table of Contents 🍓

1. Introduction ....................................................2
   1.1. Terminology and Acronyms ...................................3
2. Vendor Channel Packet Format ....................................3
3. Vendor Channel Errors ...........................................6
   3.1. Sending an Error Response ..................................7
4. IANA Considerations .............................................9
5. Security Considerations .........................................9
6. References .....................................................10
   6.1. Normative References ......................................10
   6.2. Informative References ....................................10
Authors' Addresses ................................................11

1. Introduction ✨

okay bestie, TRILL is implemented by devices called TRILL switches or RBridges (Routing Bridges) [RFC6325] [RFC7780]. It gives you efficient least-cost transparent routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. Iconic. 👑

The TRILL protocol has an RBridge Channel facility [RFC7178] that supports typed message transmission between RBridges in the same campus, and between RBridges and end stations on the same link. This document specifies a way to send messages defined by a particular organization. That organization is identified by an OUI (Organizationally Unique Identifier) [RFC7042] or a CID (Company Identifier) [802], and the messages travel over the RBridge Channel facility. These organization-specific messages could be used for things like vendor-specific diagnostic or control messages, so yes, very useful. 🦋

Also, a range of RBridge Channel protocol numbers is available based on RFC publication. If you plan to use the RBridge Channel facility, you're encouraged to document your use in an RFC, and to use RBridge Channel protocol numbers based on that RFC publication. Put it on paper, babe. 📝

1.1. Terminology and Acronyms 🌷

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🙈

This document uses the acronyms defined in [RFC6325], plus these extra ones:

  • CID - Company Identifier [802]
  • FGL - Fine-Grained Labeling
  • OUI - Organizationally Unique Identifier [RFC7042]
  • TRILL switch - An alternative term for an RBridge

2. Vendor Channel Packet Format 🧚

So here's the vibe of an RBridge Channel packet on a link between TRILL switches (RBridges). It's shown in Figure 1 below. When an RBridge Channel message goes between an RBridge and an end station on the same link (either direction), it's called a Native RBridge Channel message. In that case the TRILL Header, which includes the Inner Ethernet Addresses and Data Label area, gets omitted, as Figure 2 shows. The type of RBridge Channel packet is set by a Protocol field in the RBridge Channel Header, and that field tells you how to read the Channel-Protocol-Specific Payload. See [RFC7178]. 💖

Packet structure (Figure 1):

                   +-----------------------------------+
                   |           Link Header             |
                   +-----------------------------------+
                   |           TRILL Header            |
                   +-----------------------------------+
                   |     Inner Ethernet Addresses      |
                   +-----------------------------------+
                   |     Data Label (VLAN or FGL)      |
                   +-----------------------------------+
                   |      RBridge Channel Header       |
                   +-----------------------------------+
                   | Channel-Protocol-Specific Payload |
                   +-----------------------------------+
                   |    Link Trailer (FCS if Ethernet) |
                   +-----------------------------------+

                Figure 1: RBridge Channel Packet Structure

Message structure (Figure 2):

                   +-----------------------------------+
                   |           Link Header             |
                   +-----------------------------------+
                   |      RBridge Channel Header       |
                   +-----------------------------------+
                   | Channel Protocol Specific Payload |
                   +-----------------------------------+
                   |    Link Trailer (FCS if Ethernet) |
                   +-----------------------------------+

            Figure 2: Native RBridge Channel Message Structure

Figure 3 below zooms in on the RBridge Channel Header and Channel Protocol Specific Payload from above, for the Vendor-Specific RBridge Channel Tunnel Protocol. 0x8946 is the Ethertype [RFC7042] that the IEEE assigned to the RBridge Channel protocol. 🎀

                           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
    RBridge Channel Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    RBridge-Channel (0x8946)   |  0x0  | Channel Protocol=0x008|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Flags        |  ERR  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    RBridge Channel Protocol Specific:
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |     Vendor ID = OUI/CID       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |OUI/CID (cont.)|     VERR      | Sub-Protocol  | Sub-Version   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Vendor-Protocol-Specific Data
      |
      |  ...

                Figure 3: Channel Tunnel Message Structure

Here's what the fields in Figure 3 mean for the Vendor RBridge Channel Protocol:

  • Channel Protocol: The RBridge Channel Protocol value allocated for the Vendor Channel (see Section 4).
  • Vendor ID: This field says which vendor is specifying the particular use or uses of the Vendor Channel. The vendor that the OUI or CID in this field was allocated to is in charge of specifying Vendor Channel messages using that identifier. What it means depends on the first byte of this field, like so:
    • OUI: When the bottom two bits of the first byte of the Vendor ID are zero (that is, the first byte is 0bXXXXXX00), the Vendor ID is an OUI.
    • CID: When the bottom two bits of the first byte are a one followed by a zero (that is, the first byte is 0bXXXXXX10), the Vendor ID is a CID.
    • Other: Any other values of the bottom two bits of the first byte of the Vendor ID are invalid, and a VERR of 2 MUST be returned, subject to possible rate limiting (see Section 3).
  • VERR: Vendor Channel Error. See Section 3.
  • Sub-Protocol: Technically, the vendor specifying their use of the Vendor Channel can do whatever they want with the bits after the VERR field. But it is strongly RECOMMENDED that they use the sub-protocol and sub-version fields indicated, so that multiple and evolving uses can be specified based on a single OUI. 🫶
  • Sub-Version: See the explanation above of the Sub-Protocol field. This field indicates the version of the particular vendor's Sub-Protocol. 🌈

3. Vendor Channel Errors 🚨

okay bestie, so the VERR field has a whole guest list 💅 Values 0x0 through 0x0F (inclusive) and 0xFF are reserved for the IETF to spec out, so check out Section 4 🔥. Every other VERR value is free real estate for whatever the vendor wants 🌸. BUT there's one big no-no: a Vendor Channel implementation MUST NOT send a Vendor Channel Error in response to a Vendor Channel message with a nonzero VERR. Not allowed, periodt 🙅‍♀️

Here are the VERR values the IETF has specced so far 👑

0. In Vendor Channel messages, VERR is zero unless the packet is reporting an error. So zero is basically the "all good" vibe 💖

1. The value one means the RBridge-Channel-Specific Data is less than 4 bytes 😱 That means at least the VERR byte and maybe some or all of the OUI got chopped off ✂️ If an RBridge that implements the Vendor Channel facility gets a message like this, it MUST expand it to reach through the VERR field, set that field to one, and return the packet as described in Section 3.1 💀

2. The OUI/CID field value is unknown 🤷‍♀️ If an RBridge implements the Vendor Channel facility and gets a Vendor Channel packet with a zero VERR field, an OUI/CID it doesn't recognize, and the SL flag set to zero in the RBridge Channel Header, it MUST set the VERR field to the value two and return the packet as described in Section 3.1 🎀

3. The value 3 means the Sub-Protocol field value is unknown 🧩 An RBridge SHOULD set the VERR field to 3 and return the packet as described in Section 3.1 if it implements the Vendor Channel facility and receives a Vendor Channel packet that meets all of these conditions:

  • (a) a zero VERR field in the RBridge Channel Header,
  • (b) a zero SL flag in the RBridge Channel Header,
  • (c) an OUI/CID that it implements, and
  • (d) a Sub-Protocol field value it does not recognize even though it implements and uses the Sub-Protocol field.

4. The value 4 means the Sub-Version field value is unknown 🌈 An RBridge SHOULD set the VERR field to 4 and return the packet as described in Section 3.1 if it implements the Vendor RBridge Channel facility and receives a Vendor Channel packet that meets all of these conditions:

  • (a) a zero VERR field in the RBridge Channel Header,
  • (b) a zero SL flag in the RBridge Channel Header,
  • (c) an OUI/CID and Sub-Protocol that it implements, and
  • (d) a Sub-Version field value it does not recognize even though it implements and uses the Sub-Version field.

Uniform error handling is generally a great idea for maintenance and understandability 🧠 However, SHOULD is the word for errors 3 and 4 above, because as long as each message is distinguished by a vendor's OUI/CID, it's up to that vendor to pick between standard and nonstandard error handling 💅

3.1. Sending an Error Response ✉️

The IETF-specified Vendor Channel errors get sent back in response to a received RBridge Channel packet. You set the VERR field as specified above and then modify the packet as described below. (The ERR field will be zero, because if it weren't, the packet would have been handled at the general RBridge Channel level instead of getting passed down to the Vendor Channel level 🙃)

The RBridge Channel Header gets modified by setting the SL flag. (The flags in the Channel Header and the semantics of the SL flag are specified in [RFC7178].)

  • If an error 1 is being generated because of truncation, the RBridge-Channel-Specific Data area is extended to include the VERR byte.
  • If a Vendor Channel message was sent between RBridges, the TRILL Header is modified by (1) clearing the M bit, (2) setting the egress nickname to the ingress nickname as received, (3) setting the ingress nickname to a nickname held by the TRILL switch sending the error packet, and (4) setting the hop count to the usual value on TRILL Data packets used by the TRILL switch sending the error packet.
  • If a Vendor Channel message was sent between an RBridge and an end station in either direction, the outer MAC addresses are modified by (1) setting the Outer.MacDA to the Outer.MacSA as received and (2) setting the Outer.MacSA to the MAC address of the port of the TRILL switch or end station sending the error packet.
  • The priority of the error response message MAY be reduced from the priority of the Vendor Channel message causing the error, unless it was already minimum priority. The Drop Eligibility Indicator bit MAY be set in an error response. (See Section 4.1.1 of [RFC6325].)
  • Vendor Channel error responses MAY be rate-limited.

It's generally expected that the entire packet where an error was detected gets sent back, modified as above, as the protocol-specific payload. That makes it way easier to match error responses with the messages that were sent 🔍 Except for errors 1 and 2, though, it's up to the vendor specifying how their Vendor RBridge Channel messages are used 💜

Heads up, bestie 🙈 If you receive a Vendor Channel error message with error 1 (the truncation error), you cannot trust the apparent "OUI/CID" in that message. Don't go by it!

4. IANA Considerations 🏛️

IANA has allocated 0x008 for the Vendor-Specific RBridge Channel Protocol, from the range of RBridge Channel protocols allocated by Standards Action 🍓

IANA has also set up a subregistry in the TRILL Parameters registry, indented under "RBridge Channel Error Codes" after "RBridge Channel SubError Codes" 📋

Registry: Vendor RBridge Channel Error Codes
Registration Procedures: Standards Action
Reference: RFC 8381

      Code      Description                     Reference
      ----      -----------                     ---------
      0x00      No error                        RFC 8381
      0x01      Message too short               RFC 8381
      0x02      Unknown OUI/CID                 RFC 8381
      0x03      Unknown Sub-Protocol            RFC 8381
      0x04      Unknown Sub-Version             RFC 8381
     0x05-0x0F  Unassigned                      -
     0x10-0xFE  Reserved for vendor use         RFC 8381
      0xFF      Reserved                        RFC 8381

5. Security Considerations 🔐

See [RFC6325] for general TRILL Security Considerations 🛡️

See [RFC7178] for general RBridge Channel Security Considerations 🛡️

Neither the Vendor-Specific RBridge Channel Protocol nor the basic RBridge Channel Protocol [RFC7178] provide any security assurances or features. Lowkey a big deal! (The basic RBridge Channel Protocol's first use was as an envelope for Bidirectional Forwarding Detection (BFD) messages [RFC7175], and those provide their own security 🔒) Any security that's needed can be provided by fields or processing within the Vendor-Protocol-Specific Data, which is outside the scope of this document 🙅‍♀️ Alternatively, or in addition, use of a Vendor Channel MAY be nested inside the RBridge Channel Header Extension Protocol [RFC7978]. This can provide some security services ✨

6. References 📚

6.1. Normative References

6.2. Informative References

Authors' Addresses 💌

Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA  01757
United States of America

Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com


Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China

Phone: +86-25-56622310
Email: liyizhou@huawei.com


Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China

Phone: +86-25-56623144
Email: haoweiguo@huawei.com


Ayan Banerjee
Cisco

Email: ayabaner@cisco.com
📦 where this page comes from