Skip to main content

TRILL (Transparent Interconnection of Lots of Links): The ESADI (End Station Address Distribution Information) Protocol
draft-ietf-trill-esadi-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7357.
Authors Hongjun Zhai , fangwei hu , Radia Perlman , Donald E. Eastlake 3rd
Last updated 2012-10-02
Replaces draft-hu-trill-rbridge-esadi
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7357 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-trill-esadi-01
TRILL Working Group                                         Hongjun Zhai
INTERNET-DRAFT                                                Fangwei Hu
Intended status: Proposed Standard                                   ZTE
Updates: 6325                                              Radia Perlman
                                                              Intel Labs
                                                         Donald Eastlake
                                                                  Huawei
Expires: March 31, 2013                                  October 1, 2012

         TRILL (Transparent Interconnection of Lots of Links):
   The ESADI (End Station Address Distribution Information) Protocol
                    <draft-ietf-trill-esadi-01.txt>

Abstract

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol provides least cost pair-wise data forwarding without
   configuration in multi-hop networks with arbitrary topologies and
   link technologies. TRILL supports multi-pathing of both unicast and
   multicast traffic. Devices that implement the TRILL protocol are
   called RBridges (Routing Bridges) or TRILL Switches.

   The ESADI (End Station Address Distribution Information) protocol is
   a VLAN (Virtual Local Area Network) scoped way a TRILL switch can
   communicate VLAN-x end station addresses to other TRILL switches
   announcing ESADI participation for VLAN-x (normally a VLAN-x
   Appointed Forwarder) and running the ESADI protocol.  This document
   updates RFC 6325, specifically the documentation of the ESADI
   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: <rbridge@postel.org>.

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

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

H. Zhai, et al                                                  [Page 1]
INTERNET-DRAFT                                              TRILL: ESADI

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

H. Zhai, et al                                                  [Page 2]
INTERNET-DRAFT                                              TRILL: ESADI

Table of Contents

      1. Introduction............................................4
      1.1 Content and Precedence.................................5
      1.2 Terminology............................................5

      2. ESADI Protocol Overview.................................6
      3. ESADI DRB Determination................................10

      4. ESADI PDU processing...................................11
      4.1 Sending of ESADI PDUs.................................12
      4.2 Receipt of ESADI PDUs.................................13

      5. End Station Addresses..................................14
      5.1 Learning Confidence Level.............................14
      5.2 Forgetting End Station Addresses......................14

      6. ESADI-LSP Contents.....................................15
      6.1 ESADI Parameter Data..................................15
      6.2 MAC Reachability TLV..................................16
      6.3 Default Authentication................................16

      7. IANA Considerations....................................18
      7.1 ESADI Participation and Capability Flags..............18
      7.2 TRILL GENAPP TLV......................................18

      8. Security Considerations................................20

      Acknowledgements..........................................21
      9. References.............................................22
      9.1 Normative references..................................22
      9.2 Informative References................................23
      Change History............................................24
      From -00 to -01...........................................24

H. Zhai, et al                                                  [Page 3]
INTERNET-DRAFT                                              TRILL: ESADI

1. Introduction

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol [RFC6325] provides least cost pair-wise data forwarding
   without configuration in multi-hop networks with arbitrary topologies
   and link technologies, safe forwarding even during periods of
   temporary loops, and support for multi-pathing of both unicast and
   multicast traffic.  TRILL accomplishes this by using the IS-IS
   (Intermediate System to Intermediate System) [IS-IS] [RFC1195]
   [rfc6326bis] link state routing protocol and encapsulating traffic
   using a header that includes a hop count.  The design supports VLANs
   (Virtual Local Area Networks) and optimization of the distribution of
   multi-destination frames based on VLANs and IP multicast groups.
   Devices that implement TRILL are called RBridges (Routing Bridges) or
   TRILL switches.

   There are five ways an RBridge can learn end station addresses as
   described in Section 4.8 of [RFC6325].  The ESADI (End Station
   Address Distribution Information) protocol is an optional VLAN scoped
   way RBridges can communicate, with each other, end station addresses
   and their RBridge of attachment. An RBridge that is announcing
   interest in VLAN-x (normally a VLAN-x Appointed Forwarder [RFC6439])
   MAY use the ESADI protocol to announce the end station address of
   some or all of its attached VLAN-x end nodes to other RBridges that
   are running ESADI for VLAN-x.

   By default, RBridges with connected end stations learn addresses from
   the data plane when ingressing and egressing native frames. The ESADI
   protocol's potential advantages over data plane learning include the
   following:

   1. Security advantages: (1a) The ESADI protocol can be used to
      announce end stations with an authenticated enrollment (for
      example enrollment authenticated by cryptographically based EAP
      (Extensible Authentication Protocol [RFC3748]) methods via
      [802.1X]). (1b) The ESADI protocol supports cryptographic
      authentication of its message payloads for more secure
      transmission.

   2. Fast update advantages: The ESADI protocol provides a fast update
      of end stations MAC (Media Access Control) addresses.  If an end
      station is unplugged from one RBridge and plugged into another,
      frames addressed to that older RBridge can be black holed.  They
      can be sent just to the older RBridge that the end station was
      connected to until cached address information at some remote
      RBridge times out, possibly for tens of seconds or more [RFC6325].

   MAC address reachability information, some ESADI parameters, and
   optionally authentication information are carried in ESADI frames
   rather than in the TRILL IS-IS protocol.  As described below, ESADI

H. Zhai, et al                                                  [Page 4]
INTERNET-DRAFT                                              TRILL: ESADI

   is, for each VLAN, a virtual logical topology overlay in the TRILL
   topology. An advantage of using ESADI over using TRILL IS-IS is that
   the end station attachment information is not flooded to all RBridges
   through TRILL IS-IS but only to RBridges advertising ESADI
   participation for the VLAN in which those end stations occur.

1.1 Content and Precedence

   This document updates [RFC6325], the TRILL basic specification,
   essentially replacing the description of the ESADI protocol, and
   prevails over [RFC6325] where they conflict.

   Section 2 is the ESADI protocol overview. Section 3 specifies ESADI
   DRB state.  Section 4 discusses the processing of ESADI PDUs. Section
   5 discusses interaction with other modes of end station address
   learning. And Section 6 describes the ESADI-LSP contents.

1.2 Terminology

   This document uses the acronyms defined in [RFC6325] and the
   following phrase:

      LSP number zero - A Link State PDU with fragment number equal to
                        zero.

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

H. Zhai, et al                                                  [Page 5]
INTERNET-DRAFT                                              TRILL: ESADI

2. ESADI Protocol Overview

   ESADI is a VLAN scoped way that RBridges can announce and learn end
   station addresses rapidly and securely.  An RBridge that is
   announcing participation in ESADI for one or more VLANs is called an
   ESADI RBridge. (Usually this participation is because that RBridge is
   an Appointed Forwarder for those VLANs [RFC6439].)

   ESADI is a separate protocol from the TRILL IS-IS implemented by all
   RBridges in a campus.  There is a separate ESADI instance for each
   VLAN. In essence, for each VLAN, there is a modified instance of the
   IS-IS reliable flooding mechanism in which ESADI RBridges may choose
   to participate. (These are not the instances being specified in
   [MultiInstance].) It is an implementation decision how independent
   the multiple ESADI instances at an RBridge are. For example, the
   ESADI link state could be in a single database with a field in each
   record indicating the VLAN to which it applies or could be a separate
   database per VLAN. But the ESADI update process operates separately
   for each ESADI instance and independently from the TRILL IS-IS update
   process.

   After the TRILL header, ESADI frames have an inner Ethernet header
   with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All-
   ESADI-RBridges"), an Inner.VLAN tag specifying the VLAN of interest,
   and the "L2-IS-IS" Ethertype followed by the ESADI payload as shown
   in Figure 1.

   TRILL ESADI frame Structure

                      +--------------------------------+
                      |          Link Header           |
                      +--------------------------------+
                      |       TRILL Data Header        |
                      +--------------------------------+
                      |     Inner Ethernet Header      |
                      +--------------------------------+
                      |         ESADI Payload          |
                      +--------------------------------+
                      |          Link Trailer          |
                      +--------------------------------+

                                 Figure 1.

   TRILL ESADI frames sent on an Ethernet link are structured as shown
   below.  The outer VLAN tag will not be present if it was stripped by
   an Ethernet port out of which the frame was sent.

H. Zhai, et al                                                  [Page 6]
INTERNET-DRAFT                                              TRILL: ESADI

   Outer Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Next Hop Destination Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Hop Destination Addr.    | Sending RBridge Port MAC Addr.|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Sending RBridge Port MAC Address              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = C-Tag      0x8100 | Outer.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = TRILL      0x22F3 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   TRILL Header:                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      | V | R |M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Egress Nickname               | Ingress (Origin) Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Inner Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      All-Egress-RBridges                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | All-Egress-RBridges cont.     | Origin RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Origin RBridge MAC Address continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = C-Tag      0x8100 | Inner.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = L2-IS-IS   0x22F4 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ESADI Payload (formatted as IS-IS):
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Frame Check Sequence:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  FCS (Frame Check Sequence)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: ESADI Ethernet Link Frame Format

   The Next Hop Destination Address or Outer.MacDA is the All-RBridges
   multicast address if the ESADI PDU is multicast PDU, while if it is
   unicast PDU, the Next Hop Destination Address is the unicast address
   of the next hope RBridge.  The VLAN specified in the Outer.VLAN
   information will always be the Designated VLAN for the link on which
   the frame is sent. The V and R fields will be zero while the M field
   will be one unless the RBridge supports unicasting ESADI PDUs, in
   which case the M field MAY be zero. The VLAN specified in the
   Inner.VLAN information will be the VLAN to which the ESADI frame
   applies. The Origin RBridge MAC Address or Inner.MacSA MUST be a

H. Zhai, et al                                                  [Page 7]
INTERNET-DRAFT                                              TRILL: ESADI

   globally unique MAC address owned by the RBridge originating the
   ESADI frame, for example, any of its port MAC addresses, and each
   RBridge MUST use the same Inner.MacSA for all of the ESADI frames
   that RBridge originates.

   TRILL ESADI frames sent on a PPP link are structured as shown below.

   PPP Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PPP = TNP (TRILL data) 0x005D |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   TRILL Header:                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      | V | R |M|Op-Length| Hop Count |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Egress Nickname               | Ingress (Origin) Nickname     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Inner Ethernet Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      All-Egress-RBridges                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | All-Egress-RBridges cont.     | Origin RBridge MAC Address    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Origin RBridge MAC Address continued           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = C-Tag      0x8100 | Inner.VLAN Tag Information    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Ethertype = L2-IS-IS   0x22F4 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ESADI Payload (formatted as IS-IS):
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   PPP Check Sequence:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       PPP Check Sequence                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: ESADI PPP Link Frame Format

   All transit RBridges forward ESADI frames as if they were ordinary
   TRILL Data frames.  Because of this forwarding, it appears to an
   instance of the ESADI protocol at an RBridge that it is directly
   connected by a multi-access virtual link to all other RBridges in the
   campus running ESADI for that VLAN. No "routing" computation or
   routing decisions ever have to be performed by ESADI. An ESADI
   RBridge merely transmits the ESADI frames it originates on this
   virtual link as described for TRILL Data frames in [RFC6325]. For
   multicast ESADI frames, which is the normal case, it may use any
   distribution tree that it might use for a normal multi-destination
   TRILL Data frame. RBridges that do not implement the ESADI protocol,

H. Zhai, et al                                                  [Page 8]
INTERNET-DRAFT                                              TRILL: ESADI

   do not have it enabled, or are not participating for the Inner.VLAN
   of an ESADI frame do not decapsulate or locally process any multicast
   TRILL ESADI frames they receive.  Thus the ESADI frames are
   transparently tunneled through transit RBridges.

   TRILL ESADI frame payloads are structured like IS-IS PDUs, except as
   indicated below, but are always TRILL encapsulated on the wire as if
   they were TRILL Data frames.  The ESADI instance for VLAN-x at an
   RBridge RB1 determines who its ESADI potential neighbors are by
   logically examining the TRILL IS-IS link state database for RBridges
   that are data and IS-IS reachable from RB1 (see Section 2 of
   [ClearCorrect]) and are announcing their participation in VLAN-x
   ESADI. When an RBridge RB2 becomes IS-IS or data unreachable from RB1
   or any of the relevant entries for RB2 are purged from the core IS-IS
   link state database, it is lost as a potential neighbor and also
   dropped from any ESADI instances. And when RB2 is no longer
   announcing participation in VLAN-x ESADI, it ceases to be a potential
   neighbor for the VLAN-x ESADI instance. RB2 becomes an actual ESADI
   adjacency for RB1 when it is a potential neighbor and RB1 holds an
   ESADI-LSP zero for RB2, all these considerations being VLAN scoped.
   Because of these mechanisms, there are no "Hellos" sent in ESADI.

   The information distributed by the ESADI protocol includes a list of
   local end station MAC addresses connected to the originating RBridge
   and, for each such address, a one octet unsigned "confidence" rating
   in the range 0-254 (see Section 6.1). It is entirely up to the
   originating RBridge which locally connected MAC addresses it wishes
   to advertise via ESADI and with what confidence. It MAY advertise
   all, some, or none of such addresses. In addition, some ESADI
   parameters of the advertising RBridge (see Section 6.2) and possibly
   authenticaiton information (see Section 6.3) are included. Future
   uses of ESADI may distribute other types of information.

   TRILL ESADI-LSPs MUST NOT contain a VLAN ID in their payload. The
   VLAN ID to which the ESADI data applies is the Inner.VLAN of the
   TRILL Data frame enclosing the ESADI payload. If a VLAN ID could
   occur within the payload, it might conflict with the Inner.VLAN and
   could conflict with any future VLAN mapping scheme that may be
   adopted [VLANmapping]. If a VLAN ID field within an ESADI-LSP PDU
   does include a VLAN ID, its contents is ignored.

H. Zhai, et al                                                  [Page 9]
INTERNET-DRAFT                                              TRILL: ESADI

3. ESADI DRB Determination

   Generally speaking, the DRB state on the ESADI link operates
   similarly to a TRILL IS-IS broadcast link [RFC6327] with the
   following exceptions: In the VLAN-x ESADI-DRB election at RB1 on an
   ESADI virtual link, the candidates are the local ESADI instance for
   VLAN-x and all remote ESADI instances at RBridges that (1) are data
   and IS-IS reachable from RB1 [ClearCorrect], (2) are announcing in
   their TRILL IS-IS LSP that they are participating in ESADI for VLAN-
   x, and (3) for which RB1 is holding an ESADI-LSP zero. The winner is
   the instance with the highest ESADI Parameter 7-bit priority field
   with ties broken by System ID, comparing fields as unsigned integers
   with the larger magnitude considered higher priority. In particular
   "SNPA/MAC address" is not considered and there is no "Port ID".

   Because ESADI does no adjacency announcement or routing, the ESADI-
   DRB does not create a pseudonode.

H. Zhai, et al                                                 [Page 10]
INTERNET-DRAFT                                              TRILL: ESADI

4. ESADI PDU processing

   VLAN-x ESADI neighbors are usually not connected directly by a
   physical link, but are always logically connected by a virtual link.
   There could be hundreds or thousands of ESADI RBridges on the virtual
   link.  There are only ESADI-LSP, ESADI-CSNP and ESADI-PSNP PDUs used
   in ESADI. In particular, there are no Hello or MTU PDUs because ESADI
   does not build a topology and does not do any routing.

   In IS-IS, PDU multicasting is normal on a local link and no effort is
   made to optimize to unicast because under the original conditions
   when IS-IS was designed (commonly a piece of multi-access Ethernet
   cable) any frame made the link busy for that frame time. But in ESADI
   what appears to be a simple multi-access link is generally a set of
   multi-hop distribution trees that may or may not be pruned. Thus,
   transmitting a multicast frame on such a tree can impose a
   substantially greater load than transmitting a unicast frame. This
   load may be justified if there are likely to be multiple listeners
   but may not be justified if there is only one recipient of interest.
   For this reason, under some circumstances, ESADI PDUs MAY be TRILL
   unicast if it is confirmed that the destination RBridge supports
   receiving unicast ESADI PDUs.

   To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is
   replaced with the following:

   "4.6.2.2. TRILL ESADI Frames

      If M=1, the egress nickname designates the distribution tree.  The
      frame is forwarded as described in Section 4.6.2.5.  In addition,
      if the forwarding RBridge is (1) interested in the specified VLAN,
      for example it is Appointed Forwarder for that VLAN on at least
      one port, (2) implements the TRILL ESADI protocol, and (3) ESADI
      is enabled for that VLAN, the inner frame is decapsulated and
      provided to that local ESADI protocol.

      If M=0 and the egress nickname is not that of the receiving
      RBridge, the frame is forwarded as for known unicast TRILL Data in
      Section 4.6.2.4. If M=0 and the egress nickname is that of the
      receiving RBridge and the receiving RBridge supports unicast ESADI
      PDUs, then the ESADI frame is decapsulated and processed if it
      meets the three numbered conditions in the paragraph above,
      otherwise it is discarded."

   The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above
   references to those sections in [RFC6325].

   Section 4.1 describes the sending of ESADI PDUs. Section 4.2 covers
   the receipt of ESADI PDUs.

H. Zhai, et al                                                 [Page 11]
INTERNET-DRAFT                                              TRILL: ESADI

4.1 Sending of ESADI PDUs

   The MTU available to instances of ESADI is at least 24 bytes less
   than that available to TRILL IS-IS because of the additional fields
   required (2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) +
   6(Inner.MacSA) + 4(Inner.VLAN)). Thus the inner ESADI payload,
   starting with the Intradomain Routeing Protocol Discriminator byte,
   MUST NOT exceed Sz minus 24; however, if a larger payload is
   received, it is processed normally. (See [RFC6325] and [ClearCorrect]
   for discussions of Sz and MTU.)

   Once an ESADI instance is operationally up for VLAN-x, it multicasts
   its self-originated ESADI-LSP number zero on the virtual link to
   announce its ESADI parameters. When the other ESADI instances receive
   the ESADI-LSP number zero and find a new neighbor, their self-
   originated LSP fragments are scheduled to be sent and MAY be unicast
   to that neighbor if the neighbor is announcing in its LSP that it
   supports unicast ESADI (see Section 7.1). If all the other ESADI
   instances send their self-originated ESADI-LSPs immediately, there
   may be a surge of traffic to that new neighbor. So the other ESADI
   instances should wait an interval time before sending the ESADI-LSP
   to a new neighbor. The interval time value is up to the device
   implementation. One suggestion is that the interval time can be
   assigned a random value with a range based on the ESADI priority when
   implementation.

   If the ESADI instance believes it is DRB, it multicasts an ESADI-CSNP
   periodically (thrice per CSNP Time, see Section 6.1) to keep the Link
   State Database synchronized among its neighbors on the virtual link.
   After receiving an ESADI-PSNP PDU, the DRB will multicast the ESADI-
   LSPs requested by the ESADI-PSNP on the virtual link.

   The multi-hop TRILL multi-destination frame distribution with Reverse
   Path Forwarding Check will typically be less reliable than the single
   hop link-local LSP synchronization of TRILL IS-IS. Therefore, for LSP
   synchronization robustness, in addition to sending ESADI-CSNPs when
   it is DRB, an ESADI RBridge SHOULD also transmit an ESADI-CSNP for an
   ESADI instance if all of the following conditions are met:

   o  it sees one or more ESADI neighbors for that instance, and
   o  it does not believe it is DRB for the ESADI instance, and
   o  it has not received or sent an ESADI-CSNP PDUs for the instance
      for the CSNP Time (see Section 6.1) of the DRB.

   In the case of receiving an ESADI-LSP with a smaller sequence number
   than the copy stored in the local EASDI Link State Database, the
   local ESADI instance will also schedule to transmit the stored copy
   and MAY unicast it to the sender of the received ESADI-LSP if it is
   confirmed that the sender supports receiving unicast ESADI PDUs (see
   Section 7.1).

H. Zhai, et al                                                 [Page 12]
INTERNET-DRAFT                                              TRILL: ESADI

   The format of a unicast ESADI frame is the format of TRILL ESADI
   frame, in Section 4.2 in [RFC6325], except as follows:

   o  On an Ethernet link, in the Outer Ethernet Header the Outer.MacDA
      is the unicast address of the next hop RBridge.

   o  In the TRILL header, the M bit is set to zero and the Egress
      Nickname is the nickname of the destination RBridge.

4.2 Receipt of ESADI PDUs

   Because ESADI adjacency is in terms of System ID, all PDU acceptance
   tests that check that the PDU is from an adjacent system check that
   the System ID is that of an ESADI neighbor and do not check ether the
   source Inner or Outer SNPA/MAC.

   Because all data reachable ESADI RBridges participating for VLAN-x
   are adjacent, when RB1 receives an ESADI-CSNP from RB2 and detects
   that it has ESADI-LSPs that RB2 is missing, it sets the transmission
   flag only for its own ESADI-LSPs that RB2 is missing. Missing ESADI-
   LSPs originated by other ESADI RBridges will be detected by those
   other ESADI RBridges.

   When receiving an ESADI-PSNP PDU, if the local ESADI instance is DRB,
   ESADI-LSP PDU requested by the ESADI-PSNP will be multicast on the
   virtual link.

H. Zhai, et al                                                 [Page 13]
INTERNET-DRAFT                                              TRILL: ESADI

5. End Station Addresses

5.1 Learning Confidence Level

   The confidence level mechanism allows an RBridge campus manager to
   cause certain address learning sources to prevail over others. MAC
   address information learned through a registration protocol, such as
   [802.1X] with a cryptographically based EAP [RFC3748] method, might
   be considered more reliable than information learned through the mere
   observation of data frames.  When such authenticated learned address
   information is transmitted via the ESADI protocol, the use of
   authentication in the TRILL ESADI-LSP frames could make tampering
   with it in transit very difficult.  As a result, it might be
   reasonable to announce such authenticated information via the ESADI
   protocol with a high confidence, so it would be used in preference to
   any alternative learning from data observation.

5.2 Forgetting End Station Addresses

   The end station addresses learned through TRILL ESADI protocol should
   be forgotten through changes in ESADI-LSP. The time out of the
   learned end station address is up to the originating RBridge that
   decides when to remove such information from its ESADI-LSPs (or up to
   ESADI protocol timeouts if the originating RBridge becomes
   inaccessible).

   If RBridge RBn participating in the TRILL ESADI protocol for VLAN-x
   no longer wishes to participate in ESADI or is no longer appointed
   forwarder for VLAN-x on any port where it is providing end station
   service, it ceases to participate in ESADI after sending a final
   ESADI-LSP nulling out its ESADI-LSP information.

H. Zhai, et al                                                 [Page 14]
INTERNET-DRAFT                                              TRILL: ESADI

6. ESADI-LSP Contents

   The only PDUs used in ESADI are the Level 1 ESADI-LSP, ESADI-CSNP,
   and ESADI-PSNP PDUs. The content of an ESADI-LSP consists of zero or
   more MAC Reachability TLVs, optionally an Authentication TLV, and
   exactly one ESADI parameter APPsub-TLV. This section specifies the
   format for ESADI parameter data APPsub-TLV, which MUST occur in
   ESADI-LSP zero, gives the reference for the ESADI MAC Reachability
   TLV, and discusses default authentication configuration.

   In the future, there may be other TLVs or sub-TLVs carried in ESADI-
   LSPs.

   For robustness, the payload for an ESADI-LSP number zero MUST NOT
   exceed 1470 minus 24 bytes in length (1446 bytes) but if received
   longer, it is still processed normally.

6.1 ESADI Parameter Data

   The figure below presents the format of the ESADI parameter data.
   This APPsub-TLV MUST be included in a TRILL GENAPP TLV in ESADI-LSP
   number zero. If it is missing from ESADI-LSP number zero, priority
   for the sending RBridge defaults to zero and CSNP Time defaults to
   30. If there is more than one occurrence in ESADI-LSP zero, the first
   occurrence will be used. Occurrences of the ESADI parameter data
   APPsub-TLV in non-zero ESADI-LSP fragments are ignored.

              +-+-+-+-+-+-+-+-+
              | Type          |              (1 byte)
              +-+-+-+-+-+-+-+-+
              | Length        |              (1 byte)
              +-+-+-+-+-+-+-+-+
              |R| Priority    |              (1 byte)
              +-+-+-+-+-+-+-+-+
              | CSNP Time     |              (1 byte
              +-+-+-+-+-+-+-+-+
              | Reserved for expansion       (variable)
              +-+-+-+-...

                   Figure 4. ESADI Parameter APPsub-TLV

   Type: set to ESADI-PARAM subTLV (TRILL APPsub-TLV type 1).

   Length: Set to 2 to 255.

   R: A reserved bit that MUST be sent as zero and ignored on receipt.

H. Zhai, et al                                                 [Page 15]
INTERNET-DRAFT                                              TRILL: ESADI

   Priority: The Priority field gives the originating RBridge's priority
      for being DRB on the ESADI instance virtual link for the VLAN in
      which the PDU containing the parameter data was sent. It is an
      unsigned seven-bit integer with larger magnitude indication higher
      priority.  It defaults to 0x40 for an RBridge participating in
      ESADI for which it has not been configured.

   CSNP Time: An unsigned byte that gives the amount of time in seconds
      during which the originating RBridge, if it is DRB on the ESADI
      link, will send at least three EASDI-CSNP PDUs. It defaults to 30
      seconds for an RBridge participating in ESADI for which it has not
      been configured.

   Reserved for future expansion: Future versions of the ESADI
      Parameters APPsub-TLV may have additional information. A receiving
      ESADI RBridge ignores any additional data here unless it
      implements such future expansion(s).

6.2 MAC Reachability TLV

   The primary information in TRILL ESADI-LSP PDUs consists of MAC
   Reachability (MAC-RI) TLVs as specified in [RFC6165].  These TLVs
   contain one or more unicast MAC addresses of end stations that are
   both on a port and in a VLAN for which the originating RBridge is
   appointed forwarder, along with the one octet unsigned Confidence in
   this information with a value in the range 0-254. If such a TLV is
   received with a confidence of 255, it is treated as if the confidence
   was 254.

   To avoid conflict with the Inner.VLAN ID, the TLVs in TRILL ESADI
   PDUs, including the MAC-RI TLV, MUST NOT contain the VLAN ID. If a
   VLAN-ID is present in the MAC-RI TLV, it is ignored. In the
   encapsulated TRILL ESADI frame, only the Inner.VLAN tag indicates the
   VLAN to which the ESADI-LSP applies.

6.3 Default Authentication

   The Authentication TLV may be included in ESADI PDUs. The default for
   ESADI PDU Authentication is based on the state of TRILL IS-IS shared
   secret authentication for LSP PDUs. If TRILL IS-IS authentication and
   ESADI are implemented at a TRILL switch, then ESADI MUST be able to
   use the authentication algorithms implemented for TRILL IS-IS and
   implement the keying material derivation function given below. If
   ESADI authentication has been configured, that configuration is not

H. Zhai, et al                                                 [Page 16]
INTERNET-DRAFT                                              TRILL: ESADI

   restricted by the configuration of TRILL IS-IS security.

   If TRILL IS-IS authentication is not in effect for LSP PDUs
   originated by a TRILL switch then, by default, ESADI PDUs originated
   by that TRILL switch are also unsecured.

   If such IS-IS LSP PDU authentication is in effect at a TRILL switch
   then, unless configured otherwise, ESADI PDUs sent by that switch
   MUST use the same algorithm in their Authentication TLVs.  The ESADI
   authentication keying material used is derived from the IS-IS LSP
   shared secret keying material as detailed below. However, such
   authentication MAY be configured to use some other keying material.

        HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key )

   In the above HMAC-SHA256 is as described in [FIPS180] [RFC6234] and
   "TRILL ESADI" is the eleven byte US ASCII [ASCII] string indicated.
   IS-IS-LSP-shared-key is secret keying material being used by the
   originating TRILL switch for IS-IS LSP authentication.

H. Zhai, et al                                                 [Page 17]
INTERNET-DRAFT                                              TRILL: ESADI

7. IANA Considerations

   IANA allocation considerations are given below.

7.1 ESADI Participation and Capability Flags

   IANA is requested to allocate an "ESADI Participation" and the
   "capability of receiving unicast ESADI PDU" bit in the Interested
   VLANs and Spanning Tree Roots sub-TLV [rfc6326bis]. (bit 2 and 3
   respectively in the Interested VLANs field recommended) If TBD [bit
   2] is a one, it indicates that the originating RBridge is
   participating in ESADI for the indicated VLAN or VLANs. If TBD [bit
   3] is a one, it indicates that the originating RBridge has the
   capability of receiving and processing unicast ESADI PDUs.

7.2 TRILL GENAPP TLV

   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                Reference
            ------ --------            -----------
                0  Reserved            <this RFC>
                1  ESADI-PARAM         <this RFC>
            2-254  Available           <this RFC>
              255  Reserved            <this RFC>

   TRILL APPsub-TLV Types 2 through 254 are available for allocation by
   IETF Review. The RFC causing such an allocation will also include a
   discussion of security issues and of the rate of change of the
   information being advertised. TRILL APPsub-TLVs MUST NOT alter basic
   IS-IS protocol operation including the establishment of IS-IS
   adjacencies, the IS-IS update process, and the decision process for
   TRILL IS-IS [IS-IS] [RFC1195] [RFC6327]. The TRILL Generic
   Information TLV MUST NOT be used in an IS-IS instance zero
   [MultiInstance].

   The V, I, D, and S flags in the initial flags byte of a TRILL Generic
   Information TLV have the meanings specified in [RFCgenapp] but are
   not currently used as TRILL operates as a Level 1 IS-IS area and no
   semantics is hereby assigned to the inclusion of an IPv4 and/or IPv6

H. Zhai, et al                                                 [Page 18]
INTERNET-DRAFT                                              TRILL: ESADI

   address via the I and V flags. Thus these flags MUST be zero;
   however, use of multi-level IS-IS is an obvious extension for TRILL
   [MultiLevel] and future IETF Standards Actions may update or obsolete
   this specification to provide for the use of any or all of these
   flags in the TRILL GENAPP TLV.

   The ESADI Parameters information, for which APPsub-TLV 1 is hereby
   assigned, is compact and slow changing (see Section 6.1).

   For Security Considerations related to ESADI and the ESADI parameters
   APPsub-TLV, see Section 8.

H. Zhai, et al                                                 [Page 19]
INTERNET-DRAFT                                              TRILL: ESADI

8. Security Considerations

   For general TRILL Security Considerations, see [RFC6325].

   More TBD

H. Zhai, et al                                                 [Page 20]
INTERNET-DRAFT                                              TRILL: ESADI

Acknowledgements

   The authors thank the following, listed in alphabetic order, for
   their suggestions and contributions:

      Somnath Chatterjee and Thomas Narten

   This document was produced with raw nroff. All macros used were
   defined in the source file.

H. Zhai, et al                                                 [Page 21]
INTERNET-DRAFT                                              TRILL: ESADI

9. References

   Normative and informative references for this document are below.

9.1 Normative references

   [ASCII] - American National Standards Institute (formerly United
         States of America Standards Institute), "USA Code for
         Information Interchange", ANSI X3.4-1968, 1968.  ANSI X3.4-1968
         has been replaced by newer versions with slight modifications,
         but the 1968 version remains definitive for the Internet.

   [FIPS180] - "Secure Hash Standard (SHS)", United States of American,
         National Institute of Science and Technology, Federal
         Information Processing Standard (FIPS) 180-4, March 2012,
         http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf

   [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)", ISO/IEC 10589:2002, Second Edition, Nov
         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.

   [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for
         Layer-2 Systems", RFC 6165, April 2011.

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

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

   [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
         Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC
         6439, November 2011.

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

H. Zhai, et al                                                 [Page 22]
INTERNET-DRAFT                                              TRILL: ESADI

         in RFC Editor's queue.

   [ClearCorrect] - Eastlake, D., Zhang, M., Ghanwani, A., Manral, V.,
         A. Benerjee, "TRILL: Clarifications, Corrections, and Updates",
         draft-ietf-trill-clear-correct, in RFC Editor's queue.

   [rfc6326bis] - Eastlake, D., Senevirathne, T., Ghanwani, A., Dutt,
         D., and A. Banerjee, "Transparent Interconnection of Lots of
         Links (TRILL) Use of IS-IS", draft-eastlake-isis-rfc6326bis,
         work in progress.

9.2 Informative References

   [802.1X] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
         networks / Port-Based Network Access Control", IEEE Std
         802.1X-2010, 5 February 2010.

   [MultiInstance] - Previdi, S., L. Ginsberg, M. Shand, A. Roy, D.
         Ward, "IS-IS Multi-Instance", draft-ietf-isis-mi, work in
         progress.

   [MultiLevel] - Perlman, R., D. Eastlake, A. Ghanwani, H. Zhai,
         "Multilevel TRILL (Transparent Interconnection of Lots of
         Links)", draft-perlman-trill-rbridge-multilevel, work in
         progress.

   [RFC3748] - Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
         Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC
         3748, June 2004.

   [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash
         Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May
         2011.

   [VLANmapping] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani,
         and D. Eastlake, "RBridges: Campus VLAN and Priority Regions",
         draft-ietf-trill-rbridge-vlan-mapping, work in progress.

H. Zhai, et al                                                 [Page 23]
INTERNET-DRAFT                                              TRILL: ESADI

Change History

   RFC Editor: Please delete this section before publication.

From -00 to -01

   1. Add Section 6.3 "Default Authentication".

   2. Add "Acknowledgements" Section.

   3. Change requirement from "MAY" to "SHOULD" for an ESADI RBridge
      that is not DRB to send an ESADI-CSNP if it does not receive an
      ESADI-CSNP in long enough.

   4. Default CSNP Time was listed as 30 in one place and 40 in another.
      Change to uniformly specify 30.

   5. Update references to RFC 6326 to reference the 6326bis draft.

   6. Relax allocation criteria for TRILL APPsub-TLV type code points
      from Standard Action to IETF Review.

   7. Numerous Editorial changes.

H. Zhai, et al                                                 [Page 24]
INTERNET-DRAFT                                              TRILL: ESADI

Authors' Addresses

   Hongjun Zhai
   ZTE Corporation
   68 Zijinghua Road
   Nanjing 200012 China

   Phone: +86-25-52877345
   Email: zhai.hongjun@zte.com.cn

   Fangwei Hu
   ZTE Corporation
   889 Bibo Road
   Shanghai 201203 China

   Phone: +86-21-68896273
   Email: hu.fangwei@zte.com.cn

   Radia Perlman
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA 95054-1549 USA

   Phone: +1-408-765-8080
   Email: Radia@alum.mit.edu

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

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com

H. Zhai, et al                                                 [Page 25]
INTERNET-DRAFT                                              TRILL: ESADI

Copyright and IPR Provisions

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.

H. Zhai, et al                                                 [Page 26]