idnits 2.17.1 draft-ietf-trill-directory-assist-mechanisms-01.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 (November 10, 2014) is 3454 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) ** Obsolete normative reference: RFC 7180 (Obsoleted by RFC 7780) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Linda Dunbar 3 Intended status: Proposed Standard Donald Eastlake 4 Huawei 5 Radia Perlman 6 EMC 7 Igor Gashinsky 8 Yahoo 9 Yizhou Li 10 Huawei 11 Expires: May 9, 2014 November 10, 2014 13 TRILL: Edge Directory Assist Mechanisms 14 16 Abstract 17 This document describes mechanisms for providing directory service to 18 TRILL (Transparent Interconnection of Lots of Links) edge switches. 19 The directory information provided can be used in reducing multi- 20 destination traffic, particularly ARP/ND and unknown unicast 21 flooding. 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................................7 57 2.3.2 Push Directory Events and Conditions.................8 58 2.3.3 State Transition Diagram and Table...................9 59 2.4 Additional Push Details...............................10 60 2.5 Primary to Secondary Server Push Service..............11 62 3. Pull Model Directory Assistance Mechanisms.............12 63 3.1 Pull Directory Message Common Format..................13 64 3.2 Pull Directory Query and Response Messages............14 65 3.2.1 Pull Directory Query Message Format.................14 66 3.2.2 Pull Directory Response Format......................17 67 3.3 Cache Consistency.....................................19 68 3.3.1 Update Message Format...............................21 69 3.3.2 Acknowledge Message Format..........................22 70 3.4 Pull Directory Hosted on an End Station...............22 71 3.5 Pull Directory Message Errors.........................24 72 3.6 Additional Pull Details...............................25 74 4. Directory Use Strategies and Push-Pull Hybrids.........27 75 4.1 Strategy Configuration................................27 77 5. Security Considerations................................30 79 6. IANA Considerations....................................31 80 6.1 ESADI-Parameter Data Extensions.......................31 81 6.2 RBridge Channel Protocol Number.......................32 82 6.3 The Pull Directory (PUL) and No Data (NOD) Bits.......32 84 Acknowledgments...........................................34 85 Normative References......................................35 86 Informational References..................................36 87 Authors' Addresses........................................37 89 1. Introduction 91 [RFC7067] gives a problem statement and high level design for using 92 directory servers to assist TRILL [RFC6325] edge nodes in reducing 93 multi-destination ARP/ND, reducing unknown unicast flooding traffic, 94 and improving security against address spoofing within a TRILL 95 campus. Because multi-destination traffic becomes an increasing 96 burden as a network scales up in number of nodes, reducing ARP/ND and 97 unknown unicast flooding improves TRILL network scalability. This 98 document describes specific mechanisms for directory servers to 99 assist TRILL edge nodes. These mechanisms are optional to implement. 101 The information held by the Directory(s) is address mapping and 102 reachability information. Most commonly, what MAC address [RFC7042] 103 corresponds to an IP address within a Data Label (VLAN or FGL (Fine 104 Grained Label [RFC7172])) and the egress TRILL switch (RBridge), and 105 optionally what specific TRILL switch port, from which that MAC 106 address is reachable. But it could be what IP address corresponds to 107 a MAC address or possibly other address mappings or reachability. 109 In the data center environment, it is common for orchestration 110 software to know and control where all the IP addresses, MAC 111 addresses, and VLANs/tenants are in a data center. Thus such 112 orchestration software can be appropriate for providing the directory 113 function or for supplying the Directory(s) with directory 114 information. 116 Directory services can be offered in a Push or Pull Mode [RFC7067]. 117 Push Mode, in which a directory server pushes information to TRILL 118 switches indicating interest, is specified in Section 2. Pull Mode, 119 in which a TRILL switch queries a server for the information it 120 wants, is specified in Section 3. More detail on modes of operation, 121 including hybrid Push/Pull, are provided in Section 4. 123 The mechanism used to initially populate directory data in primary 124 servers is beyond the scope of this document. A primary server can 125 use the Push Directory service to provide directory data to secondary 126 servers as described in Section 2.5. 128 1.1 Uses of Directory Information 130 A TRILL switch can consult Directory information whenever it wants, 131 by (1) searching through information that has been retained after 132 being pushed to it or pulled by it or (2) by requesting information 133 from a Pull Directory. However, the following are expected to be the 134 most common circumstances leading to directory information use. All 135 of these are cases of ingressing (or originating) a native frame. 137 1. ARP requests and replies [RFC826] are normally broadcast. But a 138 directory assisted edge TRILL switches could intercept ARP 139 messages and reply if the TRILL switch has the relevant 140 information. 142 2. IPv6 ND (Neighbor Discovery [RFC4861]) requests and replies are 143 normally multicast. Except in the case of Secure ND [RFC3971] 144 where possession of the right keying material might be required, 145 directory assisted edge TRILL switches could intercept ND messages 146 and reply if the TRILL switch has the relevant information. 148 3. Unknown destination MAC addresses. An edge TRILL switch ingressing 149 a native frame necessarily has to determine if it knows the egress 150 RBridge from which the destination MAC address of the frame (in 151 the frame's VLAN or Fine Grained Label) is reachable. It might 152 learn that information from the directory or could query the 153 directory if it does not know. Furthermore, if the edge TRILL 154 switch has complete directory information, it can detect forged 155 source MAC address on the native frame and discard the frame in 156 that case. 158 4. RARP [RFC903] is similar to ARP as above. 160 1.2 Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 The terminology and acronyms of [RFC6325] are used herein along with 167 the following: 169 COP: Complete Push flag bit. See Sections 2 and 6.1 below. 171 CSNP Time: Complete Sequence Number PDU Time. See ESDADI [RFC7357] 172 and Section 6.1 below. 174 Data Label: VLAN or FGL. 176 FGL: Fine Grained Label [RFC7172]. 178 Host: Application running on a physical server or a virtual machine. 179 A host must have a MAC address and usually has at least one IP 180 address. 182 IP: Internet Protocol. In this document, IP includes both IPv4 and 183 IPv6. 185 PSH: Push Directory flag bit. See Sections 2 and 6.1 below. 187 PUL: Pull Directory flag bit. See Sections 3 and 6.3 below. 189 primary server: A Directory server that obtains the information it is 190 serving up by a reliable mechanism outside the scope of this 191 document designed to assure the freshness of that information. 192 (See secondary server.) 194 RBridge: An alternative name for a TRILL switch. 196 secondary server: A Directory server that obtains the information it 197 is serving up from one or more primary servers. 199 tenant: Sometimes used as a synonym for FGL. 201 TRILL switch: A device that implements the TRILL protocol. 203 2. Push Model Directory Assistance Mechanisms 205 In the Push Model [RFC7067], one or more Push Directory servers 206 reside at TRILL switches and push down the address mapping 207 information for the various addresses associated with end station 208 interfaces and the TRILL switches from which those interfaces are 209 reachable [IA]. This service is scoped by Data Label (VLAN or FGL 210 [RFC7172]). A Push Directory also advertises whether or not it 211 believes it has pushed complete mapping information for a Data Label. 212 It might be pushing only a subset of the mapping and/or reachability 213 information for a Data Label. The Push Model uses the ESADI [RFC7357] 214 protocol as its distribution mechanism. 216 With the Push Model, if complete address mapping information for a 217 Data Label being pushed is available, a TRILL switch (RBridge) which 218 has that complete pushed information and is ingressing a native frame 219 can simply drop the frame if the destination unicast MAC address 220 can't be found in the mapping information available, instead of 221 flooding the frame (ingressing it as an unknown MAC destination TRILL 222 Data frame). But this will result in lost traffic if ingress TRILL 223 switch's directory information is incomplete. 225 2.1 Requesting Push Service 227 In the Push Model, it is necessary to have a way for a TRILL switch 228 to request information from the directory server(s). TRILL switches 229 simply use the ESADI [RFC7357] protocol mechanism to announce, in 230 their core IS-IS LSPs, the Data Labels for which they are 231 participating in ESADI by using the Interested VLANs and/or 232 Interested Labels sub-TLVs [RFC7176]. This will cause them to be 233 pushed the Directory information for all such Data Labels that are 234 being served by one or more Push Directory servers. 236 2.2 Push Directory Servers 238 Push Directory servers advertise their availability to push the 239 mapping information for a particular Data Label to each other and to 240 ESADI participants for that Data Label through ESADI by turning on 241 the a flag bit in their ESADI Parameter APPsub-TLV for that ESADI 242 instance (see [RFC7357] and Section 6.1). Each Push Directory server 243 MUST participate in ESADI for the Data Labels for which it will push 244 mappings and set the PSH (Push Directory) bit in its ESADI-Parameters 245 APPsub-TLV for that Data Label. 247 For robustness, it is useful to have more than one copy of the data 248 being pushed. Each Push Directory server is configured with a number 249 N in the range 1 to 8, which defaults to 2, for each Data Label for 250 which it can push directory information. If the Push Directories for 251 a Data Label are configured the same in this regard and enough such 252 servers are available, N copies of the directory that will be pushed. 254 Each Push Directory server also has an 8-bit priority to be Active 255 (see Section 6.1 of this document). This priority is treated as an 256 unsigned integer where larger magnitude means higher priority and is 257 in its ESADI Parameter APPsub-TLV. In cases of equal priority, the 258 6-byte IS-IS System IDs of the tied Push Directories are used as a 259 tie breaker and treated as an unsigned integer where larger magnitude 260 means higher priority. 262 For each Data Label it can serve, each Push Directory server orders, 263 by priority, the Push Directory servers that it can see in the ESADI 264 link state database for that Data Label that are data reachable 265 [RFC7180] and determines its own position in that order. If a Push 266 Directory server is configured to believe that N copies of the 267 mappings for a Data Label should be pushed and finds that it is 268 number K in the priority ordering (where number 1 is highest priority 269 and number K is lowest), then if K is less than or equal to N the 270 Push Directory server is Active. If K is greater than N it is 271 Passive. Active and Passive behavior are specified below. 273 For a Push Directory to reside on an end station, one or more TRILL 274 switches locally connected to that end station must proxy for the 275 Push Directory server and advertise themselves as Push Directory 276 servers. It appears to the rest of the TRILL campus that these TRILL 277 switches (that are proxying for the end station) are the Push 278 Directory server(s). The protocol between such a Push Directory end 279 station and the one or more proxying TRILL switches acting as Push 280 Directory servers is beyond the scope of this document. 282 2.3 Push Directory Server State Machine 284 The subsections below describe the states, events, and corresponding 285 actions for Push Directory servers. 287 2.3.1 Push Directory States 289 A Push Directory Server is in one of six states, as listed below, for 290 each Data Label it can serve. In addition, it has an internal State- 291 Transition-Time variable for each Data Label it can serve which is 292 set at each state transition and which enables it to determine how 293 long it has been in its current state for that Data Label. 295 Down: A completely shut down virtual state defined for convenience in 296 specifying state diagrams. A Push Directory Server in this state 297 does not advertise any Push Directory data. It may be 298 participating in ESDADI [RFC7357] with the PSH bit zero in its 299 ESADI-Parameters or might be not participating in ESADI at all. 300 All states other than the Down state are considered to be Up 301 states. 303 Passive: No Push Directory data is advertised. Any outstanding EASDI- 304 LSP fragments containing directory data are updated to remove that 305 data and if the result is an empty fragment (contains nothing 306 except possibly an Authentication TLV), the fragment is purged. 307 The Push Directory participates in ESDADI [RFC7357] and advertises 308 its ESADI fragment zero that includes an ESADI-Parameters APPsub- 309 TLV with the PSH bit set to one and COP (Complete Push) bit zero. 311 Active: If a Push Directory server is Active, it advertises its 312 directory data and any changes through ESADI [RFC7357] in its 313 ESADI-LSPs using the Interface Addresses [IA] APPsub-TLV and 314 updates that information as it changes. The PSH bit is set to one 315 in the ESADI-Parameters and the COP bit set to zero. 317 Completing: Same behavior as the Active state but responds 318 differently to events. 320 Complete: The same behavior as Active except that the COP bit in the 321 ESADI-Parameters APPsub-TLV is set to one and the server responds 322 differently to events. 324 Reducing: The same behavior as Complete but responds differently to 325 events. The PSH bit remains a one but the COP bit is cleared to 326 zero in the ESADI-Parameters APPsub-TLV. Directory updates 327 continue to be advertised. 329 2.3.2 Push Directory Events and Conditions 331 Three auxiliary conditions referenced later in this section are 332 defined as follows for convenience: 334 The Activate Condition: The Push Directory server determines that it 335 is priority K among the data reachable Push Directory servers 336 (where highest priority is 1), the server is configured that there 337 should be N copies pushed, and K is less than or equal to N. For 338 example, the Push Directory server is configured that 2 copies 339 should be pushed and finds that it is priority 1 or 2 among the 340 Push Directory servers it can see. 342 The Pacify Condition: The Push Directory server determines that it is 343 priority K among the data reachable data reachable Push Directory 344 servers (where highest priority is 1), the server is configured 345 that there should be N copies pushed, and K is greater than N. For 346 example, the Push Directory server is configured that 2 copies 347 should be pushed and finds that it is priority 3 or lower priority 348 (higher number) among the Push directory servers it can see. 350 The Time Condition: The Push Directory server has been in its current 351 state for an amount of time equal to or larger than its CSNP time 352 (see Section 6.1).) 354 The events and conditions listed below cause state transitions in 355 Push Directory servers. 357 1. Push Directory server was Down but is now up. 359 2. The Push Directory server or the TRILL switch on which it resides 360 is being shut down. 362 3. The Activate Condition is met and the server is not configured to 363 believe it has complete data. 365 4. The Pacify Condition is met. 367 5. The Activate Condition is met and the server is configured to 368 believe it has complete data. 370 6. The server is configured to believe it does not have complete 371 data. 373 7. The Time Condition is met. 375 2.3.3 State Transition Diagram and Table 377 The state transition table is as follows: 379 Event || Down |Passive |Active |Completing|Complete|Reducing| 380 ------++-------+----------+--------+----------+--------+--------+ 381 1 ||Passive|Passive |Active |Completing|Complete|Reducing| 382 2 || Down | Down |Passive |Passive |Reducing|Reducing| 383 3 || Down |Active |Active |Active |Reducing|Reducing| 384 4 || Down |Passive |Passive |Passive |Reducing|Reducing| 385 5 || Down |Completing|Complete|Completing|Complete|Complete| 386 6 || Down |Passive |Active |Active |Reducing|Reducing| 387 7 || Down |Passive |Active |Complete |Complete|Active | 389 The above state table is equivalent to the following transition 390 diagram: 392 +-----------+ 393 | Down |<---------+ 394 +-----------+ | 395 |1 ^ | 3,4,5,6,7 | 396 | | +------------+ 397 V |2 398 +-----------+ 399 | Passive |<----------------------- 400 +-----------+ ^ ^ ^ 401 |5 |3 |1,4,6,7 | | | 402 | | +---------+ | | 403 | V |2,4 | 404 | +---------------------+ | 405 | | Active |<--+ | 406 | +---------------------+ | | 407 | |5 ^ |1,3,6,7 ^ | | 408 | | | | | | | 409 | | | +---------+ | | 410 | | | | | 411 V V |3,6 | | 412 +--------------+ | | 413 | Completing |-------------------+ 414 +--------------+ 2,4 | 415 |7 |1,5 ^ | 416 | | | | 417 | +-----+ | 418 V |7 419 +-------------+ +----------------+ 420 | Complete |--------->| Reducing |<--+ 421 +-------------+ 2,3,4,6 +----------------+ | 422 |1,5,7 ^ ^ |5 |1,2,3,4,6 | 423 | | | | | | 424 +------+ +--------------+ +--------------+ 426 Figure 1. Push Server State Diagram 428 2.4 Additional Push Details 430 Push Directory mappings can be distinguished for other data 431 distributed through ESADI because mappings are distributed only with 432 the Interface Addresses APPsub-TLV [IA] and are flagged as being Push 433 Directory data. 435 TRILL switches, whether or not they are a Push Directory server, MAY 436 continue to advertise any locally learned MAC attachment information 437 in ESDADI [RFC7357] using the Reachable MAC Addresses TLV [RFC6165]. 438 However, if a Data Label is being served by complete Push Directory 439 servers, advertising such locally learned MAC attachment generally 440 SHOULD NOT be done as it would not add anything and would just waste 441 bandwidth and ESADI link state space. An exception might be when a 442 TRILL switch learns local MAC connectivity and that information 443 appears to be missing from the directory mapping. 445 Because a Push Directory server needs to advertise interest in one or 446 more Data Labels even if it does not want to receive end station 447 multidestination data in those Data Labels, the No Data (NOD) flag 448 bit is provided as specified in Section 6.3. 450 When a Push Directory server is no longer data reachable [RFC7180], 451 TRILL switches MUST ignore any Push Directory data from that server 452 because it is no longer being updated and may be stale. 454 The nature of dynamic distributed asynchronous systems is such that 455 it is impossible for a TRILL switch receiving Push Directory 456 information to be absolutely certain that it has complete 457 information. However, it can obtain a reasonable assurance of 458 complete information by requiring two conditions to be met: 459 1. The PSH and COP bits are on in the ESADI zero fragment from the 460 server for the relevant Data Label. 461 2. It has had continuous data connectivity to the server for the 462 larger of the client's and the server's CSNP times. 463 Condition 2 is necessary because a client TRILL switch might be just 464 coming up and receive an EASDI LSP meeting the requirement in 465 condition 1 above but have not yet received all of the ESADI LSP 466 fragment from the Push Directory server. 468 There may be conflicts between mapping information from different 469 Push Directory servers or conflicts between locally learned 470 information and information received from a Push Directory server. In 471 case of such conflicts, information with a higher confidence value 472 [RFC6325] is preferred over information with a lower confidence. In 473 case of equal confidence, Push Directory information is preferred to 474 locally learned information and if information from Push Directory 475 servers conflicts, the information from the higher priority Push 476 Directory server is preferred. 478 2.5 Primary to Secondary Server Push Service 480 A secondary Push or Pull Directory server is one that obtains its 481 data from a primary directory server. Other techniques MAY be used 482 but, by default, this data transfer occurs through the primary server 483 acting as a Push Directory server for the Data Labels involved while 484 the secondary directory server takes the pushed data it receives from 485 the highest priority Push Directory server and re-originates it. Such 486 a secondary server may be a Push Directory server or a Pull Directory 487 server or both for any particular Data Label. 489 3. Pull Model Directory Assistance Mechanisms 491 In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory 492 information from an appropriate Directory Server when needed. 494 Pull Directory servers for a particular Data Label X are found by 495 looking in the core TRILL IS-IS link state database for data 496 reachable TRILL switches that advertise themselves by having the Pull 497 Directory flag (PUL) on in their Interested VLANs or Interested 498 Labels sub-TLV [RFC7176] for that Data Label. If multiple such TRILL 499 switches indicate that they are Pull Directory Servers for a 500 particular Data Label, pull requests can be sent to any one or more 501 of them but it is RECOMMENDED that pull requests be preferentially 502 sent to the server or servers that are lower cost from the requesting 503 TRILL switch. 505 Pull Directory requests are sent by enclosing them in an RBridge 506 Channel [RFC7178] message using the Pull Directory channel protocol 507 number (see Section 6.2). Responses are returned in an RBridge 508 Channel message using the same channel protocol number. See Section 509 3.2 for Query and Response message formats. For cache consistency or 510 notification purposes, Pull Directory servers can sent unsolicited 511 Update messages to client TRILL switches they believe may be holding 512 old data and those clients can acknowledge such updates, as described 513 in Section 3.3. All these messages have a common header as described 514 in Section 3.1. Errors returns can be sent for queries or updates as 515 described in Section 3.5. 517 The requests to Pull Directory Servers are typically derived from 518 ingressed ARP [RFC826], ND [RFC4861], or RARP [RFC903] messages, or 519 data frames with unknown unicast destination MAC addresses, 520 intercepted by an ingress TRILL switch as described in Section 4. 522 Pull Directory responses include an amount of time for which the 523 response should be considered valid. This includes negative responses 524 that indicate no data is available. Thus both positive responses with 525 data and negative responses can be cached and used to locally handle 526 ARP, ND, RARP, unknown destination MAC frames, or the like, until the 527 responses expire. If information previously pulled is about to 528 expire, a TRILL switch MAY try to refresh it by issuing a new pull 529 request but, to avoid unnecessary requests, SHOULD NOT do so if it 530 has not been recently used. The validity timer of cached Pull 531 Directory responses is NOT reset or extended merely because that 532 cache entry is used. 534 3.1 Pull Directory Message Common Format 536 All Pull Directory messages are transmitted as the payload of RBridge 537 Channel messages. All Pull Directory messages are formatted as 538 described below starting with the following common 8-byte header: 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Ver | Type | Flags | Count | Err | SubErr | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Sequence Number | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type Specific Payload - variable length 548 +-+-+- ... 550 Ver: Version of the Pull Directory protocol as an unsigned 551 integer. Version zero is specified in this document. 553 Type: The Pull Directory message type as follows: 555 Type Section Name 556 ---- ------- -------- 557 0 3.2.1 Query 558 1 3.2.2 Response 559 2 3.1.4 Update 560 3 3.1.5 Acknowledge 561 4-15 - Reserved 563 Flags: Four flag bits whose meaning depends on the Pull Directory 564 message Type. Flags whose meaning is not specified are 565 reserved, MUST be sent as zero, and MUST be ignored on receipt. 567 Count: Most Pull Directory message types specified herein have 568 zero or more occurrences of a Record as part of the type 569 specific payload. The Count field is the number of occurrences 570 of that Record as an unsigned integer. For Pull Directory 571 messages not structured with such occurrences, this field MUST 572 be sent as zero and ignored on receipt. 574 Err, SubErr: The error and suberror fields are only used in 575 messages that are in the nature of replies or acknowledgements. 576 In messages that are requests or updates, these fields MUST be 577 sent as zero and ignored on receipt. The meaning of values in 578 the Err field depends on the Pull Directory message Type but in 579 all cases the value zero means no error. The meaning of values 580 in the SubErr field depends on both the message Type and on the 581 value of the Err field but in all cases, a zero SubErr field is 582 allowed and provides no additional information beyond the value 583 of the Err field. 585 Sequence Number: An opaque 32-bit quantity set by the TRILL switch 586 sending a request or other unsolicited message and returned in 587 every corresponding reply or acknowledgement. It is used to 588 match up responses with the message to which they respond. 590 Type Specific Payload: Format depends on the Pull Directory 591 message Type. 593 3.2 Pull Directory Query and Response Messages 595 3.2.1 Pull Directory Query Message Format 597 A Pull Directory Query message is sent as the Channel Protocol 598 specific content of an RBridge Channel message [RFC7178] TRILL Data 599 packet or as a native RBridge Channel data frame (see Section 3.4). 600 The Data Label of the packet is the Data Label in which the query is 601 being made. The priority of the channel message is a mapping of the 602 priority of the frame being ingressed that caused the query with the 603 default mapping depending, per Data Label, on the strategy (see 604 Section 4) or a configured priority for generated queries. (Geerate 605 queries are those not the result of a mapping. For example, a query 606 to refresh a cache entry.) The Channel Protocol specific data is 607 formatted as a header and a sequence of zero or more QUERY Records as 608 follows: 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Ver | Type | Flags | Count | Err | SubErr | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Sequence Number | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | QUERY 1 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 619 | QUERY 2 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 621 | ... 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 623 | QUERY K 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 626 Ver, Sequence Number: See 3.1. 628 Type: 1 for Query. Queries received by an TRILL switch that is not 629 a Pull Directory result in an error response (see Section 3.5) 630 unless inhibited by rate limiting. 632 Flags, Err, and SubErr: MUST be sent as zero and ignored on 633 receipt. 635 Count: Number of QUERY Records present. A Query message Count of 636 zero is explicitly allowed, for the purpose of pinging a Pull 637 Directory server to see if it is responding. On receipt of such 638 an empty Query message, a Response message that also has a 639 Count of zero is sent unless inhibited by rate limiting. 641 QUERY: Each QUERY Record within a Pull Directory Query message is 642 formatted as follows: 644 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 645 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 646 | SIZE | RESV | QTYPE | 647 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 648 If QTYPE = 1 649 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 650 | AFN | 651 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 652 | Query address ... 653 +--+--+--+--+--+--+--+--+--+--+--... 654 If QTYPE = 2, 3, 4, or 5 655 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 656 | Query frame ... 657 +--+--+--+--+--+--+--+--+--+--+--... 659 SIZE: Size of the QUERY record in bytes as an unsigned integer 660 starting not counting the SIZE field and following byte. 661 Thus the minimum legal value is 2. A value of SIZE less than 662 2 indicates a malformed QUERY record. The QUERY record with 663 the illegal SIZE value and any subsequent QUERY records MUST 664 be ignored and the entire Query message MAY be ignored. 666 RESV: A block of reserved bits. MUST be sent as zero and 667 ignored on receipt. 669 QTYPE: There are several types of QUERY Records currently 670 defined in two classes as follows: (1) a QUERY Record that 671 provides an explicit address and asks for all addresses for 672 the interface specified by the query address and (2) a QUERY 673 Record that includes a frame. The fields of each are 674 specified below. Values of QTYPE are as follows: 676 QTYPE Description 677 ----- ----------- 678 0 reserved 679 1 address query 680 2 ARP query frame 681 3 ND query frame 682 4 RARP query frame 683 5 Unknown unicast MAC query frame 684 6-14 assignable by IETF Review 685 15 reserved 687 AFN: Address Family Number of the query address. 689 Address Query: The query is asking for any other addresses, 690 and the nickname of the TRILL switch from which they are 691 reachable, that correspond to the same interface, within 692 the data label of the query. Typically that would be 693 either (1) a MAC address with the querying TRILL switch 694 primarily interested in the TRILL switch by which that 695 MAC address is reachable, or (2) an IP address with the 696 querying TRILL switch interested in the corresponding MAC 697 address and the TRILL switch by which that MAC address is 698 reachable. But it could be some other address type. 700 Query Frame: Where a QUERY Record is the result of an ARP, 701 ND, RARP, or unknown unicast MAC destination address, the 702 ingress TRILL switch MAY send the frame to a Pull 703 Directory Server if the frame is small enough that the 704 resulting Query message fits into a TRILL Data packet 705 within the campus MTU. 707 If no response is received to a Pull Directory Query message within a 708 timeout configurable in milliseconds that defaults to 200, the Query 709 message should be re-transmitted with the same Sequence Number up to 710 a configurable number of times that defaults to three. If there are 711 multiple QUERY Records in a Query message, responses can be received 712 to various subsets of these QUERY Records before the timeout. In that 713 case, the remaining unanswered QUERY Records should be re-sent in a 714 new Query message with a new sequence number. If a TRILL switch is 715 not capable of handling partial responses to queries with multiple 716 QUERY Records, it MUST NOT sent a Request message with more than one 717 QUERY Record in it. 719 See Section 3.5 for a discussion of how Query message errors are 720 handled. 722 3.2.2 Pull Directory Response Format 724 Pull Directory Response messages are sent as the Channel Protocol 725 specific content of an RBridge Channel message [RFC7178] TRILL Data 726 packet or as a native RBridge Channel data frame (see Section 3.4). 727 Responses are sent with the same Data Label and priority as the Query 728 message to which they correspond except that the Response message 729 priority is limited to be not more than a configured value. This 730 priority limit is configurable at per TRILL switch and defaults to 731 priority 6. Pull Directory Response messages SHOULD NOT be sent with 732 priority 7 as that priority SHOULD be reserved for messages critical 733 to network connectivity. 735 The RBridge Channel protocol specific data format is as follows: 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Ver | Type | Flags | Count | Err | SubErr | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Sequence Number | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | RESPONSE 1 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 746 | RESPONSE 2 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 748 | ... 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 750 | RESPONSE K 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 753 Ver, Sequence Number: As specified in Section 3.1. 755 Type: 2 = Response. 757 Flags: MUST be sent as zero and ignored on receipt. 759 Count: Count is the number of RESPONSE Records present in the 760 Response message. 762 Err, SubErr: A two part error code. Zero unless there was an error 763 in the Query message, for which case see Section 3.5. 765 RESPONSE: Each RESPONSE record within a Pull Directory Response 766 message is formatted as follows: 768 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 769 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 770 | SIZE |OV| RESV | Index | 771 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 772 | Lifetime | 773 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 774 | Response Data ... 775 +--+--+--+--+--+--+--+--+--+--+--... 777 SIZE: Size of the RESPONSE Record in bytes not counting the 778 SIZE field and following byte. Thus the minimum value of 779 SIZE is 2. If SIZE is less than 2, that RESPONSE Record and 780 all subsequent RESPONSE Records in the Response message MUST 781 be ignored and the entire Response message MAY be ignored. 783 OV: The overflow flag. Indicates, as described below, that 784 there was too much Response Data to include in one Response 785 message. 787 RESV: Three reserved bits that MUST be sent as zero and ignored 788 on receipt. 790 Index: The relative index of the QUERY Record in the Query 791 message to which this RESPONSE Record corresponds. The index 792 will always be one for Query messages containing a single 793 QUERY Record. If the Index is larger than the Count was in 794 the corresponding Query, that RESPONSE Record MUST be 795 ignored and subsequent RESPONSE Records or the entire 796 Response message MAY be ignored. 798 Lifetime: The length of time for which the response should be 799 considered valid in units of 200 milliseconds except that 800 the values zero and 2**16-1 are special. If zero, the 801 response can only be used for the particular query from 802 which it resulted and MUST NOT be cached. If 2**16-1, the 803 response MAY be kept indefinitely but not after the Pull 804 Directory server goes down or becomes unreachable. The 805 maximum definite time that can be expressed is a little over 806 3.6 hours. 808 Response Data: There are various types of RESPONSE Records. 809 - If the Err field is non-zero, then the Response Data is a 810 copy of the corresponding QUERY Record data, that is, 811 either an AFN followed by an address or a query frame. 812 See Section 3.5 for additional information on errors. 813 - If the Err field is zero and the corresponding QUERY 814 Record was an address query, then the Response Data is 815 formated as the value of an Interface Addresses APPsub- 816 TLV [IA]. The maximum size of such contents is 253 bytes 817 in the case when SIZE is 255. 819 - If the Err field is zero and the corresponding QUERY 820 Record was a frame query, then the Response data consists 821 of the response frame for ARP, ND, or RARP and a copy of 822 the frame for unknown unicast destination MAC. 824 Multiple RESPONSE Records can appear in a Response message with the 825 same index if the answer to a QUERY Record consists of multiple 826 Interface Address APPsub-TLV values. This would be necessary if, for 827 example, a MAC address within a Data Label appears to be reachable by 828 multiple TRILL switches. However, all RESPONSE Records to any 829 particular QUERY Record MUST occur in the same Response message. If a 830 Pull Directory holds more mappings for a queried address than will 831 fit into one Response message, it selects which to include by some 832 method outside the scope of this document and sets the overflow flag 833 (OV) in all of the RESPONSE Records responding to that query address. 835 See Section 3.5 for a discussion of how errors are handled. 837 3.3 Cache Consistency 839 A Pull Directory MUST take action to minimize the amount of time that 840 a TRILL switch will continue to use stale information from that Pull 841 Directory by sending Update messages. 843 A Pull Directory server MUST maintain one of the following three sets 844 of records, in order of increasing specificity. Retaining more 845 specific records, such as that given in item 3 below, minimizes 846 Spontaneous Update messages sent to update pull client TRILL switch 847 caches but increases the record keeping burden on the Pull Directory 848 server. Retaining less specific records, such as that given in item 849 1, will generally increase the volume and overhead due to Spontaneous 850 Update messages and due to unnecessarily invalidating cached 851 information, but will still maintain consistency and will reduce the 852 record keeping burden on the Pull Directory server. In all cases, 853 there may still be brief periods of time when directory information 854 has changed but cached information a pull clients has not yet been 855 updated or expunged. 857 1. An overall record per Data Label of when the last positive 858 response data sent will expire at some requester and when the 859 last negative response will expire at some requester, assuming 860 those responders cached the response. 862 2. For each unit of data (IA APPsub-TLV Address Set [IA]) held by 863 the server and each address about which `a negative response 864 was sent, when the last response sent with that positive 865 response data or negative response will expire at a requester, 866 assuming the requester cached the response. 868 3. For each unit of data held by the server (IA APPsub-TLV Address 869 Set [IA]) and each address about which a negative response was 870 sent, a list of TRILL switches that were sent that data as a 871 positive response or sent a negative response for the address, 872 and the expected time to expiration for that data or address at 873 each such TRILL switch, assuming the requester cached the 874 response. 876 A Pull Directory server may have a limit as to how many TRILL 877 switches for which it can maintain expiry information by method 3 878 above or how many data units or addresses it can maintain expiry 879 information for by method 2. If such limits are exceeded, it MUST 880 transition to a lower numbered strategy but, in all cases, MUST 881 support, at a minimum, method 1. 883 When data at a Pull Directory changes or is deleted or data is added 884 and there may be unexpired stale information at a requesting TRILL 885 switch, the Pull Directory MUST send an Update message as discussed 886 below. The sending of such an Update message MAY be delayed by a 887 configurable number of milliseconds that default to 50 milliseconds 888 to await other possible changes that could be included in the same 889 Update. 891 If method 1, the most crude method, is being followed, then when any 892 Pull Directory information in a Data Label is changed or deleted and 893 there are outstanding cached positive data response(s), an all- 894 addresses flush positive Update message is flooded within that Data 895 Label as an RBridge Channel message with an Inner.MacDA of All- 896 Egress-RBridges. And if data is added and there are outstanding 897 cached negative responses, an all-addresses flush negative message is 898 similarly flooded. "All-addresses" is indicated by the Count field 899 being zero in an Update message. On receiving an all-addresses 900 flooded flush positive Update from a Pull Directory server it has 901 used, indicated by the F and P bits being one and the Count being 902 zero, a TRILL switch discards all cached data responses it has for 903 that Data Label. Similarly, on receiving an all addresses flush 904 negative Update, indicated by the F and N bits being one and the 905 Count being zero, it discards all cached negative replies for that 906 Data Label. A combined flush positive and negative can be flooded by 907 having all of the F, P, and N bits set to one resulting in the 908 discard of all positive and negative cached information for the Data 909 Label. 911 If method 2 is being followed, then a TRILL switch floods address 912 specific positive Update messages when data that might be cached by a 913 querying TRILL switch is changed or deleted and floods address 914 specific negative Update messages when such information is added to. 915 Such messages are similar to the method 1 flooded flush Update 916 messages and are also sent as RBridge Channel messages with an 917 Inner.MacDA of All-Egress-RBridges. However the Count field will be 918 non-zero and either the P or N bit, but not both, will be one. On 919 receiving such as address specific unsolicited update, if it is 920 positive the addresses in the RESPONSE records in the unsolicited 921 response are compared to the addresses about which the receiving 922 TRILL switch is holding cached positive information from that server 923 and, if they match, the cached information is updated. On receiving 924 an address specific unsolicited update negative message, the 925 addresses in the RESPONSE records in the unsolicited update are 926 compared to the addresses about which the receiving TRILL switch is 927 holding cached negative information from that server and, if they 928 match, the cached negative information is updated. 930 If method 3 is being followed, the same sort of unsolicited update 931 messages are sent as with method 2 above except they are not normally 932 flooded but unicast only to the specific TRILL switches the directory 933 server believes may be holding the cached positive or negative 934 information that needs updating. However, a Pull Directory server MAY 935 flood the unsolicited update under method 3, for example if it 936 determines that a sufficiently large fraction of the TRILL switches 937 in some Data label are requesters that need to be updated. 939 A Pull Directory server tracking cached information with method 3 940 MUST NOT clear the indication that it needs update cached information 941 at a querying TRILL switch until it has sent an Update message and 942 received a corresponding Acknowledge message or it has sent a 943 configurable number of updates at a configurable interval which 944 default to 3 updates 200 milliseconds apart. 946 A Pull Directory server tracking cached information with methods 2 or 947 1 SHOULD NOT clear the indication that it needs to update cached 948 information until it has sent an Update message and received a 949 corresponding Acknowledge message from all of its ESADI neighbors or 950 it has sent a configurable number of updates at a configurable 951 interval that defaults to 3 updates 200 milliseconds apart. 953 3.3.1 Update Message Format 955 An Update message is formatted as a Response message except that the 956 Type field in the message header is a different value. 958 Update messages are initiated by a Pull Directory server. The 959 Sequence number space used is controlled by the originating Pull 960 Directory server and different from Sequence number space used in a 961 Query and the corresponding Response that are controlled by the 962 querying TRILL switch. 964 The Flags field of the message header for an Update message is as 965 follows: 967 +---+---+---+---+ 968 | F | P | N | R | 969 +---+---+---+---+ 971 F: The Flood bit. If zero, the response is to be unicast . If F=1, it 972 is multicast to All-Egress-RBridges. 974 P, N: Flags used to indicate positive or negative Update messages. 975 P=1 indicates positive. N=1 indicates negative. Both may be 1 for 976 a flooded all addresses Update. 978 R: Reserved. MUST be sent as zero and ignored on receipt 980 3.3.2 Acknowledge Message Format 982 An Acknowledge message is sent in response to an Update to confirm 983 receipt or indicate an error unless response is inhibited by rate 984 limiting. It is also formatted as a Response message. 986 If there are no errors in the processing of an Update message, the 987 message is essentially echoed back with the Type changed to 988 Acknowledge. 990 If there was an overall or header error in an Update message, it is 991 echoed back as an Acknowledge message with the Err and SubErr fields 992 set appropriately (see Section 3.5). 994 If there is a RESPONSE Record level error in an Update message, one 995 or more Acknowledge messages may be returns as indicated in Section 996 3.5. 998 3.4 Pull Directory Hosted on an End Station 1000 Optionally, a Pull Directory actually hosted on an end station MAY be 1001 supported. In that case, one or more TRILL switches must proxy for 1002 the end station and advertise themselves as a Pull Directory server. 1003 Such proxies must have a direct connection to the end station, that 1004 is a connection not involving any intermediate TRILL switches. 1006 When the proxy TRILL switch receives a Query message, it modifies the 1007 inter-RBridge Channel message received into a native RBridge Channel 1008 message and forwards it to that end station. Later, when it receives 1009 one or more responses from that end station by native RBridge Channel 1010 messages, it modifies them into inter-RBridge Channel messages and 1011 forwards them to the source TRILL switch of the original Query 1012 message. Similarly, an Update from the end station is forwarded to 1013 client TRILL switches and acknowledgements from those TRILL switches 1014 are returned to the end station by the proxy. Because native RBridge 1015 Channel messages have no TRILL Header and are addressed by MAC 1016 address, as opposed to inter-RBridge Channel messages that are TRILL 1017 Data packets and are addressed by nickname, nickname information must 1018 be added to the native RBridge Channel version of Pull Directory 1019 messages. 1021 The native Pull Directory RBridge Channel messages use the same 1022 Channel protocol number as do the inter-RBridge Pull Directory 1023 RBridge Channel messages. The native messages SHOULD be sent with an 1024 Outer.VLAN tag which gives the priority of each message which is the 1025 priority of the original inter-RBridge request packet. The Outer.VLAN 1026 ID used is the Designated VLAN on the link to the end station. Since 1027 there is no TRILL Header or inner Data Label for native RBridge 1028 Chanel messages, that information is added to the header. 1030 The native RBridge Channel message Pull Directory message protocol 1031 dependent data part is the same as for inter-RBridge Channel messages 1032 except that the 8-byte header described in Section 3.1 is expanded to 1033 14 or 18 bytes as follows: 1035 0 1 2 3 1036 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 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Ver | Type | Flags | Count | Err | SubErr | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Sequence Number | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Nickname (2 bytes) | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1044 | Data Label ... (4 or 8 bytes) | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ 1046 | Type Specific Payload - variable length 1047 +-+-+- ... 1049 Fields not described below are as in Section 3.1. 1051 Data Label: The Data Label that normally appear right after the 1052 Inner.MacSA of the an RBridge Channel Pull Directory message 1053 appears here in the native RBridge Channel message version. 1054 This might appear in a Query message, to be reflected in a 1055 Response message, or it might appear in an Update message, to 1056 be reflected in an Acknowledge message. 1058 Nickname: The nickname of the TRILL switch that is communicating 1059 with the end station Pull Directory. Usually this is a remote 1060 TRILL switch but it could be the TRILL switch to which the end 1061 station is attached. The proxy copies this from the ingress 1062 nickname when mapping a Query or Acknowledge message to native 1063 form. It also takes this from a native Response or Update to be 1064 used as the egress of the inter-RBridge form on the message 1065 unless it is a flooded Update in which case a distribution tree 1066 is used. 1068 3.5 Pull Directory Message Errors 1070 A non-zero Err field in the Pull Directory message header indicates 1071 an error message. 1073 If there is an error that applies to an entire Query message or its 1074 header, as indicated by the range of the value of the Err field, then 1075 the QUERY records in the request are just echoed back in the RESPONSE 1076 records of the Response message but expanded with a zero Lifetime and 1077 the insertion of the Index field. If there is an error that applies 1078 to an entire Update message or its header, then the RESPONSE records 1079 in the update, if any, are echoed back in the Acknowledge message. 1081 If errors occur at the QUERY Record level for a Query message, they 1082 MUST be reported in a Response message separate from the results of 1083 any successful non-erroneous QUERY Records. If multiple QUERY Records 1084 in a Query message have different errors, they MUST be reported in 1085 separate Response messages. If multiple QUERY Records in a Query 1086 message have the same error, this error response MAY be reported in 1087 one or multiple Response messages. In an error Response message, the 1088 QUERY Record or records being responded to appear, expanded by the 1089 Lifetime for which the server thinks the error might persist and with 1090 their Index inserted, as the RESPONSE record or records. 1092 If errors occur at the RESPONSE Record level for an Update message, 1093 they MUST be reported in a Acknowledge message separate from the 1094 acknowledgement of any non-erroneous RESPONSE Records. If multiple 1095 RESPONSE Records in an Update have different errors, they MUST be 1096 reported in separate Acknowledge messages. If multiple RESPONSE 1097 Records in an Update message have the same error, this error response 1098 MAY be reported in one or multiple Acknowledge messages. In an error 1099 Acknowledge message, the RESPONSE Record or records being responded 1100 to appear, expanded by the time for which the server thinks the error 1101 might persist and with their Index inserted, as a RESPONSE Record or 1102 records. 1104 ERR values 1 through 127 are available for encoding Request or Update 1105 message level errors. ERR values 128 through 254 are available for 1106 encoding QUERY or RESPONSE Record level errors. The SubErr field is 1107 available for providing more detail on errors. The meaning of a 1108 SubErr field value depends on the value of the Err field. 1110 Err Meaning 1111 --- ------- 1112 0 (no error) 1114 1 Unknown or reserved Query message field value 1115 2 Request data too short 1116 3 Unknown or reserved Update message field value 1117 4 Update data too short 1118 5-127 (Available for allocation by IETF Review) 1120 128 Unknown or reserved QUERY Record field value 1121 129 Address not found 1122 130 Unknown or reserved RESPONSE Record field value 1123 131-254 (Available for allocation by IETF Review) 1125 255 Reserved 1127 The following sub-errors are specified under error code 1 and 3: 1129 SubErr Field with Error 1130 ------ ---------------- 1131 0 Unspecified 1132 1 Unknown V field value 1133 2 Reserved T field value 1134 3 Zero sequence number in request 1135 4-254 (Available for allocation by Expert Review) 1136 255 Reserved 1138 The following sub-errors are specified under error code 128 and 130: 1140 SubErr Field with Error 1141 ------ ---------------- 1142 0 Unspecified 1143 1 Unknown AFN field value 1144 2 Unknown or Reserved TYPE field value 1145 3 Invalid or inconsistent SIZE field value 1146 4-254 (Available for allocation by Expert Review) 1147 255 Reserved 1149 More TBD 1151 3.6 Additional Pull Details 1153 If a TRILL switch notices that a Pull Directory server is no longer 1154 data reachable [RFC7180], it MUST promptly discard all pull responses 1155 it is retaining from that server as it can no longer receive cache 1156 consistency update messages from the server. 1158 Because a Pull Directory server may need to advertise interest in 1159 Data Labels even though it does not want to received end station data 1160 in those Data Labels, the No Data (NOD) flag bit is provided as 1161 specified in Section 6.3. For example, an RBridge hosting a Pull 1162 Directory may be a secondary directory that wants to receive its data 1163 from a primary Push Directory server but have no interest in 1164 receiving multicast traffic from end stations. 1166 4. Directory Use Strategies and Push-Pull Hybrids 1168 For some edge nodes that have a great number of Data Labels enabled, 1169 managing the MAC and Data Label <-> Edge RBridge mapping for hosts 1170 under all those Data Labels can be a challenge. This is especially 1171 true for Data Center gateway nodes, which need to communicate with a 1172 majority of Data Labels, if not all. 1174 For those edge TRILL switch nodes, a hybrid model should be 1175 considered. That is the Push Model is used for some Data Labels, and 1176 the Pull Model is used for other Data Labels. It is the network 1177 operator's decision by configuration as to which Data Labels' mapping 1178 entries are pushed down from directories and which Data Labels' 1179 mapping entries are pulled. 1181 For example, assume a data center where hosts in specific Data 1182 Labels, say VLANs 1 through 100, communicate regularly with external 1183 peers. Probably, the mapping entries for those 100 VLANs should be 1184 pushed down to the data center gateway routers. For hosts in other 1185 Data Labels which only communicate with external peers occasionally 1186 for management interface, the mapping entries for those VLANs should 1187 be pulled down from directory when the need comes up. 1189 The mechanisms described above for Push and Pull Directory services 1190 make it easy to use Push for some Data Labels and Pull for others. In 1191 fact, different TRILL switches can even be configured so that some 1192 use Push Directory services and some use Pull Directory services for 1193 the same Data Label if both Push and Pull Directory services are 1194 available for that Data Label. And there can be Data Labels for which 1195 directory services are not used at all. 1197 For Data Labels in which a hybrid push/pull approach is being taken, 1198 it would make sense to use push for address information of hosts that 1199 frequently communicate with many other hosts in the Data Label, such 1200 as a file or DNS server. Pull could then be used for hosts that 1201 communicate with few other hosts, perhaps such as hosts being used as 1202 compute engines. 1204 4.1 Strategy Configuration 1206 Each TRILL switch that has the ability to use directory assistance 1207 has, for each Data Label X in which it is might ingress native 1208 frames, one of four major modes: 1210 0. No directory use: The TRILL switch does not subscribe to Push 1211 Directory data or make Pull Directory requests for Data Label X 1212 and directory data is not consulted on ingressed frames in Data 1213 Label X that might have used directory data. This includes ARP, 1214 ND, RARP, and unknown MAC destination addresses, which are 1215 flooded as appropriate. 1217 1. Use Push only: The TRILL switch subscribes to Push Directory 1218 data for Data Label X. 1220 2. Use Pull only: When the TRILL switch ingresses a frame in Data 1221 Label X that can use Directory information, if it has cached 1222 information for the address it uses it. If it does not have 1223 either cached positive or negative information for the address, 1224 it sends a Pull Directory query. 1226 3. Use Push and Pull: The TRILL switch subscribes to Push 1227 Directory data for Data Label X. When it ingresses a frame in 1228 Data Label X that can use Directory information and it does not 1229 find that information in its link state database of Push 1230 Directory information, it makes a Pull Directory query. 1232 The above major Directory use mode is per Data Label. In addition, 1233 there is a per Data Label per priority minor mode as listed below 1234 that indicates what should be done if Directory Data is not available 1235 for the ingressed frame. In all cases, if you are holding Push 1236 Directory or Pull Directory information to handle the frame given the 1237 major mode, the directory information is simply used and, in that 1238 instance, the minor mode does not matter. 1240 A. Flood immediate: Flood the frame immediately (even if you are 1241 also sending a Pull Directory) request. 1243 B. Flood: Flood the frame immediately unless you are going to do a 1244 Pull Directory request, in which case you wait for the response 1245 or for the request to time out after retries and flood the 1246 frame if the request times out. 1248 C. Discard if complete or Flood immediate: If you have complete 1249 Push Directory information and the address is not in that 1250 information, discard the frame. If you do not have complete 1251 Push Directory information, the same as A above. 1253 D. Discard if complete or Flood: If you have complete Push 1254 Directory information and the address is not in that 1255 information, discard the frame. If you do not have complete 1256 Push Directory information, the same as B above. 1258 In addition, the query message priority for Pull Directory requests 1259 sent can be configured on a per Data Label, per ingressed frame 1260 priority basis. The default mappings are as follows where Ingress 1261 Priority is the priority of the native frame that provoked the Pull 1262 Directory query: 1264 Ingress If Flood If Flood 1265 Priority Immediate Delayed 1266 -------- --------- -------- 1267 7 5 6 1268 6 5 6 1269 5 4 5 1270 4 3 4 1271 3 2 3 1272 2 0 2 1273 0 1 0 1274 1 1 1 1276 Priority 7 is normally only used for urgent messages critical to 1277 adjacency and so is avoided by default for directory traffic. 1278 Unsolicited updates are sent with a priority that is configured per 1279 Data Label that defaults to priority 5. 1281 5. Security Considerations 1283 Incorrect directory information can result in a variety of security 1284 threats including the following: 1286 Incorrect directory mappings can result in data being delivered to 1287 the wrong end stations, or set of end stations in the case of 1288 multi-destination packets, violation security policy. 1290 Missing or incorrect directory data can result in denial of 1291 service due to sending data packets to black holes or discarding 1292 data on ingress due to incorrect information that their 1293 destinations are not reachable. 1295 Push Directory data is distributed through ESADI-LSPs [RFC7357] that 1296 can be authenticated with the same mechanisms as IS-IS LSPs. See 1297 [RFC5304] [RFC5310] and the Security Considerations section of 1298 [RFC7357]. 1300 Pull Directory queries and responses are transmitted as RBridge-to- 1301 RBridge or native RBridge Channel messages. Such messages can be 1302 secured as specified in [ChannelTunnel]. 1304 For general TRILL security considerations, see [RFC6325]. 1306 6. IANA Considerations 1308 This section gives IANA assignment and registry considerations. 1310 6.1 ESADI-Parameter Data Extensions 1312 IANA will assigned two ESADI-Parameter TRILL APPsub-TLV flag bits for 1313 "Push Directory" (PSH) and "Complete Push" (COP) and will create a 1314 sub-registry in the TRILL Parameters Registry as follows: 1316 Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits 1318 Registration Procedures: Standards Action 1320 References: [RFC7357] [This document] 1322 Bit Mnemonic Description Reference 1323 --- -------- ----------- --------- 1324 0 UN Supports Unicast ESADI ESDADI [RFC7357] 1325 1 PSH Push Directory Server This document 1326 2 COP Complete Push This document 1327 3-7 - available for allocation 1329 The COP bit is ignored if the PSH bit is zero. 1331 In addition, the ESADI-Parameter APPsub-TLV is optionally extended, 1332 as provided in its original specification in ESDADI [RFC7357], by one 1333 byte as show below: 1335 +-+-+-+-+-+-+-+-+ 1336 | Type | (1 byte) 1337 +-+-+-+-+-+-+-+-+ 1338 | Length | (1 byte) 1339 +-+-+-+-+-+-+-+-+ 1340 |R| Priority | (1 byte) 1341 +-+-+-+-+-+-+-+-+ 1342 | CSNP Time | (1 byte) 1343 +-+-+-+-+-+-+-+-+ 1344 | Flags | (1 byte) 1345 +---------------+ 1346 |PushDirPriority| (optional, 1 byte) 1347 +---------------+ 1348 | Reserved for expansion (variable) 1349 +-+-+-+-... 1351 The meanings of all the fields are as specified in ESDADI [RFC7357] 1352 except that the added PushDirPriority is the priority of the 1353 advertising ESADI instance to be a Push Directory as described in 1354 Section 2.3. If the PushDirPriority field is not present (Length = 3) 1355 it is treated as if it were 0x40. 0x40 is also the value used and 1356 placed here by an TRILL switch whose priority to be a Push Directory 1357 has not been configured. 1359 6.2 RBridge Channel Protocol Number 1361 IANA will allocate a new RBridge Channel protocol number for "Pull 1362 Directory Services" from the range allocable by Standards Action and 1363 update the subregistry of such protocol number in the TRILL 1364 Parameters Registry referencing this document. 1366 6.3 The Pull Directory (PUL) and No Data (NOD) Bits 1368 IANA is requested to allocate two currently reserved bits in the 1369 Interested VLANs field of the Interested VLANs sub-TLV (suggested 1370 bits 18 and 19) and the Interested Labels field of the Interested 1371 Labels sub-TLV (suggested bits 6 and 7) [RFC7176] to indicate Pull 1372 Directory server (PUL) and No Data (NOD) respectively. These bits are 1373 to be added, with this document as reference, to the "Interested 1374 VLANs Flag Bits" and "Interested Labels Flag Bits" subregistries 1375 created by [RFC7357]. 1377 {{Material below in this subsection is technical and should be moved 1378 out of the IANA Consdierations.}} 1380 In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], 1381 the mere presence of an Interested VLANs or Interested Labels sub- 1382 TLVs in the LSP of a TRILL switch indicates connection to end 1383 stations in the VLAN(s) or FGL(s) listed and thus a desire to receive 1384 multi-destination traffic in those Data Labels. But, with Push and 1385 Pull Directories, advertising that you are a directory server 1386 requires using these sub-TLVs to indicate the Data Label(s) you are 1387 serving. If such a directory server does not wish to received multi- 1388 destination TRILL Data packets for the Data Labels it lists in one of 1389 these sub-TLVs, it sets the "No Data" (NOD) bit to one. This means 1390 that data on a distribution tree may be pruned so as not to reach the 1391 "No Data" TRILL switch as long as there are no TRILL switches 1392 interested in the Data that are beyond the "No Data" TRILL switch on 1393 a distribution tree. The NOD bit is backwards compatible as TRILL 1394 switches ignorant of it will simply not prune when they could, which 1395 is safe although it may cause increased link utilization. 1397 Example of a TRILL switch serving as a directory that might not want 1398 multi-destination traffic in some Data Labels would be a TRILL switch 1399 that does not offer end station service for any of the Data Labels 1400 for which it is serving as a directory and is either 1401 - a Pull Directory and/or 1402 - a Push Directory for which all of the ESADI traffic will be 1403 handled by unicast ESDADI [RFC7357]. 1405 A Push Directory MUST NOT set the NOD bit for a data label if it 1406 needs to communicate via multi-destination ESADI PDUs in that data 1407 label since such PDUs look like TRILL Data packets to transit TRILL 1408 switches and might be incorrectly pruned if NOD was set. 1410 Acknowledgments 1412 The contributions of the following persons are gratefully 1413 acknowledged: 1415 TBD 1417 The document was prepared in raw nroff. All macros used were defined 1418 within the source file. 1420 Normative References 1422 [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol", 1423 RFC 826, November 1982. 1425 [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 1426 Reverse Address Resolution Protocol", STD 38, RFC 903, June 1427 1984 1429 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 1430 Requirement Levels", BCP 14, RFC 2119, March 1997 1432 [RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1433 "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 1435 [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1436 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1437 September 2007. 1439 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 1440 Authentication", RFC 5304, October 2008. 1442 [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 1443 and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 1444 5310, February 2009. 1446 [RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for 1447 Layer-2 Systems", RFC 6165, April 2011. 1449 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 1450 Ghanwani, "Routing Bridges (RBridges): Base Protocol 1451 Specification", RFC 6325, July 2011. 1453 [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 1454 IETF Protocol and Documentation Usage for IEEE 802 Parameters", 1455 BCP 141, RFC 7042, October 2013. 1457 [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., 1458 and D. Dutt, "Transparent Interconnection of Lots of Links 1459 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, 1460 . 1462 [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, 1463 D., and A. Banerjee, "Transparent Interconnection of Lots of 1464 Links (TRILL) Use of IS-IS", RFC 7176, May 2014, 1465 . 1467 [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. 1468 Ward, "Transparent Interconnection of Lots of Links (TRILL): 1469 RBridge Channel Support", RFC 7178, May 2014, . 1472 [RFC7180] - Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., 1473 and A. Banerjee, "Transparent Interconnection of Lots of Links 1474 (TRILL): Clarifications, Corrections, and Updates", RFC 7180, 1475 May 2014, . 1477 [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. 1478 Stokes, "Transparent Interconnection of Lots of Links (TRILL): 1479 End Station Address Distribution Information (ESADI) Protocol", 1480 RFC 7357, September 2014, . 1483 [IA] - Eastlake, D., L. Yizhou, R. Perlman, "TRILL: Interface 1484 Addresses APPsub-TLV", draft-eastlake-trill-ia-appsubtlv, work 1485 in progress. 1487 Informational References 1489 [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. 1490 Gashinsky, "Directory Assistance Problem and High-Level Design 1491 Proposal", RFC 7067, November 2013. 1493 [ChannelTunnel] - D. Eastlake, Y. Li, "TRILL: RBridge Channel Tunnel 1494 Protocol", draft-eastlake-trill-channel-tunnel, work in 1495 progress. 1497 [ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large 1498 Data Centers", Oct 2010. 1500 Authors' Addresses 1502 Linda Dunbar 1503 Huawei Technologies 1504 5430 Legacy Drive, Suite #175 1505 Plano, TX 75024, USA 1507 Phone: +1-469-277-5840 1508 Email: ldunbar@huawei.com 1510 Donald Eastlake 1511 Huawei Technologies 1512 155 Beaver Street 1513 Milford, MA 01757 USA 1515 Phone: +1-508-333-2270 1516 Email: d3e3e3@gmail.com 1518 Radia Perlman 1519 EMC 1520 2010 256th Avenue NE, #200 1521 Bellevue, WA 98007 USA 1523 Email: Radia@alum.mit.edu 1525 Igor Gashinsky 1526 Yahoo 1527 45 West 18th Street 6th floor 1528 New York, NY 10011 1530 Email: igor@yahoo-inc.com 1532 Yizhou Li 1533 Huawei Technologies 1534 101 Software Avenue, 1535 Nanjing 210012 China 1537 Phone: +86-25-56622310 1538 Email: liyizhou@huawei.com 1540 Copyright, Disclaimer, and Additional IPR Provisions 1542 Copyright (c) 2014 IETF Trust and the persons identified as the 1543 document authors. All rights reserved. 1545 This document is subject to BCP 78 and the IETF Trust's Legal 1546 Provisions Relating to IETF Documents 1547 (http://trustee.ietf.org/license-info) in effect on the date of 1548 publication of this document. Please review these documents 1549 carefully, as they describe your rights and restrictions with respect 1550 to this document. Code Components extracted from this document must 1551 include Simplified BSD License text as described in Section 4.e of 1552 the Trust Legal Provisions and are provided without warranty as 1553 described in the Simplified BSD License. The definitive version of 1554 an IETF Document is that published by, or under the auspices of, the 1555 IETF. Versions of IETF Documents that are published by third parties, 1556 including those that are translated into other languages, should not 1557 be considered to be definitive versions of IETF Documents. The 1558 definitive version of these Legal Provisions is that published by, or 1559 under the auspices of, the IETF. Versions of these Legal Provisions 1560 that are published by third parties, including those that are 1561 translated into other languages, should not be considered to be 1562 definitive versions of these Legal Provisions. For the avoidance of 1563 doubt, each Contributor to the IETF Standards Process licenses each 1564 Contribution that he or she makes as part of the IETF Standards 1565 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 1566 language to the contrary, or terms, conditions or rights that differ 1567 from or are inconsistent with the rights and licenses granted under 1568 RFC 5378, shall have any effect and shall be null and void, whether 1569 published or posted by such Contributor, or included with or in such 1570 Contribution.