idnits 2.17.1 draft-dunbar-trill-scheme-for-directory-assist-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3832 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 5342 (Obsoleted by RFC 7042) 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 Linda Dunbar 2 Intended status: Proposed Standard Donald Eastlake 3 Updates: ESADI Huawei 4 Radia Perlman 5 Intel 6 Igor Gashinsky 7 Yahoo 8 Yizhou Li 9 Huawei 10 Expires: April 20, 2014 October 21, 2013 12 TRILL: Edge Directory Assistance Mechanisms 13 15 Abstract 16 This document describes mechanisms for using directory server(s) to 17 assist TRILL (Transparent Interconnection of Lots of Links) edge 18 switches in reducing multi-destination traffic, particularly ARP/ND 19 and unknown unicast flooding. 21 Status of This Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Distribution of this document is unlimited. Comments should be sent 27 to the TRILL working group mailing list. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 41 Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Table of Contents 46 1. Introduction............................................3 47 1.1 Terminology............................................3 49 2. Push Model Directory Assistance Mechanisms..............5 50 2.1 Requesting Push Service................................5 51 2.2 Push Directory Servers.................................5 52 2.3 Push Directory Server State Machine....................6 53 2.3.1 Push Directory States................................6 54 2.3.2 Push Directory Events and Conditions.................7 55 2.3.3 State Transition Diagram and Table...................8 56 2.4 Additional Push Details...............................10 57 2.5 Primary to Secondary Server Push Service..............11 59 3. Pull Model Directory Assistance Mechanisms.............12 60 3.1 Pull Directory Request Format.........................12 61 3.2 Pull Directory Response Format........................15 62 3.3 Pull Directory Hosted on an End Station...............18 63 3.4 Pull Directory Request Errors.........................19 64 3.5 Cache Consistency.....................................20 65 3.6 Additional Pull Details...............................22 67 4. Events That May Cause Directory Use....................23 68 4.1 Forged Native Frame Ingress...........................23 69 4.2 Unknown Destination MAC...............................23 70 4.3 Address Resolution Protocol (ARP).....................24 71 4.4 IPv6 Neighbor Discovery (ND)..........................25 72 4.5 Reverse Address Resolution Protocol (RARP)............25 74 5. Layer 3 Address Learning...............................26 76 6. Directory Use Strategies and Push-Pull Hybrids.........27 77 6.1 Strategy Configuration................................27 79 7. Security Considerations................................30 81 8. IANA Considerations....................................31 82 8.1 ESADI-Parameter Data..................................31 83 8.2 RBridge Channel Protocol Number.......................32 84 8.3 The Pull Directory and No Data Bits...................32 86 Acknowledgments...........................................33 87 Normative References......................................33 88 Informational References..................................34 89 Authors' Addresses........................................35 91 1. Introduction 93 [DirectoryFramework] describes a high-level framework for using 94 directory servers to assist TRILL [RFC6325] edge nodes to reduce 95 multi-destination ARP/ND and unknown unicast flooding traffic and to 96 potentially improve security against address spoofing within a TRILL 97 campus. Because multi-destination traffic becomes an increasing 98 burden as a network scales, reducing ARP/ND and unknown unicast 99 flooding improves TRILL network scalability. This document describes 100 specific mechanisms for directory servers to assist TRILL edge nodes. 101 These mechanisms are optional to implement. 103 The information held by the Directory(s) is address mapping and 104 reachability information. Most commonly, what MAC address 105 [RFC5342bis] corresponds to an IP address within a Data Label (VLAN 106 or FGL (Fine Grained Label [RFCfgl])) and from what egress TRILL 107 switch (RBridge) (and optionally what specific TRILL switch port) 108 that MAC address is reachable. But it could be what IP address 109 corresponds to a MAC address or possibly other address mappings or 110 reachability. In the data center environment, it is common for 111 orchestration software to know and control where all the IP 112 addresses, MAC addresses, and VLANs/tenants are in a data center. 113 Thus such orchestration software is appropriate for providing the 114 directory function or for supplying the Directory(s) with directory 115 information. 117 Directory services can be offered in a Push or Pull mode. Push mode, 118 in which a directory server pushes information to TRILL switches 119 indicating interest, is specified in Section 2. Pull mode, in which a 120 TRILL switch queries a server for the information it wants, is 121 specified in Section 3. Modes of operation, including hybrid 122 Push/Pull, are discussed in Section 4. 124 The mechanisms used to initially populate directory data in primary 125 servers is beyond the scope of this document. The Push Directory 126 service can be used by a primary server to provide Directory data to 127 secondary servers as described in Section 2. 129 1.1 Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC-2119 [RFC2119]. 135 The terminology and acronyms of [RFC6325] are used herein along with 136 the following additions: 138 CP: Complete Push flag bit. See Sections 2 and 6.1 below. 140 CSNP Time: Complete Sequence Number PDU Time. See [ESADI] and Section 141 6.1 below. 143 Data Label: VLAN or FGL. 145 FGL: Fine Grained Label [RFCfgl]. 147 Host: Application running on a physical server or a virtual machine. 148 A host must have a MAC address and usually has at least one IP 149 address. 151 IP: Internet Protocol. In this document, IP includes both IPv4 and 152 IPv6. 154 PD: Push Directory flag bit. See Sections 2 and 6.1 below. 156 primary server: A Directory server that obtains the information it is 157 serving up by a reliable mechanism outside the scope of this 158 document but designed to assure the freshness of that 159 information. (See secondary server.) 161 RBridge: An alternative name for a TRILL switch. 163 secondary server: A Directory server that obtains the information it 164 is serving up from one or more primary servers. 166 tenant: Sometimes used as a synonym for FGL. 168 TRILL switch: A device that implements the TRILL protocol. 170 2. Push Model Directory Assistance Mechanisms 172 In the Push Model [DirectoryFramework], one or more Push Directory 173 servers push down the address mapping information for the various 174 addresses associated with end station interface and the TRILL 175 switches from which those interfaces are reachable [IA]. This service 176 is scoped by Data Label (VLAN or FGL [RFCfgl]). A Push Directory 177 also advertises whether or not it believes it has pushed complete 178 mapping information for a Data Label. It might be pushing mapping 179 information for only a subset of the ports in a Data Label. The Push 180 Model uses the [ESADI] protocol as its distribution mechanism. 182 With the Push Model, if complete address mapping information for a 183 Data Label being pushed is available, a TRILL switch (RBridge) which 184 has that complete pushed information can simply drop a native frame 185 if the destination unicast MAC address can't be found in the mapping 186 information available, instead of flooding it (see Section 2.1). This 187 will minimize flooding of packets due to errors or inconsistencies 188 but is not practical if directories have incomplete information. 190 2.1 Requesting Push Service 192 In the Push Model, it is necessary to have a way for an RBridge to 193 request information from the directory server(s). RBridges simply 194 use the ESADI protocol mechanism to announce, in their core IS-IS 195 LSPs, the Data Labels for which they are participating in [ESADI] by 196 using the Interested VLANs and/or Interested Labels sub-TLVs 197 [RFC6326bis]. This will cause them to be pushed the Directory 198 information for all such Data Labels that are being served by one or 199 more Push Directory servers. 201 2.2 Push Directory Servers 203 Push Directory servers advertise their availability to push the 204 mapping information for a particular Data Label to each other and to 205 ESADI participants for that Data Label by turning on a flag bit in 206 their ESADI Parameter APPsub-TLV [ESADI] for that ESADI instance (see 207 Section 8.1). Each Push Directory server MUST participate in ESADI 208 for the Data Labels for which it will push mappings and set the PD 209 (Push Directory) bit in their ESADI-Parameters APPsub-TLV for that 210 Data Label. 212 For robustness, it is useful to have more than one copy of the data 213 being pushed. Each RBridge that is a Push Directory server is 214 configured with a number in the range 1 to 8, which defaults to 2, 215 for each Data Label for which it can push directory information. If 216 the Push Directories for a Data Label are configured the same in this 217 regard and enough such servers are available, this is the number of 218 copies of the directory that will be pushed. 220 Each Push Directory server also has an 8-bit priority to be Active 221 (see Section 8.1 of this document). This priority is treated as an 222 unsigned integer where larger magnitude means higher priority and is 223 in its ESADI Parameter APPsub-TLV. In cases of equal priority, the 224 6-byte IS-IS System ID is used as a tie breaker and treated as an 225 unsigned integer where larger magnitude means higher priority. 227 For each Data Label it can serve, each Push Directory server orders, 228 by priority, the Push Directory servers that it can see in the ESADI 229 link state database for that Data Label that are data reachable 230 [RFCclear] and determines its position in that order. If a Push 231 Directory server is configured to believe that N copies of the 232 mappings for a Data Label should be pushed and finds that it is 233 number K in the priority ordering (where number 1 is highest priority 234 and number K is lowest), then if K is less than or equal to N the 235 Push Directory server is Active. If K is greater than N it is 236 Passive. Active and Passive behavior are specified below. 238 2.3 Push Directory Server State Machine 240 The subsections below describe the states, events, and corresponding 241 actions for Push Directory servers. 243 2.3.1 Push Directory States 245 A Push Directory Server is in one of six states, as listed below, for 246 each Data Label it can serve. In addition, it has an internal State- 247 Transition-Time variable for each such Data Label which it set at 248 each state transition and which enables it to determine how long it 249 has been in its current state. 251 Down: A completely shut down virtual state defined for convenience in 252 specifying state diagrams. A Push Directory Server in this state 253 does not advertise any Push Directory data. It may be 254 participating in [ESADI] with the PD bit zero in its ESADI- 255 Parameters or might be not participating in [ESADI] at all. (All 256 states other than the Down state are considered to be Up states.) 258 Passive: No Push Directory data is advertised. Any outstanding EASDI- 259 LSP fragments containing directory data are updated to remove that 260 data and if the result is an empty fragment (contains nothing 261 except possibly an Authentication TLV), the fragment is purged. 263 The Push Directory participates in [ESADI] and its [ESADI] 264 fragment zero includes an ESADI-Parameters APPsub-TLV with the PD 265 bit set to one and CP (Complete Push) bit zero. 267 Active: If a Push Directory server is Active, it advertises its 268 directory data through [ESADI] in its ESADI-LSPs using the 269 Interface Addresses [IA] APPsub-TLV and updates that information 270 as it changes. The PD bit is set to one in the ESADI-Parameters 271 and the CP bit must be zero. 273 Completing: Same behavior as the Active state but responds 274 differently to events. 276 Complete: The same behavior as Completing except that the CP bit in 277 the ESADI-Parameters APPsub-TLV is set to one and the server 278 responds differently to events. 280 Reducing: The same behavior as Complete but responds differently to 281 events. The PD bit remains a one but the CP bit is cleared to zero 282 in the ESADI-Parameters APPsub-TLV. Directory updates continue to 283 be advertised. 285 2.3.2 Push Directory Events and Conditions 287 Three auxiliary conditions referenced later in this section are 288 defined as follows for convenience: 290 The Activate Condition: The server determines that there are K data 291 reachable Push Directory servers, the server is configured that 292 there should be N copies pushed, and K is less than or equal to N. 294 The Pacify Condition: The server determines that there are K data 295 reachable Push Directory servers, the server is configured that 296 there should be N copies pushed, and K is greater than N. 298 The Time Condition: The server has been in its current state for an 299 amount of time equal to or larger than its CSNP time (see Section 300 8.1).) 302 The events and conditions listed below cause state transitions in 303 Push Directory servers. 305 1. Push Directory server or TRILL switch was configured to be down 306 but the TRILL switch on which it resides is up and the server is 307 configured to be up. 309 2. The Push Directory server or the TRILL switch on which it is 310 resident is being shut down. 312 3. The Activate Condition is met and the server is not configured to 313 believe it has complete data. 315 4. The server determines that the Pacify Condition is met. 317 5. The server is configured to believe it has complete data and the 318 Activate Condition is met. 320 6. The server is configured to believe it does not have complete 321 data. 323 7. The Time Condition is met. 325 2.3.3 State Transition Diagram and Table 327 The state transition diagram is as follows. 329 +-----------+ 330 | Down |<---------+ 331 +-----------+ | 332 |1 ^ | 3,4,5,6,7 | 333 | | +------------+ 334 V |2 335 +-----------+ 336 | Passive |<----------------------- 337 +-----------+ ^ ^ ^ 338 |5 |3 |1,4,6,7 | | | 339 | | +---------+ | | 340 | V |2,4 | 341 | +---------------------+ | 342 | | Active |<--+ | 343 | +---------------------+ | | 344 | |5 ^ |1,3,6,7 ^ | | 345 | | | | | | | 346 | | | +---------+ | | 347 | | | | | 348 V V |3,6 | | 349 +--------------+ | | 350 | Completing |-------------------+ 351 +--------------+ 2,4 | 352 |7 |1,5 ^ | 353 | | | | 354 | +-----+ | 355 V |7 356 +-------------+ +----------------+ 357 | Complete |--------->| Reducing |<--+ 358 +-------------+ 2,3,4,6 +----------------+ | 359 |1,5,7 ^ ^ |5 |1,2,3,4,6 | 360 | | | | | | 361 +------+ +--------------+ +--------------+ 363 Figure 1. Push Server State Diagram 365 This state diagram is equivalent to the following transition table: 367 Event || Down |Passive |Active |Completing|Complete|Reducing| 368 ------++-------+----------+--------+----------+--------+--------+ 369 1 ||Passive|Passive |Active |Completing|Complete|Reducing| 370 2 || Down | Down |Passive |Passive |Reducing|Reducing| 371 3 || Down |Active |Active |Active |Reducing|Reducing| 372 4 || Down |Passive |Passive |Passive |Reducing|Reducing| 373 5 || Down |Completing|Complete|Completing|Complete|Complete| 374 6 || Down |Passive |Active |Active |Reducing|Reducing| 375 7 || Down |Passive |Active |Complete |Complete|Active | 377 2.4 Additional Push Details 379 Push Directory mappings can be distinguished for any other data 380 distributed through ESADI because mappings are distributed only with 381 the Interface Addresses APPsub-TLV [IA] and are flagged as being Push 382 Directory data. 384 RBridges, whether or not they are a Push Directory server, MAY 385 continue to advertise any locally learned MAC attachment information 386 in [ESADI] using the Reachable MAC Addresses TLV [RFC6165] . However, 387 if a Data Label is being served by complete Push Directory servers, 388 advertising such locally learned MAC attachment should generally not 389 be done as it would not add anything and would just waste bandwidth 390 and ESADI link state space. An exception would be when an RBridge 391 learns local MAC connectivity and that information appears to be 392 missing from the directory mapping. 394 Because a Push Directory server may need to advertise interest in 395 Data Labels even if it does not want to receive end station data in 396 those Data Labels, the No Data flag bit is provided as discussed in 397 Section 6.3. 399 If an RBridge notices that a Push Directory server is no longer data 400 reachable [RFCclear], it MUST ignore any Push Directory data from 401 that server because it is no longer being updated and may be stale. 403 The nature of dynamic distributed asynchronous systems is such that 404 it is impractical for an RBridge receiving Push Directory information 405 to ever be absolutely certain that it has complete information. 406 However, it can obtain a reasonable assurance of complete information 407 by requiring two conditions to be met: 408 1. The PD and CP bits are on in the ESADI zero fragment from the 409 server for the relevant Data Label. 410 2. A client RBridge might be just coming up and receive an EASDI 411 LSP meeting the requirement in point 1 above but have not yet 412 received all of the ESADI LSP fragment from the Push Directory 413 server. Thus, it should not believe that information to be 414 complete unless it has also had data connectivity to the server 415 for the larger of the client's and the server's CSNP times. 417 There may be transient conflicts between mapping information from 418 different Push Directory servers or conflicts between locally learned 419 information and information received from a Push Directory server. In 420 case of such conflicts, information with a higher confidence value is 421 preferred over information with a lower confidence. In case of equal 422 confidence, Push Directory information is preferred to locally 423 learned information and if information from Push Directory servers 424 conflicts, the information from the higher priority Push Directory 425 server is preferred. 427 2.5 Primary to Secondary Server Push Service 429 A secondary Push or Pull Directory server is one that obtains its 430 data from a primary directory server. Other techniques MAY be used 431 but, by default, this data transfer occurs through the primary server 432 acting as a Push Directory server for the Data Labels involved while 433 the secondary Push Directory server takes the pushed data it receives 434 from the highest priority Push Directory server and re-originates it. 436 3. Pull Model Directory Assistance Mechanisms 438 In the Pull Model, a TRILL switch (RBridge) pulls directory 439 information from an appropriate Directory Server when needed. 441 Pull Directory servers for a particular Data Label X are located by 442 looking in the core TRILL IS-IS link state database for RBridges that 443 advertise themselves by having the Pull Directory flag on in their 444 Interested VLANs or Interested Labels sub-TLV [RFC6326bis] for X. If 445 multiple RBridges indicate that they are Pull Directory Servers for a 446 particular Data Label, pull requests can be sent to any one or more 447 of them that are data reachable but it is RECOMMENDED that pull 448 requests be preferentially sent to the server or servers that are 449 lower cost from the requesting RBridge. 451 Pull Directory requests are sent by enclosing them in an RBridge 452 Channel [Channel] message using the Pull Directory channel protocol 453 number (see Section 8.2). Responses are returned in an RBridge 454 Channel message using the same channel protocol number. 456 The requests to Pull Directory Servers are typically derived from 457 normal ARP [RFC826], ND [RFC4861], RARP [RFC903] messages or data 458 frames with unknown unicast destination MAC addresses intercepted by 459 the RBridge as described in Section 4. 461 Pull Directory responses include an amount of time for which the 462 response should be considered valid. This includes negative responses 463 that indicate no data is available. Thus both positive responses with 464 data and negative responses can be cached and used for immediate 465 response to ARP, ND, RARP, or unknown destination MAC frames, until 466 they expire. If information previously pulled is about to expire, an 467 RBridge MAY try to refresh it by issued a new pull request but, to 468 avoid unnecessary requests, SHOULD NOT do so if it has not been 469 recently used. 471 3.1 Pull Directory Request Format 473 A Pull Directory request is sent as the Channel Protocol specific 474 content of an inter-RBridge Channel message [Channel] TRILL Data 475 packet. The Data Label in the packet is the Data Label in which the 476 query is being made. The priority of the channel message is a mapping 477 of the priority of the frame being ingressed that caused the request 478 with the default mapping depending, per Data Label, on the strategy 479 (see Section 6). The Channel Protocol specific data is formatted as 480 follows: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | V | T | RESV | Count | RESV | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Sequence Number | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | QUERY 1 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 491 | QUERY 2 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 493 | ... 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 495 | QUERY K 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 498 V: Version of the Pull Directory protocol as an unsigned integer. 499 Version zero is specified in this document. 501 T: Type. 0 => Response, 1=> Query, 2=> Unsolicited Update, 3=> 502 Reserved. An unsolicited update is formatted as a response 503 except there is no corresponding query. Messages received with 504 type = 3 are discarded. Queries received by an RBridge that is 505 not a Pull Directory are discarded. Responses that do not match 506 an outstanding Query are discarded. 508 RESV: Reserved bits. MUST be sent as zero and ignored on receipt. 510 Count: Number of queries present. 512 Sequence Number: A 32-bit quantity set by the sending RBridge, 513 returned in any responses, and used to match up responses with 514 queries. It is opaque except that the value zero is reserved 515 for Unsolicited Update response messages. A Request received 516 with Sequence Number zero is discarded. 518 QUERY: Each Query record within a Pull Directory request message 519 is formatted as follows: 521 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 522 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 523 | SIZE | RESV | TYPE | 524 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 525 If TYPE = 1 526 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 527 | AFN | 528 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 529 | Query address ... 530 +--+--+--+--+--+--+--+--+--+--+--... 531 If TYPE = 2, 3, 4, or 5 532 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 533 | Query frame ... 534 +--+--+--+--+--+--+--+--+--+--+--... 536 SIZE: Size of the query data in bytes as an unsigned byte 537 starting with and including the SIZE field itself. Thus the 538 minimum legal value is 2. A value of SIZE less than 2 539 indicates a malformed message. The "QUERY" with the illegal 540 SIZE value and all subsequent QUERYs MUST be ignored and the 541 entire query message MAY be ignored. 543 RESV: A block of reserved bits. MUST be sent as zero and 544 ignored on receipt. 546 TYPE: There are two types of queries currently defined, (1) a 547 query that provides an explicit address and asks for other 548 addresses for the interface specified by the query address 549 and (2) a query that includes a frame. The fields of each 550 are specified below. Values of TYPE are as follows 552 TYPE Description 553 ---- ----------- 554 0 reserved 555 1 query address 556 2 ARP query frame 557 3 ND query frame 558 4 RARP query frame 559 5 Unknown unicast MAC query frame 560 6-14 assignable by IETF Review 561 15 reserved 563 AFN: Address Family Number of the query address. 565 Query Address: The query is asking for any other addresses, 566 and the RBridge from which they are reachable, that 567 correspond to the same interface, within the data label 568 of the query. Typically that would be either (1) a MAC 569 address with the querying RBridge primarily interested in 570 the RBridge by which that MAC address is reachable, or 571 (2) an IP address with the querying RBridge interested in 572 the corresponding MAC address and the RBridge by which 573 that MAC address is reachable. But it could be some other 574 address type. 576 Query Frame: Where a Pull Directory query is the result of 577 an ARP, ND, RARP, or unknown unicast MAC destination 578 address, the ingress RBridge MAY send the frame to a Pull 579 Directory Server if the frame is small enough to fit into 580 a query message. 582 A query count of zero is explicitly allowed, for the purpose of 583 pinging a Pull Directory server to see if it is responding to 584 requests. On receipt of such an empty query message, a response 585 message that also has a count of zero MUST be sent unless inhibited 586 by rate limiting. 588 If no response is received to a Pull Directory request within a 589 timeout configurable in milliseconds that defaults to 2,000, the 590 request should be re-transmitted with the same Sequence Number up to 591 a configurable number of times that defaults to three. If there are 592 multiple queries in a request, responses can be received to various 593 subsets of these queries by the timeout. In that case, the remaining 594 unanswered queries should be re-sent in a new query with a new 595 sequence number. If an RBridge is not capable of handling partial 596 responses to requests with multiple queries, it MUST NOT sent a 597 request with more than one query in it. 599 3.2 Pull Directory Response Format 601 Pull Directory responses are sent as the Channel Protocol specific 602 content of inter-RBridge Channel message TRILL Data packets. 603 Responses are sent with the same Data Label and priority as the 604 request to which they correspond except that the response priority is 605 limited to be not more than a configured value. This priority limit 606 is configurable at a per RBridge level and defaults to priority 6. 607 The Channel protocol specific data format is as follows: 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | V | T |F|P|N| RESV| Count | ERR | subERR | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Sequence Number | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | RESPONSE 1 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 618 | RESPONSE 2 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 620 | ... 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 622 | RESPONSE K 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 625 V, T: Version and Type as specified in Section 3.1. 627 F: The Flood bit. If zero, the reply is to be unicast to the 628 provided Nickname. If T=2, F=1 is used to flood messages for 629 certain unsolicited update cache consistency maintenance 630 messages from an end station Pull Directory server as discussed 631 in Section 3.5. If T is not 2, F is ignored. 633 P, N: Flags used in connection with certain flooded unsolicited 634 cache consistency maintenance messages. Ignored if T is not 2. 635 If the P bit is a one, the solicited response message relates 636 to cached positive response information. If the N bit is a one, 637 the unsolicited message relates to cached negative information. 638 See Section 3.5. 640 RESV: Reserved bits. MUST be sent as zero and ignored on receipt. 642 Count: Count is the number of responses present in the particular 643 response message. 645 ERR, subERR: A two part error code. See Section 3.4. 647 Sequence Number: A 32-bit quantity set by the sending RBridge, 648 returned in any responses, and used to match up responses with 649 queries. It is opaque except that the value zero is reserved 650 for Unsolicited Update response messages. 652 RESPONSE: Each response record within a Pull Directory response 653 message is formatted as follows: 655 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 656 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 657 | SIZE | RESV | Index | 658 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 659 | Lifetime | 660 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 661 | Response Data ... 662 +--+--+--+--+--+--+--+--+--+--+--... 664 SIZE: Size of the response data in bytes starting with and 665 including the SIZE field itself. Thus the minimum value of 666 SIZE is 6. If SIZE is less than 6, that RESPONSE and all 667 subsequent RESPONSEs MUST be ignored. 669 RESV: Four reserved bits that MUST be sent as zero and ignored 670 on receipt. 672 Index: The relative index of the query in the request message 673 to which this response corresponds. The index will always be 674 one for request messages containing a single query. The 675 index will always be zero for unsolicited update "response" 676 messages. 678 Lifetime: The length of time for which the response should be 679 considered valid in seconds. If zero, the response can only 680 be used for the particular query from which it resulted. The 681 maximum time that can be expressed is just over 18.2 hours. 682 [Perhaps this should be in units of, say, 200 milliseconds?] 684 Response Data: There are two types of response data. 685 If the ERR field is non-zero, the response data is a copy of 686 the query data, that is, either an AFN followed by an 687 address or a query frame. 688 If the ERR field is zero, the response data is the contents 689 of an Interface Addresses APPsub-TLV (see Section 5) 690 without the usual TRILL GENINFO TLV type and length and 691 without the usual IA APPsub-TLV type and length before 692 it. The maximum size of such contents is 251 bytes in the 693 case when SIZE is 255. 695 Multiple response records can appear in a response message with the 696 same index if the answer to a query consists of multiple Interface 697 Address APPsub-TLV contents. This would be necessary if, for example, 698 a MAC address within a Data Label appears to be reachable by multiple 699 RBridges. However, all RESPONSE records to any particular QUERY 700 record MUST occur in the same response message. If a Pull Directory 701 holds more mappings for a queried address than will fit into one 702 response message, it selects which to include by some method outside 703 the scope of this document. 705 See Section 3.4 for a discussion of how errors are handled. 707 3.3 Pull Directory Hosted on an End Station 709 Optionally, a Pull Directory actually hosted on an end station MAY be 710 supported. In that case, when the RBridge advertising itself as a 711 Pull Directory server receives a query, it modifies the inter-RBridge 712 Channel message received into a native RBridge Channel message and 713 forwards it to that end station. Later, when it receives one or more 714 responses from that end station by native RBridge Channel messages, 715 it modifies them into inter-RBridge Channel messages and forwards 716 them to the source RBridge of the query. 718 The native Pull Directory RBridge Channel messages use the same 719 Channel protocol number as do the inter-RBridge Pull Directory 720 RBridge Channel messages. The native messages MUST be sent with an 721 Outer.VLAN tag which gives the priority of each message which is the 722 priority of the original inter-RBridge request packet. The Outer.VLAN 723 ID used is the Designated VLAN on the link. 725 The native RBridge Channel message protocol dependent data for a Pull 726 Directory query is formatted as follows: 728 0 1 2 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 | V | T | RESV | Count | Nickname | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Data Label ... (4 or 8 bytes) 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Sequence Number | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | QUERY 1 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 739 | QUERY 2 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 741 | ... 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 743 | QUERY K 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 746 Data Label: The Data Label of the original inter-RBridge Pull 747 Directory Channel protocol messages that was mapped to this 748 native channel message. The format is the same as it appears 749 right after the Inner.MacSA of the original Channel message. 751 Nickname: The nickname of the RBridge sending the original inter- 752 RBridge Pull Directory query. 754 All other fields, including the fields within the QUERY records 755 are as specified in Section 3.1. 757 The native RBridge Channel message protocol specific content for a 758 Pull Directory response is formatted as follows: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | V | T |F|P|N| RESV| Count | ERR | subERR | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Nickname | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Data Label ... (4 or 8 bytes) 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Sequence Number | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | RESPONSE 1 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 773 | RESPONSE 2 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 775 | ... 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 777 | RESPONSE K 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 780 Nickname: If F=0, the nickname of the ultimate destination 781 RBridge. If F=1, ignored. 783 Data Label: The Data Label to which the response applies. The 784 format is the same as it appears right after the Inner.MacSA in 785 TRILL Data messages. 787 All other fields, including the fields within the RESPONSE 788 records, are as specified in Section 3.2. 790 3.4 Pull Directory Request Errors 792 An error response message is indicated by a non-zero ERR field. 794 If there is an error that applies to an entire request message or its 795 header, as indicated by the range of the value of the ERR field, then 796 the query records in the request are just echoed back in the response 797 records but expanded with a zero Lifetime and the insertion of the 798 Index field. 800 If errors occur at the query level, they MUST be reported in a 801 response message separate from the results of any successful queries. 803 If multiple queries in a request have different errors, they MUST be 804 reported in separate response messages. If multiple queries in a 805 request have the same error, this error response MAY be reported in 806 one response message. 808 In an error response message, the query or queries being responded to 809 appear, expanded by the Lifetime for which the server thinks the 810 error might persist and with their Index inserted, as the RESPONSE 811 record. 813 ERR values 1 through 127 are available for encoding request message 814 level errors. ERR values 128 through 254 are available for encoding 815 query level errors. the SubErr field is available for providing more 816 detail on errors. The meaning of a SubErr field value depends on the 817 value of the ERR field. 819 ERR Meaning 820 --- ------- 821 0 (no error) 823 1 Unknown or reserved field value 824 2 Request data too short 825 3-127 (Available for allocation by IETF Review) 827 128 Unknown AFN 828 129 Address not found 829 130-254 (Available for allocation by IETF REview) 830 255 Reserved 832 The following sub-errors are specified under error code 1: 834 SubERR Field with Error 835 ------ ---------------- 836 0 Unspecified 837 1 Unknown V field value 838 2 Reserved T field value 839 3 Zero sequence number in request 840 4-254 (Available for allocation by IETF Review) 841 255 Reserved 843 More TBD 845 3.5 Cache Consistency 847 Pull Directories MUST take action to minimize the amount of time that 848 an RBridge will continue to use stale information from the Pull 849 Directory. 851 A Pull Directory server MUST maintain one of the following, in order 852 of increasing specificity. Retaining more specific records, such as 853 that given in item 3 below, minimizes spontaneous response messages 854 sent to update pull client RBridge caches. Retaining less specific 855 records, such as that given in item 1, will generally increase the 856 volume and overhead due to spontaneous response messages but still 857 maintain consistency. 859 1. An overall record per Data Label of when the last positive 860 response data will expire at a requester and when the last 861 negative response will expire. 863 2. For each unit of data (IA APPsub-TLV Address Set [IA]) held by 864 the server and each address about which a negative response was 865 sent, when the last expected response with that data or 866 negative response will expire at a requester. 868 3. For each unit of data held by the server and each address about 869 which a negative response was sent, a list of RBridges that 870 were sent that data as the response or sent a negative response 871 for the address, with the expected time to expiration at each 872 of them. 874 A Pull Directory server may have a limit as to how many RBridges it 875 can maintain expiry information for by method 3 above or how many 876 data units or addresses it can maintain expiry information for by 877 method 2. If such limits are exceeded, it MUST transition to a lower 878 numbered strategy but, in all cases, MUST support, at a minimum, 879 method 1. 881 When data at a Pull Directory changes or is deleted or data is added 882 and there may be unexpired stale information at a requesting RBridge, 883 the Pull Directory MUST send an unsolicited message as discussed 884 below. 886 If method 1, the most crude method, is being followed, then when any 887 Pull Directory information in a Data Label is changed or deleted and 888 there are outstanding cached positive data response(s), an all- 889 addresses flush positive message is flooded (multicast) within that 890 Data Label. And if data is added and there are outstanding cached 891 negative responses, an all-addresses flush negative message is 892 flooded. "All-addresses" is indicated by the Count in an unsolicited 893 response being zero. On receiving an all-addresses flooded flush 894 positive message from a Pull Directory server it has used, indicated 895 by the U, F, and P bits being one, an RBridge discards all cached 896 data responses it has for that Data Label. Similarly, on receiving an 897 all addresses flush negative message, indicated by the U, F, and N 898 bits being one, it discards all cached negative responses for that 899 Data Label. A combined flush positive and negative can be flooded by 900 having all of the U, F, P, and N bits set to one resulting in the 901 discard of all positive and negative cached information for the Data 902 Label. 904 If method 2 is being followed, then an RBridge floods address 905 specific unsolicited update positive responses when data which is 906 cached by a querying RBridge is changed or deleted and floods an 907 address specific unsolicited update negative response when such 908 information is added to. Such messages are similar to the method 1 909 flooded unsolicited flush messages. The U and F bits will be one and 910 the message will be multicast. However that Count field will be non- 911 zero and either the P or N bit, but not both, will be one. On 912 receiving such as address specific message, if it is positive the 913 addresses in the response records in the unsolicited response are 914 compared to the addresses about which the recipient RBridge is 915 holding cached positive or negative information and, if they match, 916 the cached information is updated or the negative information 917 replaced with the new positive information. On receiving an address 918 specific unsolicited update negative response, the addresses in the 919 response records in the unsolicited response are compared to the 920 addresses about which the recipient RBridge is holding cached 921 positive or negative information and, if they match, the any cached 922 positive information is discarded. 924 If method 3 is being followed, the same sort of unsolicited update 925 messages are sent as with method 2 except they are not normally 926 flooded but unicast only to the specific RBridges the server believes 927 may be holding the cached positive or negative information that may 928 need updating. However, the Pull Directory server MAY flood the 929 unsolicited update, for example if it determines that a sufficiently 930 large fraction of its requesters need to be updated. 932 3.6 Additional Pull Details 934 If an RBridge notices that a Pull Directory server is no longer data 935 reachable [RFCclear], it MUST discard all pull responses it is 936 retaining from that server as the RBridge can no longer receive cache 937 consistency messages from the server. 939 Because a Pull Directory server may need to advertise interest in 940 Data Labels even though it does not want to received end station data 941 in those Data Labels, the No Data flag bit is provided as specified 942 in Section 8.3. 944 4. Events That May Cause Directory Use 946 An RBridge can consult Directory information whenever it wants, by 947 (1) searching through information that has been retained after being 948 pushed to it or pulled by it or (2) by requesting information from a 949 Pull Directory. However, the following are expected to be the most 950 common circumstances leading to directory information use. All of 951 these are cases of ingressing (or originating) a native frame. 953 Support for each of the uses below is separately optional. 955 4.1 Forged Native Frame Ingress 957 End stations can forge the source MAC and/or IP address in a native 958 frame that an edge TRILL switch receives for ingress in some 959 particular Data Label. If there is complete Directory information as 960 to what end stations should be reachable by an egress TRILL switch or 961 a port on such a TRILL switch, frames with forged source addresses 962 SHOULD be discarded. If such frames are discarded, then none of the 963 special processing in the remaining subsection of this Section 2 964 occur and MAC address learning (see [RFC6325] Section 4.8) SHOULD NOT 965 occur. ("SHOULD NOT" is chosen because it is harmless in cases where 966 it has no effect. For example, if complete directory information is 967 available and such directory information is treated as having a 968 higher confidence that MAC addresses learned from the data plane.) 970 4.2 Unknown Destination MAC 972 Ingressing a native frame with an unknown unicast destination MAC: 973 The mapping from the destination MAC and Data Label to the egress 974 TRILL switch from which it is reachable is needed to ingress the 975 frame as unicast. If the egress RBridge is unknown, the frame must 976 be either dropped or ingressed as a multi-destination frame which 977 is flooded to all edge RBridges for its Data Label resulting in 978 increased link utilization compared with unicast routing. 979 Depending on the configuration of the TRILL switch ingressing the 980 native frame (see Section 6), directory information can be used 981 for the { destination MAC, Data Label } to egress TRILL switch 982 nickname mapping and destination MACs for which such direction 983 information is not available MAY be discarded. 985 4.3 Address Resolution Protocol (ARP) 987 Ingressing an ARP [RFC826]: 989 ARP is a flexible protocol. It is commonly used on a link to query 990 for the MAC address corresponding to an IPv4 address, test if an 991 IPv4 address is in use, or to announce a change in any of IPv4 992 address, MAC address, and/or point of attachment. 994 The logically important elements in an ARP are (1) the 995 specification of a "protocol" and a "hardware" address type, (2) 996 an operation code that can be Request or Reply, and (3) fields for 997 the protocol and hardware address of the sender and the target 998 (destination) node. 1000 Examining the three types of ARP use: 1002 1. General ARP Request / Response 1003 This is a request for the destination "hardware" address 1004 corresponding to the destination "protocol" address; however, if 1005 the source and destination protocol addresses are equal, it should 1006 be handled as in type 2 below. A general ARP is handled by doing a 1007 directory lookup on the destination "protocol" address provided in 1008 hops of finding a mapping to the desired "hardware" address. If 1009 such information is obtain from a directory, a response can be 1010 synthesized. 1012 2. Gratuitous ARP 1013 A request used by a host to announce a new IPv4 address, new MAC 1014 address, and/or new point of network attachment. Identifiable 1015 because the sender and destination "protocol" address fields have 1016 the same value. Thus, under normal circumstances, there really 1017 isn't any separate destination host to generate a response. If 1018 complete Push Directory information is being used with the Notify 1019 flag set in the IA APPsub-TLVs being pushed [IA] by all the 1020 RBridge in the Data Label, then gratuitous ARPs SHOULD be 1021 discarded rather the ingressed. Otherwise, they are either 1022 ingressed and flooded or discarded depending on local policy. 1024 3. Address Probe ARP Query 1025 An address probe ARP is used to determine if an IPv4 address is in 1026 use [RFC5227]. It can be identified by the source "protocol" 1027 (IPv4) address field being zero. The destination "protocol" 1028 address field is the IPv4 address being tested. If some host 1029 believes it has that destination IPv4 address, it would respond to 1030 the ARP query, which indicates that the address is in use. 1031 Address probe ARPs can be handled the same as General ARP queries. 1033 4.4 IPv6 Neighbor Discovery (ND) 1035 Ingressing an IPv6 ND [RFC4861]: 1036 TBD 1038 Secure Neighbor Discovery messages [RFC3971] will, in general, 1039 have to be sent to the neighbor intended so that neighbor can sign 1040 the answer; however, directory information can be used to unicast 1041 a Secure Neighbor Discovery packet rather than multicasting it. 1043 4.5 Reverse Address Resolution Protocol (RARP) 1045 Ingressing a RARP [RFC903]: 1046 RARP uses the same packet format as ARP but different Ethertype 1047 and opcode values. Its use is similar to the General ARP 1048 Request/Response as described above. The difference is that it is 1049 intended to query for the destination "protocol" address 1050 corresponding to the destination "hardware" address provided. It 1051 is handled by doing a directory lookup on the destination 1052 "hardware" address provided in hops of finding a mapping to the 1053 desired "protocol" address. For example, looking up a MAC address 1054 to find the corresponding IP address. 1056 5. Layer 3 Address Learning 1058 TRILL switches MAY learn IP addresses in a manner similar to that in 1059 which they learn MAC addresses. On ingress of a native IP frame, they 1060 can learn the { IP address, MAC address, Data Label, input port } set 1061 and on the egress of a native IP frame, they can learn the { IP 1062 address, MAC address, Data Label, remote RBridge } information plus 1063 the nickname of the RBridge that ingressed the frame. 1065 This locally learned information is retained and times out in a 1066 similar manner to MAC address learning specified in [RFC6325]. By 1067 default, it has the same Confidence as locally learned MAC 1068 reachability information. 1070 Such learned Layer 3 address information MAY be disseminated with 1071 [ESADI] using the IA APPsub-TLV [IA]. It can also be used as, in 1072 effect, local directory information to assist in locally responding 1073 to ARP/ND packets as discussed in Section 4. 1075 6. Directory Use Strategies and Push-Pull Hybrids 1077 For some edge nodes which have a great number of Data Labels enabled, 1078 managing the MAC and Data Label <-> EdgeRBridge mapping for hosts 1079 under all those Data Labels can be a challenge. This is especially 1080 true for Data Center gateway nodes, which need to communicate with a 1081 majority of Data Labels if not all. 1083 For those RBridge Edge nodes, a hybrid model should be considered. 1084 That is the Push Model is used for some Data Labels, and the Pull 1085 Model is used for other Data Labels. It is the network operator's 1086 decision by configuration as to which Data Labels' mapping entries 1087 are pushed down from directories and which Data Labels' mapping 1088 entries are pulled. 1090 For example, assume a data center when hosts in specific Data Labels, 1091 say VLANs 1 through 100, communicate regularly with external peers, 1092 the mapping entries for those 100 VLANs should be pushed down to the 1093 data center gateway routers. For hosts in other Data Labels which 1094 only communicate with external peers occasionally for management 1095 interface, the mapping entries for those VLANs should be pulled down 1096 from directory when the need comes up. 1098 The mechanisms described above for Push and Pull Directory services 1099 make it easy to use Push for some Data Labels and Pull for others. In 1100 fact, different RBridges can even be configured so that some use Push 1101 Directory services and some use Pull Directory services for the same 1102 Data Label if both Push and Pull Directory services are available for 1103 that Data Label. And there can be Data Labels for which directory 1104 services are not used at all. 1106 For Data Labels in which a hybrid push/pull approach is being taken, 1107 it would make sense to use push for address information of hosts that 1108 frequently communicate with many other hosts in the Data Label, such 1109 as a file or DNS server. Pull could then be used for hosts that 1110 communicate with few other hosts, perhaps such as hosts being used as 1111 compute engines. 1113 6.1 Strategy Configuration 1115 Each RBridge that has the ability to use directory assistance has, 1116 for each Data Label X in which it is might ingress native frames, one 1117 of four major modes: 1119 0. No directory use. The RBridge does not subscribe to Push 1120 Directory data or make Pull Directory requests for Data Label X 1121 and directory data is not consulted on ingressed frames in Data 1122 Label X that might have used directory data. This includes ARP, 1123 ND, RARP, and unknown MAC destination addresses, which are 1124 flooded. 1126 1. Use Push only. The RBridge subscribes to Push Directory data 1127 for Data Label X. 1129 2. Use Pull only. When the RBridge ingresses a frame in Data Label 1130 X that can use Directory information, if it has cached 1131 information for the address it uses it. If it does not have 1132 either cached positive or negative information for the address, 1133 it sends a Pull Directory query. 1135 3. Use Push and Pull. The RBridge subscribes to Push Directory 1136 data for Data Label X. When it ingresses a frame in Data Label 1137 X that can use Directory information and it does not find that 1138 information in its link state database of Push Directory 1139 information, it makes a Pull Directory query. 1141 The above major Directory use mode is per Data Label. In addition, 1142 there is a per Data Label per priority minor mode as listed below 1143 that indicates what should be done if Directory Data is not available 1144 for the ingressed frame. In all cases, if you are holding Push 1145 Directory or Pull Directory information to handle the frame given the 1146 major mode, the directory information is simply used and, in that 1147 instance, the minor modes does not matter. 1149 A. Flood immediate. Flood the frame immediately (even if you are 1150 also sending a Pull Directory) request. 1152 B. Flood. Flood the frame immediately unless you are going to do a 1153 Pull Directory request, in which case you wait for the response 1154 or for the request to time out after retries and flood the 1155 frame if the request times out. 1157 C. Discard if complete or Flood immediate. If you have complete 1158 Push Directory information and the address is not in that 1159 information, discard the frame. If you do not have complete 1160 Push Directory information, the same as A above. 1162 D. Discard if complete or Flood. If you have complete Push 1163 Directory information and the address is not in that 1164 information, discard the frame. If you do not have complete 1165 Push Directory information, the same as B above. 1167 In addition, the query message priority for Pull Directory requests 1168 sent can be configured on a per Data Label, per ingressed frame 1169 priority basis. The default mappings are as follows where Ingress 1170 Priority is the priority of the native frame that provoked the Pull 1171 Directory query: 1173 Ingress If Flood If Flood 1174 Priority Immediate Delayed 1175 -------- --------- -------- 1176 7 5 6 1177 6 5 6 1178 5 4 5 1179 4 3 4 1180 3 2 3 1181 2 0 2 1182 0 1 0 1183 1 1 1 1185 Priority 7 is normally only used for urgent messages critical to 1186 adjacency and so is avoided by default for directory traffic. 1188 7. Security Considerations 1190 Push Directory data is distributed through ESADI-LSPs [ESADI] which 1191 can be authenticated with the same mechanisms as IS-IS LSPs. See 1192 [RFC5304] [RFC5310] and the Security Considerations section of 1193 [ESADI]. 1195 Pull Directory queries and responses are transmitted as RBridge-to- 1196 RBridge or native RBridge Channel messages. Such messages can be 1197 secured as specified in [ChannelTunnel]. 1199 For general TRILL security considerations, see [RFC6325]. 1201 8. IANA Considerations 1203 This section give IANA allocation and registry considerations. 1205 8.1 ESADI-Parameter Data 1207 IANA is request to allocate two ESADI-Parameter TRILL APPsub-TLV flag 1208 bits for "Push Directory" (PD) and "Complete Push" (CP) and to create 1209 a sub-registry in the TRILL Parameters Registry as follows: 1211 Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits 1213 Registration Procedures: Expert Review 1215 References: [ESADI], This document 1217 Bit Mnemonic Description Reference 1218 --- -------- ----------- --------- 1219 0 UN Supports Unicast ESADI [ESADI] 1220 1 PD Push Directory Server This document 1221 2 CP Complete Push This document 1222 3-7 - available for allocation 1224 The CP bit is ignored if the PD bit is zero. 1226 In addition, the ESADI-Parameter APPsub-TLV is optionally extended, 1227 as provided in its original specification in [ESADI], by one byte as 1228 show below: 1230 +-+-+-+-+-+-+-+-+ 1231 | Type | (1 byte) 1232 +-+-+-+-+-+-+-+-+ 1233 | Length | (1 byte) 1234 +-+-+-+-+-+-+-+-+ 1235 |R| Priority | (1 byte) 1236 +-+-+-+-+-+-+-+-+ 1237 | CSNP Time | (1 byte) 1238 +-+-+-+-+-+-+-+-+ 1239 | Flags | (1 byte) 1240 +---------------+ 1241 |PushDirPriority| (optional, 1 byte) 1242 +---------------+ 1243 | Reserved for expansion (variable) 1244 +-+-+-+-... 1246 The meanings of all the fields are as specified in [ESADI] except 1247 that the added PushDirPriority is the priority of the advertising 1248 ESADI instance to be a Push Directory as described in Section 2.3. If 1249 the PushDirPriority field is not present (Length = 3) it is treated 1250 as if it were 0x40. 0x40 is also the value used and placed here by an 1251 RBridge priority to be a Push Directory has not been configured. 1253 8.2 RBridge Channel Protocol Number 1255 IANA is requested to allocate a new RBridge Channel protocol number 1256 for "Pull Directory Services" from the range allocable by Standards 1257 Action and update the table of such protocol number in the TRILL 1258 Parameters Registry referencing this document. 1260 8.3 The Pull Directory and No Data Bits 1262 IANA is requested to allocate two currently reserved bits in the 1263 Interested VLANs field of the Interested VLANs sub-TLV (suggested 1264 bits 18 and 19) and the Interested Labels field of the Interested 1265 Labels sub-TLV (suggested bits 6 and 7) [RFC6326bis] to indicate Pull 1266 Directory server (PD) and No Data (ND) respectively. These bits are 1267 to be added to the subregistry created by [ESADI] with this document 1268 as reference. 1270 In the TRILL base protocol [RFC6325] as extended for FGL [rfcFGL], 1271 the mere presence of an Interested VLANs or Interested Labels sub- 1272 TLVs in the LSP of an RBridge indicates connection to end stations in 1273 the VLANs or FGLs listed and thus a desire to receive multi- 1274 destination traffic in those Data Labels. But, with Push and Pull 1275 Directories, advertising that you are a directory server requires 1276 using these sub-TLVs for the Data Label you are serving. If such a 1277 directory server does not wish to received multi-destination TRILL 1278 Data packets for the Data Labels it lists in one of these sub-TLVs, 1279 it sets the "No Data" (ND) bit to one. This means that data on a 1280 distribution tree may be pruned so as not to reach the "No Data" 1281 RBridge as long as there are no RBridges interested in the Data who 1282 are beyond the "No Data" RBridge. This bit is backwards compatible 1283 as RBridges ignorant of it will simply not prune when they could, 1284 which is safe although it may cause increased link utilization. 1286 An example of as RBridge serving as a directory that would not want 1287 multi-destination traffic in some Data Labels might be an RBridge 1288 that does not officer end station service for any of the Data Labels 1289 for which it is serving as a directory and is either (1) a Pull 1290 Directory or (2) a Push Directory for which all of the ESADI traffic 1291 can be handled by unicast [ESADI]. 1293 Acknowledgments 1295 The contributions of the following persons are gratefully 1296 acknowledged: 1298 TBD 1300 The document was prepared in raw nroff. All macros used were defined 1301 within the source file. 1303 Normative References 1305 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 1306 RFC 826, November 1982. 1308 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 1309 Reverse Address Resolution Protocol", STD 38, RFC 903, June 1310 1984 1312 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1313 Requirement Levels", BCP 14, RFC 2119, March 1997 1315 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1316 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1318 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1319 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1320 September 2007. 1322 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1323 Authentication", RFC 5304, October 2008. 1325 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1326 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1327 5310, February 2009. 1329 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1330 Layer-2 Systems", RFC 6165, April 2011. 1332 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1333 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1334 Specification", RFC 6325, July 2011. 1336 [RFC5342bis] - Eastlake 3rd, D., "IANA Considerations and IETF 1337 Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, 1338 September 2008. 1340 [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and 1341 A. Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-rfc6326bis, 1342 work in progress. 1344 [RFCclear] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, A. 1345 Banerjee, draft-ietf-trill-clear-correct-06.txt, in RFC 1346 Editor's queue. 1348 [Channel] - D. Eastlake, V. Manral, Y. Li, S. Aldrin, D. Ward, 1349 "TRILL: RBridge Channel Support", draft-ietf-trill-rbridge- 1350 channel-08.txt, in RFC Editor's queue. 1352 [RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 1353 "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine- 1354 labeling-07.txt, in RFC Editor's queue. 1356 [ESADI] - Zhai, H., F. Hu, R. Perlman, D. Eastlake, O. Stokes, "TRILL 1357 (Transparent Interconnection of Lots of Links): The ESADI (End 1358 Station Address Distribution Information) Protocol", 1359 draft-ietf-trill-esadi, work in progress. 1361 [IA] - Eastlake, D., L. Yizhou, R. Perlman, "TRILL: Interface 1362 Addresses APPsub-TLV", draft-eastlake-trill-ia-appsubtlv, work 1363 in progress. 1365 Informational References 1367 [RFC5227] - Cheshire, S., "IPv4 Address Conflict Detection", RFC 1368 5227, July 2008. 1370 [DirectoryFramework] - Dunbar, L., D. Eastlake, R. Perlman, I. 1371 Gashinsky, "TRILL Edge Directory Assistance Framework", 1372 draft-ietf-trill-directory-framework, in RFC Editor's queue. 1374 [ChannelTunnel] - D. Eastlake, Y. Li, "TRILL: RBridge Channel Tunnel 1375 Protocol", draft-eastlake-trill-channel-tunnel, work in 1376 progress. 1378 [ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large 1379 Data Centers", Oct 2010. 1381 Authors' Addresses 1383 Linda Dunbar 1384 Huawei Technologies 1385 5430 Legacy Drive, Suite #175 1386 Plano, TX 75024, USA 1388 Phone: (469) 277 5840 1389 Email: ldunbar@huawei.com 1391 Donald Eastlake 1392 Huawei Technologies 1393 155 Beaver Street 1394 Milford, MA 01757 USA 1396 Phone: 1-508-333-2270 1397 Email: d3e3e3@gmail.com 1399 Radia Perlman 1400 Intel Labs 1401 2200 Mission College Blvd. 1402 Santa Clara, CA 95054-1549 USA 1404 Phone: +1-408-765-8080 1405 Email: Radia@alum.mit.edu 1407 Igor Gashinsky 1408 Yahoo 1409 45 West 18th Street 6th floor 1410 New York, NY 10011 1412 Email: igor@yahoo-inc.com 1414 Yizhou Li 1415 Huawei Technologies 1416 101 Software Avenue, 1417 Nanjing 210012 China 1419 Phone: +86-25-56622310 1420 Email: liyizhou@huawei.com 1422 Copyright, Disclaimer, and Additional IPR Provisions 1424 Copyright (c) 2013 IETF Trust and the persons identified as the 1425 document authors. All rights reserved. 1427 This document is subject to BCP 78 and the IETF Trust's Legal 1428 Provisions Relating to IETF Documents 1429 (http://trustee.ietf.org/license-info) in effect on the date of 1430 publication of this document. Please review these documents 1431 carefully, as they describe your rights and restrictions with respect 1432 to this document. Code Components extracted from this document must 1433 include Simplified BSD License text as described in Section 4.e of 1434 the Trust Legal Provisions and are provided without warranty as 1435 described in the Simplified BSD License. The definitive version of 1436 an IETF Document is that published by, or under the auspices of, the 1437 IETF. Versions of IETF Documents that are published by third parties, 1438 including those that are translated into other languages, should not 1439 be considered to be definitive versions of IETF Documents. The 1440 definitive version of these Legal Provisions is that published by, or 1441 under the auspices of, the IETF. Versions of these Legal Provisions 1442 that are published by third parties, including those that are 1443 translated into other languages, should not be considered to be 1444 definitive versions of these Legal Provisions. For the avoidance of 1445 doubt, each Contributor to the IETF Standards Process licenses each 1446 Contribution that he or she makes as part of the IETF Standards 1447 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1448 language to the contrary, or terms, conditions or rights that differ 1449 from or are inconsistent with the rights and licenses granted under 1450 RFC 5378, shall have any effect and shall be null and void, whether 1451 published or posted by such Contributor, or included with or in such 1452 Contribution.