idnits 2.17.1 draft-ietf-trill-directory-assist-mechanisms-06.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 (January 5, 2016) is 3033 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: July 4, 2016 January 5, 2016 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..................11 59 2.4 Additional Push Details...............................12 60 2.5 Primary to Secondary Server Push Service..............14 61 2.6 Push Directory Configuration..........................14 63 3. Pull Model Directory Assistance Mechanisms.............15 64 3.1 Pull Directory Message Common Format..................16 65 3.2 Pull Directory Query and Response Messages............17 66 3.2.1 Pull Directory Query Message Format.................17 67 3.2.2 Pull Directory Responses............................20 68 3.2.2.1 Pull Directory Response Message Format............20 69 3.2.2.2 Pull Directory Forwarding.........................23 70 3.3 Cache Consistency.....................................24 71 3.3.1 Update Message Format...............................27 72 3.3.2 Acknowledge Message Format..........................28 73 3.4 Summary of Records Formats in Messages................28 74 3.5 Pull Directory Hosted on an End Station...............29 75 3.6 Pull Directory Message Errors.........................31 76 3.6.1 Error Codes.........................................32 77 3.6.2 Sub-Errors Under Error Codes 1 and 3................33 78 3.6.3 Sub-Errors Under Error Codes 128 and 131............33 79 3.7 Additional Pull Details...............................34 80 3.8 The No Data Flag......................................34 81 3.9 Pull Directory Service Configuation...................35 83 4. Directory Use Strategies and Push-Pull Hybrids.........37 84 5. Security Considerations................................39 86 6. IANA Considerations....................................40 87 6.1 ESADI-Parameter Data Extensions.......................40 88 6.2 RBridge Channel Protocol Number.......................41 89 6.3 The Pull Directory (PUL) and No Data (NOD) Bits.......41 90 6.4 TRILL Pull Directory QTYPEs...........................41 91 6.5 Pull Directory Error Code Registries..................42 93 Normative References......................................43 94 Informational References..................................44 95 Acknowledgments...........................................45 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. 109 The information held by the Directory(s) is address mapping and 110 reachability information. Most commonly, what MAC (Media Access 111 Control) address [RFC7042] corresponds to an IP address within a Data 112 Label (VLAN or FGL (Fine Grained Label [RFC7172])) and the egress 113 TRILL switch (RBridge), and optionally what specific TRILL switch 114 port, from which that MAC address is reachable. But it could be what 115 IP address corresponds to a MAC address or possibly other address 116 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] or 126 both at the option of the server. Push Mode, in which a directory 127 server pushes information to TRILL switches indicating interest, is 128 specified in Section 2. Pull Mode, in which a TRILL switch queries a 129 server for the information it wants, is specified in Section 3. More 130 detail on modes of operation, including hybrid Push/Pull, are 131 provided in Section 4. 133 The mechanism used to initially populate directory data in primary 134 servers is beyond the scope of this document. A primary server can 135 use the Push Directory service to provide directory data to secondary 136 servers as described in Section 2.5. 138 1.1 Uses of Directory Information 140 A TRILL switch can consult Directory information whenever it wants, 141 by (1) searching through information that has been retained after 142 being pushed to it or pulled by it or (2) by requesting information 143 from a Pull Directory. However, the following are expected to be the 144 most common circumstances leading to directory information use. All 145 of these are cases of ingressing (or originating) a native frame. 147 1. ARP requests and replies [RFC826] are normally broadcast. But a 148 directory assisted edge TRILL switch could intercept ARP messages 149 and reply if the TRILL switch has the relevant 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, a 154 directory assisted edge TRILL switch 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 or IP 164 address in the native frame and discard the frame in that case. 166 4. RARP [RFC903] (Reverse ARP) 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 ESADI: End Station Address Distribution Information [RFC7357]. 184 FGL: Fine Grained Label [RFC7172]. 186 Host: A physical server or a virtual machine. A host must have a MAC 187 address and usually has at least one IP address. 189 IP: Internet Protocol. In this document, IP includes both IPv4 and 190 IPv6. 192 MAC: Media Access Control address [RFC7042] 193 MacDA: Destination MAC address. 195 PDSS: Push Directory Server Status. See Sections 2 and 6.1 below. 197 PUL: Pull Directory flag bit. See Sections 3 and 6.3 below. 199 primary server: A Directory server that obtains the information it is 200 serving up by a reliable mechanism outside the scope of this 201 document designed to assure the freshness of that information. 202 (See secondary server.) 204 RBridge: An alternative name for a TRILL switch. 206 secondary server: A Directory server that obtains the information it 207 is serving up from one or more primary servers. 209 TLV: Type, Length, Value 211 TRILL: Transparent Interconnection of Lots of Links or Tunneled 212 Routing in the Link Layer. 214 TRILL switch: A device that implements the TRILL protocol. 216 2. Push Model Directory Assistance Mechanisms 218 In the Push Model [RFC7067], one or more Push Directory servers 219 reside at TRILL switches and push down the address mapping 220 information for the various addresses associated with end station 221 interfaces and the TRILL switches from which those interfaces are 222 reachable [IA]. This service is scoped by Data Label (VLAN or FGL 223 [RFC7172]). A Push Directory also advertises whether or not it 224 believes it has pushed complete mapping information for a Data Label. 225 It might be pushing only a subset of the mapping and/or reachability 226 information for a Data Label. The Push Model uses the ESADI [RFC7357] 227 (End Station Address Distribution Information) protocol as its 228 distribution mechanism. 230 With the Push Model, if complete address mapping information for a 231 Data Label is being pushed, a TRILL switch (RBridge) that has that 232 complete information and is ingressing a native frame can simply drop 233 the frame if the destination unicast MAC address can't be found in 234 the mapping information available, instead of flooding the frame 235 (ingressing it as an unknown MAC destination TRILL Data frame). But 236 this will result in lost traffic if ingress TRILL switch's directory 237 information is incomplete. 239 2.1 Requesting Push Service 241 In the Push Model, it is necessary to have a way for a TRILL switch 242 to subscribe to information from the directory server(s). TRILL 243 switches simply use the ESADI [RFC7357] protocol mechanism to 244 announce, in their core IS-IS LSPs, the Data Labels for which they 245 are participating in ESADI by using the Interested VLANs and/or 246 Interested Labels sub-TLVs [RFC7176]. This will cause them to be 247 pushed the Directory information for all such Data Labels that are 248 being served by the one or more Push Directory servers. 250 2.2 Push Directory Servers 252 Push Directory servers advertise, through ESADI, their availability 253 to push the mapping information for a particular Data Label to each 254 other and to other ESADI participants for that Data Label by setting 255 the PDSS (Push Directory Server Status) in their ESADI Parameter 256 APPsub-TLV for that ESADI instance (see [RFC7357] and Section 6.1) to 257 a non-zero value. Each Push Directory server MUST participate in 258 ESADI for the Data Labels for which it will push mappings and set the 259 PDSS field in its ESADI-Parameters APPsub-TLV for that Data Label. 261 For robustness, it is useful to have multiple Push Directory Servers 262 for each Data Label. Each Push Directory server is configured with a 263 number N in the range 1 to 8, which defaults to 2, for each Data 264 Label for which it can push directory information (see Section 2.6). 265 If the Push Directory servers for a Data Label are configured 266 consistently with the same N and at least N servers are available, 267 then N copies of that directory will will be pushed. 269 Each Push Directory server also has a configurable 8-bit priority to 270 be Active which defaults to 0x40 (see Sections 2.6 and 6.1). This 271 priority is treated as an unsigned integer where larger magnitude 272 means higher priority. This priority appears in its ESADI Parameter 273 APPsub-TLV. In case of a tie in this configurable priority, the 274 System ID of the TRILL switch acting as the server is used as an 275 unsigned 6-byte integer where larger magnitude indicates higher 276 priority. 278 For each Data Label it can serve, each Push Directory server checks 279 to see if there appear to be enough higher priority servers to push 280 the desired number of copies. It does this by ordering, by priority, 281 the Push Directory servers whose advertisements are present in the 282 ESADI link state database for that Data Label and that are data 283 reachable [rfc7180bis] as indicated by its IS-IS link state database. 284 The Push Directory server then determines its own position in that 285 order. If a Push Directory server's configuration indicates that N 286 copies of the mappings for a Data Label should be pushed and the 287 server finds that it is number K in the priority ordering (where the 288 first is highest priority and the last is lowest), then if K is less 289 than or equal to N the Push Directory server is Active. If K is 290 greater than N it is Stand-By. Active and Stand-By behavior are 291 specified below in Section 2.3. 293 For a Push Directory to reside on an end station, one or more TRILL 294 switches locally connected to that end station must proxy for the 295 Push Directory server and advertise themselves in ESADI as Push 296 Directory servers. It appears to the rest of the TRILL campus that 297 these TRILL switches (that are proxying for the end station) are the 298 Push Directory server(s). The protocol between such a Push Directory 299 end station and the one or more proxying TRILL switches acting as 300 Push Directory servers is beyond the scope of this document. 302 2.3 Push Directory Server State Machine 304 The subsections below describe the states, events, and corresponding 305 actions for Push Directory servers. 307 The meaning of the value of the PDSS field in a Push Directory's 308 ESADI Parameter APPsub-TLV is summarized in the table below. 310 PDSS Meaning 311 ---- ---------- 312 0 Not a Push Directory Server 313 1 Push Directory Server in Stand-By Mode 314 2 Push Directory Server in Active Mode but not complete 315 3 Push Directory Server in Active Mode that has pushed 316 complete data 318 2.3.1 Push Directory States 320 A Push Directory Server is in one of seven states, as listed below, 321 for each Data Label it can serve. The name of each state is followed 322 by a symbol that starts and ends with an angle bracket and represents 323 the state. The value that the Push Directory Server advertises in 324 PDSS is determined by the state. In addition, it has an internal 325 State-Transition-Time variable for each Data Label it serves that is 326 set at each state transition and which enables it to determine how 327 long it has been in its current state for that Data Label. 329 Down : A completely shut down virtual state defined for 330 convenience in specifying state diagrams. A Push Directory Server 331 in this state does not advertise any Push Directory data. It may 332 be participating in ESDADI [RFC7357] with the PDSS field zero in 333 its ESADI-Parameters or might be not participating in ESADI at 334 all. (All states other than the Down state are considered to be Up 335 states and imply a non-zero PDSS field.) 337 Stand-By : No Push Directory data is advertised. Any outstanding 338 EASDI-LSP fragments containing directory data are updated to 339 remove that data and, if the result is an empty fragment (contains 340 nothing except possibly an Authentication TLV), the fragment is 341 purged. The Push Directory participates in ESDADI [RFC7357] and 342 advertises its ESADI fragment zero that includes an ESADI- 343 Parameters APPsub-TLV with the PDSS field set to 1. 345 Active : The PDSS field in the ESADI-Parameters is set to 2. If 346 a Push Directory server is Active, it advertises its directory 347 data and any changes through ESADI [RFC7357] in its ESADI-LSPs 348 using the Interface Addresses [IA] APPsub-TLV and updates that 349 information as it changes. 351 Active Completing : Same behavior as the Active state except 352 that the server responds differently to events. The purpose of 353 this state is to be sure there has been enough time for directory 354 information to propagate to subscribing edge TRILL switches before 355 the Directory Server advertises that the information is complete. 357 Active Complete : The same behavior as Active except that the 358 PDSS field in the ESADI-Parameters APPsub-TLV is set to 3 and the 359 server responds differently to events. 361 Going Stand-By : The same behavior as Active except that the 362 server responds differently to events. The purpose of this state 363 is to be sure that the information, that the directory will no 364 longer be complete, has enough time to propagate to edge TRILL 365 switches before the Directory Server stops advertising updates to 366 the information. (See note below.) 368 Active Uncompleting : The same behavior as Active except that it 369 responds differently to events. The purpose of this state is to be 370 sure that the information, that the directory will no longer be 371 complete, has enough time to propagate to edge TRILL switches 372 before the Directory Server might stop advertising updates to the 373 information. (See note below.) 375 Note: It might appear that a Push Directory could transition 376 directly from Active Complete to Active, since Active state 377 continues to advertise updates, eliminating the need for the 378 Active Uncompleting transition state. But consider the case of 379 the Push Directory that was complete being configured to be 380 incomplete and then the Stand-By Condition (see Section 2.3.2) 381 occurring immediately thereafter. If the first of these two 382 events caused the server to transition directly to the Active 383 state then, when the Stand-By Condition occurred, it would 384 immediately transition to Stand-By and stop advertising updates 385 even though there might not have been enough time for knowledge 386 of its incompleteness to have propagated to all edge TRILL 387 switches. 389 The following table summarizes PDSS value for each state: 391 State PDSS 392 ---------- ------ 393 Down 0 394 Stand-By 1 395 Active 2 396 Active Completing 2 397 Active Complete 3 398 Going Stand-By 2 399 Active Uncompleting 2 401 2.3.2 Push Directory Events and Conditions 403 Three auxiliary conditions referenced later in this section are 404 defined as follows for convenience: 406 The Activate Condition: In order to have the desired number of Push 407 Directory servers pushing data for Data Label X, this Push 408 Directory server should be active. This is determined by the 409 server finding that (A) it is priority K among the data reachable 410 Push Directory servers (where highest priority server is 1) for 411 Data Label X, (B) it is configured that there should be N copies 412 pushed for Data Lable X, and (C) K is less than or equal to N. For 413 example, if the Push Directory server is configured so that 2 414 copies should be pushed and finds that it is priority 1 or 2 among 415 the Push Directory servers that are visible in its ESADI link 416 state database and that are data reachable as indicated by its IS- 417 IS link state database. 419 The Stand-By Condition: In order to have the desired number of Push 420 Directory servers pushing data for Data Label X, this Push 421 Directory server should be stand-by (not active). This is 422 determined by the server finding that (A) it is priority K among 423 the data reachable Push Directory servers (where highest priority 424 server is 1) for Data Label X, (B) it is configured that there 425 should be N copies pushed for Data Label X, and (C) K is greater 426 than N. For example, the Push Directory server is configured that 427 2 copies should be pushed and finds that it is priority 3 or lower 428 priority (higher number) among the available Push directory 429 servers. 431 The Time Condition: The Push Directory server has been in its current 432 state for a configurable amount of time that defaults to twice its 433 CSNP (Complete Sequence Number PDU) time (see Sections 2.6 and 434 6.1).) 436 The events and conditions listed below cause state transitions in 437 Push Directory servers. 439 1. Push Directory server was Down but is now Up. 441 2. The Push Directory server or the TRILL switch on which it resides 442 is being shut down. 444 3. The Activate Condition is met and the server's configuration 445 indicates it has complete data. 447 4. The Stand-By Condition is met. 449 5. The Activate Condition is met and the server's configuration 450 indicates it has complete data. 452 6. The server's configuration is set to indicate it does not have 453 complete data. 455 7. The Time Condition is met. 457 2.3.3 State Transition Diagram and Table 459 The state transition table is as follows: 461 State|Down|Stand-By|Active| Active | Active | Going | Active 462 -----+ | | |Completing|Complete|Stand-By|Uncompleting 463 Event|| | | | | | 464 -----+----+--------+------+----------+--------+---------+------------ 465 1 || | | | | | 466 2 || | | | | | 467 3 || | | | | | 468 4 || | | | | | 469 5 || | | | | | 470 6 || | | | | | 471 7 || | | | | | 473 The above state table is equivalent to the following transition 474 diagram: 476 +-----------+ 477 | Down |<---------+ 478 +-----------+ | 479 |1 ^ | 3,4,5,6,7 | 480 | | +------------+ 481 V |2 482 +---------------+ 483 | Stand-By |<------------------------------------------+ 484 +---------------+ ^ ^ ^ | 485 |5 |3 |1,4,6,7 | | | | 486 | | +---------+ | | | 487 | V |2,4 | | 488 | +---------------------+ | | 489 | | Active |<---------|-----------------+ | 490 | +---------------------+ ^ | | | 491 | |5 ^ |1,3,6,7 ^ | | | | 492 | | | | | | | | | 493 | | | +---------+ | | | | 494 | | | | | | | 495 V V |3,6 | | | | 496 +------------------------+ | | | | 497 | Active Completing |------------+ | | 498 +------------------------+ 2,4 | | | 499 |7 |1,5 ^ | | | 500 | | | | | | 501 | +-------+ | | | 502 | | | | 503 | +--------------------------------------+ | | 504 | | | | | | 505 V V |7 |5 |3 |7 506 +---------------+ 3,6 +----------------+ 4 +----------------+ 507 | Active |------->| Active |----->| Going | 508 | Complete | | Uncompleting | | Stand-By | 509 | |<-------| | | | 510 +---------------+ 5 +----------------+ +----------------+ 511 |1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^ 512 | | | | | | | | 513 +-------+ | +------------+ | +--------+ 514 | | 515 +------------------------------------+ 517 Figure 1. Push Server State Diagram 519 2.4 Additional Push Details 521 Push Directory mappings can be distinguished from other data 522 distributed through ESADI because mappings are distributed only with 523 the Interface Addresses APPsub-TLV [IA] and are flagged in that 524 APPsub-TLV as being Push Directory data. 526 TRILL switches, whether or not they are a Push Directory server, MAY 527 continue to advertise any locally learned MAC attachment information 528 in ESADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165]. 529 However, if a Data Label is being served by complete Push Directory 530 servers, advertising such locally learned MAC attachment generally 531 SHOULD NOT be done as it would not add anything and would just waste 532 bandwidth and ESADI link state space. An exception might be when a 533 TRILL switch learns local MAC connectivity and that information 534 appears to be missing from the directory mapping. 536 Because a Push Directory server needs to advertise interest in one or 537 more Data Labels even though it might not want to receive multi- 538 destination TRILL Data packets in those Data Labels, the No Data 539 (NOD) flag bit is provided as discussed in Section 3.8. 541 When a Push Directory server is no longer data reachable [rfc7180bis] 542 as indicated by the IS-IS link state database, other TRILL switches 543 MUST ignore any Push Directory data from that server because it is no 544 longer being updated and may be stale. 546 The nature of dynamic distributed asynchronous systems is such that 547 it is impossible for a TRILL switch receiving Push Directory 548 information to be absolutely certain that it has complete 549 information. However, it can obtain a reasonable assurance of 550 complete information by requiring two conditions to be met: 551 1. The PDSS field is 3 in the ESADI zero fragment from the server 552 for the relevant Data Label. 553 2. In so far as it can tell, it has had continuous data 554 connectivity to the server for a configurable amount of time 555 that defaults to twice the server's CSNP time (PushDirTimer, 556 see Sectino 2.6). 557 Condition 2 is necessary because a client TRILL switch might be just 558 coming up and receive an EASDI LSP meeting the requirement in 559 condition 1 above but has not yet received all of the ESADI LSP 560 fragments from the Push Directory server. 562 There may be conflicts between mapping information from different 563 Push Directory servers or conflicts between locally learned 564 information and information received from a Push Directory server. In 565 case of such conflicts, information with a higher confidence value 566 [RFC6325] [IA] is preferred over information with a lower confidence. 567 In case of equal confidence, Push Directory information is preferred 568 to locally learned information and if information from Push Directory 569 servers conflicts, the information from the higher priority Push 570 Directory server is preferred. 572 2.5 Primary to Secondary Server Push Service 574 A secondary Push or Pull Directory server is one that obtains its 575 data from a primary directory server. Other techniques MAY be used 576 but, by default, this data transfer occurs through the primary server 577 acting as a Push Directory server for the Data Labels involved while 578 the secondary directory server takes the pushed data it receives from 579 the highest priority Push Directory server and re-originates it. Such 580 a secondary server may be a Push Directory server or a Pull Directory 581 server or both for any particular Data Label. Because the data from a 582 secondary server will necessarily be at least a little less fresh 583 than that from a primary server, it is RECOMMENDED that the re- 584 originated secondary server data be given a confidence level of one 585 less than that of the data as received from the primary (or unchanged 586 if it is already of minimum confidence). 588 2.6 Push Directory Configuration 590 The following per Data Label configuraiton parameters are available 591 for controlling Push Directory behavior: 593 Name Range Default Section 594 --------------- -------- ------- ------- 595 PusDirService T/F F 2.2 596 PushDirServers 1 - 8 2 2.2 597 PushDirPriority 0 - 255 0x3F 2.2 598 PushDirComplete T/F F 2.3.1, 2.3.2 599 PushDirTimer 1 - 511 2*CSNP 2.3.2, 2.4 601 PushDirService is a boolean. When false, Push Directory service is 602 not provided; when true, it is. 604 PushDirComplete is a boolean. When false, the server never indicates 605 that the information it has pushed is complete; when true, it does so 606 indicate after pushing all the information it knows. 608 PushDirTimer defaults to two times the ESADI CSNP configuration value 609 but not less than 1 second. 611 3. Pull Model Directory Assistance Mechanisms 613 In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory 614 information from an appropriate Directory Server when needed. 616 Pull Directory servers for a particular Data Label X are found by 617 looking in the core TRILL IS-IS link state database for data 618 reachable [rfc7180bis] TRILL switches that advertise themselves by 619 having the Pull Directory flag (PUL) on in their Interested VLANs or 620 Interested Labels sub-TLV (see Section 6.3)) for that Data Label. If 621 multiple such TRILL switches indicate that they are Pull Directory 622 Servers for a particular Data Label, pull requests can be sent to any 623 one or more of them but it is RECOMMENDED that pull requests be 624 preferentially sent to the server or servers that are lowest cost 625 from the requesting TRILL switch. 627 Pull Directory requests are sent by enclosing them in an RBridge 628 Channel [RFC7178] message using the Pull Directory channel protocol 629 number (see Section 6.2). Responses are returned in an RBridge 630 Channel message using the same channel protocol number. See Section 631 3.2 for Query and Response Message formats. For cache consistency or 632 notification purposes, Pull Directory servers, under certain 633 conditions, MUST send unsolicited Update Messages to client TRILL 634 switches they believe may be holding old data and those clients can 635 acknowledge such updates, as described in Section 3.3. All these 636 messages have a common header as described in Section 3.1. Errors can 637 be returned for queries or updates as described in Section 3.6. 639 The requests to Pull Directory Servers are typically derived from 640 ingressed ARP [RFC826], ND [RFC4861], or RARP [RFC903] messages, or 641 data frames with unknown unicast destination MAC addresses, 642 intercepted by an ingress TRILL switch as described in Section 1.1. 644 Pull Directory responses include an amount of time for which the 645 response should be considered valid. This includes negative responses 646 that indicate no data is available. It is RECOMMENDED that both 647 positive responses with data and negative responses be cached and 648 used to locally handle ARP, ND, RARP, unknown destination MAC frames, 649 or the like, until the responses expire. If information previously 650 pulled is about to expire, a TRILL switch MAY try to refresh it by 651 issuing a new pull request but, to avoid unnecessary requests, SHOULD 652 NOT do so if it has not been recently used. The validity timer of 653 cached Pull Directory responses is NOT reset or extended merely 654 because that cache entry is used. 656 3.1 Pull Directory Message Common Format 658 All Pull Directory messages are transmitted as the payload of RBridge 659 Channel messages [RFC7178]. Pull Directory messages are formatted as 660 described herein starting with the following common 8-byte header: 662 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Ver | Type | Flags | Count | Err | SubErr | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Sequence Number | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Type Specific Payload - variable length 670 +-+-+- ... 672 Ver: Version of the Pull Directory protocol as an unsigned 673 integer. Version zero is specified in this document. 675 Type: The Pull Directory message type as follows: 677 Type Section Name 678 ---- ------- -------- 679 0 - Reserved 680 1 3.2.1 Query 681 2 3.2.2 Response 682 3 3.3.1 Update 683 4 3.3.2 Acknowledge 684 5-14 - Unassigned 685 15 - Reserved 687 Flags: Four flag bits whose meaning depends on the Pull Directory 688 message Type. Flags whose meanings are not specified are 689 reserved, MUST be sent as zero, and MUST be ignored on receipt. 691 Count: Pull Directory message types specified herein have zero or 692 more occurrences of a Record as part of the type specific 693 payload. The Count field is the number of occurrences of that 694 Record as an unsigned integer. For any Pull Directory messages 695 not structured with such occurrences, this field MUST be sent 696 as zero and ignored on receipt. 698 Err, SubErr: The error and suberror fields are only used in 699 messages that are in the nature of replies. In messages that 700 are requests or updates, these fields MUST be sent as zero and 701 ignored on receipt. An Err field containing the value zero 702 means no error. The meaning of values in the SubErr field 703 depends on the value of the Err field but, in all cases, a zero 704 SubErr field is allowed and provides no additional information 705 beyond the value of the Err field. 707 Sequence Number: An identifying 32-bit quantity set by the TRILL 708 switch sending a request or other unsolicited message and 709 returned in every corresponding reply or acknowledgement. It is 710 used to match up responses with the message to which they 711 respond. 713 Type Specific Payload: Format depends on the Pull Directory 714 message Type. 716 3.2 Pull Directory Query and Response Messages 718 The format of Pull Directory Query and Response Messages is specified 719 below. 721 3.2.1 Pull Directory Query Message Format 723 A Pull Directory Query Message is sent as the Channel Protocol 724 specific content of an RBridge Channel message [RFC7178] TRILL Data 725 packet or as a native RBridge Channel data frame (see Section 3.5). 726 The Data Label of the packet is the Data Label in which the query is 727 being made. The priority of the channel message is a mapping of the 728 priority of the frame being ingressed that caused the query with the 729 default mapping depending, per Data Label, on the strategy (see 730 Section 4) or a configured priority (DirGenQPriority, Section 3.9) 731 for generated queries. (Generated queries are those not the result of 732 a mapping. For example, a query to refresh a cache entry.) The 733 Channel Protocol specific data is formatted as a header and a 734 sequence of zero or more QUERY Records as follows: 736 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Ver | Type | Flags | Count | Err | SubErr | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Sequence Number | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | QUERY 1 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 745 | QUERY 2 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 747 | ... 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 749 | QUERY K 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 752 Ver, Sequence Number: See 3.1. 754 Type: 1 for Query. Queries received by an TRILL switch that is not 755 a Pull Directory for the relevant Data Label result in an error 756 response (see Section 3.6) unless inhibited by rate limiting. 757 (See [RFC7178] for response if the Pull Directory RBridge 758 Channel protocol is not implemented or enabled.) 760 Flags, Err, and SubErr: MUST be sent as zero and ignored on 761 receipt. 763 Count: Number of QUERY Records present. A Query Message Count of 764 zero is explicitly allowed, for the purpose of pinging a Pull 765 Directory server to see if it is responding. On receipt of such 766 an empty Query Message, a Response Message that also has a 767 Count of zero is returned unless inhibited by rate limiting. 769 QUERY: Each QUERY Record within a Pull Directory Query Message is 770 formatted as follows: 772 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 773 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 774 | SIZE |FL| RESV | QTYPE | 775 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 776 If QTYPE = 1 777 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 778 | AFN | 779 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 780 | Query address ... 781 +--+--+--+--+--+--+--+--+--+--+--... 782 If QTYPE = 2, 3, 4, or 5 783 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 784 | Query frame ... 785 +--+--+--+--+--+--+--+--+--+--+--... 787 SIZE: Size of the QUERY Record in bytes as an unsigned integer 788 not including the SIZE field and following byte. A value of 789 SIZE so large that the material doesn't fit in the Query 790 Message indicates a malformed QUERY Record. The QUERY Record 791 with the illegal SIZE value and any subsequent QUERY Records 792 MUST be ignored and the entire Query Message MAY be ignored. 794 FL: The FLooded flag that is ignored if QTYPE is zero. If QTYPE 795 is 2 through 5 and the directory information sought is not 796 found, the frame provided is flooded, otherwise it is not 797 forwarded. See Section 3.2.2.2. 799 RESV: A block of three reserved bits. MUST be sent as zero and 800 ignored on receipt. 802 QTYPE: There are several types of QUERY Records currently 803 defined in two classes as follows: (1) a QUERY Record that 804 provides an explicit address and asks for all addresses for 805 the interface specified by the query address and (2) a QUERY 806 Record that includes a frame. The fields of each are 807 specified below. Values of QTYPE are as follows: 809 QTYPE Description 810 ----- ----------- 811 0 Reserved 812 1 Address query 813 2 ARP query frame 814 3 ND query frame 815 4 RARP query frame 816 5 Unknown unicast MAC query frame 817 6-14 Unassigned 818 15 Reserved 820 AFN: Address Family Number of the query address. 822 Query Address: The query is asking for any other addresses, 823 and the nickname of the TRILL switch from which they are 824 reachable, that correspond to the same interface, within 825 the Data Label of the query of the address provided. 826 Typically that would be something like the following: 827 (1) A 48-bit MAC address with the querying TRILL switch 828 primarily interested in either 829 (1a) the RBridge by which that MAC address is 830 reachable so that the querying RBridge can 831 forward an unknown (before he query) destination 832 MAC address native frame as a unicast TRILL Data 833 packet rather than flooding it, or 834 (1b) the IP address corresponding to the MAC address 835 so that RBridge can locally respond to a RARP 836 [RFC903] native frame. 837 (2) An IPv4 or IPv6 address with the querying RBridge 838 interested in the corresponding MAC address so it can 839 locally respond to an ARP [RFC826] or ND [RFC4861] 840 native frame. 841 But the query address could be some other address type 842 for which an AFN has been assigned, such as a 64-bit MAC 843 address [RFC7042] or a CLNS address [X.233]. 845 Query Frame: Where a QUERY Record is the result of an ARP, 846 ND, RARP, or unknown unicast MAC destination address, the 847 ingress TRILL switch MAY send the frame to a Pull 848 Directory Server if the frame is small enough that the 849 resulting Query Message fits into a TRILL Data packet 850 within the campus MTU. 852 If no response is received to a Pull Directory Query Message within a 853 configurable timeout (DirQueryTimeout, see Section 3.9), then the 854 Query Message should be re-transmitted with the same Sequence Number 855 (up to a configurable number of times (DirQueryRetries, see Section 856 3.9)). If there are multiple QUERY Records in a Query Message, 857 responses can be received to various subsets of these QUERY Records 858 before the timeout. In that case, the remaining unanswered QUERY 859 Records should be re-sent in a new Query Message with a new sequence 860 number. If a TRILL switch is not capable of handling partial 861 responses to queries with multiple QUERY Records, it MUST NOT send a 862 Request Message with more than one QUERY Record in it. 864 See Section 3.6 for a discussion of how Query Message errors are 865 handled. 867 3.2.2 Pull Directory Responses 869 A Pull Directory Query Message results in a Pull Directory Response 870 Message as described in Section 3.2.2.1. 872 In addition, if the QUERY Record QTYPE was 2, 3, 4, or 5, the frame 873 included in the Query may be modified and forwarded by the Pull 874 Directory server as described in Section 3.2.2.2. 876 3.2.2.1 Pull Directory Response Message Format 878 Pull Directory Response Messages are sent as the Channel Protocol 879 specific content of an RBridge Channel message [RFC7178] TRILL Data 880 packet or as a native RBridge Channel data frame (see Section 3.5). 881 Responses are sent with the same Data Label and priority as the Query 882 Message to which they correspond except that the Response Message 883 priority is limited to be not more than the configured value 884 DirRespMaxPriorty (Section 3.9). 886 The RBridge Channel protocol specific data format is as follows: 888 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Ver | Type | Flags | Count | Err | SubErr | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Sequence Number | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | RESPONSE 1 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 897 | RESPONSE 2 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 899 | ... 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 901 | RESPONSE K 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 904 Ver, Sequence Number: As specified in Section 3.1. 906 Type: 2 = Response. 908 Flags: MUST be sent as zero and ignored on receipt. 910 Count: Count is the number of RESPONSE Records present in the 911 Response Message. 913 Err, SubErr: A two-part error code. Zero unless there was an error 914 in the Query Message, for which case see Section 3.6. 916 RESPONSE: Each RESPONSE Record within a Pull Directory Response 917 Message is formatted as follows: 919 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 920 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 921 | SIZE |OV| RESV | Index | 922 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 923 | Lifetime | 924 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 925 | Response Data ... 926 +--+--+--+--+--+--+--+--+--+--+--... 928 SIZE: The size of the RESPONSE Record is an unsigned integer 929 number of bytes not including the SIZE field and following 930 byte. A value of SIZE so large that the material doesn't fit 931 in the Query Message indicates a malformed QUERY Record. The 932 QUERY Record with such an excessive SIZE value and any 933 subsequent QUERY Records MUST be ignored and the entire 934 Query Message MAY be ignored. 936 OV: The overflow flag. Indicates, as described below, that 937 there was too much Response Data to include in one Response 938 Message. 940 RESV: Three reserved bits that MUST be sent as zero and ignored 941 on receipt. 943 Index: The relative index of the QUERY Record in the Query 944 Message to which this RESPONSE Record corresponds. The index 945 will always be one for Query Messages containing a single 946 QUERY Record. If the Index is larger than the Count was in 947 the corresponding Query, that RESPONSE Record MUST be 948 ignored and subsequent RESPONSE Records or the entire 949 Response Message MAY be ignored. 951 Lifetime: The length of time for which the response should be 952 considered valid in units of 100 milliseconds except that 953 the values zero and 2**16-1 are special. If zero, the 954 response can only be used for the particular query from 955 which it resulted and MUST NOT be cached. If 2**16-1, the 956 response MAY be kept indefinitely but not after the Pull 957 Directory server goes down or becomes unreachable. (The 958 maximum definite time that can be expressed is a little over 959 1.8 hours.) 961 Response Data: There are three types of RESPONSE Records. 962 - If the Err field of the enclosing Respose Message has a 963 message level error code in it, then the the RESPONSE 964 Records are omitted and Count will be zero. See Section 965 3.6 for additional information on errors. 966 - If the Err field of the enclosing Response Message has a 967 record level error code in it, then the RESPONSE Records 968 are those in error as further described in Section 3.6. 969 - If the Err field of the enclosing Reponse Message is 970 zero, then the Response Data in each RESPONSE Record is 971 formatted as the value part of an Interface Addresses 972 APPsub-TLV [IA]. The maximum size of such contents is 255 973 bytes in the case when the RESPONSE Record SIZE field is 974 255. 976 Multiple RESPONSE Records can appear in a Response Message with the 977 same Index if an answer to the QUERY Record consists of multiple 978 Interface Address APPsub-TLV values. This would be necessary if, for 979 example, a MAC address within a Data Label appears to be reachable by 980 multiple TRILL switches. However, all RESPONSE Records to any 981 particular QUERY Record MUST occur in the same Response Message. If a 982 Pull Directory holds more mappings for a queried address than will 983 fit into one Response Message, it selects which to include by some 984 method outside the scope of this document and sets the overflow flag 985 (OV) in all of the RESPONSE Records responding to that query address. 987 See Section 3.6 for a discussion of how errors are handled. 989 3.2.2.2 Pull Directory Forwarding 991 Query Messages with QTYPEs 2, 3, 4, and 5 are interpreted and handled 992 as described below. In these cases, if the information implicitly 993 sought is not in the directory and the FL flag in the query message 994 was one, the provided frame is forwarded by the Pull Directory server 995 as a multi-destination TRILL Data packet with the ingress nickname of 996 the Pull Directory server (or proxy if it is hosted on an end 997 station) in the TRILL header. If the FL flag is zero, the frame is 998 not forwarded in this case. 1000 If there was no error in the handling of the enclosing Query Message, 1001 the Pull Directory server forwards the frame inside that QUERY 1002 Record, after modifying it in some cases, as described below: 1004 ARP: When QTYPE is 2, an ARP [RFC826] frame is included in the QUERY 1005 Record. The ar$op field MUST be ares_op$REQUEST and for the 1006 response described in 3.2.2.1, this is treated as a query for the 1007 target protocol address where the AFN of that address is given by 1008 ar$pro. (ARP field and value names with embedded dollar signs are 1009 specified in [RFC826].) If ar$op is not ares_op$REQUEST or the ARP 1010 is malformed or the query fails, an error is returned. Otherwise 1011 the ARP is modified into the appropriate ARP response that is then 1012 sent by the Pull Directory server as a TRILL Data packet. 1014 ND: When QTYPE is 3, an IPv6 Neighbor Discover (ND [RFC4861]) frame 1015 is included in the QUERY Record. Only Neighbor Solicitation ND 1016 frames (corresponding to an ARP query) are allowed. An error is 1017 returned for other ND frames or if the target address is not 1018 found. Otherwise an ND Neighbor Advertisement response is returned 1019 by the Pull Directory server as a TRILL Data packet. 1021 RARP: When QTYPE is 4, a RARP [RFC903] frame is included in the QUERY 1022 Record. If the ar$op field is ares_op$REQUEST, the frame is 1023 handled as an ARP as described above. Otherwise the ar$op field 1024 MUST be 'reverse request' and for the response described in 1025 3.2.2.1, this is treated as a query for the target hardware 1026 address where the AFN of that address is given by ar$hrd. (See 1027 [RFC826] for RARP fields.) If ar$op is not one of these values or 1028 the RARP is malformed or the query fails, an error is returned. 1029 Otherwise the RARP is modified into the appropriate RARP response 1030 that is then unicast by the Pull Directory server as a TRILL Data 1031 packet to the source hardware MAC address. 1033 MacDA: When QTYPE is 5, indicating a frame is provided in the QUERY 1034 Record whose destination MAC address TRILL switch attachment is 1035 unknown, the only requirement is that this MAC address must be 1036 unicast. If it is group addressed an error is returned. For the 1037 response described in 3.2.2.1, it is treated as a query for the 1038 MacDA. If the Pull Directory contains TRILL switch attachment 1039 information for the MAC address in the Data Label of the Query 1040 Message, it forwards the frame to that switch in a unicast TRILL 1041 Data packet. 1043 3.3 Cache Consistency 1045 Unless it sends all responses with a Lifetime of zero, a Pull 1046 Directory MUST take action, by sending Update Messages, to minimize 1047 the amount of time that a TRILL switch will continue to use stale 1048 information from that Pull Directory. The format of Update Messages 1049 and the Acknowledge Messages used to respond to Update Messages are 1050 given in Sections 3.3.1 and 3.3.2. 1052 A Pull Directory server MUST maintain one of three sets of records 1053 concerning possible cached data at clients of that server. These are 1054 numbered and listed below in order of increasing specificity: 1056 Method 1, Least Specific. An overall record per Data Label of when 1057 the last positive response data sent will expire and when the 1058 last negative response sent will; the records are retained until 1059 such expiration. 1060 Pro: Minizes the record keeping burden on the Pull Directory 1061 server. 1062 Con: Increases the volume and overhead due to spontaneous 1063 Update Messages and due to unnecessarily invalidating cached 1064 information. 1066 Method 2, Medium Specificity. For each unit of data (IA APPsub-TLV 1067 Address Set [IA]) held by the server, record when the last 1068 response sent with that positive response data will expire. In 1069 addition, record each address about which a negative response 1070 was sent by the server and when the last such negative response 1071 will expire. Each such record of a positive or negative response 1072 is discarded upon expiration. 1073 Pro/Con: An intermediate level of detail in server record 1074 keeping and an intermediate volume of and overhead due to 1075 spontaneous Update Messages with some unnecessary invalidation 1076 of cached information. 1078 Method 3, Most Specific. For each unit of data held by the server 1079 (IA APPsub-TLV Address Set [IA]) and each address about which a 1080 negative response was sent, a list of TRILL switches that were 1081 sent that data as a positive response or sent a negative 1082 response for the address, and the expected time to expiration 1083 for that data or address at each such TRILL switch, assuming the 1084 requester cached the response. Each list entry is retained until 1085 such expiration time. 1086 Pro: Minimizes spontaneous Update Messages sent to update 1088 pull client TRILL switch caches and minimizes unnecessary 1089 invalidation of cached information. 1090 Con: Increaed record keeping burden on the Pull Directory 1091 server. 1093 RESPONSE Records sent with a zero lifetime are considered to have 1094 already expired and so do not need to be tracked. In all cases, there 1095 may still be brief periods of time when directory information has 1096 changed, but information a pull client has cached has not yet been 1097 updated or expunged. 1099 A Pull Directory server may have a limit as to how many TRILL 1100 switches for which it can maintain detailed expiry information by 1101 method 3 above or how many data units or addresses it can maintain 1102 expiry information for by method 2 or the like. If such limits are 1103 exceeded, it MUST transition to a lower numbered method but, in all 1104 cases, MUST support, at a minimum, method 1. 1106 When data at a Pull Directory is changed, deleted, or added and there 1107 may be unexpired stale information at a requesting TRILL switch, the 1108 Pull Directory MUST send an Update Message as discussed below. The 1109 sending of such an Update Message MAY be delayed by a configurable 1110 number of milliseconds (DirUpdateDelay, see Section 3.9) to await 1111 other possible changes that could be included in the same Update. 1113 1. If method 1, the least detailed method, is being followed, then 1114 when any Pull Directory information in a Data Label is changed 1115 or deleted and there are outstanding cached positive data 1116 response(s), an all-addresses flush positive data Update Message 1117 is flooded within that Data Label as an RBridge Channel Message. 1118 Similarly if data is added and there are outstanding cached 1119 negative responses, an all-addresses flush negative message is 1120 similarly flooded. The Count field being zero in an Update 1121 Message indicates "all-addresses". On receiving an all-addresses 1122 flooded flush positive Update from a Pull Directory server it 1123 has used, indicated by the F and P bits being one and the Count 1124 being zero, a TRILL switch discards the cached data responses it 1125 has for that Data Label. Similarly, on receiving an all 1126 addresses flush negative Update, indicated by the F and N bits 1127 being one and the Count being zero, it discards all cached 1128 negative replies for that Data Label. A combined flush positive 1129 and negative can be flooded by having all of the F, P, and N 1130 bits set to one resulting in the discard of all positive and 1131 negative cached information for the Data Label. 1133 2. If method 2 is being followed, then a TRILL switch floods 1134 address specific positive Update Messages when data that might 1135 be cached by a querying TRILL switch is changed or deleted and 1136 floods address specific negative Update Messages when such 1137 information is added to. Such messages are sent as RBridge 1138 Channel messages. However the Count field will be non-zero and 1139 either the P or N bit, but not both, will be one. There are 1140 actually four possible message types that can be flooded: 1142 2.a If data that might still be cached is updated: 1143 An Update Message is sent with the P flag set and the 1144 Err field zero. The addresses in the RESPONSE Records that 1145 are in the unsolicited response message are compared to the 1146 addresses for which the receiving TRILL switch is holding 1147 cached positive information from that server. If they match, 1148 the cached information is updated. 1150 2.b If data that might still be cached is deleted: 1151 An Update Message is sent with the P flag set and the 1152 Err field non-zero giving the error that would now be 1153 encountered in attempting to pull information for the 1154 relevant address from the Pull Directory server. In this 1155 non-zero Err field case, the RESPONSE Record(s) differ from 1156 non-zero Err Reply Message RESPONSE Records in that they 1157 include an interface address set. Any cached positive 1158 information for the address is deleted and the negative 1159 response is cached as per the lifetime given. 1161 2.c If data for an address for which a negative response was 1162 sent is added, so that negative response that might still be 1163 cached is now incorrect: 1164 An Update Message is sent with the N flag set to one and 1165 the Err field zero. The addresses in the RESPONSE Records in 1166 the unsolicited response are compared to the addresses for 1167 which the receiving TRILL switch is holding cached negative 1168 information from that server; if they match, the cached 1169 negative information is deleted and the positive information 1170 provided is cached as per the lifetime given. 1172 2.d In the rare case where it is desired to change the lifetime 1173 or error associated with negative information that might 1174 still be cached: 1175 An Update Message is sent with the N flag set to one and 1176 the Err field non-zero. As in case 2.b above, the RESPONSE 1177 Record(s) give the relevant addresses. Any cached negative 1178 information for the address is updated. 1180 3. If method 3 is being followed, the same sort of unsolicited 1181 Update Messages are sent as with method 2 above except they are 1182 not normally flooded but unicast only to the specific TRILL 1183 switches the directory server believes may be holding the cached 1184 positive or negative information that needs deletion or 1185 updating. However, a Pull Directory server MAY flood unsolicited 1186 updates under method 3, for example if it determines that a 1187 sufficiently large fraction of the TRILL switches in some Data 1188 Label are requesters that need to be updated so that flooding is 1189 more efficient that unicast. 1191 A Pull Directory server tracking cached information with method 3 1192 MUST NOT clear the indication that it needs to update cached 1193 information at a querying TRILL switch until it has either (a) sent 1194 an Update Message and received a corresponding Acknowledge Message or 1195 (b) it has sent a configurable number of updates at a configurable 1196 interval which default to 3 updates 100 milliseconds apart (see 1197 Section 3.9). 1199 A Pull Directory server tracking cached information with methods 2 or 1200 1 SHOULD NOT clear the indication that it needs to update cached 1201 information until it has sent an Update Message and received a 1202 corresponding Acknowledge Message from all of its ESADI neighbors or 1203 it has sent a number of updates at an interval as in the paragraph 1204 above. 1206 3.3.1 Update Message Format 1208 An Update Message is formatted as a Response Message with the 1209 differences described in Section 3.3 above and the following: 1211 o The Type field in the message header is set to 3. 1212 o The Err field in the message header MUST be sent as zero and 1213 ignored on receipt. 1214 o The Index field in the RESPONSE Record(s) is set to zero (but the 1215 Count field in the Update Message header MUST still correctly 1216 indicate the number of RESPONSE Records present). 1217 o The priority with which the message is sent, DirUpdatePriority, is 1218 configurable and defaults to 5 (see Section 3.9). 1220 Update Messages are initiated by a Pull Directory server. The 1221 Sequence number space used is controlled by the originating Pull 1222 Directory server. This update Sequence number space is differennt 1223 from the Sequence number space used in a Query and the corresponding 1224 Response that are controlled by the querying TRILL switch. 1226 The 4-bit Flags field of the message header for an Update Message is 1227 as follows: 1229 +---+---+---+---+ 1230 | F | P | N | R | 1231 +---+---+---+---+ 1233 F: The Flood bit. If zero, the Update Message is unicast. If F=1, it 1234 is multicast to All-Egress-RBridges. 1236 P, N: Flags used to indicate positive or negative Update Messages. 1237 P=1 indicates positive. N=1 indicates negative. Both may be 1 for 1238 a flooded all addresses Update. 1240 R: Reserved. MUST be sent as zero and ignored on receipt 1242 For tracking methods 2 and 3 in Section 3.3.1, a particular Update 1243 Message must have either the P flag or the N flag set but not both. 1244 If both are set, the Update Message MUST be ignored. 1246 3.3.2 Acknowledge Message Format 1248 An Acknowledge Message is sent in response to an Update Message to 1249 confirm receipt or indicate an error, unless response is inhibited by 1250 rate limiting. It is formatted as a Response Message but the Type is 1251 set to 4. 1253 If there are no errors in the processing of an Update Message or if 1254 there is a message level overall or header error in an Update 1255 Message, the message is echoed back with the Err and SubErr fields 1256 set approriately, the Type changed to Acknowledge, and a null records 1257 section with the Count field set to zero. 1259 If there is a record level error in an Update Message, one or more 1260 Acknowledge Messages may be returned with the erroneous record(s) 1261 indicated in Section 3.5. 1263 The Acknowledge Messages is sent with the same priority as the Update 1264 Message it acknowledges but not more than a configured priority 1265 (DirAckMaxPriority) that defaults to 5 (see Section 3.9). 1267 3.4 Summary of Records Formats in Messages 1269 As specified in Section 3.2 and 3.3, the Query, Response, Update, and 1270 Acknowledge Messages can have zero or more repeating Record 1271 structures under different circumstances, as summarized below. The 1272 "Err" column abbreivations in this table have the meanings listed 1273 below. "IA APPsubTLV value" means the value part of the IA APPsub-TLV 1274 specified in [IA]. 1276 MBZ = MUST be zero 1277 Z = zero 1278 NZ = non-zero 1279 NZM = non-zero message level error 1280 NZR = non-zero record level error 1282 Message Err Section Record Structure Response Data 1283 ----------- --- ------- ---------------- ------------------ 1284 Query MBZ 3.2.1 QUERY Record - 1285 Response Z 3.2.2.1 RESPONSE Record IA APPsubTLV value 1286 Response NZM 3.2.2.1 null - 1287 Response NZR 3.2.2.1 RESPONSE Record Records with error 1288 Update MBZ 3.3.1 RESPONSE Record IA APPsubTLV value 1289 Acknowledge Z 3.3.2 null - 1290 Acknowledge NZM 3.3.2 null - 1291 Acknowledge NZR 3.3.2 RESPONSE Record Records with error 1293 See Section 3.6 for further details on errors. 1295 3.5 Pull Directory Hosted on an End Station 1297 Optionally, a Pull Directory actually hosted on an end station MAY be 1298 supported. In that case, one or more TRILL switches must proxy for 1299 the end station and advertise themselves as Pull Directory servers. 1300 Such proxies must have a direct connection to the end station, that 1301 is a connection not involving any intermediate TRILL switches. 1303 * * * * * * * 1304 * * 1305 +---------------+ * 1306 | RB1, Proxy | * 1307 | Pull Directory| * 1308 +-------+ Server | +----+ 1309 | +---------------+ |RB99| 1310 +---------------+ | * +----+ 1311 | End Station | +--+---+ +---------------+ * 1312 | Pull Directory+---+Bridge+---+ RB2, Proxy | * 1313 | Server | +--+---+ | Pull Directory| * 1314 +---------------+ | | Server | * 1315 | +---------------+ * 1316 | * TRILL * 1317 . * Campus * 1318 . * * 1319 . * * * * * * * 1321 Figure 2. End Station Pull Directory Example 1323 The figure above gives an example where RB1 and RB2 appear to the 1324 rest of the TRILL campus, such as RB99, to be Pull Directory servers 1325 but are actually configured to proxy for an End Station hosted Pull 1326 Directory server. This example is specific but many variations are 1327 possible. The Bridge shown might be a complex bridged LAN or might be 1328 absent if, for example, the end station was dual ported with point- 1329 to-point Ethernet links to RB1 and RB2. There could be one or more 1330 than two RBridges proxying for the server. Furthermore, there could 1331 be two or more end stations with Pull Directory servers on them. Each 1332 proxy could then be diffrently configured as to the Data Labels for 1333 which it is providing service selected from the union of the Data 1334 Labels supported by the End Station hosted servers and could select 1335 from among those End Station hosted servers supporting each Data 1336 Label the proxy is configured to serve up. 1338 When the proxy Pull Directory server TRILL switch receives a Query 1339 Message, it modifies the inter-RBridge Channel message received into 1340 a native RBridge Channel message and forwards it to the end station 1341 Pull Directory server. Later, when it receives one or more responses 1342 from that end station by native RBridge Channel messages, it modifies 1343 them into inter-RBridge Channel messages and forwards them to the 1344 source TRILL switch of the original Query Message. Similarly, an 1345 Update from the end station is forwarded to client TRILL switches and 1346 acknowledgements from those TRILL switches are returned to the end 1347 station by the proxy. Because native RBridge Channel messages have no 1348 TRILL Header and are addressed by MAC address, as opposed to inter- 1349 RBridge Channel messages that are TRILL Data packets and are 1350 addressed by nickname, nickname information must be added to the 1351 native RBridge Channel version of Pull Directory messages. 1353 The native Pull Directory RBridge Channel messages use the same 1354 Channel protocol number as do the inter-RBridge Pull Directory 1355 RBridge Channel messages. The native messages SHOULD be sent with an 1356 Outer.VLAN tag that gives the priority of each message which is the 1357 priority of the original inter-RBridge request packet. The Outer.VLAN 1358 ID used is the Designated VLAN on the link to the end station 1359 [RFC6325]. Since there is no TRILL Header or inner Data Label for 1360 native RBridge Chanel messages, that information is added to the 1361 header. 1363 The native RBridge Channel message Pull Directory message protocol 1364 dependent data part is the same as for inter-RBridge Channel messages 1365 except that the 8-byte header described in Section 3.1 is expanded to 1366 14 or 18 bytes as follows: 1368 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Ver | Type | Flags | Count | Err | SubErr | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Sequence Number | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | Nickname (2 bytes) | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1377 | Data Label ... (4 or 8 bytes) | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1379 | Type Specific Payload - variable length 1380 +-+-+- ... 1382 Fields not described below are as in Section 3.1. 1384 Nickname: The nickname of the original TRILL switch that is 1385 communicating with the end station Pull Directory. Usually this 1386 is a remote TRILL switch but it could be the TRILL switch to 1387 which the end station is attached. The proxy copies this 1388 nickname from the ingress nickname when mapping a Query or 1389 Acknowledge Message to native form. It also takes this nickname 1390 from a native Response or Update Message to be used as the 1391 egress of the inter-RBridge form on the message unless it is a 1392 flooded Update in which case a distribution tree is used. 1394 Data Label: The Data Label that normally appears right after the 1395 Inner.MacSA of the an RBridge Channel Pull Directory message 1396 appears in this field in the native RBridge Channel message 1397 version. This Data Label appear in a native Query Message, to 1398 be reflected in a Response Message, or it might appear in a 1399 native Update to be reflected in an Acknowledge Message. 1401 3.6 Pull Directory Message Errors 1403 A non-zero Err field in the Pull Directory Reponse or Acknowledge 1404 Message header indicates an error message. 1406 If there is an error that applies to an entire Query or Update 1407 Message or its header, as indicated by the range of the value of the 1408 Err field, then the QUERY Records probably were not even looked at by 1409 the Pull Directory Server and would provide no additional information 1410 in the Response or Acknowledge Message. Therefore, the Records 1411 section of the Query Response or Update Message is omitted and the 1412 Count field is set to zero in the Response or Acknowledgement 1413 Message. 1415 If errors occur at the QUERY Record level for a Query Message, they 1416 MUST be reported in a Response Message separate from the results of 1417 any successful non-erroneous QUERY Records. If multiple QUERY Records 1418 in a Query Message have different errors, they MUST be reported in 1419 separate Response Messages. If multiple QUERY Records in a Query 1420 Message have the same error, this error response MAY be reported in 1421 one or multiple Response Messages. In an error Response Message, the 1422 QUERY Record or Records being responded to appear, expanded by the 1423 Lifetime for which the server thinks the error might persist (usually 1424 2**16-1 which indicates indefinitely) and with their Index inserted, 1425 as the RESPONSE Record or Records. 1427 If errors occur at the RESPONSE Record level for an Update Message, 1428 they MUST be reported in an Acknowledge Message separate from the 1429 acknowledgement of any non-erroneous RESPONSE Records. If multiple 1430 RESPONSE Records in an Update have different errors, they MUST be 1431 reported in separate Acknowledge Messages. If multiple RESPONSE 1432 Records in an Update Message have the same error, this error response 1433 MAY be reported in one or multiple Acknowledge Messages. In an error 1434 Acknowledge Message, the RESPONSE Record or Records being responded 1435 to appear, expanded by the time for which the server thinks the error 1436 might persist and with their Index inserted, as a RESPONSE Record or 1437 Records. 1439 Err values 1 through 126 are available for encoding Request or Update 1440 Message level errors. Err values 128 through 254 are available for 1441 encoding QUERY or RESPONSE Record level errors. The SubErr field is 1442 available for providing more detail on errors. The meaning of a 1443 SubErr field value depends on the value of the Err field. 1445 3.6.1 Error Codes 1447 The following table lists error code values for the Err filed, their 1448 meaning, and whether they apply at the Message or Record level. 1450 Err Level Meaning 1451 ------ ------- ------- 1452 0 - (no error) 1454 1 Message Unknown or reserved Query Message field value 1455 2 Message Request Message/data too short 1456 3 Message Unknown or reserved Update Message field value 1457 4 Message Update Message/data too short 1458 5-126 Message (Available for allocation by IETF Review) 1459 127 - Reserved 1461 128 Record Unknown or reserved QUERY Record field value 1462 129 Record QUERY Record truncated 1463 130 Record Address not found 1464 131 Record Unknown or reserved RESPONSE Record field value 1465 132 Record RESPONSE Record truncated 1466 133-254 Record (Available for allocation by IETF Review) 1467 255 - Reserved 1469 Note that some error codes are for overall message level errors while 1470 some are for errors in the repeating records that occur in messages. 1472 3.6.2 Sub-Errors Under Error Codes 1 and 3 1474 The following sub-errors are specified under error code 1 and 3: 1476 SubErr Field with Error 1477 ------ ---------------- 1478 0 Unspecified 1479 1 Unknown Ver field value 1480 2 Unknown Type field value 1481 3 Specified Data Label not being served 1482 4-254 (Available for allocation by Expert Review) 1483 255 Reserved 1485 3.6.3 Sub-Errors Under Error Codes 128 and 131 1487 The following sub-errors are specified under error code 128 and 131: 1489 SubErr Field with Error 1490 ------ ---------------- 1491 0 Unspecified 1492 1 Unknown AFN field value 1493 2 Unknown or Reserved QTYPE field value 1494 3 Invalid or inconsistent SIZE field value 1495 4 Invalid frame for QTYPE 2, 3, 4, or 5 1496 5-254 (Available for allocation by Expert Review) 1497 255 Reserved 1499 3.7 Additional Pull Details 1501 If a TRILL switch notices that a Pull Directory server is no longer 1502 data reachable [rfc7180bis], it MUST promptly discard all pull 1503 responses it is retaining from that server as it can no longer 1504 receive cache consistency Update Messages from the server. 1506 A secondary Pull Directory server is one that obtains its data from a 1507 primary directory server. See discussion of primary to secondary 1508 directory information transfer in Section 2.5. 1510 3.8 The No Data Flag 1512 In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], 1513 the mere presence of an Interested VLANs or Interested Labels sub- 1514 TLVs in the LSP of a TRILL switch indicates connection to end 1515 stations in the VLAN(s) or FGL(s) listed and thus a need to receive 1516 multi-destination traffic in those Data Labels. However, with Pull 1517 Directories, advertising that you are a directory server requires 1518 using these sub-TLVs to indicate the Data Label(s) you are serving. 1520 Push Directories advertise themselves inside ESADI which normally 1521 requires the ability to send and receive multi-destinaiton TRILL Data 1522 packets but can be implemented with serial unicast. 1524 If a directory server does not wish to received multi-destination 1525 TRILL Data packets for the Data Labels it lists in one of the 1526 Interested VLAN sub-TLVs, it sets the "No Data" (NOD) bit to one. 1527 This means that data on a distribution tree may be pruned so as not 1528 to reach the "No Data" TRILL switch as long as there are no TRILL 1529 switches interested in the Data Label that are beyond the "No Data" 1530 TRILL switch on the distribution tree. The NOD bit is backwards 1531 compatible as TRILL switches ignorant of it will simply not prune 1532 when they could, which is safe although it may cause increased link 1533 utilization by some sending multi-destination traffic where it is not 1534 needed. 1536 Example of a TRILL switch serving as a directory that might not want 1537 multi-destination traffic in some Data Labels would be a TRILL switch 1538 that does not offer end station service for any of the Data Labels 1539 for which it is serving as a directory and is either 1540 - a Pull Directory and/or 1541 - a Push Directory for one or more Data Labels where all of the 1542 ESADI traffic for those Data Labels will be handled by unicast 1543 ESDADI [RFC7357]. 1545 A Push Directory MUST NOT set the NOD bit for a Data Label if it 1546 needs to communicate via multi-destination ESADI PDUs in that data 1547 label since such PDUs look like TRILL Data packets to transit TRILL 1548 switches and are likely to be incorrectly pruned if NOD was set. 1550 3.9 Pull Directory Service Configuation 1552 The following per RBridge scalar configuration parameters are 1553 available for controlling Pull Directory service behavior. In 1554 addition, there is a configurable per Data Label mapping from the 1555 priority of a native frame being ingress to the priority of any Pull 1556 Directory query it causes. The default such mapping depending on the 1557 client strategy as described in Section 4. 1559 Name Default Section Note Below 1560 ------------------ ------- ------- ---------- 1562 DirQueryTimeout 100 millisec 3.2.1 1 1563 DirQueryRetries 3 3.2.1 1 1564 DirGenQPriority 5 3.2.1 1 1566 DirRespMaxPriority 6 3.2.2.1 2 1568 DirUpdateDelay 50 millisec 3.3 1569 DirUpdatePriority 5 3.3.1 1570 DirUpdateTimeout 100 millisec 3.3.3 1571 DirUpdateRetries 3 3.3.3 1573 DirAckMaxPriority 5 3.3.2 3 1575 Note 1: Pull Directory Query client timeout waiting for response, 1576 maximum number of retries, and priority for client generated requests 1577 (such as a query to refresh cached information). 1579 Note 2: Pull Directory Response Messages SHOULD NOT be sent with 1580 priority 7 as that priority SHOULD be reserved for messages critical 1581 to network connectivity. 1583 Note 3: Pull Directory Acknowledge Messages SHOULD NOT be sent with 1584 priority 7 as that priority SHOULD be reserved for messages critical 1585 to network connectivity. 1587 4. Directory Use Strategies and Push-Pull Hybrids 1589 For some edge nodes that have a great number of Data Labels enabled, 1590 managing the MAC and Data Label <-> Edge RBridge mapping for hosts 1591 under all those Data Labels can be a challenge. This is especially 1592 true for Data Center gateway nodes, which need to communicate with 1593 many, if not all, Data Labels. 1595 For those edge TRILL switch nodes, a hybrid model should be 1596 considered. That is, the Push Model is used for some Data Labels or 1597 addresses within a Data Label while the Pull Model is used for other 1598 Data Labels or addresses within a Data Label. It is the network 1599 operator's decision by configuration as to which Data Labels' mapping 1600 entries are pushed down from directories and which Data Labels' 1601 mapping entries are pulled. 1603 For example, assume a data center where hosts in specific Data 1604 Labels, say VLANs 1 through 100, communicate regularly with external 1605 peers. Probably, the mapping entries for those 100 VLANs should be 1606 pushed down to the data center gateway routers. For hosts in other 1607 Data Labels that only communicate with external peers occasionally 1608 for management interfacing, the mapping entries for those VLANs 1609 should be pulled down from directory when the need comes up. 1611 Similarly, it could be that within a Data Label that some addresses, 1612 such as the addresses of gateways, file, DNS, or database server 1613 hosts are commonly referenced by most other hosts but those other 1614 hosts, perhaps compute engines, are typically only referenced by a 1615 few hosts in that Data Label. In that case, the address information 1616 for the commonly referenced hosts could be pushed as an incomplete 1617 directory while the addresses of the others are pulled when needed. 1619 The mechanisms described above for Push and Pull Directory services 1620 make it easy to use Push for some Data Labels or addresses and Pull 1621 for others. In fact, different TRILL switches can even be configured 1622 so that some use Push Directory services and some use Pull Directory 1623 services for the same Data Label if both Push and Pull Directory 1624 services are available for that Data Label. And there can be Data 1625 Labels for which directory services are not used at all. 1627 There are a wide variety of strategies that a TRILL switch can adopt 1628 for making use of directory assistance. A few suggestions are given 1629 below. 1631 - Even if a TRILL switch will normally be operating with 1632 information from a complete Push Directory server, there will be a 1633 period of time when it first comes up before the information it 1634 holds is complete. Or, it could be that the only Push Directories 1635 that can push information to it are incomplete or that they are 1636 just starting and may not yet have pushed the entire directory. 1638 Thus, it is RECOMMENDED that all TRILL switches have a strategy 1639 for dealing with the situation where they do not have complete 1640 directory information. Examples are to send a Pull Directory query 1641 or to revert to [RFC6325] behavior. 1643 - If a TRILL switch receives a native frame X resulting in 1644 seeking directory information, a choice needs to be made as to 1645 what to do if it does not already have the directory information 1646 it needs. In particular, it could (1) immediately flood the TRILL 1647 Data packet resulting from ingressing X in parallel with seeking 1648 the directory information, (2) flood that TRILL Data packet 1649 delayed, if it fails to obtain the directory information, or (3) 1650 discard X if it fails to obtain the information. The choice might 1651 depend on the priority of frame X since the higher that priority, 1652 the more urgent the frame is and the greater the probability of 1653 harm in delaying it. If a Pull Directory request is sent, it is 1654 RECOMMENDED that its priority be derived from the priority of the 1655 frame X with the derived priority configurable and having the 1656 following defaults: 1658 Ingressed If Flooded If Flooded 1659 Priority Immediately After Delay 1660 -------- ----------- ----------- 1661 7 5 6 1662 6 5 6 1663 5 4 5 1664 4 3 4 1665 3 2 3 1666 2 0 2 1667 0 1 0 1668 1 1 1 1670 NOTE: The odd looking numbers towards the bottom of the columns 1671 above are because priority 1 is lower than priority zero. That is 1672 to say, the values in the first column are in priority order. They 1673 will look more logical if you think of "0" as being "1 1/2". 1675 Priority 7 is normally only used for urgent messages critical to 1676 adjacency and so SHOULD NOT be the default for directory traffic. 1677 Unsolicited updates are sent with a priority that is configured per 1678 Data Label that defaults to priority 5. 1680 5. Security Considerations 1682 Incorrect directory information can result in a variety of security 1683 threats including the following: 1685 Incorrect directory mappings can result in data being delivered to 1686 the wrong end stations, or set of end stations in the case of 1687 multi-destination packets, violating security policy. 1689 Missing or incorrect directory data can result in denial of 1690 service due to sending data packets to black holes or discarding 1691 data on ingress due to incorrect information that their 1692 destinations are not reachable or that their source addresses are 1693 forged. 1695 Push Directory data is distributed through ESADI-LSPs [RFC7357] that 1696 can be authenticated with the same mechanisms as IS-IS LSPs. See 1697 [RFC5304] [RFC5310] and the Security Considerations section of 1698 [RFC7357]. 1700 Pull Directory queries and responses are transmitted as RBridge-to- 1701 RBridge or native RBridge Channel messages [RFC7178]. Such messages 1702 can be secured as specified in [ChannelTunnel]. 1704 For general TRILL security considerations, see [RFC6325]. 1706 6. IANA Considerations 1708 This section gives IANA assignment and registry considerations. 1710 6.1 ESADI-Parameter Data Extensions 1712 Action 1: IANA will assign a two bit field [bits 1-2 suggested] 1713 within the ESADI-Parameter TRILL APPsub-TLV flags for "Push Directory 1714 Server Status" (PDSS) and will create a sub-registry in the TRILL 1715 Parameters Registry as follows: 1717 Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits 1719 Registration Procedures: Standards Action 1721 References: [RFC7357] [This document] 1723 Bit Mnemonic Description Reference 1724 --- -------- ----------- --------- 1725 0 UN Supports Unicast ESADI ESDADI [RFC7357] 1726 1-2 PDSS Push Directory Server Status [this document] 1727 3-7 - Available for assignment 1729 Action 2: In addition, the ESADI-Parameter APPsub-TLV is optionally 1730 extended, as provided in its original specification in ESADI 1731 [RFC7357], by one byte as show below. Therefore [this document] 1732 should be added as a second reference to the ESDAI-Parameter APPsub- 1733 TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application 1734 Identifier 1" Registry. 1736 +-+-+-+-+-+-+-+-+ 1737 | Type | (1 byte) 1738 +-+-+-+-+-+-+-+-+ 1739 | Length | (1 byte) 1740 +-+-+-+-+-+-+-+-+ 1741 |R| Priority | (1 byte) 1742 +-+-+-+-+-+-+-+-+ 1743 | CSNP Time | (1 byte) 1744 +-+-+-+-+-+-+-+-+ 1745 | Flags | (1 byte) 1746 +---------------+ 1747 |PushDirPriority| (optional, 1 byte) 1748 +---------------+ 1749 | Reserved for expansion (variable) 1750 +-+-+-+-... 1752 The meanings of all the fields are as specified in ESDADI [RFC7357] 1753 except that the added PushDirPriority is the priority of the 1754 advertising ESADI instance to be a Push Directory as described in 1755 Section 2.3. If the PushDirPriority field is not present (Length = 3) 1756 it is treated as if it were 0x40. 0x40 is also the value used and 1757 placed here by an TRILL switch whose priority to be a Push Directory 1758 has not been configured. 1760 6.2 RBridge Channel Protocol Number 1762 Action 3: IANA will allocate a new RBridge Channel protocol number 1763 for "Pull Directory Services" from the range allocable by Standards 1764 Action and update the subregistry of such protocol number in the 1765 TRILL Parameters Registry referencing this document. 1767 6.3 The Pull Directory (PUL) and No Data (NOD) Bits 1769 Action 4: IANA is requested to assign a currently reserved bit in the 1770 Interested VLANs field of the Interested VLANs sub-TLV [suggested bit 1771 18] and the Interested Labels field of the Interested Labels sub-TLV 1772 [suggested bits 6] [RFC7176] to indicate Pull Directory server (PUL). 1773 This bit is to be added, with this document as reference, to the 1774 "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" 1775 subregistries created by [RFC7357]. 1777 Action 5: IANA is requested to assign a currently reserved bit in the 1778 Interested VLANs field of the Interested VLANs sub-TLV [suggested 1779 bits 19] and the Interested Labels field of the Interested Labels 1780 sub-TLV [suggested bits 7] [RFC7176] to indicate No Data (NOD, see 1781 Section 3.8). This bit is to be added, with this document as 1782 reference, to the "Interested VLANs Flag Bits" and "Interested Labels 1783 Flag Bits" subregistries created by [RFC7357]. 1785 6.4 TRILL Pull Directory QTYPEs 1787 Action 6: IANA is requested to create a new Registry on the 1788 "Transparent Interconnection of Lots of Links (TRILL) Parameters" web 1789 page as follows: 1791 Name: TRILL Pull Directory QTYPEs" 1792 Registration Procedure: IETF Review 1793 Reference: [this document] 1794 Initial contents as in Section 3.2.1. 1796 6.5 Pull Directory Error Code Registries 1798 Actions 7, 8, and 9: IANA is requested to create a new Registry and 1799 two new SubRegistries on the "Transparent Interconnection of Lots of 1800 Links (TRILL) Parameters" web page as follows: 1802 Registry 1803 Name: TRILL Pull Directory Errors 1804 Registration Procedure: IETF Review 1805 Reference: [this document] 1807 Initial contents as in Section 3.6.1. 1809 Sub-Registry 1810 Name: Sub-codes for TRILL Pull Directory Errors 1 and 3 1811 Registration Procedure: Expert Review 1812 Reference: [this document] 1814 Initial contents as in Section 3.6.2. 1816 Sub-Registry 1817 Name: Sub-codes for TRILL Pull Directory Errors 128 and 131 1818 Registration Procedure: Expert Review 1819 Reference: [this document] 1821 Initial contents as in Section 3.6.3. 1823 Normative References 1825 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 1826 RFC 826, November 1982. 1828 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 1829 Reverse Address Resolution Protocol", STD 38, RFC 903, June 1830 1984 1832 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1833 Requirement Levels", BCP 14, RFC 2119, March 1997 1835 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1836 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1838 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1839 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1840 September 2007. 1842 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1843 Authentication", RFC 5304, October 2008. 1845 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1846 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1847 5310, February 2009. 1849 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1850 Layer-2 Systems", RFC 6165, April 2011. 1852 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1853 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1854 Specification", RFC 6325, July 2011. 1856 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1857 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1858 BCP 141, RFC 7042, October 2013. 1860 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1861 and D. Dutt, "Transparent Interconnection of Lots of Links 1862 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 1863 . 1865 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1866 D., and A. Banerjee, "Transparent Interconnection of Lots of 1867 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 1868 . 1870 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1871 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1872 RBridge Channel Support", RFC 7178, May 2014, . 1875 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1876 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 1877 End Station Address Distribution Information (ESADI) Protocol", 1878 RFC 7357, September 2014, . 1881 [rfc7180bis] - D. Eastlake 3rd, M. Zhang, A. Banerjee, A. Ghanwani, 1882 and S. Gupta "Transparent Interconnection of Lots of Links 1883 (TRILL): Clarifications, Corrections, and Updates", RFC 7180, 1884 May 2014, . 1886 [IA] - Eastlake, D., L. Yizhou, R. Perlman, "TRILL: Interface 1887 Addresses APPsub-TLV", draft-ietf-trill-ia-appsubtlv, work in 1888 progress. 1890 Informational References 1892 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 1893 Gashinsky, "Directory Assistance Problem and High-Level Design 1894 Proposal", RFC 7067, November 2013. 1896 [ChannelTunnel] - D. Eastlake, M. Umair, Y. Li, "TRILL: RBridge 1897 Channel Tunnel Protocol", draft-ietf-trill-channel-tunnel, work 1898 in progress. 1900 [ARPreduction] - Y. Li, D. Eastlake, L. Dunbar, R. Perlman, I. 1901 Gashinsky, "TRILL: ARP/ND Optimization", draft-ietf-trill-arp- 1902 optimization, work in progress. 1904 [X.233] - ITU-T Recommendation X.233: Protocol for providing the 1905 connectionless-mode network service: Protocol specification, 1906 International Telecommunications Union, August 1997 1908 Acknowledgments 1910 The contributions of the following persons are gratefully 1911 acknowledged: 1913 Susan Hares, Gsyle Noble 1915 The document was prepared in raw nroff. All macros used were defined 1916 within the source file. 1918 Authors' Addresses 1920 Donald Eastlake 1921 Huawei Technologies 1922 155 Beaver Street 1923 Milford, MA 01757 USA 1925 Phone: +1-508-333-2270 1926 Email: d3e3e3@gmail.com 1928 Linda Dunbar 1929 Huawei Technologies 1930 5430 Legacy Drive, Suite #175 1931 Plano, TX 75024, USA 1933 Phone: +1-469-277-5840 1934 Email: ldunbar@huawei.com 1936 Radia Perlman 1937 EMC 1938 2010 256th Avenue NE, #200 1939 Bellevue, WA 98007 USA 1941 Email: Radia@alum.mit.edu 1943 Igor Gashinsky 1944 Yahoo 1945 45 West 18th Street 6th floor 1946 New York, NY 10011 1948 Email: igor@yahoo-inc.com 1950 Yizhou Li 1951 Huawei Technologies 1952 101 Software Avenue, 1953 Nanjing 210012 China 1955 Phone: +86-25-56622310 1956 Email: liyizhou@huawei.com 1958 Copyright, Disclaimer, and Additional IPR Provisions 1960 Copyright (c) 2016 IETF Trust and the persons identified as the 1961 document authors. All rights reserved. 1963 This document is subject to BCP 78 and the IETF Trust's Legal 1964 Provisions Relating to IETF Documents 1965 (http://trustee.ietf.org/license-info) in effect on the date of 1966 publication of this document. Please review these documents 1967 carefully, as they describe your rights and restrictions with respect 1968 to this document. Code Components extracted from this document must 1969 include Simplified BSD License text as described in Section 4.e of 1970 the Trust Legal Provisions and are provided without warranty as 1971 described in the Simplified BSD License. The definitive version of 1972 an IETF Document is that published by, or under the auspices of, the 1973 IETF. Versions of IETF Documents that are published by third parties, 1974 including those that are translated into other languages, should not 1975 be considered to be definitive versions of IETF Documents. The 1976 definitive version of these Legal Provisions is that published by, or 1977 under the auspices of, the IETF. Versions of these Legal Provisions 1978 that are published by third parties, including those that are 1979 translated into other languages, should not be considered to be 1980 definitive versions of these Legal Provisions. For the avoidance of 1981 doubt, each Contributor to the IETF Standards Process licenses each 1982 Contribution that he or she makes as part of the IETF Standards 1983 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1984 language to the contrary, or terms, conditions or rights that differ 1985 from or are inconsistent with the rights and licenses granted under 1986 RFC 5378, shall have any effect and shall be null and void, whether 1987 published or posted by such Contributor, or included with or in such 1988 Contribution.