TRILL Working Group                                         Hongjun Zhai
INTERNET-DRAFT                                                Fangwei Hu
Intended status: Proposed Standard                                   ZTE
Updates: RFCtrill                                          Radia Perlman
                                                              Intel Labs
                                                         Donald Eastlake
                                                                  Huawei
Expires: January 2, 2012                                    July 3, 2011


                      RBridges: The ESADI Protocol
                 <draft-hu-trill-rbridge-esadi-00.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
   safe forwarding even during periods of temporary loops. TRILL
   supports VLANs and the multi-pathing of both unicast and multicast
   traffic.  TRILL accomplishes this by using IS-IS (Intermediate System
   to Intermediate System) link state routing and encapsulating traffic
   using a header that includes a hop count. Devices that implement
   TRILL are called RBridges (Routing Bridges).

   The ESADI (End System Address Distribution Information) protocol is a
   VLAN (Virtual Local Area Network) scoped way that RBridge can
   communicate end station addresses to each other.  An RBridge
   announcing VLAN-x connectivity (normally a VLAN-x forwarder) and
   running the TRILL ESADI protocol receives remote address information
   and/or transmits local address information for VLAN-x.  The purpose
   of this document is to improve the documentation of the ESADI
   protocol.  The ESADI RBridge instance states, DRB (Designated
   RBridge) election procedure, and ESADI sub-TLVs are specified in this
   document.




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.


H. Zhai, et al                                                  [Page 1]


INTERNET-DRAFT                                           RBridges: ESADI


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

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

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




Acknowledgements

   TBD



































H. Zhai, et al                                                  [Page 2]


INTERNET-DRAFT                                           RBridges: 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 Election......................................8
      3.1 ESADI DRB..............................................8
      3.2 ESADI RBridge Instance States..........................8
      3.3 ESADI DRB election events..............................9
      3.4 Timers.................................................9
      3.5 ESADI Neighbor List...................................10
      3.6 State Table and Diagram...............................10

      4. ESADI PDU processing...................................13
      4.1 Sending of ESASI PDUs.................................13
      4.2 Receipt of PDUs.......................................14

      5. ESADI LSP Contents.....................................16
      5.1 ESADI Participation Data..............................16
      5.2 ESADI MAC Address sub-TLV.............................17

      6. IANA Considerations....................................18
      7. Security Considerations................................18

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






















H. Zhai, et al                                                  [Page 3]


INTERNET-DRAFT                                           RBridges: ESADI


1. Introduction

   The IETF TRILL (TRansparent Interconnection of Lots of Links)
   protocol [RFCtrill] provides least cost pair-wise data forwarding
   without configuration in multi-hop networks with arbitrary
   topologies, safe forwarding even during periods of temporary loops,
   and support for multi-pathing of both unicast and multicast traffic.
   TRILL accomplishes this by using IS-IS (Intermediate System to
   Intermediate System) [IS-IS] [RFC1195] [TRILLisis] link state routing
   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 derived multicast groups.  Devices that implement TRILL
   are called RBridges (Routing Bridges).

   There are five ways an RBridge can learn end station addresses as
   described in Section 4.8 of [RFCtrill].  The ESADI (End Station
   Address Distribution Information) protocol is an optional VLAN scoped
   way RBridges can communicate end station addresses with each other.
   An RBridge that is announcing connectivity to VLAN-x (normally a
   VLAN-x appointed forwarder) MAY use the (ESADI) protocol to announce
   some or all of its attached VLAN-x end nodes.

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

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

   2. Fast update advantages: ESADI protocol provides a fast update of
      end nodes MAC (Media Access Control) addresses.  If an end station
      is unplugged from one RBridge and plugged into another one, 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 [RFCtrill].

   MAC address reachability information and some ESADI parameters are
   carried in ESADI frames rather than in the core TRILL IS-IS protocol.
   As described below, ESADI is, for each VLAN, a virtual logical
   topology overlay in the TRILL topology. An advantage of using ESADI
   is that the end station attachment information is not flooded to all
   RBridges through the core IS-IS instance but only to participating
   RBridges advertising attachment to the VLAN in which those end


H. Zhai, et al                                                  [Page 4]


INTERNET-DRAFT                                           RBridges: ESADI


   stations occur.




1.1 Content and Precedence

   This document supplements and enriches the description of the ESADI
   protocol in the TRILL basic specification, especially the ESADI DRB
   (Designated RBridge) election procedure, ESADI instance state
   specification, and ESADI parameter announcement.  Section 2 is the
   ESADI protocol overviews. Section 3 specifics ESADI DRB principles,
   ESADI instance state and DRB election.  Section 4 discusses the
   processing of EASDI PDUs. Section 5 describes two ESADI sub-TLVs: one
   with ESADI participation information and the MAC Address sub-TLV.

   This document updates [RFCtrill] and prevails over [RFCtrill] in the
   case of conflicts.




1.2 Terminology

   This document uses the acronyms defined in [RFCtrill].

   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                                           RBridges: 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 itself as connected to one or more VLANs (usually because
   it is an Appointed Forwarder) and participates in the ESADI protocol
   is called an ESADI RBridge.

   ESADI is a separate protocol from the core IS-IS instance implemented
   by all RBridges in a campus.  There is a separate ESADI instance for
   each VLAN. In essence, for each VLAN, there is an instance of the IS-
   IS reliable flooding mechanism in which ESADI RBridges may choose to
   participate. (These are not the instances being specified in [draft-
   mi].) It is an implementation decision how independent the
   implementtion of 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.

   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.  For more detail see Section 4.2.5 in the TRILL base
   protocol specification [RFCtrill].

   TRILL ESADI frame Structure

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

                                 Figure 1

   All transit RBridges forward ESADI frames as if they were ordinary
   multicast TRILL Data frames.  Because of this forwarding, it appears
   to 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. Thus no "routing" computation or
   decisions ever have to be made by ESADI. A participating RBridge
   merely transmits the ESADI frames it originates on this virtual link
   by multicasting it as described in [RFCtrill]. RBridges that do not
   implement the ESADI protocol, do not have it enabled, or are not


H. Zhai, et al                                                  [Page 6]


INTERNET-DRAFT                                           RBridges: ESADI


   announcing connectivity for the Inner.VLAN of an ESADI frame do not
   decapsulate or locally process any TRILL ESADI frames they receive.
   Thus the ESADI frames are transparently tunneled through transit
   RBridges.

   TRILL ESADI frame payloads are structured like IS-IS frames but are
   always TRILL encapsulated on the wire as if they were TRILL Data
   frames.  The information and adjacency relation between ESADI
   RBridges are based on the ESADI frames that are carried as TRILL
   multicast data frames

   The ESADI instance for VLAN X at an RBridge acquires a neighbor when
   it first receives ESADI-LSP fragment zero from that neighbor and that
   neighbor is an existing RBridge in the core IS-IS instance link state
   database. When the entry for an RBridge is purged from the core IS-IS
   link state database, it is also purged from any ESADI instances and
   is lost as a neighbor.

   The information distributed with the ESADI protocol is a list of
   local end station MAC addresses known to the originating RBridge and,
   for each such address, a one octet unsigned "confidence" rating in
   the range 0-254 (see Section 5.2). It is entirely up to the
   originating RBridge which locally connected MAC addresses it wishes
   to advertise via ESADI. It MAY advertise all, some, or none of such
   addresses it has.

   TRILL ESADI LSPs do not contain a VLAN ID in their payload. The VLAN
   ID to which the ESADI data applies is the Inner.VLAN of the frame. 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 [VLAN-Mapping]. If a VLAN ID field in an ESADI
   frame payload does include a VLAN ID, its contents is ignored.




















H. Zhai, et al                                                  [Page 7]


INTERNET-DRAFT                                           RBridges: ESADI


3. ESADI DRB Election




3.1 ESADI DRB

   It is necessary to elect one ESADI RBridge DRB from all the ESADI
   RBridges for each VLAN where ESADI is being used.  The ESADI DRB is
   responsible for Link State Database synchronization with other
   RBridges by issuing ESADI-CSNP PDUs periodically and responding to
   PSNPs on the virtual link.




3.2 ESADI RBridge Instance States

   There are four states for each ESADI RBridge instance: Down, Initial,
   Not-DRB and DRB.  The state descriptions are as following:

   Down: This is a virtual state for convenience in creating state
         diagrams and tables.  It indicates that the ESADI instance is
         operationally down.

   Initial: This state indicates that an ESADI instance is up but does
         not know of any ESADI neighbors (i.e., the only entry in its
         neighbor list is itself). Once ESADI enters this state, it
         should start the Holding Timer, and multicast self-originated
         fragment zero LSPs to other RBridges. If a valid ESADI neighbor
         is found by receiving an ESADI LSP, the ESADI instance will
         leave this state and enter into "Not-DRB" state. In this state,
         the Holding Timer will be reset if the timer is expired or the
         found neighbor has a higher priority than the local priority.

   Not-DRB: This state indicates that the ESADI instance has found at
         least one valid ESADI neighbor and is not DRB yet. If there is
         no Holding Timer running, the timer will be started. If an
         ESADI LSP or a CSNP PDU is received from a higher priority
         ESADI RBridge, the Holding Timer will be reset. If the Holding
         Timer expires, the ESADI instance will enter into "DRB" state.

   DRB: In this state, the ESADI instance multicasts the ESADI CSNP PDUs
         periodically to keep Link State Database synchronization with
         its neighbors on virtual link, and responds to ESADI-PSNP PDUs
         with ESADI-LSPs. If an EDADI PDU (i.e., LSP, CSNP and PSNP) is
         received from a neighbor with a higher priority than its own,
         the ESADI instance will move to the "Not-DRB" state.




H. Zhai, et al                                                  [Page 8]


INTERNET-DRAFT                                           RBridges: ESADI


3.3 ESADI DRB election events

   The following events can change the ESADI state. These are all events
   for a particular ESADI VLAN-x instance.

   E1 ESADI instance is operationally up;

   E2 Finding the first ESADI neighbor;

   E3 Holding Timer expired;

   E4 Receiving an ESADI PDU from an ESADI neighbor with higher
      priority;

   E5 Losing the last ESADI neighbor;

   E6 ESADI instance goes operationally down;

   (Receiving an ESADI PDU from an ESADI neighbor with lower priority
   has no effect on the ESADI instance state.)

   Priority is determined by the seven-bit priority field in the ESADI
   participation data (see Section 5.1), with the System ID as a tie
   breaker, both considered as unsigned integers with the larger
   quantity indicating higher priority.




3.4 Timers

   There are two timers for ESADI DRB election: one the Holding Timer,
   the other the Waiting Timer. The Holding Timer is a cyclic timer, and
   is used in connection with ESADI-CSNP PDUs. If this timer expires,
   the local ESADI instance will start multicasting its own ESADI-CSNP
   PDUs and, if it was in the Non-DRB state, it decides that the DRB is
   being non-responsive and moves to the DRB state.

   The Waiting Timer is a non-cyclic timer. This timer is started by the
   change of neighbor's DRB status and killed by its expiration.  It is
   used to alleviate the PDUs storm stirred by Link State Database
   synchronization in the case of current DRB being preempted by a new
   ESADI neighbor with higher priority. If this timer expires, the new
   DRB is confirmed and its ESADI parameters, such as intervals of
   holding timer and waiting timer, are accepted to overwrite the local
   parameters.






H. Zhai, et al                                                  [Page 9]


INTERNET-DRAFT                                           RBridges: ESADI


3.5 ESADI Neighbor List

   In order to be able to access key information about ESADI neighbors
   easily, an ESADI neighbor list is maintained for each ESADI VLAN-x
   instance. Each entry in this list represents an ESADI neighbor for
   VLAN-x.

   For each neighbor, there will be a fragment zero LSP from that
   neighbor in the ESADI instance link state.  A list entry is created
   when such a fragment zero LSP is first received on the ESADI virtual
   link from some RBridge that exists in the core IS-IS instance link
   state database. A neighbor entry for an RBridge is deleted when that
   RBridge is purged from the core IS-IS instance link state database.
   For each neighbor, the parameters of System-ID/nickname, priority,
   holding timer interval, waiting timer interval and the DRB flag, are
   stored in its respective entry in this list.

   The DRB flag indicates whether a neighbor is regarded as DRB or not.
   If this flag is 1, the associated neighbor is considered as DRB,
   otherwise, not DRB. At any moment, there is no more than one entry
   that is flagged as DRB in this list. The DRB status of a neighbor can
   be changed by the receipt of ESADI-CSNP PDUs coupled with the
   priorities of the originators of the PDUs, together with the priority
   of the local ESADI instance (see Section 4.2 for more details). When
   the DRB flag of one entry, such as the entry of the local ESADI
   instance, is changed in this list, the Waiting Timer will be started
   if it is not running.  When the timer is expired, the neighbor, whose
   DRB flag is 1, will be confirmed as real DRB, and its CSNP PDUs will
   be used to accomplish Link State Database synchronization with other
   ESADI RBridges.

   If the ESADI instance is in "Initial" state, there is only one entry
   existing in this list, where the parameters of the local ESADI VLAN-x
   instance is saved. If a new entry is added to this list and the entry
   is the second one, an E2 event will occur, which drives the state of
   this ESADI instance into "Not-DRB" from "Initial".  When there are
   only two entries in this list, if the second entry is removed from
   this list, an E5 event is originated, which draws this ESADI instance
   back to "Initial" state from "Not-DRB" or "DRB".




3.6 State Table and Diagram

   The table below shows the transitions between the RBridge ESADI
   instance states defined above based on the events defined above:





H. Zhai, et al                                                 [Page 10]


INTERNET-DRAFT                                           RBridges: ESADI


   TRILL ESADI State Table

             | Event |  Down   | Initial | Not-DRB |  DRB    |
             +-------+---------+---------+---------+---------+
             |  E1   | Initial |  N/A    |  N/A    |  N/A    |
             |  E2   |   N/A   | Not-DRB |  N/A    |  N/A    |
             |  E3   |   N/A   | Initial |  DRB    |  N/A    |
             |  E4   |   N/A   | Initial | Not-DRB | Not-DRB |
             |  E5   |   N/A   | Initial | Initial | Initial |
             |  E6   |   Down  |  Down   |  Down   |  Down   |
             +-------+---------+---------+---------+---------+

                                 Figure 2

   N/A indicates that the event to the left is Not Applicable in the
   state at the top of the column.

   The first state is "Down". Once an RBridge ESADI instance is
   operationally up, it enters into "Initial" state. An ESADI instance
   should start the Holding Timer and multicast its self-originated
   fragment zero LSP to other ESADI RBridges. When the first valid ESADI
   neighbor is found on the virtual link, the ESADI instance enters
   "Not-DRB" state, otherwise the ESADI instance remains in "Initial"
   state and resets the Holding Timer whenever the timer expires. And if
   the neighbor's priority is higher than its own, the Holding Timer
   will be reset before the ESADI instance enters the "Not-DRB" state.

   In both the "Non-DRB" and "DRB" states, the ESADI RBridge multicasts
   all its self-originated LSP fragments.

   In the "Not-DRB" state, if any ESADI PDUs are received from ESADI
   neighbors with higher priorities, the Holding Timer will be reset.
   Otherwise, if the timer expires without hearing from a higher
   priority neighbor, the ESADI instance will enter "DRB" state. An
   ESADI DRB can be preempted by a higher priority neighbor. If the DRB
   receives an ESADI PDU from a higher priority neighbor, the ESADI
   instance will move to "Not-DRB" state. As DRB, an ESADI instance will
   multicast ESADI-CSNP PDUs to all neighbors on the virtual link
   periodically, and respond to the ESADI-PSNP PDUs with ESADI-LSP PDUs
   by multicasting them.

   Below is the same information as in the state table presented as a
   diagram.









H. Zhai, et al                                                 [Page 11]


INTERNET-DRAFT                                           RBridges: ESADI


   TRILL ESADI state diagram


              +------------------+
              |       Down       |<--------+
              +------------------+         |
                |   ^    |     ^           |
                |E1 |E5  | E6  |           |
                V   |    +-----+           |
              +------------------+   E6    |
        +---->|      Initial     |---------|
        |     +------------------+         |
        |      |   ^   |        ^          |
        |      |E2 |E5 |E3,E4,E5|          |
        |      V   |   +--------+          |
        |     +------------------+   E6    |
        |     |     Not-DRB      |---------|
        |     +------------------+         |
        |      |   ^   |       ^           |
        |      |E3 |E4 | E4    |           |
        |      V   |   +-------+           |
        | E5  +------------------+   E6    |
        +-----|       DRB        |---------+
              +------------------+

                             Figure 3


























H. Zhai, et al                                                 [Page 12]


INTERNET-DRAFT                                           RBridges: 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 may be hundreds of ESADI RBridges on the virtual link.  There
   are only LSP, CSNP and PSNP PDUs used in ESADI. In particular, there
   are no Hellos because ESADI does not need to build a topology and
   does not need to do any routing.

   In IS-IS, multicasting is normally 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 entire link busy for that frame time. But
   in ESADI what appears to be a simple multi-access link is actually a
   multi-hop distribution tree that may or may not be pruned. Thus,
   transmitting a multicast frame on such a tree imposes 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 unicast.

   An undesirable storm of LSP PDUs may be sent to update a new ESADI
   RBridge when it starts to participate in VLAN-x ESADI if it has
   higher priority and becomes DRB on the virtual link.

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




4.1 Sending of ESASI PDUs

   When the VLAN-x ESADI instance is in "Not-DRB" or "DRB" state and a
   new neighbor is found, its self-originated LSP fragments are
   scheduled to be sent and MAY be unicast to that neighbor. The
   interval elapsed before sending the LSP(s), depends on the priority
   of the local ESADI instance.  The higher the priority, the shorter
   the interval is.

   In the case of receiving an LSP with a smaller sequence number than
   the LSP copy stored in local Link State Database, the local ESADI
   instance will also schedule to transmit the stored LSP copy and MAY
   unicast it to the sender. After the sender receives such a LSP, it
   can originate a new LSP, whose sequence number is bigger than the
   received sequence number, to refresh the LSP in all the neighbors.

   If the ESADI instance is DRB, it multicasts a CSNP periodically to
   keep the Link State Database synchronized among its neighbors on the
   virtual link. After receiving a PSNP PDU, the DRB will transmit the


H. Zhai, et al                                                 [Page 13]


INTERNET-DRAFT                                           RBridges: ESADI


   LSPs requested by the PSNP on the virtual link.

   If the ESADI instance is not DRB, it will schedule multicasting only
   its self-originated LSP on the virtual link when it finds the DRB
   losing some LSPs or having stale LSPs, including the local ESADI
   instance's self-originated LSPs, from the CSNP PDUs it receives. The
   higher the priority, the shorter the interval is.

   The format of a unicast ESADI frame is the format of TRILL ESADI
   frame, in section 4.2 in [RFCtrill], except that, 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 PDUs

   When an ESADI PDU is received, the receiver checks for the
   originator's System ID in the receiver's core IS-IS instance link
   state database. If the System ID is not present, the PDU is
   discarded.

   After receiving a new ESADI LSP with a known System ID, the LSP will
   be installed into or replaced the older copy of this LSP in the local
   ESADI Link State Database.  If it is a fragment zero LSP, the local
   ESADI instance will try to find the originator of the LSP in its
   neighbor list. If the neighbor is found, any different parameters of
   this neighbor will be stored in the associated entry in the neighbor
   list. Otherwise, a new neighbor is detected, and an associated entry
   is inserted into the list to store this neighbor's information. If
   the local EASDI instance is in "Initial" state and the entry is the
   second entry in the neighbor list, an E2 event will be originated,
   which will push this ESADI instance into "Not-DRB" state from
   "Initial".

   On receiving a CSNP PDU with a known System ID, if the ESADI instance
   is in "Initial" state, the PDU is used for Link State Database
   synchronization. Otherwise, the local ESADI instance tries to find
   the originator in its neighbor list. In the following cases, the CSNP
   PDU will be discarded:
   1) The originator is not found in the neighbor list;
   2) The originator is found in the list, but its priority is not
      higher than the local ESADI instance's priority.

   If the CSNP PDU is not discarded and the local ESADI instance is in
   "Not-DRB" or "DRB" state, it will be used to update the DRB flag in
   the entries in the neighbor list, i.e., the originator's DRB flag is
   set to 1 and other entries' DRB flag is cleared to zero. The above
   update may make the potential DRB change from one neighbor to


H. Zhai, et al                                                 [Page 14]


INTERNET-DRAFT                                           RBridges: ESADI


   another; if so, the Waiting Timer will be started if it is not
   running.  If potential DRB doesn't change from one neighbor to
   another, and the Waiting Timer is not running yet, this CSNP PDU is
   used for Link State Database synchronization. ESADI-PSNP PDUs will be
   multicast on the virtual link to request fresh copies of lost or
   stale LSPs from DRB, if necessary.

   When receiving a PSNP PDU, if the local ESADI instance is DRB and the
   Waiting Timer is not running, LSP PDU associated the PSNP will be
   multicast on the virtual link. Otherwise, the PSNP PDU is discarded.










































H. Zhai, et al                                                 [Page 15]


INTERNET-DRAFT                                           RBridges: ESADI


5. ESADI LSP Contents

   The only PDUs used in ESADI are the Level 1 LSP, CSNP, and PSNP PDUs.
   This section specifies the format for ESADI participation data sub-
   TLV and gives the reference for the ESADI MAC Reachability TLV.




5.1 ESADI Participation Data

   The figure below presents the format of the ESADI participation data.
   This sub-TLV MUST be included in LSP fragment zero. LSP fragment zero
   MUST NOT exceed 1470 bytes in length.

   [[ This should probably be a Router Capabilities TLV and this section
   probably needs to be in an ISIS WG draft. ]]

         Participation Data

              +-+-+-+-+-+-+-+-+
              |     Type      |              (1 byte)
              +-+-+-+-+-+-+-+-+
              |    Length     |              (1 byte)
              +-+-+-+-+-+-+-+-+
              |D|  Priority   |              (1 byte)
              +-+-+-+-+-+-+-+-+
              | Holding Time  |              (1 byte)
              +-+-+-+-+-+-+-+-+
              | Waiting Time  |              (1 byte)
              +-+-+-+-+-+-+-+-+

                                 Figure 4

   Type: set to TBD

   Length: Set to 3.

   D: If the sub-TLV is originated by the DRB or an EASDI instance
      sending CSNPs as DRB, the D field is set to 1, otherwise, the
      field is zero.

   Priority: The Priority field gives the RBridge's priority for being
      DRB on the TRILL EASDI virtual link for the VLAN in which the PDU
      containing the Participation data was sent. It is a 7-bit unsigned
      integer.

   Holding Time: Gives the holding time in seconds as an unsigned
      integer.



H. Zhai, et al                                                 [Page 16]


INTERNET-DRAFT                                           RBridges: ESADI


   Waiting Time: Gives the waiting time in seconds as an unsigned
      integer.

   When an ESADI instance receives a participation data sub-TLV in which
   the D field is set to 1 and the originator of this LSP is confirmed
   DRB by the local ESADI instance as highest priority, the RBridge sets
   the local Holding Timer according to the value of holding time field,
   and sets the local Waiting Timer according to the value of waiting
   time field.




5.2 ESADI MAC Address sub-TLV

   The information in TRILL ESADI LSP PDUs consists of one or more 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.

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

























H. Zhai, et al                                                 [Page 17]


INTERNET-DRAFT                                           RBridges: ESADI


6. IANA Considerations

   TBD




7. Security Considerations

   TBD

   For general TRILL Security Considerations, see [RFCtrill].








































H. Zhai, et al                                                 [Page 18]


INTERNET-DRAFT                                           RBridges: ESADI


8. References

   Normative and informative references for this document are below.




8.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)", 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.

   [RFC4971] - Vasseur, JP., N. Shen, and R. Aggarwal, "Intermediate
         System to Intermediate System (IS-IS) Extensions for
         Advertising Router Information", RFC 4971, July 2007.

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

   [TRILLisis] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A.
         Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill-05, in
         RFC Editor's queue.

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




8.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-2004, 13 December 2004.

   [VLAN-Mapping] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani,
         and D. Eastlake, "RBridges: Campus VLAN and Priority Regions",
         draft-ietf-trill-rbridge-vlan-mapping-05.txt, work in process,
         April 2011.


H. Zhai, et al                                                 [Page 19]


INTERNET-DRAFT                                           RBridges: 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 Technologies
   155 Beaver Street
   Milford, MA 01757 USA

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
















H. Zhai, et al                                                 [Page 20]


INTERNET-DRAFT                                           RBridges: ESADI


Copyright and 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
   (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 21]