RFC 8171
Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
Pages: 55
Proposed Standard
Proposed Standard
Part 2 of 3 – Pages 17 to 42
3. Pull Model Directory Assistance Mechanisms
In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory information from an appropriate directory server when needed. A TRILL switch that makes use of Pull Directory services must implement appropriate connections between its directory utilization and its link-state database and link-state updating. For example, Pull Directory servers for a particular Data Label X are found by looking in the core TRILL IS-IS link-state database for data-reachable [RFC7780] TRILL switches that advertise themselves by setting the Pull Directory flag (PUL) to 1 in their Interested VLANs sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data Label. The set of such switches can change with configuration changes by network management, such as the following: o the startup or shutdown of Pull Directory servers
o changes in network topology, such as the connection or
disconnection of TRILL switches that are Pull Directory servers
o network partition or merger
As described in Section 3.7, a TRILL switch MUST be able to detect
that a Pull Directory from which it has cached data is no longer
data reachable so that it can discard such cached data.
If multiple data-reachable TRILL switches indicate in the link-state
database that they are Pull Directory servers for a particular Data
Label, pull requests can be sent to any one or more of them, but it
is RECOMMENDED that pull requests be preferentially sent to the
server or servers that are lowest cost from the requesting TRILL
switch.
Pull Directory requests are sent by encapsulating them in an RBridge
Channel [RFC7178] message using the Pull Directory channel protocol
number (see Section 7.2). Responses are returned in an RBridge
Channel message using the same channel protocol number. See
Section 3.2 for Query and Response Message formats. For cache
consistency or notification purposes, Pull Directory servers, under
certain conditions, MUST send unsolicited Update Messages to client
TRILL switches they believe may be holding old data. Those clients
can acknowledge such updates, as described in Section 3.3. All these
messages have a common header, as described in Section 3.1. Errors
are returned as described in Section 3.6.
The requests to Pull Directory servers are typically derived from
ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or SEND
[RFC3971] messages, or data frames with unknown unicast destination
MAC addresses, intercepted by an ingress TRILL switch, as described
in Section 1.1.
Pull Directory responses include an amount of time for which the
response should be considered valid. This includes negative
responses that indicate that no data is available. It is RECOMMENDED
that both positive responses with data and negative responses be
cached and used to locally handle ARP, ND, RARP, unknown destination
MAC frames, or the like [ARPND], until the responses expire. If
information previously pulled is about to expire, a TRILL switch MAY
try to refresh it by issuing a new pull request but, to avoid
unnecessary requests, SHOULD NOT do so unless it has been recently
used. The validity timer of cached Pull Directory responses is NOT
reset or extended merely because that cache entry is used.
3.1. Pull Directory Message: Common Format
All Pull Directory messages are transmitted as the Channel Protocol-specific payload of RBridge Channel messages [RFC7178]. Pull Directory messages are formatted as described herein, starting with the following common 8-byte header: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Flags | Count | Err | SubErr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Specific Payload - variable length +-+-+- ... Ver: Version of the Pull Directory protocol. An unsigned integer. Version 0 (zero) is specified in this document. See Section 3.1.1 for a discussion of version negotiation. Type: The Pull Directory message type, as follows: Type Section Name ---- ------- ------------ 0 - Reserved 1 3.2.1 Query 2 3.2.2 Response 3 3.3.1 Update 4 3.3.2 Acknowledge 5-14 - Unassigned 15 - Reserved Flags: Four flag bits whose meaning depends on the Pull Directory message type. Flags whose meanings are not specified are reserved, MUST be sent as zero, and MUST be ignored on receipt. Count: Some Pull Directory message types specified herein have zero or more occurrences of a Record as part of the type-specific payload. The Count field is the number of occurrences of that Record and is expressed as an unsigned integer. For any Pull Directory messages not structured with such occurrences, this field MUST be sent as zero and ignored on receipt.
Err, SubErr: A two-part error code. These fields are only used in
Reply Messages. In messages that are requests or updates,
these fields MUST be sent as zero and ignored on receipt. An
Err field containing the value zero means no error. The
meaning of values in the SubErr field depends on the value of
the Err field, but in all cases, a zero SubErr field is allowed
and provides no additional information beyond the value of the
Err field.
Sequence Number: An identifying 32-bit quantity set by the TRILL
switch sending a request or other unsolicited message and
returned in every corresponding reply or acknowledgment. It is
used to match up responses with the message to which they
respond.
Type Specific Payload: Format depends on the Pull Directory
message type.
3.1.1. Version Negotiation
The version number (Ver) in the Pull Directory message header is
incremented for a future version with changes such that TRILL
directory messages cannot be parsed correctly by an earlier version.
Ver is not incremented for minor changes such as defining a new field
value for an existing field.
Pull Directory messages come in pairs (Request-Response,
Update-Acknowledgment). The version number in the Request/Update
(Ver1) indicates the format of that message and the format of the
corresponding returned Response/Acknowledgment. The version number
in the returned Response/Acknowledgment (Ver2) indicates the highest
version number that the sender of that Response/Acknowledgment
understands.
In the most common case -- a well-configured network -- Ver1 and Ver2
will be equal.
If Ver2 is less than Ver1, the returned Response/Acknowledgment will
be an error message saying that the version is not understood.
If Ver2 is greater than Ver1 and the responder understands Ver1, it
responds normally in Ver1 format. However, if the responder does not
understand Ver1, it MUST send a "Version not understood" error
message (Section 3.6.2) correctly formatted for Ver1. Thus, all
implementations that support some version X MUST be able to send a
Version not understood error message correctly formatted for all
lower versions down to version 0.
3.2. Pull Directory Query and Response Messages
The formats of Pull Directory Query Messages and Pull Directory Response Messages are specified in Sections 3.2.1 and 3.2.2.1, respectively.3.2.1. Pull Directory Query Message Format
A Pull Directory Query Message is sent as the Channel Protocol-specific content of an RBridge Channel message [RFC7178] TRILL Data packet or as a native RBridge Channel data frame (see Section 3.5). The Data Label of the packet is the Data Label in which the query is being made. The priority of the RBridge Channel message is a mapping of the priority of the ingressed frame that caused the query. The default mapping depends, per Data Label, on the strategy (see Section 4) or a configured priority (see "DirGenQPriority" in Section 3.9) for generated queries. (Generated queries are those queries that are not the result of a mapping -- for example, a query to refresh a cache entry.) The Channel Protocol-specific data is formatted as a header and a sequence of zero or more QUERY Records as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Flags | Count | Err | SubErr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QUERY 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | QUERY 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... | QUERY K +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Ver, Sequence Number: See Section 3.1. Type: 1 for Query. Queries received by a TRILL switch that is not a Pull Directory for the relevant Data Label result in an error response (see Section 3.6) unless inhibited by rate limiting. (See [RFC7178] for information on the Response Message that is generated if the recipient implements the RBridge Channel features but does not implement the Pull Directory RBridge Channel Protocol.)
Flags, Err, and SubErr: MUST be sent as zero and ignored on
receipt.
Count: Count is the number of QUERY Records present. A
Query Message Count of 0 is explicitly allowed, for the purpose
of pinging a Pull Directory server to see if it is responding.
On receipt of such an empty Query Message, a Response Message
that also has a Count of 0 is returned unless inhibited by rate
limiting.
QUERY: Each QUERY Record within a Pull Directory Query Message is
formatted as follows:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |FR| RESV | QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
If QTYPE = 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| AFN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Address ...
+--+--+--+--+--+--+--+--+--+--+--...
If QTYPE = 2 or 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Frame ...
+--+--+--+--+--+--+--+--+--+--+--...
SIZE: Size of the QUERY Record in bytes, expressed as an
unsigned integer and not including the SIZE field and
following byte. A value of SIZE so large that the material
doesn't fit in the Query Message indicates a malformed
QUERY Record. A QUERY Record with such an illegal SIZE
value, and any subsequent QUERY Records, MUST be ignored,
and the entire Query Message MAY be ignored.
FR: The Flood Record flag. Ignored if QTYPE is 1. If QTYPE is
2 or 5 and the directory information sought is not found,
the frame provided is flooded; otherwise, it is not
forwarded. See Section 3.2.2.2. For QTYPEs other than 2 or
5, the FR flag has no effect.
RESV: A block of three reserved bits. MUST be sent as zero and
ignored on receipt.
QTYPE: There are several types of QUERY Records currently
defined in two classes, as follows: (1) a QUERY Record that
provides an explicit address and asks for all addresses for
the interface specified by the Query Address and (2) a
QUERY Record that includes a frame. The fields of each are
specified below. Values of QTYPE are as follows:
QTYPE Description
----- -------------------------------
0 Reserved
1 Address query
2 Frame query
3-4 Unassigned
5 Unknown unicast MAC Query Frame
6-14 Unassigned
15 Reserved
AFN: Address Family Number of the Query Address.
Query Address: The query is asking for any other addresses, and
the nickname of the TRILL switch from which they are
reachable, that correspond to the same interface as this
address, within the Data Label of the query of the address
provided. A typical Query Address would be something like
the following:
1. A 48-bit MAC address, with the querying TRILL switch
primarily interested in either
a. the RBridge by which that MAC address is reachable, so
that the querying RBridge can forward an unknown
(before the query) destination MAC address native
frame as a unicast TRILL Data packet rather than
flooding it, or
b. the IP address corresponding to the MAC address, so
that the RBridge can locally respond to a RARP
[RFC903] native frame.
2. An IPv4 or IPv6 address, with the querying RBridge
interested in the corresponding MAC address so it can
locally respond to an ARP [RFC826] or ND [RFC4861] native
frame [ARPND].
But the Query Address could be some other address type for
which an AFN has been assigned, such as a 64-bit MAC address
[RFC7042] or a CLNS (connectionless-mode network service)
[X.233] address.
Query Frame: Where a QUERY Record is the result of an ARP, ND,
RARP, SEND, or unknown unicast MAC destination address, the
ingress TRILL switch MAY send the frame to a Pull Directory
server if the frame is small enough that the resulting Query
Message fits into a TRILL Data packet within the campus MTU.
The full frame is included, starting with the destination
and source MAC addresses, but does not include the Frame
Check Sequence (FCS).
If no response to a Pull Directory Query Message is received within a
configurable timeout (see "DirQueryTimeout" in Section 3.9), then the
Query Message should be retransmitted with the same Sequence Number
(up to a configurable number of times (see "DirQueryRetries" in
Section 3.9)). If there are multiple QUERY Records in a
Query Message, responses to various subsets of these QUERY Records
can be received before the timeout. In that case, the remaining
unanswered QUERY Records should be resent in a new Query Message with
a new Sequence Number. If a TRILL switch is not capable of handling
partial responses to queries with multiple QUERY Records, it MUST NOT
send a Request Message with more than one QUERY Record in it.
See Section 3.6 for a discussion of how Query Message errors are
handled.
3.2.2. Pull Directory Responses
A Pull Directory Query Message results in a Pull Directory Response
Message as described in Section 3.2.2.1.
In addition, if the QUERY Record QTYPE was 2 or 5, the frame included
in the Query may be modified and forwarded by the Pull Directory
server as described in Section 3.2.2.2.
3.2.2.1. Pull Directory Response Message Format
Pull Directory Response Messages are sent as the
Channel Protocol-specific content of an RBridge Channel message
[RFC7178] TRILL Data packet or as a native RBridge Channel data frame
(see Section 3.5). Responses are sent with the same Data Label and
priority as the Query Message to which they correspond, except that
the Response Message priority is limited to be no more than the
configured value DirRespMaxPriority (Section 3.9).
The RBridge Channel Protocol-specific data format is as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESPONSE 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Ver, Sequence Number: As specified in Section 3.1.
Type: 2 = Response.
Flags: MUST be sent as zero and ignored on receipt.
Count: Count is the number of RESPONSE Records present in the
Response Message.
Err, SubErr: A two-part error code. Zero, unless there was an
error in the Query Message (in which case, see Section 3.6).
RESPONSE: Each RESPONSE Record within a Pull Directory Response
Message is formatted as follows:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |OV| RESV | Index |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Lifetime |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Response Data ...
+--+--+--+--+--+--+--+--+--+--+--...
SIZE: The size of the RESPONSE Record is an unsigned integer
number of bytes, not including the SIZE field and following
byte. A value of SIZE so large that the material doesn't
fit in the Query Message indicates a malformed
RESPONSE Record. A RESPONSE Record with such an excessive
SIZE value, and any subsequent RESPONSE Records, MUST be
ignored, and the entire Response Message MAY be ignored.
OV: The overflow flag. Indicates, as described below, that
there was too much Response Data to include in one Response
Message.
RESV: Three reserved bits that MUST be sent as zero and ignored
on receipt.
Index: The relative index of the QUERY Record in the Query
Message to which this RESPONSE Record corresponds. The
Index will always be 1 for Query Messages containing a
single QUERY Record. If the Index is larger than the Count
was in the corresponding Query, that RESPONSE Record MUST be
ignored, and subsequent RESPONSE Records or the entire
Response Message MAY be ignored.
Lifetime: The length of time, in units of 100 milliseconds,
for which the response should be considered valid, except
that the values zero and 2**16 - 1 are special. If zero,
the response can only be used for the particular query from
which it resulted and MUST NOT be cached. If 2**16 - 1, the
response MAY be kept indefinitely but not after the Pull
Directory server goes down or becomes unreachable. (The
maximum definite time that can be expressed is a little over
1.8 hours.)
Response Data: There are three types of RESPONSE Records:
- If the Err field of the encapsulating Response Message has a
message-level error code in it, then the RESPONSE Records
are omitted and Count will be 0. See Section 3.6 for
additional information on errors.
- If the Err field of the encapsulating Response Message has a
record-level error code in it, then the RESPONSE Records are
those having that error, as further described in
Section 3.6.
- If the Err field of the encapsulating Response Message is 0,
then the Response Data in each RESPONSE Record is formatted
as the value part of an Interface Addresses APPsub-TLV
[RFC7961]. The maximum size of such contents is 255 bytes,
in which case the RESPONSE Record SIZE field is 255.
Multiple RESPONSE Records can appear in a Response Message with the same Index if an answer to the QUERY Record consists of multiple Interface Addresses APPsub-TLV values. This would be necessary if, for example, a MAC address within a Data Label appears to be reachable by multiple TRILL switches. However, all RESPONSE Records to any particular QUERY Record MUST occur in the same Response Message. If a Pull Directory holds more mappings for a queried address than will fit into one Response Message, it selects which mappings to include, by some method outside the scope of this document, and sets the overflow flag (OV) in all of the RESPONSE Records responding to that Query Address. See Section 3.6 for a discussion of how errors are handled.3.2.2.2. Pull Directory Forwarding
Query Messages with QTYPEs 2 and 5 are interpreted and handled as described below. In these cases, if the information implicitly sought is not in the directory and the FR flag in the Query Message was 1 (one), the provided frame is forwarded by the Pull Directory server as a multi-destination TRILL Data packet with the ingress nickname of the Pull Directory server (or proxy, if it is hosted on an end station) in the TRILL Header. If the FR flag is 0, the frame is not forwarded in this case. If there was no error in the handling of the encapsulating Query Message, the Pull Directory server forwards the frame inside that QUERY Record, after modifying it in some cases, as described below: ARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates that an ARP [RFC826] frame is included in the Record: The ar$op field MUST be ares_op$REQUEST, and for the response described in Section 3.2.2.1, this is treated as a query for the target protocol address, where the AFN of that address is given by ar$pro. (ARP fields and value names with embedded dollar signs ("$") are specified in [RFC826].) If (1) ar$op is not ares_op$REQUEST, (2) the ARP is malformed, or (3) the query fails, an error is returned. Otherwise, the ARP is modified into the appropriate ARP response, which is then sent by the Pull Directory server as a TRILL Data packet. ND/SEND: When QTYPE is 2 and the Ethertype in the QUERY Record indicates that an IPv6 ND [RFC4861] or SEND [RFC3971] frame is included in the Record: Only Neighbor Solicitation ND frames (corresponding to an ARP query) are allowed. An error is returned for other ND frames or if the target address is not found. Otherwise, if the ND is not a
SEND, an ND Neighbor Advertisement response is returned by the
Pull Directory server as a TRILL Data packet. In the case of
SEND, an error is returned indicating that a SEND frame was
received by the Pull Directory, and the Pull Directory then either
(1) forwards the SEND frame to the holder of the IPv6 address if
that information is in the directory or (2) multicasts the
SEND frame.
RARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates
that a RARP [RFC903] frame is included in the Record:
If the ar$op field is ares_op$REQUEST, the frame is handled as an
ARP, as described above. Otherwise, the ar$op field MUST be
"reverse request", and for the response described in
Section 3.2.2.1, this is treated as a query for the target
hardware address, where the AFN of that address is given by
ar$hrd. (See [RFC826] for RARP fields.) If (1) ar$op is not one
of these values, (2) the RARP is malformed, or (3) the query
fails, an error is returned. Otherwise, the RARP is modified into
the appropriate RARP response, which is then unicast by the Pull
Directory server as a TRILL Data packet to the source hardware MAC
address.
MacDA: When QTYPE is 5, indicating that a frame is provided in the
QUERY Record whose destination MAC address TRILL switch attachment
is unknown, the only requirement is that this MAC address has to
be unicast. The Ethertype in the QUERY Record is ignored. If
this MAC address is a group address, an error is returned. In the
case of Pull Directory Response Messages (Section 3.2.2.1), this
MAC address is treated as a query for the MacDA. In the creation
of the response described in Section 3.2.2.1, the query is treated
as a query for this MAC address. If the Pull Directory contains
TRILL switch attachment information for the MAC address in the
Data Label of the Query Message, it forwards the frame to that
switch in a unicast TRILL Data packet.
3.3. Cache Consistency
Unless it sends all responses with a Lifetime of 0, a Pull Directory
MUST take action, by sending Update Messages, to minimize the amount
of time that a TRILL switch will continue to use stale information
from that Pull Directory. The formats of Update Messages and the
Acknowledge Messages used to respond to Update Messages are given in
Sections 3.3.1 and 3.3.2, respectively.
A Pull Directory server MUST maintain one of three sets of records
concerning possible cached data at clients of that server. These are
numbered and listed below in order of increasing specificity:
Method 1, Least Specific. An overall record, per Data Label, of when
the last positive Response Data sent will expire and when the last
negative response sent will expire; the records are retained until
such expiration.
Pro: Minimizes the record-keeping burden on the Pull Directory
server.
Con: Increases the volume of and overhead due to (1) spontaneous
Update Messages and (2) unnecessarily invalidating cached
information.
Method 2, Medium Specificity. For each unit of data (Interface
Addresses APPsub-TLV (IA APPsub-TLV) Address Set [RFC7961]) held
by the server, record when the last response sent with that
positive Response Data will expire. In addition, record each
address about which a negative response was sent by the server and
when the last such negative response will expire. Each such
record of a positive or negative response is discarded upon
expiration.
Pros/Cons: An intermediate level of detail in server
record-keeping; also, an intermediate volume of, and overhead
due to, spontaneous Update Messages with some unnecessary
invalidation of cached information.
Method 3, Most Specific. For each unit of data held by the server
(IA APPsub-TLV Address Set [RFC7961]) and each address about which
a negative response was sent, a list of TRILL switches that were
sent that data as a positive response or sent a negative response
for the address, and the expected time to expiration for that data
or address at each such TRILL switch, assuming that the requester
cached the response. Each list entry is retained until such
expiration time.
Pros: Minimizes spontaneous Update Messages sent to update pull
client TRILL switch caches, and minimizes unnecessary
invalidation of cached information.
Con: Increased record-keeping burden on the Pull Directory server.
RESPONSE Records sent with a zero Lifetime are considered to have already expired and so do not need to be tracked. In all cases, there may still be brief periods of time when directory information has changed, but information that a pull client has cached has not yet been updated or expunged. A Pull Directory server might have a limit as to (1) how many TRILL switches for which it can maintain detailed expiry information using method 3 or (2) how many data units or addresses for which it can maintain expiry information using method 2 or the like. If such limits are exceeded, it MUST transition to a lower-numbered method but, in all cases, MUST support, at a minimum, method 1 and SHOULD support methods 2 and 3. The use of method 1 may be quite inefficient, due to large amounts of cached positive and negative information being unnecessarily discarded. When data at a Pull Directory is changed, deleted, or added and there may be unexpired stale information at a requesting TRILL switch, the Pull Directory MUST send an Update Message as discussed below. The sending of such an Update Message MAY be delayed by a configurable number of milliseconds (see "DirUpdateDelay" in Section 3.9) to await other possible changes that could be included in the same Update Message. 1. If method 1, the least detailed method, is being followed, then when any Pull Directory information in a Data Label is changed or deleted and there are outstanding cached positive data response(s), an all-addresses flush positive data Update Message is flooded within that Data Label as an RBridge Channel message. If data is added and there are outstanding cached negative responses, an all-addresses flush negative message is similarly flooded. A Count field value of 0 in an Update Message indicates "all-addresses". On receiving an all-addresses flooded flush positive Update from a Pull Directory server it has used, indicated by the F (Flood) and P (Positive) bits being 1 and the Count being 0, a TRILL switch discards the cached data responses it has for that Data Label. Similarly, on receiving an all-addresses flush negative Update, indicated by the F and N (Negative) bits being 1 and the Count being 0, it discards all cached negative replies for that Data Label. A combined flush positive and negative can be flooded by having all of the F, P, and N bits (see Section 3.3.1) set to 1 and the Count field 0, resulting in the discard of all positive and negative cached information for the Data Label. 2. If method 2 is being followed, then a TRILL switch floods address-specific positive Update Messages when data that might be cached by a querying TRILL switch is changed or deleted and floods
address-specific negative Update Messages when data that might be
cached by a querying TRILL switch is added. Such messages are
sent as RBridge Channel messages. The F bit will be 1; however,
the Count field will be non-zero, and either the P bit or the
N bit, but not both, will be 1. There are actually four possible
message types that can be flooded:
a. If data that might still be cached is updated:
An unsolicited Update Message is sent with the P flag set and
the Err field 0. On receipt, the addresses in the RESPONSE
Records are compared to the addresses for which the receiving
TRILL switch is holding cached positive information from that
server. If they match, the cached information is updated.
b. If data that might still be cached is deleted:
An unsolicited Update Message is sent with the P flag set and
the Err field non-zero, giving the error that would now be
encountered in attempting to pull information for the relevant
address from the Pull Directory server. In this non-zero Err
field case, the RESPONSE Record(s) differs from non-zero Err
Reply Message RESPONSE Records in that they do include an
interface address set. Any cached positive information for the
addresses given is deleted, and the negative response is cached
as per the Lifetime given.
c. If data for an address for which a negative response was sent
is added, so that negative response that might still be cached
is now incorrect:
An unsolicited Update Message is sent with the N flag set to 1
and the Err field 0. The addresses in the RESPONSE Records are
compared to the addresses for which the receiving TRILL switch
is holding cached negative information from that server; if
they match, the cached negative information is deleted, and the
positive information provided is cached as per the Lifetime
given.
d. In the rare case where it is desired to change the Lifetime or
error associated with negative information that might still be
cached:
An unsolicited Update Message is sent with the N flag set to 1
and the Err field non-zero. As in case b above, the RESPONSE
Record(s) gives the relevant addresses. Any cached negative
information for the addresses is updated.
3. If method 3 is being followed, unsolicited Update Messages of the
same sort are sent as with method 2 above, except that they are
not normally flooded but unicast only to the specific TRILL
switches the directory server believes may be holding the cached
positive or negative information that needs deletion or updating.
However, a Pull Directory server MAY flood unsolicited updates
using method 3 -- for example, if it determines that a
sufficiently large fraction of the TRILL switches in some Data
Label are requesters that need to be updated so that flooding is
more efficient than unicast.
A Pull Directory server tracking cached information with method 3
MUST NOT clear the indication that it needs to update cached
information at a querying TRILL switch until it has either (a) sent
an Update Message and received a corresponding Acknowledge Message or
(b) sent a configurable number of updates at a configurable interval
where these parameters default to three updates 100 milliseconds
apart (see Section 3.9).
A Pull Directory server tracking cached information with method 1 or
method 2 SHOULD NOT clear the indication that it needs to update
cached information until it has sent an Update Message and received a
corresponding Acknowledge Message from all of its ESADI neighbors or
it has sent a number of updates at a configurable interval, as
specified in the paragraph above.
3.3.1. Update Message Format
An Update Message is formatted as a Response Message, with the
differences described in Section 3.3 above and the following:
o The Type field in the message header is set to 3.
o The Index field in the RESPONSE Record(s) is set to 0 on
transmission and ignored on receipt (but the Count field in the
Update Message header MUST still correctly indicate the number of
RESPONSE Records present).
o The priority with which the message is sent, DirUpdatePriority, is
configurable and defaults to 5 (see Section 3.9).
Update Messages are initiated by a Pull Directory server. The
Sequence Number space used is controlled by the originating Pull
Directory server. This Sequence Number space for Update Messages is
different from the Sequence Number space used in a Query and the
corresponding Response that are controlled by the querying
TRILL switch.
The 4-bit Flags field of the message header for an Update Message is
as follows:
+---+---+---+---+
| F | P | N | R |
+---+---+---+---+
F: The Flood bit. If F = 0, the Update Message is unicast. If
F = 1, it is multicast to All-Egress-RBridges.
P, N: Flags used to indicate positive or negative Update Messages.
P = 1 indicates "positive". N = 1 indicates "negative". Both
may be 1 for a flooded all-addresses Update.
R: Reserved. MUST be sent as zero and ignored on receipt.
For tracking methods 2 and 3 in Section 3.3, a particular Update
Message MUST have either the P flag or the N flag set, but not both.
If both are set, the Update Message MUST be ignored, as this
combination is only valid for method 1.
3.3.2. Acknowledge Message Format
An Acknowledge Message is sent in response to an Update Message to
confirm receipt or indicate an error, unless response is inhibited by
rate limiting. It is formatted as a Response Message, but the Type
is set to 4.
If there are no errors in the processing of an Update Message or if
there is an overall message-level error or a header error in an
Update Message, the message is echoed back with the Err and
SubErr fields set appropriately, the Type changed to Acknowledge, and
a null Records section with the Count field set to 0.
If there is a record-level error in an Update Message, one or more
Acknowledge Messages may be returned with the erroneous record(s)
indicated as discussed in Section 3.6.
An Acknowledge Message is sent with the same priority as the Update
Message it acknowledges but not more than a configured priority
called "DirAckMaxPriority", which defaults to 5 (see Section 3.9).
3.4. Summary of Record Formats in Messages
As specified in Sections 3.2 and 3.3, the Query, Response, Update, and Acknowledge Messages can have zero or more repeating Record structures under different circumstances, as summarized below. The "Err" column abbreviations in this table have the meanings listed below. "IA APPsub-TLV value" means the value part of the IA APPsub-TLV specified in [RFC7961]. MBZ = MUST be zero Z = zero NZ = non-zero NZM = non-zero message-level error NZR = non-zero record-level error Message Err Section Record Structure Response Data ----------- --- ------- ---------------- ------------------- Query MBZ 3.2.1 QUERY Record - Response Z 3.2.2.1 RESPONSE Record IA APPsub-TLV value Response NZM 3.2.2.1 null - Response NZR 3.2.2.1 RESPONSE Record Records with error Update MBZ 3.3.1 RESPONSE Record IA APPsub-TLV value Acknowledge Z 3.3.2 null - Acknowledge NZM 3.3.2 null - Acknowledge NZR 3.3.2 RESPONSE Record Records with error See Section 3.6 for further details on errors.3.5. End Stations and Pull Directories
A Pull Directory can be hosted on an end station as specified in Section 3.5.1. An end station can use a Pull Directory as specified in Section 3.5.2. This capability would be useful in supporting an end station that performs directory-assisted encapsulation [DirAsstEncap] or that is a "Smart Endnode" [SmartEN]. The native Pull Directory messages used in these cases are as specified in Section 3.5.3. In these cases, the edge RBridge(s) and end station(s) involved need to detect each other and exchange some control information. This is accomplished with the TRILL End System to Intermediate System (ES-IS) mechanism specified in Section 5.
3.5.1. Pull Directory Hosted on an End Station
Optionally, a Pull Directory actually hosted on an end station MAY be supported. In that case, one or more TRILL switches must act as indirect Pull Directory servers. That is, they host a Pull Directory server, which is seen by other TRILL switches in the campus, and a Pull Directory client, which fetches directory information from one or more end-station Pull Directory servers, where at least some of the information provided by the Pull Directory server may be information fetched from an end station to which it is directly connected by the co-located Pull Directory client. ("Direct connection" means a connection not involving any intermediate TRILL switches.) End stations hosting a Pull Directory server MUST support TRILL ES-IS (see Section 5) and advertise the Data Labels for which they are providing service in one or more Interested VLANs sub-TLVs or Interested Labels sub-TLVs by setting the PUL flag (see Section 7.3). * * * * * * * +---------------+ * * | End Station 1 | +---------------+ * | Pull Directory+--------------+ RB1, Pull | * | Server | | Directory| * +---------------+ +-------+ Client|Server | +----+ | +---------------+ |RB99| +---------------+ | * +----+ | End Station 2 | +--+---+ +---------------+ * | Pull Directory+---+Bridge+---+ RB2, Pull | * | Server | +--+---+ | Directory| * +---------------+ | | Client|Server | * | +---------------+ * | * TRILL * . * Campus * . * * . * * * * * * * Figure 2: End-Station Pull Directory Example Figure 2 gives an example where RB1 and RB2 advertise themselves to the rest of the TRILL campus, such as RB99, as Pull Directory servers and obtain at least some of the information they are providing by issuing Pull Directory queries to End Stations 1 and/or 2. This example is specific, but many variations are possible. The box labeled "Bridge" in Figure 2 could be replaced by a complex bridged LAN or could be a bridgeless LAN through the use of a hub or repeater. Or, end stations might be connected via point-to-point links (as shown for End Station 1), including multi-ported
end stations connected by point-to-point links to multiple RBridges. Although Figure 2 shows two end stations and two RBridges, there could be one or more than two RBridges having such indirect Pull Directory servers. Furthermore, there could be one or more than two end stations with Pull Directory servers on them. Each TRILL switch acting as an indirect Pull Directory server could then be differently configured as to the Data Labels for which it is providing indirect service selected from the union of the Data Labels supported by the end-station hosted servers and could select from among those end-station hosted servers supporting each Data Label the indirect server is configured to provide. When an indirect Pull Directory server receives Query Messages from other TRILL switches, it answers from information it has cached or issues Pull Directory requests to end-station Pull Directory servers with which it has TRILL ES-IS adjacency to obtain the information. Any Response sent by an indirect Pull Directory server MUST NOT have a validity time longer than the validity period of the data on which it is based. When an indirect Pull Directory server receives Update Messages, it updates its cached information and MUST originate Update Messages to any clients that may have mirrors of the cached information so updated. Since an indirect Pull Directory server discards information it has cached from queries to an end-station Pull Directory server if it loses adjacency to the server (Section 3.7), if it detects that such information may be cached at RBridge clients and has no other source for the information, it MUST send Update Messages to those clients withdrawing the information. For this reason, indirect Pull Directory servers may wish to query multiple sources, if available, and cache multiple copies of returned information from those multiple sources. Then, if one end-station source becomes inaccessible or withdraws the information but the indirect Pull Directory server has the information from another source, it need not originate Update Messages.3.5.2. Use of Pull Directory by End Stations
Some special end stations, such as those discussed in [DirAsstEncap] and [SmartEN], may need to access directory information. How edge RBridges provide this optional service is specified below. When Pull Directory support is provided by an edge RBridge to end stations, the messages used are as specified in Section 3.5.3 below. The edge RBridge MUST support TRILL ES-IS (Section 5) and advertises the Data Labels for which it offers this service to end stations by
setting the Pull Directory flag (PUL) to 1 in its Interested VLANs sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data Label advertised through TRILL ES-IS.3.5.3. Native Pull Directory Messages
The Pull Directory messages used between TRILL switches and end stations are native RBridge Channel messages [RFC7178]. These RBridge Channel messages use the same Channel Protocol number as the inter-RBridge Pull Directory RBridge Channel messages. The Outer.VLAN ID used is the TRILL ES-IS Designated VLAN (see Section 5) on the link to the end station. Since there is no TRILL Header or inner Data Label for native RBridge Channel messages, that information is added to the Pull Directory message header as specified below. The protocol-dependent data part of the native RBridge Channel message is the same as for inter-RBridge Channel messages, except that the 8-byte header described in Section 3.1 is expanded to 12 or 16 bytes, as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Type | Flags | Count | Err | SubErr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Label ... (4 or 8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ | Type Specific Payload - variable length +-+-+- ... Fields other than the Data Label field are as defined in Section 3.1. The Data Label that normally appears right after the Inner.MacSA of the RBridge Channel Pull Directory message appears in the Data Label field of the Pull Directory message header in the native RBridge Channel message version. This Data Label appears in a native Query Message, to be reflected in a Response Message, or it might appear in a native Update to be reflected in an Acknowledge Message. Since the appropriate VLAN or FGL [RFC7172] Ethertype is included, the length of the Data Label can be determined from the first 2 bytes.
3.6. Pull Directory Message Errors
A non-zero Err field in the Pull Directory Response or Acknowledge Message header indicates an error message. If there is an error that applies to an entire Query or Update Message or its header, as indicated by the range of the value of the Err field, then the QUERY Records probably were not even looked at by the Pull Directory server and would provide no additional information in the Response or Acknowledge Message. Therefore, the Records section of the response to a Query Message or Update Message is omitted, and the Count field is set to 0 in the Response or Acknowledge Message. If errors occur at the QUERY Record level for a Query Message, they MUST be reported in a Response Message separate from the results of any successful non-erroneous QUERY Records. If multiple QUERY Records in a Query Message have different errors, they MUST be reported in separate Response Messages. If multiple QUERY Records in a Query Message have the same error, this error response MAY be reported in one or multiple Response Messages. In an error Response Message, the QUERY Record or Records being responded to appear, expanded by the Lifetime for which the server thinks the error might persist (usually 2**16 - 1, which indicates "indefinitely") and with their Index inserted, as the RESPONSE Record or Records. If errors occur at the RESPONSE Record level for an Update Message, they MUST be reported in an Acknowledge Message separate from the acknowledgment of any non-erroneous RESPONSE Records. If multiple RESPONSE Records in an Update have different errors, they MUST be reported in separate Acknowledge Messages. If multiple RESPONSE Records in an Update Message have the same error, this error response MAY be reported in one or multiple Acknowledge Messages. In an error Acknowledge Message, the RESPONSE Record or Records being responded to appear, expanded by the time for which the server thinks the error might persist and with their Index inserted, as a RESPONSE Record or Records. Err values 1 through 126 are available for encoding errors at the Request Message or Update Message level. Err values 128 through 254 are available for encoding errors at the QUERY Record or RESPONSE Record level. The SubErr field is available for providing more detail on errors. The meaning of a SubErr field value depends on the value of the Err field.
3.6.1. Error Codes
The following table lists error code values for the Err field, their meanings, and whether they apply at the message level or the record level. Err Level Meaning ------- ------- ----------------------------------------------- 0 - No Error 1 Message Unknown or reserved Query Message field value 2 Message Request Message/data too short 3 Message Unknown or reserved Update Message field value 4 Message Update Message/data too short 5-126 Message Unassigned 127 - Reserved 128 Record Unknown or reserved QUERY Record field value 129 Record QUERY Record truncated 130 Record Address not found 131 Record Unknown or reserved RESPONSE Record field value 132 Record RESPONSE Record truncated 133-254 Record Unassigned 255 - Reserved Note that some error codes are for overall message-level errors, while some are for errors in the repeating records that occur in messages.3.6.2. Sub-errors under Error Codes 1 and 3
The following sub-errors are specified under error codes 1 and 3: SubErr Field with Error ------ ------------------------------------------- 0 Unspecified 1 Version not understood (see Section 3.1.1) 2 Unknown Type field value 3 Specified Data Label not being served 4-254 Unassigned 255 Reserved
3.6.3. Sub-errors under Error Codes 128 and 131
The following sub-errors are specified under error codes 128 and 131: SubErr Field with Error ------ ---------------------------------------------------- 0 Unspecified 1 Unknown AFN field value 2 Unknown or Reserved QTYPE field value 3 Invalid or inconsistent SIZE field value 4 Invalid frame for QTYPE 2 (other than SEND) 5 SEND frame sent as QTYPE 2 6 Invalid frame for QTYPE 5 (such as multicast MacDA) 7-254 Unassigned 255 Reserved3.7. Additional Pull Details
A Pull Directory client MUST be able to detect, by tracking link-state changes, when a Pull Directory server is no longer accessible (data reachable [RFC7780] for the inter-RBridge case or TRILL ES-IS (Section 5) adjacent for the end-station-to-RBridge case) and MUST promptly discard all pull responses it is retaining from that server, as it can no longer receive cache consistency Update Messages from the server. A secondary Pull Directory server is one that obtains its data from a primary directory server. See the discussion in Section 2.6 regarding the transfer of directory information from the primary server to the secondary server.3.8. The "No Data" Flag
In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], the mere presence of any Interested VLANs sub-TLVs or Interested Labels sub-TLVs in the LSP of a TRILL switch indicates connection to end stations in the VLAN(s) or FGL(s) listed and thus a need to receive multi-destination traffic in those Data Labels. However, with Pull Directories, advertising that you are a directory server requires using these sub-TLVs to indicate the Data Label(s) you are serving. If a directory server does not wish to receive multi-destination TRILL Data packets for the Data Labels it lists in one of the Interested VLANs or Interested Labels (FGLs) sub-TLVs (see Section 1.2), it sets the No Data (NOD) bit to 1 (see Section 7.3). This means that data on a distribution tree may be pruned so as not to reach the "No Data" TRILL switch as long as there are no TRILL
switches interested in the Data Label that are beyond the No Data
TRILL switch on that distribution tree. The NOD bit is backward
compatible, as TRILL switches ignorant of it will simply not prune
when they could; this is safe, although it may cause increased link
utilization by some TRILL switches sending multi-destination traffic
where it is not needed.
Push Directories advertise themselves inside ESADI, which normally
requires the ability to send and receive multi-destination TRILL Data
packets but can be implemented with serial unicast.
An example of a TRILL switch serving as a directory that might not
want multi-destination traffic in some Data Labels would be a TRILL
switch that does not offer end-station service for any of the Data
Labels for which it is serving as a directory and is
- a Pull Directory and/or
- a Push Directory for one or more Data Labels, where all of the
ESADI traffic for those Data Labels will be handled by unicast
ESADI [RFC7357].
A Push Directory MUST NOT set the NOD bit for a Data Label if it
needs to communicate via multi-destination ESADI or RBridge Channel
PDUs in that Data Label, since such PDUs look like TRILL Data packets
to transit TRILL switches and are likely to be incorrectly pruned if
the NOD bit was set.
3.9. Pull Directory Service Configuration
The following per-RBridge scalar configuration parameters are available for controlling Pull Directory service behavior. In addition, there is a configurable mapping, per Data Label, from the priority of a native frame being ingressed to the priority of any Pull Directory query it causes. The default mapping depends on the client strategy, as described in Section 4. Name Default Section Note Below ------------------ ---------------- ------- ---------- DirQueryTimeout 100 milliseconds 3.2.1 1 DirQueryRetries 3 3.2.1 1 DirGenQPriority 5 3.2.1 2 DirRespMaxPriority 6 3.2.2.1 3 DirUpdateDelay 50 milliseconds 3.3 DirUpdatePriority 5 3.3.1 DirUpdateTimeout 100 milliseconds 3.3.3 DirUpdateRetries 3 3.3.3 DirAckMaxPriority 5 3.3.2 4 Note 1: Pull Directory Query client timeout waiting for response and maximum number of retries. Note 2: Priority for client-generated requests (such as a query to refresh cached information). Note 3: Pull Directory Response Messages SHOULD NOT be sent with priority 7, as that priority SHOULD be reserved for messages critical to network connectivity. Note 4: Pull Directory Acknowledge Messages SHOULD NOT be sent with priority 7, as that priority SHOULD be reserved for messages critical to network connectivity.
(page 42 continued on part 3)