One document matched: draft-ietf-trill-adj-02.txt
Differences from draft-ietf-trill-adj-01.txt
TRILL Working Group Donald Eastlake 3rd
INTERNET-DRAFT Huawei
Intended status: Proposed Standard Radia Perlman
Updates: RFCtrill Intel Labs
Anoop Ghanwani
Brocade
Dinesh G. Dutt
Cisco Systems
Vishwas Manral
IP Infusion
Expires: August 6, 2011 February 7, 2011
RBridges: Adjacency
<draft-ietf-trill-adj-02.txt>
Abstract
The IETF TRILL protocol provides optimal pair-wise data forwarding
without configuration, safe forwarding even during periods of
temporary loops, and support for multipathing of both unicast and
multicast traffic. TRILL accomplishes this by using IS-IS link state
routing and by encapsulating traffic using a header that includes a
hop count. Devices that implement TRILL are called RBridges.
TRILL supports multi-access LAN links that can have multiple end
stations and RBridges attached. This document describes the TRILL LAN
Hello protocol used on such links as regards adjacency, designated
RBridge selection, and MTU procedures, with state machines. There is
no change for IS-IS point-to-point Hellos used on links configured as
point-to-point in TRILL.
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 <rbridge@postel.org>.
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
D. Eastlake, et al [Page 1]
INTERNET-DRAFT RBridges: Adjacency
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Acknowledgements
The authors of [RFCtrill] and those listed in the Acknowledgements
section of [RFCtrill] are hereby acknowledged by reference. The
contributions of Les Ginsberg and Mike Shand are also acknowledged.
D. Eastlake, et al [Page 2]
INTERNET-DRAFT RBridges: Adjacency
Table of Contents
1. Introduction............................................4
1.1 Content and Precedence.................................4
1.2 Terminology and Acronyms...............................5
1.2 Conventions used in this document......................5
2. The TRILL Hello Environment and Purposes................6
2.1 Incrementally Replacing 802.1Q-2005 Bridges............6
2.2 Handling Native Frames.................................7
2.3 Zero or Minimal Configuration..........................8
2.4 MTU Robustness.........................................8
2.5 Purposes of the TRILL Hello Protocol...................8
3. Adjacency State Machinery..............................10
3.1 TRILL LAN Hellos, MTU Test, and VLANs.................10
3.2 Adjacency Table Entries and States....................10
3.3 Adjacency Events......................................11
3.4 Adjacency State Diagram and Table.....................13
3.5 Multiple Parallel Links...............................14
3.6 Insufficient Space in Adjacency Table.................15
4. RBridge LAN Ports and DRB State........................16
4.1 Port Table Entries and DRB Election State.............16
4.2 DRB Election Events...................................17
4.3 State Table and Diagram...............................18
5. MTU Matching...........................................19
6. Pseudonodes............................................20
7. TRILL Hello Reception and Transmission.................21
7.1 Receiving TRILL Hellos................................21
7.2 Transmitting TRILL Hellos.............................22
8. Multiple Ports on the Same Link........................24
9. Security Considerations................................24
10. IANA Considerations...................................24
11. References............................................25
11.1 Normative References.................................25
11.2 Informative References...............................25
D. Eastlake, et al [Page 3]
INTERNET-DRAFT RBridges: Adjacency
1. Introduction
The IETF TRILL protocol [RFCtrill] provides optimal pair-wise data
frame forwarding without configuration, safe forwarding even during
periods of temporary loops, and support for multipathing of both
unicast and multicast traffic. TRILL accomplishes this by using [IS-
IS] link state routing and encapsulating traffic using a header that
includes a hop count. The design supports VLANs and optimization of
the distribution of multi-destination frames based on VLANs and IP
derived multicast groups. Devices that implement TRILL are called
RBridges.
The purpose of this document is to improve the quality of the
description of the TRILL LAN Hello protocol which RBridges use on
broadcast (LAN) links. It includes reference implementation details.
Alternative implementations that interoperate on the wire are
permitted. There is no change for IS-IS point-to-point Hellos used on
links configured as point-to-point in TRILL.
The scope of this document is limited to the following aspects of the
TRILL LAN Hello protocol:
- Adjacency formation
- DRB (aka DIS) election
- Rules for two-way and MTU matching for advertisements
- Creation and use of pseudo-nodes
For other aspects of the TRILL base protocol see [RFCtrill].
1.1 Content and Precedence
Section 2 below explains the rationale for the differences between
the TRILL LAN Hello protocol and the Layer 3 IS-IS LAN Hello protocol
[IS-IS] [RFC1195] in light of the environment for which the TRILL
protocol is designed. It also describes the purposes of the TRILL LAN
Hello protocol.
Section 3 describes the adjacency state machine and its states and
relevant events.
Section 4 describes the Designated RBridge (DRB) election state
machine for RBridge ports and its states and relevant events.
Section 5 describes MTU testing and matching on a TRILL link.
D. Eastlake, et al [Page 4]
INTERNET-DRAFT RBridges: Adjacency
Section 6 discusses pseudonode creation and use.
Section 7 provides more details on the reception and transmission of
TRILL LAN Hellos.
Section 8 discusses multiple ports from one RBridge on the same link.
While no change in the technical provisions of [RFCtrill] is
intended, in case of conflict, this document prevails.
1.2 Terminology and Acronyms
This document uses the acronyms defined in [RFCtrill] supplemented by
the following additional acronym:
SNPA - Sub-Network Point of Attachment
1.2 Conventions used in this document
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 [RFC2119].
D. Eastlake, et al [Page 5]
INTERNET-DRAFT RBridges: Adjacency
2. The TRILL Hello Environment and Purposes
[IS-IS] has subnetwork independent functions and subnetwork dependent
functions. Currently Layer 3 use of IS-IS supports two types of
subnetworks: point-to-point link subnetworks between routers and
general broadcast (LAN) subnetworks. Because of the differences
between the environment of Layer 3 routers and the environment of
TRILL RBridges, instead of the broadcast (LAN) subnetwork dependent
functions encountered at Layer 3, which are specified in [IS-IS]
Section 8.4, the TRILL protocol uses different subnetwork dependent
functions for a LAN subnetwork. The environmental differences are
described in Sections 2.1 through 2.4 below followed by a summation,
in Section 2.5, of the purposes of the TRILL LAN Hello protocol.
2.1 Incrementally Replacing 802.1Q-2005 Bridges
RBridges can incrementally replace IEEE [802.1Q-2005] bridges. Thus
RBridges need to provide similar services, including delivery of
frames only to links in the frame's VLAN and priority queuing of
frames, to the extent that multiple queues are implemented at any
particular RBridge port.
RBridge ports are IEEE [802.1Q-2005] ports in terms of their frame
VLAN and priority configuration and processing as described in
Section 2.6 of [RFCtrill]. When a frame is received through an
RBridge port, like a frame received through any [802.1Q-2005] port,
it has an associated VLAN ID and frame priority. When a frame is
presented to an [802.1Q-2005] port for queuing and transmission, it
must be accompanied by a VLAN ID and frame priority, although whether
the frame, if actually transmitted, will be VLAN tagged is determined
by whether the port is configured to "strip VLAN tags" in that case.
Furthermore, in the general case, a broadcast (LAN) link between
RBridges can be a VLAN-capable bridged LAN that may be configured to
partition VLANs.
Because devices that restrict VLAN connectivity, such as bridged LANs
or provider bridging equipment, can be part of the link between
RBridges, TRILL Data and TRILL IS-IS frames between RBridges use the
link's Designated VLAN. The Designated VLAN is dictated for a link by
the elected Designated RBridge (equivalent to the Designated
Intermediate System at Layer 3). Because TRILL Data frames flow
between RBridges on a link only in the link's Designated VLAN,
adjacency for routing calculations is based only on connectivity
characteristics in that VLAN.
D. Eastlake, et al [Page 6]
INTERNET-DRAFT RBridges: Adjacency
2.2 Handling Native Frames
Layer 3 packets are already "tamed" when they are originated by an
end station: they include a TTL and layer 3 source and destination
addresses. Furthermore, there is no requirement to preserve their
outer layer 2 addressing and, at least for unicast packets, they are
addressed to their first hop router. In contrast, RBridges running
TRILL must accept, transport, and deliver untamed "native" frames (as
defined in Section 1.4 of [RFCtrill]). Native frames lack a TRILL TTL
field. Native frames also have layer 2 addresses that are used as the
basis for their forwarding and which must be preserved for delivery
to their destination. One resulting difference is that RBridge ports
must receive in promiscuous MAC address mode while Layer 3 router
ports typically receive in a regularly selective MAC address mode.
TRILL handles this by having, on the link where an end station
originated a native frame, one RBridge "ingress" that native frame by
adding a TRILL Header that includes a hop count, thus converting it
to a TRILL Data frame. This augmented frame is then routed to one
RBridge on the link having the destination end-station for the frame
(or one RBridge on each such link if it is a multi-destination
frame). Such final RBridges perform an "egress" function, removing
the TRILL Header and delivering the original frame to its
destination(s). (For the purposes of TRILL, a Layer 3 router is an
end station.)
Great care must be taken to avoid a loop that would involve egressing
a native frame and then re-ingressing it because, while it is in
native form, it would not be protected by a hop count. Such a loop
could involve multiplication of the number of frames each time around
and would likely saturate all links involved within milliseconds. For
TRILL, safety against such loops for a link is more important than
data connectivity on that link.
The primary TRILL defense mechanism against such loops, which is
mandatory, is to assure that, as far as practically possible, there
is only a single RBridge on each link that is in charge of ingressing
and egressing native frames from and to that link. This is the
Designated RBridge which is elected using TRILL LAN Hellos as further
described in Sections 2.5 and 4 below.
Because bridged LANs between RBridges can be configured in complex
ways, including so as to pass frames in some VLANs in one direction
only, and loop safety is so important, there are additional TRILL
defenses against loops, where the looping traffic is in native format
for part of the loop, that are beyond the scope of this document.
These additional defenses have no effect on adjacency states or the
receipt or forwarding of TRILL Data frames, they only affect native
frame ingress and egress.
D. Eastlake, et al [Page 7]
INTERNET-DRAFT RBridges: Adjacency
2.3 Zero or Minimal Configuration
RBridges are expected to provide service with zero configuration,
except for services such as non-default VLAN or priority that require
configuration when offered by [802.1Q-2005] bridges. This differs
from Layer 3 routing where routers typically need to be configured as
to the subnetworks connected to each port, etc., to provide service.
2.4 MTU Robustness
TRILL IS-IS needs to be robust against links with reasonably
restricted MTUs, including links that accommodate only classic
Ethernet frames, despite the addition of reasonable headers such as
VLAN tags. This is particularly true for TRILL LAN Hellos so as to
assure that a unique DRB is elected.
TRILL will also be used inside data centers where it is not uncommon
for all of the links and switches to support frames substantially
larger than the classic Ethernet maximum. For example they may have
an MTU adequate to comfortably handle Fiber Channel over Ethernet
frames, for which T11 recommends a 2,500 byte MTU [FCoE]. It would be
beneficial for an RBridge campus with such a larger MTU to be able to
safely make use of it.
These needs are met by limiting the size of TRILL LAN Hellos and by
the use of MTU testing as described below.
2.5 Purposes of the TRILL Hello Protocol
There are three purposes for the TRILL Hello protocol as listed below
along with a reference to the Section of this document in which each
is discussed:
a) To determine which RBridge neighbors have acceptable connectivity
to be reported as part of the topology (Section 3)
b) To elect a unique Designated RBridge on the link (Section 4)
c) To determine the MTU with which it is possible to communicate with
each RBridge neighbor (Section 5)
In Layer 3 IS-IS all three of these functions are combined. Hellos
may be padded to the maximum length (see [RFC3719], Section 6) so
that a router neighbor is not even discovered if it is impossible to
communicate with it using maximum sized packets. Also, even if Hellos
from a neighbor R2 are received by R1, if connectivity to R2 is not
D. Eastlake, et al [Page 8]
INTERNET-DRAFT RBridges: Adjacency
2-way (i.e., R2 does not list R1 in R2's Hello), then R1 does not
consider R2 as a Designated Router candidate. Because of this logic,
it is possible at Layer 3 for multiple Designated Routers to be
elected on a LAN, with each representing the LAN as a pseudonode. It
appears to the topology as if the LAN is now two or more separate
LANs. Although this is surprising, it does not disrupt Layer 3 IS-IS.
In contrast, this behavior is not acceptable for TRILL, since in
TRILL it is essential that all RBridges on the link know about each
other, and choose a single RBridge to be the DRB and to control the
native frame ingress and egress on that link. Otherwise, multiple
RBridges might encapsulate/decapsulate the same native frame, forming
loops that are not protected by the hop count in the TRILL header as
discussed above.
So, the TRILL Hello protocol is best understood by focusing on each
of these functions separately.
One other issue with TRILL LAN Hellos is to ensure that subsets of
the information can appear in any single message, and be processable,
in the spirit of IS-IS LSPs and CSNPs. TRILL Hello frames, even
though they are not padded, can become very large. An example where
this might be the case is when some sort of backbone technology
interconnects hundreds of TRILL sites over what would appear to TRILL
to be a giant Ethernet, where the RBridges connected to that cloud
will perceive that backbone to be a single link with hundreds of
neighbors. Thus the TRILL Hellos uses a different Neighbor TLV
[RFCtisis] that lists neighbors seen for a range of MAC (SNPA)
addresses.
D. Eastlake, et al [Page 9]
INTERNET-DRAFT RBridges: Adjacency
3. Adjacency State Machinery
Each RBridge port has associated with it a table of zero or more
adjacencies. The sub-sections below give the states such adjacencies
can have, the events that cause state changes, the actions associated
with those state changes, and a state table and diagram.
3.1 TRILL LAN Hellos, MTU Test, and VLANs
The determination of LSP reported adjacencies on links that are not
configured as point-to-point is made using TRILL LAN Hellos (see also
Section 7) and an optional MTU test. Appropriate TRILL LAN Hello
exchange and the satisfaction of the MTU test (see Section 5), if the
MTU test is enabled, is required for there to be an adjacency that
will be reported in an LSP of the RBridge in question.
Because bridges acting as glue on the LAN might be configured in such
a way that some VLANs are partitioned, it is necessary for RBridges
to transmit Hellos with multiple VLAN tags. The conceptually simplest
solution may have been to have all RBridges transmit up to 4,094
times as many Hellos, one with each legal VLAN ID enabled at each
port, but this would obviously have deleterious performance
implications. So, the TRILL protocol specifies that if RB1 knows it
is not DRB, it transmits its Hellos on only a limited set of VLANs,
and only an RBridge that believes itself to be DRB on a port "sprays"
its TRILL Hellos on all of its enabled VLANs at a port (with the
ability to configure to send on only a subset of those). The details
are given in [RFCtrill] Section 4.4.3.
The MAC address (SNPA) of an RBridge port MUST NOT be used as the MAC
address of a port of any other RBridge on the same link. However, if
a particular RBridge has more than one port on a link, those ports
may use the same MAC address (see Section 8); they can distinguished
by the Port ID field in the TRILL Hellos sent on them.
All TRILL LAN Hellos issued by an RBridge on a particular port MUST
have the same source MAC address, priority, desired Designated VLAN,
and Port ID regardless of the VLAN in which the Hello is sent. Of
course, the priority and desired Designated VLAN can change on
occasion, but then the new value must similarly be used in all TRILL
Hellos on the port, regardless of VLAN.
3.2 Adjacency Table Entries and States
Each adjacency is in one of the following four states:
D. Eastlake, et al [Page 10]
INTERNET-DRAFT RBridges: Adjacency
Down:
This is a virtual state for convenience in creating state
diagrams and tables. It indicates that the adjacency is non-
existent and there is no entry in the adjacency table for it.
Detect:
An adjacent neighbor has been detected either (1) not on the
Designated VLAN or (2) on the Designated VLAN but neither 2-way
connectivity nor the MTU of such connectivity has been
confirmed.
2-Way:
2-way connectivity to the neighbor has been found on the
Designated VLAN but MTU testing is enabled and has not yet
confirmed that the connectivity meets the campus minimum MTU
requirement.
Report:
There is 2-way connectivity to the neighbor on the Designated
VLAN and either MTU testing has confirmed that the connectivity
meets the campus minimum MTU requirement or MTU testing is not
enabled. This connectivity will be reported in an LSP (with
appropriate provision for the link pseudonode, if any).
For an adjacency in any of the three non-down states (Detect, 2-Way,
and Report), there will be an adjacency table entry. That entry will
give the state of the adjacency and will also include the information
listed below.
o The address of the neighbor (that is, its SNPA), usually a
48-bit MAC address, and the Port ID in the received Hellos.
Together, these quantities uniquely identify the adjacency.
o Exactly two Hello holding timers, each consisting of an 16-bit
unsigned integer number of seconds: a Designated VLAN holding
timer and a non-Designated VLAN holding timer.
o The 7-bit unsigned priority of the neighbor to be DRB.
o The VLAN that the neighbor RBridge wants to be the Designated
VLAN on the link.
3.3 Adjacency Events
The following events can change the state of an adjacency:
Events:
D. Eastlake, et al [Page 11]
INTERNET-DRAFT RBridges: Adjacency
A1. Receive a TRILL LAN Hello on the Designated VLAN with a TRILL
Neighbor TLV that explicitly lists the receiver's address
(SNPA)
A2. Receive a TRILL LAN Hello that either (1) is not on the
Designated VLAN (any TRILL Neighbor TLV in such a Hello is
ignored) or (2) is on the Designated VLAN but does not contain
a TRILL Neighbor TLV covering an address range including the
receiver's address (SNPA)
A3. Receive a TRILL LAN Hello on the Designated VLAN with one or
more TRILL Neighbor TLVs covering an address range including
the receiver's address (SNPA) none of which lists the receiver
A4. The expiration of one or both Hello holding timers results in
them both being expired
A5. The Designated VLAN Hello holding timer expires but the non-
Designated VLAN Hello holding timer still has time left until
it expires
A6. MTU test successful
A7. MTU test was successful but now fails
A8. The RBridge port goes operationally down
The receipt of a TRILL LAN Hello, that is the occurrence of events
A1, A2, or A3, causes the following actions (except where the Hello
would create a new adjacency table entry, the table is full, and the
Hello is too low a priority to displace an existing entry as
described in Section 3.6). The Designated VLAN used in these actions
is the Designated VLAN dictated by the DRB determined without taking
the received TRILL LAN Hello into account (see Section 4).
o If the receipt of the Hellos creates a new adjacency table
entry, the neighbor RBridge MAC address (SNPA) and Port ID are
set from the Hello.
o The appropriate Hello holding timer for the adjacency,
depending on whether the Hello was received on the Designated
VLAN or not, is set to the Holding Time field of the Hello. If
the receipt of the Hello is creating a new adjacency table
entry, the other timer is set to expired.
o The priority of the neighbor RBridge to be DRB is set to the
priority field of the Hello.
o The VLAN that the neighbor RBridge wants to be the Designated
VLAN on the link is set from the Hello.
D. Eastlake, et al [Page 12]
INTERNET-DRAFT RBridges: Adjacency
o If the creation of a new adjacency table entry or the priority
update above changes the results of the DRB election on the
link, the appropriate RBridge port event (D3 or D4) occurs,
after the above actions, as described in Section 4.2.
Concerning events A6 and A7, if MTU testing is not enabled, A6 is
considered to occur immediately upon the adjacency entering the 2-Way
state and A7 cannot occur.
See further TRILL LAN Hello receipt detail in Section 7.
3.4 Adjacency State Diagram and Table
The table below shows the transitions between the states defined
above based on the events defined above:
| Event | Down | Detect | 2-Way | Report |
+-------+--------+--------+--------+--------+
| A1 | 2-Way | 2-Way | 2-Way | Report |
| A2 | Detect | Detect | 2-Way | Report |
| A3 | Detect | Detect | Detect | Detect |
| A4 | N/A | Down | Down | Down |
| A5 | N/A | Detect | Detect | Detect |
| A6 | N/A | N/A | Report | Report |
| A7 | N/A | N/A | 2-Way | 2-Way |
| A8 | Down | Down | Down | Down |
N/A indicates that the event to the left is Not Applicable in the
state at the top of the column.
Below is the same information as that in the state table presented as
a diagram:
D. Eastlake, et al [Page 13]
INTERNET-DRAFT RBridges: Adjacency
+---------------+
| Down |<--------+
+---------------+ |
| | ^ | |
A2,A3| |A8| |A1 |
| +--+ | |
| +-----------|---+
V | |
+----------------+ A4,A8 | |
+----->| Detect |------->| |
| +----------------+ | |
| | | ^ | |
| A1| |A2,A3,A5 | | |
| | +---------+ | |
| | | |
| | +------------|---+
| | | |
| V V |
|A3,A5 +----------------+ A4,A8 |
|<-----| 2-Way |------->|
| +----------------+ |
| | ^ | ^ |
| A6| | |A1,A2,A7| |
| | | +--------+ |
| | | |
| | |A7 |
| V | |
|A3,A5 +-------------+ A4,A8 |
|<-----| Report |---------->|
+-------------+
| ^
|A1,A2,A6 |
+---------+
3.5 Multiple Parallel Links
There can be multiple parallel adjacencies between neighbor RBridges
that are visible to TRILL. (Multiple low level links that have been
bonded together by technologies such as link aggregation [802.1AX]
appear to TRILL as a single link over which a single adjacency could
be established.)
Any such links that have pseudonodes (see Section 6) are
distinguished in the topology and such adjacencies, if they are in
the Report state, appear in LSPs as per [IS-IS]. However, there can
be multiple parallel adjacencies without pseudonodes because they are
point-to-point adjacencies or TRILL LAN adjacencies for which a
pseudonode is not being created. Such parallel non-pseudonode
D. Eastlake, et al [Page 14]
INTERNET-DRAFT RBridges: Adjacency
adjacencies in the Report state appear in LSPs as a single adjacency.
The cost of such an adjacency MAY be adjusted downwards to account
for the parallel paths. Multipathing across such parallel
connections can be freely done for unicast TRILL Data traffic on a
per flow basis but is restricted for multi-destination traffic, as
described in [RFCtrill] Section 4.5.2, point 3, and Appendix C.
3.6 Insufficient Space in Adjacency Table
If a TRILL LAN Hello would create a new adjacency table entry, that
is, would transition an adjacency out of the Down state, there may be
no space for the new entry. In that case, the DRB election priority
(see Section 4.2) of the new entry that would be created is compared
with that priority for the existing entries. If the new entry is
higher priority than the lowest priority existing entry, it replaces
the lowest priority existing entry, which is transitioned to the Down
state (see Section 3).
D. Eastlake, et al [Page 15]
INTERNET-DRAFT RBridges: Adjacency
4. RBridge LAN Ports and DRB State
The information at an RBridge associated with each of its LAN ports
includes the following:
o Enablement bit, which defaults to enabled.
o SNPA (usually a 48-bit MAC address) of the port.
o Port ID, used in TRILL Hellos sent on the port.
o The Holding Time, used in TRILL Hellos sent on the port.
o The Priority to be DRB, used in TRILL Hellos sent on the port.
o The DRB status of the port, determined as specified below.
o The desired Designated VLAN. The VLAN this RBridge wants to be
the Designated VLAN for the link out this port, used in TRILL
Hellos sent on the port.
o A table of zero or more adjacencies (see Section 3).
4.1 Port Table Entries and DRB Election State
The TRILL equivalent of the DIS (Designated Intermediate System) on a
link is the DRB or Designated RBridge. The DRB election state
machinery is described below.
Each RBridge port is in one of the following four DRB states:
Down:
The port is operationally down. It might be administratively
disabled or down at the link layer. In this state, Hellos are
not accepted on the port and there will be no adjacency table
entries for the port.
Pre-DRB:
The port has become DRB but is in a pre-forwarding state with
regard to native frames and is inhibited from ingressing or
egressing them.
DRB:
The port is DRB and may ingress and egress native frames.
Not DRB:
The port is deferring to another port on the link which it
believes is DRB.
D. Eastlake, et al [Page 16]
INTERNET-DRAFT RBridges: Adjacency
4.2 DRB Election Events
The following events can change the DRB state of a port:
Events:
D1. Enablement of the port.
D2. Expiration of the pre-forwarding timer.
D3. Adjacency table for the port changes and there are now one or
more other RBridge ports on the link that appear to be higher
priority to be DRB than the local port.
D4. Adjacency table for the port changes and there are now no
other RBridge ports on the link that appear to be higher
priority to be DRB than the local port.
D5. The port becomes operationally down.
Events D1 and D4 cause a pre-forwarding timer associated with the
port to be set to the port Holding Time. When the pre-forwarding
timer for a port expires, it causes an event D2 for that port.
Event D1 is considered to occur on RBridge boot if the port is
administratively and link layer enabled.
Determination of events D3 and D4 occurs by comparing priorities
(with neighbor MAC address (SNPA) as a tie breaker and Port ID as a
secondary tie breaker) across all entries in the port's adjacency
table including those in the Detect and 2-Way states as well as those
in the Report state. The quantities compared are considered to be
unsigned integers with a larger value indicating higher priority.
Events D3 and D4 result from a change in the apparent DRB on the
link. The normal case is that all RBridge ports on the link would be
configured with the same desired Designated VLAN. However, if the
change in apparent DRB results in a change in Designated VLAN, then,
for all adjacency table entries for that port, the following steps
occur in the order given:
o The non-Designated VLAN Hello Holding timer is set to the
maximum of its time to expiration and the time to expiration of
the Designated VLAN Hello Holding timer.
o If the Designated VLAN Hello Holding timer has expired, skip
this step. If the Designated VLAN Hello Holding timer is not
expired, it is set to expired and an event A5 occurs for the
adjacency (see Section 3.3).
D. Eastlake, et al [Page 17]
INTERNET-DRAFT RBridges: Adjacency
4.3 State Table and Diagram
The table below shows the transitions between the DRB states defined
above based on the events defined above:
| Event | Down | Pre-DRB | DRB | Not DRB |
+-------+---------+---------+---------+---------+
| D1 | Pre-DRB | N/A | N/A | N/A |
| D2 | Down | DRB | N/A | Not DRB |
| D3 | N/A | Not DRB | Not DRB | Not DRB |
| D4 | N/A | Pre-DRB | DRB | Pre DRB |
| D5 | Down | Down | Down | Down |
N/A indicates that the event to the left is Not Applicable in the
state at the top of the column.
Below is the same information as in the state table presented as a
diagram:
+-----------+
| Down |<---------+
+-----------+ |
| | ^ |
D1| |D2| |
| +--+ |
| |
V |
+--------------+ D5 |
| Pre-DRB |------->|
+-+--------+---+ |
| ^ | ^ | |
D3| | |D4| |D2 |
| | +--+ | |
| | | |
| | V |
| | +-------+ D5 |
| | | DRB |------>|
| | +-------+ |
| | | | ^ |
| | D3| |D4| |
| | | +--+ |
| |D4 | |
V | V |
+--------------+ D5 |
| Not DRB |------->|
+--------------+
| ^
|D2,D3|
+-----+
D. Eastlake, et al [Page 18]
INTERNET-DRAFT RBridges: Adjacency
5. MTU Matching
The purpose of MTU testing is to ensure that the links used in the
campus topology can pass TRILL IS-IS frames at the RBridge campus
MTU.
An RBridge, RB1, determines the desired campus link MTU by
calculating the minimum of its originatingL1LSPBufferSize and the
originatingL1LSPBufferSize of other RBridges in the campus, as
advertised in the link state database, but not less than 1,470 bytes.
Although originatingL1LSPBufferSize in Layer 3 [IS-IS] is limited to
the range 512 to 1,492 bytes inclusive, in TRILL it is limited to the
range 1,470 to 65,535 bytes inclusive.
Although MTU testing is optional, it is mandatory for an RBridge to
respond to an MTU-probe PDU with an MTU-ack PDU [RFCtrill]
[RFCtisis].
RB1 can test the MTU size to RB2 as described in Section 4.3.2 of
[RFCtrill]. For this purpose, MTU testing is only done in the
Designated VLAN. An adjacency that fails the MTU test at the campus
MTU will not enter the "Report" state or, if the adjacency is in that
state, it leaves that state. Thus an adjacency failing the MTU test
will not be reported by the RBridge performing the test. Since
inclusion in least cost route computation requires the adjacency to
be reported by both ends, as long as the MTU failure is noticed by
the RBridge at either end of the adjacency, it will not be so used.
If it tests MTU, RB1 lists the largest size for which the MTU test
succeeds or a flag indicating that it fails at the campus MTU, with
the neighbor in RB1's TRILL Neighbor TLV and MAY report this with the
adjacency in an Extended Reachability TLV in RB1's LSP. RB1 MAY
choose to test MTU sizes greater than the desired campus MTU as well
as the desired campus MTU.
Most types of TRILL IS-IS frames, such as LSPs, can make use of the
campus MTU. The exceptions are TRILL Hellos, which must be kept small
for loop safety, and the MTU PDUs whose size must be adjusted
appropriately for the tests being performed.
D. Eastlake, et al [Page 19]
INTERNET-DRAFT RBridges: Adjacency
6. Pseudonodes
The Designated RBridge (DRB), determined as described above, controls
whether a pseudonode will be used on a link.
It is anticipated that many links between RBridges will actually be
point-to-point, in which case using a pseudonode merely adds to the
complexity. If the DRB sets the bypass pseudonode bit in its TRILL
LAN Hellos, the RBridges on the link (including the DRB) just
directly report all their adjacencies on the LAN that are in the
Report state. If the DRB does not set the bypass pseudonode bit in
its TRILL Hellos, then (as in [IS-IS]) it sends LSPs on behalf of the
pseudonode, and all RBridges report only their adjacency to the
pseudonode. Setting the bypass pseudonode bit has no effect on how
LSPs are flooded on a link. It only affects what LSPs are generated.
For example, if RB1 and RB2 are the only RBridges on the link and RB1
is DRB, then if RB1 creates a pseudonode that is used, there are 3
LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, where RB1.25
reports connectivity to RB1 and RB2, and RB1 and RB2 each just say
they are connected to RB1.25. Whereas if DRB RB1 sets the bypass
pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and
RB2 each reporting connectivity to each other.
A DRB SHOULD set the bypass pseudonode bit in its Hellos if it has
not seen at least two simultaneous adjacencies in the Report state
since it last re-booted or was reset by network management.
D. Eastlake, et al [Page 20]
INTERNET-DRAFT RBridges: Adjacency
7. TRILL Hello Reception and Transmission
This section provides further details on the receipt and transmission
of TRILL LAN Hellos.
TRILL LAN Hellos, like all TRILL IS-IS frames, are primarily
distinguished from Layer 3 IS-IS frames by being sent to the All-IS-
IS-RBridges multicast address (01-80-C2-00-00-41). TRILL IS-IS frames
also have the L2-IS-IS Ethertype (0x22F4) and are Ethertype encoded.
Although future extensions to TRILL may include use of Level 2 IS-IS,
[RFCtrill] specifies TRILL using a single Level 1 Area with Area
Address zero (see Section 4.2 of [RFCtisis]).
IS-IS Layer 3 routers are frequently connected to other Layer 3
routers that are part of a different routing domain. In that case,
the externalDomain flag is normally set for the port through which
such a connection is made. The setting of this flag to "true" causes
no IS-IS PDUs to be sent out the port and any IS-IS PDUs received to
be discarded, including Hellos. RBridges operate in a different
environment where all neighbor RBridges merge into a single campus.
For loop safety, RBridges do not implement the externalDomain flag or
implement it with the fixed value "false". They send and receive
TRILL LAN Hellos on every port that is not disabled or configured as
point-to-point.
7.1 Receiving TRILL Hellos
Assuming a frame has the All-IS-IS-RBridges multicast address and
L2-IS-IS Ethertype, it will be examined to see if it appears to be an
IS-IS PDU. If so, and it appears to be a LAN Hello PDU, the following
tests are performed.
o If the Circuit Type field is other than 1, the PDU is
discarded.
o If the PDU does not contain an Area Address TLV or it contains
an Area Address TLV that is other than the single Area Address
zero, it is discarded.
o If the Hello includes a Protocols Supported TLV that does not
list the TRILL NLPID (0xC0), it is discarded.
o If the Hello does not contain an MT Port Capabilities TLV
containing a VLAN-FLAGS sub-TLV [RFCtisis], it is discarded.
o If the maximumAreaAddresses field of the PDU is not 1, it is
discarded.
D. Eastlake, et al [Page 21]
INTERNET-DRAFT RBridges: Adjacency
o If IS-IS authentication is in use on the link and the PDU
either has no Authentication TLV or validation of that
Authentication TLV fails, it is discarded.
If none of the rules in the list above has been satisfied, the frame
is assumed to be a well-formed TRILL Hello received on the link. It
is treated as an event A1, A2, or A3 based on the criteria listed in
Section 3.3.
7.2 Transmitting TRILL Hellos
TRILL LAN Hellos are sent with the same timing as Layer 3 IS-IS LAN
Hellos [IS-IS].
TRILL Hello messages MUST NOT exceed 1,470 octets in length and
SHOULD NOT be padded.
TRILL Hello PDU headers MUST conform to the following:
o Maximum Area Addresses equal to 1.
o Circuit Type equal to 1.
Each TRILL Hello MUST contain (1) a Protocols Supported TLV listing
the TRILL NLPID (0xC0), (2) an Area Addresses TLV listing only the
single Area zero, and (3) an MT Port Capabilities TLV containing a
VLAN-FLAGS sub-TLV [RFCtisis].
The TRILL Neighbor TLV sent in a Hello MUST show the neighbor
information, as sensed by the transmitting RBridge, for the VLAN on
which the Hello is sent. Since implementations conformant to this
document maintain such information on a per VLAN basis only for the
Designated VLAN, such implementations only send the TRILL Neighbor
TLV in TRILL Hellos on the Designated VLAN. If there are no
adjacencies with a non-zero Designated VLAN Hello Holding timer, an
empty TRILL Neighbor TLV MUST be included in each Hello sent on the
designated VLAN. If there are such adjacencies, then the Hello MAY
contain a TRILL Neighbor TLV as described in Section 4.4.2.1 of
[RFCtrill]. To ensure that any RBridge RB2 can definitively determine
whether RB1 can hear RB2, RB1's neighbor list MUST eventually cover
every possible range of IDs, that is, within a period that depends on
RB1's policy and not necessarily within any specific period such as
the holding time. In other words, if X1 is the smallest reported in
one of RB1's neighbor lists, and the "smallest" flag is not set, then
X1 MUST appear in a different neighbor list as well, as the largest
ID reported in that fragment. Or, lists may overlap, as long as there
is no gap, such that some range, say between Xi and Xj, never appears
in any list.
D. Eastlake, et al [Page 22]
INTERNET-DRAFT RBridges: Adjacency
TRILL Hellos MAY contain an Authentication TLV.
D. Eastlake, et al [Page 23]
INTERNET-DRAFT RBridges: Adjacency
8. Multiple Ports on the Same Link
It is possible for an RBridge RB1 to have multiple ports on the same
link. It is important for RB1 to recognize which of its ports are on
the same link. RB1 detects this condition based on receiving TRILL
LAN Hello messages with the same LAN ID on multiple ports.
The DRB election is port-based (see Section 4) and only the Hellos
from the elected port can perform certain functions such as dictating
the Designated VLAN or whether a pseudonode will be used; however,
the election also designates the RBridge with that port as DRB for
the link. An RBridge may choose to load split some tasks among its
ports on the link it if has more than one and it is safe to do so as
described in Section 4.4.4 of [RFCtrill].
9. Security Considerations
This memo provides improved documentation of some aspects of the
TRILL base protocol standard, particularly the TRILL LAN Hello
protocol, and does not change the security considerations of the
TRILL base protocol. See Section 6 of [RFCtrill].
10. IANA Considerations
This document requires no IANA actions. RFC Editor: Please delete
this section before publication.
D. Eastlake, et al [Page 24]
INTERNET-DRAFT RBridges: Adjacency
11. References
Normative and Informational references for this document are listed
below.
11.1 Normative References
[IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to
Intermediate System Intra-Domain Routing Exchange Protocol for
use in Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", 2002.
[RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFCtisis] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A.
Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill, work in
progress.
[RFCtrill] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
trill-rbridge-protocol-16.txt, in RFC Editor's queue.
11.2 Informative References
[802.1AX] - "IEEE Standard for Local and metropolitan area networks /
Link Aggregation", 802.1AX-2008, 1 January 2008.
[FCoE] - From www.t11.org discussion of "FCoE Max Size" generated
from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU".
[RFC3719] - Parker, J., Ed., "Recommendations for Interoperable
Networks using Intermediate System to Intermediate System (IS-
IS)", February 2004.
D. Eastlake, et al [Page 25]
INTERNET-DRAFT RBridges: Adjacency
Authors' Addresses
Donald E. Eastlake, 3rd
Huawei
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
Anoop Ghanwani
Brocade Communications Systems
130 Holger Way
San Jose, CA 95134 USA
Phone: +1-408-333-7149
Email: anoop@brocade.com
Dinesh G. Dutt
Cisco Systems
170 Tasman Drive
San Jose, CA 95134-1706 USA
Phone: +1-408-527-0955
Email: ddutt@cisco.com
Vishwas Manral
IP Infusion Inc.
1188 E. Arques Ave.
Sunnyvale, CA 94089 USA
Tel: +1-408-400-1900
email: vishwas@ipinfusion.com
D. Eastlake, et al [Page 26]
INTERNET-DRAFT RBridges: Adjacency
Copyright and IPR Provisions
Copyright (c) 2011 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 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.
D. Eastlake, et al [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-23 06:04:06 |