TRILL Working Group Donald Eastlake 3rd
INTERNET-DRAFT Stellar Switches
Intended status: Proposed Standard Vishwas Manral
Updates: RFCtrill IP Infusion
Dave Ward
Juniper
Ayan Banerjee
Cisco
Expires: April 16, 2011 October 17, 2010
RBridges: OAM and BFD Support for TRILL
<draft-eastlake-trill-rbridge-bfd-00.txt>
Abstract
This document specifies a general channel for sending OAM
(Operations, Administration, and Maintenance) messages between
RBridges in a campus through an extension to the TRILL (Transparent
Interconnection of Lots of Links) protocol. It further specifies use
of this channel for the BFD (Bidirectional Forwarding Detection)
protocol.
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
D. Eastlake, et al [Page 1]
INTERNET-DRAFT RBridges: OAM and BFD
Table of Contents
1. Introduction............................................3
1.1 Terminology............................................3
1.2 Additional Acronyms....................................3
1.3 Acknowledgements.......................................4
2. The TRILL OAM Message Channel...........................5
2.1 The OAM Message Inner Frame............................5
2.1.1 Inner Ethernet Header................................6
2.1.2 TRILL OAM Header.....................................7
2.2 The TRILL Header for OAM Messages......................8
2.3 OAM Message Ethernet Link Header.......................9
2.4 The TRILL OAM-Channel Bit Option.......................9
2.5 Processing TRILL OAM Messages.........................10
2.5.1 Processing the TRILL OAM Channel Header.............10
2.5.2 Native TRILL-OAM Frames.............................11
3. TRILL BFD..............................................12
3.1 Sessions and Initialization...........................12
3.2 TRILL BFD Control Protocol............................12
3.2.1 One-Hop TRILL BFD Control...........................13
3.2.2 BFD Control Frame Processing........................13
3.3 TRILL BFD Echo Protocol...............................14
3.3.1 BFD Echo Frame Processing...........................14
4. Management and Operations Considerations...............16
5. Allocations Considerations.............................17
5.1 IANA Considerations...................................17
5.2 IEEE Registration Authority Considerations............18
6. Security Considerations................................19
6.1 OAM Channel Security Considerations...................19
6.2 BFD Security Considerations...........................19
7. Normative References...................................21
8. Informative References.................................21
D. Eastlake, et al [Page 2]
INTERNET-DRAFT RBridges: OAM and BFD
1. Introduction
The TRILL IS-IS Hellos used between RBridges provide a basic neighbor
and continuity check for TRILL links [RFCtrill]. However, failure
detection by non-receipt of such Hellos is based on the holding time
parameter which is typically set to a value over ten seconds and, in
any case, has a minimum expressible value of one second.
Many applications, including voice over IP, may wish, with very high
probability, to detect interruptions in continuity within a much
shorter time period. In some cases physical layer failures can be
detected very rapidly but this is not always possible, such as when
there is a failure between two devices that are in turn between two
RBridges, and there are many subtle failures possible at higher
levels. For example, some forms of failure could affect unicast
frames while still letting multicast frames through and all TRILL IS-
IS frames, including Hellos, are multicast. Thus, a method of
frequently testing continuity for the TRILL Data between neighbor
RBridges is necessary for some applications.
Such continuity testing is one example of TRILL data plane
Operations, Administration, and Maintenance (OAM) requirements.
Various of such requirements can be met by a variety of protocols
such as the Bidirectional Forwarding Detection (BFD) [RFC5880]
[RFC5882] and [Y.1731].
This document specifies, in Section 2, a general channel for sending
OAM messages between RBridges in a campus using extensions to the
TRILL protocol and further specifies, in Section 3, use of this
channel for the BFD protocol. TRILL BFD can be used to provide rapid
detection of link continuity failure for TRILL Data frames.
1.1 Terminology
The terminology and acronyms of [RFCtrill] are 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].
1.2 Additional Acronyms
The following acronyms are used in this document in addition to those
defined in [RFCtrill]:
BFD - Bidirectional Forwarding Detection
D. Eastlake, et al [Page 3]
INTERNET-DRAFT RBridges: OAM and BFD
MH - Multi-Hop
OAM - Operations, Administration, and Maintenance
OV - OAM (Message Channel) Version
SL - Silent
1.3 Acknowledgements
The authors would like to particularly thank David Katz, co-author of
[RFC5880] and [RFC5882]. Some of the text is this document was
adapted from those RFCs.
D. Eastlake, et al [Page 4]
INTERNET-DRAFT RBridges: OAM and BFD
2. The TRILL OAM Message Channel
TRILL OAM messages are transmitted as TRILL Data frames. They are
primarily identified as OAM messages by their Inner.MacDA and Inner
Ethertype. This Inner Ethertype is followed by a 32-bit TRILL OAM
Header used to indicate the OAM protocol of the following OAM
protocol specific data. A TRILL Header bit option is provided that
may optionally be used to guarantee that frames sent over the TRILL
OAM Message Channel cannot accidentally be forwarded to end stations,
even by RBridges that are ignorant of the TRILL OAM Message Channel
mechanism.
The diagram below shows the overall structure of a TRILL OAM Message
Channel frame on a link between two RBridges:
Frame Structure Section of This Document
------------------------
+--------------------------------+
| Outer Link Header | Section 2.3 if Ethernet Link
+--------------------------------+
| TRILL Header | Section 2.2
+--------------------------------+
| Inner Ethernet Header | Section 2.1.1
+--------------------------------+
| TRILL OAM Channel Header | Section 2.1.2
+--------------------------------+
| OAM Protocol Specific Payload | See specific OAM protocol
+--------------------------------+
| Link Trailer (FCS if Ethernet) |
+--------------------------------+
The Sections 2.1 and 2.2 below describe the Inner frame and TRILL
Header for frames sent in the TRILL OAM Message Channel. As always,
the Outer link header is whatever is needed to get a TRILL Data frame
from one RBridge to the next, depends on link technology, and can
change with each hop for multi-hop OAM messages. Section 2.3
describes the Outer link header for Ethernet. Section 2.4 goes into
further detail on the OAM-Channel Bit Option. And Section 2.5
describes some details of TRILL OAM Message processing.
2.1 The OAM Message Inner Frame
The encapsulated Inner frame within A TRILL OAM Message Channel frame
is as shown below.
D. Eastlake, et al [Page 5]
INTERNET-DRAFT RBridges: OAM and BFD
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA cont. | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = C-Tag (0x8100) | Priority, VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL OAM Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL-OAM Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | OV | TRILL OAM Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OAM Protocol Specific Information:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ OAM Protocol Specific Data
| ...
2.1.1 Inner Ethernet Header
The special Inner.MacDA is one of two values: OAM-RBridge-MAC if the
OAM message is unicast or All-OAM-RBridges if the OAM message is
multi-destination (see Section 6).
The Inner.MacSA is selected by the RBridge originating the OAM
message. If it is a unicast MAC address, on decapsulation it will be
learned as being attached to the ingress RBridge. If that learning is
not desired, the Inner.MacSA MAY be set to All-OAM-RBridges. Address
learning on decapsulation does not occur if the source MAC has the
group bit on.
As with all TRILL encapsulated frames, a VLAN tag MUST be present.
Use of a VLAN tag Ethertype other than 0x8100 is beyond the scope of
this document. Recommendations for the frame priority are as follows:
- For one-hop known unicast OAM messages critical to network
connectivity, such as one-hop BFD for rapid link failure detection
in support of TRILL IS-IS, the RECOMMENDED priority is 7.
- For multi-hop known unicast OAM messages, the RECOMMENDED priority
is 6.
- For multi-destination OAM messages, it is RECOMMENDED that the
priority be no higher than 5.
D. Eastlake, et al [Page 6]
INTERNET-DRAFT RBridges: OAM and BFD
Multi-destination TRILL OAM messages are VLAN scoped so the
Inner.VLAN ID MUST be set to the VLAN of interest. To the extent that
distribution tree pruning is in effect, such OAM messages will only
reach RBridges advertising that they have appointed forwarder
connectivity to that VLAN.
For known unicast OAM messages, if the message is one-hop it is
RECOMMENDED that the Inner.VLAN ID be the Designated VLAN on that
hop. For multi-hop unicast OAM messages, it is RECOMMENDED that the
Inner.VLAN ID be the default VLAN 1.
2.1.2 TRILL OAM Header
After the TRILL OAM Ethertype (see Section 6) is a four-byte quantity
with three sub-fields. The first, Flags, provides 16 bits of flags
which, except as specified below, MUST be sent as zero, transparently
copied by transit RBridges, and ignored on receipt. The next field,
OV, gives the OAM Header version and MUST be zero. Lastly, a 12-bit
field specified the particular TRILL OAM protocol to which the
message applies. See Section 6 for IANA Considerations.
The flag bits are numbered from 0 to 15 as shown below.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|SL|MH| Available Flags |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Bit 0, which is the high order bit in network order, is defined as
the SL or Silent bit. If it is a one, it suppresses OAM Channel Error
messages due to the use of an unknown version or OAM protocol (see
Section 2.5.1). Bit 1 is the MH or Multi-Hop bit. It is used to
inform the destination OAM protocol that the message was intended to
be multi-hop (MH=1) or one-hop (MH=0).
The TRILL OAM Protocol field specifies the OAM protocol that the OAM
Channel message relates to. Initial defined values are as listed
below. See Section 6 for IANA Considerations.
Protocol Name - Section of this Document
-------- -------------------------------
0x0001 OAM Channel Error - Section 2.5
0x0002 TRILL BFD Control - Section 3.2
0x0003 TRILL BFD Echo - Section 3.3
D. Eastlake, et al [Page 7]
INTERNET-DRAFT RBridges: OAM and BFD
2.2 The TRILL Header for OAM Messages
After the Outer link header (which for Ethernet ends with the TRILL
Ethertype) and before the encapsulated frame, the OAM message's TRILL
Header appears as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0|0 0|M| Op-Len | Hops=0x3F |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TRILL Header version V, MUST be zero, the M bit is set
appropriately as the OAM message is known unicast (M=0) or multi-
destination (M=1), and Op-Len is set appropriately for the length of
the options area, if any, all as specified in [RFCtrill].
When a TRILL OAM message is originated, the hop count field is always
set to the maximum value, 0x3F. For messages sent a known number of
hops, particularly one-hop messages or neighbor echo messages,
checking the Hops (Hop Count) field provides an additional validity
check as discussed in [RFC5082].
The RBridge originating a TRILL OAM message places a nickname that it
holds into the ingress nickname field.
There are several cases for the egress nickname field. If the OAM
message is multi-destination, then the egress nickname designates the
distribution tree to use. If the OAM message is a multi-hop unicast
message, then the egress nickname is a nickname of the target
RBridge; this includes the special case of an "echo" OAM message
where the originator places its own nickname in both the ingress and
egress nickname fields. If the OAM message is a one-hop unicast
message, there are two possibilities for the egress nickname.
o The egress nickname can bet set to a nickname of the target
neighbor RBridge. This will usually work well but there is a small
chance that, due to a nickname transient, the frame will actually
be delivered to some other RBridge in the campus. Due to this
possibility, both here and in the multi-hop unicast case, if a
TRILL OAM message is intended for a specific RBridge in the campus
topology, it is RECOMMENDED that the OAM protocol specific data
include the IS-IS SystemID of the target RBridge for an added
check.
o The special nickname Any-RBridge may be used. This will guarantee
decapsulation at the immediate neighbor RBridge regardless of the
state of nickname assignments. RBridges supporting the TRILL OAM
Channel facility MUST recognize the Any-RBridge special nickname
and accept TRILL Data frames having that value in the egress
D. Eastlake, et al [Page 8]
INTERNET-DRAFT RBridges: OAM and BFD
nickname field as being sent to them as the egress.
2.3 OAM Message Ethernet Link Header
If the link on which a TRILL OAM frame is transmitted between
neighbor RBridges is Ethernet, the link header follows the usual
rules for a TRILL Data frame over Ethernet [RFCtrill]. In particular,
the Outer.MacSA is the MAC address of the port from which the frame
is sent. The Outer.MacDA is the MAC address of the next-hop RBridge
port for unicast TRILL OAM messages or the All-RBridges multicast
address for multi-destination TRILL OAM messages. If an Outer.VLAN
tag is present, it must specify the Designated VLAN for that hop and
the priority must be the same as in the Inner.VLAN tag.
2.4 The TRILL OAM-Channel Bit Option
A critical ingress-to-egress TRILL Header bit option, OAM-Channel, is
specified associated with the TRILL OAM Channel facility. This option
is NOT REQUIRED to appear in the TRILL Header in TRILL OAM message
frames. It serves two functions, as follows:
o An RBridge indicates that it supports the TRILL OAM Channel
facility by advertising, in the link state database, its support
for this bit option.
o If this bit option is present in a TRILL OAM message frame, it
guarantees that, if the inner frame is decapsulated by an RBridge
that does not implement the TRILL OAM Channel it will be discarded
rather than being locally flooded as a native frame out all ports
for which that RBridge is appointed forwarder for the Inner.VLAN.
However, if it is certain that all RBridges in the campus
implement the TRILL OAM Channel or if the possible local flooding
of the inner frame as specified above is acceptable, there is NO
REQUIREMENT to include an options area or to set this particular
option bit in the TRILL Header options area even if an options
area is included.
As with any other critical ingress-to-egress option, if the bit
options area is present and this bit option is set, then the summary
CItE bit MUST be set at the top of the options area.
D. Eastlake, et al [Page 9]
INTERNET-DRAFT RBridges: OAM and BFD
2.5 Processing TRILL OAM Messages
TRILL OAM messages are designed to look like and, to the extent
practical, be processed as regular TRILL Data frames. On receiving a
TRILL OAM frame, the initial tests on the Outer.MacDA, Outer
Ethertype, TRILL Header V and Hop Count fields and the RPF check if
the frame is multi-destination, are all performed as usual. The
forwarding and/or decapsulation decisions are the same as for a
regular TRILL Data frame with the exception that a RBridge
implementing the TRILL OAM Channel MUST recognize the Any-RBridge
egress nickname in unicast TRILL Data frames, decapsulating and not
forwarding such frames if they meet other checks.
If the OAM-Channel critical ingress-to-egress bit option is present
and the egressing RBridge does not implement the TRILL OAM Channel,
the frame is discarded. If other options are present, they may affect
processing or cause the frame to be discarded.
On decapsulation, the special Inner.MacDA values of OAM-RBridge-MAC
(unicast) and All-OAM-RBridges (multicast) and/or the Inner Ethertype
of TRILL-OAM MUST be recognized to trigger processing as a TRILL OAM
message. If the decapsulating RBridge does not implement the TRILL
OAM Channel, it will treat the frame as a regular TRILL Data frame
and locally flood the decapsulated native frame out all ports where
it is appointed forwarder for the Inner.VLAN.
2.5.1 Processing the TRILL OAM Channel Header
Knowing that it has a TRILL OAM Channel message, the egress RBridge
looks at the OV (OAM Message Header version) and OAM Protocol fields.
If the OV field is non-zero or if the OAM Protocol field is a
reserved value or a value unknown to the egress RBridge, the egress
RBridge returns an OAM Channel Error frame unless the "SL" (Silent)
flag is a one in the OAM message. An OAM Channel Error frame is a
multi-hop unicast TRILL OAM Channel message with the ingress nickname
set to the nickname of the RBridge detecting the error, and the
egress nickname set to the value of the ingress nickname in the OAM
message for which the error was detected. For the protocol specific
data area, an OAM Channel Message Error frame has at least the first
256 bytes (or less if less are available) of the erroneous
decapsulated OAM message starting with the Inner.MacDA. All RBridges
implementing the TRILL OAM Message Channel MUST recognize the OAM
Message Channel Error protocol value (0x001) and MUST NOT generate an
OAM Message Channel Error message in response to a received OAM
Message Channel Error frame, even if they always set the "SL" flag is
all TRILL OAM messages they send so they would not normally expect to
receive an OAM Channel Message Error frame.
D. Eastlake, et al [Page 10]
INTERNET-DRAFT RBridges: OAM and BFD
If the OV field is zero and the processing RBridge recognizes the OAM
Protocol value, it processes the message in accordance with that OAM
protocol.
Errors within a recognized OAM Protocol are handled within that
protocol and do not produce OAM Message Channel Error frames.
2.5.2 Native TRILL-OAM Frames
A TRILL OAM Message Channel frame MAY be generated, if provided for
by the OAM protocol involved, as the result of the receipt by an
RBridge of a native frame with the TRILL-OAM Ethertype. Such a native
frame must met the usual VLAN restrictions to be accepted by the
ingress RBridge generating the TRILL OAM Message Channel frame. If
the native frame's destination MAC address is not one of the special
MAC destination addresses All-OAM-RBridges or OAM-RBridge-MAC, it
MUST be changed to one of those two addresses before the frame is
encapsulated.
The decapsulation and processing of a TRILL OAM Message Channel frame
MAY, if provided for by the OAM protocol involved, result in the
sending of a native frame with the TRILL-OAM Ethertype out one or
more ports of the egress RBridge. The VLAN, and the MAC destination
addres, of the frame MAY be set to appropriate values before it is
transmitted.
D. Eastlake, et al [Page 11]
INTERNET-DRAFT RBridges: OAM and BFD
3. TRILL BFD
Using the TRILL OAM Message Channel facility, described in Section 2,
TRILL supports one-hop and multi-hop BFD Control and neighbor BFD
Echo as detailed below. Multi-destination BFD is beyond the scope of
this document.
3.1 Sessions and Initialization
Within an RBridge campus, there will be only a single TRILL BFD
Control session between two RBridges over a given interface visible
to TRILL. This BFD session must be bound to this interface. As
such, both sides of a session MUST take the "Active" role (sending
initial BFD Control packets with a zero value of Your Discriminator),
and any BFD packet from the remote machine with a zero value of Your
Discriminator MUST be associated with the session bound to the remote
system and interface.
Note that TRILL BFD provides OAM facilities for the TRILL Data plane.
This is above whatever protocol is in use on a particular link, such
as PPP [TrillPPP]. Link technology specific OAM protocols may be used
on a link between neighbor RBridges, for example Continuity Fault
Management [802.1ag] if the link is Ethernet. But such link layer OAM
and coordination between it and TRILL data plan layer OAM, such as
TRILL BFD, is beyond the scope of this document.
If lower level mechanisms, such as link aggregation [802.1AX], are in
use that present a single logical interface to TRILL IS-IS, only a
single TRILL BFD session can be established to any other RBridge over
this logical interface. However, link layer OAM could be run
separately on each of the components of a link aggregation.
3.2 TRILL BFD Control Protocol
TRILL BFD Control frames are unicast TRILL OAM Message Channel frames
as described in Section 2 above supplemented by the specifications
below.
As a unicast message, the M bit in the TRILL Header is zero and the
Inner.MacDA is OAM-RBridge-MAC. The TRILL OAM Protocol value is
0x002.
The protocol specific data associated with the TRILL BFD Control
protocol is as shown below. See [RFC5880] for further information on
the fields after the initial SystemIDs.
D. Eastlake, et al [Page 12]
INTERNET-DRAFT RBridges: OAM and BFD
TRILL BFD Control Protocol Data:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target RBridge SystemID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target RBridge SystemID | Orig. RBridge SystemID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating RBridge SystemID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional Authentication Section:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Authentication Data... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1 One-Hop TRILL BFD Control
One-hop TRILL BFD Control is typically used in support of TRILL IS-IS
to rapidly detect link failure. Such TRILL BFD frames SHOULD be sent
with priority 7.
For neighbor RBridges RB1 and RB2, each RBridge sends one-hop TRILL
BFD Control frames to the other only if TRILL IS-IS has detected bi-
directional connectivity and both RBridges indicate support of TRILL
BFD is enabled. The BFD Enabled TLV is used to indicate this as
specified in [RFCbfdtlv]. The indication of TRILL BFD support with
the BFD Enabled TLV overrides any indication of lack of support
through failure to advertise support of the OAM-Channel TRILL Header
bit option in the link state database.
3.2.2 BFD Control Frame Processing
The following tests SHOULD be performed on received TRILL BFD Control
frames before generic BFD processing. (In some implementations, the
TRILL Header may not be available to the TRILL BFD module in which
case some of these check are not possible.)
D. Eastlake, et al [Page 13]
INTERNET-DRAFT RBridges: OAM and BFD
Is the M bit in the TRILL Header non-zero? If so, discard the frame.
TRILL support of multi-destination BFD Control is beyond the scope
of this document.
If the MH OAM Header flag is zero, indicating one-hop, test that the
TRILL Header hop count received was 0x3F (i.e., is 0x3E if it has
already been decremented) and if it is any other value discard the
frame. If the MH OAM flag is one, indicating multi-hop, test that
the TRILL Header hop count received was not less than a
configurable value that defaults to 0x30. If it is less, discard
the frame.
Check that the target IS-IS SystemID in the OAM protocol data is your
SystemID. If not, discard the frame.
If the MH OAM Header flag is zero, test that the originating SystemID
is that of a neighbor RBridge. If not, discard the frame.
3.3 TRILL BFD Echo Protocol
A TRILL BFD Echo frame is a unicast TRILL OAM Message Channel frame,
as specified in Section 2, which should be bounced back by an
immediate neighbor because both the ingress and egress nicknames are
set to a nickname of the originating RBridge. Normal TRILL Data frame
forwarding will cause the frame to be returned.
TRILL BFD Echo frames SHOULD only be sent on a link if a TRILL BFD
Control session has been established, TRILL BFD Echo support is
indicated by the potentially echo responding RBridge, and the TRILL
BFD Echo originating RBridge wishes to make use of this optional
feature.
Since the originating RBridge is the RBridge that will be processing
a returned Echo frame, the entire TRILL BFD Echo protocol specific
data area is considered opaque and left to the discretion of the
originating RBridge. Nevertheless, it is RECOMMENDED that this data
include information by which the originating RBridge can authenticate
the returned BFD Echo frame and confirm the neighbor that echoed the
frame back. For example, it could include its own SystemID, the
neighbor's SystemID, a session identifier and a sequence count as
well as a Message Authentication Code.
3.3.1 BFD Echo Frame Processing
The following tests SHOULD be performed on returned TRILL BFD Echo
frames before other processing. (In some implementations, the TRILL
D. Eastlake, et al [Page 14]
INTERNET-DRAFT RBridges: OAM and BFD
Header may not be available to the TRILL BFD Echo module in which
case these check are not possible.)
Is the M bit in the TRILL Header non-zero? If so, discard the frame.
TRILL support of multi-destination BFD Echo is beyond the scope of
this document.
The TRILL BFD Echo frame should have gone exactly two hops so test
that the TRILL Header hop count as received was 0x3E (i.e., 0x3D
if it has already been decremented) and if it is any other value
discard the frame. (The value of the MH flag is ignored for TRILL
BFD Echo protocol.)
D. Eastlake, et al [Page 15]
INTERNET-DRAFT RBridges: OAM and BFD
4. Management and Operations Considerations
The TRILL BFD parameters at an RBridge are configurable... The
default values are ... TBD.
It is required that the operator of an RBridge campus configure the
rates at which TRILL BFD frames are transmitted on a link to avoid
congestion (e.g., link, I/O, CPU) and false failure detection.
D. Eastlake, et al [Page 16]
INTERNET-DRAFT RBridges: OAM and BFD
5. Allocations Considerations
The following subsection give IANA and IEEE Registration Authority
Considerations.
5.1 IANA Considerations
In this section, the allocation procedures "Standards Action", "IETF
Review", and "RFC Publication" are as specified in [RFC5226].
IANA hereby allocates a previously unassigned TRILL Nickname as
follows:
Any-RBridge TBD (0xFFCO suggested)
IANA hereby allocates a previously unassigned TRILL Multicast address
as follows:
All-OAM-RBridges TBD (01-80-C2-00-00-43 suggested)
IANA hereby allocates a previously unassigned TRILL critical ingress-
to-egress Bit Option as follows:
TBD OAM-Option
IANA allocates the following block of 16 globally unique unicast MAC
addresses for use with the TRILL protocol and creates a sub-registry
in the TRILL Parameter Registry for these addresses:
00-00-5E-xx-xx-x0 - OAM-RBridge-MAC
00-00-5E-xx-xx-x1 to 00-00-5E-xx-xx-xF - available for allocation
(suggested 00-00-5E-00-03-00 through 00-00-5E-00-03-0F)
Allocation of unicast MAC values from the above block for TRILL use
is based on IETF Review.
IANA creates an additional sub-registry in the TRILL Parameter
Registry for TRILL OAM Protocols, with initial contents as follows:
D. Eastlake, et al [Page 17]
INTERNET-DRAFT RBridges: OAM and BFD
Protocol Use
-------- ---
0x000 Reserved
0x001 OAM Channel Error
0x002 BFD Control
0x003 BFD Echo
0x004-0x0FF Available for allocation (1)
0x100-0xFF7 Available for allocation (2)
0xFF8-0xFFE For Experimental use, will not be allocated
0xFFF Reserved
(1) TRILL OAM protocol code points from 0x004 to 0x0FF require an
IETF Standards Action for allocation.
(2) TRILL OAM protocol code points from 0x100 to 0xFF7 require RFC
Publication to allocate a single value or IETF Review to allocate
multiple values.
IANA creates an additional sub-registry in the TRILL Parameter
Registry for TRILL OAM Header Flags with initial contents as follows:
Flag Bit Mnemonic Allocation
-------- -------- ----------
0 SL Silent
1 MH Multi-hop
2-15 - Available for allocation
Allocation of TRILL OAM Header Flags is based on IETF Standards
Action [RFC5226].
5.2 IEEE Registration Authority Considerations
The Ethertype <tbd> is assigned by the IEEE Registration Authority
for TRILL-OAM.
D. Eastlake, et al [Page 18]
INTERNET-DRAFT RBridges: OAM and BFD
6. Security Considerations
The following sections provide security considerations for the TRILL
OAM Message Channel and for TRILL BFD.
See [RFCtrill] for general RBridge Security Considerations.
6.1 OAM Channel Security Considerations
-- TBD --
6.2 BFD Security Considerations
BFD Control frames can be secured by authentication mechanisms native
to BFD [RFC5880].
If shared secret IS-IS authentication is not in effect for the Hellos
exchanged by two neighbor RBridges then, by default, TRILL BFD
between those RBridges is also unsecured.
If shared secret IS-IS authentication is in effect for the Hellos
exchanged by two neighbor RBridges then, by default, TRILL BFD
Control frames sent between those RBridges use BFD Keyed SHA1
authentication with keying material derived as follows:
HMAC-SHA1 ( ( "TRILL BFD Control" | smallerSystemID |
largerSystemID ), IS-IS-key )
where HMAC-SHA1 is as specified in [RFC2104] (see also [RFC4634]),
"TRILL BFD Control" is the seventeen byte US ASCII string indicated
which is then concatenated with the SystemIDs of both of the neighbor
RBridges sorted as unsigned 48-bit integers, and IS-IS-key is the
secret keying material being used for IS-IS authentication on the
link. In the Authentication Section of the BFD Control frame OAM
protocol specific data, Auth Type would be 4, Auth Len would be 28,
and Auth Key ID is zero. The RBridges MAY be configured to use other
BFD security modes or keying material including configuration to use
no security.
Authentication for TRILL BFD Echo SHOULD be provided but is a local
implementation issue as BFD Echo frames are only authenticated by
their sender when received in the form of Echo responses. However, if
TRILL IS-IS and BFD Control are being authenticated to a neighbor and
BFD Echo is in use, BFD Echo frames to be returned by that neighbor
SHOULD be authenticated and such authenticate SHOULD use different
keying material from other types of authentication. For example, it
D. Eastlake, et al [Page 19]
INTERNET-DRAFT RBridges: OAM and BFD
could use keying material derived as follows:
HMAC-SHA1 ( ( "TRILL BFD Echo" | smallerSystemID | largerSystemID
), IS-IS-key )
D. Eastlake, et al [Page 20]
INTERNET-DRAFT RBridges: OAM and BFD
7. Normative References
[RFC2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection
(BFD)", June 2010.
[RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional
Forwarding Detection (BFD)", June 2010.
[RFCtrill] - R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
trill-rbridge-protocol-16.txt, in RFC Editor queue.
[RFCbfdtlv] - C. Hopps, L. Ginsberg, "IS-IS BFD Enabled TLV", draft-
ietf-isis-bfd-tlv-02.txt, work in progress, 4 January 2010.
8. Informative References
[802.1AX] - IEEE, "IEEE Standard for Local and metropolitan area
networks / Link Aggregation", 802.1AX-2008, 1 January 2008.
[802.1ag] - IEEE, "IEEE Standard for Local and metropolitan area
networks / Virtual Bridged Local Area Networks / Connectivity
Fault Management", 802.1ag-2007, 17 December 2007.
[RFC4634] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC
5082, October 2007
[TrillPPP] - Carlson, J., "PPP TRILL Protocol Control Protocol",
draft-ietf-pppext-trill-protocol-01.txt, work in progress, May
2010.
[Y.1731] - ITU-T Recommendation Y.1731 (02/08), "OAM functions and
mechanisms for Ethernet based networks", February 2008
D. Eastlake, et al [Page 21]
INTERNET-DRAFT RBridges: OAM and BFD
Authors' Addresses
Donald Eastlake 3rd
Stellar Switches
155 Beaver Street
Milford, MA 01757 USA
Tel: +1-508-333-2270
EMail: d3e3e3@gmail.com
Vishwas Manral
IP Infusion Inc.
1188 E. Arques Ave.
Sunnyvale, CA 94089 USA
Tel: +1-408-400-1900
EMail: vishwas@ipinfusion.com
Dave Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089-1206
USA
Phone: +1-408-745-2000
EMail: dward@juniper.net
Ayan Banerjee
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95138 USA
Phone: +1-408-525-8781
EmMail: ayabaner@cisco.com
D. Eastlake, et al [Page 22]
INTERNET-DRAFT RBridges: OAM and BFD
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2010 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 23]