TRILL Working Group Donald Eastlake
INTERNET-DRAFT Huawei
Intended status: Proposed Standard Vishwas Manral
HP Networking
Li Yizhou
Sam Aldrin
Huawei
Dave Ward
Juniper
Expires: December 2, 2011 June 3, 2011
RBridges: TRILL RBridge Channel Support
<draft-ietf-trill-rbridge-channel-01.txt>
Abstract
This document specifies a general channel mechanism for sending
messages, such as OAM (Operations, Administration, and Maintenance)
messages, between RBridges (Routing Bridges) and between RBridges and
end stations in an RBridge campus through extensions to the TRILL
(TRansparent Interconnection of Lots of Links) 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: RBridge Channel
Table of Contents
1. Introduction............................................3
1.1 RBridge Channel Requirements...........................3
1.2 Terminology............................................4
2. RBridge Channel Messages................................5
2.1 The RBridge Channel Message Inner Frame................6
2.1.1 RBridge Channel Header...............................6
2.1.2 Inner Ethernet Header................................7
2.1.3 Inner.VLAN Tag.......................................8
2.2 The TRILL Header for RBridge Channel Messages..........9
2.3 Channel Message Ethernet Link Header and Trailer......10
2.4 Special Transmission and Rate Considerations..........10
3. Processing RBridge Channel Messages....................11
3.1 Processing the RBridge Channel Header.................11
3.2 RBridge Channel Errors................................12
4. Native RBridge Channel Frames..........................14
5. Indicating Support for RBridge Channel Protocols.......15
6. Allocation Considerations..............................17
6.1 IANA Considerations...................................17
6.1.1 TRILL GENAPP ID and APPsub-TLV......................17
6.1.2 Other IANA Considerations...........................18
6.2 IEEE Registration Authority Considerations............19
7. Security Considerations................................20
8. References.............................................21
8.1 Normative References..................................21
8.2 Informative References................................21
D. Eastlake, et al [Page 2]
INTERNET-DRAFT RBridges: RBridge Channel
1. Introduction
RBridge campuses support transparent least-cost path forwarding using
the TRILL (TRansparent Interconnection of Lots of Links) protocol
that builds on IS-IS (Intermediate System to Intermediate System)
routing [IS-IS] [RFC1195]. Devices the implement TRILL are called
RBridges (Routing Bridges). However, the TRILL base protocol standard
[RFCtrill] provides only for TRILL Data messages, to handle end
station data, and TRILL IS-IS messages.
This document specifies a general channel mechanism for the
transmission of other messages within an RBridge campus, such as OAM
(Operations, Administration, and Maintenance, [RFCoam]) messages,
between RBridges or between RBridges and end stations. This mechanism
supports a requirement to be able to operate with minimal or no
configuration.
Familiarity with [RFCtrill] and [RFCadj] is assumed in this document.
1.1 RBridge Channel Requirements
It is anticipated that various protocols operating at the TRILL
level, such as OAM protocols, will be desired in RBridge campuses.
For example, there is a need for rapid response continuity checking
with a protocol such as BFD [RFC5880] [RFC5882] and for a variety of
optional reporting, in the spirit of some ICMP [RFC792] messages,
such as reporting Hop Count exhaustion, unknown egress nickname in
the TRILL header, and the like, including ping and trace route
functions.
To avoid having to design and specify a way to carry each new OAM or
similar protocol between RBridges, this document specifies a general
channel for sending messages between RBridges in a campus at the
TRILL level by extending the TRILL protocol. To accommodate a wide
variety of protocols, this RBridge Channel facility accommodates all
the regular modes of TRILL Data transmission including single and
multiple hop unicast as well as VLAN scoped multi-destination
distribution.
To minimize unnecessary burden on transit RBridges and to provide a
more realistic test of network continuity and the like, RBridge
Channel messages are designed to look like TRILL Data frames and, in
the case of multi-hop messages, can normally be handled by transit
RBridges as if they were TRILL Data frames; however, to enable
processing at transit RBridges when required by particular messages,
they may optionally use the Alert TRILL extended header flag [RFCext]
that causes a transit RBridge to more closely examine a frame,
usually by sending it to the slow path.
D. Eastlake, et al [Page 3]
INTERNET-DRAFT RBridges: RBridge Channel
This document also provides a format for sending RBridge Channel
messages between RBridges and end stations, in either direction, when
provided for by the protocol involved.
Each particular protocol using the RBridge Channel will likely use
only a subset of the facilities specified herein.
The RBridge Channel is similar to the MPLS Generic Channel specified
in [RFC5586]. Instead of using a special MPLS label to indicate a
special channel message, an RBridge Channel message is indicated by a
special multicast Inner.MacDA and inner Ethertype.
1.2 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 [RFC2119].
The terminology and acronyms of [RFCtrill] are used in this document
with the additions listed below.
BFD - Bidirectional Forwarding Detection
BVL - Bit Vector Length
BVO - Bit Vector Offset
CHV - Channel Header Version
ICMP - Internet Control Message Protocol
MH - Multi-Hop
NA - Native
OAM - Operations, Administration, and Maintenance
SL - Silent
D. Eastlake, et al [Page 4]
INTERNET-DRAFT RBridges: RBridge Channel
2. RBridge Channel Messages
RBridge Channel messages are transmitted as TRILL Data frames. They
are identified as RBridge Channel messages by their Inner.MacDA,
which is the All-Egress-RBridges multicast address, together with
their Inner Ethertype, which is the RBridge-Channel Ethertype. This
Ethertype is part of an RBridge Channel Header. The payload of the
encapsulated frame starts with an RBridge Channel Header and
indicates the protocol being sent through the RBridge Channel.
The diagram below shows the overall structure of a RBridge Channel
Message frame on a link between two RBridges:
Frame Structure Section of This Document
------------------------
+--------------------------------+
| Link Header | Section 2.3 if Ethernet Link
+--------------------------------+
| TRILL Header | Section 2.2
+--------------------------------+
| Inner Ethernet Header | Section 2.1.2
+--------------------------------+
| RBridge Channel Header | Section 2.1.1
+--------------------------------+
| Protocol Specific Payload | See specific channel protocol
+--------------------------------+
| Link Trailer (FCS if Ethernet) |
+--------------------------------+
Some channel messages may require examination of the frame by transit
RBridges that support the RBridge Channel feature, to determine if
they need to take any action. To indicate this, such messages use the
Alert extended TRILL header flag as further described in Section 3
below.
The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL
Header for frames sent in an RBridge Channel. As always, the Outer
link header and trailer are whatever is needed to get a TRILL Data
frame to the next hop RBridge, depend on the technology used by the
link, and can change with each hop for multi-hop messages. Section
2.3 describes the Outer link header for Ethernet. And Section 2.4
discusses some special considerations for the first hop transmission
of RBridge Channel messages.
Section 3 describes some details of RBridge Channel message
processing. Section 4 provides further specifications for native
RBridge Channel frames between RBridges and end stations. And Section
5 provides information on how to advertise support for particular
channel protocols.
D. Eastlake, et al [Page 5]
INTERNET-DRAFT RBridges: RBridge Channel
2.1 The RBridge Channel Message Inner Frame
The encapsulated inner frame within an RBridge Channel message frame
is as shown below.
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA cont. | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype | Priority, VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel Ethertype | CHV | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Protocol Specific Information:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Channel Protocol Specific Data
| ...
The channel protocol specific data contains the information related
to the specific channel protocol used in the channel message. Details
of that data are outside the scope of this document, except in the
case of the RBridge Channel Error protocol specified below.
2.1.1 RBridge Channel Header
As shown in the diagram above, the RBridge Channel header starts with
the RBridge-Channel Ethertype (see Section 6.2). Following that is a
four-byte quantity with four sub-fields as follows:
CHV: A 4-bit field that gives the RBridge Channel Header Version
and MUST be zero.
Channel Protocol: A 12-bit unsigned integer that specifies the
particular RBridge Channel protocol to which the message
applies.
Flags: Provides 12 bits of flags described below.
D. Eastlake, et al [Page 6]
INTERNET-DRAFT RBridges: RBridge Channel
ERR: A 4-bit unsigned integer used in connection with error
reporting at the RBridge Channel level as described in
Section 3.
The flag bits are numbered from 0 to 11 as shown below.
0 1 2 3 4 5 6 7 8 9 10 11
+--+--+--+--+--+--+--+--+--+--+--+--+
|SL|MH|NA| 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 RBridge Channel
Error messages (see Section 3).
Bit 1 is the MH or Multi-Hop bit. It is used to inform the
destination RBridge protocol that the message may be multi-hop (MH=1)
or was intended to be one-hop (MH=0).
Bit 2 is the NA or Native bit. It is used as described in Section 4
below.
The RBridge Channel Protocol field specifies the protocol that the
channel message relates to. The initial defined value is listed
below. See Section 6 for IANA Considerations.
Protocol Name - Section of this Document
-------- -------------------------------
0x001 RBridge Channel Error - Section 3
2.1.2 Inner Ethernet Header
The special Inner.MacDA is the All-Egress-RBridges multicast MAC
address to signal that the frame is intended for the egress RBridge
itself (or the egress RBridges themselves if the frame is multi-
destination) (see Section 6). The RBridge-Channel Ethertype indicates
that the frame is an RBridge Channel message. The only other
Ethertype currently specified for use with the All-Egress-RBridges
Inner.MacDA is L2-IS-IS to indicate an ESADI frame [RFCtrill]. In the
future additional Ethertypes may be specified for use with the All-
Egress-RBridges multicast address.
The RBridge originating the channel message selects the Inner.MacSA.
The Inner.MacSA MUST be set by the originating RBridge to a MAC
address unique within the campus owned by the originating RBridge.
This MAC address can be considered, in effect, the MAC address of a
virtual internal end station that handles the RBridge Channel frames
D. Eastlake, et al [Page 7]
INTERNET-DRAFT RBridges: RBridge Channel
originated by or destined for that RBridge.
2.1.3 Inner.VLAN Tag
As with all TRILL encapsulated frames, a VLAN tag MUST be present.
Use of a VLAN tag Ethertype other than 0x8100 or stacked VLAN tags is
beyond the scope of this document.
Multi-destination RBridge Channel messages are, like all multi-
destination TRILL Data messages, 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 in the campus, such channel messages may
only reach RBridges advertising that they have appointed forwarder
connectivity to that VLAN.
For channel messages sent as a known unicast TRILL Data frames, 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.
The Inner.VLAN will also specify a three-bit frame priority for which
the following recommendations apply:
1. For one-hop channel 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.
2. For single and multi-hop known unicast channel messages
important to network operation but not critical for
connectivity, the RECOMMENDED priority is 6.
3. For other known unicast channel messages and all multi-
destination channel messages, it is RECOMMENDED that the
default priority zero be used. In any case, priorities higher
than 5 SHOULD NOT be used for such frames.
There is one additional bit in a VLAN tag value beyond the 12 bit
VLAN ID and 3-bit priority. In some applications, this bit is called
the Drop Eligibility Indicator (DEI). It is RECOMMENDED that this bit
be zero for the first two categories of channel messages listed
immediately above. The setting of this bit for channel messages in
the third category may be dependent on the channel protocol and no
general recommendation is made for that case.
D. Eastlake, et al [Page 8]
INTERNET-DRAFT RBridges: RBridge Channel
2.2 The TRILL Header for RBridge Channel Messages
After the outer Link Header (which, for Ethernet, ends with the TRILL
Ethertype) and before the encapsulated frame, the channel message's
TRILL Header initially appears as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0| R |M| Ext-Len | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TRILL Header version V MUST be zero, the R bits are reserved, the
M bit is set appropriately as the channel message is to be forwarded
as known unicast (M=0) or multi-destination (M=1) regardless of the
fact that the Inner.MacDA is always the All-Egress-RBridges multicast
address, and Ext-Len is set appropriately for the length of the TRILL
Header extensions area, if any, all as specified in [RFCtrill] (where
the extensions area is referred to as the options area).
When an RBridge Channel message is originated, the Hop Count field
defaults to the maximum value, 0x3F, but particular RBridge Channel
protocols MAY specify other values. For messages sent a known number
of hops, such as one-hop messages or two-hop neighbor echo messages,
setting the Hops field to the maximum value and checking the Hop
Count field on receipt provides an additional validity check as
discussed in [RFC5082].
The RBridge originating a channel message places a nickname that it
holds into the ingress nickname field.
There are several cases for the egress nickname field. If the channel
message is multi-destination, then the egress nickname designates the
distribution tree to use. If the channel 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 one of its own nicknames in both the
ingress and egress nickname fields. If the channel 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.
o The special nickname Any-RBridge may be used. RBridges supporting
the RBridge Channel facility MUST recognize the Any-RBridge
special nickname and accept TRILL Data frames having that value in
the egress nickname field as being sent to them as the egress.
Thus, for such RBridges, using this egress nickname guarantees
processing by an immediate neighbor regardless of the state of
D. Eastlake, et al [Page 9]
INTERNET-DRAFT RBridges: RBridge Channel
nicknames.
2.3 Channel Message Ethernet Link Header and Trailer
An RBridge Channel frame has the usual link header and trailer
depending on the type of link on which it is sent.
For an Ethernet link [RFCtrill] 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 RBridge Channel
messages or the All-RBridges multicast address for multi-destination
RBridge Channel messages. The Outer.VLAN tag specifies the Designated
VLAN for that hop and the priority should be the same as in the
Inner.VLAN tag; however, the output port may have been configured to
strip VLAN tags, in which case no Outer.VLAN tag appears on the wire.
And the link trailer is the Ethernet FCS.
2.4 Special Transmission and Rate Considerations
If a multi-hop RBridge Channel message is received by an RBridge, the
criteria and method of forwarding it are the same as for any TRILL
Data frame. If it is so forwarded, it will be on a link that was
included in the routing topology because it was in the Report state
as specified in [RFCadj].
However, special considerations apply to the first hop because, for
some RBridge Channel protocols, it may be desirable to sent RBridge
Channel messages on links that are not yet fully up. In particular,
it is permissible, if specified by the particular channel protocol,
for the source RBridge that has created an RBridge Channel message to
transmit it to a next hop RBridge when the link is in the Detect or
Two-Way states, as specified in [RFCadj], as well as when it is in
the Report state.
RBridge Channel messages represent a burden on the RBridges and links
in a campus and should be rate limited, especially if they are sent
as high priority, multi-destination, or multi-hop frames or have the
Alert extended header flag set.
D. Eastlake, et al [Page 10]
INTERNET-DRAFT RBridges: RBridge Channel
3. Processing RBridge Channel Messages
RBridge Channel messages are designed to look like and, to the extent
practical, be forwarded as regular TRILL Data frames. On receiving a
channel message, the initial tests on the Outer.MacDA, Outer
Ethertype, TRILL Header V and Hop Count fields and the Reverse Path
Forwarding 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 following exceptions for
RBridges implementing the RBridge Channel facility:
1. An RBridge implementing the RBridge Channel facility MUST
recognize the Any-RBridge egress nickname in TRILL Data frames,
decapsulating such frames if they meet other checks. (Such a
frame cannot be a valid multi-destination frame because Any-
RBridge is not a valid distribution tree root.)
2. If the Alert extended header flag is set, then the RBridge MUST
process the RBridge Channel message as described below even if
it is not egressing the frame. If it is egressing the frame,
then no additional processing beyond egress processing is
needed even if the Alert flag is set.
3. On decapsulation, the special Inner.MacDA value of All-Egress-
RBridges MUST be recognized to trigger checking the
Inner.Ethertype and processing as an RBridge Channel message if
that Ethertype is RBridge-Channel.
RBridge Channel messages SHOULD only be sent to RBridges that
advertise support for the channel protocol involved as specified in
Section 6.
All RBridges supporting the RBridge Channel facility MUST recognize
the RBridge-Channel Ethertype.
3.1 Processing the RBridge Channel Header
Knowing that it has an RBridge Channel message, the egress RBridge,
and any transit RBridge if the Alert bit is set in the TRILL Header,
looks at the CHV (RBridge Channel Header Version) and Channel
Protocol fields.
If any of the following conditions occur at an egress RBridge, the
frame is not processed and an error may be generated as specified in
Section 3.2; however, if these conditions are detected at a transit
RBridge examining the message because the Alert flag is set, no error
is generated and the frame is still forwarded normally.
D. Eastlake, et al [Page 11]
INTERNET-DRAFT RBridges: RBridge Channel
1. The Ethertype is not RBridge-Channel and not any other
Ethertype known to the RBridge as usable with the All-Egress-
RBridges Inner.MacDA, or the frame is so short that the
Ethertype is truncated.
2. The CHV field is non-zero or the frame is so short that the
version zero Channel Header is truncated.
3. The Channel Protocol field is a reserved value or a value
unknown to the processing RBridge.
4. The ERR field is non-zero and Channel Protocol is a value other
than 0x001.
5. The RBridge Channel Header NA flag is set to one indicating
that the frame should have been received as a native frame
rather than an encapsulated frame.
If the CHV field and NA flag are zero and the processing RBridge
recognizes the Channel Protocol value, it processes the message in
accordance with that channel protocol. The processing model is as if
the received frame starting with and including the TRILL Header is
delivered to the Channel protocol along with a flag indicating
whether this is (a) transit RBridge processing due to the Alert flag
being set or (b) egress processing.
Errors within a recognized Channel Protocol are handled by that
channel protocol itself and do not produce RBridge Channel Error
frames.
3.2 RBridge Channel Errors
A variety of problems at the RBridge Channel level cause the return
of an RBridge Channel Error frame unless (a) the "SL" (Silent) flag
is a one in the channel message for which the problem was detected,
(b) the processing is due to the Alert bit being set, (c) the frame
in error appears, itself, to be an RBridge Channel error frame (has a
non-zero ERR field or an Channel Protocol of 0x001), or (d) the error
is suppressed due to rate limiting.
An RBridge Channel Error frame is a multi-hop unicast RBridge 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 channel message for which the error was
detected. The SL and MH flags SHOULD be set to one, the NA flag to
zero, and the ERR field MUST be non-zero as described below. For the
protocol specific data area, an RBridge Channel Message Error frame
has at least the first 256 bytes (or less if less are available) of
D. Eastlake, et al [Page 12]
INTERNET-DRAFT RBridges: RBridge Channel
the erroneous decapsulated channel message starting with the TRILL
Header. (Note: The TRILL Header does not include the TRILL Ethertype
which is part of the Link Header on Ethernet Links and may be absent
for other link technologies.)
The following values for ERR are specified:
ERR Meaning
--- -------
0 - Not an RBridge Channel error frame.
1 Frame too short (truncated Ethertype or RBridge Channel Header)
2 Unrecognized Ethertype
3 Unimplemented value of CHV
4 Wrong value of NA flag
5 Channel Protocol is reserved or unimplemented
6-14 - Available for allocation, see Section 6.
15 Reserved
All RBridges implementing the RBridge Channel feature MUST recognize
the RBridge Channel Error protocol value (0x001). They MUST NOT
generate an RBridge Channel Error message in response to a RBridge
Channel Error message, that is, a channel message with a protocol
value of 0x001 or with a non-zero ERR field.
D. Eastlake, et al [Page 13]
INTERNET-DRAFT RBridges: RBridge Channel
4. Native RBridge Channel Frames
If provided for by the channel protocol involved, native RBridge
channel messages may be sent between end-stations and RBridges in
either direction. On an Ethernet link, such native frames have the
RBridge-Channel Ethertype and are like the encapsulated frame inside
an RBridge Channel message with the following exceptions:
1. TRILL does not require the presence of VLAN tagging on such
native RBridge channel frames. However, port configuration,
link characteristics, or the channel protocol involved may
require such tagging.
2. If the frame is unicast, the destination MAC address is the
unicast MAC address of the RBridge or end-station port that is
its intended destination. If the frame is multicast to all the
RBridges on a link that support an RBridge Channel protocol
that uses this transport, the destination MAC address is the
All-Egress-RBridges multicast address. If the frame is
multicast to all the devices that TRILL considers to be end
stations on a link that support an RBridge Channel protocol
that uses this transport, the destination MAC address is the
TRILL-End-Stations multicast address (see Section 6). The
RBridge-Channel Ethertype must be present. In the future there
may be other protocols using the All-Egress-RBridges and/or
TRILL-End-Stations multicast addresses on native frames
distinguished by different Ethertypes.
3. The NA or native bit in the RBridge Channel Header flags must
be a one.
4. As with any native frame, the source MAC address is that of the
port sending the frame.
A native frame with the RBridge-Channel Ethertype must meet the usual
native frame restrictions to be accepted by an RBridge, for example
VLAN and destination MAC address restrictions on an Ethernet link. If
provided for by the channel protocol involved, the receipt of such a
native frame MAY lead to the generation and transmission of one or
more native or TRILL encapsulated RBridge Channel frames. The
decapsulation and processing of an encapsulated RBridge Channel frame
MAY, if provided for by the channel protocol involved, result in the
sending of one or more native RBridge channel frames to one or more
end stations.
D. Eastlake, et al [Page 14]
INTERNET-DRAFT RBridges: RBridge Channel
5. Indicating Support for RBridge Channel Protocols
Support for RBridge Channel protocols is indicated by the presence of
one or more Channel Protocols TRILL APPsub-TLVs (see Section 6) in an
RBridge's link state. The Channel Protocols TRILL APPsub-TLV has as
its value one or more byte-aligned bit vectors where a one bit
indicates support of a particular RBridge Channel protocol. Each
byte-aligned bit vector is formatted as follows:
| 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Bit Vector Length | Bit Vector Offset |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| bits
+--+--+--...
Note that the bit vector length (BVL) is a seven bit unsigned integer
field and the bit vector offset (BVO) is a nine bit unsigned integer
field. The bits in each bit vector are numbered in network order,
the high order bit of the first byte of bits being bit 0 + 8*BVO, the
low order bit of that byte being 7 + 8*BVO, the high order bit of the
second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge
Channel protocols supported bit vector MUST NOT extend beyond the end
of the value in the APPsub-TLV (see Section 6) in which it occurs. If
multiple byte-aligned bit vectors are present in one such APPsub-TLV,
they are contiguous, the BVL field for the next starting immediately
after the last byte of bits for the previous. The one or more bit
vectors present MUST exactly fill the APPsub-TLV value.
If different bit vectors overlap in the protocol number space they
refer to and they have inconsistent bit values for a channel
protocol, support for the protocol is assumed if any of these bit
vectors has a 1 for that protocol.
RBridge Channel protocols 0 and 0xFFF are reserved and protocol 1,
the RBridge Channel error protocol, MUST be implemented as part of
the RBridge Channel feature so, if an RBridge supports the RBridge
Channel feature, it should be advertising support for protocol 1 in
its LSP. The absence of any occurrences of this APPsub-TLV in the
LSP for an RBridge implies that that RBridge does not support the
RBridge Channel feature. Bit positions for protocols 0, 1, and 0xFFF
that appear in bit vectors in this APPsub-TLV MUST have the bits set
to 0 for protocols 0 and 0xFFF and the bit set to 1 for protocol;
however, these bits are ignored on receipt and support for protocol 1
is always assumed, if the RBridge Channel feature is supported.
To avoid wasted space, trailing bit vector zero bytes SHOULD be
eliminated by reducing BVL, any null bit vectors (ones with BVL equal
to zero) eliminated, and generally the most compact encoding used.
For example, support for channel protocols 1 and 32 could be encoded
D. Eastlake, et al [Page 15]
INTERNET-DRAFT RBridges: RBridge Channel
as
BVL = 5
BVO = 0
0b01000000
0b00000000
0b00000000
0b00000000
0b10000000
or as
BVL = 1
BVO = 0
0b01000000
BLV = 1
BVO = 4
0b1000000
The first takes 7 bytes while the second takes only 6 and thus the
second would be preferred.
D. Eastlake, et al [Page 16]
INTERNET-DRAFT RBridges: RBridge Channel
6. Allocation Considerations
The following subsections give IANA and IEEE allocation
considerations. In this document, the allocation procedures
"Standards Action", "IETF Review", "RFC Publication", and "Private
Use" are as specified in [RFC5226].
6.1 IANA Considerations
The following subsections give IANA allocation considerations.
6.1.1 TRILL GENAPP ID and APPsub-TLV
IANA is requested to allocate an IS-IS Application Identifier under
the Generic Information TLV (#251) for TRILL [RFCgenapp] and to
create a subregistry in the TRILL Parameters Registry for "TRILL
APPsub-TLVs under IS-IS TLV #251 Application Identifier #TBD". The
initial contents of this subregistry are as follows:
Type Name MI0? Reference
------ -------- ------ -----------
0 Reserved - <this RFC>
1 Channel Protocols Y <this RFC>
2-254 Available - <this RFC>
255 Reserved - <this RFC>
TRILL APPsub-TLV Types 2 through 254 are available for allocation by
Standard Action as modified by [RFC4020]. The standards track RFC
making such allocation shall specify whether a TRILL Generic
Information TLV containing an instance of that TRILL APPsub-TLV is
permitted to occur in instance zero LSPs and a column in the TRILL
APPsub-TLV registry will indicate this. The RFC will also include a
discussion of security issues and of the rate of change of the
information being advertised. TRILL APPsub-TLVs MUST NOT alter basic
TRILL IS-IS protocol operation including the establishment of
adjacencies, the update process, and the decision process [IS-IS]
[RFC1195] [RFCadj].
The V, I, D, and S flags in the initial flags byte of a TRILL Generic
Information TLV [RFCgenapp] are not used as TRILL operates as a Level
1 IS-IS area and no meaning is hereby assigned to the inclusion of an
IPv4 and/or IPv6 address via the I and V flags. Thus these flags MUST
be zero; however, use of multi-level IS-IS is an obvious extension
for TRILL and future IETF Standards Actions may update or obsolete
this specification to provide for the use of any or all of these
flags in the TRILL GENAPP TLV.
D. Eastlake, et al [Page 17]
INTERNET-DRAFT RBridges: RBridge Channel
The RBridge Channel Protocols information is expected to be compact
and slow changing. It would typically change only on manual re-
configuration, software/firmware update, or the like. The Channel
Protocols TRILL APPsub-TLV may occur in instance zero LSPs. The
security implications of each RBridge Channel protocol will be
discussed in the RFC specifying that protocol. For Security
Considerations related to the Channel Protocols APPsub-TLV, see
Section 7.
6.1.2 Other IANA Considerations
IANA is requested to allocate a previously unassigned TRILL Nickname
as follows:
Any-RBridge TBD (0xFFCO suggested)
IANA is requested to add "All-Egress-RBridges" to the TRILL Parameter
Registry as an alternative name for the "All-ESADI-RBridges"
multicast address.
IANA is requested to allocate one previously unassigned TRILL
Multicast address as follows:
TRILL-End-Stations TBD (01-80-C2-00-00-43 suggested)
IANA is requested to create an additional sub-registry in the TRILL
Parameter Registry for RBridge Channel Protocols, with initial
contents as follows:
Protocol Use
-------- ---
0x000 Reserved
0x001 RBridge Channel Error
0x002-0x0FF Available for allocation (1)
0x100-0xFF7 Available for allocation (2)
0xFF8-0xFFE Private Use
0xFFF Reserved
(1) RBridge Channel protocol code points from 0x002 to 0x0FF require
a Standards Action as modified by [RFC4020] for allocation.
(2) RBridge Channel protocol code points from 0x100 to 0xFF7 require
RFC Publication to allocate a single value or IETF Review to allocate
multiple values.
IANA is requested to create an additional sub-registry in the TRILL
Parameter Registry for RBridge Channel Header Flags with initial
D. Eastlake, et al [Page 18]
INTERNET-DRAFT RBridges: RBridge Channel
contents as follows:
Flag Bit Mnemonic Allocation
-------- -------- ----------
0 SL Silent
1 MH Multi-hop
2 NA Native
3-11 - Available for allocation
Allocation of an RBridge Channel Header Flag is based on Standards
Action as modified by [RFC4020].
IANA is requested to create an additional sub-registry in the TRILL
Parameter Registry for RBridge Channel Error codes with initial
contents as listed in Section 3.2 above and with available values
allocated by Standards Action as modified by [RFC4020].
6.2 IEEE Registration Authority Considerations
The IEEE Registration Authority has been assigned the Ethertype <TBD>
for RBridge-Channel.
D. Eastlake, et al [Page 19]
INTERNET-DRAFT RBridges: RBridge Channel
7. Security Considerations
See [RFCtrill] for general RBridge Security Considerations.
No general integrity, authentication, or encryption mechanisms are
provided herein for RBridge Channel messages. If these services are
required for a particular RBridge Channel protocol, they must be
supplied by that channel protocol. See, for example, the BFD
Authentication mechanism [RFC5880].
If RBridge Channel APPsub-TLVs are improperly absent, it could deny
all RBridge Channel services, for example OAM services, for the
RBridge in question. If a particular RBridge channel is incorrectly
not advertised as supported, it would deny the service of that
channel protocol to the RBridge in question.
Incorrect presence of the RBridge Channel APPsub-TLV and assertion of
support for a channel protocol could encourage RBridge Channel
messages to be sent to an RBridge that does not support that channel
protocol. The inner frame of such messages could be decapsulated and
that inner frame would likely be sent out all ports that are
appointed forwarders for the frame's Inner.VLAN. However, this is
unlikely to cause much harm. There are two possibilities: (2a) If end
stations do not recognize the RBridge-Channel Ethertype of the inner
frame, they will drop the frame. (2b) If end stations do recognize
the RBridge-Channel Ethertype and the channel protocol indicated in
the frame, they should refuse to process the frame due to an
incorrect value of the RBridge Channel Header NA flag.
D. Eastlake, et al [Page 20]
INTERNET-DRAFT RBridges: RBridge Channel
8. References
The following sections list normative and informative references for
this document.
8.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
[RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[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's queue.
[RFCgenapp] - L. Ginsberg, S. Previdi, M. Shand, "Advertising Generic
Information in IS-IS", draft-ietf-isis-genapp-04.txt, in RFC
Editor's queue.
[RFCadj] - D. Eastlake, R. Perlman, A. Ghanwani, D. Dutt, V. Manral,
"RBridges: Adjacency", draft-ietf-trill-adj, work in progress.
[RFCext] - D. Eastlake, A. Ghanwani, V. Manral, C. Bestler,
"RBridges: TRILL Header Extensions", draft-ietf-trill-rbridge-
options, work in progress.
8.2 Informative References
[RFC792] - Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
D. Eastlake, et al [Page 21]
INTERNET-DRAFT RBridges: RBridge Channel
[RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC
5082, October 2007
[RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, June 2009.
[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.
[RFCoam] - Andersson, L., H. van Helvoort, R. Bonica, D. Romascanu,
S. Mansfield, "Guidelines for the use of the OAM acronym in the
IETF", draft-ietf-opsawg-mpls-tp-oam-def-10.txt, work in
progress.
D. Eastlake, et al [Page 22]
INTERNET-DRAFT RBridges: RBridge Channel
Authors' Addresses
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Tel: +1-508-333-2270
EMail: d3e3e3@gmail.com
Vishwas Manral
HP Networking
19111 Pruneridge Avenue
Cupertino, CA 95014 USA
Tel: +1-408-477-0000
EMail: vishwa.manral@hp.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Sam Aldrin
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050 USA
Phone: +1-408-330-5000
Email: sam.aldrin@huawei.com
Dave Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089-1206 USA
Phone: +1-408-745-2000
EMail: dward@juniper.net
D. Eastlake, et al [Page 23]
INTERNET-DRAFT RBridges: RBridge Channel
Copyright, Disclaimer, and Additional 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 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.
D. Eastlake, et al [Page 24]
