TRILL Working Group Hongjun Zhai INTERNET-DRAFT Fangwei Hu Intended status: Proposed Standard ZTE Updates: 6325 Radia Perlman Intel Labs Donald Eastlake Huawei Expires: Jun 30, 2012 December 31, 2011 RBridges: The ESADI Protocol <draft-hu-trill-rbridge-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 safe forwarding even during periods of temporary loops. TRILL supports 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. 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 can receive remote address information and/or transmit local address information for VLAN-x to other such RBridges. The purpose of this document is to improve and update the documentation of the ESADI protocol. It updates RFC 6325. The ESADI RBridge instance states, DRB (Designated RBridge) election procedure, and ESADI sub-TLV 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 Control State.....................................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...............................11 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................................20 H. Zhai, et al [Page 3]
INTERNET-DRAFT RBridges: 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, 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] [RFC6326] 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) 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 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 the MAC 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: 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 [RFC3748]) 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 RB1 and plugged into RB2, 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 [RFC6325]. 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 H. Zhai, et al [Page 4]
INTERNET-DRAFT RBridges: ESADI RBridges through the core IS-IS instance but only to participating RBridges advertising ESADI support for the VLAN in which those end stations occur. 1.1 Content and Precedence This document clarifies and updates 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 overview. Section 3 specifics ESADI DRB principles, ESADI instance state and DRB election. Section 4 discusses the processing of ESADI PDUs. Section 5 describes two ESADI sub-TLVs: the one with ESADI participation information and the MAC Address sub-TLV. This document updates [RFC6325] and prevails over [RFC6325] in the case of conflicts. 1.2 Terminology This document uses the acronyms defined in [RFC6325]. 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 [MultiInstance].) It is an implementation decision how independent the implementations 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 or could be a separate database per VLAN. But the update processes operate separately for each ESADI instance. 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 [RFC6325]. 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 H. Zhai, et al [Page 6]
INTERNET-DRAFT RBridges: ESADI as described in [RFC6325] for any multicast frame. RBridges that do not implement the ESADI protocol, do not have it enabled, or are not 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 ESADI instance for VLAN-x at an RBridge RB1 acquires a neighbor when it first receives ESADI-LSP number zero from that neighbor and that neighbor is an existing RBridge in the core IS-IS instance link state database that is data and IS-IS reachable from RB1 (see Section 2 of [ClearCorrect]). When an RBridge RB2 becomes IS-IS or data unreachable from RB1 or the entry for RB1 is purged from the core IS- IS link state database, it is lost as a neighbor and also purged from any ESADI instances. 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. Future uses of ESADI may use it to distribute additional 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 in an ESADI frame payload does include a VLAN ID, its contents is ignored. (In the future, TRILL may be extended to provide more fine-grained labeling of data and ports [FineGrained]. If so, it is expected that ESADI will be extended by allowing such fineegrained labeling of ESADI frames, as an alternative to the currently allowed Inner.VLAN labeling. As with the current ESADI specification, it would generally be prohibited for such fine-grained labeling information to appear inside such extended ESADI frames.) H. Zhai, et al [Page 7]
INTERNET-DRAFT RBridges: ESADI 3. ESADI Control State This Section discusses ESADI control state in terms of DRB, neighbors, and instance states. 3.1 ESADI DRB It is necessary to elect one ESADI RBridge for each VLAN scoped virtual link 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 the ESADI instance at each RBridge for each VLAN: 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 number zero LSPs on the virtual link. If a valid ESADI neighbor is found by receiving an ESADI-LSP number zero, the ESADI instance will leave this state and enter into "Not-DRB" state. In this state, the Holding Timer will be recycled 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 an ESADI-CSNP PDU is received from a higher priority ESADI RBridge, the Holding Timer will be recycled. 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 H. Zhai, et al [Page 8]
INTERNET-DRAFT RBridges: ESADI 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. 3.3 ESADI DRB election events The following events can change the ESADI state. These are all events for a particular RBridge's 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 PDU storm stirred by Link State Database synchronization in the case of current DRB being preempted by a new H. Zhai, et al [Page 9]
INTERNET-DRAFT RBridges: ESADI 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. 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 number zero LSP from that neighbor in the ESADI instance link state. A list entry is created when such a number zero LSP is first received on the ESADI virtual link from some RBridge that exists in the core IS-IS instance link state database and is both data and IS-IS reachable (see Section 2 of [ClearCorrect]). A neighbor entry for an RBridge is deleted when that RBridge if that RBridge becomes data or IS-IS unreachable or if it 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". H. Zhai, et al [Page 10]
INTERNET-DRAFT RBridges: ESADI 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: 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 | N/A | 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. On transition into the Initial state, an ESADI instance starts its Holding Timer and multicasts its self-originated number zero LSP on the virtual link. 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. While in Initial state, whenever the timer expires it recycles the Holding Timer and multicasts its ESADI- LSP number zero. And if the neighbor's priority is higher than its own, the Holding Timer will be recycled 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 recycled. Otherwise, if the timer expires without hearing from a higher priority neighbor, the ESADI instance will enter "DRB" state. 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 above presented as a diagram. H. Zhai, et al [Page 11]
INTERNET-DRAFT RBridges: ESADI TRILL ESADI state diagram +------------------+ | Down |<--------+ +------------------+ | | | ^ | |E1 | E6 | | V +-----+ | +------------------+ E6 | +---->| Initial |---------| | +------------------+ | | | ^ | ^ | | |E2 |E5 |E3,E4 | | | 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 could 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 Hello or MTU PDUs because ESADI does not build a topology and does not 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 TRILL unicast. An undesirable storm of LSP PDUs could be sent to update a new RBridge participant in VLAN-x ESADI if it has higher priority and becomes DRB on the virtual link. ESADI has a feature to ameliorate this. 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 an ESADI-CSNP periodically to keep the Link State Database synchronized among its H. Zhai, et al [Page 13]
INTERNET-DRAFT RBridges: ESADI neighbors on the virtual link. After receiving an ESADI-PSNP PDU, the DRB will transmit the 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 ESADI-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 [RFC6325], 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 or appears to be data or IS-IS unreachable, the ESADI PDU is discarded. After receiving a new ESADI-LSP that passes the above check, 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 number 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 ESADI instance is in "Initial" state, the entry will be the second entry in the neighbor list, an E2 event will be originated, which will move this ESADI instance into "Not-DRB" state from "Initial". On receiving an ESADI-CSNP PDU from an ESADI neighbor list member, the PDU is used for Link State Database synchronization. If received from some other RBridge, it is discarded. If the ESADI-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 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 H. Zhai, et al [Page 14]
INTERNET-DRAFT RBridges: ESADI multicast on the virtual link to request fresh copies of lost or stale LSPs from DRB, if necessary. When receiving an ESADI-PSNP PDU, if the local ESADI instance is DRB and the Waiting Timer is not running, LSP PDU requested 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 APPsub-TLV MUST be included in a TRILL GENAPP TLV in ESADI LSP number zero. LSP number zero MUST NOT exceed 1470 bytes in length. 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 TRILL APPsub-TLV type 1. Length: Set to 3. D: If the sub-TLV is originated by an ESADI instance that thinks it is DRB or an ESADI instance sending CSNPs as DRB, the D field is set to 1, otherwise, the field is zero. Priority: The Priority field gives the ESADI instance's priority for being DRB on the TRILL ESADI 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. Waiting Time: Gives the waiting time in seconds as an unsigned integer. H. Zhai, et al [Page 16]
INTERNET-DRAFT RBridges: ESADI 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 ESADI 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 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 Parameters <this RFC> 2-254 Available <this RFC> 255 Reserved <this RFC> TRILL APPsub-TLV Types 2 through 254 are available for allocation by Standard Action as modified by [RFC4020]. The standards track 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 TRILL IS-IS protocol operation including the establishment of adjacencies, the update process, and the decision process [IS-IS] [RFC1195] [RFC6327]. The V, I, D, and S flags in the initial flags byte of a TRILL Generic Information TLV [RFCgenapp] are not used as TRILL operates as a Level 1 IS-IS area and no meaning is hereby assigned to the inclusion of an IPv4 and/or IPv6 address via the I and V flags. Thus these flags 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 5.1). The security implications of each RBridge Channel protocol will be discussed in the RFC specifying that protocol. For Security Considerations related to ESADI and the ESADI parameters APPsub-TLV, see Section 7. 7. Security Considerations TBD For general TRILL Security Considerations, see [RFC6325]. 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. [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [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. [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011. [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011. [RFCgenapp] - Ginsberg, L., S. Previdi, M. Shand, "Advertising Generic Information in IS-IS", draft-ietf-isis-genapp-04.txt, in RFC Editor's queue. [ClearCorrect] - draft-eastlake-trill-rbridge-clear-correct, work in progress. H. Zhai, et al [Page 19]
INTERNET-DRAFT RBridges: ESADI 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-2010, 5 February 2010. [FineGrained] - Eastlake, D., M. Zhang, P. Agarwal, D. Dutt, R. Perlman, "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine- labeling, work in progres. [MultiInstance] - Previdi, S., L. Ginsberg, M. Shand, A. Roy, D. Ward, draft-ietf-isis-mi, work in progrss. [MultiLevel] - 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. [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 process. H. Zhai, et al [Page 20]
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 21]
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 22]