< draft-ietf-trill-rbridge-channel-04.txt   draft-ietf-trill-rbridge-channel-05.txt >
TRILL Working Group Donald Eastlake TRILL Working Group Donald Eastlake
INTERNET-DRAFT Huawei INTERNET-DRAFT Huawei
Intended status: Proposed Standard Vishwas Manral Intended status: Proposed Standard Vishwas Manral
HP Networking HP Networking
Li Yizhou Li Yizhou
Sam Aldrin Sam Aldrin
Huawei Huawei
Dave Ward Dave Ward
Cisco Cisco
Expires: July 16, 2012 January 17, 2012 Expires: August 19, 2012 February 20, 2012
TRILL: RBridge Channel Support TRILL: RBridge Channel Support
<draft-ietf-trill-rbridge-channel-04.txt> <draft-ietf-trill-rbridge-channel-05.txt>
Abstract Abstract
This document specifies a general channel mechanism for sending This document specifies a general channel mechanism for sending
messages, such as OAM (Operations, Administration, and Maintenance) messages, such as BFD (Bidirectional Forwarding Detection) messages,
messages, between RBridges (Routing Bridges) and between RBridges and between RBridges (Routing Bridges) and between RBridges and end
end stations in an RBridge campus through extensions to the TRILL stations in an RBridge campus through extensions to the TRILL
(TRansparent Interconnection of Lots of Links) protocol. (TRansparent Interconnection of Lots of Links) protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list. to the TRILL working group mailing list.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
Table of Contents Table of Contents
1. Introduction............................................3 1. Introduction............................................3
1.1 RBridge Channel Requirements...........................3 1.1 RBridge Channel Requirements...........................3
1.2 Terminology............................................4 1.2 Relation to the MPLS Generic Channel...................4
1.3 Terminology............................................4
2. RBridge Channel Messages................................5 2. Inter-RBridge Channel Messages..........................5
2.1 The RBridge Channel Message Inner Frame................6 2.1 The RBridge Channel Message Inner Frame................6
2.1.1 RBridge Channel Header...............................6 2.1.1 RBridge Channel Header...............................6
2.1.2 Inner Ethernet Header................................7 2.1.2 Inner Ethernet Header................................7
2.1.3 Inner.VLAN Tag.......................................8 2.1.3 Inner.VLAN Tag.......................................8
2.2 The TRILL Header for RBridge Channel Messages..........9 2.2 The TRILL Header for RBridge Channel Messages..........9
2.3 Channel Message Ethernet Link Header and Trailer......10 2.3 Ethernet Link Header and Trailer......................10
2.4 Special Transmission and Rate Considerations..........10 2.4 Special Transmission and Rate Considerations..........10
3. Processing RBridge Channel TRILL Data Messages.........11 3. Processing RBridge Channel TRILL Data Messages.........11
3.1 Processing the RBridge Channel Header.................11 3.1 Processing the RBridge Channel Header.................11
3.2 RBridge Channel Errors................................12 3.2 RBridge Channel Errors................................12
4. Native RBridge Channel Frames..........................14 4. Native RBridge Channel Frames..........................14
5. Indicating Support for RBridge Channel Protocols.......16 5. Indicating Support for RBridge Channel Protocols.......16
6. Allocation Considerations..............................17 6. Allocation Considerations..............................17
6.1 IANA Considerations...................................17 6.1 IANA Considerations...................................17
6.2 IEEE Registration Authority Considerations............18 6.2 IEEE Registration Authority Considerations............18
7. Security Considerations................................19 7. Security Considerations................................19
8. References.............................................20 8. References.............................................20
8.1 Normative References..................................20 8.1 Normative References..................................20
8.2 Informative References................................20 8.2 Informative References................................20
Appendix: Change History..................................22 Appendix: Change History..................................22
Acknowledgmnts............................................24
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
1. Introduction 1. Introduction
RBridge campuses provide transparent least-cost path forwarding using RBridge campuses provide transparent least-cost path forwarding using
the TRILL (TRansparent Interconnection of Lots of Links) protocol the TRILL (TRansparent Interconnection of Lots of Links) protocol
that builds on IS-IS (Intermediate System to Intermediate System) that builds on IS-IS (Intermediate System to Intermediate System)
routing [IS-IS] [RFC1195] [RFC6326bis]. Devices the implement TRILL routing [IS-IS] [RFC1195] [RFC6326bis]. Devices that implement TRILL
are called RBridges (Routing Bridges) or TRILL Switches. However, the are called RBridges (Routing Bridges) or TRILL Switches. However, the
TRILL base protocol standard [RFC6325] provides only for TRILL Data TRILL base protocol standard [RFC6325] provides only for TRILL Data
messages and TRILL IS-IS messages. messages and TRILL IS-IS messages.
This document specifies a general channel mechanism for the This document specifies a general channel mechanism for the
transmission of other messages within an RBridge campus, such as OAM transmission of other messages within an RBridge campus, such as BFD
(Operations, Administration, and Maintenance, [RFC6291]) messages, (Bidirectional Forwarding Detection, [RFC5880]) messages, between
between RBridges and between RBridges and end stations. This RBridges and end stations that are directly connected on the same
mechanism supports a requirement to be able to operate with minimal link and between RBridges. This mechanism supports a requirement to
configuration. be able to operate with minimal configuration.
Familiarity with [RFC6325] and [RFC6327] is assumed in this document. Familiarity with [RFC6325] and [RFC6327] is assumed in this document.
1.1 RBridge Channel Requirements 1.1 RBridge Channel Requirements
It is anticipated that various protocols operating at the TRILL It is anticipated that various protocols operating at the TRILL level
level, such as OAM protocols, will be desired in RBridge campuses. will be desired in RBridge campuses. For example, there is a need for
For example, there is a need for rapid response continuity checking rapid response continuity checking with a protocol such as BFD
with a protocol such as BFD [RFC5880] [RFC5882] and for a variety of [RFC5880] [RFC5882] and for a variety of optional reporting.
optional reporting.
To avoid having to design and specify a way to carry each such To avoid the requirement to design and specify a way to carry each
protocol, this document specifies a general channel for sending such protocol, this document specifies a general channel for sending
messages between RBridges in a campus at the TRILL level by extending messages between RBridges in a campus at the TRILL level by extending
the TRILL protocol. To accommodate a wide variety of protocols, this the TRILL protocol. To accommodate a wide variety of protocols, this
RBridge Channel facility accommodates all the regular modes of TRILL RBridge Channel facility accommodates all the regular modes of TRILL
Data transmission including single and multiple hop unicast as well Data transmission including single and multiple hop unicast as well
as VLAN scoped multi-destination distribution. as VLAN scoped multi-destination distribution.
To minimize unnecessary burden on transit RBridges and to provide a To minimize any unnecessary burden on transit RBridges and to provide
more realistic test of network continuity and the like, RBridge a more realistic test of network continuity and the like, RBridge
Channel messages are designed to look like TRILL Data frames and, in Channel messages are designed to look like TRILL Data frames and, in
the case of multi-hop messages, can normally be handled by transit the case of multi-hop messages, can normally be handled by transit
RBridges as if they were TRILL Data frames; however, to enable RBridges as if they were TRILL Data frames; however, to enable
processing at transit RBridges when required by particular messages, processing at transit RBridges when required by particular messages,
they may optionally use the RBridge Channel Alert TRILL extended they may optionally use the RBridge Channel Alert TRILL extended
header flags [RFCext] that causes a transit RBridge implementing the header flags [RFCext] that causes a transit RBridge implementing the
flag to more closely examine a frame. flag to more closely examine a flagged frame.
This document also provides a format for sending RBridge Channel This document also specifies a format for sending RBridge Channel
messages between RBridges and end stations, in either direction, when messages between RBridges and end stations that are directly
provided for by the protocol involved. connected over a link, in either direction, when provided for by the
protocol involved. For the most part, this format is the same as the
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
Each particular protocol using the RBridge Channel will likely use format that is TRILL Data encapsulated for inter-RBridge channel
only a subset of the facilities specified herein. messages.
Each particular protocol using the RBridge Channel facility will
likely use only a subset of the facilities specified herein.
1.2 Relation to the MPLS Generic Channel
The RBridge Channel is similar to the MPLS Generic Channel specified The RBridge Channel is similar to the MPLS Generic Channel specified
in [RFC5586]. Instead of using a special MPLS label to indicate a in [RFC5586]. Instead of using a special MPLS label to indicate a
special channel message, an RBridge Channel message is indicated by a special channel message, an RBridge Channel message is indicated by a
special multicast Inner.MacDA and inner Ethertype. special multicast Inner.MacDA and inner Ethertype.
1.2 Terminology 1.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The terminology and acronyms of [RFC6325] are used in this document The terminology and acronyms of [RFC6325] are used in this document
with the additions listed below. with the additions listed below.
BFD - Bidirectional Forwarding Detection BFD - Bidirectional Forwarding Detection
CHV - Channel Header Version CHV - Channel Header Version
MH - Multi-Hop MH - Multi-Hop
NA - Native NA - Native
OAM - Operations, Administration, and Maintenance
SL - Silent SL - Silent
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
2. RBridge Channel Messages 2. Inter-RBridge Channel Messages
RBridge Channel messages are transmitted as TRILL Data frames. They Channel messages between RBridges are transmitted as TRILL Data
are identified as RBridge Channel messages by their Inner.MacDA, frames. (For information on channel messages that can be transmitted
which is the All-Egress-RBridges multicast address, together with between RBridges and end stations that are directly connected by a
their Inner Ethertype, which is the RBridge-Channel Ethertype. This link, see Section 4.) Inter-RBridge Channel messages are identified
Ethertype is part of an RBridge Channel Header. The payload of the as such by their Inner.MacDA, which is the All-Egress-RBridges
encapsulated frame starts with an RBridge Channel Header and multicast address, together with their Inner Ethertype, which is the
indicates the protocol being sent through the RBridge Channel. RBridge-Channel Ethertype. This Ethertype is part of and starts the
RBridge Channel Header.
The diagram below shows the overall structure of a RBridge Channel The diagram below shows the overall structure of a RBridge Channel
Message frame on a link between two RBridges: Message frame on a link between two RBridges:
Frame Structure Section of This Document Frame Structure Section of This Document
------------------------ ------------------------
+--------------------------------+ +--------------------------------+
| Link Header | Section 2.3 if Ethernet Link | Link Header | Section 2.3 if Ethernet Link
+--------------------------------+ +--------------------------------+
| TRILL Header | Section 2.2 | TRILL Header | Section 2.2
+--------------------------------+ +--------------------------------+
| Inner Ethernet Header | Section 2.1.2 | Inner Ethernet Header | Section 2.1.2
+--------------------------------+ +--------------------------------+
| RBridge Channel Header | Section 2.1.1 | RBridge Channel Header | Section 2.1.1
+--------------------------------+ +--------------------------------+
| Protocol Specific Payload | See specific channel protocol | Protocol Specific Payload | See specific channel protocol
+--------------------------------+ +--------------------------------+
| Link Trailer (FCS if Ethernet) | | Link Trailer (FCS if Ethernet) |
+--------------------------------+ +--------------------------------+
Some channel messages may require examination of the frame by transit Optionally, some channel messages may require examination of the
RBridges that support the RBridge Channel feature, to determine if frame by transit RBridges that support the RBridge Channel feature,
they need to take any action. To indicate this, such messages use a to determine if they need to take any action. To indicate this, such
RBridge Channel Alert extended TRILL header flag as further described messages use a RBridge Channel Alert extended TRILL header flags as
in Section 3 below. further described in Section 3 below.
The Sections 2.1 and 2.2 below describe the Inner frame and the TRILL 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 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 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 frame to the next hop RBridge, depending on the technology of the
link, and can change with each hop for multi-hop messages. Section 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 2.3 describes the outer Link Header for Ethernet. And Section 2.4
discusses some special considerations for the first hop transmission discusses some special considerations for the first hop transmission
of RBridge Channel messages. of RBridge Channel messages.
Section 3 describes some details of RBridge Channel message Section 3 describes some details of RBridge Channel message
processing. Section 4 provides further specifications for native processing. Section 4 provides the specifications for native RBridge
RBridge Channel frames between RBridges and end stations. Channel frames between RBridges and end stations that are directly
connected over a link.
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
2.1 The RBridge Channel Message Inner Frame 2.1 The RBridge Channel Message Inner Frame
The encapsulated inner frame within an RBridge Channel message frame The encapsulated inner frame within an RBridge Channel message frame
is as shown below. is as shown below.
Inner Ethernet Header: Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 34 skipping to change at page 6, line 34
| RBridge-Channel Ethertype | CHV | Channel Protocol | | RBridge-Channel Ethertype | CHV | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR | | Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Protocol Specific Information: RBridge Channel Protocol Specific Information:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Channel Protocol Specific Data + Channel Protocol Specific Data
| ... | ...
The channel protocol specific data contains the information related The Channel Protocol Specific Data contains the information related
to the specific channel protocol used in the channel message. Details to the specific channel protocol used in the channel message. Details
of that data are outside the scope of this document, except in the of that data are outside the scope of this document, except in the
case of the RBridge Channel Error protocol specified below. case of the RBridge Channel Error protocol specified below.
2.1.1 RBridge Channel Header 2.1.1 RBridge Channel Header
As shown in the diagram above, the RBridge Channel header starts with As shown in the diagram above, the RBridge Channel header starts with
the RBridge-Channel Ethertype (see Section 6.2). Following that is a the RBridge-Channel Ethertype (see Section 6.2). Following that is a
four-byte quantity with four sub-fields as follows: four-byte quantity with four sub-fields as follows:
skipping to change at page 7, line 15 skipping to change at page 7, line 15
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
ERR: A 4-bit unsigned integer used in connection with error ERR: A 4-bit unsigned integer used in connection with error
reporting at the RBridge Channel level as described in reporting at the RBridge Channel level as described in
Section 3. Section 3.
The flag bits are numbered from 0 to 11 as shown below. The flag bits are numbered from 0 to 11 as shown below.
0 1 2 3 4 5 6 7 8 9 10 11 0 1 2 3 4 5 6 7 8 9 10 11
+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+
|SL|MH|NA| Available Flags | |SL|MH|NA| Reserved |
+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+
Bit 0, which is the high order bit in network order, is defined as 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 the SL or Silent bit. If it is a one, it suppresses RBridge
Error messages (see Section 3). Channel Error messages (see Section 3).
Bit 1 is the MH or Multi-Hop bit. It is used to inform the 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) destination RBridge protocol that the message may be multi-hop
or was intended to be one-hop (MH=0). (MH=1) or was intended to be one-hop only (MH=0).
Bit 2 is the NA or Native bit. It is used as described in Section 4 Bit 2 is the NA or Native bit. It is used as described in Section 4
below. below.
Reserved: Bits reserved for future specification that MUST be sent as
zero and ignored on receipt.
The RBridge Channel Protocol field specifies the protocol that the The RBridge Channel Protocol field specifies the protocol that the
channel message relates to. The initial defined value is listed channel message relates to. The initial defined value is listed
below. See Section 6 for IANA Considerations. below. See Section 6 for IANA Considerations.
Protocol Name - Section of this Document Protocol Name - Section of this Document
-------- ------------------------------- -------- -------------------------------
0x001 RBridge Channel Error - Section 3 0x001 RBridge Channel Error - Section 3
2.1.2 Inner Ethernet Header 2.1.2 Inner Ethernet Header
The special Inner.MacDA is the All-Egress-RBridges multicast MAC The special Inner.MacDA is the All-Egress-RBridges multicast MAC
address to signal that the frame is intended for the egress RBridge address to signal that the frame is intended for the egress
itself (or the egress RBridges themselves if the frame is multi- (decapsulating) RBridge itself (or the egress RBridges themselves if
destination). (This address is called the All-ESADI-RBridges address the frame is multi-destination). (This address is called the All-
in [RFC6325].) The RBridge-Channel Ethertype indicates that the frame ESADI-RBridges address in [RFC6325].) The RBridge-Channel Ethertype
is an RBridge Channel message. The only other Ethertype currently indicates that the frame is an RBridge Channel message. The only
specified for use with the All-Egress-RBridges Inner.MacDA is L2-IS- other Ethertype currently specified for use with the All-Egress-
IS to indicate an ESADI frame [RFC6325]. In the future additional RBridges Inner.MacDA is L2-IS-IS to indicate an ESADI frame
Ethertypes may be specified for use with the All-Egress-RBridges [RFC6325]. In the future additional Ethertypes may be specified for
multicast address. use with the All-Egress-RBridges multicast address.
The RBridge originating the channel message selects the Inner.MacSA. 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
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
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 virtual internal end station that handles the RBridge Channel frames
originated by or destined for that RBridge. It may be the same as the originated by or destined for that RBridge. It MAY be the same as the
Inner.MacSA used by the RBridge when it originates ESADI frames Inner.MacSA used by the RBridge when it originates ESADI frames
[RFC6325]. [RFC6325].
2.1.3 Inner.VLAN Tag 2.1.3 Inner.VLAN Tag
As with all frames formatted to be processed as a TRILL Data frame, As with all frames formatted to be processed as a TRILL Data frame,
an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than an Inner.VLAN tag is present. Use of a VLAN tag Ethertype other than
0x8100 or stacked tags is beyond the scope of this document but is an 0x8100 or stacked tags is beyond the scope of this document but is an
obvious extension. obvious extension.
skipping to change at page 8, line 47 skipping to change at page 8, line 50
2. For single and multi-hop known unicast channel messages 2. For single and multi-hop known unicast channel messages
important to network operation but not critical for important to network operation but not critical for
connectivity, the RECOMMENDED priority is 6. connectivity, the RECOMMENDED priority is 6.
3. For other known unicast channel messages and all multi- 3. For other known unicast channel messages and all multi-
destination channel messages, it is RECOMMENDED that the destination channel messages, it is RECOMMENDED that the
default priority zero be used. In any case, priorities higher default priority zero be used. In any case, priorities higher
than 5 SHOULD NOT be used for such frames. than 5 SHOULD NOT be used for such frames.
There is one additional bit in a VLAN tag value between the 12-bit There is one additional bit in a VLAN tag value between the 12-bit
VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI). It VLAN ID and 3-bit priority, the Drop Eligibility Indicator (DEI,
is RECOMMENDED that this bit be zero for the first two categories of [ClearCorrect]). It is RECOMMENDED that this bit be zero for the
channel messages listed immediately above. The setting of this bit first two categories of channel messages listed immediately above.
for channel messages in the third category may be dependent on the The setting of this bit for channel messages in the third category
channel protocol and no general recommendation is made for that case. may be dependent on the channel protocol and no general
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
recommendation is made for that case.
2.2 The TRILL Header for RBridge Channel Messages 2.2 The TRILL Header for RBridge Channel Messages
After the outer Link Header (that, for Ethernet, ends with the TRILL After the outer Link Header (that, for Ethernet, ends with the TRILL
Ethertype) and before the encapsulated frame, the channel message's Ethertype) and before the encapsulated frame, the channel message's
TRILL Header initially appears as follows: TRILL Header initially appears as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0| R |M| Ext-Len | Hop Count | |V=0| R |M| Ext-Len | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname | | Egress Nickname | Ingress Nickname |
skipping to change at page 9, line 44 skipping to change at page 9, line 46
on receipt provides an additional validity check as discussed in on receipt provides an additional validity check as discussed in
[RFC5082]. [RFC5082].
The RBridge originating a channel message places a nickname that it The RBridge originating a channel message places a nickname that it
holds into the ingress nickname field. holds into the ingress nickname field.
There are several cases for the egress nickname field. If the channel There are several cases for the egress nickname field. If the channel
message is multi-destination, then the egress nickname designates the message is multi-destination, then the egress nickname designates the
distribution tree to use. If the channel message is a multi-hop distribution tree to use. If the channel message is a multi-hop
unicast message, then the egress nickname is a nickname of the target unicast message, then the egress nickname is a nickname of the target
RBridge; this includes the special case of an OAM message intended to RBridge; this includes the special case of a message intended to loop
loop back from an immediate neighbor where the originator places one back from an immediate neighbor where the originator places one of
of its own nicknames in both the ingress and egress nickname fields. its own nicknames in both the ingress and egress nickname fields. If
If the channel message is a one-hop unicast message, there are two the channel message is a one-hop unicast message, there are two
possibilities for the egress nickname. possibilities for the egress nickname.
o The egress nickname can be set to a nickname of the target o The egress nickname can be set to a nickname of the target
neighbor RBridge. neighbor RBridge.
INTERNET-DRAFT TRILL: RBridge Channel
o The special nickname Any-RBridge may be used. RBridges supporting o The special nickname Any-RBridge may be used. RBridges supporting
the RBridge Channel facility MUST recognize the Any-RBridge the RBridge Channel facility MUST recognize the Any-RBridge
special nickname and accept TRILL Data frames having that value in special nickname and accept TRILL Data frames having that value in
the egress nickname field as being sent to them as the egress. the egress nickname field as being sent to them as the egress.
INTERNET-DRAFT TRILL: RBridge Channel
Thus, for such RBridges, using this egress nickname guarantees Thus, for such RBridges, using this egress nickname guarantees
processing by an immediate neighbor regardless of the state of processing by an immediate neighbor regardless of the state of
nicknames. nicknames.
2.3 Channel Message Ethernet Link Header and Trailer 2.3 Ethernet Link Header and Trailer
An RBridge Channel frame has the usual 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. depending on the type of link on which it is sent.
For an Ethernet link [RFC6325] the Outer.MacSA is the MAC address of For an Ethernet link [RFC6325] the Outer.MacSA is the MAC address of
the port from which the frame is sent. The Outer.MacDA is the MAC 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 address of the next-hop RBridge port for unicast RBridge Channel
messages or the All-RBridges multicast address for multi-destination messages or the All-RBridges multicast address for multi-destination
RBridge Channel messages. The Outer.VLAN tag specifies the Designated RBridge Channel messages. The Outer.VLAN tag specifies the Designated
VLAN for that hop and the priority should be the same as in the VLAN for that hop and the priority should be the same as in the
skipping to change at page 10, line 34 skipping to change at page 10, line 38
And the link trailer is the Ethernet FCS. And the link trailer is the Ethernet FCS.
2.4 Special Transmission and Rate Considerations 2.4 Special Transmission and Rate Considerations
If a multi-hop RBridge Channel message is received by an RBridge, the 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 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 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 included in the routing topology because it was in the Report state
as specified in [RFC6327]. as specified in [RFC6327].
However, special considerations apply to the first hop because, for However, special considerations apply to single hop messages because,
some RBridge Channel protocols, it may be desirable to send RBridge for some RBridge Channel protocols, it may be desirable to send
Channel messages on links that are not yet fully up. In particular, RBridge Channel messages over a link that is not yet fully up. In
it is permissible, if specified by the particular channel protocol, particular, it is permissible, if specified by the particular channel
for the source RBridge that has created an RBridge Channel message to protocol, for the source RBridge that has created an RBridge Channel
attempt to transmit it to a next hop RBridge when the link is in the message to attempt to transmit it to a next hop RBridge when the link
Detect or Two-Way states, as specified in [RFC6327], as well as when is in the Detect or Two-Way states, as specified in [RFC6327], as
it is in the Report state. well as when it is in the Report state. Such messages can also be
sent on point-to-point links that are not in the Up state.
RBridge Channel messages represent a burden on the RBridges and links RBridge Channel messages represent a burden on the RBridges and links
in a campus and should be rate limited, especially if they are sent in a campus and should be rate limited, especially if they are sent
as high priority, multi-destination, or multi-hop frames or have an as high priority, multi-destination, or multi-hop frames or have an
RBridge Channel Alert extended header flag set. RBridge Channel Alert extended header flag set.
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
3. Processing RBridge Channel TRILL Data Messages 3. Processing RBridge Channel TRILL Data Messages
skipping to change at page 11, line 41 skipping to change at page 11, line 41
3. On decapsulation, the special Inner.MacDA value of All-Egress- 3. On decapsulation, the special Inner.MacDA value of All-Egress-
RBridges MUST be recognized to trigger checking the RBridges MUST be recognized to trigger checking the
Inner.Ethertype and processing as an RBridge Channel message if Inner.Ethertype and processing as an RBridge Channel message if
that Ethertype is RBridge-Channel. that Ethertype is RBridge-Channel.
RBridge Channel messages SHOULD only be sent to RBridges that RBridge Channel messages SHOULD only be sent to RBridges that
advertise support for the channel protocol involved as described in advertise support for the channel protocol involved as described in
Section 5. Section 5.
All RBridges supporting the RBridge Channel facility MUST recognize All RBridges supporting the RBridge Channel facility MUST recognize
the RBridge-Channel Ethertype. the RBridge-Channel inner Ethertype.
3.1 Processing the RBridge Channel Header 3.1 Processing the RBridge Channel Header
Knowing that it has an RBridge Channel message, the egress RBridge, Knowing that it has an RBridge Channel message, the egress RBridge,
and any transit RBridge if an RBridge Channel Alert bit is set in the and any transit RBridge if an RBridge Channel Alert bit is set in the
TRILL Header, looks at the CHV (RBridge Channel Header Version) and TRILL Header, looks at the CHV (RBridge Channel Header Version) and
Channel Protocol fields. Channel Protocol fields.
If any of the following conditions occur at an egress RBridge, the If any of the following conditions occur at an egress RBridge, the
frame is not processed, an error may be generated as specified in frame is not processed, an error may be generated as specified in
skipping to change at page 13, line 18 skipping to change at page 13, line 18
ingress nickname in the channel message for which the error was ingress nickname in the channel message for which the error was
detected. No per-hop transit processing is specified for such error detected. No per-hop transit processing is specified for such error
frames, so the RBridge Channel Alert extended header flags SHOULD, if frames, so the RBridge Channel Alert extended header flags SHOULD, if
an extension is present, be set to zero. The SL and MH flags SHOULD an extension is present, be set to zero. The SL and MH flags SHOULD
be set to one, the NA flag MUST be zero, and the ERR field MUST be be set to one, the NA flag MUST be zero, and the ERR field MUST be
non-zero as described below. For the protocol specific data area, an non-zero as described below. For the protocol specific data area, an
RBridge Channel Message Error frame has at least the first 256 bytes RBridge Channel Message Error frame has at least the first 256 bytes
(or less if less are available) of the erroneous decapsulated channel (or less if less are available) of the erroneous decapsulated channel
message starting with the TRILL Header. (Note: The TRILL Header does message starting with the TRILL Header. (Note: The TRILL Header does
not include the TRILL Ethertype that is part of the Link Header on not include the TRILL Ethertype that is part of the Link Header on
Ethernet Links and may be absent for other link technologies.) Ethernet Links.)
The following values for ERR are specified: The following values for ERR are specified:
ERR Meaning ERR Meaning
--- ------- --- -------
0 - Not an RBridge Channel error frame. 0 - Not an RBridge Channel error frame.
1 Frame too short (truncated Ethertype or RBridge Channel Header) 1 Frame too short (truncated Ethertype or RBridge Channel Header)
2 Unrecognized Ethertype 2 Unrecognized Ethertype
3 Unimplemented value of CHV 3 Unimplemented value of CHV
4 Wrong value of NA flag 4 Wrong value of NA flag
skipping to change at page 14, line 9 skipping to change at page 14, line 9
All RBridges implementing the RBridge Channel feature MUST recognize All RBridges implementing the RBridge Channel feature MUST recognize
the RBridge Channel Error protocol value (0x001). They MUST NOT the RBridge Channel Error protocol value (0x001). They MUST NOT
generate an RBridge Channel Error message in response to a RBridge generate an RBridge Channel Error message in response to a RBridge
Channel Error message, that is, a channel message with a protocol Channel Error message, that is, a channel message with a protocol
value of 0x001 or with a non-zero ERR field. value of 0x001 or with a non-zero ERR field.
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
4. Native RBridge Channel Frames 4. Native RBridge Channel Frames
Other sections of this document specify non-native RBridge Channel
messages and their processing, that is, RBridge Channel messages
formatted as TRILL Data frames and sent between RBridges. This
section specifies the differences for native RBridge Channel
messages.
If provided for by the channel protocol involved, native RBridge If provided for by the channel protocol involved, native RBridge
channel messages may be sent between end-stations and RBridges in channel messages may be sent between end-stations and RBridges that
either direction. On an Ethernet link, such native frames have the are directly connected over a link, in either direction. On an
RBridge-Channel Ethertype and are like the encapsulated frame inside Ethernet link, such native frames have the RBridge-Channel Ethertype
an RBridge Channel message with the following exceptions: and are like the encapsulated frame inside an RBridge Channel message
except as follows:
1. TRILL does not require the presence of a VLAN tag on such 1. TRILL does not require the presence of a VLAN tag on such
native RBridge channel frames. However, port configuration, native RBridge channel frames. However, port configuration,
link characteristics, or the channel protocol involved may link characteristics, or the channel protocol involved may
require such tagging. require such tagging.
2. If the frame is unicast, the destination MAC address is the 2. If the frame is unicast, the destination MAC address is the
unicast MAC address of the RBridge or end-station port that is unicast MAC address of the RBridge or end-station port that is
its intended destination. If the frame is multicast by an end its intended destination. If the frame is multicast by an end
station to all the RBridges on a link that support an RBridge station to all the RBridges on a link that support an RBridge
Channel protocol that uses this transport, the destination MAC Channel protocol that uses this transport, the destination MAC
address is the All-Edge-RBridges multicast address. If the address is the All-Edge-RBridges multicast address (see Section
frame is multicast by an RBridge to all the devices that TRILL 6). A native RBridge Channel frame received at an ingress
considers to be end stations on a link that support an RBridge RBridge with a destination MAC address that is a unicast
Channel protocol that uses this transport, the destination MAC address different from that of the port or multicast address
address is the TRILL-End-Stations multicast address (see different from All-Edge-RBridges, is discarded. If the frame is
Section 6). The RBridge-Channel Ethertype must be present. In multicast by an RBridge to all the devices that TRILL considers
the future there may be other protocols using the All-Edge- to be end stations on a link that support an RBridge Channel
RBridges and/or TRILL-End-Stations multicast addresses on protocol that uses this transport, the destination MAC address
native frames distinguished by different Ethertypes. is the TRILL-End-Stations multicast address (see Section 6). A
native RBridge Channel frame received at an end station with a
destination MAC address that is a unicast address different
from that of the port or multicast address different from
TRILL-End-Stations, is discarded.
3. The NA or native bit in the RBridge Channel Header flags must 3. The RBridge-Channel outer Ethertype must be present. In the
be a one. future there may be other protocols using the All-Edge-RBridges
and/or TRILL-End-Stations multicast addresses on native frames
distinguished by different Ethertypes.
4. As with any Ethernet frame, the source MAC address is that of 4. The NA or native bit in the RBridge Channel Header flags must
the port sending the frame. be a one.
5. There might be additional tags present between the Outer.MacDA, 5. There might be additional tags present between the Outer.MacDA,
Outer.MacSA pair and the RBridge-Channel Ethertype. Outer.MacSA pair and the RBridge-Channel Ethertype.
If provided for by the channel protocol involved, the receipt of such
a native RBridge Channel frame MAY lead to the generation and
transmission of one or more native or TRILL Data RBridge Channel
frames. The decapsulation and processing of a TRILL Data 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.
An erroneous native RBridge Channel message results in a native
RBridge channel error message under the same conditions for which an
TRILL Data RBridge Channel message would result in a TRILL Data
RBridge channel error message. However, in a native RBridge Channel
error message, the NA flag MUST be one. The destination MAC address
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
of such error messages is set to the soure MAC address of the native The RBridge Channel protocol number space for native RBridge Channel
RBridge Channel message that was in error. messages and TRILL Data formatted RBridge Channel messages is the
same. If provided for by the channel protocol involved, the receipt
of a native RBridge Channel frame MAY lead to the generation and
transmission of one or more Inter-RBridge Channel frames. The
decapsulation and processing of a TRILL Data 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. Thus, there could be an RBridge Channel protocol that
involved an RBridge Channel message sent from an origin RBridge where
the message is created, through one or more other RBridges and from
the last as a native RBridge channel message to and end station or
the reverse of such a path; however, to do this the RBridge channel
protocol involved must be implemented at the RBridge where the
channel message is changed between a native frame and a TRILL Data
format frame and must change the channel message itself, at a minimum
complementing the NA flag in the Channel Header and making
appropriate MAC address changes.
An erroneous native channel message results in a native RBridge
channel error message under the same conditions for which an TRILL
Data RBridge Channel message would result in a TRILL Data RBridge
channel error message. However, in a native RBridge Channel error
message, the NA flag MUST be one. Also, since there is no TRILL
Header in native RBridge Channel protocol frames, the beginning part
of the frame in which the error was detected that is included in
native RBridge Channel error frames starts with the RBridge Channel
Header (including the RBridge-Channel Ethertype). The destination MAC
address of such error messages is set to the source MAC address of
the native RBridge Channel message that was in error.
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
5. Indicating Support for RBridge Channel Protocols 5. Indicating Support for RBridge Channel Protocols
Support for RBridge Channel protocols is indicated by the presence of Support for RBridge Channel protocols is indicated by the presence of
one or more TLVs or sub-TLVs in an RBridge's LSP as documented in one or more TLVs and/or sub-TLVs in an RBridge's LSP as documented in
[RFC6326bis]. [RFC6326bis].
RBridge Channel protocols 0 and 0xFFF are reserved and protocol 1, 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 error protocol, MUST be implemented as part of
the RBridge Channel feature. Thus, if an RBridge supports the RBridge the RBridge Channel feature. Thus, if an RBridge supports the RBridge
Channel feature, it should be advertising support for protocol 1 and Channel feature, it should be advertising support for protocol 1 and
not advertising support for protocols 0 or 0xFFF in its LSP. not advertising support for protocols 0 or 0xFFF in its LSP.
However, indication of support or non-support for RBridge Channel However, indication of support or non-support for RBridge Channel
protocol 1 is ignored on receipt and support for it is always protocol 1 is ignored on receipt and support for it is always
assumed, if support for any RBridge Channel is indicated in the assumed, if support for any RBridge Channel is indicated in the
skipping to change at page 17, line 45 skipping to change at page 17, line 45
-------- ----------- --------- -------- ----------- ---------
0x000 Reserved (This document) 0x000 Reserved (This document)
0x001 RBridge Channel Error (This document) 0x001 RBridge Channel Error (This document)
0x002-0x0FF Available (1) 0x002-0x0FF Available (1)
0x100-0xFF7 Available (2) 0x100-0xFF7 Available (2)
0xFF8-0xFFE Private Use 0xFF8-0xFFE Private Use
0xFFF Reserved (This document) 0xFFF Reserved (This document)
(1) RBridge Channel protocol code points from 0x002 to 0x0FF require (1) RBridge Channel protocol code points from 0x002 to 0x0FF require
a Standards Action as modified by [RFC4020] for allocation. a Standards Action, as modified by [RFC4020], for allocation.
(2) RBridge Channel protocol code points from 0x100 to 0xFF7 require (2) RBridge Channel protocol code points from 0x100 to 0xFF7 require
RFC Publication to allocate a single value or IETF Review to allocate RFC Publication to allocate a single value or IETF Review to allocate
multiple values. multiple values.
IANA is requested to create an additional sub-registry in the TRILL IANA is requested to create an additional sub-registry in the TRILL
Parameter Registry for RBridge Channel Header Flags with initial Parameter Registry for RBridge Channel Header Flags with initial
contents as follows: contents as follows:
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
skipping to change at page 19, line 9 skipping to change at page 19, line 9
6.2 IEEE Registration Authority Considerations 6.2 IEEE Registration Authority Considerations
The IEEE Registration Authority has been assigned the Ethertype <TBD> The IEEE Registration Authority has been assigned the Ethertype <TBD>
for RBridge-Channel. for RBridge-Channel.
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
7. Security Considerations 7. Security Considerations
See [RFC6325] for general TRILL Security Considerations.
No general integrity, authentication, or encryption mechanisms are No general integrity, authentication, or encryption mechanisms are
provided herein for RBridge Channel messages. If these services are provided herein for RBridge Channel messages. If these services are
required for a particular RBridge Channel protocol, they must be required for a particular RBridge Channel protocol, they must be
supplied by that channel protocol. See, for example, the BFD supplied by that channel protocol. See, for example, the BFD
Authentication mechanism [RFC5880]. Authentication mechanism [RFC5880].
If indication of RBridge Channel Protocol support are improperly If indication of RBridge Channel Protocol support are improperly
absent from an RBridge's LSP, it could deny all RBridge Channel absent from an RBridge's LSP, it could deny all RBridge Channel
services, for example some OAM services, for the RBridge in question. services, for example some BFD services, for the RBridge in question.
If a particular RBridge channel protocol is incorrectly not If a particular RBridge channel protocol is incorrectly not
advertised as supported, it would deny the service of that channel advertised as supported, it would deny the service of that channel
protocol to the RBridge in question. protocol to the RBridge in question.
Incorrect presence of indication of RBridge Channel Protocol support Incorrect presence of indication of RBridge Channel Protocol support
or incorrect assertion of support for a channel protocol could or incorrect assertion of support for a channel protocol could
encourage RBridge channel messages to be sent to an RBridge that does encourage RBridge channel messages to be sent to an RBridge that does
not support that channel protocol. The inner frame of such messages not support the channel feature or the particular channel protocol
could be decapsulated and that inner frame would likely be sent out used. The inner frame of such messages could be decapsulated and that
all ports that are appointed forwarders for the frame's Inner.VLAN. inner frame could be sent out all ports that are appointed forwarders
However, this is unlikely to cause much harm. There are two for the frame's Inner.VLAN. However, this is unlikely to cause much
possibilities: (a) If end stations do not recognize the RBridge- harm; in particuclar, there are two possibilities as follows: (a) If
Channel Ethertype of the frame, they will drop it. (b) If end end stations do not recognize the RBridge-Channel Ethertype of the
stations do recognize the RBridge-Channel Ethertype and the channel frame, they will drop it. (b) If end stations do recognize the
protocol indicated in the frame, they should refuse to process the RBridge-Channel Ethertype and the channel protocol indicated in the
frame due to an incorrect value of the RBridge Channel Header NA frame, they should refuse to process the frame due to an incorrect
flag. value of the RBridge Channel Header NA flag.
See [RFC6325] for general TRILL Security Considerations. No protection is provided against forging or the ingress nickname in
a TRILL Data formatted channel message or the Outer.MacSA in a native
RBridge Channel frame. This may result in misdirected return
responses or error messages.
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
8. References 8. References
The following sections list normative and informative references for The following sections list normative and informative references for
this document. this document.
8.1 Normative References 8.1 Normative References
skipping to change at page 21, line 16 skipping to change at page 21, line 16
[RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., [RFC5586] - Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
"MPLS Generic Associated Channel", RFC 5586, June 2009. "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection [RFC5880] - D. Katz, D. Ward, "Bidirectional Forwarding Detection
(BFD)", June 2010. (BFD)", June 2010.
[RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional [RFC5882] - D. Katz, D. Ward, "Generic Application of Bidirectional
Forwarding Detection (BFD)", June 2010. Forwarding Detection (BFD)", June 2010.
[RFC6291] - Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V. [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, A. Banerjee, V.
Manral, "TRILL: Clarifications, Corrections, and Updates", Manral, "TRILL: Clarifications, Corrections, and Updates",
draft-eastlake-trill-rbridge-clear-correct, work in progress. draft-ietf-trill-clear-correct, work in progress.
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
Appendix: Change History Appendix: Change History
RFC Editor: please delete this appendix before publication. RFC Editor: please delete this appendix before publication.
Changes from -00 to -01 Changes from -00 to -01
1. Spell out more acronyms. 1. Spell out more acronyms.
2. Add reference to "Guidelines for the Use of OAM" draft. 2. Add reference to "Guidelines for the Use of OAM" draft.
3. Move definition of Alert flag to draft-ietf-trill-rbridge-options 3. Move definition of Alert flag to draft-ietf-trill-rbridge-options
and refer to it as an extended header flag. and refer to it as an extended header flag.
4. Change name of "Egress-RBridges" multicast address to "All-Egress- 4. Change name of "Egress-RBridges" multicast address to "All-Egress-
RBridges". Merge with All-IS-IS-RBridges (i.e., they are two names RBridges". Merge with All-ESADI-RBridges (i.e., they are two names
for the same MAC address). for the same MAC address).
5. Add detailed bit vector description for indicating support of 5. Add detailed bit vector description for indicating support of
RBridge channel protocols. Add GENAPP and an APPsub-TLV to hold RBridge channel protocols. Add GENAPP and an APPsub-TLV to hold
one or more bit vectors. one or more bit vectors.
6. Assorted editorial changes. 6. Assorted editorial changes.
Changes from -01 to -02 Changes from -01 to -02
skipping to change at page 22, line 46 skipping to change at page 22, line 46
3. Remove GENAPP and move RBridge Channels supported information to 3. Remove GENAPP and move RBridge Channels supported information to
another document. another document.
4. Clarify native RBridge Channel error messages. 4. Clarify native RBridge Channel error messages.
5. Assorted editorial changes. 5. Assorted editorial changes.
Changes from -02 to -03 Changes from -02 to -03
1. Liberalize restrictions on RBridge acceptance of native RBridge 1. Liberalize restrictions on RBridge acceptance of native RBridge
Channel messages. These are typically OAM messages and should Channel messages. These are typically messages and should
generally be accepted unless in a VLAN not enabled at the port or generally be accepted unless in a VLAN not enabled at the port or
the like. the like.
2. Change multi-cast address used by end stations in sending a native 2. Change multi-cast address used by end stations in sending a native
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
RBridge Channel message to all RBridges on the link from All- RBridge Channel message to all RBridges on the link from All-
Egress-RBridges to All-Edge-RBridges to avoid possible confusion Egress-RBridges to All-Edge-RBridges to avoid possible confusion
if such a frame were encapsulated resulting in an All-Egress- if such a frame were encapsulated resulting in an All-Egress-
skipping to change at page 24, line 5 skipping to change at page 23, line 32
1. Update for the replacement of the CFI bit by the DEI bit (see 1. Update for the replacement of the CFI bit by the DEI bit (see
[ClearCorrect]). [ClearCorrect]).
2. Update for the existence of both critical and non-critical RBridge 2. Update for the existence of both critical and non-critical RBridge
Channel alert flags. Channel alert flags.
3. Update author information. 3. Update author information.
4. Assorted editorial changes. 4. Assorted editorial changes.
Changes from -04 to -05
1. Clarify the distinction between native and non-native RBridge
Channel messages and that native channel messages are only
intended to be transmitted between RBridge and end stations on the
same link.
2. Add a paragraph to the Security Considerations section about
forged ingress nicknames / source MAC addresses in channel
messages.
3. Add acknowledgements section.
4. Replace "OAM" references with "BFD" references in Abstract and
Introduction.
5. Very minor editorial changes.
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
Acknowledgmnts
The authors gratefully acknowledge the comments and contributions of
the follows, listed is alphabetic order: Somnath Chatterjee, Anoop
Ghanwani, Raksh Kumar, and Tissa Senevirathne.
Authors' Addresses Authors' Addresses
Donald Eastlake 3rd Donald Eastlake 3rd
Huawei R&D USA Huawei R&D USA
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757 USA
Tel: +1-508-333-2270 Tel: +1-508-333-2270
EMail: d3e3e3@gmail.com EMail: d3e3e3@gmail.com
skipping to change at page 24, line 46 skipping to change at page 25, line 5
Santa Clara, CA 95050 USA Santa Clara, CA 95050 USA
Phone: +1-408-330-5000 Phone: +1-408-330-5000
Email: sam.aldrin@huawei.com Email: sam.aldrin@huawei.com
Dave Ward Dave Ward
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
INTERNET-DRAFT TRILL: RBridge Channel
EMail: dward@cisco.com EMail: dward@cisco.com
INTERNET-DRAFT TRILL: RBridge Channel INTERNET-DRAFT TRILL: RBridge Channel
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
 End of changes. 61 change blocks. 
146 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/