diff options
Diffstat (limited to 'doc/rfc/rfc8171.txt')
| -rw-r--r-- | doc/rfc/rfc8171.txt | 3083 |
1 files changed, 3083 insertions, 0 deletions
diff --git a/doc/rfc/rfc8171.txt b/doc/rfc/rfc8171.txt new file mode 100644 index 0000000..29e84aa --- /dev/null +++ b/doc/rfc/rfc8171.txt @@ -0,0 +1,3083 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Eastlake 3rd +Request for Comments: 8171 L. Dunbar +Category: Standards Track Huawei +ISSN: 2070-1721 R. Perlman + EMC + Y. Li + Huawei + June 2017 + + + Transparent Interconnection of Lots of Links (TRILL): + Edge Directory Assistance Mechanisms + +Abstract + + This document describes mechanisms for providing directory service to + TRILL (Transparent Interconnection of Lots of Links) edge switches. + The directory information provided can be used in reducing multi- + destination traffic, particularly ARP / Neighbor Discovery (ND) and + unknown unicast flooding. It can also be used to detect traffic with + forged source addresses. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8171. + + + + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 1] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +Copyright Notice + + Copyright (c) 2017 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. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Uses of Directory Information ..............................5 + 1.2. Terminology ................................................6 + 2. Push Model Directory Assistance Mechanisms ......................7 + 2.1. Requesting Push Service ....................................7 + 2.2. Push Directory Servers .....................................8 + 2.3. Push Directory Server State Machine ........................9 + 2.3.1. Push Directory States ...............................9 + 2.3.2. Push Directory Events and Conditions ...............11 + 2.3.3. State Transition Diagram and Table .................13 + 2.4. End Stations and Push Directories .........................15 + 2.5. Additional Push Details ...................................15 + 2.6. Providing Secondary Servers with Data from a + Primary Server ............................................16 + 2.7. Push Directory Configuration ..............................17 + 3. Pull Model Directory Assistance Mechanisms .....................17 + 3.1. Pull Directory Message: Common Format .....................19 + 3.1.1. Version Negotiation ................................20 + 3.2. Pull Directory Query and Response Messages ................21 + 3.2.1. Pull Directory Query Message Format ................21 + 3.2.2. Pull Directory Responses ...........................24 + 3.2.2.1. Pull Directory Response Message Format ....24 + 3.2.2.2. Pull Directory Forwarding .................27 + 3.3. Cache Consistency .........................................28 + 3.3.1. Update Message Format ..............................32 + 3.3.2. Acknowledge Message Format .........................33 + 3.4. Summary of Record Formats in Messages .....................34 + + + + + + + +Eastlake, et al. Standards Track [Page 2] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + 3.5. End Stations and Pull Directories .........................34 + 3.5.1. Pull Directory Hosted on an End Station ............35 + 3.5.2. Use of Pull Directory by End Stations ..............36 + 3.5.3. Native Pull Directory Messages .....................37 + 3.6. Pull Directory Message Errors .............................38 + 3.6.1. Error Codes ........................................39 + 3.6.2. Sub-errors under Error Codes 1 and 3 ...............39 + 3.6.3. Sub-errors under Error Codes 128 and 131 ...........40 + 3.7. Additional Pull Details ...................................40 + 3.8. The "No Data" Flag ........................................40 + 3.9. Pull Directory Service Configuration ......................42 + 4. Directory Use Strategies and Push-Pull Hybrids .................42 + 5. TRILL ES-IS ....................................................44 + 5.1. PDUs and System IDs .......................................45 + 5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs .......46 + 5.3. Link State ................................................47 + 6. Security Considerations ........................................47 + 6.1. Directory Information Security ............................47 + 6.2. Directory Confidentiality and Privacy .....................47 + 6.3. Directory Message Security Considerations .................48 + 7. IANA Considerations ............................................48 + 7.1. ESADI-Parameter Data Extensions ...........................48 + 7.2. RBridge Channel Protocol Numbers ..........................49 + 7.3. The Pull Directory (PUL) and No Data (NOD) Bits ...........49 + 7.4. TRILL Pull Directory QTYPEs ...............................50 + 7.5. Pull Directory Error Code Registries ......................50 + 7.6. TRILL-ES-IS MAC Address ...................................51 + 8. References .....................................................51 + 8.1. Normative References ......................................51 + 8.2. Informative References ....................................54 + Acknowledgments ...................................................55 + Authors' Addresses ................................................55 + + + + + + + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 3] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +1. Introduction + + [RFC7067] gives a problem statement and high-level design for using + directory servers to assist TRILL [RFC6325] [RFC7780] edge nodes in + reducing multi-destination ARP / Neighbor Discovery (ND) [ARPND], + reducing unknown unicast flooding traffic, and improving security + against address spoofing within a TRILL campus. Because + multi-destination traffic becomes an increasing burden as a network + scales up in number of nodes, reducing ARP/ND and unknown unicast + flooding improves TRILL network scalability. This document describes + specific mechanisms for TRILL directory servers. + + The information held by the directory or directories is address + mapping and reachability information -- most commonly, what MAC + (Media Access Control) address [RFC7042] corresponds to an IP address + within a Data Label (VLAN or FGL (Fine-Grained Label) [RFC7172]) and + the egress TRILL switch (RBridge), and, optionally, what specific + port on that TRILL switch, from which that MAC address is reachable. + But it could be what IP address corresponds to a MAC address or + possibly other address mapping or reachability information. + + The mechanism used to initially populate directory data in primary + servers is beyond the scope of this document. A primary server can + use the Push Directory service to provide directory data to secondary + servers, as described in Section 2.6. 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 can be + appropriate for providing the directory function or for supplying the + directory or directories with directory information. + + Efficient routing of unicast traffic in a TRILL campus assumes that + the mapping of destination MAC addresses to edge RBridges is stable + enough that the default data-plane learning of TRILL and/or the use + of directories reduces to an acceptable level the need to flood + packets where the location of the destination is unknown. Although + not prohibited, "ephemeral" MAC addresses are unlikely to be used in + such an environment. Directories need not be complete, and in the + case that any ephemeral MAC addresses were in use, they would + probably not be included in directory information. + + Directory services can be offered in a Push Mode, Pull Mode, or both + [RFC7067] at the discretion of the server. 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. More detail on modes of operation, including hybrid + Push/Pull, are provided in Section 4. + + + +Eastlake, et al. Standards Track [Page 4] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +1.1. Uses of Directory Information + + A TRILL switch 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) requesting information from a + Pull Directory. However, the following are expected to be the most + common circumstances leading to the use of directory information. + All of these are cases of ingressing (or originating) a native frame. + + 1. ARP requests and replies [RFC826] are normally broadcast. But a + directory-assisted edge TRILL switch could intercept ARP messages + and reply if the TRILL switch has the relevant information + [ARPND]. + + 2. IPv6 ND [RFC4861] requests and replies are normally multicast. + Except in the case of Secure Neighbor Discovery (SEND) [RFC3971], + where possession of the right keying material might be required, a + directory-assisted edge TRILL switch could intercept ND messages + and reply if the TRILL switch has the relevant information + [ARPND]. + + 3. Unknown destination MAC addresses normally cause a native frame to + be flooded. An edge TRILL switch ingressing a native frame + necessarily has to determine if it knows the egress RBridge from + which the destination MAC address of the frame (in the frame's + VLAN or FGL) is reachable. It might have learned that information + from the directory or could query the directory if it does not + know it. Furthermore, if the edge TRILL switch has complete + directory information, it can detect a forged source MAC or IP + address in any native frame and discard the frame if it finds such + a forged address. + + 4. RARP [RFC903] (Reverse ARP) is similar to ARP (item 1 above). + + + + + + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 5] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +1.2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The terminology and abbreviations of [RFC6325] are used herein, along + with the following: + + AFN: Address Family Number + (http://www.iana.org/assignments/address-family-numbers/). + + CSNP Time: Complete Sequence Number Protocol Data Unit (PDU) time. + See ESADI [RFC7357] and Section 7.1 below. + + Data Label: VLAN or FGL. + + ESADI: End Station Address Distribution Information [RFC7357]. + + FGL: Fine-Grained Label [RFC7172]. + + FR: Flood Record flag bit. See Section 3.2.1. + + Host: A physical server or a virtual machine. A host must have a MAC + address and usually has at least one IP address. + + Interested Labels sub-TLV: Short for "Interested Labels and Spanning + Tree Roots sub-TLV" [RFC7176]. + + Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning + Tree Roots sub-TLV" [RFC7176]. + + IP: Internet Protocol. In this document, IP includes both IPv4 + and IPv6. + + MAC address: Media Access Control address [RFC7042]. + + MacDA: Destination MAC address. + + MacSA: Source MAC address. + + OV: Overflow flag bit. See Section 3.2.2.1. + + PDSS: Push Directory Server Status. See Sections 2 and 7.1. + + + + + +Eastlake, et al. Standards Track [Page 6] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + Primary server: A directory server that obtains the information it is + providing by a reliable mechanism designed to assure the freshness + of that information. This mechanism is outside the scope of this + document. (See "Secondary server" below.) + + PUL: Pull Directory flag bit. See Sections 3 and 7.3. + + RBridge: An alternative name for a TRILL switch. + + Secondary server: A directory server that obtains the information it + is providing from one or more primary servers. + + TLV: Type, Length, Value. + + TRILL: Transparent Interconnection of Lots of Links or Tunneled + Routing in the Link Layer. + + TRILL switch: A device that implements the TRILL protocol. + +2. Push Model Directory Assistance Mechanisms + + In the Push Model [RFC7067], one or more Push Directory servers + reside at TRILL switches and "push down" the address mapping + information for the various addresses associated with end-station + interfaces and the TRILL switches from which those interfaces are + reachable [RFC7961]. This service is scoped by Data Label (VLAN or + FGL [RFC7172]). A Push Directory advertises when, for a Data Label, + it is configured to be a directory having complete information and + also has actually pushed all the information it has. It might be + pushing only a subset of the mapping and/or reachability information + for a Data Label. The Push Model uses the ESADI [RFC7357] protocol + as its distribution mechanism. + + With the Push Model, if complete address mapping information for a + Data Label is being pushed, a TRILL switch (RBridge) that has that + complete information and is ingressing a native frame can simply drop + the frame if the destination unicast MAC address can't be found in + the mapping information available, instead of flooding the frame + (ingressing it as an unknown MAC destination TRILL Data frame). But + this will result in lost traffic if the ingress TRILL switch's + directory information is incomplete. + +2.1. Requesting Push Service + + In the Push Model, it is necessary to have a way for a TRILL switch + to subscribe to information from the directory server(s). TRILL + switches simply use the ESADI [RFC7357] protocol mechanism to + announce, in their core IS-IS Link State PDUs (LSPs), the Data Labels + + + +Eastlake, et al. Standards Track [Page 7] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + for which they are participating in ESADI by using the Interested + VLANs sub-TLV [RFC7176] and/or the Interested Labels sub-TLV + [RFC7176]. This will cause the directory information to be pushed to + them for all such Data Labels that are being served by the one or + more Push Directory servers. + +2.2. Push Directory Servers + + Push Directory servers advertise, through ESADI, their availability + to push the mapping information for a particular Data Label by + setting the PDSS in their ESADI-Parameter APPsub-TLV for that ESADI + instance (see [RFC7357] and Section 7.1) to a non-zero value. This + PDSS field setting is visible to other ESADI participants, including + other Push Directory servers, for that Data Label. Each Push + Directory server MUST participate in ESADI for the Data Labels for + which it will push mappings and set the PDSS field in its + ESADI-Parameter APPsub-TLV for that Data Label. For increased + robustness, increased bandwidth capability, and improved locality, it + is useful to have multiple Push Directory servers for each + Data Label. Each Push Directory server is configured with a + number N, which is in the range 1 through 8 and defaults to 2, for + each Data Label for which it can push directory information (see + "PushDirServers" in Section 2.7). If the Push Directory servers for + a Data Label are configured consistently with the same N and at least + N servers are available, then N copies of that directory will be + pushed. + + Each Push Directory server also has a configurable 8-bit priority + (PushDirPriority) to be Active, which defaults to 0x3F (see + Section 2.7). This priority is treated as an unsigned integer, where + the larger magnitude means higher priority. This priority appears in + its ESADI-Parameter APPsub-TLV (see Section 7.1). In the case of a + tie in this configurable priority, the System ID of the TRILL switch + acting as the server is used as a tiebreaker and is treated as an + unsigned 6-byte integer, where the larger magnitude indicates higher + priority. + + For each Data Label it can serve, each Push Directory server checks + to see if there appear to be enough higher-priority servers to push + the desired number of copies. It does this by ordering, by priority, + the Push Directory servers whose advertisements are present in the + ESADI link-state database for that Data Label and that are + data reachable [RFC7780] as indicated by its IS-IS link-state + database. The Push Directory server then determines its own position + in that order. If a Push Directory server's configuration indicates + that N copies of the mappings for a Data Label should be pushed and + the server finds that it is number K in the priority ordering (where + number 1 in the ordered list is highest priority and the last is + + + +Eastlake, et al. Standards Track [Page 8] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + lowest priority), then if K is less than or equal to N, the Push + Directory server is Active. If K is greater than N, it is Stand-By. + Active and Stand-By behavior are specified below in Section 2.3. + + For a Push Directory to reside on an end station, one or more TRILL + switches locally connected to that end station must proxy for the + Push Directory server and advertise themselves in ESADI as Push + Directory servers. It appears to the rest of the TRILL campus that + these TRILL switches (that are proxying for the end station) are the + Push Directory server(s). The protocol between such a Push Directory + end station and the one or more proxying TRILL switches acting as + Push Directory servers is beyond the scope of this document. + +2.3. Push Directory Server State Machine + + The subsections below describe the states, events, and corresponding + actions for Push Directory servers. + + The meanings of possible values of the PDSS field in a Push + Directory's ESADI-Parameter APPsub-TLV are summarized in the table + below. + + PDSS Meaning + ---- ------------------------------------------------------ + 0 Not a Push Directory server + 1 Push Directory server in Stand-By Mode + 2 Push Directory server in Active Mode but not complete + 3 Push Directory server in Active Mode that has pushed + complete data + +2.3.1. Push Directory States + + A Push Directory server is in one of seven states, as listed below, + for each Data Label it can serve. The name of each state is followed + by a symbol that starts and ends with an angle bracket (for example, + "<S1>") and represents the state. The value that the Push Directory + server advertises in the PDSS is determined by the state. In + addition, it has an internal State-Transition-Time variable for each + Data Label it serves that is set at each state transition and that + enables it to determine how long it has been in its current state for + that Data Label. + + + + + + + + + + +Eastlake, et al. Standards Track [Page 9] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + Down <S1>: 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 [RFC7357] with the PDSS field set to 0 + in its ESADI-Parameter APPsub-TLV, or it might not be + participating in ESADI at all. All states other than the Down + state are considered to be Up states and imply a non-zero + PDSS field. + + Stand-By <S2>: No Push Directory data is advertised. Any outstanding + ESADI-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. The Push Directory participates in ESADI [RFC7357] and + advertises its ESADI fragment zero that includes an + ESADI-Parameter APPsub-TLV with the PDSS field set to 1. + + Active <S3>: The Push Directory participates in ESADI [RFC7357] and + advertises its ESADI fragment zero that includes an + ESADI-Parameter APPsub-TLV with the PDSS field set to 2. It also + advertises its directory data and any changes through ESADI + [RFC7357] in its ESADI-LSPs, using the Interface Addresses + APPsub-TLV [RFC7961], and updates that information as it changes. + + Active Completing <S4>: The same behavior as the Active state, except + that the server responds differently to events. The purpose of + this state is to be sure that there has been enough time for + directory information to propagate to subscribing edge TRILL + switches (see "Time Condition", as defined in Section 2.3.2) + before the directory server advertises that the information is + complete. + + Active Complete <S5>: The same behavior as Active, except that the + PDSS field in the ESADI-Parameter APPsub-TLV is set to 3 and the + server responds differently to events. + + Going Stand-By Was Complete <S6>: The same behavior as Active, except + that the server responds differently to events. The purpose of + this state is to be sure that the information indicating that the + directory will no longer be complete has enough time to propagate + to edge TRILL switches (see "Time Condition" in Section 2.3.2) + before the directory server stops advertising updates to the + information. (See note below.) + + Active Uncompleting <S7>: The same behavior as Active, except that it + responds differently to events. The purpose of this state is to + be sure that the information indicating that the directory will no + longer be complete has enough time to propagate to edge TRILL + + + +Eastlake, et al. Standards Track [Page 10] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + switches (see "Time Condition" in Section 2.3.2) before the + directory server might stop advertising updates to the + information. (See note below.) + + Note: It might appear that a Push Directory could transition + directly from Active Complete to Active, since the Active state + continues to advertise updates, eliminating the need for the + Active Uncompleting transition state. But consider the case of + the Push Directory that was complete being configured to be + incomplete and then the Stand-By Condition (see Section 2.3.2) + occurring shortly thereafter. If the first of these two events + caused the server to transition directly to the Active state, + then later, when the Stand-By Condition occurred, it would + immediately transition to Stand-By and stop advertising updates + even though there might not have been enough time for knowledge of + its incompleteness to have propagated to all edge TRILL switches. + + The following table lists each state and its corresponding PDSS + value: + + State PDSS + -------------------------------- ------ + Down <S1> 0 + Stand-By <S2> 1 + Active <S3> 2 + Active Completing <S4> 2 + Active Complete <S5> 3 + Going Stand-By Was Complete <S6> 2 + Active Uncompleting <S7> 2 + +2.3.2. Push Directory Events and Conditions + + Three auxiliary conditions, referenced later in this subsection, are + defined as follows: + + The Activate Condition: In order to have the desired number of Push + Directory servers pushing data for Data Label X, this Push + Directory server should be active. This is determined by the + server finding that (a) it is priority K among the data-reachable + Push Directory servers (where the highest-priority server is 1) + for Data Label X, (b) it is configured that there should be + N copies pushed for Data Label X, and (c) K is less than or equal + to N. For example, the Push Directory server is configured so + that two copies should be pushed and finds that it is priority 1 + or 2 among the Push Directory servers that are visible in its + ESADI link-state database and that are data reachable, as + indicated by its IS-IS link-state database. + + + + +Eastlake, et al. Standards Track [Page 11] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + The Stand-By Condition: In order to have the desired number of Push + Directory servers pushing data for Data Label X, this Push + Directory server should be Stand-By (not Active). This is + determined by the server finding that (a) it is priority K among + the data-reachable Push Directory servers (where the + highest-priority server is 1) for Data Label X, (b) it is + configured that there should be N copies pushed for Data Label X, + and (c) K is greater than N. For example, the Push Directory + server is configured so that two copies should be pushed and finds + that it is priority 3 or lower priority (higher number) among the + available Push Directory servers. + + The Time Condition: The Push Directory server has been in its current + state for a configurable amount of time (PushDirTimer) that + defaults to twice its CSNP (Complete Sequence Number PDU) time + (see Sections 2.7 and 7.1). + + The events and conditions listed below cause state transitions in + Push Directory servers. + + 1. The Push Directory server comes up. + + 2. The Push Directory server or the TRILL switch on which it resides + is being shut down. This is a persistent condition, unless the + shutdown is canceled. So, for example, a Push Directory server in + the Going Stand-By Was Complete state does not transition out of + that state due to this condition but, after (1) the Time Condition + is met and (2) the directory transitions to Stand-By and then + performs the actions required there (such as purging LSPs), + continues to the Down state if this condition is still true. + Similar comments apply to events/conditions 3, 4, and 5. + + 3. The Activate Condition is met, and the server's configuration + indicates that it does not have complete data. + + 4. The Stand-By Condition is met. + + 5. The Activate Condition is met, and the server's configuration + indicates that it has complete data. + + 6. The server's configuration is changed to indicate that it does not + have complete data. + + 7. The Time Condition is met. + + + + + + + +Eastlake, et al. Standards Track [Page 12] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +2.3.3. State Transition Diagram and Table + + The state transition table is as follows: + + | | | | Active | Active | Going | Active +State|Down|Stand-By|Active|Completing|Complete| Stand-By |Uncompleting +-----+ | | | | |Was Complete| +Event|<S1>| <S2> | <S3> | <S4> | <S5> | <S6> | <S7> +-----+----+--------+------+----------+--------+------------+------------ + 1 |<S2>| N/A | N/A | N/A | N/A | N/A | N/A + 2 |<S1>| <S1> | <S2> | <S2> | <S6> | <S6> | <S7> + 3 |<S1>| <S3> | <S3> | <S3> | <S7> | <S3> | <S7> + 4 |<S1>| <S2> | <S2> | <S2> | <S6> | <S6> | <S6> + 5 |<S1>| <S4> | <S4> | <S4> | <S5> | <S5> | <S5> + 6 |<S1>| <S2> | <S3> | <S3> | <S7> | <S6> | <S7> + 7 |<S1>| <S2> | <S3> | <S5> | <S5> | <S2> | <S3> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 13] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + The above state table is equivalent to the following transition + diagram: + + +-----------+ + | Down <S1> |<---------+ + +-----------+ | + |1 ^ | 3,4,5,6,7 | + | | +------------+ + V |2 + +---------------+ + | Stand-By <S2> |<--------------------------------------+ + +---------------+ ^ ^ ^ | + |5 |3 |1,4,6,7 | | | | + | | +---------+ | | | + | V |2,4 | | + | +---------------------+ | | + | | Active <S3> |<---------|-------------+ | + | +---------------------+ ^ | | | + | |5 ^ |1,3,6,7 ^ | | | | + | | | | | | | | | + | | | +---------+ | | | | + | | | | | | | + V V |3,6 | | | | + +------------------------+ | | | | + | Active Completing <S4> |------------+ | | + +------------------------+ 2,4 | | | + |7 |1,5 ^ | | | + | | | | | | + | +-------+ | | | + | | | | + | +------------------------------------+ | | + | | | | | | + V V |7 |5 |3 |7 + +-------------+ 3,6 +----------------+ 4 +----------------+ + | Active |------->| Active |--->| Going Stand-By | + | Complete | | Uncompleting | | Was Complete | + | <S5> |<-------| <S7> | | <S6> | + +-------------+ 5 +----------------+ +----------------+ + |1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^ + | | | | | | | | + +-------+ | +------------+ | +--------+ + | | + +----------------------------------+ + + Figure 1: Push Server State Diagram + + + + + + +Eastlake, et al. Standards Track [Page 14] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +2.4. End Stations and Push Directories + + End-station hosting and end-station use of Push Directories are + outside the scope of this document. Push Directory information + distribution is accomplished using ESADI [RFC7357], which does not + operate to end stations. In the future, ESADI might be extended to + operate to end stations, or some other method, such as BGP, might be + specified as a way to support end-station hosting or end-station use + of Push Directories. + +2.5. Additional Push Details + + Push Directory mappings can be distinguished from other data + distributed through ESADI, because mappings are distributed only with + the Interface Addresses APPsub-TLV [RFC7961] and are flagged in that + APPsub-TLV as being Push Directory data. + + TRILL switches, whether or not they are Push Directory servers, MAY + continue to advertise any locally learned MAC attachment information + in ESADI [RFC7357] using the MAC-Reachability TLV [RFC6165]. + However, if a Data Label is being served by complete Push Directory + servers, advertising such a locally learned MAC attachment generally + SHOULD NOT be done, as it would not add anything and would just waste + bandwidth and ESADI link-state space. An exception might be when a + TRILL switch learns local MAC connectivity and that information + appears to be missing from the directory mapping. + + Because a Push Directory server needs to advertise interest in one or + more Data Labels even though it might not want to receive + multi-destination TRILL Data packets in those Data Labels, the + "No Data" (NOD) flag bit is provided, as discussed in Section 3.8. + + When a Push Directory server is no longer data reachable [RFC7780], + as indicated by the IS-IS link-state database, other TRILL switches + 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 impossible for a TRILL switch receiving Push Directory + information to be absolutely certain that it has complete + information. However, it can obtain a reasonable assurance of + complete information by requiring that two conditions be met: + + 1. The PDSS field is 3 in the ESADI fragment zero from the server for + the relevant Data Label. + + + + + + +Eastlake, et al. Standards Track [Page 15] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + 2. As far as it can tell, it has had continuous data connectivity to + the server for a configurable amount of time that defaults to + twice the server's CSNP time (see "PushDirTimer" in Section 2.7). + + Condition 2 is necessary because a client TRILL switch might be just + coming up and receive an ESADI-LSP meeting the requirement in + condition 1 above but has not yet received all of the ESADI-LSP + fragments from the Push Directory server. + + Likewise, due to various delays, when an end station connects to or + disconnects from the campus, there are timing differences between + such a connection or disconnection, the update of directory + information at the directory, and the update of directory information + at any particular RBridge in the TRILL campus. Thus, there is + commonly a small window during which an RBridge using directory + information might either (1) drop or unnecessarily flood a frame as + having an unknown unicast destination or (2) encapsulate a frame to + an edge RBridge where the end station is no longer connected when the + frame arrives at that edge RBridge. + + There may be conflicts between mapping information from different + Push Directory servers or conflicts between locally learned + information and information received from a Push Directory server. + In cases of such conflicts, information with a higher confidence + value [RFC6325] [RFC7961] is preferred over information with a lower + confidence value. In cases of equal confidence values, 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. + +2.6. Providing Secondary Servers with Data from a Primary Server + + A secondary Push or Pull Directory server is one that obtains its + data from a primary directory server. Such systems, where some + directory servers can be populated from others, have been found + useful for multiple-server directory applications -- for example, in + the DNS, where it is the normal case that some authoritative servers + (secondary servers) are populated with data from other authoritative + servers (primary servers). + + 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 directory server + takes the pushed data it receives from the highest-priority Push + Directory server and re-originates it. Such a secondary server + may be a Push Directory server, a Pull Directory server, or both for + any particular Data Label. Because the data from a secondary server + + + +Eastlake, et al. Standards Track [Page 16] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + will necessarily be at least a little less fresh than that from a + primary server, it is RECOMMENDED that the re-originated secondary + server's data be given a confidence level at least one less than that + of the data as received from the primary server (or unchanged if it + is already of minimum confidence). + +2.7. Push Directory Configuration + + The following configuration parameters, per Data Label, are available + for controlling Push Directory behavior: + + Name Range/Setting Default Section + --------------- ------------- --------- ------------ + PushDirService true/false false 2.2 + PushDirServers 1-8 2 2.2 + PushDirPriority 0-255 0x3F 2.2 + PushDirComplete true/false false 2.3.1, 2.3.2 + PushDirTimer 1-511 2 * CSNP 2.3.2, 2.5 + + PushDirService is a boolean. When false, Push Directory service is + not provided; when true, it is. + + PushDirComplete is a boolean. When false, the server never indicates + that the information it has pushed is complete; when true, it does so + indicate after pushing all the information it knows. + + PushDirTimer defaults to two times the ESADI-CSNP configuration value + but not less than 1 second. + +3. Pull Model Directory Assistance Mechanisms + + In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory + information from an appropriate directory server when needed. + + A TRILL switch that makes use of Pull Directory services must + implement appropriate connections between its directory utilization + and its link-state database and link-state updating. For example, + Pull Directory servers for a particular Data Label X are found by + looking in the core TRILL IS-IS link-state database for + data-reachable [RFC7780] TRILL switches that advertise themselves by + setting the Pull Directory flag (PUL) to 1 in their Interested VLANs + sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data + Label. The set of such switches can change with configuration + changes by network management, such as the following: + + o the startup or shutdown of Pull Directory servers + + + + + +Eastlake, et al. Standards Track [Page 17] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + o changes in network topology, such as the connection or + disconnection of TRILL switches that are Pull Directory servers + + o network partition or merger + + As described in Section 3.7, a TRILL switch MUST be able to detect + that a Pull Directory from which it has cached data is no longer + data reachable so that it can discard such cached data. + + If multiple data-reachable TRILL switches indicate in the link-state + database that they are Pull Directory servers for a particular Data + Label, pull requests can be sent to any one or more of them, but it + is RECOMMENDED that pull requests be preferentially sent to the + server or servers that are lowest cost from the requesting TRILL + switch. + + Pull Directory requests are sent by encapsulating them in an RBridge + Channel [RFC7178] message using the Pull Directory channel protocol + number (see Section 7.2). Responses are returned in an RBridge + Channel message using the same channel protocol number. See + Section 3.2 for Query and Response Message formats. For cache + consistency or notification purposes, Pull Directory servers, under + certain conditions, MUST send unsolicited Update Messages to client + TRILL switches they believe may be holding old data. Those clients + can acknowledge such updates, as described in Section 3.3. All these + messages have a common header, as described in Section 3.1. Errors + are returned as described in Section 3.6. + + The requests to Pull Directory servers are typically derived from + ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or SEND + [RFC3971] messages, or data frames with unknown unicast destination + MAC addresses, intercepted by an ingress TRILL switch, as described + in Section 1.1. + + Pull Directory responses include an amount of time for which the + response should be considered valid. This includes negative + responses that indicate that no data is available. It is RECOMMENDED + that both positive responses with data and negative responses be + cached and used to locally handle ARP, ND, RARP, unknown destination + MAC frames, or the like [ARPND], until the responses expire. If + information previously pulled is about to expire, a TRILL switch MAY + try to refresh it by issuing a new pull request but, to avoid + unnecessary requests, SHOULD NOT do so unless it has been recently + used. The validity timer of cached Pull Directory responses is NOT + reset or extended merely because that cache entry is used. + + + + + + +Eastlake, et al. Standards Track [Page 18] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +3.1. Pull Directory Message: Common Format + + All Pull Directory messages are transmitted as the Channel + Protocol-specific payload of RBridge Channel messages [RFC7178]. + Pull Directory messages are formatted as described herein, starting + with the following common 8-byte header: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ver | Type | Flags | Count | Err | SubErr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Specific Payload - variable length + +-+-+- ... + + Ver: Version of the Pull Directory protocol. An unsigned integer. + Version 0 (zero) is specified in this document. See + Section 3.1.1 for a discussion of version negotiation. + + Type: The Pull Directory message type, as follows: + + Type Section Name + ---- ------- ------------ + 0 - Reserved + 1 3.2.1 Query + 2 3.2.2 Response + 3 3.3.1 Update + 4 3.3.2 Acknowledge + 5-14 - Unassigned + 15 - Reserved + + Flags: Four flag bits whose meaning depends on the Pull Directory + message type. Flags whose meanings are not specified are + reserved, MUST be sent as zero, and MUST be ignored on receipt. + + Count: Some Pull Directory message types specified herein have + zero or more occurrences of a Record as part of the + type-specific payload. The Count field is the number of + occurrences of that Record and is expressed as an unsigned + integer. For any Pull Directory messages not structured with + such occurrences, this field MUST be sent as zero and ignored + on receipt. + + + + + + + +Eastlake, et al. Standards Track [Page 19] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + Err, SubErr: A two-part error code. These fields are only used in + Reply Messages. In messages that are requests or updates, + these fields MUST be sent as zero and ignored on receipt. An + Err field containing the value zero means no error. The + meaning of values in the SubErr field depends on the value of + the Err field, but in all cases, a zero SubErr field is allowed + and provides no additional information beyond the value of the + Err field. + + Sequence Number: An identifying 32-bit quantity set by the TRILL + switch sending a request or other unsolicited message and + returned in every corresponding reply or acknowledgment. It is + used to match up responses with the message to which they + respond. + + Type Specific Payload: Format depends on the Pull Directory + message type. + +3.1.1. Version Negotiation + + The version number (Ver) in the Pull Directory message header is + incremented for a future version with changes such that TRILL + directory messages cannot be parsed correctly by an earlier version. + Ver is not incremented for minor changes such as defining a new field + value for an existing field. + + Pull Directory messages come in pairs (Request-Response, + Update-Acknowledgment). The version number in the Request/Update + (Ver1) indicates the format of that message and the format of the + corresponding returned Response/Acknowledgment. The version number + in the returned Response/Acknowledgment (Ver2) indicates the highest + version number that the sender of that Response/Acknowledgment + understands. + + In the most common case -- a well-configured network -- Ver1 and Ver2 + will be equal. + + If Ver2 is less than Ver1, the returned Response/Acknowledgment will + be an error message saying that the version is not understood. + + If Ver2 is greater than Ver1 and the responder understands Ver1, it + responds normally in Ver1 format. However, if the responder does not + understand Ver1, it MUST send a "Version not understood" error + message (Section 3.6.2) correctly formatted for Ver1. Thus, all + implementations that support some version X MUST be able to send a + Version not understood error message correctly formatted for all + lower versions down to version 0. + + + + +Eastlake, et al. Standards Track [Page 20] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +3.2. Pull Directory Query and Response Messages + + The formats of Pull Directory Query Messages and Pull Directory + Response Messages are specified in Sections 3.2.1 and 3.2.2.1, + respectively. + +3.2.1. Pull Directory Query Message Format + + A Pull Directory Query Message is sent as the Channel + Protocol-specific content of an RBridge Channel message [RFC7178] + TRILL Data packet or as a native RBridge Channel data frame (see + Section 3.5). The Data Label of the packet is the Data Label in + which the query is being made. The priority of the RBridge Channel + message is a mapping of the priority of the ingressed frame that + caused the query. The default mapping depends, per Data Label, on + the strategy (see Section 4) or a configured priority (see + "DirGenQPriority" in Section 3.9) for generated queries. (Generated + queries are those queries that are not the result of a mapping -- for + example, a query to refresh a cache entry.) The Channel + Protocol-specific data is formatted as a header and a sequence of + zero or more QUERY Records as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ver | Type | Flags | Count | Err | SubErr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | QUERY 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... + | QUERY 2 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... + | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... + | QUERY K + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... + + Ver, Sequence Number: See Section 3.1. + + Type: 1 for Query. Queries received by a TRILL switch that is not + a Pull Directory for the relevant Data Label result in an error + response (see Section 3.6) unless inhibited by rate limiting. + (See [RFC7178] for information on the Response Message that is + generated if the recipient implements the RBridge Channel + features but does not implement the Pull Directory RBridge + Channel Protocol.) + + + + +Eastlake, et al. Standards Track [Page 21] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + Flags, Err, and SubErr: MUST be sent as zero and ignored on + receipt. + + Count: Count is the number of QUERY Records present. A + Query Message Count of 0 is explicitly allowed, for the purpose + of pinging a Pull Directory server to see if it is responding. + On receipt of such an empty Query Message, a Response Message + that also has a Count of 0 is returned unless inhibited by rate + limiting. + + QUERY: Each QUERY Record within a Pull Directory Query Message is + formatted as follows: + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | SIZE |FR| RESV | QTYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + If QTYPE = 1 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | AFN | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Query Address ... + +--+--+--+--+--+--+--+--+--+--+--... + If QTYPE = 2 or 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Query Frame ... + +--+--+--+--+--+--+--+--+--+--+--... + + SIZE: Size of the QUERY Record in bytes, expressed as an + unsigned integer and not including the SIZE field and + following byte. A value of SIZE so large that the material + doesn't fit in the Query Message indicates a malformed + QUERY Record. A QUERY Record with such an illegal SIZE + value, and any subsequent QUERY Records, MUST be ignored, + and the entire Query Message MAY be ignored. + + FR: The Flood Record flag. Ignored if QTYPE is 1. If QTYPE is + 2 or 5 and the directory information sought is not found, + the frame provided is flooded; otherwise, it is not + forwarded. See Section 3.2.2.2. For QTYPEs other than 2 or + 5, the FR flag has no effect. + + RESV: A block of three reserved bits. MUST be sent as zero and + ignored on receipt. + + + + + + + +Eastlake, et al. Standards Track [Page 22] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + QTYPE: There are several types of QUERY Records currently + defined in two classes, as follows: (1) a QUERY Record that + provides an explicit address and asks for all addresses for + the interface specified by the Query Address and (2) a + QUERY Record that includes a frame. The fields of each are + specified below. Values of QTYPE are as follows: + + QTYPE Description + ----- ------------------------------- + 0 Reserved + 1 Address query + 2 Frame query + 3-4 Unassigned + 5 Unknown unicast MAC Query Frame + 6-14 Unassigned + 15 Reserved + + AFN: Address Family Number of the Query Address. + + Query Address: The query is asking for any other addresses, and + the nickname of the TRILL switch from which they are + reachable, that correspond to the same interface as this + address, within the Data Label of the query of the address + provided. A typical Query Address would be something like + the following: + + 1. A 48-bit MAC address, with the querying TRILL switch + primarily interested in either + + a. the RBridge by which that MAC address is reachable, so + that the querying RBridge can forward an unknown + (before the query) destination MAC address native + frame as a unicast TRILL Data packet rather than + flooding it, or + + b. the IP address corresponding to the MAC address, so + that the RBridge can locally respond to a RARP + [RFC903] native frame. + + 2. An IPv4 or IPv6 address, with the querying RBridge + interested in the corresponding MAC address so it can + locally respond to an ARP [RFC826] or ND [RFC4861] native + frame [ARPND]. + + But the Query Address could be some other address type for + which an AFN has been assigned, such as a 64-bit MAC address + [RFC7042] or a CLNS (connectionless-mode network service) + [X.233] address. + + + +Eastlake, et al. Standards Track [Page 23] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + Query Frame: Where a QUERY Record is the result of an ARP, ND, + RARP, SEND, or unknown unicast MAC destination address, the + ingress TRILL switch MAY send the frame to a Pull Directory + server if the frame is small enough that the resulting Query + Message fits into a TRILL Data packet within the campus MTU. + The full frame is included, starting with the destination + and source MAC addresses, but does not include the Frame + Check Sequence (FCS). + + If no response to a Pull Directory Query Message is received within a + configurable timeout (see "DirQueryTimeout" in Section 3.9), then the + Query Message should be retransmitted with the same Sequence Number + (up to a configurable number of times (see "DirQueryRetries" in + Section 3.9)). If there are multiple QUERY Records in a + Query Message, responses to various subsets of these QUERY Records + can be received before the timeout. In that case, the remaining + unanswered QUERY Records should be resent in a new Query Message with + a new Sequence Number. If a TRILL switch is not capable of handling + partial responses to queries with multiple QUERY Records, it MUST NOT + send a Request Message with more than one QUERY Record in it. + + See Section 3.6 for a discussion of how Query Message errors are + handled. + +3.2.2. Pull Directory Responses + + A Pull Directory Query Message results in a Pull Directory Response + Message as described in Section 3.2.2.1. + + In addition, if the QUERY Record QTYPE was 2 or 5, the frame included + in the Query may be modified and forwarded by the Pull Directory + server as described in Section 3.2.2.2. + +3.2.2.1. Pull Directory Response Message Format + + Pull Directory Response Messages are sent as the + Channel Protocol-specific content of an RBridge Channel message + [RFC7178] TRILL Data packet or as a native RBridge Channel data frame + (see Section 3.5). Responses are sent with the same Data Label and + priority as the Query Message to which they correspond, except that + the Response Message priority is limited to be no more than the + configured value DirRespMaxPriority (Section 3.9). + + + + + + + + + +Eastlake, et al. Standards Track [Page 24] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + The RBridge Channel Protocol-specific data format is as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ver | Type | Flags | Count | Err | SubErr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESPONSE 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... + | RESPONSE 2 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... + | ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... + | RESPONSE K + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... + + Ver, Sequence Number: As specified in Section 3.1. + + Type: 2 = Response. + + Flags: MUST be sent as zero and ignored on receipt. + + Count: Count is the number of RESPONSE Records present in the + Response Message. + + Err, SubErr: A two-part error code. Zero, unless there was an + error in the Query Message (in which case, see Section 3.6). + + RESPONSE: Each RESPONSE Record within a Pull Directory Response + Message is formatted as follows: + + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | SIZE |OV| RESV | Index | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Lifetime | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | Response Data ... + +--+--+--+--+--+--+--+--+--+--+--... + + SIZE: The size of the RESPONSE Record is an unsigned integer + number of bytes, not including the SIZE field and following + byte. A value of SIZE so large that the material doesn't + fit in the Query Message indicates a malformed + + + + + +Eastlake, et al. Standards Track [Page 25] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + RESPONSE Record. A RESPONSE Record with such an excessive + SIZE value, and any subsequent RESPONSE Records, MUST be + ignored, and the entire Response Message MAY be ignored. + + OV: The overflow flag. Indicates, as described below, that + there was too much Response Data to include in one Response + Message. + + RESV: Three reserved bits that MUST be sent as zero and ignored + on receipt. + + Index: The relative index of the QUERY Record in the Query + Message to which this RESPONSE Record corresponds. The + Index will always be 1 for Query Messages containing a + single QUERY Record. If the Index is larger than the Count + was in the corresponding Query, that RESPONSE Record MUST be + ignored, and subsequent RESPONSE Records or the entire + Response Message MAY be ignored. + + Lifetime: The length of time, in units of 100 milliseconds, + for which the response should be considered valid, except + that the values zero and 2**16 - 1 are special. If zero, + the response can only be used for the particular query from + which it resulted and MUST NOT be cached. If 2**16 - 1, the + response MAY be kept indefinitely but not after the Pull + Directory server goes down or becomes unreachable. (The + maximum definite time that can be expressed is a little over + 1.8 hours.) + + Response Data: There are three types of RESPONSE Records: + + - If the Err field of the encapsulating Response Message has a + message-level error code in it, then the RESPONSE Records + are omitted and Count will be 0. See Section 3.6 for + additional information on errors. + + - If the Err field of the encapsulating Response Message has a + record-level error code in it, then the RESPONSE Records are + those having that error, as further described in + Section 3.6. + + - If the Err field of the encapsulating Response Message is 0, + then the Response Data in each RESPONSE Record is formatted + as the value part of an Interface Addresses APPsub-TLV + [RFC7961]. The maximum size of such contents is 255 bytes, + in which case the RESPONSE Record SIZE field is 255. + + + + + +Eastlake, et al. Standards Track [Page 26] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + Multiple RESPONSE Records can appear in a Response Message with the + same Index if an answer to the QUERY Record consists of multiple + Interface Addresses APPsub-TLV values. This would be necessary if, + for example, a MAC address within a Data Label appears to be + reachable by multiple TRILL switches. 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 + mappings to include, by some method outside the scope of this + document, and sets the overflow flag (OV) in all of the + RESPONSE Records responding to that Query Address. + + See Section 3.6 for a discussion of how errors are handled. + +3.2.2.2. Pull Directory Forwarding + + Query Messages with QTYPEs 2 and 5 are interpreted and handled as + described below. In these cases, if the information implicitly + sought is not in the directory and the FR flag in the Query Message + was 1 (one), the provided frame is forwarded by the Pull Directory + server as a multi-destination TRILL Data packet with the ingress + nickname of the Pull Directory server (or proxy, if it is hosted on + an end station) in the TRILL Header. If the FR flag is 0, the frame + is not forwarded in this case. + + If there was no error in the handling of the encapsulating + Query Message, the Pull Directory server forwards the frame inside + that QUERY Record, after modifying it in some cases, as described + below: + + ARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates + that an ARP [RFC826] frame is included in the Record: + The ar$op field MUST be ares_op$REQUEST, and for the response + described in Section 3.2.2.1, this is treated as a query for the + target protocol address, where the AFN of that address is given by + ar$pro. (ARP fields and value names with embedded dollar signs + ("$") are specified in [RFC826].) If (1) ar$op is not + ares_op$REQUEST, (2) the ARP is malformed, or (3) the query fails, + an error is returned. Otherwise, the ARP is modified into the + appropriate ARP response, which is then sent by the Pull Directory + server as a TRILL Data packet. + + ND/SEND: When QTYPE is 2 and the Ethertype in the QUERY Record + indicates that an IPv6 ND [RFC4861] or SEND [RFC3971] frame is + included in the Record: + Only Neighbor Solicitation ND frames (corresponding to an ARP + query) are allowed. An error is returned for other ND frames or + if the target address is not found. Otherwise, if the ND is not a + + + +Eastlake, et al. Standards Track [Page 27] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + SEND, an ND Neighbor Advertisement response is returned by the + Pull Directory server as a TRILL Data packet. In the case of + SEND, an error is returned indicating that a SEND frame was + received by the Pull Directory, and the Pull Directory then either + (1) forwards the SEND frame to the holder of the IPv6 address if + that information is in the directory or (2) multicasts the + SEND frame. + + RARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates + that a RARP [RFC903] frame is included in the Record: + If the ar$op field is ares_op$REQUEST, the frame is handled as an + ARP, as described above. Otherwise, the ar$op field MUST be + "reverse request", and for the response described in + Section 3.2.2.1, this is treated as a query for the target + hardware address, where the AFN of that address is given by + ar$hrd. (See [RFC826] for RARP fields.) If (1) ar$op is not one + of these values, (2) the RARP is malformed, or (3) the query + fails, an error is returned. Otherwise, the RARP is modified into + the appropriate RARP response, which is then unicast by the Pull + Directory server as a TRILL Data packet to the source hardware MAC + address. + + MacDA: When QTYPE is 5, indicating that a frame is provided in the + QUERY Record whose destination MAC address TRILL switch attachment + is unknown, the only requirement is that this MAC address has to + be unicast. The Ethertype in the QUERY Record is ignored. If + this MAC address is a group address, an error is returned. In the + case of Pull Directory Response Messages (Section 3.2.2.1), this + MAC address is treated as a query for the MacDA. In the creation + of the response described in Section 3.2.2.1, the query is treated + as a query for this MAC address. If the Pull Directory contains + TRILL switch attachment information for the MAC address in the + Data Label of the Query Message, it forwards the frame to that + switch in a unicast TRILL Data packet. + +3.3. Cache Consistency + + Unless it sends all responses with a Lifetime of 0, a Pull Directory + MUST take action, by sending Update Messages, to minimize the amount + of time that a TRILL switch will continue to use stale information + from that Pull Directory. The formats of Update Messages and the + Acknowledge Messages used to respond to Update Messages are given in + Sections 3.3.1 and 3.3.2, respectively. + + + + + + + + +Eastlake, et al. Standards Track [Page 28] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + A Pull Directory server MUST maintain one of three sets of records + concerning possible cached data at clients of that server. These are + numbered and listed below in order of increasing specificity: + + Method 1, Least Specific. An overall record, per Data Label, of when + the last positive Response Data sent will expire and when the last + negative response sent will expire; the records are retained until + such expiration. + + Pro: Minimizes the record-keeping burden on the Pull Directory + server. + + Con: Increases the volume of and overhead due to (1) spontaneous + Update Messages and (2) unnecessarily invalidating cached + information. + + Method 2, Medium Specificity. For each unit of data (Interface + Addresses APPsub-TLV (IA APPsub-TLV) Address Set [RFC7961]) held + by the server, record when the last response sent with that + positive Response Data will expire. In addition, record each + address about which a negative response was sent by the server and + when the last such negative response will expire. Each such + record of a positive or negative response is discarded upon + expiration. + + Pros/Cons: An intermediate level of detail in server + record-keeping; also, an intermediate volume of, and overhead + due to, spontaneous Update Messages with some unnecessary + invalidation of cached information. + + Method 3, Most Specific. For each unit of data held by the server + (IA APPsub-TLV Address Set [RFC7961]) and each address about which + a negative response was sent, a list of TRILL switches that were + sent that data as a positive response or sent a negative response + for the address, and the expected time to expiration for that data + or address at each such TRILL switch, assuming that the requester + cached the response. Each list entry is retained until such + expiration time. + + Pros: Minimizes spontaneous Update Messages sent to update pull + client TRILL switch caches, and minimizes unnecessary + invalidation of cached information. + + Con: Increased record-keeping burden on the Pull Directory server. + + + + + + + +Eastlake, et al. Standards Track [Page 29] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + RESPONSE Records sent with a zero Lifetime are considered to have + already expired and so do not need to be tracked. In all cases, + there may still be brief periods of time when directory information + has changed, but information that a pull client has cached has not + yet been updated or expunged. + + A Pull Directory server might have a limit as to (1) how many TRILL + switches for which it can maintain detailed expiry information using + method 3 or (2) how many data units or addresses for which it can + maintain expiry information using method 2 or the like. If such + limits are exceeded, it MUST transition to a lower-numbered method + but, in all cases, MUST support, at a minimum, method 1 and SHOULD + support methods 2 and 3. The use of method 1 may be quite + inefficient, due to large amounts of cached positive and negative + information being unnecessarily discarded. + + When data at a Pull Directory is changed, deleted, or added and there + may be unexpired stale information at a requesting TRILL switch, the + Pull Directory MUST send an Update Message as discussed below. The + sending of such an Update Message MAY be delayed by a configurable + number of milliseconds (see "DirUpdateDelay" in Section 3.9) to await + other possible changes that could be included in the same + Update Message. + + 1. If method 1, the least detailed 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 data Update Message + is flooded within that Data Label as an RBridge Channel message. + If data is added and there are outstanding cached negative + responses, an all-addresses flush negative message is similarly + flooded. A Count field value of 0 in an Update Message indicates + "all-addresses". On receiving an all-addresses flooded flush + positive Update from a Pull Directory server it has used, + indicated by the F (Flood) and P (Positive) bits being 1 and the + Count being 0, a TRILL switch discards the cached data responses + it has for that Data Label. Similarly, on receiving an + all-addresses flush negative Update, indicated by the F and + N (Negative) bits being 1 and the Count being 0, it discards all + cached negative replies for that Data Label. A combined flush + positive and negative can be flooded by having all of the F, P, + and N bits (see Section 3.3.1) set to 1 and the Count field 0, + resulting in the discard of all positive and negative cached + information for the Data Label. + + 2. If method 2 is being followed, then a TRILL switch floods + address-specific positive Update Messages when data that might be + cached by a querying TRILL switch is changed or deleted and floods + + + +Eastlake, et al. Standards Track [Page 30] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + address-specific negative Update Messages when data that might be + cached by a querying TRILL switch is added. Such messages are + sent as RBridge Channel messages. The F bit will be 1; however, + the Count field will be non-zero, and either the P bit or the + N bit, but not both, will be 1. There are actually four possible + message types that can be flooded: + + a. If data that might still be cached is updated: + An unsolicited Update Message is sent with the P flag set and + the Err field 0. On receipt, the addresses in the RESPONSE + Records are compared to the addresses for which the receiving + TRILL switch is holding cached positive information from that + server. If they match, the cached information is updated. + + b. If data that might still be cached is deleted: + An unsolicited Update Message is sent with the P flag set and + the Err field non-zero, giving the error that would now be + encountered in attempting to pull information for the relevant + address from the Pull Directory server. In this non-zero Err + field case, the RESPONSE Record(s) differs from non-zero Err + Reply Message RESPONSE Records in that they do include an + interface address set. Any cached positive information for the + addresses given is deleted, and the negative response is cached + as per the Lifetime given. + + c. If data for an address for which a negative response was sent + is added, so that negative response that might still be cached + is now incorrect: + An unsolicited Update Message is sent with the N flag set to 1 + and the Err field 0. The addresses in the RESPONSE Records are + compared to the addresses for which the receiving TRILL switch + is holding cached negative information from that server; if + they match, the cached negative information is deleted, and the + positive information provided is cached as per the Lifetime + given. + + d. In the rare case where it is desired to change the Lifetime or + error associated with negative information that might still be + cached: + An unsolicited Update Message is sent with the N flag set to 1 + and the Err field non-zero. As in case b above, the RESPONSE + Record(s) gives the relevant addresses. Any cached negative + information for the addresses is updated. + + 3. If method 3 is being followed, unsolicited Update Messages of the + same sort are sent as with method 2 above, except that they are + not normally flooded but unicast only to the specific TRILL + switches the directory server believes may be holding the cached + + + +Eastlake, et al. Standards Track [Page 31] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + positive or negative information that needs deletion or updating. + However, a Pull Directory server MAY flood unsolicited updates + using method 3 -- for example, if it determines that a + sufficiently large fraction of the TRILL switches in some Data + Label are requesters that need to be updated so that flooding is + more efficient than unicast. + + A Pull Directory server tracking cached information with method 3 + MUST NOT clear the indication that it needs to update cached + information at a querying TRILL switch until it has either (a) sent + an Update Message and received a corresponding Acknowledge Message or + (b) sent a configurable number of updates at a configurable interval + where these parameters default to three updates 100 milliseconds + apart (see Section 3.9). + + A Pull Directory server tracking cached information with method 1 or + method 2 SHOULD NOT clear the indication that it needs to update + cached information until it has sent an Update Message and received a + corresponding Acknowledge Message from all of its ESADI neighbors or + it has sent a number of updates at a configurable interval, as + specified in the paragraph above. + +3.3.1. Update Message Format + + An Update Message is formatted as a Response Message, with the + differences described in Section 3.3 above and the following: + + o The Type field in the message header is set to 3. + + o The Index field in the RESPONSE Record(s) is set to 0 on + transmission and ignored on receipt (but the Count field in the + Update Message header MUST still correctly indicate the number of + RESPONSE Records present). + + o The priority with which the message is sent, DirUpdatePriority, is + configurable and defaults to 5 (see Section 3.9). + + Update Messages are initiated by a Pull Directory server. The + Sequence Number space used is controlled by the originating Pull + Directory server. This Sequence Number space for Update Messages is + different from the Sequence Number space used in a Query and the + corresponding Response that are controlled by the querying + TRILL switch. + + + + + + + + +Eastlake, et al. Standards Track [Page 32] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + The 4-bit Flags field of the message header for an Update Message is + as follows: + + +---+---+---+---+ + | F | P | N | R | + +---+---+---+---+ + + F: The Flood bit. If F = 0, the Update Message is unicast. If + F = 1, it is multicast to All-Egress-RBridges. + + P, N: Flags used to indicate positive or negative Update Messages. + P = 1 indicates "positive". N = 1 indicates "negative". Both + may be 1 for a flooded all-addresses Update. + + R: Reserved. MUST be sent as zero and ignored on receipt. + + For tracking methods 2 and 3 in Section 3.3, a particular Update + Message MUST have either the P flag or the N flag set, but not both. + If both are set, the Update Message MUST be ignored, as this + combination is only valid for method 1. + +3.3.2. Acknowledge Message Format + + An Acknowledge Message is sent in response to an Update Message to + confirm receipt or indicate an error, unless response is inhibited by + rate limiting. It is formatted as a Response Message, but the Type + is set to 4. + + If there are no errors in the processing of an Update Message or if + there is an overall message-level error or a header error in an + Update Message, the message is echoed back with the Err and + SubErr fields set appropriately, the Type changed to Acknowledge, and + a null Records section with the Count field set to 0. + + If there is a record-level error in an Update Message, one or more + Acknowledge Messages may be returned with the erroneous record(s) + indicated as discussed in Section 3.6. + + An Acknowledge Message is sent with the same priority as the Update + Message it acknowledges but not more than a configured priority + called "DirAckMaxPriority", which defaults to 5 (see Section 3.9). + + + + + + + + + + +Eastlake, et al. Standards Track [Page 33] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +3.4. Summary of Record Formats in Messages + + As specified in Sections 3.2 and 3.3, the Query, Response, Update, + and Acknowledge Messages can have zero or more repeating Record + structures under different circumstances, as summarized below. The + "Err" column abbreviations in this table have the meanings listed + below. "IA APPsub-TLV value" means the value part of the + IA APPsub-TLV specified in [RFC7961]. + + MBZ = MUST be zero + Z = zero + NZ = non-zero + NZM = non-zero message-level error + NZR = non-zero record-level error + + Message Err Section Record Structure Response Data + ----------- --- ------- ---------------- ------------------- + Query MBZ 3.2.1 QUERY Record - + Response Z 3.2.2.1 RESPONSE Record IA APPsub-TLV value + Response NZM 3.2.2.1 null - + Response NZR 3.2.2.1 RESPONSE Record Records with error + Update MBZ 3.3.1 RESPONSE Record IA APPsub-TLV value + Acknowledge Z 3.3.2 null - + Acknowledge NZM 3.3.2 null - + Acknowledge NZR 3.3.2 RESPONSE Record Records with error + + See Section 3.6 for further details on errors. + +3.5. End Stations and Pull Directories + + A Pull Directory can be hosted on an end station as specified in + Section 3.5.1. + + An end station can use a Pull Directory as specified in + Section 3.5.2. This capability would be useful in supporting an end + station that performs directory-assisted encapsulation [DirAsstEncap] + or that is a "Smart Endnode" [SmartEN]. + + The native Pull Directory messages used in these cases are as + specified in Section 3.5.3. In these cases, the edge RBridge(s) and + end station(s) involved need to detect each other and exchange some + control information. This is accomplished with the TRILL End System + to Intermediate System (ES-IS) mechanism specified in Section 5. + + + + + + + + +Eastlake, et al. Standards Track [Page 34] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +3.5.1. Pull Directory Hosted on an End Station + + Optionally, a Pull Directory actually hosted on an end station MAY be + supported. In that case, one or more TRILL switches must act as + indirect Pull Directory servers. That is, they host a Pull Directory + server, which is seen by other TRILL switches in the campus, and a + Pull Directory client, which fetches directory information from one + or more end-station Pull Directory servers, where at least some of + the information provided by the Pull Directory server may be + information fetched from an end station to which it is directly + connected by the co-located Pull Directory client. ("Direct + connection" means a connection not involving any intermediate TRILL + switches.) + + End stations hosting a Pull Directory server MUST support TRILL ES-IS + (see Section 5) and advertise the Data Labels for which they are + providing service in one or more Interested VLANs sub-TLVs or + Interested Labels sub-TLVs by setting the PUL flag (see Section 7.3). + + * * * * * * * + +---------------+ * * + | End Station 1 | +---------------+ * + | Pull Directory+--------------+ RB1, Pull | * + | Server | | Directory| * + +---------------+ +-------+ Client|Server | +----+ + | +---------------+ |RB99| + +---------------+ | * +----+ + | End Station 2 | +--+---+ +---------------+ * + | Pull Directory+---+Bridge+---+ RB2, Pull | * + | Server | +--+---+ | Directory| * + +---------------+ | | Client|Server | * + | +---------------+ * + | * TRILL * + . * Campus * + . * * + . * * * * * * * + + Figure 2: End-Station Pull Directory Example + + Figure 2 gives an example where RB1 and RB2 advertise themselves to + the rest of the TRILL campus, such as RB99, as Pull Directory servers + and obtain at least some of the information they are providing by + issuing Pull Directory queries to End Stations 1 and/or 2. This + example is specific, but many variations are possible. The box + labeled "Bridge" in Figure 2 could be replaced by a complex bridged + LAN or could be a bridgeless LAN through the use of a hub or + repeater. Or, end stations might be connected via point-to-point + links (as shown for End Station 1), including multi-ported + + + +Eastlake, et al. Standards Track [Page 35] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + end stations connected by point-to-point links to multiple RBridges. + Although Figure 2 shows two end stations and two RBridges, there + could be one or more than two RBridges having such indirect Pull + Directory servers. Furthermore, there could be one or more than two + end stations with Pull Directory servers on them. Each TRILL switch + acting as an indirect Pull Directory server could then be differently + configured as to the Data Labels for which it is providing indirect + service selected from the union of the Data Labels supported by the + end-station hosted servers and could select from among those + end-station hosted servers supporting each Data Label the indirect + server is configured to provide. + + When an indirect Pull Directory server receives Query Messages from + other TRILL switches, it answers from information it has cached or + issues Pull Directory requests to end-station Pull Directory servers + with which it has TRILL ES-IS adjacency to obtain the information. + Any Response sent by an indirect Pull Directory server MUST NOT have + a validity time longer than the validity period of the data on which + it is based. When an indirect Pull Directory server receives Update + Messages, it updates its cached information and MUST originate Update + Messages to any clients that may have mirrors of the cached + information so updated. + + Since an indirect Pull Directory server discards information it has + cached from queries to an end-station Pull Directory server if it + loses adjacency to the server (Section 3.7), if it detects that such + information may be cached at RBridge clients and has no other source + for the information, it MUST send Update Messages to those clients + withdrawing the information. For this reason, indirect Pull + Directory servers may wish to query multiple sources, if available, + and cache multiple copies of returned information from those multiple + sources. Then, if one end-station source becomes inaccessible or + withdraws the information but the indirect Pull Directory server has + the information from another source, it need not originate Update + Messages. + +3.5.2. Use of Pull Directory by End Stations + + Some special end stations, such as those discussed in [DirAsstEncap] + and [SmartEN], may need to access directory information. How edge + RBridges provide this optional service is specified below. + + When Pull Directory support is provided by an edge RBridge to end + stations, the messages used are as specified in Section 3.5.3 below. + The edge RBridge MUST support TRILL ES-IS (Section 5) and advertises + the Data Labels for which it offers this service to end stations by + + + + + +Eastlake, et al. Standards Track [Page 36] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + setting the Pull Directory flag (PUL) to 1 in its Interested VLANs + sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data + Label advertised through TRILL ES-IS. + +3.5.3. Native Pull Directory Messages + + The Pull Directory messages used between TRILL switches and end + stations are native RBridge Channel messages [RFC7178]. These + RBridge Channel messages use the same Channel Protocol number as the + inter-RBridge Pull Directory RBridge Channel messages. The + Outer.VLAN ID used is the TRILL ES-IS Designated VLAN (see Section 5) + on the link to the end station. Since there is no TRILL Header or + inner Data Label for native RBridge Channel messages, that + information is added to the Pull Directory message header as + specified below. + + The protocol-dependent data part of the native RBridge Channel + message is the same as for inter-RBridge Channel messages, except + that the 8-byte header described in Section 3.1 is expanded to 12 or + 16 bytes, as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ver | Type | Flags | Count | Err | SubErr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Label ... (4 or 8 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ + | Type Specific Payload - variable length + +-+-+- ... + + Fields other than the Data Label field are as defined in Section 3.1. + The Data Label that normally appears right after the Inner.MacSA of + the RBridge Channel Pull Directory message appears in the Data Label + field of the Pull Directory message header in the native RBridge + Channel message version. This Data Label appears in a native Query + Message, to be reflected in a Response Message, or it might appear in + a native Update to be reflected in an Acknowledge Message. Since the + appropriate VLAN or FGL [RFC7172] Ethertype is included, the length + of the Data Label can be determined from the first 2 bytes. + + + + + + + + + +Eastlake, et al. Standards Track [Page 37] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +3.6. Pull Directory Message Errors + + A non-zero Err field in the Pull Directory Response or Acknowledge + Message header indicates an error message. + + If there is an error that applies to an entire Query or Update + Message or its header, as indicated by the range of the value of the + Err field, then the QUERY Records probably were not even looked at by + the Pull Directory server and would provide no additional information + in the Response or Acknowledge Message. Therefore, the Records + section of the response to a Query Message or Update Message is + omitted, and the Count field is set to 0 in the Response or + Acknowledge Message. + + If errors occur at the QUERY Record level for a Query Message, they + MUST be reported in a Response Message separate from the results of + any successful non-erroneous QUERY Records. If multiple + QUERY Records in a Query Message have different errors, they MUST be + reported in separate Response Messages. If multiple QUERY Records in + a Query Message have the same error, this error response MAY be + reported in one or multiple Response Messages. In an error Response + Message, the QUERY Record or Records being responded to appear, + expanded by the Lifetime for which the server thinks the error might + persist (usually 2**16 - 1, which indicates "indefinitely") and with + their Index inserted, as the RESPONSE Record or Records. + + If errors occur at the RESPONSE Record level for an Update Message, + they MUST be reported in an Acknowledge Message separate from the + acknowledgment of any non-erroneous RESPONSE Records. If multiple + RESPONSE Records in an Update have different errors, they MUST be + reported in separate Acknowledge Messages. If multiple + RESPONSE Records in an Update Message have the same error, this error + response MAY be reported in one or multiple Acknowledge Messages. In + an error Acknowledge Message, the RESPONSE Record or Records being + responded to appear, expanded by the time for which the server thinks + the error might persist and with their Index inserted, as a + RESPONSE Record or Records. + + Err values 1 through 126 are available for encoding errors at the + Request Message or Update Message level. Err values 128 through 254 + are available for encoding errors at the QUERY Record or + RESPONSE Record level. 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. + + + + + + + +Eastlake, et al. Standards Track [Page 38] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +3.6.1. Error Codes + + The following table lists error code values for the Err field, their + meanings, and whether they apply at the message level or the + record level. + + Err Level Meaning + ------- ------- ----------------------------------------------- + 0 - No Error + + 1 Message Unknown or reserved Query Message field value + 2 Message Request Message/data too short + 3 Message Unknown or reserved Update Message field value + 4 Message Update Message/data too short + 5-126 Message Unassigned + 127 - Reserved + + 128 Record Unknown or reserved QUERY Record field value + 129 Record QUERY Record truncated + 130 Record Address not found + 131 Record Unknown or reserved RESPONSE Record field value + 132 Record RESPONSE Record truncated + 133-254 Record Unassigned + 255 - Reserved + + Note that some error codes are for overall message-level errors, + while some are for errors in the repeating records that occur in + messages. + +3.6.2. Sub-errors under Error Codes 1 and 3 + + The following sub-errors are specified under error codes 1 and 3: + + SubErr Field with Error + ------ ------------------------------------------- + 0 Unspecified + 1 Version not understood (see Section 3.1.1) + 2 Unknown Type field value + 3 Specified Data Label not being served + 4-254 Unassigned + 255 Reserved + + + + + + + + + + +Eastlake, et al. Standards Track [Page 39] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +3.6.3. Sub-errors under Error Codes 128 and 131 + + The following sub-errors are specified under error codes 128 and 131: + + SubErr Field with Error + ------ ---------------------------------------------------- + 0 Unspecified + 1 Unknown AFN field value + 2 Unknown or Reserved QTYPE field value + 3 Invalid or inconsistent SIZE field value + 4 Invalid frame for QTYPE 2 (other than SEND) + 5 SEND frame sent as QTYPE 2 + 6 Invalid frame for QTYPE 5 (such as multicast MacDA) + 7-254 Unassigned + 255 Reserved + +3.7. Additional Pull Details + + A Pull Directory client MUST be able to detect, by tracking + link-state changes, when a Pull Directory server is no longer + accessible (data reachable [RFC7780] for the inter-RBridge case or + TRILL ES-IS (Section 5) adjacent for the end-station-to-RBridge case) + and MUST promptly discard all pull responses it is retaining from + that server, as it can no longer receive cache consistency Update + Messages from the server. + + A secondary Pull Directory server is one that obtains its data from a + primary directory server. See the discussion in Section 2.6 + regarding the transfer of directory information from the + primary server to the secondary server. + +3.8. The "No Data" Flag + + In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], + the mere presence of any Interested VLANs sub-TLVs or Interested + Labels sub-TLVs in the LSP of a TRILL switch indicates connection to + end stations in the VLAN(s) or FGL(s) listed and thus a need to + receive multi-destination traffic in those Data Labels. However, + with Pull Directories, advertising that you are a directory server + requires using these sub-TLVs to indicate the Data Label(s) you are + serving. + + If a directory server does not wish to receive multi-destination + TRILL Data packets for the Data Labels it lists in one of the + Interested VLANs or Interested Labels (FGLs) sub-TLVs (see + Section 1.2), it sets the No Data (NOD) bit to 1 (see Section 7.3). + This means that data on a distribution tree may be pruned so as not + to reach the "No Data" TRILL switch as long as there are no TRILL + + + +Eastlake, et al. Standards Track [Page 40] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + switches interested in the Data Label that are beyond the No Data + TRILL switch on that distribution tree. The NOD bit is backward + compatible, as TRILL switches ignorant of it will simply not prune + when they could; this is safe, although it may cause increased link + utilization by some TRILL switches sending multi-destination traffic + where it is not needed. + + Push Directories advertise themselves inside ESADI, which normally + requires the ability to send and receive multi-destination TRILL Data + packets but can be implemented with serial unicast. + + An example of a TRILL switch serving as a directory that might not + want multi-destination traffic in some Data Labels would be a TRILL + switch that does not offer end-station service for any of the Data + Labels for which it is serving as a directory and is + + - a Pull Directory and/or + + - a Push Directory for one or more Data Labels, where all of the + ESADI traffic for those Data Labels will be handled by unicast + ESADI [RFC7357]. + + A Push Directory MUST NOT set the NOD bit for a Data Label if it + needs to communicate via multi-destination ESADI or RBridge Channel + PDUs in that Data Label, since such PDUs look like TRILL Data packets + to transit TRILL switches and are likely to be incorrectly pruned if + the NOD bit was set. + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 41] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +3.9. Pull Directory Service Configuration + + The following per-RBridge scalar configuration parameters are + available for controlling Pull Directory service behavior. In + addition, there is a configurable mapping, per Data Label, from the + priority of a native frame being ingressed to the priority of any + Pull Directory query it causes. The default mapping depends on the + client strategy, as described in Section 4. + + Name Default Section Note Below + ------------------ ---------------- ------- ---------- + + DirQueryTimeout 100 milliseconds 3.2.1 1 + DirQueryRetries 3 3.2.1 1 + DirGenQPriority 5 3.2.1 2 + + DirRespMaxPriority 6 3.2.2.1 3 + + DirUpdateDelay 50 milliseconds 3.3 + DirUpdatePriority 5 3.3.1 + DirUpdateTimeout 100 milliseconds 3.3.3 + DirUpdateRetries 3 3.3.3 + + DirAckMaxPriority 5 3.3.2 4 + + Note 1: Pull Directory Query client timeout waiting for response + and maximum number of retries. + + Note 2: Priority for client-generated requests (such as a query to + refresh cached information). + + Note 3: Pull Directory Response Messages SHOULD NOT be sent with + priority 7, as that priority SHOULD be reserved for messages + critical to network connectivity. + + Note 4: Pull Directory Acknowledge Messages SHOULD NOT be sent + with priority 7, as that priority SHOULD be reserved for + messages critical to network connectivity. + +4. Directory Use Strategies and Push-Pull Hybrids + + For some edge nodes that have a great number of Data Labels enabled, + managing the MAC and Data Label <-> Edge RBridge 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 + many, if not all, Data Labels. + + + + + +Eastlake, et al. Standards Track [Page 42] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + For those edge TRILL switch nodes, a hybrid model should be + considered. That is, the Push Model is used for some Data Labels or + addresses within a Data Label, while the Pull Model is used for other + Data Labels or addresses within a Data Label. The network operator + decides, via configuration, which Data Labels' mapping entries are + pushed down from directories and which Data Labels' mapping entries + are pulled. + + For example, assume a data center where hosts in specific Data + Labels, say VLANs 1 through 100, communicate regularly with external + peers. The mapping entries for those 100 VLANs should probably be + pushed down to the data-center gateway routers. For hosts in other + Data Labels that only communicate with external peers occasionally + for management interfacing, the mapping entries for those VLANs + should be pulled down from the directory when needed. + + Similarly, within a Data Label, it could be that some addresses, such + as the addresses of gateways, files, DNS, or database server hosts + are commonly referenced by most other hosts but those other hosts, + perhaps compute engines, are typically only referenced by a few hosts + in that Data Label. In that case, the address information for the + commonly referenced hosts could be pushed as an incomplete directory, + while the addresses of the others are pulled when needed. + + The mechanisms described in this document for Push and Pull Directory + services make it easy to use Push for some Data Labels or addresses + and Pull for others. In fact, different TRILL switches 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. Also, there + can be Data Labels for which directory services are not used at all. + + There are a wide variety of strategies that a TRILL switch can adopt + for making use of directory assistance. A few suggestions are given + below. + + - Even if a TRILL switch will normally be operating with information + from a complete Push Directory server, there will be a period of + time when it first comes up before the information it holds is + complete. Or, it could be that the only Push Directories that can + push information to it are incomplete or that they are just + starting and may not yet have pushed the entire directory. Thus, + it is RECOMMENDED that all TRILL switches have a strategy for + dealing with the situation where they do not have complete + directory information. Examples are to send a Pull Directory + query or to revert to the behavior described in [RFC6325]. + + + + + +Eastlake, et al. Standards Track [Page 43] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + - If a TRILL switch receives a native frame X resulting in seeking + directory information, a choice needs to be made as to what to do + if it does not already have the directory information it needs. + In particular, it could (1) immediately flood the TRILL Data + packet resulting from ingressing X in parallel with seeking the + directory information, (2) flood that TRILL Data packet after a + delay, if it fails to obtain the directory information, or + (3) discard X if it fails to obtain the information. The choice + might depend on the priority of frame X, since the higher that + priority the more urgent the frame typically is, and the greater + the probability of harm in delaying it. If a Pull Directory + request is sent, it is RECOMMENDED that its priority be derived + from the priority of frame X according to the table below; + however, it SHOULD be possible, on a per-TRILL-switch basis, to + configure the second two columns of this table. + + Ingressed If Flooded If Flooded + Priority Immediately After Delay + -------- ----------- ----------- + 7 5 6 + 6 5 6 + 5 4 5 + 4 3 4 + 3 2 3 + 2 0 2 + 0 1 0 + 1 1 1 + + Note: The odd-looking ordering of numbers towards the bottom of + the columns above is because priority 1 is lower than priority + zero. That is to say, the values in the first column are in + priority order. They will look more logical if you think of "0" + as being "1.5". + + Priority 7 is normally only used for urgent messages critical to + adjacency and so SHOULD NOT be the default for directory traffic. + Unsolicited updates are sent with a priority that is configured per + Data Label and that defaults to priority 5. + +5. TRILL ES-IS + + TRILL ES-IS (End System to Intermediate System) is a variation of + TRILL IS-IS [RFC7176] [RFC7177] [RFC7780] designed to operate on a + TRILL link among and between one or more TRILL switches and end + stations on that link. TRILL ES-IS is analogous to the ISO/IEC ES-IS + standard [ISO9542] but is implemented in a significantly different + way as a variation of TRILL IS-IS, as specified in this section. + Support of TRILL ES-IS is generally optional for both the TRILL + + + +Eastlake, et al. Standards Track [Page 44] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + switches and the end stations on a link but may be required to + support certain features. At the time of this writing, the only + features requiring TRILL ES-IS are those listed in this section. + + TRILL ES-IS + + o is useful for supporting Pull Directory hosting on, or use from, + end stations (see Section 3.5), + + o is useful for supporting specialized end stations [DirAsstEncap] + [SmartEN], and + + o may have additional future uses. + + The advantages of TRILL ES-IS over simply making an "end station" be + a TRILL switch include relieving the end station of having to + maintain a copy of the core link-state database (LSPs) and of having + to perform routing calculations or having the ability to forward + traffic. + + Except as provided below in this section, TRILL ES-IS PDUs and TLVs + are the same as TRILL IS-IS PDUs and TLVs. + +5.1. PDUs and System IDs + + All TRILL ES-IS PDUs (except some MTU-probe and MTU-ack PDUs, which + may be unicast) are multicast using the TRILL-ES-IS multicast MAC + address (see Section 7.6). This use of a different multicast address + assures that TRILL ES-IS and TRILL IS-IS PDUs will not be confused + for one another. + + Because end stations do not have IS-IS System IDs, TRILL ES-IS uses + port MAC addresses in their place. This is convenient, since MAC + addresses are 48-bit and almost all IS-IS implementations use 48-bit + System IDs. Logically, TRILL IS-IS operates between the TRILL + switches in a TRILL campus as identified by the System ID, while + TRILL ES-IS operates between Ethernet ports on an Ethernet link + (which may be a bridged LAN) as identified by the MAC address + [RFC6325]. + + As System IDs of TRILL switches in a campus are required to be + unique, so the MAC addresses of TRILL ES-IS ports on a link MUST be + unique. + + + + + + + + +Eastlake, et al. Standards Track [Page 45] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs + + TRILL ES-IS adjacency formation and Designated RBridge (DRB) election + operate between the ports on the link as specified in [RFC7177] for a + broadcast link. The DRB specifies an ES-IS Designated VLAN for the + link. Adjacency determination, DRB election, and Designated VLANs as + described in this section are distinct from TRILL IS-IS adjacency, + DRB election, and Designated VLANs. + + Although the "Report state" [RFC7177] exists for TRILL ES-IS + adjacencies, such adjacencies are only reported in TRILL ES-IS LSPs, + not in any TRILL IS-IS LSPs. + + End stations supporting TRILL ES-IS MUST assign a unique Port ID to + each of their TRILL ES-IS ports; the Port ID appears in the TRILL + ES-IS Hellos they send. + + TRILL ES-IS has nothing to do with Appointed Forwarders. The + Appointed Forwarders sub-TLV and the VLANs Appointed sub-TLV + [RFC7176] are not used and SHOULD NOT be sent in TRILL ES-IS; if such + a sub-TLV is received in TRILL ES-IS, it is ignored. (The Appointed + Forwarders on a link are determined as specified in [RFC8139], using + TRILL IS-IS.) + + Although some of the ports sending TRILL ES-IS PDUs are on end + stations and thus not on routers (TRILL switches), they nevertheless + may make use of the Router CAPABILITY (#242) [RFC7981] and + MT-Capability (#144) [RFC6329] IS-IS TLVs to indicate capabilities as + specified in [RFC7176]. + + TRILL ES-IS Hellos are like TRILL IS-IS Hellos, but note the + following: in the Special VLANs and Flags sub-TLV [RFC7176], any + TRILL switches advertise a nickname they own, but for end stations, + that field MUST be sent as zero and ignored on receipt. In addition, + in the Special VLANs and Flags sub-TLV (Section 2.2.1 of [RFC7176]) + in a TRILL ES-IS Hello, the AF and TR flag bits MUST be sent as zero, + the AC flag bit MUST be sent as one (1), and all three are ignored + on receipt. + + + + + + + + + + + + + +Eastlake, et al. Standards Track [Page 46] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +5.3. Link State + + The only link-state transmission and synchronization that occur in + TRILL ES-IS are for E-L1CS (Extended Level 1 Circuit Scope) PDUs + [RFC7356]. In particular, the end-station Ethernet ports supporting + TRILL ES-IS do not support the core TRILL IS-IS LSPs and do not + support E-L1FS (Extended Level 1 Flooding Scope) LSPs [RFC7780] (or + the CSNPs or PSNPs (Partial Sequence Number PDUs) [RFC7356] + corresponding to either of them). TLVs and sub-TLVs that would + otherwise be sent in TRILL IS-IS LSPs or E-L1FS LSPs are instead sent + in E-L1CS LSPs. + +6. Security Considerations + + For general TRILL security considerations, see [RFC6325]. + +6.1. Directory Information Security + + Incorrect directory information can result in a variety of security + threats, including those listed below. Directory servers therefore + need to take care to implement and enforce access control policies + that are not overly permissive. + + o Incorrect directory mappings can result in data being delivered to + the wrong end stations, or set of end stations in the case of + multi-destination packets, violating security policy. + + o Missing, incorrect, or inaccessible directory data can result in + denial of service due to sending data packets to black holes or + discarding data on ingress due to incorrect information that their + destinations are not reachable or that their source addresses are + forged. + + For these reasons, whatever server or end station the directory + information resides on, it needs to be protected from unauthorized + modification. Parties authorized to modify directory data can + violate availability and integrity policies. + +6.2. Directory Confidentiality and Privacy + + In implementations of the base TRILL protocol [RFC6325] [RFC7780], + RBridges deal almost exclusively with MAC addresses. The use of + directories to map to/from IP addresses means that RBridges deal more + actively with IP addresses as well. But RBridges in any case would + be exposed to plain-text ARP/ND/SEND/IP traffic and so can see all + this addressing metadata. So, this more-explicit dealing with IP + addresses has little effect on the privacy of end-station traffic. + + + + +Eastlake, et al. Standards Track [Page 47] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + Parties authorized to read directory data can violate privacy + policies for such data. + +6.3. Directory Message Security Considerations + + Push Directory data is distributed through ESADI-LSPs [RFC7357]. + ESADI is built on IS-IS, and such data can thus be authenticated with + the widely implemented and deployed IS-IS PDU security. This + mechanism provides authentication and integrity protection. See + [RFC5304], [RFC5310], and the Security Considerations section of + [RFC7357]. + + Pull Directory queries and responses are transmitted as + RBridge-to-RBridge or native RBridge Channel messages [RFC7178]. + Such messages can be secured by the mechanisms specified in + [RFC7978]. These mechanisms can provide authentication and + confidentiality protection. At the time of this writing, these + security mechanisms are believed to be less widely implemented than + IS-IS security. + +7. IANA Considerations + +7.1. ESADI-Parameter Data Extensions + + IANA has created a subregistry in the "TRILL Parameters" registry + as follows: + + Subregistry: ESADI-Parameter APPsub-TLV Flag Bits + Registration Procedure(s): Standards Action + References: [RFC7357] [RFC8171] + + Bit Mnemonic Description Reference + --- -------- ---------------------------- --------------- + 0 UN Supports Unicast ESADI ESADI [RFC7357] + 1-2 PDSS Push Directory Server Status [RFC8171] + 3-7 - Unassigned + + In addition, the ESADI-Parameter APPsub-TLV is optionally extended, + as provided in its original specification in ESADI [RFC7357], by + 1 byte as shown below. Therefore, [RFC8171] has also been added as a + second reference to the ESADI-Parameter APPsub-TLV in the "TRILL + APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" + registry. + + + + + + + + +Eastlake, et al. Standards Track [Page 48] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + +-+-+-+-+-+-+-+-+ + | Type | (1 byte) + +-+-+-+-+-+-+-+-+ + | Length | (1 byte) + +-+-+-+-+-+-+-+-+ + |R| Priority | (1 byte) + +-+-+-+-+-+-+-+-+ + | CSNP Time | (1 byte) + +-+-+-+-+-+-+-+-+ + | Flags | (1 byte) + +---------------+ + |PushDirPriority| (optional, 1 byte) + +---------------+ + | Reserved for (variable) + | expansion + +-+-+-+-... + + The meanings of all the fields are as specified in ESADI [RFC7357], + 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 the PushDirPriority field is not present + (Length = 3), it is treated as if it were 0x3F. 0x3F is also the + value used and placed here by a TRILL switch whose priority to be a + Push Directory has not been configured. + +7.2. RBridge Channel Protocol Numbers + + IANA has assigned a new RBridge Channel Protocol number (0x005) from + the range assignable by Standards Action [RFC5226] and updated the + subregistry accordingly in the "TRILL Parameters" registry. The + description is "Pull Directory Services". The reference is + [RFC8171]. + +7.3. The Pull Directory (PUL) and No Data (NOD) Bits + + IANA has assigned a previously reserved bit in the Interested VLANs + field of the Interested VLANs sub-TLV and the Interested Labels field + of the Interested Labels sub-TLV [RFC7176] to indicate a Pull + Directory server (PUL). This bit has been added, with this document + as a reference, to the "Interested VLANs Flag Bits" and "Interested + Labels Flag Bits" subregistries created by [RFC7357], as shown below. + + + + + + + + + + +Eastlake, et al. Standards Track [Page 49] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + IANA has assigned a previously reserved bit in the Interested VLANs + field of the Interested VLANs sub-TLV and the Interested Labels field + of the Interested Labels sub-TLV [RFC7176] to indicate No Data (NOD) + (see Section 3.8). This bit has been added, with this document as a + reference, to the "Interested VLANs Flag Bits" and "Interested Labels + Flag Bits" subregistries created by [RFC7357], as shown below. + + The bits are as follows: + + Registry: Interested VLANs Flag Bits + + Bit Mnemonic Description Reference + --- -------- -------------- --------------- + 18 PUL Pull Directory [RFC8171] + 19 NOD No Data [RFC8171] + + Registry: Interested Labels Flag Bits + + Bit Mnemonic Description Reference + --- -------- -------------- --------------- + 6 PUL Pull Directory [RFC8171] + 7 NOD No Data [RFC8171] + +7.4. TRILL Pull Directory QTYPEs + + IANA has created a new registry as follows: + + Name: TRILL Pull Directory Query Types (QTYPEs) + Registration Procedure(s): IETF Review + Reference: [RFC8171] + Initial contents as in Section 3.2.1. + +7.5. Pull Directory Error Code Registries + + IANA has created a new registry and two new indented subregistries + as follows: + + Registry + Name: TRILL Pull Directory Errors + Registration Procedure(s): IETF Review + Reference: [RFC8171] + + Initial contents as in Section 3.6.1. + + + + + + + + +Eastlake, et al. Standards Track [Page 50] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + Subregistry + Name: Sub-codes for TRILL Pull Directory Errors 1 and 3 + Registration Procedure(s): Expert Review + Reference: [RFC8171] + + Initial contents as in Section 3.6.2. + + Subregistry + Name: Sub-codes for TRILL Pull Directory Errors 128 and 131 + Registration Procedure(s): Expert Review + Reference: [RFC8171] + + Initial contents as in Section 3.6.3. + +7.6. TRILL-ES-IS MAC Address + + IANA has assigned a TRILL multicast MAC address (01-80-C2-00-00-47) + from the "TRILL Multicast Addresses" registry. The description is + "TRILL-ES-IS". The reference is [RFC8171]. + +8. References + +8.1. Normative References + + [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or + Converting Network Protocol Addresses to 48.bit Ethernet + Address for Transmission on Ethernet Hardware", STD 37, + RFC 826, DOI 10.17487/RFC0826, November 1982, + <http://www.rfc-editor.org/info/rfc826>. + + [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A + Reverse Address Resolution Protocol", STD 38, RFC 903, + DOI 10.17487/RFC0903, June 1984, + <http://www.rfc-editor.org/info/rfc903>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, + DOI 10.17487/RFC3971, March 2005, + <http://www.rfc-editor.org/info/rfc3971>. + + + + + + + +Eastlake, et al. Standards Track [Page 51] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + DOI 10.17487/RFC4861, September 2007, + <http://www.rfc-editor.org/info/rfc4861>. + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, DOI 10.17487/RFC5304, + October 2008, <http://www.rfc-editor.org/info/rfc5304>. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, DOI 10.17487/RFC5310, + February 2009, <http://www.rfc-editor.org/info/rfc5310>. + + [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 + Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, + <http://www.rfc-editor.org/info/rfc6165>. + + [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. + Ghanwani, "Routing Bridges (RBridges): Base Protocol + Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, + <http://www.rfc-editor.org/info/rfc6325>. + + [RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, + A., and P. Unbehagen, "IS-IS Extensions Supporting + IEEE 802.1aq Shortest Path Bridging", RFC 6329, + DOI 10.17487/RFC6329, April 2012, + <http://www.rfc-editor.org/info/rfc6329>. + + [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and + IETF Protocol and Documentation Usage for IEEE 802 + Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, + October 2013, <http://www.rfc-editor.org/info/rfc7042>. + + [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and + D. Dutt, "Transparent Interconnection of Lots of Links + (TRILL): Fine-Grained Labeling", RFC 7172, + DOI 10.17487/RFC7172, May 2014, + <http://www.rfc-editor.org/info/rfc7172>. + + [RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, + D., and A. Banerjee, "Transparent Interconnection of Lots + of Links (TRILL) Use of IS-IS", RFC 7176, + DOI 10.17487/RFC7176, May 2014, + <http://www.rfc-editor.org/info/rfc7176>. + + + + + + +Eastlake, et al. Standards Track [Page 52] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + + [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and + V. Manral, "Transparent Interconnection of Lots of Links + (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, + May 2014, <http://www.rfc-editor.org/info/rfc7177>. + + [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. + Ward, "Transparent Interconnection of Lots of Links + (TRILL): RBridge Channel Support", RFC 7178, + DOI 10.17487/RFC7178, May 2014, + <http://www.rfc-editor.org/info/rfc7178>. + + [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding + Scope Link State PDUs (LSPs)", RFC 7356, + DOI 10.17487/RFC7356, September 2014, + <http://www.rfc-editor.org/info/rfc7356>. + + [RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. + Stokes, "Transparent Interconnection of Lots of Links + (TRILL): End Station Address Distribution Information + (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, + September 2014, <http://www.rfc-editor.org/info/rfc7357>. + + [RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., + Ghanwani, A., and S. Gupta, "Transparent Interconnection + of Lots of Links (TRILL): Clarifications, Corrections, and + Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, + <http://www.rfc-editor.org/info/rfc7780>. + + [RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent + Interconnection of Lots of Links (TRILL): Interface + Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, + August 2016, <http://www.rfc-editor.org/info/rfc7961>. + + [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions + for Advertising Router Information", RFC 7981, + DOI 10.17487/RFC7981, October 2016, + <http://www.rfc-editor.org/info/rfc7981>. + + [RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. + Hu, "Transparent Interconnection of Lots of Links (TRILL): + Appointed Forwarders", RFC 8139, DOI 10.17487/RFC7961, + June 2017, <http://www.rfc-editor.org/info/rfc8139>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + <http://www.rfc-editor.org/info/rfc8174>. + + + + +Eastlake, et al. Standards Track [Page 53] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +8.2. Informative References + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. + Gashinsky, "Directory Assistance Problem and High-Level + Design Proposal", RFC 7067, DOI 10.17487/RFC7067, + November 2013, <http://www.rfc-editor.org/info/rfc7067>. + + [RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent + Interconnection of Lots of Links (TRILL): RBridge Channel + Header Extension", RFC 7978, DOI 10.17487/RFC7978, + September 2016, <http://www.rfc-editor.org/info/rfc7978>. + + [ARPND] Li, Y., Eastlake 3rd, D., Dunbar, L., Perlman, R., and M. + Umair, "TRILL: ARP/ND Optimization", Work in Progress, + draft-ietf-trill-arp-optimization-08, April 2017. + + [DirAsstEncap] + Dunbar, L., Eastlake 3rd, D., and R. Perlman, "Directory + Assisted TRILL Encapsulation", Work in Progress, + draft-ietf-trill-directory-assisted-encap-05, May 2017. + + [ISO9542] ISO 9542:1988, "Information processing systems -- + Telecommunications and information exchange between + systems -- End system to Intermediate system routeing + exchange protocol for use in conjunction with the Protocol + for providing the connectionless-mode network service + (ISO 8473)", August 1988. + + [SmartEN] Perlman, R., Hu, F., Eastlake 3rd, D., Krupakaran, K., and + T. Liao, "TRILL Smart Endnodes", Work in Progress, + draft-ietf-trill-smart-endnodes-05, February 2017. + + [X.233] International Telecommunication Union, ITU-T + Recommendation X.233: "Information technology - Protocol + for providing the connectionless-mode network service: + Protocol specification", August 1997, + <https://www.itu.int/rec/T-REC-X.233/en>. + + + + + + + + + +Eastlake, et al. Standards Track [Page 54] + +RFC 8171 TRILL: Directory Service Mechanisms June 2017 + + +Acknowledgments + + The contributions of the following persons are gratefully + acknowledged: + + Amanda Baber, Matthew Bocci, Alissa Cooper, Stephen Farrell, + Daniel Franke, Igor Gashinsky, Joel Halpern, Susan Hares, Alexey + Melnikov, Gayle Noble, and Tianran Zhou. + +Authors' Addresses + + Donald Eastlake 3rd + Huawei Technologies + 155 Beaver Street + Milford, MA 01757 + United States of America + Phone: +1-508-333-2270 + Email: d3e3e3@gmail.com + + + Linda Dunbar + Huawei Technologies + 5430 Legacy Drive, Suite #175 + Plano, TX 75024 + United States of America + Phone: +1-469-277-5840 + Email: ldunbar@huawei.com + + + Radia Perlman + EMC + 2010 256th Avenue NE, #200 + Bellevue, WA 98007 + United States of America + Email: Radia@alum.mit.edu + + + Yizhou Li + Huawei Technologies + 101 Software Avenue + Nanjing 210012 + China + Phone: +86-25-56622310 + Email: liyizhou@huawei.com + + + + + + + +Eastlake, et al. Standards Track [Page 55] + |