INTERNET-DRAFT Linda Dunbar Intended status: Proposed Standard Donald Eastlake Updates: ESADI Huawei Radia Perlman Intel Igor Gashinsky Yahoo Yizhou Li Huawei Expires: April 20, 2014 October 21, 2013 TRILL: Edge Directory Assistance Mechanisms Abstract This document describes mechanisms for using directory server(s) to assist TRILL (Transparent Interconnection of Lots of Links) edge switches in reducing multi-destination traffic, particularly ARP/ND and unknown unicast flooding. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- 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." 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. L. Dunbar, et al [Page 1] INTERNET-DRAFT TRILL: Directory Assist Mechanisms Table of Contents 1. Introduction............................................3 1.1 Terminology............................................3 2. Push Model Directory Assistance Mechanisms..............5 2.1 Requesting Push Service................................5 2.2 Push Directory Servers.................................5 2.3 Push Directory Server State Machine....................6 2.3.1 Push Directory States................................6 2.3.2 Push Directory Events and Conditions.................7 2.3.3 State Transition Diagram and Table...................8 2.4 Additional Push Details...............................10 2.5 Primary to Secondary Server Push Service..............11 3. Pull Model Directory Assistance Mechanisms.............12 3.1 Pull Directory Request Format.........................12 3.2 Pull Directory Response Format........................15 3.3 Pull Directory Hosted on an End Station...............18 3.4 Pull Directory Request Errors.........................19 3.5 Cache Consistency.....................................20 3.6 Additional Pull Details...............................22 4. Events That May Cause Directory Use....................23 4.1 Forged Native Frame Ingress...........................23 4.2 Unknown Destination MAC...............................23 4.3 Address Resolution Protocol (ARP).....................24 4.4 IPv6 Neighbor Discovery (ND)..........................25 4.5 Reverse Address Resolution Protocol (RARP)............25 5. Layer 3 Address Learning...............................26 6. Directory Use Strategies and Push-Pull Hybrids.........27 6.1 Strategy Configuration................................27 7. Security Considerations................................30 8. IANA Considerations....................................31 8.1 ESADI-Parameter Data..................................31 8.2 RBridge Channel Protocol Number.......................32 8.3 The Pull Directory and No Data Bits...................32 Acknowledgments...........................................33 Normative References......................................33 Informational References..................................34 Authors' Addresses........................................35 L. Dunbar, et al [Page 2] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 1. Introduction [DirectoryFramework] describes a high-level framework for using directory servers to assist TRILL [RFC6325] edge nodes to reduce multi-destination ARP/ND and unknown unicast flooding traffic and to potentially improve security against address spoofing within a TRILL campus. Because multi-destination traffic becomes an increasing burden as a network scales, reducing ARP/ND and unknown unicast flooding improves TRILL network scalability. This document describes specific mechanisms for directory servers to assist TRILL edge nodes. These mechanisms are optional to implement. The information held by the Directory(s) is address mapping and reachability information. Most commonly, what MAC address [RFC5342bis] corresponds to an IP address within a Data Label (VLAN or FGL (Fine Grained Label [RFCfgl])) and from what egress TRILL switch (RBridge) (and optionally what specific TRILL switch port) that MAC address is reachable. But it could be what IP address corresponds to a MAC address or possibly other address mappings or reachability. In the data center environment, it is common for orchestration software to know and control where all the IP addresses, MAC addresses, and VLANs/tenants are in a data center. Thus such orchestration software is appropriate for providing the directory function or for supplying the Directory(s) with directory information. Directory services can be offered in a Push or Pull mode. Push mode, in which a directory server pushes information to TRILL switches indicating interest, is specified in Section 2. Pull mode, in which a TRILL switch queries a server for the information it wants, is specified in Section 3. Modes of operation, including hybrid Push/Pull, are discussed in Section 4. The mechanisms used to initially populate directory data in primary servers is beyond the scope of this document. The Push Directory service can be used by a primary server to provide Directory data to secondary servers as described in Section 2. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. The terminology and acronyms of [RFC6325] are used herein along with the following additions: CP: Complete Push flag bit. See Sections 2 and 6.1 below. L. Dunbar, et al [Page 3] INTERNET-DRAFT TRILL: Directory Assist Mechanisms CSNP Time: Complete Sequence Number PDU Time. See [ESADI] and Section 6.1 below. Data Label: VLAN or FGL. FGL: Fine Grained Label [RFCfgl]. Host: Application running on a physical server or a virtual machine. A host must have a MAC address and usually has at least one IP address. IP: Internet Protocol. In this document, IP includes both IPv4 and IPv6. PD: Push Directory flag bit. See Sections 2 and 6.1 below. primary server: A Directory server that obtains the information it is serving up by a reliable mechanism outside the scope of this document but designed to assure the freshness of that information. (See secondary server.) RBridge: An alternative name for a TRILL switch. secondary server: A Directory server that obtains the information it is serving up from one or more primary servers. tenant: Sometimes used as a synonym for FGL. TRILL switch: A device that implements the TRILL protocol. L. Dunbar, et al [Page 4] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 2. Push Model Directory Assistance Mechanisms In the Push Model [DirectoryFramework], one or more Push Directory servers push down the address mapping information for the various addresses associated with end station interface and the TRILL switches from which those interfaces are reachable [IA]. This service is scoped by Data Label (VLAN or FGL [RFCfgl]). A Push Directory also advertises whether or not it believes it has pushed complete mapping information for a Data Label. It might be pushing mapping information for only a subset of the ports in a Data Label. The Push Model uses the [ESADI] protocol as its distribution mechanism. With the Push Model, if complete address mapping information for a Data Label being pushed is available, a TRILL switch (RBridge) which has that complete pushed information can simply drop a native frame if the destination unicast MAC address can't be found in the mapping information available, instead of flooding it (see Section 2.1). This will minimize flooding of packets due to errors or inconsistencies but is not practical if directories have incomplete information. 2.1 Requesting Push Service In the Push Model, it is necessary to have a way for an RBridge to request information from the directory server(s). RBridges simply use the ESADI protocol mechanism to announce, in their core IS-IS LSPs, the Data Labels for which they are participating in [ESADI] by using the Interested VLANs and/or Interested Labels sub-TLVs [RFC6326bis]. This will cause them to be pushed the Directory information for all such Data Labels that are being served by one or more Push Directory servers. 2.2 Push Directory Servers Push Directory servers advertise their availability to push the mapping information for a particular Data Label to each other and to ESADI participants for that Data Label by turning on a flag bit in their ESADI Parameter APPsub-TLV [ESADI] for that ESADI instance (see Section 8.1). Each Push Directory server MUST participate in ESADI for the Data Labels for which it will push mappings and set the PD (Push Directory) bit in their ESADI-Parameters APPsub-TLV for that Data Label. For robustness, it is useful to have more than one copy of the data being pushed. Each RBridge that is a Push Directory server is configured with a number in the range 1 to 8, which defaults to 2, for each Data Label for which it can push directory information. If L. Dunbar, et al [Page 5] INTERNET-DRAFT TRILL: Directory Assist Mechanisms the Push Directories for a Data Label are configured the same in this regard and enough such servers are available, this is the number of copies of the directory that will be pushed. Each Push Directory server also has an 8-bit priority to be Active (see Section 8.1 of this document). This priority is treated as an unsigned integer where larger magnitude means higher priority and is in its ESADI Parameter APPsub-TLV. In cases of equal priority, the 6-byte IS-IS System ID is used as a tie breaker and treated as an unsigned integer where larger magnitude means higher priority. For each Data Label it can serve, each Push Directory server orders, by priority, the Push Directory servers that it can see in the ESADI link state database for that Data Label that are data reachable [RFCclear] and determines its position in that order. If a Push Directory server is configured to believe that N copies of the mappings for a Data Label should be pushed and finds that it is number K in the priority ordering (where number 1 is highest priority and number K is lowest), then if K is less than or equal to N the Push Directory server is Active. If K is greater than N it is Passive. Active and Passive behavior are specified below. 2.3 Push Directory Server State Machine The subsections below describe the states, events, and corresponding actions for Push Directory servers. 2.3.1 Push Directory States A Push Directory Server is in one of six states, as listed below, for each Data Label it can serve. In addition, it has an internal State- Transition-Time variable for each such Data Label which it set at each state transition and which enables it to determine how long it has been in its current state. Down: A completely shut down virtual state defined for convenience in specifying state diagrams. A Push Directory Server in this state does not advertise any Push Directory data. It may be participating in [ESADI] with the PD bit zero in its ESADI- Parameters or might be not participating in [ESADI] at all. (All states other than the Down state are considered to be Up states.) Passive: No Push Directory data is advertised. Any outstanding EASDI- LSP fragments containing directory data are updated to remove that data and if the result is an empty fragment (contains nothing except possibly an Authentication TLV), the fragment is purged. L. Dunbar, et al [Page 6] INTERNET-DRAFT TRILL: Directory Assist Mechanisms The Push Directory participates in [ESADI] and its [ESADI] fragment zero includes an ESADI-Parameters APPsub-TLV with the PD bit set to one and CP (Complete Push) bit zero. Active: If a Push Directory server is Active, it advertises its directory data through [ESADI] in its ESADI-LSPs using the Interface Addresses [IA] APPsub-TLV and updates that information as it changes. The PD bit is set to one in the ESADI-Parameters and the CP bit must be zero. Completing: Same behavior as the Active state but responds differently to events. Complete: The same behavior as Completing except that the CP bit in the ESADI-Parameters APPsub-TLV is set to one and the server responds differently to events. Reducing: The same behavior as Complete but responds differently to events. The PD bit remains a one but the CP bit is cleared to zero in the ESADI-Parameters APPsub-TLV. Directory updates continue to be advertised. 2.3.2 Push Directory Events and Conditions Three auxiliary conditions referenced later in this section are defined as follows for convenience: The Activate Condition: The server determines that there are K data reachable Push Directory servers, the server is configured that there should be N copies pushed, and K is less than or equal to N. The Pacify Condition: The server determines that there are K data reachable Push Directory servers, the server is configured that there should be N copies pushed, and K is greater than N. The Time Condition: The server has been in its current state for an amount of time equal to or larger than its CSNP time (see Section 8.1).) The events and conditions listed below cause state transitions in Push Directory servers. 1. Push Directory server or TRILL switch was configured to be down but the TRILL switch on which it resides is up and the server is configured to be up. 2. The Push Directory server or the TRILL switch on which it is resident is being shut down. L. Dunbar, et al [Page 7] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 3. The Activate Condition is met and the server is not configured to believe it has complete data. 4. The server determines that the Pacify Condition is met. 5. The server is configured to believe it has complete data and the Activate Condition is met. 6. The server is configured to believe it does not have complete data. 7. The Time Condition is met. 2.3.3 State Transition Diagram and Table The state transition diagram is as follows. L. Dunbar, et al [Page 8] INTERNET-DRAFT TRILL: Directory Assist Mechanisms +-----------+ | Down |<---------+ +-----------+ | |1 ^ | 3,4,5,6,7 | | | +------------+ V |2 +-----------+ | Passive |<----------------------- +-----------+ ^ ^ ^ |5 |3 |1,4,6,7 | | | | | +---------+ | | | V |2,4 | | +---------------------+ | | | Active |<--+ | | +---------------------+ | | | |5 ^ |1,3,6,7 ^ | | | | | | | | | | | | +---------+ | | | | | | | V V |3,6 | | +--------------+ | | | Completing |-------------------+ +--------------+ 2,4 | |7 |1,5 ^ | | | | | | +-----+ | V |7 +-------------+ +----------------+ | Complete |--------->| Reducing |<--+ +-------------+ 2,3,4,6 +----------------+ | |1,5,7 ^ ^ |5 |1,2,3,4,6 | | | | | | | +------+ +--------------+ +--------------+ Figure 1. Push Server State Diagram This state diagram is equivalent to the following transition table: Event || Down |Passive |Active |Completing|Complete|Reducing| ------++-------+----------+--------+----------+--------+--------+ 1 ||Passive|Passive |Active |Completing|Complete|Reducing| 2 || Down | Down |Passive |Passive |Reducing|Reducing| 3 || Down |Active |Active |Active |Reducing|Reducing| 4 || Down |Passive |Passive |Passive |Reducing|Reducing| 5 || Down |Completing|Complete|Completing|Complete|Complete| 6 || Down |Passive |Active |Active |Reducing|Reducing| 7 || Down |Passive |Active |Complete |Complete|Active | L. Dunbar, et al [Page 9] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 2.4 Additional Push Details Push Directory mappings can be distinguished for any other data distributed through ESADI because mappings are distributed only with the Interface Addresses APPsub-TLV [IA] and are flagged as being Push Directory data. RBridges, whether or not they are a Push Directory server, MAY continue to advertise any locally learned MAC attachment information in [ESADI] using the Reachable MAC Addresses TLV [RFC6165] . However, if a Data Label is being served by complete Push Directory servers, advertising such locally learned MAC attachment should generally not be done as it would not add anything and would just waste bandwidth and ESADI link state space. An exception would be when an RBridge learns local MAC connectivity and that information appears to be missing from the directory mapping. Because a Push Directory server may need to advertise interest in Data Labels even if it does not want to receive end station data in those Data Labels, the No Data flag bit is provided as discussed in Section 6.3. If an RBridge notices that a Push Directory server is no longer data reachable [RFCclear], it MUST ignore any Push Directory data from that server because it is no longer being updated and may be stale. The nature of dynamic distributed asynchronous systems is such that it is impractical for an RBridge receiving Push Directory information to ever be absolutely certain that it has complete information. However, it can obtain a reasonable assurance of complete information by requiring two conditions to be met: 1. The PD and CP bits are on in the ESADI zero fragment from the server for the relevant Data Label. 2. A client RBridge might be just coming up and receive an EASDI LSP meeting the requirement in point 1 above but have not yet received all of the ESADI LSP fragment from the Push Directory server. Thus, it should not believe that information to be complete unless it has also had data connectivity to the server for the larger of the client's and the server's CSNP times. There may be transient conflicts between mapping information from different Push Directory servers or conflicts between locally learned information and information received from a Push Directory server. In case of such conflicts, information with a higher confidence value is preferred over information with a lower confidence. In case of equal confidence, Push Directory information is preferred to locally learned information and if information from Push Directory servers conflicts, the information from the higher priority Push Directory server is preferred. L. Dunbar, et al [Page 10] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 2.5 Primary to Secondary Server Push Service A secondary Push or Pull Directory server is one that obtains its data from a primary directory server. Other techniques MAY be used but, by default, this data transfer occurs through the primary server acting as a Push Directory server for the Data Labels involved while the secondary Push Directory server takes the pushed data it receives from the highest priority Push Directory server and re-originates it. L. Dunbar, et al [Page 11] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 3. Pull Model Directory Assistance Mechanisms In the Pull Model, a TRILL switch (RBridge) pulls directory information from an appropriate Directory Server when needed. Pull Directory servers for a particular Data Label X are located by looking in the core TRILL IS-IS link state database for RBridges that advertise themselves by having the Pull Directory flag on in their Interested VLANs or Interested Labels sub-TLV [RFC6326bis] for X. If multiple RBridges indicate that they are Pull Directory Servers for a particular Data Label, pull requests can be sent to any one or more of them that are data reachable but it is RECOMMENDED that pull requests be preferentially sent to the server or servers that are lower cost from the requesting RBridge. Pull Directory requests are sent by enclosing them in an RBridge Channel [Channel] message using the Pull Directory channel protocol number (see Section 8.2). Responses are returned in an RBridge Channel message using the same channel protocol number. The requests to Pull Directory Servers are typically derived from normal ARP [RFC826], ND [RFC4861], RARP [RFC903] messages or data frames with unknown unicast destination MAC addresses intercepted by the RBridge as described in Section 4. Pull Directory responses include an amount of time for which the response should be considered valid. This includes negative responses that indicate no data is available. Thus both positive responses with data and negative responses can be cached and used for immediate response to ARP, ND, RARP, or unknown destination MAC frames, until they expire. If information previously pulled is about to expire, an RBridge MAY try to refresh it by issued a new pull request but, to avoid unnecessary requests, SHOULD NOT do so if it has not been recently used. 3.1 Pull Directory Request Format A Pull Directory request is sent as the Channel Protocol specific content of an inter-RBridge Channel message [Channel] TRILL Data packet. The Data Label in the packet is the Data Label in which the query is being made. The priority of the channel message is a mapping of the priority of the frame being ingressed that caused the request with the default mapping depending, per Data Label, on the strategy (see Section 6). The Channel Protocol specific data is formatted as follows: L. Dunbar, et al [Page 12] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | T | RESV | Count | RESV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUERY 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | QUERY 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | QUERY K +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... V: Version of the Pull Directory protocol as an unsigned integer. Version zero is specified in this document. T: Type. 0 => Response, 1=> Query, 2=> Unsolicited Update, 3=> Reserved. An unsolicited update is formatted as a response except there is no corresponding query. Messages received with type = 3 are discarded. Queries received by an RBridge that is not a Pull Directory are discarded. Responses that do not match an outstanding Query are discarded. RESV: Reserved bits. MUST be sent as zero and ignored on receipt. Count: Number of queries present. Sequence Number: A 32-bit quantity set by the sending RBridge, returned in any responses, and used to match up responses with queries. It is opaque except that the value zero is reserved for Unsolicited Update response messages. A Request received with Sequence Number zero is discarded. QUERY: Each Query record within a Pull Directory request message is formatted as follows: L. Dunbar, et al [Page 13] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | SIZE | RESV | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ If TYPE = 1 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | AFN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Query address ... +--+--+--+--+--+--+--+--+--+--+--... If TYPE = 2, 3, 4, or 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Query frame ... +--+--+--+--+--+--+--+--+--+--+--... SIZE: Size of the query data in bytes as an unsigned byte starting with and including the SIZE field itself. Thus the minimum legal value is 2. A value of SIZE less than 2 indicates a malformed message. The "QUERY" with the illegal SIZE value and all subsequent QUERYs MUST be ignored and the entire query message MAY be ignored. RESV: A block of reserved bits. MUST be sent as zero and ignored on receipt. TYPE: There are two types of queries currently defined, (1) a query that provides an explicit address and asks for other addresses for the interface specified by the query address and (2) a query that includes a frame. The fields of each are specified below. Values of TYPE are as follows TYPE Description ---- ----------- 0 reserved 1 query address 2 ARP query frame 3 ND query frame 4 RARP query frame 5 Unknown unicast MAC query frame 6-14 assignable by IETF Review 15 reserved AFN: Address Family Number of the query address. Query Address: The query is asking for any other addresses, and the RBridge from which they are reachable, that correspond to the same interface, within the data label of the query. Typically that would be either (1) a MAC address with the querying RBridge primarily interested in the RBridge by which that MAC address is reachable, or L. Dunbar, et al [Page 14] INTERNET-DRAFT TRILL: Directory Assist Mechanisms (2) an IP address with the querying RBridge interested in the corresponding MAC address and the RBridge by which that MAC address is reachable. But it could be some other address type. Query Frame: Where a Pull Directory query is the result of an ARP, ND, RARP, or unknown unicast MAC destination address, the ingress RBridge MAY send the frame to a Pull Directory Server if the frame is small enough to fit into a query message. A query count of zero is explicitly allowed, for the purpose of pinging a Pull Directory server to see if it is responding to requests. On receipt of such an empty query message, a response message that also has a count of zero MUST be sent unless inhibited by rate limiting. If no response is received to a Pull Directory request within a timeout configurable in milliseconds that defaults to 2,000, the request should be re-transmitted with the same Sequence Number up to a configurable number of times that defaults to three. If there are multiple queries in a request, responses can be received to various subsets of these queries by the timeout. In that case, the remaining unanswered queries should be re-sent in a new query with a new sequence number. If an RBridge is not capable of handling partial responses to requests with multiple queries, it MUST NOT sent a request with more than one query in it. 3.2 Pull Directory Response Format Pull Directory responses are sent as the Channel Protocol specific content of inter-RBridge Channel message TRILL Data packets. Responses are sent with the same Data Label and priority as the request to which they correspond except that the response priority is limited to be not more than a configured value. This priority limit is configurable at a per RBridge level and defaults to priority 6. The Channel protocol specific data format is as follows: L. Dunbar, et al [Page 15] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | T |F|P|N| RESV| Count | ERR | subERR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESPONSE 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | RESPONSE 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | RESPONSE K +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... V, T: Version and Type as specified in Section 3.1. F: The Flood bit. If zero, the reply is to be unicast to the provided Nickname. If T=2, F=1 is used to flood messages for certain unsolicited update cache consistency maintenance messages from an end station Pull Directory server as discussed in Section 3.5. If T is not 2, F is ignored. P, N: Flags used in connection with certain flooded unsolicited cache consistency maintenance messages. Ignored if T is not 2. If the P bit is a one, the solicited response message relates to cached positive response information. If the N bit is a one, the unsolicited message relates to cached negative information. See Section 3.5. RESV: Reserved bits. MUST be sent as zero and ignored on receipt. Count: Count is the number of responses present in the particular response message. ERR, subERR: A two part error code. See Section 3.4. Sequence Number: A 32-bit quantity set by the sending RBridge, returned in any responses, and used to match up responses with queries. It is opaque except that the value zero is reserved for Unsolicited Update response messages. RESPONSE: Each response record within a Pull Directory response message is formatted as follows: L. Dunbar, et al [Page 16] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | SIZE | RESV | Index | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Lifetime | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Response Data ... +--+--+--+--+--+--+--+--+--+--+--... SIZE: Size of the response data in bytes starting with and including the SIZE field itself. Thus the minimum value of SIZE is 6. If SIZE is less than 6, that RESPONSE and all subsequent RESPONSEs MUST be ignored. RESV: Four reserved bits that MUST be sent as zero and ignored on receipt. Index: The relative index of the query in the request message to which this response corresponds. The index will always be one for request messages containing a single query. The index will always be zero for unsolicited update "response" messages. Lifetime: The length of time for which the response should be considered valid in seconds. If zero, the response can only be used for the particular query from which it resulted. The maximum time that can be expressed is just over 18.2 hours. [Perhaps this should be in units of, say, 200 milliseconds?] Response Data: There are two types of response data. If the ERR field is non-zero, the response data is a copy of the query data, that is, either an AFN followed by an address or a query frame. If the ERR field is zero, the response data is the contents of an Interface Addresses APPsub-TLV (see Section 5) without the usual TRILL GENINFO TLV type and length and without the usual IA APPsub-TLV type and length before it. The maximum size of such contents is 251 bytes in the case when SIZE is 255. Multiple response records can appear in a response message with the same index if the answer to a query consists of multiple Interface Address APPsub-TLV contents. This would be necessary if, for example, a MAC address within a Data Label appears to be reachable by multiple RBridges. However, all RESPONSE records to any particular QUERY record MUST occur in the same response message. If a Pull Directory holds more mappings for a queried address than will fit into one response message, it selects which to include by some method outside the scope of this document. L. Dunbar, et al [Page 17] INTERNET-DRAFT TRILL: Directory Assist Mechanisms See Section 3.4 for a discussion of how errors are handled. 3.3 Pull Directory Hosted on an End Station Optionally, a Pull Directory actually hosted on an end station MAY be supported. In that case, when the RBridge advertising itself as a Pull Directory server receives a query, it modifies the inter-RBridge Channel message received into a native RBridge Channel message and forwards it to that end station. Later, when it receives one or more responses from that end station by native RBridge Channel messages, it modifies them into inter-RBridge Channel messages and forwards them to the source RBridge of the query. The native Pull Directory RBridge Channel messages use the same Channel protocol number as do the inter-RBridge Pull Directory RBridge Channel messages. The native messages MUST be sent with an Outer.VLAN tag which gives the priority of each message which is the priority of the original inter-RBridge request packet. The Outer.VLAN ID used is the Designated VLAN on the link. The native RBridge Channel message protocol dependent data for a Pull Directory query is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | T | RESV | Count | Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Label ... (4 or 8 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUERY 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | QUERY 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | QUERY K +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Data Label: The Data Label of the original inter-RBridge Pull Directory Channel protocol messages that was mapped to this native channel message. The format is the same as it appears right after the Inner.MacSA of the original Channel message. Nickname: The nickname of the RBridge sending the original inter- RBridge Pull Directory query. L. Dunbar, et al [Page 18] INTERNET-DRAFT TRILL: Directory Assist Mechanisms All other fields, including the fields within the QUERY records are as specified in Section 3.1. The native RBridge Channel message protocol specific content for a Pull Directory response is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | T |F|P|N| RESV| Count | ERR | subERR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Label ... (4 or 8 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESPONSE 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | RESPONSE 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | RESPONSE K +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Nickname: If F=0, the nickname of the ultimate destination RBridge. If F=1, ignored. Data Label: The Data Label to which the response applies. The format is the same as it appears right after the Inner.MacSA in TRILL Data messages. All other fields, including the fields within the RESPONSE records, are as specified in Section 3.2. 3.4 Pull Directory Request Errors An error response message is indicated by a non-zero ERR field. If there is an error that applies to an entire request message or its header, as indicated by the range of the value of the ERR field, then the query records in the request are just echoed back in the response records but expanded with a zero Lifetime and the insertion of the Index field. If errors occur at the query level, they MUST be reported in a response message separate from the results of any successful queries. L. Dunbar, et al [Page 19] INTERNET-DRAFT TRILL: Directory Assist Mechanisms If multiple queries in a request have different errors, they MUST be reported in separate response messages. If multiple queries in a request have the same error, this error response MAY be reported in one response message. In an error response message, the query or queries being responded to appear, expanded by the Lifetime for which the server thinks the error might persist and with their Index inserted, as the RESPONSE record. ERR values 1 through 127 are available for encoding request message level errors. ERR values 128 through 254 are available for encoding query level errors. the SubErr field is available for providing more detail on errors. The meaning of a SubErr field value depends on the value of the ERR field. ERR Meaning --- ------- 0 (no error) 1 Unknown or reserved field value 2 Request data too short 3-127 (Available for allocation by IETF Review) 128 Unknown AFN 129 Address not found 130-254 (Available for allocation by IETF REview) 255 Reserved The following sub-errors are specified under error code 1: SubERR Field with Error ------ ---------------- 0 Unspecified 1 Unknown V field value 2 Reserved T field value 3 Zero sequence number in request 4-254 (Available for allocation by IETF Review) 255 Reserved More TBD 3.5 Cache Consistency Pull Directories MUST take action to minimize the amount of time that an RBridge will continue to use stale information from the Pull Directory. L. Dunbar, et al [Page 20] INTERNET-DRAFT TRILL: Directory Assist Mechanisms A Pull Directory server MUST maintain one of the following, in order of increasing specificity. Retaining more specific records, such as that given in item 3 below, minimizes spontaneous response messages sent to update pull client RBridge caches. Retaining less specific records, such as that given in item 1, will generally increase the volume and overhead due to spontaneous response messages but still maintain consistency. 1. An overall record per Data Label of when the last positive response data will expire at a requester and when the last negative response will expire. 2. For each unit of data (IA APPsub-TLV Address Set [IA]) held by the server and each address about which a negative response was sent, when the last expected response with that data or negative response will expire at a requester. 3. For each unit of data held by the server and each address about which a negative response was sent, a list of RBridges that were sent that data as the response or sent a negative response for the address, with the expected time to expiration at each of them. A Pull Directory server may have a limit as to how many RBridges it can maintain expiry information for by method 3 above or how many data units or addresses it can maintain expiry information for by method 2. If such limits are exceeded, it MUST transition to a lower numbered strategy but, in all cases, MUST support, at a minimum, method 1. When data at a Pull Directory changes or is deleted or data is added and there may be unexpired stale information at a requesting RBridge, the Pull Directory MUST send an unsolicited message as discussed below. If method 1, the most crude method, is being followed, then when any Pull Directory information in a Data Label is changed or deleted and there are outstanding cached positive data response(s), an all- addresses flush positive message is flooded (multicast) within that Data Label. And if data is added and there are outstanding cached negative responses, an all-addresses flush negative message is flooded. "All-addresses" is indicated by the Count in an unsolicited response being zero. On receiving an all-addresses flooded flush positive message from a Pull Directory server it has used, indicated by the U, F, and P bits being one, an RBridge discards all cached data responses it has for that Data Label. Similarly, on receiving an all addresses flush negative message, indicated by the U, F, and N bits being one, it discards all cached negative responses for that Data Label. A combined flush positive and negative can be flooded by having all of the U, F, P, and N bits set to one resulting in the L. Dunbar, et al [Page 21] INTERNET-DRAFT TRILL: Directory Assist Mechanisms discard of all positive and negative cached information for the Data Label. If method 2 is being followed, then an RBridge floods address specific unsolicited update positive responses when data which is cached by a querying RBridge is changed or deleted and floods an address specific unsolicited update negative response when such information is added to. Such messages are similar to the method 1 flooded unsolicited flush messages. The U and F bits will be one and the message will be multicast. However that Count field will be non- zero and either the P or N bit, but not both, will be one. On receiving such as address specific message, if it is positive the addresses in the response records in the unsolicited response are compared to the addresses about which the recipient RBridge is holding cached positive or negative information and, if they match, the cached information is updated or the negative information replaced with the new positive information. On receiving an address specific unsolicited update negative response, the addresses in the response records in the unsolicited response are compared to the addresses about which the recipient RBridge is holding cached positive or negative information and, if they match, the any cached positive information is discarded. If method 3 is being followed, the same sort of unsolicited update messages are sent as with method 2 except they are not normally flooded but unicast only to the specific RBridges the server believes may be holding the cached positive or negative information that may need updating. However, the Pull Directory server MAY flood the unsolicited update, for example if it determines that a sufficiently large fraction of its requesters need to be updated. 3.6 Additional Pull Details If an RBridge notices that a Pull Directory server is no longer data reachable [RFCclear], it MUST discard all pull responses it is retaining from that server as the RBridge can no longer receive cache consistency messages from the server. Because a Pull Directory server may need to advertise interest in Data Labels even though it does not want to received end station data in those Data Labels, the No Data flag bit is provided as specified in Section 8.3. L. Dunbar, et al [Page 22] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 4. Events That May Cause Directory Use An RBridge can consult Directory information whenever it wants, by (1) searching through information that has been retained after being pushed to it or pulled by it or (2) by requesting information from a Pull Directory. However, the following are expected to be the most common circumstances leading to directory information use. All of these are cases of ingressing (or originating) a native frame. Support for each of the uses below is separately optional. 4.1 Forged Native Frame Ingress End stations can forge the source MAC and/or IP address in a native frame that an edge TRILL switch receives for ingress in some particular Data Label. If there is complete Directory information as to what end stations should be reachable by an egress TRILL switch or a port on such a TRILL switch, frames with forged source addresses SHOULD be discarded. If such frames are discarded, then none of the special processing in the remaining subsection of this Section 2 occur and MAC address learning (see [RFC6325] Section 4.8) SHOULD NOT occur. ("SHOULD NOT" is chosen because it is harmless in cases where it has no effect. For example, if complete directory information is available and such directory information is treated as having a higher confidence that MAC addresses learned from the data plane.) 4.2 Unknown Destination MAC Ingressing a native frame with an unknown unicast destination MAC: The mapping from the destination MAC and Data Label to the egress TRILL switch from which it is reachable is needed to ingress the frame as unicast. If the egress RBridge is unknown, the frame must be either dropped or ingressed as a multi-destination frame which is flooded to all edge RBridges for its Data Label resulting in increased link utilization compared with unicast routing. Depending on the configuration of the TRILL switch ingressing the native frame (see Section 6), directory information can be used for the { destination MAC, Data Label } to egress TRILL switch nickname mapping and destination MACs for which such direction information is not available MAY be discarded. L. Dunbar, et al [Page 23] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 4.3 Address Resolution Protocol (ARP) Ingressing an ARP [RFC826]: ARP is a flexible protocol. It is commonly used on a link to query for the MAC address corresponding to an IPv4 address, test if an IPv4 address is in use, or to announce a change in any of IPv4 address, MAC address, and/or point of attachment. The logically important elements in an ARP are (1) the specification of a "protocol" and a "hardware" address type, (2) an operation code that can be Request or Reply, and (3) fields for the protocol and hardware address of the sender and the target (destination) node. Examining the three types of ARP use: 1. General ARP Request / Response This is a request for the destination "hardware" address corresponding to the destination "protocol" address; however, if the source and destination protocol addresses are equal, it should be handled as in type 2 below. A general ARP is handled by doing a directory lookup on the destination "protocol" address provided in hops of finding a mapping to the desired "hardware" address. If such information is obtain from a directory, a response can be synthesized. 2. Gratuitous ARP A request used by a host to announce a new IPv4 address, new MAC address, and/or new point of network attachment. Identifiable because the sender and destination "protocol" address fields have the same value. Thus, under normal circumstances, there really isn't any separate destination host to generate a response. If complete Push Directory information is being used with the Notify flag set in the IA APPsub-TLVs being pushed [IA] by all the RBridge in the Data Label, then gratuitous ARPs SHOULD be discarded rather the ingressed. Otherwise, they are either ingressed and flooded or discarded depending on local policy. 3. Address Probe ARP Query An address probe ARP is used to determine if an IPv4 address is in use [RFC5227]. It can be identified by the source "protocol" (IPv4) address field being zero. The destination "protocol" address field is the IPv4 address being tested. If some host believes it has that destination IPv4 address, it would respond to the ARP query, which indicates that the address is in use. Address probe ARPs can be handled the same as General ARP queries. L. Dunbar, et al [Page 24] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 4.4 IPv6 Neighbor Discovery (ND) Ingressing an IPv6 ND [RFC4861]: TBD Secure Neighbor Discovery messages [RFC3971] will, in general, have to be sent to the neighbor intended so that neighbor can sign the answer; however, directory information can be used to unicast a Secure Neighbor Discovery packet rather than multicasting it. 4.5 Reverse Address Resolution Protocol (RARP) Ingressing a RARP [RFC903]: RARP uses the same packet format as ARP but different Ethertype and opcode values. Its use is similar to the General ARP Request/Response as described above. The difference is that it is intended to query for the destination "protocol" address corresponding to the destination "hardware" address provided. It is handled by doing a directory lookup on the destination "hardware" address provided in hops of finding a mapping to the desired "protocol" address. For example, looking up a MAC address to find the corresponding IP address. L. Dunbar, et al [Page 25] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 5. Layer 3 Address Learning TRILL switches MAY learn IP addresses in a manner similar to that in which they learn MAC addresses. On ingress of a native IP frame, they can learn the { IP address, MAC address, Data Label, input port } set and on the egress of a native IP frame, they can learn the { IP address, MAC address, Data Label, remote RBridge } information plus the nickname of the RBridge that ingressed the frame. This locally learned information is retained and times out in a similar manner to MAC address learning specified in [RFC6325]. By default, it has the same Confidence as locally learned MAC reachability information. Such learned Layer 3 address information MAY be disseminated with [ESADI] using the IA APPsub-TLV [IA]. It can also be used as, in effect, local directory information to assist in locally responding to ARP/ND packets as discussed in Section 4. L. Dunbar, et al [Page 26] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 6. Directory Use Strategies and Push-Pull Hybrids For some edge nodes which have a great number of Data Labels enabled, managing the MAC and Data Label <-> EdgeRBridge mapping for hosts under all those Data Labels can be a challenge. This is especially true for Data Center gateway nodes, which need to communicate with a majority of Data Labels if not all. For those RBridge Edge nodes, a hybrid model should be considered. That is the Push Model is used for some Data Labels, and the Pull Model is used for other Data Labels. It is the network operator's decision by configuration as to which Data Labels' mapping entries are pushed down from directories and which Data Labels' mapping entries are pulled. For example, assume a data center when hosts in specific Data Labels, say VLANs 1 through 100, communicate regularly with external peers, the mapping entries for those 100 VLANs should be pushed down to the data center gateway routers. For hosts in other Data Labels which only communicate with external peers occasionally for management interface, the mapping entries for those VLANs should be pulled down from directory when the need comes up. The mechanisms described above for Push and Pull Directory services make it easy to use Push for some Data Labels and Pull for others. In fact, different RBridges can even be configured so that some use Push Directory services and some use Pull Directory services for the same Data Label if both Push and Pull Directory services are available for that Data Label. And there can be Data Labels for which directory services are not used at all. For Data Labels in which a hybrid push/pull approach is being taken, it would make sense to use push for address information of hosts that frequently communicate with many other hosts in the Data Label, such as a file or DNS server. Pull could then be used for hosts that communicate with few other hosts, perhaps such as hosts being used as compute engines. 6.1 Strategy Configuration Each RBridge that has the ability to use directory assistance has, for each Data Label X in which it is might ingress native frames, one of four major modes: 0. No directory use. The RBridge does not subscribe to Push Directory data or make Pull Directory requests for Data Label X and directory data is not consulted on ingressed frames in Data Label X that might have used directory data. This includes ARP, L. Dunbar, et al [Page 27] INTERNET-DRAFT TRILL: Directory Assist Mechanisms ND, RARP, and unknown MAC destination addresses, which are flooded. 1. Use Push only. The RBridge subscribes to Push Directory data for Data Label X. 2. Use Pull only. When the RBridge ingresses a frame in Data Label X that can use Directory information, if it has cached information for the address it uses it. If it does not have either cached positive or negative information for the address, it sends a Pull Directory query. 3. Use Push and Pull. The RBridge subscribes to Push Directory data for Data Label X. When it ingresses a frame in Data Label X that can use Directory information and it does not find that information in its link state database of Push Directory information, it makes a Pull Directory query. The above major Directory use mode is per Data Label. In addition, there is a per Data Label per priority minor mode as listed below that indicates what should be done if Directory Data is not available for the ingressed frame. In all cases, if you are holding Push Directory or Pull Directory information to handle the frame given the major mode, the directory information is simply used and, in that instance, the minor modes does not matter. A. Flood immediate. Flood the frame immediately (even if you are also sending a Pull Directory) request. B. Flood. Flood the frame immediately unless you are going to do a Pull Directory request, in which case you wait for the response or for the request to time out after retries and flood the frame if the request times out. C. Discard if complete or Flood immediate. If you have complete Push Directory information and the address is not in that information, discard the frame. If you do not have complete Push Directory information, the same as A above. D. Discard if complete or Flood. If you have complete Push Directory information and the address is not in that information, discard the frame. If you do not have complete Push Directory information, the same as B above. In addition, the query message priority for Pull Directory requests sent can be configured on a per Data Label, per ingressed frame priority basis. The default mappings are as follows where Ingress Priority is the priority of the native frame that provoked the Pull Directory query: L. Dunbar, et al [Page 28] INTERNET-DRAFT TRILL: Directory Assist Mechanisms Ingress If Flood If Flood Priority Immediate Delayed -------- --------- -------- 7 5 6 6 5 6 5 4 5 4 3 4 3 2 3 2 0 2 0 1 0 1 1 1 Priority 7 is normally only used for urgent messages critical to adjacency and so is avoided by default for directory traffic. L. Dunbar, et al [Page 29] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 7. Security Considerations Push Directory data is distributed through ESADI-LSPs [ESADI] which can be authenticated with the same mechanisms as IS-IS LSPs. See [RFC5304] [RFC5310] and the Security Considerations section of [ESADI]. Pull Directory queries and responses are transmitted as RBridge-to- RBridge or native RBridge Channel messages. Such messages can be secured as specified in [ChannelTunnel]. For general TRILL security considerations, see [RFC6325]. L. Dunbar, et al [Page 30] INTERNET-DRAFT TRILL: Directory Assist Mechanisms 8. IANA Considerations This section give IANA allocation and registry considerations. 8.1 ESADI-Parameter Data IANA is request to allocate two ESADI-Parameter TRILL APPsub-TLV flag bits for "Push Directory" (PD) and "Complete Push" (CP) and to create a sub-registry in the TRILL Parameters Registry as follows: Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits Registration Procedures: Expert Review References: [ESADI], This document Bit Mnemonic Description Reference --- -------- ----------- --------- 0 UN Supports Unicast ESADI [ESADI] 1 PD Push Directory Server This document 2 CP Complete Push This document 3-7 - available for allocation The CP bit is ignored if the PD bit is zero. In addition, the ESADI-Parameter APPsub-TLV is optionally extended, as provided in its original specification in [ESADI], by one byte as show below: +-+-+-+-+-+-+-+-+ | Type | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ |R| Priority | (1 byte) +-+-+-+-+-+-+-+-+ | CSNP Time | (1 byte) +-+-+-+-+-+-+-+-+ | Flags | (1 byte) +---------------+ |PushDirPriority| (optional, 1 byte) +---------------+ | Reserved for expansion (variable) +-+-+-+-... The meanings of all the fields are as specified in [ESADI] except that the added PushDirPriority is the priority of the advertising ESADI instance to be a Push Directory as described in Section 2.3. If L. Dunbar, et al [Page 31] INTERNET-DRAFT TRILL: Directory Assist Mechanisms the PushDirPriority field is not present (Length = 3) it is treated as if it were 0x40. 0x40 is also the value used and placed here by an RBridge priority to be a Push Directory has not been configured. 8.2 RBridge Channel Protocol Number IANA is requested to allocate a new RBridge Channel protocol number for "Pull Directory Services" from the range allocable by Standards Action and update the table of such protocol number in the TRILL Parameters Registry referencing this document. 8.3 The Pull Directory and No Data Bits IANA is requested to allocate two currently reserved bits in the Interested VLANs field of the Interested VLANs sub-TLV (suggested bits 18 and 19) and the Interested Labels field of the Interested Labels sub-TLV (suggested bits 6 and 7) [RFC6326bis] to indicate Pull Directory server (PD) and No Data (ND) respectively. These bits are to be added to the subregistry created by [ESADI] with this document as reference. In the TRILL base protocol [RFC6325] as extended for FGL [rfcFGL], the mere presence of an Interested VLANs or Interested Labels sub- TLVs in the LSP of an RBridge indicates connection to end stations in the VLANs or FGLs listed and thus a desire to receive multi- destination traffic in those Data Labels. But, with Push and Pull Directories, advertising that you are a directory server requires using these sub-TLVs for the Data Label you are serving. If such a directory server does not wish to received multi-destination TRILL Data packets for the Data Labels it lists in one of these sub-TLVs, it sets the "No Data" (ND) bit to one. This means that data on a distribution tree may be pruned so as not to reach the "No Data" RBridge as long as there are no RBridges interested in the Data who are beyond the "No Data" RBridge. This bit is backwards compatible as RBridges ignorant of it will simply not prune when they could, which is safe although it may cause increased link utilization. An example of as RBridge serving as a directory that would not want multi-destination traffic in some Data Labels might be an RBridge that does not officer end station service for any of the Data Labels for which it is serving as a directory and is either (1) a Pull Directory or (2) a Push Directory for which all of the ESADI traffic can be handled by unicast [ESADI]. L. Dunbar, et al [Page 32] INTERNET-DRAFT TRILL: Directory Assist Mechanisms Acknowledgments The contributions of the following persons are gratefully acknowledged: TBD The document was prepared in raw nroff. All macros used were defined within the source file. Normative References [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, November 1982. [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, June 1984 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008. [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. [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. [RFC5342bis] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008. [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and L. Dunbar, et al [Page 33] INTERNET-DRAFT TRILL: Directory Assist Mechanisms A. Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-rfc6326bis, work in progress. [RFCclear] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, A. Banerjee, draft-ietf-trill-clear-correct-06.txt, in RFC Editor's queue. [Channel] - D. Eastlake, V. Manral, Y. Li, S. Aldrin, D. Ward, "TRILL: RBridge Channel Support", draft-ietf-trill-rbridge- channel-08.txt, in RFC Editor's queue. [RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine- labeling-07.txt, in RFC Editor's queue. [ESADI] - Zhai, H., F. Hu, R. Perlman, D. Eastlake, O. Stokes, "TRILL (Transparent Interconnection of Lots of Links): The ESADI (End Station Address Distribution Information) Protocol", draft-ietf-trill-esadi, work in progress. [IA] - Eastlake, D., L. Yizhou, R. Perlman, "TRILL: Interface Addresses APPsub-TLV", draft-eastlake-trill-ia-appsubtlv, work in progress. Informational References [RFC5227] - Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, July 2008. [DirectoryFramework] - Dunbar, L., D. Eastlake, R. Perlman, I. Gashinsky, "TRILL Edge Directory Assistance Framework", draft-ietf-trill-directory-framework, in RFC Editor's queue. [ChannelTunnel] - D. Eastlake, Y. Li, "TRILL: RBridge Channel Tunnel Protocol", draft-eastlake-trill-channel-tunnel, work in progress. [ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large Data Centers", Oct 2010. L. Dunbar, et al [Page 34] INTERNET-DRAFT TRILL: Directory Assist Mechanisms Authors' Addresses Linda Dunbar Huawei Technologies 5430 Legacy Drive, Suite #175 Plano, TX 75024, USA Phone: (469) 277 5840 Email: ldunbar@huawei.com Donald Eastlake Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: 1-508-333-2270 Email: d3e3e3@gmail.com Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA Phone: +1-408-765-8080 Email: Radia@alum.mit.edu Igor Gashinsky Yahoo 45 West 18th Street 6th floor New York, NY 10011 Email: igor@yahoo-inc.com Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China Phone: +86-25-56622310 Email: liyizhou@huawei.com L. Dunbar, et al [Page 35] INTERNET-DRAFT TRILL: Directory Assist Mechanisms Copyright, Disclaimer, and Additional IPR Provisions Copyright (c) 2013 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. L. Dunbar, et al [Page 36]