TRILL Working Group                                      Donald Eastlake
INTERNET-DRAFT                                                    Huawei
Intended status: Proposed Standard                        Vishwas Manral
Updates: RFCtrill                                            IP Infusion
                                                               Dave Ward
                                                               Li Yizhou
                                                              Sam Aldrin
Expires: September 6, 2011                                 March 7, 2011

                 RBridges: OAM Channel Support in TRILL


   This document specifies a general channel for sending OAM
   (Operations, Administration, and Maintenance) messages in an RBridge
   campus through an extension 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: OAM Channel

Table of Contents

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

      2. The TRILL OAM Channel Messages..........................5
      2.1 The OAM Message Inner Frame............................6
      2.1.1 TRILL OAM Channel Header.............................6
      2.1.2 Inner Ethernet Header................................7
      2.1.3 Inner.VLAN...........................................7
      2.3 The TRILL Header for OAM Messages......................8
      2.4 OAM Message Ethernet Link Header.......................9
      2.5 Special Transmission and Rate Considerations...........9

      3. The TRILL OAM-Channel Extended Flag....................11

      4. Processing TRILL OAM Chanel Messages...................12
      4.1 Processing the TRILL OAM Channel Header...............12
      4.2 OAM Channel Errors....................................13

      5. Native TRILL-OAM Frames................................15

      6. Allocations Considerations.............................16
      6.1 IANA Considerations...................................16
      6.2 IEEE Registration Authority Considerations............17

      7. Security Considerations................................18

      8. References.............................................19
      8.1 Normative References..................................19
      8.2 Informative References................................19

D. Eastlake, et al                                              [Page 2]

INTERNET-DRAFT                                     RBridges: OAM Channel

1. Introduction

   RBridge campuses provide Layer 2 data networking using the TRILL
   protocol. However, the TRILL base protocol specification [RFCtrill]
   does not specifically provide for OAM (Operations, Administration,
   and Maintenance) messages. This document specifies a facility for the
   transmission of OAM messages within an RBridge campus.

   Familiarity with [RFCtrill] is assumed in this document.

1.1 TRILL Channel Requirements

   It is anticipated that various OAM 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, 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 functions.

   To avoid having to design and specify a way to carry each new OAM
   protocol in TRILL, this document specifies a general channel for
   sending OAM messages between RBridges in a campus at the TRILL level
   using extensions to the TRILL protocol. To accommodate a wide variety
   of OAM protocols, the OAM 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, TRILL OAM 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 of an OAM message at transit RBridges
   when required, an optional Alert non-critical hop-by-hop extended
   header flag is specified to cause transit RBridge to examine a frame
   with that flag set.

   This document also provides a format for sending OAM messages between
   end stations and RBridges, in either direction, when appropriate for
   the OAM protocol involved.

   Each particular OAM protocol will likely use only a subset of the
   facilities specified herein.

   The TRILL OAM Channel is similar to the MPLS Generic Channel
   specified in [RFC5586]. Instead of using a special MPLS label to
   indicate a special channel message, a TRILL OAM Channel message is
   indicated by a special Inner.MacDA.

D. Eastlake, et al                                              [Page 3]

INTERNET-DRAFT                                     RBridges: OAM Channel

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

      ICMP - Internet Control Message Protocol

      MH - Multi-Hop

      OAM - Operations, Administration, and Maintenance

      OV - OAM (Message Channel) Version

      SL - Silent

D. Eastlake, et al                                              [Page 4]

INTERNET-DRAFT                                     RBridges: OAM Channel

2. The TRILL OAM Channel Messages

   TRILL OAM messages are transmitted as TRILL Data frames. They are
   identified as OAM messages by their Inner.MacDA. The encapsulated
   frame has, after the Inner Ethernet Header, the TRILL-OAM Ethertype
   that is part of an OAM Channel Header. That Header indicates the OAM
   protocol of the following OAM protocol specific data.

   The diagram below shows the overall structure of a TRILL OAM Message
   Channel frame on a link between two RBridges:

               Frame Structure               Section of This Document
      |       Outer Link Header        |   Section 2.4 if Ethernet Link
      |          TRILL Header          |   Section 2.2
      |     Inner Ethernet Header      |   Section 2.1.2
      |    TRILL OAM Channel Header    |   Section 2.1.1
      | OAM Protocol Specific Payload  |   See specific OAM protocol
      | Link Trailer (FCS if Ethernet) |

   Some OAM messages may require examination of the frame, to determine
   if the transit RBridge needs to take any action, by transit RBridges
   that support the OAM Channel feature. To indicate this, a non-
   critical hop-by-hop extended TRILL header flag is allocated as the
   Alert bit, as further described in Section 4 below.

   In addition, a TRILL Header extended flag is provided that may
   optionally be used to guarantee that frames sent over the TRILL OAM
   Message Channel cannot be accidentally forwarded to end stations,
   even by minimally conformant RBridges that are ignorant of the TRILL
   OAM Message Channel feature.

   The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL
   Header for frames sent in the TRILL OAM Message Channel. As always,
   the Outer link header is whatever is needed to get a TRILL Data frame
   to the next hop RBridge, depends on link technology, and can change
   with each hop for multi-hop OAM messages. Section 2.4 describes the
   Outer link header for Ethernet. And Section 2.5 discusses some
   special considerations for the first hop transmission of OAM Channel

   Section 3 describes the OAM-Channel extended flag. Section 4
   describes some details of TRILL OAM Message processing. And Section 5

D. Eastlake, et al                                              [Page 5]

INTERNET-DRAFT                                     RBridges: OAM Channel

   specifies an optional format for native OAM frames.

2.1 The OAM Message Inner Frame

   The encapsulated Inner frame within a TRILL OAM Message Channel frame
   is as shown below.

    Inner Ethernet Header:
      |                    Special Inner.MacDA                        |
      |   Special Inner.MacDA cont.   |         Inner.MacSA           |
      |                       Inner.MacSA cont.                       |
      | Ethertype = C-Tag (0x8100)    |   Priority, VLAN ID           |
    TRILL OAM Channel Header:
      |       TRILL-OAM Ethertype     |  OV   |  TRILL OAM Protocol   |
      |           Flags       |  ERR  |
    OAM Protocol Specific Information:
      |                                                               |
      +                   OAM Protocol Specific Data
      |  ...

   The OAM protocol specific data contains the information related to
   the specific protocol type used in the OAM channel message. Details
   of that data are outside the scope of the document, except in the
   case of the OAM Channel error protocol specified below.

2.1.1 TRILL OAM Channel Header

   As shown in the diagram above, the TRILL OAM header starts with the
   TRILL OAM Ethertype (see Section 6.2). Following that is a four-byte
   quantity with four sub-fields as follows:

      OV gives the OAM Header version and MUST be zero.

      A 12-bit field that specifies the particular TRILL OAM protocol to
            which the message applies.

      Flags provides 12 bits of flags described below.

D. Eastlake, et al                                              [Page 6]

INTERNET-DRAFT                                     RBridges: OAM Channel

      ERR is a four-bit field used in connection with error reporting at
            the OAM Channel level as described in Section 4.

   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|       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 OAM Channel Error
   messages (see Section 4).

   Bit 1 is the MH or Multi-Hop bit. It is used to inform the
   destination OAM protocol that the message was intended to be multi-
   hop (MH=1) or one-hop (MH=0).

   The TRILL OAM Protocol field specifies the OAM protocol that the OAM
   Channel message relates to. The initial defined value is listed
   below. See Section 5 for IANA Considerations.

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

          0x0001   OAM Channel Error - Section 4

2.1.2 Inner Ethernet Header

   The special Inner.MacDA is All-OAM-RBridges to signal that the frame
   is a TRILL OAM Chanel message (see Section 6.1).

   The RBridge originating the OAM message selects the Inner.MacSA.
   Because OAM Channel messages are handled very much like ordinary
   TRILL Data frames, if the Inner.MacSA is a unicast MAC address, on
   decapsulation it will be learned as being attached to the ingress
   RBridge. If that learning is not desired, the Inner.MacSA MAY be set
   to All-OAM-RBridges or the like. MAC address learning on does not
   occur if the MAC address has the group bit on.

2.1.3 Inner.VLAN

   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.

D. Eastlake, et al                                              [Page 7]

INTERNET-DRAFT                                     RBridges: OAM Channel

   Multi-destination TRILL OAM 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, such OAM messages will only reach RBridges advertising
   that they have appointed forwarder connectivity to that VLAN.

   For known unicast OAM messages, 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 specify a three-bit frame priority for which the
   following recommendations apply:

   -  For one-hop OAM 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.

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

   -  For other known unicast OAM messages and all multi-destination OAM
      messages, it is RECOMMENDED that the default priority zero be used
      and, in any case priorities higher than 5 SHOULD NOT be used.

2.3 The TRILL Header for OAM Messages

   After the Outer link header (which, for Ethernet, ends with the TRILL
   Ethertype) and before the encapsulated frame, the OAM message's TRILL
   Header appears as follows:

                                       |V=0| R |M| Op-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 OAM message is known unicast (M=0)
   or multi-destination (M=1), and Op-Len is set appropriately for the
   length of the options area, if any, all as specified in [RFCtrill].

   When a TRILL OAM 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].

D. Eastlake, et al                                              [Page 8]

INTERNET-DRAFT                                     RBridges: OAM Channel

   The RBridge originating a TRILL OAM message places a nickname that it
   holds into the ingress nickname field.

   There are several cases for the egress nickname field. If the OAM
   message is multi-destination, then the egress nickname designates the
   distribution tree to use. If the OAM 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 OAM message is a one-hop
   unicast message, there are two possibilities for the egress nickname.

   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 TRILL OAM 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.4 OAM Message Ethernet Link Header

   If the link on which a TRILL OAM frame is transmitted between
   neighbor RBridges is Ethernet, the link header follows the usual
   rules for a TRILL Data frame over Ethernet [RFCtrill]. In particular,
   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 TRILL OAM messages or the All-RBridges multicast
   address for multi-destination TRILL OAM messages. The Outer.VLAN tag
   specifies the Designated VLAN for that hop and the priority must 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.

2.5 Special Transmission and Rate Considerations

   If a multi-hop OAM Channel message is received by an RBridge, the
   criteria and method of forwarding it is 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 it may

D. Eastlake, et al                                              [Page 9]

INTERNET-DRAFT                                     RBridges: OAM Channel

   be desirable to use some OAM messages on links that are not yet fully
   up. In particular, it is permissible, if specified by the particular
   OAM protocol, for the source RBridge that has created an OAM Channel
   message to transmit it to a next hop RBridge when the link is in the
   Detect and Two-Way states, as specified in [RFCadj], as well as when
   it is in the Report state.

   OAM messages may represent a burden on the RBridges in a campus and
   should be rate limited, especially if they are multi-destination,
   multi-hop, and/or have the Alert extended flag set.

D. Eastlake, et al                                             [Page 10]

INTERNET-DRAFT                                     RBridges: OAM Channel

3. The TRILL OAM-Channel Extended Flag

   If an OAM Channel ignorant RBridge were to receive an OAM Channel
   frame, it would generally flood the encapsulated frame out all ports
   where it was the appointed forwarder for the frame's VLAN as
   specified by the Inner.VLAN ID. It may be desirable to stop such
   flooding in case, due to transient conditions, an OAM Channel frame
   is misdelivered to an OAM Channel ignorant RBridge. It is also
   desirable for an RBridge to be able to indicate that it supports the
   OAM Channel facility.

   To provide these facilities, a critical ingress-to-egress TRILL
   Header extended flag, OAM-Channel, is specified for the TRILL OAM
   Channel facility [TRILLopt]. This flag is not required to be set in
   the TRILL Header in TRILL OAM message frames. It serves the two
   functions described above, as follows:

   o  An RBridge indicates that it supports the TRILL OAM Channel
      facility by advertising, in the link state database, its support
      for this extended flag.

   o If this extended flag is set in a TRILL OAM message frame, it
      guarantees that, if the inner frame is processed for egress by an
      RBridge that does not implement the TRILL OAM Channel, the
      decapsulated frame will be discarded because egress RBridges are
      required by the base standard to discard frames indicating a
      critical ingress-to-egress extended flag they do not support. If
      it is certain that all RBridges in the campus implement the TRILL
      OAM Channel or if the possible local flooding of the inner frame
      as described above is acceptable, there is no requirement to
      include an options area nor to set this particular extended flag
      in the TRILL Header even if an options area is included.

   As with any other critical ingress-to-egress extended flag, if this
   extended flag is set, then the summary CItE bit MUST be set at the
   top of the options area.

D. Eastlake, et al                                             [Page 11]

INTERNET-DRAFT                                     RBridges: OAM Channel

4. Processing TRILL OAM Chanel Messages

   TRILL OAM messages are designed to look like and, to the extent
   practical, be processed as regular TRILL Data frames. On receiving a
   TRILL OAM frame, 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 TRILL OAM Channel:

      1. An RBridge implementing the TRILL OAM Channel MUST recognize
         the Any-RBridge egress nickname in unicast TRILL Data frames,
         decapsulating and not forwarding such frames if they meet other

      2. If the Alert extended flag is set, then the RBridge needs to
         process the OAM 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 All-OAM-
         RBridges MUST be recognized to trigger processing as a TRILL
         OAM Channel message.

   If the OAM-Channel extended flag is present and set and an egressing
   RBridge does not implement the TRILL OAM Channel feature, the frame
   is discarded. If other extended flags or options are present, they
   may affect processing or cause the frame to be discarded.

4.1 Processing the TRILL OAM Channel Header

   Knowing that it has a TRILL OAM Channel message, the egress RBridge,
   and any transit RBridge if the Alert bit is set in the TRILL Header,
   looks at the OV (OAM Message Header version) and OAM Protocol fields;
   however, if the frame is so short that the Ethertype or the OAM
   Channel Header does not fit or the Ethertype is other than TRILL-OAM,
   the frame is discarded.

   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 4.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 OV field is non-zero.

D. Eastlake, et al                                             [Page 12]

INTERNET-DRAFT                                     RBridges: OAM Channel

      2. The OAM Protocol field is a reserved value or a value unknown
         to the processing RBridge.

      3. The ERR field is non-zero and OAM protocol is a value other
         than 0x001.

   If the OV field is zero and the processing RBridge recognizes the OAM
   Protocol value, it processes the message in accordance with that OAM
   protocol. The processing model is as if the received frame starting
   with and including the TRILL Header is delivered to the OAM 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 OAM Protocol are handled by that OAM
   protocol itself and do not produce OAM Message Channel Error frames.

4.2 OAM Channel Errors

   A variety of problems at the OAM Channel level cause the return of an
   OAM Channel Error frame unless the "SL" (Silent) flag is a one in the
   OAM message for which the problem was detected or the frame in error
   appears, itself, to be an OAM Channel error frame or the error is
   suppressed due to rate limiting.

   An OAM Channel Error frame is a multi-hop unicast TRILL OAM Channel
   message with the ingress nickname set to the nickname of the RBridge
   detecting the error, and the egress nickname set to the value of the
   ingress nickname in the OAM message for which the error was detected.
   The SL and MH flags SHOULD be set to one and the ERR field MUST be
   non-zero as described below. In case more than one error applies, the
   lower numbered ERR value is used. For the protocol specific data
   area, an OAM Channel Message Error frame has at least the first 256
   bytes (or less if less are available) of the erroneous decapsulated
   OAM message starting with the TRILL Header.

   The following values for ERR are specified:

   ERR   Meaning
   ---   -------
    0    - Not an OAM Channel error frame.
    1    Unimplemented value of OV
    2    Reserved or unimplemented value of Protocol
    3    ERR field is non-zero but Protocol field does not equal 0x001
   4-15  - Available for allocation, see Section 6.1.

   All RBridges implementing the TRILL OAM Message Channel feature MUST
   recognize the OAM Message Channel Error protocol value (0x001). They
   MUST NOT generate an OAM Message Channel Error message in response to

D. Eastlake, et al                                             [Page 13]

INTERNET-DRAFT                                     RBridges: OAM Channel

   a TRILL OAM Channel Error message, that is an OAM message with a
   protocol value of 0x001.

D. Eastlake, et al                                             [Page 14]

INTERNET-DRAFT                                     RBridges: OAM Channel

5. Native TRILL-OAM Frames

   If provided for by the OAM protocol involved, native TRILL OAM
   messages may be sent between end-stations and RBridges in either
   direction. Such native frames have the TRILL-OAM Ethertype and look
   like the encapsulated frame within a TRILL OAM Channel message with
   the following exceptions:

      1. TRILL does not require the presence of VLAN tagging on such
         native TRILL OAM frames. However, port configuration, link
         characteristics, or the OAM protocol involved may require such

      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 some OAM protocol that uses
         this transport, the destination MAC address is All-OAM-
         RBridges. If the frame is multicast to all the devices that
         TRILL considers to be end stations on a link that support some
         OAM protocol that uses this transport, the destination MAC
         address is TRILL-End-Stations (see Section 6.1).

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

   A native frame with the TRILL-OAM Ethertype must meet the usual VLAN
   and destination MAC address restrictions to be accepted by an
   RBridge. If provided for by the OAM protocol involved, the receipt of
   such a native frame MAY lead to the generation and forwarding of one
   or more TRILL OAM Channel frames.  The decapsulation and processing
   of a TRILL OAM Channel frame MAY, if provided for by the OAM protocol
   involved, result in the sending of one or more native TRILL OAM
   frames to one or more end stations.

D. Eastlake, et al                                             [Page 15]

INTERNET-DRAFT                                     RBridges: OAM Channel

6. Allocations Considerations

   The following subsections give IANA and IEEE Registration Authority

6.1 IANA Considerations

   In this document, the allocation procedures "Standards Action", "IETF
   Review", "RFC Publication", and "Private Use" are as specified in

   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:

         All-OAM-RBridges      TBD (01-80-C2-00-00-43 suggested)
         TRILL-End-Stations    TBD (01-80-C2-00-00-44 suggested)

   IANA is requested to allocate a previously unassigned TRILL critical
   ingress-to-egress extended flag bit as follows:

         TBD                   OAM-Flag

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

         TBD                   Alert

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

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

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

   (1) TRILL OAM protocol code points from 0x002 to 0x0FF require a
   Standards Action for allocation.

D. Eastlake, et al                                             [Page 16]

INTERNET-DRAFT                                     RBridges: OAM Channel

   (2) TRILL OAM 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 TRILL OAM Header Flags with initial contents
   as follows:

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

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

   Allocation of a TRILL OAM Header Flag is based on Standards Action

   IANA is requested to create an additional sub-registry in the TRILL
   Parameter Registry for TRILL OAM Channel error codes with initial
   contents as listed in Section 4.2 above and with available values
   allocated by Standards Action.

6.2 IEEE Registration Authority Considerations

   The Ethertype TBD has been is assigned by the IEEE Registration
   Authority for TRILL-OAM.

D. Eastlake, et al                                             [Page 17]

INTERNET-DRAFT                                     RBridges: OAM Channel

7. Security Considerations

   See [RFCtrill] for general RBridge Security Considerations.

   -- More TBD --

D. Eastlake, et al                                             [Page 18]

INTERNET-DRAFT                                     RBridges: OAM Channel

8. References

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

8.1 Normative References

   [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

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

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

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

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

8.2 Informative References

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

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

D. Eastlake, et al                                             [Page 19]

INTERNET-DRAFT                                     RBridges: OAM 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

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

   Phone: +1-408-745-2000

   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


D. Eastlake, et al                                             [Page 20]

INTERNET-DRAFT                                     RBridges: OAM 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 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 21]