GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7178

Internet Engineering Task Force (IETF) D. Eastlake 3rd Request for Comments: 7178 Huawei Category: Standards Track V. Manral ISSN: 2070-1721 Ionos Corp.

                                                                 Y. Li
                                                             S. Aldrin
                                                                Huawei
                                                               D. Ward
                                                                 Cisco
                                                              May 2014
       Transparent Interconnection of Lots of Links (TRILL):
                      RBridge Channel Support

Abstract

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

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7178.

Eastlake, et al. Standards Track [Page 1] RFC 7178 TRILL: RBridge Channel Support May 2014

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
    1.1. RBridge Channel Requirements ...............................3
    1.2. Relation to the MPLS Generic Associated Channel ............4
    1.3. Terminology ................................................4
 2. Inter-RBridge Channel Messages ..................................4
    2.1. RBridge Channel Message Inner Frame ........................6
         2.1.1. RBridge Channel Header ..............................6
         2.1.2. Inner Ethernet Header ...............................8
         2.1.3. Inner.VLAN Tag ......................................8
    2.2. TRILL Header for RBridge Channel Messages ..................9
    2.3. Ethernet Link Header and Trailer ..........................10
    2.4. Special Transmission and Rate Considerations ..............10
 3. Processing RBridge Channel TRILL Data Messages .................11
    3.1. Processing the RBridge Channel Header .....................12
    3.2. RBridge Channel Errors ....................................13
 4. Native RBridge Channel Frames ..................................14
 5. Indicating Support for RBridge Channel Protocols ...............16
 6. Congestion Considerations ......................................16
 7. Allocation Considerations ......................................17
    7.1. IANA Considerations .......................................17
    7.2. IEEE Registration Authority Considerations ................18
 8. Security Considerations ........................................18
 9. References .....................................................19
    9.1. Normative References ......................................19
    9.2. Informative References ....................................20
 10. Acknowledgments ...............................................20

Eastlake, et al. Standards Track [Page 2] RFC 7178 TRILL: RBridge Channel Support May 2014

1. Introduction

 RBridge campuses provide transparent least-cost forwarding using the
 Transparent Interconnection of Lots of Links (TRILL) protocol that
 builds on Intermediate System to Intermediate System (IS-IS) routing
 [IS-IS] [RFC1195] [RFC7176].  Devices that implement TRILL are called
 Routing Bridges (RBridges) or TRILL Switches.  However, the TRILL
 base protocol standard [RFC6325] provides only for TRILL Data
 messages and TRILL IS-IS messages.
 This document specifies a general channel mechanism for the
 transmission of other messages within an RBridge campus, such as BFD
 [RFC5880] messages, (1) between RBridges and end stations that are
 directly connected on the same link and (2) between RBridges.  This
 mechanism supports a requirement to be able to operate with minimal
 configuration.

1.1. RBridge Channel Requirements

 It is anticipated that various protocols operating at the TRILL layer
 will be desired in RBridge campuses.  For example, there is a need
 for rapid-response continuity checking with a protocol such as BFD
 [RFC5880] [RFC5882] and for a variety of optional reporting.
 To avoid the requirement to design and specify a way to carry each
 such protocol, this document specifies a general channel for sending
 messages between RBridges in a campus at the TRILL level by extending
 the TRILL protocol.  To accommodate a wide variety of protocols, this
 RBridge Channel facility accommodates all the regular modes of TRILL
 Data transmission including single- and multiple-hop unicast as well
 as VLAN-scoped multi-destination distribution.
 To minimize any unnecessary burden on transit RBridges and to provide
 a more realistic test of network continuity and the like, RBridge
 Channel messages are designed to look like TRILL Data frames and, in
 the case of multi-hop messages, can normally be handled by transit
 RBridges as if they were TRILL Data frames; however, to enable
 processing at transit RBridges when required by particular messages,
 they may optionally use the RBridge Channel Alert TRILL extended
 header flags [RFC7179] that causes a transit RBridge implementing the
 flag to more closely examine a flagged frame.
 This document also specifies a format for sending RBridge Channel
 messages between RBridges and end stations that are directly
 connected over a link, in either direction, when provided for by the
 protocol involved.  For the most part, this format is the same as the
 format that is encapsulated by TRILL Data for inter-RBridge Channel
 messages.

Eastlake, et al. Standards Track [Page 3] RFC 7178 TRILL: RBridge Channel Support May 2014

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

1.2. Relation to the MPLS Generic Associated Channel

 The RBridge Channel is similar to the MPLS Generic Associated Channel
 specified in [RFC5586].  Instead of using a special MPLS label to
 indicate a special channel message, an RBridge Channel message is
 indicated by a special multicast Inner.MacDA and inner Ethertype (see
 Section 2.1).

1.3. Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].
 The terminology and acronyms of [RFC6325] are used in this document
 with the additions listed below.
    BFD - Bidirectional Forwarding Detection
    CHV - Channel Header Version
    MH - Multi-Hop
    NA - Native
    SL - Silent

2. Inter-RBridge Channel Messages

 Channel messages between RBridges are transmitted as TRILL Data
 frames.  (For information on channel messages that can be transmitted
 between RBridges and end stations that are directly connected by a
 link, see Section 4.)  Inter-RBridge Channel messages are identified
 as such by their Inner.MacDA, which is the All-Egress-RBridges
 multicast address, together with their inner Ethertype, which is the
 RBridge-Channel Ethertype.  This Ethertype is part of and starts the
 RBridge Channel Header.

Eastlake, et al. Standards Track [Page 4] RFC 7178 TRILL: RBridge Channel Support May 2014

 The diagram below shows the overall structure of an RBridge Channel
 Message frame on a link between two RBridges:
            Frame Structure             Section of This Document
                                        ------------------------
   +--------------------------------+
   |          Link Header           |   Section 2.3 if Ethernet link
   +--------------------------------+
   |          TRILL Header          |   Section 2.2
   +--------------------------------+
   |     Inner Ethernet Header      |   Section 2.1.2
   +--------------------------------+
   |     RBridge Channel Header     |   Section 2.1.1
   +--------------------------------+
   |   Protocol-Specific Payload    |   See specific channel protocol
   +--------------------------------+
   | Link Trailer (FCS if Ethernet) |
   +--------------------------------+
              Figure 1: RBridge Channel Frame Structure
 Optionally, some channel messages may require examination of the
 frame by transit RBridges that support the RBridge Channel feature,
 to determine if they need to take any action.  To indicate this, such
 messages use an RBridge Channel Alert extended TRILL Header flag as
 further described in Section 3 below.
 Sections 2.1 and 2.2 describe the inner frame and the TRILL Header
 for frames sent in an RBridge Channel.  As always, the outer Link
 Header and Link Trailer are whatever is needed to get a TRILL Data
 frame to the next-hop RBridge, depending on the technology of the
 link, and can change with each hop for multi-hop messages.  Section
 2.3 describes the outer Link Header for Ethernet links, and Section
 2.4 discusses some special considerations for the first hop
 transmission of RBridge Channel messages.
 Section 3 describes some details of RBridge Channel message
 processing.  Section 4 provides the specifications for native RBridge
 Channel frames between RBridges and end stations that are directly
 connected over a link.  Section 5 describes how support for RBridge
 Channel protocols is indicated.  And Sections 6, 7, and 8 give
 congestion, allocation (IANA and IEEE), and security considerations
 respectively.

Eastlake, et al. Standards Track [Page 5] RFC 7178 TRILL: RBridge Channel Support May 2014

2.1. RBridge Channel Message Inner Frame

 The encapsulated inner frame within an RBridge Channel message frame
 is as shown below.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  Inner Ethernet Header:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Special Inner.MacDA = All-Egress-RBridges             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Special Inner.MacDA cont.   |         Inner.MacSA           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Inner.MacSA cont.                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       VLAN Tag Ethertype      |  Priority, DEI, VLAN ID       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  RBridge Channel Header:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    RBridge-Channel Ethertype  |  CHV  |   Channel Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Flags        |  ERR  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Information specific to the RBridge Channel Protocol:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                 Channel-Protocol-Specific Data
    |  ...
          Figure 2: RBridge Channel Inner Frame Header Fields
 The Channel-Protocol-Specific Data contains the information related
 to the specific channel protocol used in the channel message.
 Details of that data are outside the scope of this document, except
 in the case of the RBridge Channel Error protocol specified in
 Section 3.2.

2.1.1. RBridge Channel Header

 As shown in Figure 2, the RBridge Channel Header starts with the
 RBridge-Channel Ethertype (see Section 7.2).  Following that is a
 four-byte quantity with four sub-fields as follows:
    CHV: A 4-bit field that gives the RBridge Channel Header Version.
       This document specifies version zero.

Eastlake, et al. Standards Track [Page 6] RFC 7178 TRILL: RBridge Channel Support May 2014

    Channel Protocol: A 12-bit unsigned integer that specifies the
       particular RBridge Channel protocol to which the message
       applies.
    Flags: Provides 12 bits of flags as described below.
    ERR: A 4-bit unsigned integer used in connection with error
       reporting at the RBridge Channel level as described in Section
       3.
 The flag bits are numbered from 0 to 11 as shown below.
              | 0  1  2  3  4  5  6  7  8  9 10 11|
              +--+--+--+--+--+--+--+--+--+--+--+--+
              |SL|MH|NA|        Reserved          |
              +--+--+--+--+--+--+--+--+--+--+--+--+
               Figure 3: Channel Header Flag Bits
    Bit 0: The SL or Silent bit, the high-order bit in network order.
       If it is a one, it suppresses RBridge Channel Error messages
       (see Section 3).
    Bit 1: The MH or Multi-Hop bit.  It is used to inform the
       destination RBridge protocol that the message may be multi-hop
       (MH=1) or was intended to be one-hop only (MH=0).
    Bit 2: The NA or Native bit.  It is used as described in Section
       4.
    Reserved: Bits reserved for future specification that MUST be sent
       as zero and ignored on receipt.
 The RBridge Channel Protocol field specifies the protocol that the
 channel message relates to.  The initial defined value is listed
 below.
       Protocol  Name - Section of This Document
       --------  -------------------------------
        0x001    RBridge Channel Error - Section 3
 IANA Considerations for RBridge Channel protocol numbers are provided
 in Section 7.  These include provisions for Private Use protocol
 numbers.  Because different uses of Private Use RBridge Channel
 protocol numbers may conflict, such use MUST be within a private
 network.  It is the responsibility of the private network manager to
 avoid conflicting use of these code points and unacceptable burdens
 within the private network from their use.

Eastlake, et al. Standards Track [Page 7] RFC 7178 TRILL: RBridge Channel Support May 2014

2.1.2. Inner Ethernet Header

 The special Inner.MacDA is the All-Egress-RBridges multicast Media
 Access Control (MAC) address to signal that the frame is intended for
 the egress (decapsulating) RBridge itself (or the egress RBridges
 themselves if the frame is multi-destination).  (This address is
 called the All-ESADI-RBridges address in [RFC6325].)  The RBridge-
 Channel Ethertype indicates that the frame is an RBridge Channel
 message.  The only other Ethertype currently specified for use with
 the All-Egress-RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI
 frame [RFC6325].  In the future, additional Ethertypes may be
 specified for use with the All-Egress-RBridges multicast address.
 The RBridge originating the channel message selects the Inner.MacSA.
 The Inner.MacSA MUST be set by the originating RBridge to a MAC
 address unique within the campus owned by the originating RBridge.
 This MAC address can be considered, in effect, the MAC address of a
 virtual internal end station that handles the RBridge Channel frames
 originated by or destined for that RBridge.  It MAY be the same as
 the Inner.MacSA used by the RBridge when it originates ESADI frames
 [RFC6325].

2.1.3. Inner.VLAN Tag

 As with all frames formatted to be processed as a TRILL Data frame,
 an Inner.VLAN tag is present.  Use of a VLAN tag Ethertype other than
 0x8100 or stacked tags is beyond the scope of this document but is an
 obvious extension.
 Multi-destination RBridge Channel messages are, like all multi-
 destination TRILL Data messages, VLAN scoped so the Inner.VLAN ID
 MUST be set to the VLAN of interest.  To the extent that distribution
 tree pruning is in effect in the campus, such channel messages may
 only reach RBridges advertising that they have connectivity to that
 VLAN.
 For channel messages sent as known unicast TRILL Data frames, the
 default value for the Inner.VLAN ID is VLAN 1, but particular RBridge
 Channel protocols MAY specify other values.
 The Inner.VLAN also specifies a three-bit frame priority for which
 the following recommendations apply:
 1.  For one-hop channel messages critical to network connectivity,
     such as one-hop BFD for rapid link-failure detection in support
     of TRILL IS-IS, the RECOMMENDED priority is 7.

Eastlake, et al. Standards Track [Page 8] RFC 7178 TRILL: RBridge Channel Support May 2014

 2.  For single and multi-hop unicast channel messages important to
     network operation but not critical for connectivity, the
     RECOMMENDED priority is 6.
 3.  For other unicast channel messages and all multi-destination
     channel messages, it is RECOMMENDED that the default priority
     zero be used.  In any case, priorities higher than 5 SHOULD NOT
     be used for such frames.
 There is one additional bit in a VLAN tag value between the 12-bit
 VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI)
 [RFC7180].  It is RECOMMENDED that this bit be zero for the first two
 categories of channel messages listed immediately above.  The setting
 of this bit for channel messages in the third category may be
 dependent on the channel protocol and no general recommendation is
 made for that case.

2.2. TRILL Header for RBridge Channel Messages

 After the outer Link Header (that, for an Ethernet link, ends with
 the TRILL Ethertype) and before the encapsulated frame, the channel
 message's TRILL Header initially appears as follows:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |V=0| R |M| Op-Len  | Hop Count |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Egress Nickname         |       Ingress Nickname        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 4: RBridge Channel TRILL Header Fields
 The TRILL Header version (V) MUST be zero; the R bits are reserved;
 the M bit is set appropriately as the channel message is to be
 forwarded as known destination unicast (M=0) or multi-destination
 (M=1), regardless of the fact that the Inner.MacDA is always the All-
 Egress-RBridges multicast address; and Op-Len is set appropriately
 for the length of the TRILL Header extensions area, if any, all as
 specified in [RFC6325].
 When an RBridge Channel message is originated, the Hop Count field
 defaults to the maximum value, 0x3F, but particular RBridge Channel
 protocols MAY specify other values.  For messages sent a known number
 of hops, such as one-hop messages or a two-hop self-addressed message
 intended to loop back through an immediate neighbor RBridge, setting
 the Hop Count field in the TRILL Header to the maximum value and
 checking its value on receipt provides an additional validity check

Eastlake, et al. Standards Track [Page 9] RFC 7178 TRILL: RBridge Channel Support May 2014

 as discussed in [RFC5082], where this type of field is referred to as
 "TTL" or "Hop Limit".
 The RBridge originating a channel message places a nickname that it
 holds in the Ingress Nickname field.
 There are several cases for the Egress Nickname field.  If the
 channel message is multi-destination, then the Egress Nickname
 designates the distribution tree to use.  If the channel message is a
 multi-hop unicast message, then the Egress Nickname is a nickname of
 the target RBridge; this includes the special case of a message
 intended to loop back from an immediate neighbor where the originator
 places one of its own nicknames in both the Ingress Nickname and
 Egress Nickname fields.  If the channel message is a one-hop unicast
 message, there are two possibilities for the Egress Nickname.
 o  The Egress Nickname can be set to a nickname of the target
    neighbor RBridge.
 o  The special nickname Any-RBridge may be used.  RBridges supporting
    the RBridge Channel facility MUST recognize the Any-RBridge
    special nickname and accept TRILL Data frames having that value in
    the Egress Nickname field as being sent to them as the egress.
    Thus, for such RBridges, using this egress nickname guarantees
    processing by an immediate neighbor regardless of the state of
    nicknames.

2.3. Ethernet Link Header and Trailer

 An RBridge Channel frame has the usual Link Header and Link Trailer
 for a TRILL Data frame depending on the type of link on which it is
 sent.
 For an Ethernet link [RFC6325], the Outer.MacSA is the MAC address of
 the port from which the frame is sent.  The Outer.MacDA is the MAC
 address of the next-hop RBridge port for unicast RBridge Channel
 messages or the All-RBridges multicast address for multi-destination
 RBridge Channel messages.  The Outer.VLAN tag specifies the
 designated VLAN for that hop, and the priority should be the same as
 in the Inner.VLAN tag; however, the output port may have been
 configured to strip VLAN tags, in which case no Outer.VLAN tag
 appears on the wire.  And the Link Trailer is the Ethernet FCS.

2.4. Special Transmission and Rate Considerations

 If a multi-hop RBridge Channel message is received by an RBridge, the
 criteria and method of forwarding it are the same as for any TRILL
 Data frame.  If it is so forwarded, it will be on a link that was

Eastlake, et al. Standards Track [Page 10] RFC 7178 TRILL: RBridge Channel Support May 2014

 included in the routing topology because it was in the Report state
 as specified in [RFC7177].
 However, special considerations apply to single-hop messages because,
 for some RBridge Channel protocols, it may be desirable to send
 RBridge Channel messages over a link that is not yet fully up.  In
 particular, it is permissible, if specified by the particular channel
 protocol, for the source RBridge that has created an RBridge Channel
 message to attempt to transmit it to a next-hop RBridge when the link
 is in the Detect or 2-Way state, as specified in [RFC7177], as well
 as when it is in the Report state.  Such messages can also be sent on
 point-to-point links that are not in the Up state.
 RBridge Channel messages represent a burden on the RBridges, and
 links in a campus and should be rate limited, especially if they are
 sent as high priority, multi-destination, or multi-hop frames or have
 an RBridge Channel Alert extended header flag set.  See Section 6,
 "Congestion Considerations".

3. Processing RBridge Channel TRILL Data Messages

 RBridge Channel TRILL Data messages are designed to look like and, to
 the extent practical, be forwarded as regular TRILL Data frames.  On
 receiving a channel message, an RBridge performs the usual initial
 tests on the frame and makes the same forwarding and/or decapsulation
 decisions as for a regular TRILL Data frame [RFC6325] with the
 following exceptions for RBridges implementing the RBridge Channel
 facility:
 1.  An RBridge implementing the RBridge Channel facility MUST
     recognize the Any-RBridge egress nickname in TRILL Data frames,
     decapsulating such frames if they meet other checks.  (Such a
     frame cannot be a valid multi-destination frame because the Any-
     RBridge nickname is not a valid distribution tree root.)
 2.  If an RBridge Channel Alert extended header flag is set, then the
     RBridge MUST process the RBridge Channel message as described
     below even if it is not egressing the frame.  If it is egressing
     the frame, then no additional processing beyond egress processing
     is needed even if an RBridge Channel Alert flag is set.
 3.  On decapsulation, the special Inner.MacDA value of All-Egress-
     RBridges MUST be recognized to trigger checking the
     Inner.Ethertype and processing as an RBridge Channel message if
     that Ethertype is RBridge-Channel.

Eastlake, et al. Standards Track [Page 11] RFC 7178 TRILL: RBridge Channel Support May 2014

 RBridge Channel messages SHOULD only be sent to RBridges that
 advertise support for the channel protocol involved as described in
 Section 5.
 All RBridges supporting the RBridge Channel facility MUST recognize
 the RBridge-Channel inner Ethertype.

3.1. Processing the RBridge Channel Header

 Knowing that it has an RBridge Channel message, the egress RBridge,
 and any transit RBridge if an RBridge Channel Alert bit is set in the
 TRILL Header, looks at the CHV (RBridge Channel Header Version) and
 Channel Protocol fields.
 If any of the following conditions occur at an egress RBridge, the
 frame is not processed, an error may be generated as specified in
 Section 3.2, and the frame is discarded.  The behavior is the same if
 the frame is being processed at a transit RBridge because the RBridge
 Critical Channel Alert flag is set [RFC7179].  However, if these
 conditions are detected at a transit RBridge examining the message
 because the RBridge Non-critical Channel Alert flag is set [RFC7179]
 but the RBridge Critical Channel Alert flag is not set, no error is
 generated, and the frame is still forwarded normally.
 Error Conditions:
 1.  The Ethertype is not RBridge-Channel and not any other Ethertype
     known to the RBridge as usable with the All-Egress-RBridges
     Inner.MacDA, or the frame is so short that the Ethertype is
     truncated.
 2.  The CHV field is non-zero, or the frame is so short that the
     version zero Channel Header is truncated.
 3.  The Channel Protocol field is a reserved value or a value unknown
     to the processing RBridge.
 4.  The ERR field is non-zero, and Channel Protocol is a value other
     than 0x001.
 5.  The RBridge Channel Header NA flag is set to one, indicating that
     the frame should have been received as a native frame rather than
     a TRILL Data frame.
 If the CHV field and NA flag are zero and the processing RBridge
 recognizes the Channel Protocol value, it processes the message in
 accordance with that channel protocol.  The processing model is as if
 the received frame starting with and including the TRILL Header is

Eastlake, et al. Standards Track [Page 12] RFC 7178 TRILL: RBridge Channel Support May 2014

 delivered to the Channel protocol along with a flag indicating
 whether this is (a) transit RBridge processing due to an RBridge
 Channel Alert flag being set or (b) egress processing.
 Errors within a recognized Channel Protocol are handled by that
 channel protocol itself and do not produce RBridge Channel Error
 frames.

3.2. RBridge Channel Errors

 A variety of problems at the RBridge Channel level cause the return
 of an RBridge Channel Error frame unless one of the following apply:
 (a) the "SL" (Silent) flag is a one in the channel message for which
 the problem was detected, (b) the processing is due to the RBridge
 Non-critical Channel Alert flag being set, (c) the frame in error
 appears, itself, to be an RBridge Channel Error frame (has a non-zero
 ERR field or a Channel Protocol of 0x001), or (d) the error is
 suppressed due to rate limiting.
 An RBridge Channel Error frame is a multi-hop unicast RBridge Channel
 message with the Ingress Nickname set to a nickname of the RBridge
 detecting the error and the Egress Nickname set to the value of the
 Ingress Nickname in the channel message for which the error was
 detected.  No per-hop transit processing is specified for such error
 frames, so the RBridge Channel Alert extended header flags SHOULD, if
 an extension is present, be set to zero.  The SL and MH flags SHOULD
 be set to one; the NA flag MUST be zero; and the ERR field MUST be
 non-zero as described below.  For the protocol-specific data area, an
 RBridge Channel Message Error frame has at least the first 256 bytes
 (or less if less are available) of the erroneous decapsulated channel
 message starting with the TRILL Header.  (Note: The TRILL Header does
 not include the TRILL Ethertype that is part of the Link Header on
 Ethernet links.)
 The following values for ERR are specified:
    ERR   RBridge Channel Error Code Meaning
    ---   ----------------------------------
     0    No error
     1    Frame too short (truncated Ethertype or Channel Header)
     2    Unrecognized Ethertype
     3    Unimplemented value of CHV
     4    Wrong value of NA flag
     5    Channel Protocol is reserved or unimplemented
    6-14  Unassigned (see Section 7)
    15    Reserved (see Note)

Eastlake, et al. Standards Track [Page 13] RFC 7178 TRILL: RBridge Channel Support May 2014

    Note:  Intended to be allocated by Standards Action for an error
           code expansion feature when it appears likely that all
           other available error codes are being allocated.
 All RBridges implementing the RBridge Channel feature MUST recognize
 the RBridge Channel Error protocol value (0x001).  They MUST NOT
 generate an RBridge Channel Error message in response to an RBridge
 Channel Error message, that is, a channel message with a protocol
 value of 0x001 or with a non-zero ERR field.

4. Native RBridge Channel Frames

 Other sections of this document specify non-native RBridge Channel
 messages and their processing, that is, RBridge Channel messages
 formatted as TRILL Data frames and sent between RBridges.  This
 section specifies the differences for native RBridge Channel
 messages.
 If provided for by the channel protocol involved, native RBridge
 Channel messages may be sent between end stations and RBridges that
 are directly connected over a link, in either direction.  On an
 Ethernet link, such native frames have the RBridge-Channel Ethertype
 and are like the encapsulated frame inside an RBridge Channel message
 except as follows:
 1.  TRILL does not require the presence of a VLAN tag on such native
     RBridge Channel frames.  However, port configuration, link
     characteristics, or the channel protocol involved may require
     such tagging.
 2.  If the frame is unicast, the destination MAC address is the
     unicast MAC address of the RBridge or end-station port that is
     its intended destination.  If the frame is multicast by an end
     station to all the RBridges on a link that support an RBridge
     Channel protocol using this transport, the destination MAC
     address is the All-Edge-RBridges multicast address (see Section
     7).  A native RBridge Channel frame received at an ingress
     RBridge is discarded if its destination MAC address is neither
     the unicast address of the port nor the multicast address All-
     Edge-RBridges.  If the frame is multicast by an RBridge to all
     the devices that TRILL considers to be end stations on a link and
     that support an RBridge Channel protocol using this transport,
     the destination MAC address is the TRILL-End-Stations multicast
     address (see Section 7).  A native RBridge Channel frame received
     at an end station is discarded if its destination MAC address is
     neither the unicast address of the port nor the multicast address
     TRILL-End-Stations.

Eastlake, et al. Standards Track [Page 14] RFC 7178 TRILL: RBridge Channel Support May 2014

 3.  The RBridge-Channel outer Ethertype must be present.  In the
     future, there may be other protocols using the All-Edge-RBridges
     and/or TRILL-End-Stations multicast addresses on native frames
     distinguished by different Ethertypes.
 4.  The NA or Native bit in the RBridge Channel Header flags MUST be
     a one.
 5.  There might be additional tags present between the Outer.MacDA,
     Outer.MacSA pair, and the RBridge-Channel Ethertype.
 The RBridge Channel protocol number space for native RBridge Channel
 messages and TRILL Data formatted RBridge Channel messages is the
 same.  If provided for by the channel protocol involved, the receipt
 of a native RBridge Channel frame MAY lead to the generation and
 transmission of one or more Inter-RBridge Channel frames.  The
 decapsulation and processing of a TRILL Data RBridge Channel frame
 MAY, if provided for by the channel protocol involved, result in the
 sending of one or more native RBridge Channel frames to one or more
 end stations.  Thus, there could be an RBridge Channel protocol that
 involved an RBridge Channel message sent (1) from an origin RBridge
 where the message is created, (2) through one or more transit
 RBridges, and (3) from a final RBridge as a native RBridge Channel
 message to an end station (or the reverse of such a three-part path);
 however, to do this, the RBridge Channel protocol involved must be
 implemented at the RBridge where the channel message is changed
 between a native frame and a TRILL Data format frame, and that
 RBridge must change the channel message itself, at a minimum
 complementing the NA flag in the Channel Header and making
 appropriate MAC address changes.
 An erroneous native channel message results in a native RBridge
 Channel Error message under the same conditions for which a TRILL
 Data RBridge Channel message would result in a TRILL Data RBridge
 Channel Error message.  However, in a native RBridge Channel Error
 message, the NA flag MUST be one.  Also, since there is no TRILL
 Header in native RBridge Channel protocol frames, the beginning part
 of the frame in which the error was detected that is included in
 native RBridge Channel Error frames starts with the RBridge Channel
 Header (including the RBridge-Channel Ethertype).  The destination
 MAC address of such error messages is set to the source MAC address
 of the native RBridge Channel message that was in error.
 There is no mechanism to stop end stations from directly exchanging
 native RBridge Channel messages, but such usage is beyond the scope
 of this document.

Eastlake, et al. Standards Track [Page 15] RFC 7178 TRILL: RBridge Channel Support May 2014

5. Indicating Support for RBridge Channel Protocols

 Support for RBridge Channel protocols is indicated by the presence of
 one or more TLVs and/or sub-TLVs in an RBridge's Link State PDU (LSP)
 as documented in [RFC7176].
 RBridge Channel protocols 0 and 0xFFF are reserved, and protocol 1,
 the RBridge Channel Error protocol, MUST be implemented as part of
 the RBridge Channel feature.  Thus, if an RBridge supports the
 RBridge Channel feature, it should be advertising support for
 protocol 1 and not advertising support for protocols 0 or 0xFFF in
 its LSP.  However, indication of support or non-support for RBridge
 Channel protocol 1 is ignored on receipt, and support for it is
 always assumed if support for any RBridge Channel is indicated in the
 RBridge's LSP.

6. Congestion Considerations

 The bandwidth resources used by RBridge Channel protocols are
 recommended to be small compared to the total bandwidth of the links
 they traverse.  When doing network planning, the bandwidth
 requirements for TRILL Data, TRILL IS-IS, TRILL ESADI, RBridge
 Channel protocol traffic, and any other link-local traffic need to be
 taken into account.
 Specifications for particular RBridge Channel protocols MUST consider
 congestion and bandwidth usage implications and provide guidance on
 bandwidth or packet-frequency management.  RBridge Channel protocols
 can have built-in bandwidth management in their protocols.  Outgoing
 channel messages SHOULD be rate-limited, by configuring the
 underlying protocols or otherwise, to prevent aggressive connectivity
 verification or other applications consuming excessive bandwidth,
 causing congestion, or becoming denial-of-service attacks.
 If these conditions cannot be followed, an adaptive loss-based scheme
 SHOULD be applied to congestion-control outgoing RBridge Channel
 traffic, so that it competes fairly, taking into account packet
 priorities and drop eligibility as indicated in the Inner.VLAN, with
 TCP or similar traffic within an order of magnitude.  One method of
 determining an acceptable bandwidth for RBridge Channel traffic is
 described in [RFC5348]; other methods exist.  For example, bandwidth
 or packet-frequency management can include any of the following: a
 negotiation of transmission interval/rate such as that provided in
 BFD [RFC5880], a throttled transmission rate on "congestion detected"
 situations, a gradual ramp-up after shutdown due to congestion and
 until basic connectivity is verified, and other mechanisms.

Eastlake, et al. Standards Track [Page 16] RFC 7178 TRILL: RBridge Channel Support May 2014

 Connectivity-checking applications such as BFD [RFC5880] SHOULD be
 rate-limited to below 5% of the bitrate of the associated link or
 links.  For this purpose, the mean or sustained bitrate of the link
 or links is used.
 Incoming RBridge Channel messages MAY be rate-limited as a protection
 against denial-of-service attacks.  This throttling of incoming
 messages SHOULD honor packet priorities and drop eligibility
 indications as indicated in the Inner.VLAN, preferentially discarding
 drop-eligible and lower-priority packets.

7. Allocation Considerations

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

7.1. IANA Considerations

 IANA has allocated a previously unassigned TRILL Nickname as follows:
       Any-RBridge           0xFFC0
 IANA has added "All-Egress-RBridges" to the TRILL Parameter Registry
 as an alternative name for the "All-ESADI-RBridges" multicast
 address.
 IANA has allocated two previously unassigned TRILL multicast
 addresses as follows:
       TRILL-End-Stations    01-80-C2-00-00-45
       All-Edge-RBridges     01-80-C2-00-00-46
 IANA has created an additional sub-registry in the TRILL Parameter
 Registry for RBridge Channel Protocols, with initial contents as
 follows:
    Protocol      Description                     Reference
    --------      -----------                     ---------
    0x000         Reserved; not to be allocated   (This document)
    0x001         RBridge Channel Error           (This document)
    0x002-0x0FF   Unassigned (1)
    0x100-0xFF7   Unassigned (2)
    0xFF8-0xFFE   Reserved for Private Use
    0xFFF         Reserved; not to be allocated   (This document)

Eastlake, et al. Standards Track [Page 17] RFC 7178 TRILL: RBridge Channel Support May 2014

 (1) RBridge Channel protocol code points from 0x002 to 0x0FF require
     a Standards Action, as modified by [RFC7120], for allocation.
 (2) RBridge Channel protocol code points from 0x100 to 0xFF7 are RFC
     Required to allocate a single value or IESG Approval to allocate
     multiple values.
 IANA has created an additional sub-registry in the TRILL Parameter
 Registry for RBridge Channel Header Flags with initial contents as
 follows:
       Flag Bit  Mnemonic  Allocation
       --------  --------  ----------
          0         SL     Silent
          1         MH     Multi-hop
          2         NA     Native
         3-11       -      Unassigned
 Allocation of an RBridge Channel Header Flag is based on IETF Review.
 IANA has created an additional sub-registry in the TRILL Parameter
 Registry for RBridge Channel Error Codes with initial contents as
 listed in Section 3.2 above and with available values allocated by
 Standards Action as modified by [RFC7120].

7.2. IEEE Registration Authority Considerations

 The IEEE Registration Authority has assigned the Ethertype 0x8946 for
 TRILL RBridge Channel.

8. Security Considerations

 No general integrity, authentication, or encryption mechanisms are
 provided herein for RBridge Channel messages.  If these services are
 required for a particular RBridge Channel protocol, they MUST be
 supplied by that channel protocol.  See, for example, the BFD
 Authentication mechanism [RFC5880].
 See [RFC6325] for general TRILL security considerations.  As stated
 therein, no protection is provided by TRILL against forging of the
 Ingress Nickname in a TRILL Data formatted channel message or the
 Outer.MacSA in a native RBridge Channel frame on an Ethernet link.
 This may result in misdirected return responses or error messages.
 However, link-level security protocols may be used to authenticate
 the origin station on a link and protect against attacks on links.
 See also Section 6 concerning congestion.

Eastlake, et al. Standards Track [Page 18] RFC 7178 TRILL: RBridge Channel Support May 2014

 If indications of RBridge Channel Protocol support are improperly
 absent from an RBridge's LSP, it could deny all RBridge Channel
 services, for example, some BFD services, for the RBridge in
 question.  If a particular RBridge Channel protocol is incorrectly
 not advertised as supported, it could deny the service of that
 channel protocol to the RBridge in question.
 Incorrect indication of RBridge Channel Protocol support or incorrect
 assertion of support for a channel protocol could encourage RBridge
 Channel messages to be sent to an RBridge that does not support the
 channel feature or the particular channel protocol used.  The inner
 frame of such messages could be decapsulated and that inner frame
 could be sent out all ports that are Appointed Forwarders for the
 frame's Inner.VLAN.  However, this is unlikely to cause much harm; in
 particular, there are two possibilities as follows: (a) if end
 stations do not recognize the RBridge-Channel Ethertype of the frame,
 they will drop it, and (b) if end stations do recognize the RBridge-
 Channel Ethertype and the channel protocol indicated in the frame,
 they should refuse to process the frame due to an incorrect value of
 the RBridge Channel Header NA flag.

9. References

9.1. Normative References

 [IS-IS]    International Organization for Standardization,
            "Intermediate System to Intermediate System intra-domain
            routeing information exchange protocol for use in
            conjunction with the protocol for providing the
            connectionless-mode network service (ISO 8473)", Second
            Edition, November 2002.
 [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
            dual environments", RFC 1195, December 1990.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.
 [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
            Friendly Rate Control (TFRC): Protocol Specification", RFC
            5348, September 2008.

Eastlake, et al. Standards Track [Page 19] RFC 7178 TRILL: RBridge Channel Support May 2014

 [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
            Ghanwani, "Routing Bridges (RBridges): Base Protocol
            Specification", RFC 6325, July 2011.
 [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
            Points", BCP 100, RFC 7120, January 2014.
 [RFC7176]  Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
            D., and A. Banerjee, "Transparent Interconnection of Lots
            of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
 [RFC7177]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
            V. Manral, "Transparent Interconnection of Lots of Links
            (TRILL): Adjacency", RFC 7177, May 2014.
 [RFC7179]  Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C.
            Bestler, "Transparent Interconnection of Lots of Links
            (TRILL): Header Extension", RFC 7179, May 2014.

9.2. Informative References

 [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
            Pignataro, "The Generalized TTL Security Mechanism
            (GTSM)", RFC 5082, October 2007.
 [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
            "MPLS Generic Associated Channel", RFC 5586, June 2009.
 [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
            (BFD)", RFC 5880, June 2010.
 [RFC5882]  Katz, D. and D. Ward, "Generic Application of
            Bidirectional Forwarding Detection (BFD)", RFC 5882, June
            2010.
 [RFC7180]  Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
            A. Banerjee, "Transparent Interconnection of Lots of Links
            (TRILL): Clarifications, Corrections, and Updates", RFC
            7180, May 2014.

10. Acknowledgments

 The authors gratefully acknowledge the comments and contributions of
 the follows, listed is alphabetic order: Stewart Bryant, Somnath
 Chatterjee, Adrian Farrel, Stephen Farrell, Miguel A. Garcia, Anoop
 Ghanwani, Brian Haberman, Rakesh Kumar, Barry Leiba, and Tissa
 Senevirathne.

Eastlake, et al. Standards Track [Page 20] RFC 7178 TRILL: RBridge Channel Support May 2014

Authors' Addresses

 Donald Eastlake 3rd
 Huawei R&D USA
 155 Beaver Street
 Milford, MA 01757
 USA
 Phone: +1-508-333-2270
 EMail: d3e3e3@gmail.com
 Vishwas Manral
 Ionos Corp.
 4100 Moorpark Ave.
 San Jose, CA  95117
 USA
 EMail: vishwas@ionosnetworks.com
 Yizhou Li
 Huawei Technologies
 101 Software Avenue,
 Nanjing 210012
 China
 Phone: +86-25-56622310
 EMail: liyizhou@huawei.com
 Sam Aldrin
 Huawei Technologies
 2330 Central Expressway
 Santa Clara, CA 95050
 USA
 Phone: +1-408-330-5000
 EMail: sam.aldrin@huawei.com
 Dave Ward
 Cisco Systems
 170 W. Tasman Drive
 San Jose, CA 95134
 USA
 EMail: dward@cisco.com

Eastlake, et al. Standards Track [Page 21]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7178.txt · Last modified: 2014/05/08 06:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki