Skip to main content

TRILL: RBridge Channel Support
draft-ietf-trill-rbridge-channel-05

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7178.
Authors Donald E. Eastlake 3rd , Vishwas Manral , Yizhou Li , Sam Aldrin
Last updated 2012-02-21 (Latest revision 2012-01-18)
Replaces draft-eastlake-trill-rbridge-bfd, draft-eastlake-trill-rbridge-channel
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Consensus: Waiting for Write-Up
Document shepherd (None)
IESG IESG state Became RFC 7178 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-trill-rbridge-channel-05
TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                                    Huawei
Intended status: Proposed Standard                        Vishwas Manral
                                                           HP Networking
                                                               Li Yizhou
                                                              Sam Aldrin
                                                                  Huawei
                                                               Dave Ward
                                                                   Cisco
Expires: August 19, 2012                               February 20, 2012

                     TRILL: RBridge Channel Support
               <draft-ietf-trill-rbridge-channel-05.txt>

Abstract

   This document specifies a general channel mechanism for sending
   messages, such as BFD (Bidirectional Forwarding Detection) messages,
   between RBridges (Routing Bridges) and between RBridges and end
   stations in an RBridge campus through extensions to the TRILL
   (TRansparent Interconnection of Lots of Links) protocol.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the TRILL working group mailing list.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

D. Eastlake, et al                                              [Page 1]
INTERNET-DRAFT                                    TRILL: RBridge Channel

Table of Contents

      1. Introduction............................................3
      1.1 RBridge Channel Requirements...........................3
      1.2 Relation to the MPLS Generic Channel...................4
      1.3 Terminology............................................4

      2. Inter-RBridge Channel Messages..........................5
      2.1 The RBridge Channel Message Inner Frame................6
      2.1.1 RBridge Channel Header...............................6
      2.1.2 Inner Ethernet Header................................7
      2.1.3 Inner.VLAN Tag.......................................8
      2.2 The 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.................11
      3.2 RBridge Channel Errors................................12

      4. Native RBridge Channel Frames..........................14
      5. Indicating Support for RBridge Channel Protocols.......16

      6. Allocation Considerations..............................17
      6.1 IANA Considerations...................................17
      6.2 IEEE Registration Authority Considerations............18

      7. Security Considerations................................19

      8. References.............................................20
      8.1 Normative References..................................20
      8.2 Informative References................................20

      Appendix: Change History..................................22
      Acknowledgmnts............................................24

D. Eastlake, et al                                              [Page 2]
INTERNET-DRAFT                                    TRILL: RBridge Channel

1. Introduction

   RBridge campuses provide transparent least-cost path forwarding using
   the TRILL (TRansparent Interconnection of Lots of Links) protocol
   that builds on IS-IS (Intermediate System to Intermediate System)
   routing [IS-IS] [RFC1195] [RFC6326bis].  Devices that implement TRILL
   are called RBridges (Routing Bridges) 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
   (Bidirectional Forwarding Detection, [RFC5880]) messages, between
   RBridges and end stations that are directly connected on the same
   link and between RBridges. This mechanism supports a requirement to
   be able to operate with minimal configuration.

   Familiarity with [RFC6325] and [RFC6327] is assumed in this document.

1.1 RBridge Channel Requirements

   It is anticipated that various protocols operating at the TRILL level
   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 [RFCext] 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

D. Eastlake, et al                                              [Page 3]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   format that is TRILL Data encapsulated for inter-RBridge channel
   messages.

   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 Channel

   The RBridge Channel is similar to the MPLS Generic 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.

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

D. Eastlake, et al                                              [Page 4]
INTERNET-DRAFT                                    TRILL: RBridge Channel

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.

   The diagram below shows the overall structure of a 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) |
      +--------------------------------+

   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 a RBridge Channel Alert extended TRILL header flags as
   further described in Section 3 below.

   The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL
   Header for frames sent in an RBridge Channel. As always, the Outer
   link header and 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. 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.

D. Eastlake, et al                                              [Page 5]
INTERNET-DRAFT                                    TRILL: RBridge Channel

2.1 The RBridge Channel Message Inner Frame

   The encapsulated inner frame within an RBridge Channel message frame
   is as shown below.

    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  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    RBridge Channel Protocol Specific Information:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                 Channel Protocol Specific Data
      |  ...

   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 below.

2.1.1 RBridge Channel Header

   As shown in the diagram above, the RBridge Channel header starts with
   the RBridge-Channel Ethertype (see Section 6.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
            and MUST be 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 described below.

D. Eastlake, et al                                              [Page 6]
INTERNET-DRAFT                                    TRILL: RBridge Channel

      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          |
         +--+--+--+--+--+--+--+--+--+--+--+--+

   Bit 0, which is the high order bit in network order, is defined as
         the SL or Silent bit. If it is a one, it suppresses RBridge
         Channel Error messages (see Section 3).

   Bit 1 is 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 is the NA or Native bit. It is used as described in Section 4
         below.

   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. See Section 6 for IANA Considerations.

         Protocol  Name - Section of this Document
         --------  -------------------------------

          0x001    RBridge Channel Error - Section 3

2.1.2 Inner Ethernet Header

   The special Inner.MacDA is the All-Egress-RBridges multicast 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.

D. Eastlake, et al                                              [Page 7]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   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.

      2. For single and multi-hop known unicast channel messages
         important to network operation but not critical for
         connectivity, the RECOMMENDED priority is 6.

      3. For other known 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,
   [ClearCorrect]). 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

D. Eastlake, et al                                              [Page 8]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   recommendation is made for that case.

2.2 The TRILL Header for RBridge Channel Messages

   After the outer Link Header (that, for Ethernet, ends with the TRILL
   Ethertype) and before the encapsulated frame, the channel message's
   TRILL Header initially appears as follows:

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |V=0| R |M| Ext-Len | Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Egress Nickname         |       Ingress Nickname        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 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 Ext-Len is set appropriately for the length of the TRILL
   Header extensions area, if any, all as specified in [RFC6325] (where
   the extensions area is referred to as the options area and this field
   as Op-Len).

   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 Hops field to the maximum value and checking the Hop Count field
   on receipt provides an additional validity check as discussed in
   [RFC5082].

   The RBridge originating a channel message places a nickname that it
   holds into 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 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.

D. Eastlake, et al                                              [Page 9]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   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 trailer
   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
   included in the routing topology because it was in the Report state
   as specified in [RFC6327].

   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 Two-Way states, as specified in [RFC6327], 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.

D. Eastlake, et al                                             [Page 10]
INTERNET-DRAFT                                    TRILL: RBridge Channel

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, the initial tests on the Outer.MacDA,
   Outer Ethertype, TRILL Header V and Hop Count fields and the Reverse
   Path Forwarding Check if the frame is multi-destination, are all
   performed as usual. The forwarding and/or decapsulation decisions are
   the same as for a regular TRILL Data frame with 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.

   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
   critical RBridge Channel Alert flag is set [RFCext]. However, if

D. Eastlake, et al                                             [Page 11]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   these conditions are detected at a transit RBridge examining the
   message because the non-critical RBridge Channel Alert flag is set
   [RFCext] but the critical flag is not set, no error is generated and
   the frame is still forwarded normally.

      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
   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 (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 non-critical RBridge Channel Alert
   bit 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 the nickname of the RBridge

D. Eastlake, et al                                             [Page 12]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   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   Meaning
   ---   -------
    0    - Not an RBridge Channel error frame.
    1    Frame too short (truncated Ethertype or RBridge 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   - Available for allocation, see Section 6.
   15    Reserved

   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 a RBridge
   Channel Error message, that is, a channel message with a protocol
   value of 0x001 or with a non-zero ERR field.

D. Eastlake, et al                                             [Page 13]
INTERNET-DRAFT                                    TRILL: RBridge Channel

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 that uses this transport, the destination MAC
         address is the All-Edge-RBridges multicast address (see Section
         6). A native RBridge Channel frame received at an ingress
         RBridge with a destination MAC address that is a unicast
         address different from that of the port or multicast address
         different from All-Edge-RBridges, is discarded. If the frame is
         multicast by an RBridge to all the devices that TRILL considers
         to be end stations on a link that support an RBridge Channel
         protocol that uses this transport, the destination MAC address
         is the TRILL-End-Stations multicast address (see Section 6). A
         native RBridge Channel frame received at an end station with a
         destination MAC address that is a unicast address different
         from that of the port or multicast address different from
         TRILL-End-Stations, is discarded.

         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.

D. Eastlake, et al                                             [Page 14]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   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 from an origin RBridge where
   the message is created, through one or more other RBridges and from
   the last as a native RBridge channel message to and end station or
   the reverse of such a 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 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 an 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.

D. Eastlake, et al                                             [Page 15]
INTERNET-DRAFT                                    TRILL: RBridge Channel

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 LSP as documented in
   [RFC6326bis].

   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.

D. Eastlake, et al                                             [Page 16]
INTERNET-DRAFT                                    TRILL: RBridge Channel

6. Allocation Considerations

   The following subsections give IANA and IEEE allocation
   considerations. In this document, the allocation procedure
   specifications are as defined in [RFC5226].

6.1 IANA Considerations

   IANA is requested to allocate a previously unassigned TRILL Nickname
   as follows:

         Any-RBridge           TBD (0xFFCO suggested)

   IANA is requested to add "All-Egress-RBridges" to the TRILL Parameter
   Registry as an alternative name for the "All-ESADI-RBridges"
   multicast address.

   IANA is requested to allocate two previously unassigned TRILL
   Multicast address as follows:

         TRILL-End-Stations    TBD (01-80-C2-00-00-45 suggested)
         All-Edge-RBridges     TBD (01-80-C2-00-00-46 suggested)

   IANA is requested to create an additional sub-registry in the TRILL
   Parameter Registry for RBridge Channel Protocols, with initial
   contents as follows:

         Protocol       Description            Reference
         --------       -----------            ---------

         0x000          Reserved               (This document)
         0x001          RBridge Channel Error  (This document)
         0x002-0x0FF    Available (1)
         0x100-0xFF7    Available (2)
         0xFF8-0xFFE    Private Use
         0xFFF          Reserved               (This document)

   (1) RBridge Channel protocol code points from 0x002 to 0x0FF require
   a Standards Action, as modified by [RFC4020], for allocation.

   (2) RBridge Channel protocol code points from 0x100 to 0xFF7 require
   RFC Publication to allocate a single value or IETF Review to allocate
   multiple values.

   IANA is requested to create an additional sub-registry in the TRILL
   Parameter Registry for RBridge Channel Header Flags with initial
   contents as follows:

D. Eastlake, et al                                             [Page 17]
INTERNET-DRAFT                                    TRILL: RBridge Channel

         Flag Bit  Mnemonic  Allocation
         --------  --------  ----------

            0         SL     Silent
            1         MH     Multi-hop
            2         NA     Native
           3-11       -      Available for allocation

   Allocation of an RBridge Channel Header Flag is based on Standards
   Action as modified by [RFC4020].

   IANA is requested to create 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 [RFC4020].

6.2 IEEE Registration Authority Considerations

   The IEEE Registration Authority has been assigned the Ethertype <TBD>
   for RBridge-Channel.

D. Eastlake, et al                                             [Page 18]
INTERNET-DRAFT                                    TRILL: RBridge Channel

7. Security Considerations

   See [RFC6325] for general TRILL 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].

   If indication 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 would deny the service of that channel
   protocol to the RBridge in question.

   Incorrect presence of 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 particuclar, there are two possibilities as follows: (a) If
   end stations do not recognize the RBridge-Channel Ethertype of the
   frame, they will drop it. (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.

   No protection is provided against forging or the ingress nickname in
   a TRILL Data formatted channel message or the Outer.MacSA in a native
   RBridge Channel frame. This may result in misdirected return
   responses or error messages.

D. Eastlake, et al                                             [Page 19]
INTERNET-DRAFT                                    TRILL: RBridge Channel

8. References

   The following sections list normative and informative references for
   this document.

8.1 Normative References

   [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to
         Intermediate System Intra-Domain Routing Exchange Protocol for
         use in Conjunction with the Protocol for Providing the
         Connectionless-mode Network Service (ISO 8473)", 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

   [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
         Standards Track Code Points", BCP 100, RFC 4020, February 2005.

   [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
         IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
         2008.

   [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
         Ghanwani, "Routing Bridges (RBridges): Base Protocol
         Specification", RFC 6325, July 2011.

   [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
         and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
         6327, July 2011.

   [RFCext] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. Bestler,
         "TRILL: TRILL Header Extension", draft-ietf-trill-rbridge-
         extension, work in progress.

   [RFC6326bis] - Eastlake, D., A. Banerjee, D. Dutt, A. Ghanwani, R.
         Perlman, "TRILL Use of IS-IS", draft-eastlake-isis-rfc6326bis,
         work in progress.

8.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

D. Eastlake, et al                                             [Page 20]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   [RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
         "MPLS Generic Associated Channel", RFC 5586, June 2009.

   [RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection
         (BFD)", June 2010.

   [RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional
         Forwarding Detection (BFD)", June 2010.

   [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V.
         Manral, "TRILL: Clarifications, Corrections, and Updates",
         draft-ietf-trill-clear-correct, work in progress.

D. Eastlake, et al                                             [Page 21]
INTERNET-DRAFT                                    TRILL: RBridge Channel

Appendix: Change History

   RFC Editor: please delete this appendix before publication.

Changes from -00 to -01

   1. Spell out more acronyms.

   2. Add reference to "Guidelines for the Use of OAM" draft.

   3. Move definition of Alert flag to draft-ietf-trill-rbridge-options
      and refer to it as an extended header flag.

   4. Change name of "Egress-RBridges" multicast address to "All-Egress-
      RBridges". Merge with All-ESADI-RBridges (i.e., they are two names
      for the same MAC address).

   5. Add detailed bit vector description for indicating support of
      RBridge channel protocols. Add GENAPP and an APPsub-TLV to hold
      one or more bit vectors.

   6. Assorted editorial changes.

Changes from -01 to -02

   1. Update for drafts that have been issued as RFCs.

   2. Change to specification of Inner.VLAN in RBridge channel messages.

   3. Remove GENAPP and move RBridge Channels supported information to
      another document.

   4. Clarify native RBridge Channel error messages.

   5. Assorted editorial changes.

Changes from -02 to -03

   1. Liberalize restrictions on RBridge acceptance of native RBridge
      Channel messages. These are typically messages and should
      generally be accepted unless in a VLAN not enabled at the port or
      the like.

   2. Change multi-cast address used by end stations in sending a native

D. Eastlake, et al                                             [Page 22]
INTERNET-DRAFT                                    TRILL: RBridge Channel

      RBridge Channel message to all RBridges on the link from All-
      Egress-RBridges to All-Edge-RBridges to avoid possible confusion
      if such a frame were encapsulated resulting in an All-Egress-
      RBridges Inner.MacDA.

   3. Reword references to "two-hop echo" and the like for clarity.
      (This meant an echo frame that went to an immediate neighbor and
      back.)

   4. Add reference to and move some material to the RFC 6326bis draft.

   5. Assorted editorial changes.

Changes from -03 to -04

   1. Update for the replacement of the CFI bit by the DEI bit (see
      [ClearCorrect]).

   2. Update for the existence of both critical and non-critical RBridge
      Channel alert flags.

   3. Update author information.

   4. Assorted editorial changes.

Changes from -04 to -05

   1. Clarify the distinction between native and non-native RBridge
      Channel messages and that native channel messages are only
      intended to be transmitted between RBridge and end stations on the
      same link.

   2. Add a paragraph to the Security Considerations section about
      forged ingress nicknames / source MAC addresses in channel
      messages.

   3. Add acknowledgements section.

   4. Replace "OAM" references with "BFD" references in Abstract and
      Introduction.

   5. Very minor editorial changes.

D. Eastlake, et al                                             [Page 23]
INTERNET-DRAFT                                    TRILL: RBridge Channel

Acknowledgmnts

   The authors gratefully acknowledge the comments and contributions of
   the follows, listed is alphabetic order: Somnath Chatterjee, Anoop
   Ghanwani, Raksh Kumar, and Tissa Senevirathne.

Authors' Addresses

   Donald Eastlake 3rd
   Huawei R&D USA
   155 Beaver Street
   Milford, MA 01757 USA

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

   Vishwas Manral
   HP Networking
   19111 Pruneridge Avenue
   Cupertino, CA 95014 USA

   Tel:   +1-408-477-0000
   EMail: vishwa.manral@hp.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

D. Eastlake, et al                                             [Page 24]
INTERNET-DRAFT                                    TRILL: RBridge Channel

   EMail: dward@cisco.com

D. Eastlake, et al                                             [Page 25]
INTERNET-DRAFT                                    TRILL: RBridge Channel

Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2012 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.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.

D. Eastlake, et al                                             [Page 26]