doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc7178.txt b/doc/rfc/rfc7178.txt
new file mode 100644
index 0000000..5ca4495
--- /dev/null
+++ b/doc/rfc/rfc7178.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
+Request for Comments: 7178                                        Huawei
+Category: Standards Track                                      V. Manral
+ISSN: 2070-1721                                              Ionos Corp.
+                                                                   Y. Li
+                                                               S. Aldrin
+                                                                  Huawei
+                                                                 D. Ward
+                                                                   Cisco
+                                                                May 2014
+
+
+         Transparent Interconnection of Lots of Links (TRILL):
+                        RBridge Channel Support
+
+Abstract
+
+   This document specifies a general channel mechanism for sending
+   messages, such as Bidirectional Forwarding Detection (BFD) messages,
+   between Routing Bridges (RBridges) and between RBridges and end
+   stations in an RBridge campus through extensions to the Transparent
+   Interconnection of Lots of Links (TRILL) protocol.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7178.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 1]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to 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 are provided without 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 ...............................................20
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 2]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+1.  Introduction
+
+   RBridge campuses provide transparent least-cost forwarding using the
+   Transparent Interconnection of Lots of Links (TRILL) protocol that
+   builds 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.  However, the TRILL
+   base protocol standard [RFC6325] provides only for TRILL Data
+   messages and TRILL IS-IS messages.
+
+   This document specifies a general channel mechanism for the
+   transmission of other messages within an RBridge campus, such as BFD
+   [RFC5880] messages, (1) between RBridges and end stations that are
+   directly connected on the same link and (2) between RBridges.  This
+   mechanism supports a requirement to be able to operate with minimal
+   configuration.
+
+1.1.  RBridge Channel Requirements
+
+   It is anticipated that various protocols operating at the TRILL layer
+   will be desired in RBridge campuses.  For example, there is a need
+   for rapid-response continuity checking with a protocol such as BFD
+   [RFC5880] [RFC5882] and for a variety of optional reporting.
+
+   To avoid the requirement to design and specify a way to carry each
+   such protocol, this document specifies a general channel for sending
+   messages between RBridges in a campus at the TRILL level by extending
+   the TRILL protocol.  To accommodate a wide variety of protocols, this
+   RBridge Channel facility accommodates all the regular modes of TRILL
+   Data transmission including single- and multiple-hop unicast as well
+   as VLAN-scoped multi-destination distribution.
+
+   To minimize any unnecessary burden on transit RBridges and to provide
+   a more realistic test of network continuity and the like, RBridge
+   Channel messages are designed to look like TRILL Data frames and, in
+   the case of multi-hop messages, can normally be handled by transit
+   RBridges as if they were TRILL Data frames; however, to enable
+   processing at transit RBridges when required by particular messages,
+   they may optionally use the RBridge Channel Alert TRILL extended
+   header flags [RFC7179] that causes a transit RBridge implementing the
+   flag to more closely examine a flagged frame.
+
+   This document 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 provided for by the
+   protocol involved.  For the most part, this format is the same as the
+   format that is encapsulated by TRILL Data for inter-RBridge Channel
+   messages.
+
+
+
+Eastlake, et al.             Standards Track                    [Page 3]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   Each particular protocol using the RBridge Channel facility will
+   likely use only a subset of the facilities specified herein.
+
+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
+   indicate a special channel message, an RBridge Channel message is
+   indicated by a special multicast Inner.MacDA and 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
+   with the additions listed below.
+
+      BFD - Bidirectional Forwarding Detection
+
+      CHV - Channel Header Version
+
+      MH - Multi-Hop
+
+      NA - Native
+
+      SL - Silent
+
+2.  Inter-RBridge Channel Messages
+
+   Channel messages between RBridges are transmitted as TRILL Data
+   frames.  (For information on channel messages that can be transmitted
+   between RBridges and end stations that are directly connected by a
+   link, see Section 4.)  Inter-RBridge Channel messages are identified
+   as such by their Inner.MacDA, which is the All-Egress-RBridges
+   multicast address, together with their inner Ethertype, which is the
+   RBridge-Channel Ethertype.  This Ethertype is part of and starts the
+   RBridge Channel Header.
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 4]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   The diagram below shows 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 Structure
+
+   Optionally, some channel messages may require examination of the
+   frame by transit RBridges that support the RBridge Channel feature,
+   to determine if they need to take any action.  To indicate this, such
+   messages use an RBridge Channel Alert extended TRILL Header flag as
+   further described in Section 3 below.
+
+   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 is needed to get a TRILL Data
+   frame to the next-hop RBridge, depending on the technology of the
+   link, and can change with each hop for multi-hop messages.  Section
+   2.3 describes the outer Link Header for Ethernet links, and Section
+   2.4 discusses some special considerations for the first hop
+   transmission of RBridge Channel messages.
+
+   Section 3 describes some details of RBridge Channel message
+   processing.  Section 4 provides the specifications for native RBridge
+   Channel frames between RBridges and end stations that are directly
+   connected over a link.  Section 5 describes how support for RBridge
+   Channel protocols is indicated.  And Sections 6, 7, and 8 give
+   congestion, allocation (IANA and IEEE), and security considerations
+   respectively.
+
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 5]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+2.1.  RBridge Channel Message Inner Frame
+
+   The encapsulated inner frame within an RBridge Channel message frame
+   is as shown below.
+
+       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 Fields
+
+   The Channel-Protocol-Specific Data contains the information related
+   to the specific channel protocol used in the channel message.
+   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).  Following that is a
+   four-byte quantity with four sub-fields as follows:
+
+      CHV: A 4-bit field that gives the RBridge Channel Header Version.
+         This document specifies version zero.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 6]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+      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 below.
+
+                | 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 specifies the protocol that the
+   channel message relates to.  The initial defined value is listed
+   below.
+
+         Protocol  Name - Section of This Document
+         --------  -------------------------------
+          0x001    RBridge Channel Error - Section 3
+
+   IANA Considerations for RBridge Channel protocol numbers are provided
+   in Section 7.  These 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.
+
+
+
+Eastlake, et al.             Standards Track                    [Page 7]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+2.1.2.  Inner Ethernet Header
+
+   The special Inner.MacDA is the All-Egress-RBridges multicast Media
+   Access Control (MAC) address to signal that the frame is intended for
+   the egress (decapsulating) RBridge itself (or 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 for which
+   the following recommendations apply:
+
+   1.  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.
+
+
+
+
+
+Eastlake, et al.             Standards Track                    [Page 8]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   2.  For single and multi-hop unicast channel messages important to
+       network operation but not critical for connectivity, the
+       RECOMMENDED priority is 6.
+
+   3.  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 (that, 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 Fields
+
+   The 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; and 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
+
+
+
+Eastlake, et al.             Standards Track                    [Page 9]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   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.
+
+   o  The Egress Nickname can be set to a nickname of the target
+      neighbor RBridge.
+
+   o  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
+
+   If a multi-hop RBridge Channel message is received by an RBridge, the
+   criteria and method of forwarding it are the same as for any TRILL
+   Data frame.  If it is so forwarded, it will be on a link that was
+
+
+
+Eastlake, et al.             Standards Track                   [Page 10]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   included in the routing topology because it was in the Report state
+   as specified in [RFC7177].
+
+   However, special considerations apply to single-hop messages because,
+   for some RBridge Channel protocols, it may be desirable to send
+   RBridge Channel messages over a link that is not yet fully up.  In
+   particular, it is permissible, if specified by the particular channel
+   protocol, for the source RBridge that has created an RBridge Channel
+   message to attempt to transmit it to a next-hop RBridge when the link
+   is in the Detect or 2-Way state, as specified in [RFC7177], as well
+   as when it is in the Report state.  Such messages can also be sent on
+   point-to-point links that are not in the Up state.
+
+   RBridge Channel messages represent a burden on the RBridges, and
+   links in a campus and should be rate limited, especially if they are
+   sent as high priority, multi-destination, or multi-hop frames or have
+   an RBridge Channel Alert extended header flag set.  See Section 6,
+   "Congestion Considerations".
+
+3.  Processing RBridge Channel TRILL Data Messages
+
+   RBridge Channel TRILL Data messages are designed to look like and, to
+   the extent practical, be forwarded as regular TRILL Data frames.  On
+   receiving a channel message, an RBridge performs the usual initial
+   tests on the frame and makes the same forwarding and/or decapsulation
+   decisions as for a regular TRILL Data frame [RFC6325] with the
+   following exceptions for RBridges implementing the RBridge Channel
+   facility:
+
+   1.  An RBridge implementing the RBridge Channel facility MUST
+       recognize the Any-RBridge egress nickname in TRILL Data frames,
+       decapsulating such frames if they meet other checks.  (Such a
+       frame cannot be a valid multi-destination frame because the Any-
+       RBridge nickname is not a valid distribution tree root.)
+
+   2.  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 is not egressing the frame.  If it is egressing
+       the frame, then no additional processing beyond egress processing
+       is needed even if an RBridge Channel Alert flag is set.
+
+   3.  On decapsulation, the special Inner.MacDA value of All-Egress-
+       RBridges MUST be recognized to trigger checking the
+       Inner.Ethertype and processing as an RBridge Channel message if
+       that Ethertype is RBridge-Channel.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 11]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   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.
+
+3.1.  Processing the RBridge Channel Header
+
+   Knowing that 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 occur 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.  The behavior is the same if
+   the frame is being processed at a transit RBridge because the RBridge
+   Critical Channel Alert flag is set [RFC7179].  However, if these
+   conditions are detected at a transit RBridge examining the message
+   because the RBridge Non-critical Channel Alert flag is set [RFC7179]
+   but the RBridge Critical Channel Alert flag is not set, no error is
+   generated, and the frame is still forwarded normally.
+
+   Error Conditions:
+
+   1.  The Ethertype is not RBridge-Channel and not any other Ethertype
+       known to the RBridge as usable with the All-Egress-RBridges
+       Inner.MacDA, or the frame is so short that the Ethertype is
+       truncated.
+
+   2.  The CHV field is non-zero, or the frame is so short that the
+       version zero Channel Header is truncated.
+
+   3.  The Channel Protocol field is a reserved value or a value unknown
+       to the processing RBridge.
+
+   4.  The ERR field is non-zero, and Channel Protocol is a value other
+       than 0x001.
+
+   5.  The RBridge Channel Header NA flag 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 in
+   accordance with that channel protocol.  The processing model is as if
+   the received frame starting with and including the TRILL Header is
+
+
+
+Eastlake, et al.             Standards Track                   [Page 12]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   delivered to the Channel protocol along with a flag indicating
+   whether this is (a) transit RBridge processing due to an RBridge
+   Channel Alert flag being set or (b) egress processing.
+
+   Errors within a recognized Channel Protocol are handled by that
+   channel protocol itself and do not produce RBridge Channel Error
+   frames.
+
+3.2.   RBridge Channel Errors
+
+   A variety of problems at the RBridge Channel level cause the return
+   of an RBridge Channel Error frame unless one of the following apply:
+   (a) the "SL" (Silent) flag is a one in the channel message for which
+   the problem was detected, (b) the processing is due to the RBridge
+   Non-critical Channel Alert flag being set, (c) the frame in error
+   appears, itself, to be an RBridge Channel Error frame (has a non-zero
+   ERR field or a Channel Protocol of 0x001), or (d) the error is
+   suppressed due to 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
+   detecting the error and the Egress Nickname set to the value of the
+   Ingress Nickname in the channel message for which the error was
+   detected.  No per-hop transit processing is specified for such 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 does
+   not include the TRILL Ethertype that is part of the Link Header on
+   Ethernet links.)
+
+   The following values for ERR 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)
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 13]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+      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.
+
+4.  Native RBridge Channel Frames
+
+   Other sections of this document specify non-native RBridge Channel
+   messages and their processing, that is, RBridge Channel messages
+   formatted as TRILL Data frames and sent between RBridges.  This
+   section specifies the differences for native RBridge Channel
+   messages.
+
+   If provided for by the channel protocol involved, native RBridge
+   Channel messages may be sent between end stations and RBridges that
+   are directly connected over a link, in either direction.  On an
+   Ethernet link, such native frames have the RBridge-Channel Ethertype
+   and are like the encapsulated frame inside an RBridge Channel message
+   except as follows:
+
+   1.  TRILL does not require the presence of a VLAN tag on such native
+       RBridge Channel frames.  However, port configuration, link
+       characteristics, or the channel protocol involved may require
+       such tagging.
+
+   2.  If the frame is unicast, the destination MAC address is the
+       unicast MAC address of the RBridge or end-station port that is
+       its intended destination.  If the frame is multicast by an end
+       station 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 is discarded if its destination MAC address is neither
+       the unicast address of the port nor the multicast address All-
+       Edge-RBridges.  If the frame is multicast by an RBridge to all
+       the devices that TRILL considers to be end stations on a link and
+       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 is discarded if its destination MAC address is
+       neither the unicast address of the port nor the multicast address
+       TRILL-End-Stations.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 14]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   3.  The RBridge-Channel outer Ethertype must be present.  In the
+       future, there may be other protocols using the All-Edge-RBridges
+       and/or TRILL-End-Stations multicast addresses on native frames
+       distinguished by different Ethertypes.
+
+   4.  The NA or Native bit in the RBridge Channel Header flags MUST be
+       a one.
+
+   5.  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 provided for by the channel protocol involved, the receipt
+   of a native RBridge Channel frame MAY lead to the generation and
+   transmission of one or more Inter-RBridge Channel frames.  The
+   decapsulation and processing of a TRILL Data RBridge Channel frame
+   MAY, if provided for by the channel protocol involved, result in the
+   sending of one or more native RBridge Channel frames to one or more
+   end stations.  Thus, there could be an RBridge Channel protocol that
+   involved an RBridge Channel message sent (1) from an origin RBridge
+   where the message is 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 such a three-part path);
+   however, to do this, the RBridge Channel protocol involved must be
+   implemented at the RBridge where the channel message is changed
+   between a native frame and a TRILL Data format frame, and that
+   RBridge must change the channel message itself, at a minimum
+   complementing the NA flag in the Channel Header and making
+   appropriate MAC address changes.
+
+   An erroneous native channel message results in a native RBridge
+   Channel Error message under the same conditions for which a TRILL
+   Data RBridge Channel message would result in a TRILL Data RBridge
+   Channel Error message.  However, in a native RBridge Channel Error
+   message, the NA flag MUST be one.  Also, since there is no TRILL
+   Header in native RBridge Channel protocol frames, the beginning part
+   of the frame in which the error was detected that is included in
+   native RBridge Channel Error frames starts with the RBridge Channel
+   Header (including the RBridge-Channel Ethertype).  The destination
+   MAC address of such error messages is set to the source MAC address
+   of the native RBridge Channel message that was in error.
+
+   There is no mechanism to stop end stations from directly exchanging
+   native RBridge Channel messages, but such usage is beyond the scope
+   of this document.
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 15]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+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, and protocol 1,
+   the RBridge Channel Error protocol, MUST be implemented as part of
+   the RBridge Channel feature.  Thus, 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, the bandwidth
+   requirements for TRILL Data, TRILL IS-IS, TRILL ESADI, RBridge
+   Channel protocol traffic, and any other link-local traffic need to be
+   taken into account.
+
+   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, to prevent aggressive connectivity
+   verification or other applications consuming excessive bandwidth,
+   causing congestion, or becoming denial-of-service attacks.
+
+   If these conditions cannot be followed, an adaptive loss-based scheme
+   SHOULD be applied to congestion-control outgoing RBridge Channel
+   traffic, so that it competes 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]; other methods exist.  For example, bandwidth
+   or packet-frequency management can include any of the following: a
+   negotiation of transmission interval/rate such as that 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.
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 16]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   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 a 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           0xFFC0
+
+   IANA 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-46
+
+   IANA 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)
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 17]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   (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       -      Unassigned
+
+   Allocation 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
+
+   No general integrity, authentication, or encryption mechanisms are
+   provided herein for RBridge Channel messages.  If these services are
+   required for a particular RBridge Channel protocol, they MUST be
+   supplied by that channel protocol.  See, for example, the BFD
+   Authentication mechanism [RFC5880].
+
+   See [RFC6325] for general TRILL security considerations.  As stated
+   therein, no protection is provided by TRILL against forging of the
+   Ingress Nickname in a TRILL Data formatted channel message or the
+   Outer.MacSA in a native RBridge Channel frame on an Ethernet link.
+   This may result in misdirected return responses or error messages.
+   However, link-level security protocols may be used to authenticate
+   the origin station on a link and protect against attacks on links.
+   See also Section 6 concerning congestion.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 18]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   If indications of RBridge Channel Protocol support are improperly
+   absent from an RBridge's LSP, it could deny all RBridge Channel
+   services, for example, some BFD services, for the RBridge in
+   question.  If a particular RBridge Channel protocol is incorrectly
+   not advertised as supported, it could deny the service of that
+   channel protocol to the RBridge in question.
+
+   Incorrect indication of RBridge Channel Protocol support or incorrect
+   assertion of support for a channel protocol could encourage RBridge
+   Channel messages to be sent to an RBridge that does not support the
+   channel feature or the particular channel protocol used.  The inner
+   frame of such messages could be decapsulated and that inner frame
+   could be sent out all ports that are Appointed Forwarders for the
+   frame's Inner.VLAN.  However, this is unlikely to cause much harm; in
+   particular, there are two possibilities as follows: (a) if end
+   stations do not recognize the RBridge-Channel Ethertype of the frame,
+   they will drop it, and (b) if end stations do recognize the RBridge-
+   Channel Ethertype and the channel protocol indicated in the frame,
+   they should refuse to process the frame due to an incorrect value of
+   the RBridge 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.
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 19]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+   [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 is alphabetic order: Stewart Bryant, Somnath
+   Chatterjee, Adrian Farrel, Stephen Farrell, Miguel A. Garcia, Anoop
+   Ghanwani, Brian Haberman, Rakesh Kumar, Barry Leiba, and Tissa
+   Senevirathne.
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 20]
+
+RFC 7178             TRILL: RBridge Channel Support             May 2014
+
+
+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
+
+
+
+
+
+
+
+Eastlake, et al.             Standards Track                   [Page 21]
+