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