idnits 2.17.1 draft-ietf-trill-directory-assist-mechanisms-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2015) is 3233 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7042 (Obsoleted by RFC 9542) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Linda Dunbar 3 Huawei 4 Radia Perlman 5 EMC 6 Igor Gashinsky 7 Yahoo 8 Yizhou Li 9 Huawei 10 Expires: December 19, 2015 June 20, 2015 12 TRILL: Edge Directory Assist Mechanisms 13 15 Abstract 16 This document describes mechanisms for providing directory service to 17 TRILL (Transparent Interconnection of Lots of Links) edge switches. 18 The directory information provided can be used in reducing multi- 19 destination traffic, particularly ARP/ND and unknown unicast 20 flooding. It can also be used to detect traffic with forged source 21 addresses. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the TRILL working group mailing list. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 43 Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 1. Introduction............................................3 49 1.1 Uses of Directory Information..........................3 50 1.2 Terminology............................................4 52 2. Push Model Directory Assistance Mechanisms..............6 53 2.1 Requesting Push Service................................6 54 2.2 Push Directory Servers.................................6 55 2.3 Push Directory Server State Machine....................7 56 2.3.1 Push Directory States................................8 57 2.3.2 Push Directory Events and Conditions.................9 58 2.3.3 State Transition Diagram and Table..................10 59 2.4 Additional Push Details...............................12 60 2.5 Primary to Secondary Server Push Service..............13 62 3. Pull Model Directory Assistance Mechanisms.............14 63 3.1 Pull Directory Message Common Format..................15 64 3.2 Pull Directory Query and Response Messages............16 65 3.2.1 Pull Directory Query Message Format.................16 66 3.2.2 Pull Directory Responses............................19 67 3.2.2.1 Pull Directory Response Message Format............19 68 3.2.2.2 Pull Directory Forwarding.........................21 69 3.3 Cache Consistency.....................................22 70 3.3.1 Update Message Format...............................25 71 3.3.2 Acknowledge Message Format..........................26 72 3.4 Summary of Records Formats in Messages................26 73 3.5 Pull Directory Hosted on an End Station...............27 74 3.6 Pull Directory Message Errors.........................28 75 3.6.1 Error Codes.........................................29 76 3.6.2 Sub-Errors Under Error Codes 1 and 3................30 77 3.6.3 Sub-Errors Under Error Codes 128 and 131............30 78 3.7 Additional Pull Details...............................31 79 3.8 The No Data Flag......................................31 81 4. Directory Use Strategies and Push-Pull Hybrids.........33 82 5. Security Considerations................................35 84 6. IANA Considerations....................................36 85 6.1 ESADI-Parameter Data Extensions.......................36 86 6.2 RBridge Channel Protocol Number.......................37 87 6.3 The Pull Directory (PUL) and No Data (NOD) Bits.......37 88 6.4 TRILL Pull Directory QTYPEs...........................37 89 6.5 Pull Directory Error Code Registries..................38 91 Normative References......................................39 92 Informational References..................................40 94 Acknowledgments...........................................41 95 Authors' Addresses........................................42 97 1. Introduction 99 [RFC7067] gives a problem statement and high level design for using 100 directory servers to assist TRILL [RFC6325] edge nodes in reducing 101 multi-destination ARP/ND [ARPreduction], reducing unknown unicast 102 flooding traffic, and improving security against address spoofing 103 within a TRILL campus. Because multi-destination traffic becomes an 104 increasing burden as a network scales up in number of nodes, reducing 105 ARP/ND and unknown unicast flooding improves TRILL network 106 scalability. This document describes specific mechanisms for 107 directory servers to assist TRILL edge nodes. These mechanisms are 108 optional to implement. 110 The information held by the Directory(s) is address mapping and 111 reachability information. Most commonly, what MAC address [RFC7042] 112 corresponds to an IP address within a Data Label (VLAN or FGL (Fine 113 Grained Label [RFC7172])) and the egress TRILL switch (RBridge), and 114 optionally what specific TRILL switch port, from which that MAC 115 address is reachable. But it could be what IP address corresponds to 116 a MAC address or possibly other address mappings or reachability. 118 In the data center environment, it is common for orchestration 119 software to know and control where all the IP addresses, MAC 120 addresses, and VLANs/tenants are in a data center. Thus such 121 orchestration software can be appropriate for providing the directory 122 function or for supplying the Directory(s) with directory 123 information. 125 Directory services can be offered in a Push or Pull Mode [RFC7067]. 126 Push Mode, in which a directory server pushes information to TRILL 127 switches indicating interest, is specified in Section 2. Pull Mode, 128 in which a TRILL switch queries a server for the information it 129 wants, is specified in Section 3. More detail on modes of operation, 130 including hybrid Push/Pull, are provided in Section 4. 132 The mechanism used to initially populate directory data in primary 133 servers is beyond the scope of this document. A primary server can 134 use the Push Directory service to provide directory data to secondary 135 servers as described in Section 2.5. 137 1.1 Uses of Directory Information 139 A TRILL switch can consult Directory information whenever it wants, 140 by (1) searching through information that has been retained after 141 being pushed to it or pulled by it or (2) by requesting information 142 from a Pull Directory. However, the following are expected to be the 143 most common circumstances leading to directory information use. All 144 of these are cases of ingressing (or originating) a native frame. 146 1. ARP requests and replies [RFC826] are normally broadcast. But a 147 directory assisted edge TRILL switches could intercept ARP 148 messages and reply if the TRILL switch has the relevant 149 information. 151 2. IPv6 ND (Neighbor Discovery [RFC4861]) requests and replies are 152 normally multicast. Except in the case of Secure ND [RFC3971] 153 where possession of the right keying material might be required, 154 directory assisted edge TRILL switches could intercept ND messages 155 and reply if the TRILL switch has the relevant information. 157 3. Unknown destination MAC addresses. An edge TRILL switch ingressing 158 a native frame necessarily has to determine if it knows the egress 159 RBridge from which the destination MAC address of the frame (in 160 the frame's VLAN or FGL) is reachable. It might learn that 161 information from the directory or could query the directory if it 162 does not know. Furthermore, if the edge TRILL switch has complete 163 directory information, it can detect a forged source MAC address 164 in the native frame and discard the frame in that case. 166 4. RARP [RFC903] is similar to ARP as above. 168 1.2 Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 The terminology and acronyms of [RFC6325] are used herein along with 175 the following: 177 CSNP Time: Complete Sequence Number PDU Time. See ESDADI [RFC7357] 178 and Section 6.1 below. 180 Data Label: VLAN or FGL. 182 FGL: Fine Grained Label [RFC7172]. 184 Host: Application running on a physical server or a virtual machine. 185 A host must have a MAC address and usually has at least one IP 186 address. 188 IP: Internet Protocol. In this document, IP includes both IPv4 and 189 IPv6. 191 MacDA: Destination MAC address. 193 PDSS: Push Directory Server Status. See Sections 2 and 6.1 below. 195 PUL: Pull Directory flag bit. See Sections 3 and 6.3 below. 197 primary server: A Directory server that obtains the information it is 198 serving up by a reliable mechanism outside the scope of this 199 document designed to assure the freshness of that information. 200 (See secondary server.) 202 RBridge: An alternative name for a TRILL switch. 204 secondary server: A Directory server that obtains the information it 205 is serving up from one or more primary servers. 207 TRILL: Transparent Interconnection of Lots of Links or Tunneled 208 Routing in the Link Layer. 210 TRILL switch: A device that implements the TRILL protocol. 212 2. Push Model Directory Assistance Mechanisms 214 In the Push Model [RFC7067], one or more Push Directory servers 215 reside at TRILL switches and push down the address mapping 216 information for the various addresses associated with end station 217 interfaces and the TRILL switches from which those interfaces are 218 reachable [IA]. This service is scoped by Data Label (VLAN or FGL 219 [RFC7172]). A Push Directory also advertises whether or not it 220 believes it has pushed complete mapping information for a Data Label. 221 It might be pushing only a subset of the mapping and/or reachability 222 information for a Data Label. The Push Model uses the ESADI [RFC7357] 223 protocol as its distribution mechanism. 225 With the Push Model, if complete address mapping information for a 226 Data Label is being pushed, a TRILL switch (RBridge) which has that 227 complete information and is ingressing a native frame can simply drop 228 the frame if the destination unicast MAC address can't be found in 229 the mapping information available, instead of flooding the frame 230 (ingressing it as an unknown MAC destination TRILL Data frame). But 231 this will result in lost traffic if ingress TRILL switch's directory 232 information is incomplete. 234 2.1 Requesting Push Service 236 In the Push Model, it is necessary to have a way for a TRILL switch 237 to subscribe to information from the directory server(s). TRILL 238 switches simply use the ESADI [RFC7357] protocol mechanism to 239 announce, in their core IS-IS LSPs, the Data Labels for which they 240 are participating in ESADI by using the Interested VLANs and/or 241 Interested Labels sub-TLVs [RFC7176]. This will cause them to be 242 pushed the Directory information for all such Data Labels that are 243 being served by the one or more Push Directory servers. 245 2.2 Push Directory Servers 247 Push Directory servers advertise their availability to push the 248 mapping information for a particular Data Label to each other and to 249 ESADI participants for that Data Label through ESADI by setting the 250 PDSS (Push Directory Server Status) in their ESADI Parameter APPsub- 251 TLV for that ESADI instance (see [RFC7357] and Section 6.1) to a non- 252 zero value. Each Push Directory server MUST participate in ESADI for 253 the Data Labels for which it will push mappings and set the PDSS 254 field in its ESADI-Parameters APPsub-TLV for that Data Label. 256 For robustness, it is useful to have multiple Push Directory Servers 257 for each Data Label. Each Push Directory server is configured with a 258 number N in the range 1 to 8, which defaults to 2, for each Data 259 Label for which it can push directory information. If the Push 260 Directory servers for a Data Label are configured consistently with 261 the same N and at least N servers are available, then N copies of 262 that directory will will be pushed. 264 Each Push Directory server also has an 8-bit priority to be Active 265 (see Section 6.1 of this document). This priority is treated as an 266 unsigned integer where larger magnitude means higher priority. This 267 priority appears in its ESADI Parameter APPsub-TLV. 269 For each Data Label it can serve, each Push Directory server checks 270 to see if there are enough higher priority servers to push the 271 desired number of copies. It does this by ordering, by priority, the 272 Push Directory servers that it can see in the ESADI link state 273 database for that Data Label that are data reachable [rfc7180bis] and 274 determines its own position in that order. If a Push Directory server 275 is configured to believe that N copies of the mappings for a Data 276 Label should be pushed and finds that it is number K in the priority 277 ordering (where the first is highest priority and the last is 278 lowest), then if K is less than or equal to N the Push Directory 279 server is Active. If K is greater than N it is Stand-By. Active and 280 Stand-By behavior are specified below. 282 For a Push Directory to reside on an end station, one or more TRILL 283 switches locally connected to that end station must proxy for the 284 Push Directory server and advertise themselves as Push Directory 285 servers. It appears to the rest of the TRILL campus that these TRILL 286 switches (that are proxying for the end station) are the Push 287 Directory server(s). The protocol between such a Push Directory end 288 station and the one or more proxying TRILL switches acting as Push 289 Directory servers is beyond the scope of this document. 291 2.3 Push Directory Server State Machine 293 The subsections below describe the states, events, and corresponding 294 actions for Push Directory servers. 296 The meaning of the value of the PDSS field in a Push Directory's 297 ESADI Parameter APPsub-TLV is summarized in the table below. 299 PDSS Meaning 300 ---- ---------- 301 0 Not a Push Directory Server 302 1 Push Directory Server in Stand-By Mode 303 2 Push Directory Server in Active Mode but not complete 304 3 Push Directory Server in Active Mode that has pushed 305 complete data 307 2.3.1 Push Directory States 309 A Push Directory Server is in one of seven states, as listed below, 310 for each Data Label it can serve. The name of each state is followed 311 by a symbol that starts and ends with an angel bracket and represents 312 the state. The value that the Push Directory Server advertises in 313 PDSS is determined by the state. In addition, it has an internal 314 State-Transition-Time variable for each Data Label it serves which is 315 set at each state transition and which enables it to determine how 316 long it has been in its current state for that Data Label. 318 Down : A completely shut down virtual state defined for 319 convenience in specifying state diagrams. A Push Directory Server 320 in this state does not advertise any Push Directory data. It may 321 be participating in ESDADI [RFC7357] with the PDSS field zero in 322 its ESADI-Parameters or might be not participating in ESADI at 323 all. (All states other than the Down state are considered to be Up 324 states and imply a non-zero PDSS field.) 326 Stand-By : No Push Directory data is advertised. Any outstanding 327 EASDI-LSP fragments containing directory data are updated to 328 remove that data and if the result is an empty fragment (contains 329 nothing except possibly an Authentication TLV), the fragment is 330 purged. The Push Directory participates in ESDADI [RFC7357] and 331 advertises its ESADI fragment zero that includes an ESADI- 332 Parameters APPsub-TLV with the PDSS field set to 1. 334 Active : The PDSS field in the ESADI-Parameters is set to 2. If 335 a Push Directory server is Active, it advertises its directory 336 data and any changes through ESADI [RFC7357] in its ESADI-LSPs 337 using the Interface Addresses [IA] APPsub-TLV and updates that 338 information as it changes. 340 Active Completing : Same behavior as the Active state except 341 that it responds differently to events. The purpose of this state 342 is to be sure there has been enough time for directory information 343 to propagate to subscribing edge TRILL switches before the 344 Directory Server advertises that the information is complete. 346 Active Complete : The same behavior as Active except that the 347 PDSS field in the ESADI-Parameters APPsub-TLV is set to 3 and the 348 server responds differently to events. 350 Going Stand-By : The same behavior as Active except that it 351 responds differently to events. The purpose of this state is to be 352 sure that the information, that the directory is no longer 353 complete, has enough time to propagate to edge TRILL switches 354 before the Directory Server stops advertising updates to the 355 information. 357 Active Uncompleting : The same behavior as Active except that it 358 responds differently to events. The purpose of this state is to be 359 sure that the information, that the directory is no longer 360 complete, has enough time to propagate to edge TRILL switches 361 before the Directory Server might stop advertising updates to the 362 information. (See note below.) 364 Note: It might appear that a Push Directory could transition 365 directly from Active Complete to Active, since Active state 366 continues to advertise updates, eliminating the need for the 367 Active Uncompleting transition state. But consider the case of 368 the Push Directory being configured to be incomplete and then 369 the Stand-By Condition (see Section 2.3.2) occurring 370 immediately thereafter. If the first of these two events caused 371 the server to transition directly to the Active state then, 372 when the Stand-By Condition occurred, it would immediately 373 transition to Stand-By and stop advertising updates even though 374 there might not have been enough time for knowledge of its 375 incompleteness to have propagated to all edge TRILL switches. 377 The following table summarizes PDSS value for each state: 379 State PDSS 380 ---------- ------ 381 Down 0 382 Stand-By 1 383 Active 2 384 Active Completing 2 385 Active Complete 3 386 Going Stand-By 2 387 Active Uncompleting 2 389 2.3.2 Push Directory Events and Conditions 391 Three auxiliary conditions referenced later in this section are 392 defined as follows for convenience: 394 The Activate Condition: In order to have the desired number of Push 395 Directory servers pushing data, this Push Directory server should 396 be active. This is determined by the server finding that it is 397 priority K among the data reachable Push Directory servers (where 398 highest priority is 1), it is configured that there should be N 399 copies pushed, and K is less than or equal to N. For example, the 400 Push Directory server is configured that 2 copies should be pushed 401 and finds that it is priority 1 or 2 among the Push Directory 402 servers it can see. 404 The Stand-By Condition: In order to have the desired number of Push 405 Directory servers pushing data, this Push Directory server should 406 be stand-by (not active). This is determined by the server finding 407 that it is priority K among the data reachable Push Directory 408 servers (where highest priority is 1), it is configured that there 409 should be N copies pushed, and K is greater than N. For example, 410 the Push Directory server is configured that 2 copies should be 411 pushed and finds that it is priority 3 or lower priority (higher 412 number) among the Push directory servers it can see. 414 The Time Condition: The Push Directory server has been in its current 415 state for a configurable amount of time that defaults to twice its 416 CSNP time (see Section 6.1).) 418 The events and conditions listed below cause state transitions in 419 Push Directory servers. 421 1. Push Directory server was Down but is now Up. 423 2. The Push Directory server or the TRILL switch on which it resides 424 is being shut down. 426 3. The Activate Condition is met and the server is not configured to 427 believe it has complete data. 429 4. The Stand-By Condition is met. 431 5. The Activate Condition is met and the server is configured to 432 believe it has complete data. 434 6. The server is configured to believe it does not have complete 435 data. 437 7. The Time Condition is met. 439 2.3.3 State Transition Diagram and Table 441 The state transition table is as follows: 443 State|Down|Stand-By|Active| Active | Active | Going | Active 444 -----+ | | |Completing|Complete|Stand-By|Uncompleting 445 Event|| | | | | | 446 -----+----+--------+------+----------+--------+---------+------------ 447 1 || | | | | | 448 2 || | | | | | 449 3 || | | | | | 450 4 || | | | | | 451 5 || | | | | | 452 6 || | | | | | 453 7 || | | | | | 455 The above state table is equivalent to the following transition 456 diagram: 458 +-----------+ 459 | Down |<---------+ 460 +-----------+ | 461 |1 ^ | 3,4,5,6,7 | 462 | | +------------+ 463 V |2 464 +---------------+ 465 | Stand-By |<------------------------------------------+ 466 +---------------+ ^ ^ ^ | 467 |5 |3 |1,4,6,7 | | | | 468 | | +---------+ | | | 469 | V |2,4 | | 470 | +---------------------+ | | 471 | | Active |<---------|-----------------+ | 472 | +---------------------+ ^ | | | 473 | |5 ^ |1,3,6,7 ^ | | | | 474 | | | | | | | | | 475 | | | +---------+ | | | | 476 | | | | | | | 477 V V |3,6 | | | | 478 +------------------------+ | | | | 479 | Active Completing |------------+ | | 480 +------------------------+ 2,4 | | | 481 |7 |1,5 ^ | | | 482 | | | | | | 483 | +-------+ | | | 484 | | | | 485 | +--------------------------------------+ | | 486 | | | | | | 487 V V |7 |5 |3 |7 488 +---------------+ 3,6 +----------------+ 4 +----------------+ 489 | Active |------->| Active |----->| Going | 490 | Complete | | Uncompleting | | Stand-By | 491 | |<-------| | | | 492 +---------------+ 5 +----------------+ +----------------+ 493 |1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^ 494 | | | | | | | | 495 +-------+ | +------------+ | +--------+ 496 | | 497 +------------------------------------+ 499 Figure 2. Push Server State Diagram 501 2.4 Additional Push Details 503 Push Directory mappings can be distinguished from other data 504 distributed through ESADI because mappings are distributed only with 505 the Interface Addresses APPsub-TLV [IA] and are flagged in that 506 APPsub-TLV as being Push Directory data. 508 TRILL switches, whether or not they are a Push Directory server, MAY 509 continue to advertise any locally learned MAC attachment information 510 in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165]. 511 However, if a Data Label is being served by complete Push Directory 512 servers, advertising such locally learned MAC attachment generally 513 SHOULD NOT be done as it would not add anything and would just waste 514 bandwidth and ESADI link state space. An exception might be when a 515 TRILL switch learns local MAC connectivity and that information 516 appears to be missing from the directory mapping. 518 Because a Push Directory server needs to advertise interest in one or 519 more Data Labels even though it might not want to receive multi- 520 destination data in those Data Labels, the No Data (NOD) flag bit is 521 provided as discussed in Section 3.8. 523 When a Push Directory server is no longer data reachable 524 [rfc7180bis], TRILL switches MUST ignore any Push Directory data from 525 that server because it is no longer being updated and may be stale. 527 The nature of dynamic distributed asynchronous systems is such that 528 it is impossible for a TRILL switch receiving Push Directory 529 information to be absolutely certain that it has complete 530 information. However, it can obtain a reasonable assurance of 531 complete information by requiring two conditions to be met: 532 1. The PDSS field is 3 in the ESADI zero fragment from the server 533 for the relevant Data Label. 534 2. In so far as it can tell, it has had continuous data 535 connectivity to the server for a configurable amount of time 536 that defaults to twice the server's CSNP time. 537 Condition 2 is necessary because a client TRILL switch might be just 538 coming up and receive an EASDI LSP meeting the requirement in 539 condition 1 above but has not yet received all of the ESADI LSP 540 fragment from the Push Directory server. 542 There may be conflicts between mapping information from different 543 Push Directory servers or conflicts between locally learned 544 information and information received from a Push Directory server. In 545 case of such conflicts, information with a higher confidence value 546 [RFC6325] is preferred over information with a lower confidence. In 547 case of equal confidence, Push Directory information is preferred to 548 locally learned information and if information from Push Directory 549 servers conflicts, the information from the higher priority Push 550 Directory server is preferred. 552 2.5 Primary to Secondary Server Push Service 554 A secondary Push or Pull Directory server is one that obtains its 555 data from a primary directory server. Other techniques MAY be used 556 but, by default, this data transfer occurs through the primary server 557 acting as a Push Directory server for the Data Labels involved while 558 the secondary directory server takes the pushed data it receives from 559 the highest priority Push Directory server and re-originates it. Such 560 a secondary server may be a Push Directory server or a Pull Directory 561 server or both for any particular Data Label. Because the data from a 562 secondary server will necessarily be at least a little less fresh 563 than that from a primary server, it is RECOMMENDED that the re- 564 originated secondary server data be given a confidence level of one 565 less than that of the data as received from the primary (or unchanged 566 if it is already of minimum confidence). 568 3. Pull Model Directory Assistance Mechanisms 570 In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory 571 information from an appropriate Directory Server when needed. 573 Pull Directory servers for a particular Data Label X are found by 574 looking in the core TRILL IS-IS link state database for data 575 reachable [rfc7180bis] TRILL switches that advertise themselves by 576 having the Pull Directory flag (PUL) on in their Interested VLANs or 577 Interested Labels sub-TLV (see Section 6.3)) for that Data Label. If 578 multiple such TRILL switches indicate that they are Pull Directory 579 Servers for a particular Data Label, pull requests can be sent to any 580 one or more of them but it is RECOMMENDED that pull requests be 581 preferentially sent to the server or servers that are lowest cost 582 from the requesting TRILL switch. 584 Pull Directory requests are sent by enclosing them in an RBridge 585 Channel [RFC7178] message using the Pull Directory channel protocol 586 number (see Section 6.2). Responses are returned in an RBridge 587 Channel message using the same channel protocol number. See Section 588 3.2 for Query and Response Message formats. For cache consistency or 589 notification purposes, Pull Directory servers, under certain 590 conditions, MUST send unsolicited Update Messages to client TRILL 591 switches they believe may be holding old data and those clients can 592 acknowledge such updates, as described in Section 3.3. All these 593 messages have a common header as described in Section 3.1. Errors can 594 be returned for queries or updates as described in Section 3.6. 596 The requests to Pull Directory Servers are typically derived from 597 ingressed ARP [RFC826], ND [RFC4861], or RARP [RFC903] messages, or 598 data frames with unknown unicast destination MAC addresses, 599 intercepted by an ingress TRILL switch as described in Section 1.1. 601 Pull Directory responses include an amount of time for which the 602 response should be considered valid. This includes negative responses 603 that indicate no data is available. It is RECOMMENDED that both 604 positive responses with data and negative responses can be cached and 605 used to locally handle ARP, ND, RARP, unknown destination MAC frames, 606 or the like, until the responses expire. If information previously 607 pulled is about to expire, a TRILL switch MAY try to refresh it by 608 issuing a new pull request but, to avoid unnecessary requests, SHOULD 609 NOT do so if it has not been recently used. The validity timer of 610 cached Pull Directory responses is NOT reset or extended merely 611 because that cache entry is used. 613 3.1 Pull Directory Message Common Format 615 All Pull Directory messages are transmitted as the payload of RBridge 616 Channel messages [RFC7178]. Pull Directory messages are formatted as 617 described herein starting with the following common 8-byte header: 619 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Ver | Type | Flags | Count | Err | SubErr | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Sequence Number | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Type Specific Payload - variable length 627 +-+-+- ... 629 Ver: Version of the Pull Directory protocol as an unsigned 630 integer. Version zero is specified in this document. 632 Type: The Pull Directory message type as follows: 634 Type Section Name 635 ---- ------- -------- 636 0 - Reserved 637 1 3.2.1 Query 638 2 3.2.2 Response 639 3 3.3.1 Update 640 4 3.3.2 Acknowledge 641 5-14 - Unassigned 642 15 - Reserved 644 Flags: Four flag bits whose meaning depends on the Pull Directory 645 message Type. Flags whose meanings are not specified are 646 reserved, MUST be sent as zero, and MUST be ignored on receipt. 648 Count: Pull Directory message types specified herein have zero or 649 more occurrences of a Record as part of the type specific 650 payload. The Count field is the number of occurrences of that 651 Record as an unsigned integer. For any Pull Directory messages 652 not structured with such occurrences, this field MUST be sent 653 as zero and ignored on receipt. 655 Err, SubErr: The error and suberror fields are only used in 656 messages that are in the nature of replies. In messages that 657 are requests or updates, these fields MUST be sent as zero and 658 ignored on receipt. An Err field containing the value zero 659 means no error. The meaning of values in the SubErr field 660 depends on the value of the Err field but in all cases, a zero 661 SubErr field is allowed and provides no additional information 662 beyond the value of the Err field. 664 Sequence Number: An identifying 32-bit quantity set by the TRILL 665 switch sending a request or other unsolicited message and 666 returned in every corresponding reply or acknowledgement. It is 667 used to match up responses with the message to which they 668 respond. 670 Type Specific Payload: Format depends on the Pull Directory 671 message Type. 673 3.2 Pull Directory Query and Response Messages 675 The format of the Pull Directory Query and Response Messages is 676 specified below. 678 3.2.1 Pull Directory Query Message Format 680 A Pull Directory Query Message is sent as the Channel Protocol 681 specific content of an RBridge Channel message [RFC7178] TRILL Data 682 packet or as a native RBridge Channel data frame (see Section 3.5). 683 The Data Label of the packet is the Data Label in which the query is 684 being made. The priority of the channel message is a mapping of the 685 priority of the frame being ingressed that caused the query with the 686 default mapping depending, per Data Label, on the strategy (see 687 Section 4) or a configured priority for generated queries. (Generated 688 queries are those not the result of a mapping. For example, a query 689 to refresh a cache entry.) The Channel Protocol specific data is 690 formatted as a header and a sequence of zero or more QUERY Records as 691 follows: 693 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Ver | Type | Flags | Count | Err | SubErr | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Sequence Number | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | QUERY 1 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 702 | QUERY 2 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 704 | ... 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 706 | QUERY K 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 709 Ver, Sequence Number: See 3.1. 711 Type: 1 for Query. Queries received by an TRILL switch that is not 712 a Pull Directory for the relevant Data Label result in an error 713 response (see Section 3.6) unless inhibited by rate limiting. 714 (See [RFC7178] for response if the Pull Directory RBridge 715 Channel protocol is not enabled.) 717 Flags, Err, and SubErr: MUST be sent as zero and ignored on 718 receipt. 720 Count: Number of QUERY Records present. A Query Message Count of 721 zero is explicitly allowed, for the purpose of pinging a Pull 722 Directory server to see if it is responding. On receipt of such 723 an empty Query Message, a Response Message that also has a 724 Count of zero is sent unless inhibited by rate limiting. 726 QUERY: Each QUERY Record within a Pull Directory Query Message is 727 formatted as follows: 729 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 730 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 731 | SIZE |FL| RESV | QTYPE | 732 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 733 If QTYPE = 1 734 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 735 | AFN | 736 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 737 | Query address ... 738 +--+--+--+--+--+--+--+--+--+--+--... 739 If QTYPE = 2, 3, 4, or 5 740 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 741 | Query frame ... 742 +--+--+--+--+--+--+--+--+--+--+--... 744 SIZE: Size of the QUERY Record in bytes as an unsigned integer 745 not including the SIZE field and following byte. A value of 746 SIZE so large that the material doesn't fit in the Query 747 Message indicates a malformed QUERY Record. The QUERY Record 748 with the illegal SIZE value and any subsequent QUERY Records 749 MUST be ignored and the entire Query Message MAY be ignored. 751 FL: The FLooded flag that is ignored if QTYPE is zero. If QTYPE 752 is 2 through 5 and the directory information sought is not 753 found, the frame provided is flooded, otherwise it is not 754 forwarded. See Section 3.2.2.2. 756 RESV: A block of three reserved bits. MUST be sent as zero and 757 ignored on receipt. 759 QTYPE: There are several types of QUERY Records currently 760 defined in two classes as follows: (1) a QUERY Record that 761 provides an explicit address and asks for all addresses for 762 the interface specified by the query address and (2) a QUERY 763 Record that includes a frame. The fields of each are 764 specified below. Values of QTYPE are as follows: 766 QTYPE Description 767 ----- ----------- 768 0 Reserved 769 1 Address query 770 2 ARP query frame 771 3 ND query frame 772 4 RARP query frame 773 5 Unknown unicast MAC query frame 774 6-14 Unassigned 775 15 Reserved 777 AFN: Address Family Number of the query address. 779 Query Address: The query is asking for any other addresses, 780 and the nickname of the TRILL switch from which they are 781 reachable, that correspond to the same interface, within 782 the data label of the query. Typically that would be 783 either (1) a MAC address with the querying TRILL switch 784 primarily interested in the TRILL switch by which that 785 MAC address is reachable, or (2) an IP address with the 786 querying TRILL switch interested in the corresponding MAC 787 address and the TRILL switch by which that MAC address is 788 reachable. But it could be some other address type. 790 Query Frame: Where a QUERY Record is the result of an ARP, 791 ND, RARP, or unknown unicast MAC destination address, the 792 ingress TRILL switch MAY send the frame to a Pull 793 Directory Server if the frame is small enough that the 794 resulting Query Message fits into a TRILL Data packet 795 within the campus MTU. 797 If no response is received to a Pull Directory Query Message within a 798 timeout configurable in milliseconds that defaults to 100, the Query 799 Message should be re-transmitted with the same Sequence Number up to 800 a configurable number of times that defaults to three. If there are 801 multiple QUERY Records in a Query Message, responses can be received 802 to various subsets of these QUERY Records before the timeout. In that 803 case, the remaining unanswered QUERY Records should be re-sent in a 804 new Query Message with a new sequence number. If a TRILL switch is 805 not capable of handling partial responses to queries with multiple 806 QUERY Records, it MUST NOT send a Request Message with more than one 807 QUERY Record in it. 809 See Section 3.6 for a discussion of how Query Message errors are 810 handled. 812 3.2.2 Pull Directory Responses 814 A Pull Directory Query Message results in a Pull Directory Response 815 Message as described in Section 3.2.2.1. 817 In addition, if the QUERY Record QTYPE was 2, 3, 4, or 5, the frame 818 included in the Query may be modified and forwarded by the Pull 819 Directory server as described in Section 3.2.2.2. 821 3.2.2.1 Pull Directory Response Message Format 823 Pull Directory Response Messages are sent as the Channel Protocol 824 specific content of an RBridge Channel message [RFC7178] TRILL Data 825 packet or as a native RBridge Channel data frame (see Section 3.5). 826 Responses are sent with the same Data Label and priority as the Query 827 Message to which they correspond except that the Response Message 828 priority is limited to be not more than a configured value. This 829 priority limit is configurable per TRILL switch and defaults to 830 priority 6. Pull Directory Response Messages SHOULD NOT be sent with 831 priority 7 as that priority SHOULD be reserved for messages critical 832 to network connectivity. 834 The RBridge Channel protocol specific data format is as follows: 836 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Ver | Type | Flags | Count | Err | SubErr | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Sequence Number | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | RESPONSE 1 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 845 | RESPONSE 2 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 847 | ... 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 849 | RESPONSE K 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 852 Ver, Sequence Number: As specified in Section 3.1. 854 Type: 2 = Response. 856 Flags: MUST be sent as zero and ignored on receipt. 858 Count: Count is the number of RESPONSE Records present in the 859 Response Message. 861 Err, SubErr: A two-part error code. Zero unless there was an error 862 in the Query Message, for which case see Section 3.6. 864 RESPONSE: Each RESPONSE Record within a Pull Directory Response 865 Message is formatted as follows: 867 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 868 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 869 | SIZE |OV| RESV | Index | 870 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 871 | Lifetime | 872 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 873 | Response Data ... 874 +--+--+--+--+--+--+--+--+--+--+--... 876 SIZE: The size of the RESPONSE Record is an unsigned integer 877 number of bytes not including the SIZE field and following 878 byte. A value of SIZE so large that the material doesn't fit 879 in the Query Message indicates a malformed QUERY Record. The 880 QUERY Record with such an excessive SIZE value and any 881 subsequent QUERY Records MUST be ignored and the entire 882 Query Message MAY be ignored. 884 OV: The overflow flag. Indicates, as described below, that 885 there was too much Response Data to include in one Response 886 Message. 888 RESV: Three reserved bits that MUST be sent as zero and ignored 889 on receipt. 891 Index: The relative index of the QUERY Record in the Query 892 Message to which this RESPONSE Record corresponds. The index 893 will always be one for Query Messages containing a single 894 QUERY Record. If the Index is larger than the Count was in 895 the corresponding Query, that RESPONSE Record MUST be 896 ignored and subsequent RESPONSE Records or the entire 897 Response Message MAY be ignored. 899 Lifetime: The length of time for which the response should be 900 considered valid in units of 100 milliseconds except that 901 the values zero and 2**16-1 are special. If zero, the 902 response can only be used for the particular query from 903 which it resulted and MUST NOT be cached. If 2**16-1, the 904 response MAY be kept indefinitely but not after the Pull 905 Directory server goes down or becomes unreachable. (The 906 maximum definite time that can be expressed is a little over 907 1.8 hours.) 909 Response Data: There are three types of RESPONSE Records. 910 - If the Err field of the enclosing Respose Message has a 911 message level error code in it, then the the REPONSE 912 Records are omitted and Count will be zero. See Section 913 3.6 for additional information on errors. 914 - If the Err field of the encosing Response Message has a 915 record level error code in it, then the RESPONSE Records 916 are those in error as further described in Section 3.6. 917 - If the Err field of the enclosing Repose Message is zero, 918 then the Response Data in each RESPONSE Record is 919 formatted as the value of an Interface Addresses APPsub- 920 TLV [IA]. The maximum size of such contents is 255 bytes 921 in the case when the RESPONSE Record SIZE field is 255. 923 Multiple RESPONSE Records can appear in a Response Message with the 924 same Index if the answer to a QUERY Record consists of multiple 925 Interface Address APPsub-TLV values. This would be necessary if, for 926 example, a MAC address within a Data Label appears to be reachable by 927 multiple TRILL switches. However, all RESPONSE Records to any 928 particular QUERY Record MUST occur in the same Response Message. If a 929 Pull Directory holds more mappings for a queried address than will 930 fit into one Response Message, it selects which to include by some 931 method outside the scope of this document and sets the overflow flag 932 (OV) in all of the RESPONSE Records responding to that query address. 934 See Section 3.6 for a discussion of how errors are handled. 936 3.2.2.2 Pull Directory Forwarding 938 Query Messages with QTYPEs 2, 3, 4, and 5 are interpreted and handled 939 as described below. In these cases, if the information sought is not 940 in the directory, the provided frame is forwarded by the Pull 941 Directory server as a multi-destination TRILL Data packet if the FL 942 flag in the Query Message was one, otherwise the frame is not 943 forwarded. If there was no error in the handling of the enclosing 944 Query Message then the Pull Directory server forwards the frame 945 inside that QUERY Record, after modifying it in some cases, as 946 described below. 948 ARP: When QTYPE is 2, an ARP [RFC826] frame is included in the QUERY 949 Record. The ar$op field MUST be ares_op$REQUEST and for the 950 response described in 3.2.2.1, this is treated as a query for the 951 target protocol address where the AFN of that address is given by 952 ar$pro. (ARP field and value names with embedded dollar signs are 953 specified in [RFC826].) If ar$op is not ares_op$REQUEST or the ARP 954 is malformed or the query fails, an error is returned. Otherwise 955 the ARP is modified into the appropriate ARP response that is then 956 sent by the Pull Directory server as a TRILL Data packet. 958 ND: When QTYPE is 3, an IPv6 Neighbor Discover (ND [RFC4861]) frame 959 is included in the QUERY Record. Only Neighbor Solicitation ND 960 frames (corresponding to an ARP query) are allowed. An error is 961 returned for other ND frames or if the target address is not 962 found. Otherwise an ND Neighbor Advertisement response is returned 963 by the Pull Directory server as a TRILL Data packet. 965 RARP: When QTYPE is 4, a RARP [RFC903] frame is included in the QUERY 966 Record. If the ar$op field is ares_op$REQUEST, the frame is 967 handled as an ARP as described above. Otherwise the ar$op field 968 MUST be 'reverse request' and for the response described in 969 3.2.2.1, this is treated as a query for the target hardware 970 address where the AFN of that address is given by ar$hrd. (See 971 [RFC826] for RARP fields.) If ar$op is not one of these values or 972 the RARP is malformed or the query fails, an error is returned. 973 Otherwise the RARP is modified into the appropriate RARP response 974 that is then unicast by the Pull Directory server as a TRILL Data 975 packet to the source hardware MAC address. 977 MacDA: When QTYPE is 5, indicating a fame is provided in the QUERY 978 Record whose destination MAC address TRILL switch attachment is 979 unknown, the only requirement is that this MAC address must be 980 unicast. If it is group addressed an error is returned. For the 981 response described in 3.2.2.1, it is treated as a query for the 982 MacDA. If the Pull Directory contains TRILL switch attachment 983 information for the MAC address in the Data Label of the Query 984 Message, it forwards the frame to that switch in a unicast TRILL 985 Data packet. 987 3.3 Cache Consistency 989 Unless it sends all responses with a Lifetime of zero, a Pull 990 Directory MUST take action, by sending Update Messages, to minimize 991 the amount of time that a TRILL switch will continue to use stale 992 information from that Pull Directory. The format of Update Messages 993 and the Acknowledge Messages used to respond to Update Messages are 994 given in Sections 3.3.1 and 3.3.2. 996 A Pull Directory server MUST maintain one of the following three sets 997 of records, in order of increasing specificity. Retaining more 998 specific records, such as that given in method 3 below, minimizes 999 spontaneous Update Messages sent to update pull client TRILL switch 1000 caches but increases the record keeping burden on the Pull Directory 1001 server. Retaining less specific records, such as that given in method 1002 1, will generally increase the volume and overhead due to spontaneous 1003 Update Messages and due to unnecessarily invalidating cached 1004 information, but will still maintain consistency and will reduce the 1005 record keeping burden on the Pull Directory server. In all cases, 1006 there may still be brief periods of time when directory information 1007 has changed, but information a pull client has cached has not yet 1008 been updated or expunged. 1010 1. An overall record per Data Label of when the last positive 1011 response data sent will expire at some requester and when the 1012 last negative response will expire at some requester, assuming 1013 those requesters cached the response. 1015 2. For each unit of data (IA APPsub-TLV Address Set [IA]) held by 1016 the server and each address about which a negative response was 1017 sent, when the last response sent with that positive response 1018 data and when the last negative response will expire at a 1019 requester, assuming the requester cached the response. 1021 3. For each unit of data held by the server (IA APPsub-TLV Address 1022 Set [IA]) and each address about which a negative response was 1023 sent, a list of TRILL switches that were sent that data as a 1024 positive response or sent a negative response for the address, 1025 and the expected time to expiration for that data or address at 1026 each such TRILL switch, assuming the requester cached the 1027 response. 1029 RESPONSE Records sent with a zero lifetime are considered to have 1030 already expired and so do not need to be tracked. 1032 A Pull Directory server may have a limit as to how many TRILL 1033 switches for which it can maintain expiry information by method 3 1034 above or how many data units or addresses it can maintain expiry 1035 information for by method 2 or the like. If such limits are exceeded, 1036 it MUST transition to a lower numbered method but, in all cases, MUST 1037 support, at a minimum, method 1. 1039 When data at a Pull Directory is changed, deleted, or added and there 1040 may be unexpired stale information at a requesting TRILL switch, the 1041 Pull Directory MUST send an Update Message as discussed below. The 1042 sending of such an Update Message MAY be delayed by a configurable 1043 number of milliseconds that default to 50 milliseconds to await other 1044 possible changes that could be included in the same Update. 1046 1. If method 1, the crudest method, is being followed, then when 1047 any Pull Directory information in a Data Label is changed or 1048 deleted and there are outstanding cached positive data 1049 response(s), an all-addresses flush positive data Update Message 1050 is flooded within that Data Label as an RBridge Channel Message 1051 with an Inner.MacDA of All-Egress-RBridges. Similarly if data is 1052 added and there are outstanding cached negative responses, an 1053 all-addresses flush negative message is similarly flooded. The 1054 Count field being zero in an Update Message indicates "all- 1055 addresses". On receiving an all-addresses flooded flush positive 1056 Update from a Pull Directory server it has used, indicated by 1057 the F and P bits being one and the Count being zero, a TRILL 1058 switch discards the cached data responses it has for that Data 1059 Label. Similarly, on receiving an all addresses flush negative 1060 Update, indicated by the F and N bits being one and the Count 1061 being zero, it discards all cached negative replies for that 1062 Data Label. A combined flush positive and negative can be 1063 flooded by having all of the F, P, and N bits set to one 1064 resulting in the discard of all positive and negative cached 1065 information for the Data Label. 1067 2. If method 2 is being followed, then a TRILL switch floods 1068 address specific positive Update Messages when data that might 1069 be cached by a querying TRILL switch is changed or deleted and 1070 floods address specific negative Update Messages when such 1071 information is added to. Such messages are somewhat similar to 1072 the method 1 flooded flush Update Messages and are also sent as 1073 RBridge Channel messages with an Inner.MacDA of All-Egress- 1074 RBridges. However the Count field will be non-zero and either 1075 the P or N bit, but not both, will be one. There are actually 1076 four possible message types that can be flooded: 1078 2.a If data still being cached is updated, then an Update 1079 Message is sent with the P flag set and the Err field zero. 1080 The addresses in the RESPONSE Records in the unsolicited 1081 response are compared to the addresses about which the 1082 receiving TRILL switch is holding cached positive 1083 information from that server and, if they match, the cached 1084 information is updated. 1086 2.b If data still being cached is deleted, then an Update 1087 Message is sent with the P flag set and the Err field non- 1088 zero giving the error that would now be encountered in 1089 attempting to pull information for the relevant address from 1090 the Pull Directory server. In this non-zero Err field case, 1091 the RESPONSE Record(s) differ from non-zero Err Reply 1092 Message RESPONSE Records in that they include an interface 1093 address set. Any cached positive information for the 1094 address is deleted and the negative response cached as per 1095 the lifetime given. 1097 2.c If data for an address about which a negative response was 1098 sent is added so that negative response is now incorrect, an 1099 Update Message is sent with the N flag set to one and the 1100 Err field zero. The addresses in the RESPONSE Records in the 1101 unsolicited response are compared to the addresses about 1102 which the receiving TRILL switch is holding cached negative 1103 information from that server and, if they match, the cached 1104 negative information is deleted and the positive information 1105 provided is cached as per the lifetime given. 1107 2.d In the rare case where it is desired to change the lifetime 1108 or error associated with cached negative information, it is 1109 possible to send an Update Message with the N flag set to 1110 one and the Err field non-zero. As in case 2.b above, the 1111 RESPONSE Record(s) give the relevant addresses. Any cached 1112 negative information for the address is updated. 1114 3. If method 3 is being followed, the same sort of unsolicited 1115 Update Messages are sent as with method 2 above except they are 1116 not normally flooded but unicast only to the specific TRILL 1117 switches the directory server believes may be holding the cached 1118 positive or negative information that needs updating. However, a 1119 Pull Directory server MAY flood unsolicited updates under method 1120 3, for example if it determines that a sufficiently large 1121 fraction of the TRILL switches in some Data Label are requesters 1122 that need to be updated. 1124 A Pull Directory server tracking cached information with method 3 1125 MUST NOT clear the indication that it needs to update cached 1126 information at a querying TRILL switch until it has sent an Update 1127 Message and received a corresponding Acknowledge Message or it has 1128 sent a configurable number of updates at a configurable interval 1129 which default to 3 updates 100 milliseconds apart. 1131 A Pull Directory server tracking cached information with methods 2 or 1132 1 SHOULD NOT clear the indication that it needs to update cached 1133 information until it has sent an Update Message and received a 1134 corresponding Acknowledge Message from all of its ESADI neighbors or 1135 it has sent a configurable number of updates at a configurable 1136 interval that defaults to 3 updates 100 milliseconds apart. 1138 3.3.1 Update Message Format 1140 An Update Message is formatted as a Response Message with the 1141 differences described in Section 3.3 above and the following: 1143 o The Type field in the message header is set to 3. 1144 o The Err field in the message header MUST be sent as zero and 1145 ignored on receipt. 1146 o The Index field in the RESPONSE Record(s) is set to zero (but the 1147 Count field in the Update Message header MUST still correctly 1148 indicate the number of RESPONSE Records present). 1150 Update Messages are initiated by a Pull Directory server. The 1151 Sequence number space used is controlled by the originating Pull 1152 Directory server and different from Sequence number space used in a 1153 Query and the corresponding Response that are controlled by the 1154 querying TRILL switch. 1156 The 4-bit Flags field of the message header for an Update Message is 1157 as follows: 1159 +---+---+---+---+ 1160 | F | P | N | R | 1161 +---+---+---+---+ 1163 F: The Flood bit. If zero, the Update Message is unicast. If F=1, it 1164 is multicast to All-Egress-RBridges. 1166 P, N: Flags used to indicate positive or negative Update Messages. 1167 P=1 indicates positive. N=1 indicates negative. Both may be 1 for 1168 a flooded all addresses Update. 1170 R: Reserved. MUST be sent as zero and ignored on receipt 1172 For tracking methods 2 and 3 in Section 3.3.1, a particular Update 1173 Message must have either the P flag or the N flag set but not both. 1175 3.3.2 Acknowledge Message Format 1177 An Acknowledge Message is sent in response to an Update Message to 1178 confirm receipt or indicate an error, unless response is inhibited by 1179 rate limiting. It is also formatted as a Response Message but the 1180 Type is set to 4. 1182 If there are no errors in the processing of an Update Message or if 1183 there is a message level overall or header error in an Update 1184 Message, the message is essentially echoed back with the Err and 1185 SubErr fields set approriately, the Type changed to Acknowledge, and 1186 a null records section with the Count field set to zero. 1188 If there is a record level error in an Update Message, one or more 1189 Acknowledge Messages may be returned with the erroneous record(s) 1190 indicated in Section 3.5. 1192 3.4 Summary of Records Formats in Messages 1194 As specified in Section 3.2 and 3.3, the Query, Response, Update, and 1195 Acknowledge Messages can have zero or more repeating Record 1196 structures under different circumstances, as summarized below. The 1197 "Err" column abbreivations in this table have the meanings listed 1198 below. "IA APPsubTLV value" means the value part of the IA APPsub-TLV 1199 specified in [IA]. 1201 MBZ = MUST be zero 1202 Z = zero 1203 NZ = non-zero 1204 NZM = non-zero message level error 1205 NZR = non-zero record level error 1207 Message Err Section Record Structure Response Data 1208 ----------- --- ------- ---------------- ------------------ 1209 Query MBZ 3.2.1 QUERY Record - 1210 Response Z 3.2.2.1 RESPONSE Record IA APPsubTLV value 1211 Response NZM 3.2.2.1 null - 1212 Response NZR 3.2.2.1 RESPONSE Record Records with error 1213 Update MBZ 3.3.1 RESPONSE Record IA APPsubTLV value 1214 Acknowledge Z 3.3.2 null - 1215 Acknowledge NZM 3.3.2 null - 1216 Acknowledge NZR 3.3.2 RESPONSE Record Records with error 1218 See Section 3.6 for further details on errors. 1220 3.5 Pull Directory Hosted on an End Station 1222 Optionally, a Pull Directory actually hosted on an end station MAY be 1223 supported. In that case, one or more TRILL switches must proxy for 1224 the end station and advertise themselves as Pull Directory servers. 1225 Such proxies must have a direct connection to the end station, that 1226 is a connection not involving any intermediate TRILL switches. 1228 When the proxy Pull Directory server TRILL switch receives a Query 1229 Message, it modifies the inter-RBridge Channel message received into 1230 a native RBridge Channel message and forwards it to the end station 1231 Pull Directory server. Later, when it receives one or more responses 1232 from that end station by native RBridge Channel messages, it modifies 1233 them into inter-RBridge Channel messages and forwards them to the 1234 source TRILL switch of the original Query Message. Similarly, an 1235 Update from the end station is forwarded to client TRILL switches and 1236 acknowledgements from those TRILL switches are returned to the end 1237 station by the proxy. Because native RBridge Channel messages have no 1238 TRILL Header and are addressed by MAC address, as opposed to inter- 1239 RBridge Channel messages that are TRILL Data packets and are 1240 addressed by nickname, nickname information must be added to the 1241 native RBridge Channel version of Pull Directory messages. 1243 The native Pull Directory RBridge Channel messages use the same 1244 Channel protocol number as do the inter-RBridge Pull Directory 1245 RBridge Channel messages. The native messages SHOULD be sent with an 1246 Outer.VLAN tag that gives the priority of each message which is the 1247 priority of the original inter-RBridge request packet. The Outer.VLAN 1248 ID used is the Designated VLAN on the link to the end station 1250 [RFC6325]. Since there is no TRILL Header or inner Data Label for 1251 native RBridge Chanel messages, that information is added to the 1252 header. 1254 The native RBridge Channel message Pull Directory message protocol 1255 dependent data part is the same as for inter-RBridge Channel messages 1256 except that the 8-byte header described in Section 3.1 is expanded to 1257 14 or 18 bytes as follows: 1259 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Ver | Type | Flags | Count | Err | SubErr | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Sequence Number | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Nickname (2 bytes) | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1268 | Data Label ... (4 or 8 bytes) | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1270 | Type Specific Payload - variable length 1271 +-+-+- ... 1273 Fields not described below are as in Section 3.1. 1275 Nickname: The nickname of the original TRILL switch that is 1276 communicating with the end station Pull Directory. Usually this 1277 is a remote TRILL switch but it could be the TRILL switch to 1278 which the end station is attached. The proxy copies this from 1279 the ingress nickname when mapping a Query or Acknowledge 1280 Message to native form. It also takes this from a native 1281 Response or Update Message to be used as the egress of the 1282 inter-RBridge form on the message unless it is a flooded Update 1283 in which case a distribution tree is used. 1285 Data Label: The Data Label that normally appears right after the 1286 Inner.MacSA of the an RBridge Channel Pull Directory message 1287 appears here in the native RBridge Channel message version. 1288 This might appear in a native Query Message, to be reflected in 1289 a Response Message, or it might appear in a native Update to be 1290 reflected in an Acknowledge Message. 1292 3.6 Pull Directory Message Errors 1294 A non-zero Err field in the Pull Directory Reponse or Acknowledge 1295 Message header indicates an error message. 1297 If there is an error that applies to an entire Query or Update 1298 Message or its header, as indicated by the range of the value of the 1299 Err field, then the QUERY Records probably were not even looked at by 1300 the Pull Directory server and would provide no information in the 1301 Response or Acknowledge Message so they are omitted and the Count 1302 field is set to zero in the Response or Acknowledgement Message. 1304 If errors occur at the QUERY Record level for a Query Message, they 1305 MUST be reported in a Response Message separate from the results of 1306 any successful non-erroneous QUERY Records. If multiple QUERY Records 1307 in a Query Message have different errors, they MUST be reported in 1308 separate Response Messages. If multiple QUERY Records in a Query 1309 Message have the same error, this error response MAY be reported in 1310 one or multiple Response Messages. In an error Response Message, the 1311 QUERY Record or Records being responded to appear, expanded by the 1312 Lifetime for which the server thinks the error might persist and with 1313 their Index inserted, as the RESPONSE Record or Records. 1315 If errors occur at the RESPONSE Record level for an Update Message, 1316 they MUST be reported in a Acknowledge Message separate from the 1317 acknowledgement of any non-erroneous RESPONSE Records. If multiple 1318 RESPONSE Records in an Update have different errors, they MUST be 1319 reported in separate Acknowledge Messages. If multiple RESPONSE 1320 Records in an Update Message have the same error, this error response 1321 MAY be reported in one or multiple Acknowledge Messages. In an error 1322 Acknowledge Message, the RESPONSE Record or Records being responded 1323 to appear, expanded by the time for which the server thinks the error 1324 might persist and with their Index inserted, as a RESPONSE Record or 1325 Records. 1327 ERR values 1 through 126 are available for encoding Request or Update 1328 Message level errors. ERR values 128 through 254 are available for 1329 encoding QUERY or RESPONSE Record level errors. The SubErr field is 1330 available for providing more detail on errors. The meaning of a 1331 SubErr field value depends on the value of the Err field. 1333 3.6.1 Error Codes 1334 Err Level Meaning 1335 ------ ------- ------- 1336 0 - (no error) 1338 1 Message Unknown or reserved Query Message field value 1339 2 Message Request Message/data too short 1340 3 Message Unknown or reserved Update Message field value 1341 4 Message Update Message/data too short 1342 5-126 Message (Available for allocation by IETF Review) 1343 127 - Reserved 1345 128 Record Unknown or reserved QUERY Record field value 1346 129 Record QUERY Record truncated 1347 130 Record Address not found 1348 131 Record Unknown or reserved RESPONSE Record field value 1349 132 Record RESPONSE Record truncated 1350 133-254 Record (Available for allocation by IETF Review) 1351 255 - Reserved 1353 Note that some error codes are for overall message level errors while 1354 some are for errors in the repeating records that occur in messages. 1356 3.6.2 Sub-Errors Under Error Codes 1 and 3 1358 The following sub-errors are specified under error code 1 and 3: 1360 SubErr Field with Error 1361 ------ ---------------- 1362 0 Unspecified 1363 1 Unknown Ver field value 1364 2 Unknown Type field value 1365 3 Specified Data Label not being served 1366 4-254 (Available for allocation by Expert Review) 1367 255 Reserved 1369 3.6.3 Sub-Errors Under Error Codes 128 and 131 1371 The following sub-errors are specified under error code 128 and 131: 1373 SubErr Field with Error 1374 ------ ---------------- 1375 0 Unspecified 1376 1 Unknown AFN field value 1377 2 Unknown or Reserved QTYPE field value 1378 3 Invalid or inconsistent SIZE field value 1379 4 Invalid frame for QTYPE 2, 3, 4, or 5 1380 5-254 (Available for allocation by Expert Review) 1381 255 Reserved 1383 3.7 Additional Pull Details 1385 If a TRILL switch notices that a Pull Directory server is no longer 1386 data reachable [rfc7180bis], it MUST promptly discard all pull 1387 responses it is retaining from that server as it can no longer 1388 receive cache consistency Update Messages from the server. 1390 A secondary Pull Directory server is one that obtains its data from a 1391 primary directory server. See discussion of primary to secondary 1392 directory information transfer in Section 2.5. 1394 3.8 The No Data Flag 1396 In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], 1397 the mere presence of an Interested VLANs or Interested Labels sub- 1398 TLVs in the LSP of a TRILL switch indicates connection to end 1399 stations in the VLAN(s) or FGL(s) listed and thus a desire to receive 1400 multi-destination traffic in those Data Labels. But, with Push and 1401 Pull Directories, advertising that you are a directory server 1402 requires using these sub-TLVs to indicate the Data Label(s) you are 1403 serving. If such a directory server does not wish to received multi- 1404 destination TRILL Data packets for the Data Labels it lists in one of 1405 these sub-TLVs, it sets the "No Data" (NOD) bit to one. This means 1406 that data on a distribution tree may be pruned so as not to reach the 1407 "No Data" TRILL switch as long as there are no TRILL switches 1408 interested in the Data that are beyond the "No Data" TRILL switch on 1409 the distribution tree. The NOD bit is backwards compatible as TRILL 1410 switches ignorant of it will simply not prune when they could, which 1411 is safe although it may cause increased link utilization. 1413 Example of a TRILL switch serving as a directory that might not want 1414 multi-destination traffic in some Data Labels would be a TRILL switch 1415 that does not offer end station service for any of the Data Labels 1416 for which it is serving as a directory and is either 1417 - a Pull Directory and/or 1418 - a Push Directory for which all of the ESADI traffic will be 1419 handled by unicast ESDADI [RFC7357]. 1421 A Push Directory MUST NOT set the NOD bit for a Data Label if it 1422 needs to communicate via multi-destination ESADI PDUs in that data 1423 label since such PDUs look like TRILL Data packets to transit TRILL 1424 switches and are likely to be incorrectly pruned if NOD was set. 1426 4. Directory Use Strategies and Push-Pull Hybrids 1428 For some edge nodes that have a great number of Data Labels enabled, 1429 managing the MAC and Data Label <-> Edge RBridge mapping for hosts 1430 under all those Data Labels can be a challenge. This is especially 1431 true for Data Center gateway nodes, which need to communicate with 1432 many, if not all, Data Labels. 1434 For those edge TRILL switch nodes, a hybrid model should be 1435 considered. That is, the Push Model is used for some Data Labels or 1436 addresses within a Data Label while the Pull Model is used for other 1437 Data Labels or addresses within a Data Label. It is the network 1438 operator's decision by configuration as to which Data Labels' mapping 1439 entries are pushed down from directories and which Data Labels' 1440 mapping entries are pulled. 1442 For example, assume a data center where hosts in specific Data 1443 Labels, say VLANs 1 through 100, communicate regularly with external 1444 peers. Probably, the mapping entries for those 100 VLANs should be 1445 pushed down to the data center gateway routers. For hosts in other 1446 Data Labels that only communicate with external peers occasionally 1447 for management interfacing, the mapping entries for those VLANs 1448 should be pulled down from directory when the need comes up. 1450 Similarly, it could be that within a Data Label that some addresses, 1451 such as the addresses of gateways, file, DNS, or database server 1452 hosts are commonly referenced by most other hosts but those other 1453 hosts, perhaps compute engines, are typically only referenced by a 1454 few hosts in that Data Label. In that case, the address information 1455 for the commonly referenced hosts could be pushed as an incomplete 1456 directory while the addresses of the others are pulled when needed. 1458 The mechanisms described above for Push and Pull Directory services 1459 make it easy to use Push for some Data Labels or addresses and Pull 1460 for others. In fact, different TRILL switches can even be configured 1461 so that some use Push Directory services and some use Pull Directory 1462 services for the same Data Label if both Push and Pull Directory 1463 services are available for that Data Label. And there can be Data 1464 Labels for which directory services are not used at all. 1466 There are a wide variety of strategies that a TRILL switch can adopt 1467 for making use of directory assistance. A few suggestions are given 1468 below. 1470 - Even if a TRILL switch will normally be operating with 1471 information from a complete Push Directory server, there will be a 1472 period of time when it first comes up before the information it 1473 holds is complete. Or, it could be that the only Push Directories 1474 that can push information to it are incomplete or that they are 1475 just starting and may not yet have pushed the entire directory. 1477 Thus, it is RECOMMENDED that all TRILL switches have a strategy 1478 for dealing with the situation where they do not have complete 1479 directory information. Examples are to send a Pull Directory query 1480 or to revert to [RFC6325] behavior. 1482 - If a TRILL switch receives a native frame X resulting in 1483 seeking directory information, a choice needs to be made as to 1484 what to do if it does not already have the directory information 1485 it needs. In particular, it could (1) immediately flood the TRILL 1486 Data packet resulting from ingressing X in parallel with seeking 1487 the directory information, (2) flood that TRILL Data packet 1488 delayed, if it fails to obtain the directory information, or (3) 1489 discard X if it fails to obtain the information. The choice might 1490 depend on the priority of frame X since the higher that priority, 1491 the more urgent the frame is and the greater the probability of 1492 harm in delaying it. If a Pull Directory request is sent, it is 1493 RECOMMENDED that its priority be derived from the priority of the 1494 frame X with the derived priority configurable and having the 1495 following defaults: 1497 Ingressed If Flooded If Flooded 1498 Priority Immediately After Delay 1499 -------- ----------- ----------- 1500 7 5 6 1501 6 5 6 1502 5 4 5 1503 4 3 4 1504 3 2 3 1505 2 0 2 1506 0 1 0 1507 1 1 1 1509 Priority 7 is normally only used for urgent messages critical to 1510 adjacency and so SHOULD NOT be the default for directory traffic. 1511 Unsolicited updates are sent with a priority that is configured per 1512 Data Label that defaults to priority 5. 1514 5. Security Considerations 1516 Incorrect directory information can result in a variety of security 1517 threats including the following: 1519 Incorrect directory mappings can result in data being delivered to 1520 the wrong end stations, or set of end stations in the case of 1521 multi-destination packets, violating security policy. 1523 Missing or incorrect directory data can result in denial of 1524 service due to sending data packets to black holes or discarding 1525 data on ingress due to incorrect information that their 1526 destinations are not reachable. 1528 Push Directory data is distributed through ESADI-LSPs [RFC7357] that 1529 can be authenticated with the same mechanisms as IS-IS LSPs. See 1530 [RFC5304] [RFC5310] and the Security Considerations section of 1531 [RFC7357]. 1533 Pull Directory queries and responses are transmitted as RBridge-to- 1534 RBridge or native RBridge Channel messages [RFC7178]. Such messages 1535 can be secured as specified in [ChannelTunnel]. 1537 For general TRILL security considerations, see [RFC6325]. 1539 6. IANA Considerations 1541 This section gives IANA assignment and registry considerations. 1543 6.1 ESADI-Parameter Data Extensions 1545 Action 1: IANA will assign a two bit field [bits 1-2 suggested] 1546 within the ESADI-Parameter TRILL APPsub-TLV flags for "Push Directory 1547 Server Status" (PDSS) and will create a sub-registry in the TRILL 1548 Parameters Registry as follows: 1550 Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits 1552 Registration Procedures: Standards Action 1554 References: [RFC7357] [This document] 1556 Bit Mnemonic Description Reference 1557 --- -------- ----------- --------- 1558 0 UN Supports Unicast ESADI ESDADI [RFC7357] 1559 1-2 PDSS Push Directory Server Status [this document] 1560 3-7 - Available for assignment 1562 Action 2: In addition, the ESADI-Parameter APPsub-TLV is optionally 1563 extended, as provided in its original specification in ESADI 1564 [RFC7357], by one byte as show below. Therefore [this document] 1565 should be added as a second reference to the ESDAI-Parameter APPsub- 1566 TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 1567 Identifier 1" Registry. 1569 +-+-+-+-+-+-+-+-+ 1570 | Type | (1 byte) 1571 +-+-+-+-+-+-+-+-+ 1572 | Length | (1 byte) 1573 +-+-+-+-+-+-+-+-+ 1574 |R| Priority | (1 byte) 1575 +-+-+-+-+-+-+-+-+ 1576 | CSNP Time | (1 byte) 1577 +-+-+-+-+-+-+-+-+ 1578 | Flags | (1 byte) 1579 +---------------+ 1580 |PushDirPriority| (optional, 1 byte) 1581 +---------------+ 1582 | Reserved for expansion (variable) 1583 +-+-+-+-... 1585 The meanings of all the fields are as specified in ESDADI [RFC7357] 1586 except that the added PushDirPriority is the priority of the 1587 advertising ESADI instance to be a Push Directory as described in 1588 Section 2.3. If the PushDirPriority field is not present (Length = 3) 1589 it is treated as if it were 0x40. 0x40 is also the value used and 1590 placed here by an TRILL switch whose priority to be a Push Directory 1591 has not been configured. 1593 6.2 RBridge Channel Protocol Number 1595 Action 3: IANA will allocate a new RBridge Channel protocol number 1596 for "Pull Directory Services" from the range allocable by Standards 1597 Action and update the subregistry of such protocol number in the 1598 TRILL Parameters Registry referencing this document. 1600 6.3 The Pull Directory (PUL) and No Data (NOD) Bits 1602 Action 4: IANA is requested to assign a currently reserved bit in the 1603 Interested VLANs field of the Interested VLANs sub-TLV [suggested bit 1604 18] and the Interested Labels field of the Interested Labels sub-TLV 1605 [suggested bits 6] [RFC7176] to indicate Pull Directory server (PUL). 1606 This bit is to be added, with this document as reference, to the 1607 "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" 1608 subregistries created by [RFC7357]. 1610 Action 5: IANA is requested to assign a currently reserved bit in the 1611 Interested VLANs field of the Interested VLANs sub-TLV [suggested 1612 bits 19] and the Interested Labels field of the Interested Labels 1613 sub-TLV [suggested bits 7] [RFC7176] to indicate No Data (NOD, see 1614 Section 3.8). This bit is to be added, with this document as 1615 reference, to the "Interested VLANs Flag Bits" and "Interested Labels 1616 Flag Bits" subregistries created by [RFC7357]. 1618 6.4 TRILL Pull Directory QTYPEs 1620 Action 6: IANA is requested to create a new Registry on the 1621 "Transparent Interconnection of Lots of Links (TRILL) Parameters" web 1622 page as follows: 1624 Name: TRILL Pull Directory QTYPEs" 1625 Registration Procedure: IETF Review 1626 Reference: [this document] 1627 Initial contents as in Section 3.2.1. 1629 6.5 Pull Directory Error Code Registries 1631 Actions 7, 8, and 9: IANA is requested to create a new Registry and 1632 two new SubRegistries on the "Transparent Interconnection of Lots of 1633 Links (TRILL) Parameters" web page as follows: 1635 Registry 1636 Name: TRILL Pull Directory Errors 1637 Registration Procedure: IETF Review 1638 Reference: [this document] 1640 Initial contents as in Section 3.6.1. 1642 Sub-Registry 1643 Name: Sub-codes for TRILL Pull Directory Errors 1 and 3 1644 Registration Procedure: Expert Review 1645 Reference: [this document] 1647 Initial contents as in Section 3.6.2. 1649 Sub-Registry 1650 Name: Sub-codes for TRILL Pull Directory Errors 128 and 131 1651 Registration Procedure: Expert Review 1652 Reference: [this document] 1654 Initial contents as in Section 3.6.3. 1656 Normative References 1658 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 1659 RFC 826, November 1982. 1661 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 1662 Reverse Address Resolution Protocol", STD 38, RFC 903, June 1663 1984 1665 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1666 Requirement Levels", BCP 14, RFC 2119, March 1997 1668 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1669 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1671 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1672 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1673 September 2007. 1675 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1676 Authentication", RFC 5304, October 2008. 1678 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1679 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1680 5310, February 2009. 1682 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1683 Layer-2 Systems", RFC 6165, April 2011. 1685 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1686 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1687 Specification", RFC 6325, July 2011. 1689 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1690 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1691 BCP 141, RFC 7042, October 2013. 1693 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1694 and D. Dutt, "Transparent Interconnection of Lots of Links 1695 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 1696 . 1698 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1699 D., and A. Banerjee, "Transparent Interconnection of Lots of 1700 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 1701 . 1703 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1704 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1705 RBridge Channel Support", RFC 7178, May 2014, . 1708 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1709 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 1710 End Station Address Distribution Information (ESADI) Protocol", 1711 RFC 7357, September 2014, . 1714 [rfc7180bis] - D. Eastlake 3rd, M. Zhang, A. Banerjee, A. Ghanwani, 1715 and S. Gupta "Transparent Interconnection of Lots of Links 1716 (TRILL): Clarifications, Corrections, and Updates", RFC 7180, 1717 May 2014, . 1719 [IA] - Eastlake, D., L. Yizhou, R. Perlman, "TRILL: Interface 1720 Addresses APPsub-TLV", draft-ietf-trill-ia-appsubtlv, work in 1721 progress. 1723 Informational References 1725 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 1726 Gashinsky, "Directory Assistance Problem and High-Level Design 1727 Proposal", RFC 7067, November 2013. 1729 [ChannelTunnel] - D. Eastlake, M. Umair, Y. Li, "TRILL: RBridge 1730 Channel Tunnel Protocol", draft-ietf-trill-channel-tunnel, work 1731 in progress. 1733 [ARPreduction] - Y. Li, D. Eastlake, L. Dunbar, R. Perlman, I. 1734 Gashinsky, "TRILL: ARP/ND Optimization", draft-ietf-trill-arp- 1735 optimization, work in progress. 1737 Acknowledgments 1739 The contributions of the following persons are gratefully 1740 acknowledged: 1742 Gsyle Noble 1744 The document was prepared in raw nroff. All macros used were defined 1745 within the source file. 1747 Authors' Addresses 1749 Donald Eastlake 1750 Huawei Technologies 1751 155 Beaver Street 1752 Milford, MA 01757 USA 1754 Phone: +1-508-333-2270 1755 Email: d3e3e3@gmail.com 1757 Linda Dunbar 1758 Huawei Technologies 1759 5430 Legacy Drive, Suite #175 1760 Plano, TX 75024, USA 1762 Phone: +1-469-277-5840 1763 Email: ldunbar@huawei.com 1765 Radia Perlman 1766 EMC 1767 2010 256th Avenue NE, #200 1768 Bellevue, WA 98007 USA 1770 Email: Radia@alum.mit.edu 1772 Igor Gashinsky 1773 Yahoo 1774 45 West 18th Street 6th floor 1775 New York, NY 10011 1777 Email: igor@yahoo-inc.com 1779 Yizhou Li 1780 Huawei Technologies 1781 101 Software Avenue, 1782 Nanjing 210012 China 1784 Phone: +86-25-56622310 1785 Email: liyizhou@huawei.com 1787 Copyright, Disclaimer, and Additional IPR Provisions 1789 Copyright (c) 2015 IETF Trust and the persons identified as the 1790 document authors. All rights reserved. 1792 This document is subject to BCP 78 and the IETF Trust's Legal 1793 Provisions Relating to IETF Documents 1794 (http://trustee.ietf.org/license-info) in effect on the date of 1795 publication of this document. Please review these documents 1796 carefully, as they describe your rights and restrictions with respect 1797 to this document. Code Components extracted from this document must 1798 include Simplified BSD License text as described in Section 4.e of 1799 the Trust Legal Provisions and are provided without warranty as 1800 described in the Simplified BSD License. The definitive version of 1801 an IETF Document is that published by, or under the auspices of, the 1802 IETF. Versions of IETF Documents that are published by third parties, 1803 including those that are translated into other languages, should not 1804 be considered to be definitive versions of IETF Documents. The 1805 definitive version of these Legal Provisions is that published by, or 1806 under the auspices of, the IETF. Versions of these Legal Provisions 1807 that are published by third parties, including those that are 1808 translated into other languages, should not be considered to be 1809 definitive versions of these Legal Provisions. For the avoidance of 1810 doubt, each Contributor to the IETF Standards Process licenses each 1811 Contribution that he or she makes as part of the IETF Standards 1812 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1813 language to the contrary, or terms, conditions or rights that differ 1814 from or are inconsistent with the rights and licenses granted under 1815 RFC 5378, shall have any effect and shall be null and void, whether 1816 published or posted by such Contributor, or included with or in such 1817 Contribution.