Internet DRAFT - draft-dunbar-trill-scheme-for-directory-assist
draft-dunbar-trill-scheme-for-directory-assist
INTERNET-DRAFT Linda Dunbar
Intended status: Proposed Standard Donald Eastlake
Updates: ESADI Huawei
Radia Perlman
Intel
Igor Gashinsky
Yahoo
Yizhou Li
Huawei
Expires: April 20, 2014 October 21, 2013
TRILL: Edge Directory Assistance Mechanisms
<draft-dunbar-trill-scheme-for-directory-assist-06.txt>
Abstract
This document describes mechanisms for using directory server(s) to
assist TRILL (Transparent Interconnection of Lots of Links) edge
switches in reducing multi-destination traffic, particularly ARP/ND
and unknown unicast flooding.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
L. Dunbar, et al [Page 1]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
Table of Contents
1. Introduction............................................3
1.1 Terminology............................................3
2. Push Model Directory Assistance Mechanisms..............5
2.1 Requesting Push Service................................5
2.2 Push Directory Servers.................................5
2.3 Push Directory Server State Machine....................6
2.3.1 Push Directory States................................6
2.3.2 Push Directory Events and Conditions.................7
2.3.3 State Transition Diagram and Table...................8
2.4 Additional Push Details...............................10
2.5 Primary to Secondary Server Push Service..............11
3. Pull Model Directory Assistance Mechanisms.............12
3.1 Pull Directory Request Format.........................12
3.2 Pull Directory Response Format........................15
3.3 Pull Directory Hosted on an End Station...............18
3.4 Pull Directory Request Errors.........................19
3.5 Cache Consistency.....................................20
3.6 Additional Pull Details...............................22
4. Events That May Cause Directory Use....................23
4.1 Forged Native Frame Ingress...........................23
4.2 Unknown Destination MAC...............................23
4.3 Address Resolution Protocol (ARP).....................24
4.4 IPv6 Neighbor Discovery (ND)..........................25
4.5 Reverse Address Resolution Protocol (RARP)............25
5. Layer 3 Address Learning...............................26
6. Directory Use Strategies and Push-Pull Hybrids.........27
6.1 Strategy Configuration................................27
7. Security Considerations................................30
8. IANA Considerations....................................31
8.1 ESADI-Parameter Data..................................31
8.2 RBridge Channel Protocol Number.......................32
8.3 The Pull Directory and No Data Bits...................32
Acknowledgments...........................................33
Normative References......................................33
Informational References..................................34
Authors' Addresses........................................35
L. Dunbar, et al [Page 2]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
1. Introduction
[DirectoryFramework] describes a high-level framework for using
directory servers to assist TRILL [RFC6325] edge nodes to reduce
multi-destination ARP/ND and unknown unicast flooding traffic and to
potentially improve security against address spoofing within a TRILL
campus. Because multi-destination traffic becomes an increasing
burden as a network scales, reducing ARP/ND and unknown unicast
flooding improves TRILL network scalability. This document describes
specific mechanisms for directory servers to assist TRILL edge nodes.
These mechanisms are optional to implement.
The information held by the Directory(s) is address mapping and
reachability information. Most commonly, what MAC address
[RFC5342bis] corresponds to an IP address within a Data Label (VLAN
or FGL (Fine Grained Label [RFCfgl])) and from what egress TRILL
switch (RBridge) (and optionally what specific TRILL switch port)
that MAC address is reachable. But it could be what IP address
corresponds to a MAC address or possibly other address mappings or
reachability. In the data center environment, it is common for
orchestration software to know and control where all the IP
addresses, MAC addresses, and VLANs/tenants are in a data center.
Thus such orchestration software is appropriate for providing the
directory function or for supplying the Directory(s) with directory
information.
Directory services can be offered in a Push or Pull mode. Push mode,
in which a directory server pushes information to TRILL switches
indicating interest, is specified in Section 2. Pull mode, in which a
TRILL switch queries a server for the information it wants, is
specified in Section 3. Modes of operation, including hybrid
Push/Pull, are discussed in Section 4.
The mechanisms used to initially populate directory data in primary
servers is beyond the scope of this document. The Push Directory
service can be used by a primary server to provide Directory data to
secondary servers as described in Section 2.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
The terminology and acronyms of [RFC6325] are used herein along with
the following additions:
CP: Complete Push flag bit. See Sections 2 and 6.1 below.
L. Dunbar, et al [Page 3]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
CSNP Time: Complete Sequence Number PDU Time. See [ESADI] and Section
6.1 below.
Data Label: VLAN or FGL.
FGL: Fine Grained Label [RFCfgl].
Host: Application running on a physical server or a virtual machine.
A host must have a MAC address and usually has at least one IP
address.
IP: Internet Protocol. In this document, IP includes both IPv4 and
IPv6.
PD: Push Directory flag bit. See Sections 2 and 6.1 below.
primary server: A Directory server that obtains the information it is
serving up by a reliable mechanism outside the scope of this
document but designed to assure the freshness of that
information. (See secondary server.)
RBridge: An alternative name for a TRILL switch.
secondary server: A Directory server that obtains the information it
is serving up from one or more primary servers.
tenant: Sometimes used as a synonym for FGL.
TRILL switch: A device that implements the TRILL protocol.
L. Dunbar, et al [Page 4]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
2. Push Model Directory Assistance Mechanisms
In the Push Model [DirectoryFramework], one or more Push Directory
servers push down the address mapping information for the various
addresses associated with end station interface and the TRILL
switches from which those interfaces are reachable [IA]. This service
is scoped by Data Label (VLAN or FGL [RFCfgl]). A Push Directory
also advertises whether or not it believes it has pushed complete
mapping information for a Data Label. It might be pushing mapping
information for only a subset of the ports in a Data Label. The Push
Model uses the [ESADI] protocol as its distribution mechanism.
With the Push Model, if complete address mapping information for a
Data Label being pushed is available, a TRILL switch (RBridge) which
has that complete pushed information can simply drop a native frame
if the destination unicast MAC address can't be found in the mapping
information available, instead of flooding it (see Section 2.1). This
will minimize flooding of packets due to errors or inconsistencies
but is not practical if directories have incomplete information.
2.1 Requesting Push Service
In the Push Model, it is necessary to have a way for an RBridge to
request information from the directory server(s). RBridges simply
use the ESADI protocol mechanism to announce, in their core IS-IS
LSPs, the Data Labels for which they are participating in [ESADI] by
using the Interested VLANs and/or Interested Labels sub-TLVs
[RFC6326bis]. This will cause them to be pushed the Directory
information for all such Data Labels that are being served by one or
more Push Directory servers.
2.2 Push Directory Servers
Push Directory servers advertise their availability to push the
mapping information for a particular Data Label to each other and to
ESADI participants for that Data Label by turning on a flag bit in
their ESADI Parameter APPsub-TLV [ESADI] for that ESADI instance (see
Section 8.1). Each Push Directory server MUST participate in ESADI
for the Data Labels for which it will push mappings and set the PD
(Push Directory) bit in their ESADI-Parameters APPsub-TLV for that
Data Label.
For robustness, it is useful to have more than one copy of the data
being pushed. Each RBridge that is a Push Directory server is
configured with a number in the range 1 to 8, which defaults to 2,
for each Data Label for which it can push directory information. If
L. Dunbar, et al [Page 5]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
the Push Directories for a Data Label are configured the same in this
regard and enough such servers are available, this is the number of
copies of the directory that will be pushed.
Each Push Directory server also has an 8-bit priority to be Active
(see Section 8.1 of this document). This priority is treated as an
unsigned integer where larger magnitude means higher priority and is
in its ESADI Parameter APPsub-TLV. In cases of equal priority, the
6-byte IS-IS System ID is used as a tie breaker and treated as an
unsigned integer where larger magnitude means higher priority.
For each Data Label it can serve, each Push Directory server orders,
by priority, the Push Directory servers that it can see in the ESADI
link state database for that Data Label that are data reachable
[RFCclear] and determines its position in that order. If a Push
Directory server is configured to believe that N copies of the
mappings for a Data Label should be pushed and finds that it is
number K in the priority ordering (where number 1 is highest priority
and number K is lowest), then if K is less than or equal to N the
Push Directory server is Active. If K is greater than N it is
Passive. Active and Passive behavior are specified below.
2.3 Push Directory Server State Machine
The subsections below describe the states, events, and corresponding
actions for Push Directory servers.
2.3.1 Push Directory States
A Push Directory Server is in one of six states, as listed below, for
each Data Label it can serve. In addition, it has an internal State-
Transition-Time variable for each such Data Label which it set at
each state transition and which enables it to determine how long it
has been in its current state.
Down: A completely shut down virtual state defined for convenience in
specifying state diagrams. A Push Directory Server in this state
does not advertise any Push Directory data. It may be
participating in [ESADI] with the PD bit zero in its ESADI-
Parameters or might be not participating in [ESADI] at all. (All
states other than the Down state are considered to be Up states.)
Passive: No Push Directory data is advertised. Any outstanding EASDI-
LSP fragments containing directory data are updated to remove that
data and if the result is an empty fragment (contains nothing
except possibly an Authentication TLV), the fragment is purged.
L. Dunbar, et al [Page 6]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
The Push Directory participates in [ESADI] and its [ESADI]
fragment zero includes an ESADI-Parameters APPsub-TLV with the PD
bit set to one and CP (Complete Push) bit zero.
Active: If a Push Directory server is Active, it advertises its
directory data through [ESADI] in its ESADI-LSPs using the
Interface Addresses [IA] APPsub-TLV and updates that information
as it changes. The PD bit is set to one in the ESADI-Parameters
and the CP bit must be zero.
Completing: Same behavior as the Active state but responds
differently to events.
Complete: The same behavior as Completing except that the CP bit in
the ESADI-Parameters APPsub-TLV is set to one and the server
responds differently to events.
Reducing: The same behavior as Complete but responds differently to
events. The PD bit remains a one but the CP bit is cleared to zero
in the ESADI-Parameters APPsub-TLV. Directory updates continue to
be advertised.
2.3.2 Push Directory Events and Conditions
Three auxiliary conditions referenced later in this section are
defined as follows for convenience:
The Activate Condition: The server determines that there are K data
reachable Push Directory servers, the server is configured that
there should be N copies pushed, and K is less than or equal to N.
The Pacify Condition: The server determines that there are K data
reachable Push Directory servers, the server is configured that
there should be N copies pushed, and K is greater than N.
The Time Condition: The server has been in its current state for an
amount of time equal to or larger than its CSNP time (see Section
8.1).)
The events and conditions listed below cause state transitions in
Push Directory servers.
1. Push Directory server or TRILL switch was configured to be down
but the TRILL switch on which it resides is up and the server is
configured to be up.
2. The Push Directory server or the TRILL switch on which it is
resident is being shut down.
L. Dunbar, et al [Page 7]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
3. The Activate Condition is met and the server is not configured to
believe it has complete data.
4. The server determines that the Pacify Condition is met.
5. The server is configured to believe it has complete data and the
Activate Condition is met.
6. The server is configured to believe it does not have complete
data.
7. The Time Condition is met.
2.3.3 State Transition Diagram and Table
The state transition diagram is as follows.
L. Dunbar, et al [Page 8]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
+-----------+
| Down |<---------+
+-----------+ |
|1 ^ | 3,4,5,6,7 |
| | +------------+
V |2
+-----------+
| Passive |<-----------------------
+-----------+ ^ ^ ^
|5 |3 |1,4,6,7 | | |
| | +---------+ | |
| V |2,4 |
| +---------------------+ |
| | Active |<--+ |
| +---------------------+ | |
| |5 ^ |1,3,6,7 ^ | |
| | | | | | |
| | | +---------+ | |
| | | | |
V V |3,6 | |
+--------------+ | |
| Completing |-------------------+
+--------------+ 2,4 |
|7 |1,5 ^ |
| | | |
| +-----+ |
V |7
+-------------+ +----------------+
| Complete |--------->| Reducing |<--+
+-------------+ 2,3,4,6 +----------------+ |
|1,5,7 ^ ^ |5 |1,2,3,4,6 |
| | | | | |
+------+ +--------------+ +--------------+
Figure 1. Push Server State Diagram
This state diagram is equivalent to the following transition table:
Event || Down |Passive |Active |Completing|Complete|Reducing|
------++-------+----------+--------+----------+--------+--------+
1 ||Passive|Passive |Active |Completing|Complete|Reducing|
2 || Down | Down |Passive |Passive |Reducing|Reducing|
3 || Down |Active |Active |Active |Reducing|Reducing|
4 || Down |Passive |Passive |Passive |Reducing|Reducing|
5 || Down |Completing|Complete|Completing|Complete|Complete|
6 || Down |Passive |Active |Active |Reducing|Reducing|
7 || Down |Passive |Active |Complete |Complete|Active |
L. Dunbar, et al [Page 9]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
2.4 Additional Push Details
Push Directory mappings can be distinguished for any other data
distributed through ESADI because mappings are distributed only with
the Interface Addresses APPsub-TLV [IA] and are flagged as being Push
Directory data.
RBridges, whether or not they are a Push Directory server, MAY
continue to advertise any locally learned MAC attachment information
in [ESADI] using the Reachable MAC Addresses TLV [RFC6165] . However,
if a Data Label is being served by complete Push Directory servers,
advertising such locally learned MAC attachment should generally not
be done as it would not add anything and would just waste bandwidth
and ESADI link state space. An exception would be when an RBridge
learns local MAC connectivity and that information appears to be
missing from the directory mapping.
Because a Push Directory server may need to advertise interest in
Data Labels even if it does not want to receive end station data in
those Data Labels, the No Data flag bit is provided as discussed in
Section 6.3.
If an RBridge notices that a Push Directory server is no longer data
reachable [RFCclear], it MUST ignore any Push Directory data from
that server because it is no longer being updated and may be stale.
The nature of dynamic distributed asynchronous systems is such that
it is impractical for an RBridge receiving Push Directory information
to ever be absolutely certain that it has complete information.
However, it can obtain a reasonable assurance of complete information
by requiring two conditions to be met:
1. The PD and CP bits are on in the ESADI zero fragment from the
server for the relevant Data Label.
2. A client RBridge might be just coming up and receive an EASDI
LSP meeting the requirement in point 1 above but have not yet
received all of the ESADI LSP fragment from the Push Directory
server. Thus, it should not believe that information to be
complete unless it has also had data connectivity to the server
for the larger of the client's and the server's CSNP times.
There may be transient conflicts between mapping information from
different Push Directory servers or conflicts between locally learned
information and information received from a Push Directory server. In
case of such conflicts, information with a higher confidence value is
preferred over information with a lower confidence. In case of equal
confidence, Push Directory information is preferred to locally
learned information and if information from Push Directory servers
conflicts, the information from the higher priority Push Directory
server is preferred.
L. Dunbar, et al [Page 10]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
2.5 Primary to Secondary Server Push Service
A secondary Push or Pull Directory server is one that obtains its
data from a primary directory server. Other techniques MAY be used
but, by default, this data transfer occurs through the primary server
acting as a Push Directory server for the Data Labels involved while
the secondary Push Directory server takes the pushed data it receives
from the highest priority Push Directory server and re-originates it.
L. Dunbar, et al [Page 11]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
3. Pull Model Directory Assistance Mechanisms
In the Pull Model, a TRILL switch (RBridge) pulls directory
information from an appropriate Directory Server when needed.
Pull Directory servers for a particular Data Label X are located by
looking in the core TRILL IS-IS link state database for RBridges that
advertise themselves by having the Pull Directory flag on in their
Interested VLANs or Interested Labels sub-TLV [RFC6326bis] for X. If
multiple RBridges indicate that they are Pull Directory Servers for a
particular Data Label, pull requests can be sent to any one or more
of them that are data reachable but it is RECOMMENDED that pull
requests be preferentially sent to the server or servers that are
lower cost from the requesting RBridge.
Pull Directory requests are sent by enclosing them in an RBridge
Channel [Channel] message using the Pull Directory channel protocol
number (see Section 8.2). Responses are returned in an RBridge
Channel message using the same channel protocol number.
The requests to Pull Directory Servers are typically derived from
normal ARP [RFC826], ND [RFC4861], RARP [RFC903] messages or data
frames with unknown unicast destination MAC addresses intercepted by
the RBridge as described in Section 4.
Pull Directory responses include an amount of time for which the
response should be considered valid. This includes negative responses
that indicate no data is available. Thus both positive responses with
data and negative responses can be cached and used for immediate
response to ARP, ND, RARP, or unknown destination MAC frames, until
they expire. If information previously pulled is about to expire, an
RBridge MAY try to refresh it by issued a new pull request but, to
avoid unnecessary requests, SHOULD NOT do so if it has not been
recently used.
3.1 Pull Directory Request Format
A Pull Directory request is sent as the Channel Protocol specific
content of an inter-RBridge Channel message [Channel] TRILL Data
packet. The Data Label in the packet is the Data Label in which the
query is being made. The priority of the channel message is a mapping
of the priority of the frame being ingressed that caused the request
with the default mapping depending, per Data Label, on the strategy
(see Section 6). The Channel Protocol specific data is formatted as
follows:
L. Dunbar, et al [Page 12]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | T | RESV | Count | RESV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QUERY 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
V: Version of the Pull Directory protocol as an unsigned integer.
Version zero is specified in this document.
T: Type. 0 => Response, 1=> Query, 2=> Unsolicited Update, 3=>
Reserved. An unsolicited update is formatted as a response
except there is no corresponding query. Messages received with
type = 3 are discarded. Queries received by an RBridge that is
not a Pull Directory are discarded. Responses that do not match
an outstanding Query are discarded.
RESV: Reserved bits. MUST be sent as zero and ignored on receipt.
Count: Number of queries present.
Sequence Number: A 32-bit quantity set by the sending RBridge,
returned in any responses, and used to match up responses with
queries. It is opaque except that the value zero is reserved
for Unsolicited Update response messages. A Request received
with Sequence Number zero is discarded.
QUERY: Each Query record within a Pull Directory request message
is formatted as follows:
L. Dunbar, et al [Page 13]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE | RESV | TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
If TYPE = 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| AFN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query address ...
+--+--+--+--+--+--+--+--+--+--+--...
If TYPE = 2, 3, 4, or 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query frame ...
+--+--+--+--+--+--+--+--+--+--+--...
SIZE: Size of the query data in bytes as an unsigned byte
starting with and including the SIZE field itself. Thus the
minimum legal value is 2. A value of SIZE less than 2
indicates a malformed message. The "QUERY" with the illegal
SIZE value and all subsequent QUERYs MUST be ignored and the
entire query message MAY be ignored.
RESV: A block of reserved bits. MUST be sent as zero and
ignored on receipt.
TYPE: There are two types of queries currently defined, (1) a
query that provides an explicit address and asks for other
addresses for the interface specified by the query address
and (2) a query that includes a frame. The fields of each
are specified below. Values of TYPE are as follows
TYPE Description
---- -----------
0 reserved
1 query address
2 ARP query frame
3 ND query frame
4 RARP query frame
5 Unknown unicast MAC query frame
6-14 assignable by IETF Review
15 reserved
AFN: Address Family Number of the query address.
Query Address: The query is asking for any other addresses,
and the RBridge from which they are reachable, that
correspond to the same interface, within the data label
of the query. Typically that would be either (1) a MAC
address with the querying RBridge primarily interested in
the RBridge by which that MAC address is reachable, or
L. Dunbar, et al [Page 14]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
(2) an IP address with the querying RBridge interested in
the corresponding MAC address and the RBridge by which
that MAC address is reachable. But it could be some other
address type.
Query Frame: Where a Pull Directory query is the result of
an ARP, ND, RARP, or unknown unicast MAC destination
address, the ingress RBridge MAY send the frame to a Pull
Directory Server if the frame is small enough to fit into
a query message.
A query count of zero is explicitly allowed, for the purpose of
pinging a Pull Directory server to see if it is responding to
requests. On receipt of such an empty query message, a response
message that also has a count of zero MUST be sent unless inhibited
by rate limiting.
If no response is received to a Pull Directory request within a
timeout configurable in milliseconds that defaults to 2,000, the
request should be re-transmitted with the same Sequence Number up to
a configurable number of times that defaults to three. If there are
multiple queries in a request, responses can be received to various
subsets of these queries by the timeout. In that case, the remaining
unanswered queries should be re-sent in a new query with a new
sequence number. If an RBridge is not capable of handling partial
responses to requests with multiple queries, it MUST NOT sent a
request with more than one query in it.
3.2 Pull Directory Response Format
Pull Directory responses are sent as the Channel Protocol specific
content of inter-RBridge Channel message TRILL Data packets.
Responses are sent with the same Data Label and priority as the
request to which they correspond except that the response priority is
limited to be not more than a configured value. This priority limit
is configurable at a per RBridge level and defaults to priority 6.
The Channel protocol specific data format is as follows:
L. Dunbar, et al [Page 15]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | T |F|P|N| RESV| Count | ERR | subERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESPONSE 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
V, T: Version and Type as specified in Section 3.1.
F: The Flood bit. If zero, the reply is to be unicast to the
provided Nickname. If T=2, F=1 is used to flood messages for
certain unsolicited update cache consistency maintenance
messages from an end station Pull Directory server as discussed
in Section 3.5. If T is not 2, F is ignored.
P, N: Flags used in connection with certain flooded unsolicited
cache consistency maintenance messages. Ignored if T is not 2.
If the P bit is a one, the solicited response message relates
to cached positive response information. If the N bit is a one,
the unsolicited message relates to cached negative information.
See Section 3.5.
RESV: Reserved bits. MUST be sent as zero and ignored on receipt.
Count: Count is the number of responses present in the particular
response message.
ERR, subERR: A two part error code. See Section 3.4.
Sequence Number: A 32-bit quantity set by the sending RBridge,
returned in any responses, and used to match up responses with
queries. It is opaque except that the value zero is reserved
for Unsolicited Update response messages.
RESPONSE: Each response record within a Pull Directory response
message is formatted as follows:
L. Dunbar, et al [Page 16]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE | RESV | Index |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Lifetime |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Response Data ...
+--+--+--+--+--+--+--+--+--+--+--...
SIZE: Size of the response data in bytes starting with and
including the SIZE field itself. Thus the minimum value of
SIZE is 6. If SIZE is less than 6, that RESPONSE and all
subsequent RESPONSEs MUST be ignored.
RESV: Four reserved bits that MUST be sent as zero and ignored
on receipt.
Index: The relative index of the query in the request message
to which this response corresponds. The index will always be
one for request messages containing a single query. The
index will always be zero for unsolicited update "response"
messages.
Lifetime: The length of time for which the response should be
considered valid in seconds. If zero, the response can only
be used for the particular query from which it resulted. The
maximum time that can be expressed is just over 18.2 hours.
[Perhaps this should be in units of, say, 200 milliseconds?]
Response Data: There are two types of response data.
If the ERR field is non-zero, the response data is a copy of
the query data, that is, either an AFN followed by an
address or a query frame.
If the ERR field is zero, the response data is the contents
of an Interface Addresses APPsub-TLV (see Section 5)
without the usual TRILL GENINFO TLV type and length and
without the usual IA APPsub-TLV type and length before
it. The maximum size of such contents is 251 bytes in the
case when SIZE is 255.
Multiple response records can appear in a response message with the
same index if the answer to a query consists of multiple Interface
Address APPsub-TLV contents. This would be necessary if, for example,
a MAC address within a Data Label appears to be reachable by multiple
RBridges. 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 to include by some method outside
the scope of this document.
L. Dunbar, et al [Page 17]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
See Section 3.4 for a discussion of how errors are handled.
3.3 Pull Directory Hosted on an End Station
Optionally, a Pull Directory actually hosted on an end station MAY be
supported. In that case, when the RBridge advertising itself as a
Pull Directory server receives a query, it modifies the inter-RBridge
Channel message received into a native RBridge Channel message and
forwards it to that end station. Later, when it receives one or more
responses from that end station by native RBridge Channel messages,
it modifies them into inter-RBridge Channel messages and forwards
them to the source RBridge of the query.
The native Pull Directory RBridge Channel messages use the same
Channel protocol number as do the inter-RBridge Pull Directory
RBridge Channel messages. The native messages MUST be sent with an
Outer.VLAN tag which gives the priority of each message which is the
priority of the original inter-RBridge request packet. The Outer.VLAN
ID used is the Designated VLAN on the link.
The native RBridge Channel message protocol dependent data for a Pull
Directory query is formatted as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | T | RESV | Count | Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label ... (4 or 8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QUERY 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Data Label: The Data Label of the original inter-RBridge Pull
Directory Channel protocol messages that was mapped to this
native channel message. The format is the same as it appears
right after the Inner.MacSA of the original Channel message.
Nickname: The nickname of the RBridge sending the original inter-
RBridge Pull Directory query.
L. Dunbar, et al [Page 18]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
All other fields, including the fields within the QUERY records
are as specified in Section 3.1.
The native RBridge Channel message protocol specific content for a
Pull Directory response is formatted as follows:
0 1 2 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | T |F|P|N| RESV| Count | ERR | subERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label ... (4 or 8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESPONSE 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Nickname: If F=0, the nickname of the ultimate destination
RBridge. If F=1, ignored.
Data Label: The Data Label to which the response applies. The
format is the same as it appears right after the Inner.MacSA in
TRILL Data messages.
All other fields, including the fields within the RESPONSE
records, are as specified in Section 3.2.
3.4 Pull Directory Request Errors
An error response message is indicated by a non-zero ERR field.
If there is an error that applies to an entire request message or its
header, as indicated by the range of the value of the ERR field, then
the query records in the request are just echoed back in the response
records but expanded with a zero Lifetime and the insertion of the
Index field.
If errors occur at the query level, they MUST be reported in a
response message separate from the results of any successful queries.
L. Dunbar, et al [Page 19]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
If multiple queries in a request have different errors, they MUST be
reported in separate response messages. If multiple queries in a
request have the same error, this error response MAY be reported in
one response message.
In an error response message, the query or queries being responded to
appear, expanded by the Lifetime for which the server thinks the
error might persist and with their Index inserted, as the RESPONSE
record.
ERR values 1 through 127 are available for encoding request message
level errors. ERR values 128 through 254 are available for encoding
query level errors. 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.
ERR Meaning
--- -------
0 (no error)
1 Unknown or reserved field value
2 Request data too short
3-127 (Available for allocation by IETF Review)
128 Unknown AFN
129 Address not found
130-254 (Available for allocation by IETF REview)
255 Reserved
The following sub-errors are specified under error code 1:
SubERR Field with Error
------ ----------------
0 Unspecified
1 Unknown V field value
2 Reserved T field value
3 Zero sequence number in request
4-254 (Available for allocation by IETF Review)
255 Reserved
More TBD
3.5 Cache Consistency
Pull Directories MUST take action to minimize the amount of time that
an RBridge will continue to use stale information from the Pull
Directory.
L. Dunbar, et al [Page 20]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
A Pull Directory server MUST maintain one of the following, in order
of increasing specificity. Retaining more specific records, such as
that given in item 3 below, minimizes spontaneous response messages
sent to update pull client RBridge caches. Retaining less specific
records, such as that given in item 1, will generally increase the
volume and overhead due to spontaneous response messages but still
maintain consistency.
1. An overall record per Data Label of when the last positive
response data will expire at a requester and when the last
negative response will expire.
2. For each unit of data (IA APPsub-TLV Address Set [IA]) held by
the server and each address about which a negative response was
sent, when the last expected response with that data or
negative response will expire at a requester.
3. For each unit of data held by the server and each address about
which a negative response was sent, a list of RBridges that
were sent that data as the response or sent a negative response
for the address, with the expected time to expiration at each
of them.
A Pull Directory server may have a limit as to how many RBridges it
can maintain expiry information for by method 3 above or how many
data units or addresses it can maintain expiry information for by
method 2. If such limits are exceeded, it MUST transition to a lower
numbered strategy but, in all cases, MUST support, at a minimum,
method 1.
When data at a Pull Directory changes or is deleted or data is added
and there may be unexpired stale information at a requesting RBridge,
the Pull Directory MUST send an unsolicited message as discussed
below.
If method 1, the most crude 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 message is flooded (multicast) within that
Data Label. And if data is added and there are outstanding cached
negative responses, an all-addresses flush negative message is
flooded. "All-addresses" is indicated by the Count in an unsolicited
response being zero. On receiving an all-addresses flooded flush
positive message from a Pull Directory server it has used, indicated
by the U, F, and P bits being one, an RBridge discards all cached
data responses it has for that Data Label. Similarly, on receiving an
all addresses flush negative message, indicated by the U, F, and N
bits being one, it discards all cached negative responses for that
Data Label. A combined flush positive and negative can be flooded by
having all of the U, F, P, and N bits set to one resulting in the
L. Dunbar, et al [Page 21]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
discard of all positive and negative cached information for the Data
Label.
If method 2 is being followed, then an RBridge floods address
specific unsolicited update positive responses when data which is
cached by a querying RBridge is changed or deleted and floods an
address specific unsolicited update negative response when such
information is added to. Such messages are similar to the method 1
flooded unsolicited flush messages. The U and F bits will be one and
the message will be multicast. However that Count field will be non-
zero and either the P or N bit, but not both, will be one. On
receiving such as address specific message, if it is positive the
addresses in the response records in the unsolicited response are
compared to the addresses about which the recipient RBridge is
holding cached positive or negative information and, if they match,
the cached information is updated or the negative information
replaced with the new positive information. On receiving an address
specific unsolicited update negative response, the addresses in the
response records in the unsolicited response are compared to the
addresses about which the recipient RBridge is holding cached
positive or negative information and, if they match, the any cached
positive information is discarded.
If method 3 is being followed, the same sort of unsolicited update
messages are sent as with method 2 except they are not normally
flooded but unicast only to the specific RBridges the server believes
may be holding the cached positive or negative information that may
need updating. However, the Pull Directory server MAY flood the
unsolicited update, for example if it determines that a sufficiently
large fraction of its requesters need to be updated.
3.6 Additional Pull Details
If an RBridge notices that a Pull Directory server is no longer data
reachable [RFCclear], it MUST discard all pull responses it is
retaining from that server as the RBridge can no longer receive cache
consistency messages from the server.
Because a Pull Directory server may need to advertise interest in
Data Labels even though it does not want to received end station data
in those Data Labels, the No Data flag bit is provided as specified
in Section 8.3.
L. Dunbar, et al [Page 22]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
4. Events That May Cause Directory Use
An RBridge can consult Directory information whenever it wants, by
(1) searching through information that has been retained after being
pushed to it or pulled by it or (2) by requesting information from a
Pull Directory. However, the following are expected to be the most
common circumstances leading to directory information use. All of
these are cases of ingressing (or originating) a native frame.
Support for each of the uses below is separately optional.
4.1 Forged Native Frame Ingress
End stations can forge the source MAC and/or IP address in a native
frame that an edge TRILL switch receives for ingress in some
particular Data Label. If there is complete Directory information as
to what end stations should be reachable by an egress TRILL switch or
a port on such a TRILL switch, frames with forged source addresses
SHOULD be discarded. If such frames are discarded, then none of the
special processing in the remaining subsection of this Section 2
occur and MAC address learning (see [RFC6325] Section 4.8) SHOULD NOT
occur. ("SHOULD NOT" is chosen because it is harmless in cases where
it has no effect. For example, if complete directory information is
available and such directory information is treated as having a
higher confidence that MAC addresses learned from the data plane.)
4.2 Unknown Destination MAC
Ingressing a native frame with an unknown unicast destination MAC:
The mapping from the destination MAC and Data Label to the egress
TRILL switch from which it is reachable is needed to ingress the
frame as unicast. If the egress RBridge is unknown, the frame must
be either dropped or ingressed as a multi-destination frame which
is flooded to all edge RBridges for its Data Label resulting in
increased link utilization compared with unicast routing.
Depending on the configuration of the TRILL switch ingressing the
native frame (see Section 6), directory information can be used
for the { destination MAC, Data Label } to egress TRILL switch
nickname mapping and destination MACs for which such direction
information is not available MAY be discarded.
L. Dunbar, et al [Page 23]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
4.3 Address Resolution Protocol (ARP)
Ingressing an ARP [RFC826]:
ARP is a flexible protocol. It is commonly used on a link to query
for the MAC address corresponding to an IPv4 address, test if an
IPv4 address is in use, or to announce a change in any of IPv4
address, MAC address, and/or point of attachment.
The logically important elements in an ARP are (1) the
specification of a "protocol" and a "hardware" address type, (2)
an operation code that can be Request or Reply, and (3) fields for
the protocol and hardware address of the sender and the target
(destination) node.
Examining the three types of ARP use:
1. General ARP Request / Response
This is a request for the destination "hardware" address
corresponding to the destination "protocol" address; however, if
the source and destination protocol addresses are equal, it should
be handled as in type 2 below. A general ARP is handled by doing a
directory lookup on the destination "protocol" address provided in
hops of finding a mapping to the desired "hardware" address. If
such information is obtain from a directory, a response can be
synthesized.
2. Gratuitous ARP
A request used by a host to announce a new IPv4 address, new MAC
address, and/or new point of network attachment. Identifiable
because the sender and destination "protocol" address fields have
the same value. Thus, under normal circumstances, there really
isn't any separate destination host to generate a response. If
complete Push Directory information is being used with the Notify
flag set in the IA APPsub-TLVs being pushed [IA] by all the
RBridge in the Data Label, then gratuitous ARPs SHOULD be
discarded rather the ingressed. Otherwise, they are either
ingressed and flooded or discarded depending on local policy.
3. Address Probe ARP Query
An address probe ARP is used to determine if an IPv4 address is in
use [RFC5227]. It can be identified by the source "protocol"
(IPv4) address field being zero. The destination "protocol"
address field is the IPv4 address being tested. If some host
believes it has that destination IPv4 address, it would respond to
the ARP query, which indicates that the address is in use.
Address probe ARPs can be handled the same as General ARP queries.
L. Dunbar, et al [Page 24]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
4.4 IPv6 Neighbor Discovery (ND)
Ingressing an IPv6 ND [RFC4861]:
TBD
Secure Neighbor Discovery messages [RFC3971] will, in general,
have to be sent to the neighbor intended so that neighbor can sign
the answer; however, directory information can be used to unicast
a Secure Neighbor Discovery packet rather than multicasting it.
4.5 Reverse Address Resolution Protocol (RARP)
Ingressing a RARP [RFC903]:
RARP uses the same packet format as ARP but different Ethertype
and opcode values. Its use is similar to the General ARP
Request/Response as described above. The difference is that it is
intended to query for the destination "protocol" address
corresponding to the destination "hardware" address provided. It
is handled by doing a directory lookup on the destination
"hardware" address provided in hops of finding a mapping to the
desired "protocol" address. For example, looking up a MAC address
to find the corresponding IP address.
L. Dunbar, et al [Page 25]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
5. Layer 3 Address Learning
TRILL switches MAY learn IP addresses in a manner similar to that in
which they learn MAC addresses. On ingress of a native IP frame, they
can learn the { IP address, MAC address, Data Label, input port } set
and on the egress of a native IP frame, they can learn the { IP
address, MAC address, Data Label, remote RBridge } information plus
the nickname of the RBridge that ingressed the frame.
This locally learned information is retained and times out in a
similar manner to MAC address learning specified in [RFC6325]. By
default, it has the same Confidence as locally learned MAC
reachability information.
Such learned Layer 3 address information MAY be disseminated with
[ESADI] using the IA APPsub-TLV [IA]. It can also be used as, in
effect, local directory information to assist in locally responding
to ARP/ND packets as discussed in Section 4.
L. Dunbar, et al [Page 26]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
6. Directory Use Strategies and Push-Pull Hybrids
For some edge nodes which have a great number of Data Labels enabled,
managing the MAC and Data Label <-> EdgeRBridge mapping for hosts
under all those Data Labels can be a challenge. This is especially
true for Data Center gateway nodes, which need to communicate with a
majority of Data Labels if not all.
For those RBridge Edge nodes, a hybrid model should be considered.
That is the Push Model is used for some Data Labels, and the Pull
Model is used for other Data Labels. It is the network operator's
decision by configuration as to which Data Labels' mapping entries
are pushed down from directories and which Data Labels' mapping
entries are pulled.
For example, assume a data center when hosts in specific Data Labels,
say VLANs 1 through 100, communicate regularly with external peers,
the mapping entries for those 100 VLANs should be pushed down to the
data center gateway routers. For hosts in other Data Labels which
only communicate with external peers occasionally for management
interface, the mapping entries for those VLANs should be pulled down
from directory when the need comes up.
The mechanisms described above for Push and Pull Directory services
make it easy to use Push for some Data Labels and Pull for others. In
fact, different RBridges can even be configured so that some use Push
Directory services and some use Pull Directory services for the same
Data Label if both Push and Pull Directory services are available for
that Data Label. And there can be Data Labels for which directory
services are not used at all.
For Data Labels in which a hybrid push/pull approach is being taken,
it would make sense to use push for address information of hosts that
frequently communicate with many other hosts in the Data Label, such
as a file or DNS server. Pull could then be used for hosts that
communicate with few other hosts, perhaps such as hosts being used as
compute engines.
6.1 Strategy Configuration
Each RBridge that has the ability to use directory assistance has,
for each Data Label X in which it is might ingress native frames, one
of four major modes:
0. No directory use. The RBridge does not subscribe to Push
Directory data or make Pull Directory requests for Data Label X
and directory data is not consulted on ingressed frames in Data
Label X that might have used directory data. This includes ARP,
L. Dunbar, et al [Page 27]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
ND, RARP, and unknown MAC destination addresses, which are
flooded.
1. Use Push only. The RBridge subscribes to Push Directory data
for Data Label X.
2. Use Pull only. When the RBridge ingresses a frame in Data Label
X that can use Directory information, if it has cached
information for the address it uses it. If it does not have
either cached positive or negative information for the address,
it sends a Pull Directory query.
3. Use Push and Pull. The RBridge subscribes to Push Directory
data for Data Label X. When it ingresses a frame in Data Label
X that can use Directory information and it does not find that
information in its link state database of Push Directory
information, it makes a Pull Directory query.
The above major Directory use mode is per Data Label. In addition,
there is a per Data Label per priority minor mode as listed below
that indicates what should be done if Directory Data is not available
for the ingressed frame. In all cases, if you are holding Push
Directory or Pull Directory information to handle the frame given the
major mode, the directory information is simply used and, in that
instance, the minor modes does not matter.
A. Flood immediate. Flood the frame immediately (even if you are
also sending a Pull Directory) request.
B. Flood. Flood the frame immediately unless you are going to do a
Pull Directory request, in which case you wait for the response
or for the request to time out after retries and flood the
frame if the request times out.
C. Discard if complete or Flood immediate. If you have complete
Push Directory information and the address is not in that
information, discard the frame. If you do not have complete
Push Directory information, the same as A above.
D. Discard if complete or Flood. If you have complete Push
Directory information and the address is not in that
information, discard the frame. If you do not have complete
Push Directory information, the same as B above.
In addition, the query message priority for Pull Directory requests
sent can be configured on a per Data Label, per ingressed frame
priority basis. The default mappings are as follows where Ingress
Priority is the priority of the native frame that provoked the Pull
Directory query:
L. Dunbar, et al [Page 28]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
Ingress If Flood If Flood
Priority Immediate Delayed
-------- --------- --------
7 5 6
6 5 6
5 4 5
4 3 4
3 2 3
2 0 2
0 1 0
1 1 1
Priority 7 is normally only used for urgent messages critical to
adjacency and so is avoided by default for directory traffic.
L. Dunbar, et al [Page 29]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
7. Security Considerations
Push Directory data is distributed through ESADI-LSPs [ESADI] which
can be authenticated with the same mechanisms as IS-IS LSPs. See
[RFC5304] [RFC5310] and the Security Considerations section of
[ESADI].
Pull Directory queries and responses are transmitted as RBridge-to-
RBridge or native RBridge Channel messages. Such messages can be
secured as specified in [ChannelTunnel].
For general TRILL security considerations, see [RFC6325].
L. Dunbar, et al [Page 30]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
8. IANA Considerations
This section give IANA allocation and registry considerations.
8.1 ESADI-Parameter Data
IANA is request to allocate two ESADI-Parameter TRILL APPsub-TLV flag
bits for "Push Directory" (PD) and "Complete Push" (CP) and to create
a sub-registry in the TRILL Parameters Registry as follows:
Sub-Registry: ESADI-Parameter APPsub-TLV Flag Bits
Registration Procedures: Expert Review
References: [ESADI], This document
Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 UN Supports Unicast ESADI [ESADI]
1 PD Push Directory Server This document
2 CP Complete Push This document
3-7 - available for allocation
The CP bit is ignored if the PD bit is zero.
In addition, the ESADI-Parameter APPsub-TLV is optionally extended,
as provided in its original specification in [ESADI], by one byte as
show below:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|R| Priority | (1 byte)
+-+-+-+-+-+-+-+-+
| CSNP Time | (1 byte)
+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+---------------+
|PushDirPriority| (optional, 1 byte)
+---------------+
| Reserved for expansion (variable)
+-+-+-+-...
The meanings of all the fields are as specified in [ESADI] except
that the added PushDirPriority is the priority of the advertising
ESADI instance to be a Push Directory as described in Section 2.3. If
L. Dunbar, et al [Page 31]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
the PushDirPriority field is not present (Length = 3) it is treated
as if it were 0x40. 0x40 is also the value used and placed here by an
RBridge priority to be a Push Directory has not been configured.
8.2 RBridge Channel Protocol Number
IANA is requested to allocate a new RBridge Channel protocol number
for "Pull Directory Services" from the range allocable by Standards
Action and update the table of such protocol number in the TRILL
Parameters Registry referencing this document.
8.3 The Pull Directory and No Data Bits
IANA is requested to allocate two currently reserved bits in the
Interested VLANs field of the Interested VLANs sub-TLV (suggested
bits 18 and 19) and the Interested Labels field of the Interested
Labels sub-TLV (suggested bits 6 and 7) [RFC6326bis] to indicate Pull
Directory server (PD) and No Data (ND) respectively. These bits are
to be added to the subregistry created by [ESADI] with this document
as reference.
In the TRILL base protocol [RFC6325] as extended for FGL [rfcFGL],
the mere presence of an Interested VLANs or Interested Labels sub-
TLVs in the LSP of an RBridge indicates connection to end stations in
the VLANs or FGLs listed and thus a desire to receive multi-
destination traffic in those Data Labels. But, with Push and Pull
Directories, advertising that you are a directory server requires
using these sub-TLVs for the Data Label you are serving. If such a
directory server does not wish to received multi-destination TRILL
Data packets for the Data Labels it lists in one of these sub-TLVs,
it sets the "No Data" (ND) bit to one. This means that data on a
distribution tree may be pruned so as not to reach the "No Data"
RBridge as long as there are no RBridges interested in the Data who
are beyond the "No Data" RBridge. This bit is backwards compatible
as RBridges ignorant of it will simply not prune when they could,
which is safe although it may cause increased link utilization.
An example of as RBridge serving as a directory that would not want
multi-destination traffic in some Data Labels might be an RBridge
that does not officer end station service for any of the Data Labels
for which it is serving as a directory and is either (1) a Pull
Directory or (2) a Push Directory for which all of the ESADI traffic
can be handled by unicast [ESADI].
L. Dunbar, et al [Page 32]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
Acknowledgments
The contributions of the following persons are gratefully
acknowledged:
TBD
The document was prepared in raw nroff. All macros used were defined
within the source file.
Normative References
[RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol",
RFC 826, November 1982.
[RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
Reverse Address Resolution Protocol", STD 38, RFC 903, June
1984
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC3971] - Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
5310, February 2009.
[RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for
Layer-2 Systems", RFC 6165, April 2011.
[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC5342bis] - Eastlake 3rd, D., "IANA Considerations and IETF
Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342,
September 2008.
[RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and
L. Dunbar, et al [Page 33]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
A. Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-rfc6326bis,
work in progress.
[RFCclear] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, A.
Banerjee, draft-ietf-trill-clear-correct-06.txt, in RFC
Editor's queue.
[Channel] - D. Eastlake, V. Manral, Y. Li, S. Aldrin, D. Ward,
"TRILL: RBridge Channel Support", draft-ietf-trill-rbridge-
channel-08.txt, in RFC Editor's queue.
[RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt,
"TRILL: Fine-Grained Labeling", draft-ietf-trill-fine-
labeling-07.txt, in RFC Editor's queue.
[ESADI] - Zhai, H., F. Hu, R. Perlman, D. Eastlake, O. Stokes, "TRILL
(Transparent Interconnection of Lots of Links): The ESADI (End
Station Address Distribution Information) Protocol",
draft-ietf-trill-esadi, work in progress.
[IA] - Eastlake, D., L. Yizhou, R. Perlman, "TRILL: Interface
Addresses APPsub-TLV", draft-eastlake-trill-ia-appsubtlv, work
in progress.
Informational References
[RFC5227] - Cheshire, S., "IPv4 Address Conflict Detection", RFC
5227, July 2008.
[DirectoryFramework] - Dunbar, L., D. Eastlake, R. Perlman, I.
Gashinsky, "TRILL Edge Directory Assistance Framework",
draft-ietf-trill-directory-framework, in RFC Editor's queue.
[ChannelTunnel] - D. Eastlake, Y. Li, "TRILL: RBridge Channel Tunnel
Protocol", draft-eastlake-trill-channel-tunnel, work in
progress.
[ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large
Data Centers", Oct 2010.
L. Dunbar, et al [Page 34]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
Authors' Addresses
Linda Dunbar
Huawei Technologies
5430 Legacy Drive, Suite #175
Plano, TX 75024, USA
Phone: (469) 277 5840
Email: ldunbar@huawei.com
Donald Eastlake
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: 1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054-1549 USA
Phone: +1-408-765-8080
Email: Radia@alum.mit.edu
Igor Gashinsky
Yahoo
45 West 18th Street 6th floor
New York, NY 10011
Email: igor@yahoo-inc.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012 China
Phone: +86-25-56622310
Email: liyizhou@huawei.com
L. Dunbar, et al [Page 35]
INTERNET-DRAFT TRILL: Directory Assist Mechanisms
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
L. Dunbar, et al [Page 36]
