TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                                    Huawei
Intended status: Proposed Standard                        Vishwas Manral
Updates: RFCtrill                                            IP Infusion
                                                               Li Yizhou
                                                              Sam Aldrin
                                                               Dave Ward
Expires: October 19, 2011                                 April 20, 2011

                RBridges: TRILL RBridge Channel Support


   This document specifies a general channel for sending OAM
   (Operations, Administration, and Maintenance) or other messages 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

D. Eastlake, et al                                              [Page 1]

INTERNET-DRAFT                                 RBridges: RBridge Channel

Table of Contents

      1. Introduction............................................3
      1.1 RBridge Channel Requirements...........................3
      1.2 Terminology............................................4

      2. 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..........8
      2.3 Channel Message Ethernet Link Header and Trailer.......9
      2.4 Special Transmission and Rate Considerations..........10

      3. Processing RBridge Channel Messages....................11
      3.1 Processing the RBridge Channel Header.................11
      3.2 RBridge Channel Errors................................12

      4. Native RBridge Channel Frames..........................14

      5. Allocation Considerations..............................15
      5.1 IANA Considerations...................................15
      5.1.1 TRILL GENAPP ID and APPsub-TLVs.....................15
      5.1.2 Other IANA Considerations...........................16
      5.2 IEEE Registration Authority Considerations............18

      6. Security Considerations................................19

      7. References.............................................20
      7.1 Normative References..................................20
      7.2 Informative References................................20

D. Eastlake, et al                                              [Page 2]

INTERNET-DRAFT                                 RBridges: RBridge Channel

1. Introduction

   RBridge campuses support transparent forwarding using the TRILL
   protocol that builds on IS-IS routing [IS-IS] [RFC1195]. However, the
   TRILL base protocol standard [RFCtrill] provides only for TRILL Data
   messages to handle end station data and TRILL IS-IS messages.

   This document specifies a general channel mechanism for the
   transmission of other messages within an RBridge campus, such as OAM
   (Operations, Administration, and Maintenance) messages, between
   RBridges or between end stations and RBridges. This mechanism
   supports a requirement to be able to operate with no or minimal

   Familiarity with [RFCtrill] and [RFCadj] is assumed in this document.

1.1 RBridge Channel Requirements

   It is anticipated that various protocols operating at the TRILL
   level, such as OAM protocols, 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, in the spirit of some ICMP [RFC792] messages,
   such as reporting Hop Count exhaustion, unknown egress nickname in
   the TRILL header, and the like, including ping and trace route

   To avoid having to design and specify a way to carry each new OAM or
   similar protocol between RBridges, 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

   To minimize 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,
   an optional Alert TRILL extended header flag is specified. The Alert
   bit causes a transit RBridge to examine a frame with that flag set,
   usually by sending it to the slow path.

   This document also provides a format for sending RBridge Channel
   messages between end stations and RBridges, in either direction, when

D. Eastlake, et al                                              [Page 3]

INTERNET-DRAFT                                 RBridges: RBridge Channel

   appropriate for the protocol involved.

   Each particular protocol using the RBridge Channel will likely use
   only a subset of the facilities specified herein.

   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.

1.2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   The terminology and acronyms of [RFCtrill] are used in this document
   with the additions listed below.

      BFD - Bidirectional Forwarding Detection

      CHV - Channel Header Version

      ICMP - Internet Control Message Protocol

      MH - Multi-Hop

      OAM - Operations, Administration, and Maintenance

      SL - Silent

D. Eastlake, et al                                              [Page 4]

INTERNET-DRAFT                                 RBridges: RBridge Channel

2. RBridge Channel Messages

   RBridge Channel messages are transmitted as TRILL Data frames. They
   are identified as RBridge Channel messages by their Inner.MacDA
   together with their Ethertype, which are the Egress-RBridges
   multicast address and the RBridge-Channel Ethertype. This Ethertype
   is part of an RBridge Channel Header. The payload of the encapsulated
   frame starts with an RBridge Channel Header that indicates the
   protocol being sent through the RBridge Channel.

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

   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, a non-critical hop-
   by-hop extended TRILL header flag is allocated as the Alert bit
   [RFCext], 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 the RBridge Channel. As always, the Outer
   link header is whatever is needed to get a TRILL Data frame to the
   next hop RBridge, depends on the technology used by 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. And Section 4 provides further specifications for
   optional native RBridge Channel frames between RBridges and end

D. Eastlake, et al                                              [Page 5]

INTERNET-DRAFT                                 RBridges: 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 = Egress-RBridges               |
      |   Special Inner.MacDA cont.   |         Inner.MacSA           |
      |                       Inner.MacSA cont.                       |
      |       VLAN Tag Ethertype      |   Priority, 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 protocol type 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 5.2). Following that is a
   four-byte quantity with four sub-fields as follows:

      CHV: Gives the RBridge Channel Header Version and MUST be zero.

      Channel Protocol: A 12-bit field that specifies the particular
            RBridge Channel protocol to which the message applies.

      Flags: Provides 12 bits of flags described below.

      ERR: A four-bit field used in connection with error reporting at
            the RBridge Channel level as described in Section 3.

D. Eastlake, et al                                              [Page 6]

INTERNET-DRAFT                                 RBridges: RBridge Channel

   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|     Available Flags      |

   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 was intended to be
   multi-hop (MH=1) or one-hop (MH=0).

   Bit 2 is the NA or Native bit. It is used as described in Section 4

   The RBridge Channel Protocol field specifies the protocol that the
   channel message relates to. The initial defined value is listed
   below. See Section 5 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 Egress-RBridges multicast MAC address
   to signal that the frame is intended for the egress RBridge itself
   (or the egress RBridges themselves if the frame is multi-destination)
   (see Section 5). That the frame is an RBridge Channel message is
   indicated by the RBridge-Channel Ethertype. In the future there may
   be other Ethertypes that make use of the Egress-RBridges Inner.MacDA.

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

D. Eastlake, et al                                              [Page 7]

INTERNET-DRAFT                                 RBridges: RBridge Channel

2.1.3 Inner.VLAN Tag

   As with all TRILL encapsulated frames, a VLAN tag MUST be present.
   Use of a VLAN tag Ethertype other than 0x8100 or stacked VLAN tags is
   beyond the scope of this document.

   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 appointed forwarder
   connectivity to that VLAN.

   For channel messages sent as known unicast TRILL Data frames, if the
   message is one-hop it is RECOMMENDED that the Inner.VLAN ID be the
   Designated VLAN on that hop. For multi-hop unicast OAM messages, it
   is RECOMMENDED that the Inner.VLAN ID be the default VLAN 1.

   The Inner.VLAN will also specify 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 beyond the 12 bit
   VLAN ID and 3-bit priority. In some applications, this bit is called
   the Drop Eligibility Indicator (DEI). 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 The TRILL Header for RBridge Channel Messages

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

D. Eastlake, et al                                              [Page 8]

INTERNET-DRAFT                                 RBridges: RBridge Channel

                                       |V=0| R |M| Ext-Len | Hops=0x3F |
       |       Egress Nickname         |       Ingress Nickname        |

   The TRILL Header version V MUST be zero, the R bit 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 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 [RFCtrill] (where
   it is referred to as the options area).

   When an RBridge Channel message is originated, the hop count field
   MUST be set to the maximum value, 0x3F. For messages sent a known
   number of hops, particularly one-hop messages or two-hop neighbor
   echo messages, checking the Hops (Hop Count) field 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 an "echo" OAM message
   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

   o  The egress nickname can bet 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

2.3 Channel Message 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.

D. Eastlake, et al                                              [Page 9]

INTERNET-DRAFT                                 RBridges: RBridge Channel

   For an Ethernet link [RFCtrill] 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 Report state as
   specified in [RFCadj].

   However, special considerations apply to the first hop because, for
   some RBridge Channel protocols, it may be desirable to sent RBridge
   Channel messages on links that are 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
   transmit it to a next hop RBridge when the link is in the Detect or
   Two-Way states, as specified in [RFCadj], as well as when it is in
   the Report 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 the
   Alert extended flag set.

D. Eastlake, et al                                             [Page 10]

INTERNET-DRAFT                                 RBridges: RBridge Channel

3. Processing RBridge Channel Messages

   RBridge Channel 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 MUST recognize the
         Any-RBridge egress nickname in TRILL Data frames, decapsulating
         such frames if they meet other checks and not forwarding them
         in encapsulated form unless they are an appropriate multi-
         destination frame.

      2. If the Alert extended 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 the Alert flag is set.

      3. On decapsulation, the special Inner.MacDA value of 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 that facility as specified in Section 5. If an
   RBridge that does not recognize the Egress-RBridges Inner.MacDA
   multicast address received an RBridge Channel message, it might
   decapsulate the inner frame and sent it out all ports for which that
   RBridge is an appointed forwarder for the Inner.VLAN.

   All RBridges that recognize the Egress-RBridges multicast address
   MUST recognize the RBridge-Channel Ethertype. If the future, there
   may be other Inner.Ethertypes defined that use the Egress-RBridges
   Inner.MacDA. If the Ethertype is not recognized, this error condition
   is handled as described below.

3.1 Processing the RBridge Channel Header

   Knowing that it has an RBridge Channel message, the egress RBridge,
   and any transit RBridge if the Alert bit is set in the TRILL Header,
   looks at the CHV (RBridge Channel Header Version) and Channel
   Protocol fields.

D. Eastlake, et al                                             [Page 11]

INTERNET-DRAFT                                 RBridges: RBridge Channel

   If any of the following conditions occur at an egress RBridge, the
   frame is not processed and an error may be generated as specified in
   Section 3.2; however, if these conditions are detected at a transit
   RBridge examining the message because the Alert flag is set, no error
   is generated and the frame is still forwarded normally.

      1. The Ethertype is not RBridge-Channel or not any other (future)
         Ethertype known to the RBridge as usable with the 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 an encapsulated 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 the 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 OAM Message Channel Error

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 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 an 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                                 RBridges: 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. The SL and MH flags SHOULD be set to one, the NA flag to
   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
   which is part of the Link Header on Ethernet Links and may be absent
   for other link technologies.)

   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 5.
   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                                 RBridges: RBridge Channel

4. Native RBridge Channel Frames

   If provided for by the channel protocol involved, native RBridge
   channel messages may be sent between end-stations and RBridges in
   either direction. Such native frames have the RBridge-Channel
   Ethertype and are like the encapsulated frame inside an RBridge
   Channel message with the following exceptions:

      1. TRILL does not require the presence of VLAN tagging 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 to all the
         RBridges on a link that support an RBridge Channel protocol
         that uses this transport, the destination MAC address is the
         Egress-RBridges multicast address. If the frame is multicast 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 5). The RBridge-Channel
         Ethertype must be present. In the future there may be other
         protocols using the Egress-RBridges and/or TRILL-End-Stations
         multicast addresses distinguished by a different Ethertype.

      3. The NA bit in the RBridge Channel Header flags must be a one.

      4. As with any native frame, the source MAC address is that of the
         port sending the frame.

   A native frame with the RBridge-Channel Ethertype must meet the usual
   VLAN and destination MAC address restrictions to be accepted by an
   RBridge. If provided for by the channel protocol involved, the
   receipt of such a native frame MAY lead to the generation and
   transmission of one or more native or TRILL encapsulated RBridge
   Channel frames.  The decapsulation and processing of an encapsulated
   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.

D. Eastlake, et al                                             [Page 14]

INTERNET-DRAFT                                 RBridges: RBridge Channel

5. Allocation Considerations

   The following subsections give IANA and IEEE allocation
   considerations.  In this document, the allocation procedures
   "Standards Action", "IETF Review", "RFC Publication", and "Private
   Use" are as specified in [RFC5226].

5.1 IANA Considerations

   The following subsections give IANA allocation considerations.


   IANA is requested to allocate an IS-IS Application Identifier under
   the Generic Information TLV (#251) for TRILL [RFCgenapp] and to
   create a subregistry in the TRILL Parameters Registry for "TRILL
   APPsub-TLVs under IS-IS TLV #251 Application Identifier #TBD".  The
   initial contents of this subregistry are as follows:

       Type    Name               MI0?     Reference
      ------ --------            ------   -----------
          0  Reserved               -
          1  Data Capabilities      Y     <this RFC>
      2-254  Available              -     <this RFC>
        255  Reserved               -

   The V, I, D, and S flags in the initial flags byte of a TRILL Generic
   Information TLV [RFCgenapp] are not used as TRILL operates as a Level
   1 IS-IS area and no meaning is hereby assigned to the inclusion of an
   IPv4 and/or IPv6 address via the I and V flags. Thus these flags will
   be zero; however, use of multi-level IS-IS is an obvious extension of
   TRILL and a future IETF Standards Action may update this
   specification to provide for the use of any or all of these flags.
   TRILL APPsub-TLVs MUST NOT alter basic IS-IS protocol operation
   including the establishment of adjacencies, the update process, and
   the decision process [IS-IS] [RFC1195].

   TRILL APPsub-TLV Types 2 through 254 are available for allocation by
   Standard Action as modified by [RFC4020]. The standards track RFC
   making such allocation shall specify whether a TRILL Generic
   Information TLV containing an instance of that TRILL APPsub-TLV is
   permitted to occur in instance zero LSPs and a column in the TRILL
   APPsub-TLV registry will indicate this. The RFC will also include a
   discussion of security issues and of the rate of change of the
   information being advertised.

D. Eastlake, et al                                             [Page 15]

INTERNET-DRAFT                                 RBridges: RBridge Channel

   The Data Capabilities TRILL APPsub-TLV has as its value a bit vector
   where a one bit indicates support of a particular TRILL Data frame
   format, encapsulation, or sub-type. The bits in the value of this
   APPsub-TLV are numbered in network order, the high order bit of the
   first byte being 0, the low order bit of that byte being 7, the high
   order bit of the second byte being 8, etc. The maximum value length
   permitted is 64 so the highest available bit is number 511. A longer
   value is processed but bytes beyond the 64th are ignored. By
   implication, the value of all bits higher numbered than those present
   is zero. The absence of this APPsub-TLV implies that all bits are
   zero and the relevant RBridge supports no TRILL data capabilities
   other than those in the TRILL base protocol standard [RFCtrill]. To
   avoid wasted space, a Data Capabilities TRILL APPsub-TLV SHOULD have
   the smallest length that will accommodate all the one bits in its

   This Data Capabilities information is expected to be very compact and
   slow changing. It would typically change only on manual re-
   configuration, software/firmware update, or the like. The Data
   Capabilities TRILL APPsub-TLV may occur in instance zero LSPs. The
   security implications of each defined bit in the value of a Data
   Capabilities TRILL APPsub-TLV will be discussed in the RFC specifying
   that bit.

   IANA is requested to create a "Data Capabilities APPsub-TLV Bits"
   subregistry in the TRILL Parameters Registry. The initial table of
   bits is as follows:

       Bit      Name              Reference
      -----    ------            -----------
        0      RBridge Channel   <this document>
      1-511    Available

   Bits will be allocated in ascending numeric order without gaps based
   on IETF Review for single bits and Standards Action as modified by
   [RFC4020] for more than one bit.

5.1.2 Other IANA Considerations

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

         Any-RBridge           TBD (0xFFCO suggested)

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

         Egress-RBridges       TBD (01-80-C2-00-00-43 suggested)

D. Eastlake, et al                                             [Page 16]

INTERNET-DRAFT                                 RBridges: RBridge Channel

         TRILL-End-Stations    TBD (01-80-C2-00-00-44 suggested)

   IANA is request to allocate a previously unassigned TRILL non-
   critical hop-by-hop extended flag bit [RFCext] as follows:

         TBD                   Alert

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

         Protocol       Use
         --------       ---

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

   (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:

         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 4.2 above and with available values
   allocated by Standards Action as modified by [RFC4020].

D. Eastlake, et al                                             [Page 17]

INTERNET-DRAFT                                 RBridges: RBridge Channel

5.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                                 RBridges: RBridge Channel

6. Security Considerations

   See [RFCtrill] for general RBridge 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].)

   An incorrect value of the RBridge Channel bit in the TRILL APPsub-TLV
   can have the following effects: (1) If improperly set to zero, it
   could deny RBridge Channel services, for example OAM services, for
   the RBridge in question. (2) If improperly set to one, it could
   encourage RBridge Channel messages to be sent to an RBridge that does
   not support this feature. The inner frame of such messages would be
   decapsulated and that inner frame would likely be sent out all ports
   that are appointed forwarders for the frame's Inner.VLAN. However,
   this is unlikely to cause harm. There are two possibilities: (2a) If
   the end stations does not recognize the RBridge-Channel Ethertype of
   that inner frame it will drop the frame. (2b) If the end station does
   recognize the RBridge-Channel Ethertype, it should refuse to process
   the frame due to an incorrect value of the RBridge Channel Header NA

D. Eastlake, et al                                             [Page 19]

INTERNET-DRAFT                                 RBridges: RBridge Channel

7. References

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

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

   [RFCtrill] - R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A.
         Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
         trill-rbridge-protocol-16.txt, in RFC Editor's queue.

   [RFCgenapp] - L. Ginsberg, S. Previdi, M. Shand, "Advertising Generic
         Information in IS-IS", draft-ietf-isis-genapp-04.txt, in RFC
         Editor's queue.

   [RFCadj] - D. Eastlake, R. Perlman, A. Ghanwani, D. Dutt, V. Manral,
         "RBridges: Adjacency", draft-ietf-trill-adj, work in progress.

   [RFCext] - D. Eastlake, A. Ghanwani, V. Manral, C. Bestler,
         "RBridges: TRILL Header Extensions", draft-ietf-trill-rbridge-
         options, work in progress.

7.2 Informative References

   [RFC792] - Postel, J., "Internet Control Message Protocol", STD 5,
         RFC 792, September 1981.

D. Eastlake, et al                                             [Page 20]

INTERNET-DRAFT                                 RBridges: RBridge Channel

   [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] - D. Katz, D. Ward, "Bidirectional Forwarding Detection
         (BFD)", June 2010.

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

D. Eastlake, et al                                             [Page 21]

INTERNET-DRAFT                                 RBridges: RBridge Channel

Authors' Addresses

   Donald Eastlake 3rd
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA

   Tel:   +1-508-333-2270

   Vishwas Manral
   IP Infusion
   1188 E. Arques Ave.
   Sunnyvale, CA 94089 USA

   Tel:   +1-408-400-1900

   Yizhou Li
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012, China

   Phone: +86-25-56622310

   Sam Aldrin
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA 95050 USA

   Phone: +1-408-330-5000

   Dave Ward
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089-1206 USA

   Phone: +1-408-745-2000

D. Eastlake, et al                                             [Page 22]

INTERNET-DRAFT                                 RBridges: RBridge Channel

Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2011 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
   ( 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

D. Eastlake, et al                                             [Page 23]