< draft-eastlake-trill-rbridge-dcb-03.txt   draft-eastlake-trill-rbridge-dcb-04.txt >
skipping to change at page 1, line 13 skipping to change at page 1, line 13
TRILL Working Group Donald Eastlake TRILL Working Group Donald Eastlake
INTERNET-DRAFT Huawei INTERNET-DRAFT Huawei
Intended status: Proposed Standard Manoj Wadekar Intended status: Proposed Standard Manoj Wadekar
Updates: 6325 QLogic Updates: 6325 QLogic
Anoop Ghanwani Anoop Ghanwani
Dell Dell
Puneet Agarwal Puneet Agarwal
Broadcom Broadcom
Tal Mizrahi Tal Mizrahi
Marvell Marvell
Expires: September 1, 2012 March 2, 2012 Expires: March 31, 2013 October 2, 2012
RBridges: Support of IEEE 802.1Qbb, 802.1Qaz, and 802.1Qau TRILL: Support of IEEE 802.1Qbb, 802.1Qaz, and Congestion Notification
<draft-eastlake-trill-rbridge-dcb-03.txt> <draft-eastlake-trill-rbridge-dcb-04.txt>
Abstract Abstract
IEEE 802.1 has developed standards as part of its Data Center IEEE 802.1 has developed standards as part of its Data Center
Bridging (DCB) activity to (1) efficiently minimize data loss due to Bridging (DCB) activity to (1) efficiently minimize data loss due to
queue overflow for selected classes of traffic within Local Area queue overflow for selected classes of traffic within Local Area
Networks (LANs) meeting certain conditions and (2) provide means to Networks (LANs) meeting certain conditions and (2) provide means to
allocate the available bandwidth on links to different classes of allocate the available bandwidth on links to different classes of
traffic. These standards were adopted as the IEEE 802.1Qbb, 802.1Qaz, traffic. These standards are now in IEEE Std 802.1Qbb-2011, IEEE Std
and 802.1Qau amendmenst to the 802.1Q standard. 802.1Qaz-2011, and the Congestion Notificaiton freature in IEEE Std
802.1Q-2011.
This document briefly explains the standards and discusses the This document briefly explains these standards and discusses the
support of these IEEE 802 standards in RBridges (devices that support of these IEEE 802 standards in TRILL switches (devices that
implement the IETF TRILL standard). implement the IETF TRILL protocol standard).
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 authors or the TRILL working group mailing list: to the authors.
<rbridge@postel.org>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
Table of Contents Table of Contents
1. Introduction............................................4 1. Introduction............................................4
1.1 Overview of These Standards............................5 1.1 Overview of These Standards............................5
1.2 Terminology............................................6 1.2 Terminology............................................6
1.3 Additional Acronyms....................................6 1.3 Additional Acronyms....................................6
2. Priority-Based Flow Control.............................7 2. Priority-Based Flow Control.............................7
3. Enhanced Transmission Selection.........................8 3. Enhanced Transmission Selection.........................8
4. The DCB Exchange Protocol...............................8 4. The DCB Exchange Protocol...............................9
5. Congestion Notification.................................9
5.1 Congestion Notification Domains.......................11
5.2 Congestion Notification Tag Details...................13
5.3 Congestion Notification Message Details...............13
5.4 Additions to TRILL to Support Congestion Notification.14
5.4.1 RBridge Ingress Details.............................15
5.4.2 Transit RBridge Details.............................19
5.4.2.1 Transit RBridge Input Port........................19
5.4.2.2 Transit RBridge Output Port.......................19
5.4.3 RBridge Egress Details..............................20
6. Management Considerations..............................21 5. Congestion Notification................................10
7. IANA Considerations....................................21 5.1 Congestion Notification Domains.......................12
8. Security Considerations................................21 5.2 Congestion Notification Tag Details...................14
5.3 Congestion Notification Message Details...............14
5.4 Additions to TRILL to Support Congestion Notification.15
5.4.1 TRILL Switch Ingress Details........................16
5.4.2 Transit TRILL Switch Details........................19
5.4.2.1 Transit TRILL Switch Input Port...................20
5.4.2.2 Transit TRILL Switch Output Port..................20
5.4.3 TRILL Switch Egress Details.........................21
9. References.............................................22 6. Management Considerations..............................22
9.1 Normative References..................................22 7. IANA Considerations....................................22
9.2 Informative References................................22 8. Security Considerations................................22
Version History...........................................24 9. References.............................................23
9.1 Normative References..................................23
9.2 Informative References................................23
Version History...........................................25
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
1. Introduction 1. Introduction
IEEE 802.1 has developed various standards as part of its Data Center IEEE 802.1 has developed various standards as part of its Data Center
Bridging (DCB) activity. These include the 802.1Qau, 802.1Qaz, and Bridging (DCB) activity. The intent of three of these standards is
802.1Qbb amendments to IEEE [802.1Q]. The intent of these three (1) to efficiently eliminate data loss due to queue overflow for
standards is (1) to efficiently eliminate data loss due to queue selected classes of traffic within Local Area Networks (LANs) meeting
overflow for selected classes of traffic within Local Area Networks certain conditions and (2) to provide limited means to allocate the
(LANs) meeting certain conditions and (2) to provide limited means to available bandwidth to different classes of traffic. Those three
allocate the available bandwidth to different classes of traffic. standardes are Priority Based Flow Control (the IEEE [802.1Qbb]
Intended uses include the support of loss sensitive services, such as standard), Enhanced Tramission Selection (the IEEE [802.1Qaz]
Fiber Channel over Ethernet [FCoE], in data centers. Because they standard), and the Congestion Notification (CN) feature in the IEEE
are primarily implemented at the 802.1Q port level, no changes in the [802.1Q] standard. Intended uses include the support of loss
TRILL protocol are required to support IEEE 802.1Qbb or 802.1Qaz. To sensitive services, such as Fiber Channel over Ethernet [FCoE], in
support 802.1Qau, minor changes to TRILL are required as specified data centers. Because they are primarily implemented at the port
herein. level, no changes in the TRILL protocol are required to support IEEE
802.1Qbb or 802.1Qaz. To support 802.1Qau, minor changes to TRILL are
required as specified herein.
The existing optional PAUSE feature of IEEE 802.3 (Annex 31B of The existing optional PAUSE feature of IEEE 802.3 (Annex 31B of
[802.3]) can, with appropriate engineering, also provide Ethernet [802.3]) can, with appropriate engineering, also provide Ethernet
service without loss of frames due to queue overflow. However, PAUSE service without loss of frames due to queue overflow. However, PAUSE
has problems as follows: has problems as follows:
1. Traffic for some protocols, for example TCP [RFC793], requires 1. Traffic for some protocols, for example TCP [RFC793], requires
frame losses to signal congestion for flow control. Elimination of frame losses to signal congestion for flow control. Elimination of
frame drops due to congestion would prevent TCP flow control, frame drops due to congestion would prevent TCP flow control,
unless some other mechanism were added. unless some other mechanism were added.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
out that port it is likely that output queues to P1 will fill up out that port it is likely that output queues to P1 will fill up
quickly. As soon as one output queue to P1 is full or almost so quickly. As soon as one output queue to P1 is full or almost so
then, to avoid frame loss, S1 must send PAUSE frames out on each then, to avoid frame loss, S1 must send PAUSE frames out on each
of its ports that might receive a frame for output to P1. For of its ports that might receive a frame for output to P1. For
example, it might have to PAUSE input on P2 through P9, example, it might have to PAUSE input on P2 through P9,
unnecessarily blocking traffic between any pair of those ports, to unnecessarily blocking traffic between any pair of those ports, to
be sure it will not receive input on any of them for P1. This can be sure it will not receive input on any of them for P1. This can
repeat in switches connected to S1, switches connected to switches repeat in switches connected to S1, switches connected to switches
connected to S1, etc. connected to S1, etc.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
1.1 Overview of These Standards 1.1 Overview of These Standards
Overviews of the three DCB standards covered herein are given below. Overviews of the three DCB standards covered herein are given below.
IEEE 802.1 has specified theses standards and the behavior needed to IEEE 802.1 has specified theses standards and the behavior needed to
support them in bridges and end stations. This document discusses the support them in bridges and end stations. This document discusses the
support of these standards in RBridges [RFC6325]. support of these standards in TRILL switches (commonly called
RBridges [RFC6325]).
IEEE [802.1Qbb], Priority-based Flow Control (PFC), provides a frame IEEE [802.1Qbb], Priority-based Flow Control (PFC), provides a frame
priority based refinement of the Ethernet PAUSE feature as described priority based refinement of the Ethernet PAUSE feature as described
in Section 2. To the extent that a switch implements separate queues in Section 2. To the extent that a switch implements separate queues
for different priorities at each port, this can eliminate the first for different priorities at each port, this can eliminate the first
and second of the PAUSE problems listed above. Traffic requiring and second of the PAUSE problems listed above. Traffic requiring
frame drops due to congestion can be assigned a priority for which frame drops due to congestion can be assigned a priority for which
PFC is not enabled. PFC is not normally enabled for the two highest PFC is not enabled. PFC is not normally enabled for the two highest
priorities, 6 and 7, which are typically used for time sensitive priorities, 6 and 7, which are typically used for time sensitive
control frames. PFC also reduces the third problem as any congestion control frames. PFC also reduces the third problem as any congestion
skipping to change at page 6, line 5 skipping to change at page 6, line 5
that frames that require drops due to congestion for flow control can that frames that require drops due to congestion for flow control can
be assigned a priority for which CN is not enabled. CN avoids the be assigned a priority for which CN is not enabled. CN avoids the
second problem because it is not normally used to limit priorities 6 second problem because it is not normally used to limit priorities 6
and 7, which are typically used for time sensitive control frames. and 7, which are typically used for time sensitive control frames.
And CN avoids the third problem listed above for PAUSE because it And CN avoids the third problem listed above for PAUSE because it
acts by restraining end station flow sources rather than blocking acts by restraining end station flow sources rather than blocking
transmission on intermediate switch ports. Section 5 below provides transmission on intermediate switch ports. Section 5 below provides
additional information on CN and specifies additions to the TRILL additional information on CN and specifies additions to the TRILL
protocol to support it. protocol to support it.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
These three DCB standards may be implemented independently or in any These three DCB standards may be implemented independently or in any
combination except that implementation of any of them implies combination except that implementation of any of them implies
implementation of DCBX, specified in IEEE [802.1Qaz]. implementation of DCBX, specified in IEEE [802.1Qaz].
1.2 Terminology 1.2 Terminology
The terminology and acronyms of [RFC6325] are used in this document. The terminology and acronyms of [RFC6325] are used in this document.
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].
1.3 Additional Acronyms 1.3 Additional Acronyms
The following acronyms are used in this document in addition to those The following acronyms are used in this document in addition to those
defined in [RFC6325]. defined in [RFC6325].
AVB - Audio-Visual Bridging AVB - Audio-Visual Bridging
CN - Congestion Notification CN - Congestion Notification [802.1Q]
CNM - Congestion Notification Message CNM - Congestion Notification Message
CNtag - Congestion Notification tag CNtag - Congestion Notification tag
DCB - Data Center Bridging DCB - Data Center Bridging [802.1Qaz]
DCBX - DCB Exchange protocol DCBX - DCB Exchange protocol [802.1Qaz]
ETS - Enhanced Transmission Selection (IEEE 802.1Qaz) ETS - Enhanced Transmission Selection [802.1Qaz]
FCoE - Fiber Channel over Ethernet FCoE - Fiber Channel over Ethernet [FCoE]
LLDP - Link Layer Discovery Protocol (IEEE 802.1AB) LLDP - Link Layer Discovery Protocol (IEEE 802.1AB)
PFC - Priority-based Flow Control (IEEE 802.1Qbb, 802.3bd) PFC - Priority-based Flow Control [802.1Qbb] [802.3bd]
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support RBridge - Routing Bridge [RFC6325]
TRILL Switch - An alternative name for an RBridge
INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
2. Priority-Based Flow Control 2. Priority-Based Flow Control
IEEE [802.1Qbb], Priority-Based Flow Control (PFC), refines the IEEE IEEE [802.1Qbb], Priority-Based Flow Control (PFC), refines the IEEE
[802.3] PAUSE feature to permit separately requesting, on a physical [802.3] PAUSE feature to permit separately requesting, on a physical
link, pausing and unpausing the traffic of each of the eight Ethernet link, pausing and unpausing the traffic of each of the eight
available frame priority levels. The actual priority-based pause available frame priority levels. The actual priority-based pause
Ethernet control frame is specified in IEEE [802.3bd]. Ethernet control frame is specified in IEEE [802.3bd].
Such queue pausing occurs within the transmission logic associated Such queue pausing occurs within the transmission logic associated
with a port and requires no changes to the TRILL protocol, which is with a port and requires no changes to the TRILL protocol, which is
implemented above such port logic, as described in [RFC6325]. implemented above such port logic, as described in [RFC6325].
LLDP/DCBX is used in PFC discovery and agreement with peers as LLDP/DCBX is used in PFC discovery and agreement with peers as
described in Section 4. An RBridge implementing the PFC standard MUST described in Section 4. A TRILL switch implementing the PFC standard
implement DCBX, signaling PFC support and configuration. Guarantee of MUST implement DCBX, signaling PFC support and configuration.
lossless handling of frames with a particular priority in an RBridge Guarantee of lossless handling of frames with a particular priority
campus requires implementation and enablement of PFC for that in a TRILL campus requires implementation and enablement of PFC for
priority at all end stations that originate frames and all RBridges that priority at all end stations that originate frames and all TRILL
and bridges in that campus as well as meeting the PFC engineering switches and bridges in that campus as well as meeting the PFC
requirements specified in [802.1Qbb]. engineering requirements in [802.1Qbb].
The PFC control frames specified in [802.3bd] are MAC control frames The PFC control frames specified in [802.3bd] are MAC control frames
that are not VLAN tagged. Their transmission normally bypasses the that are not VLAN tagged. Their transmission normally bypasses the
output queue at a port so they are transmitted immediately, or as output queue at a port so they are transmitted immediately, or as
soon as the frame currently being transmitted is sent, so as to meet soon as the frame currently being transmitted is sent, so as to meet
the timing requirements of PFC. the timing requirements of PFC.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
3. Enhanced Transmission Selection 3. Enhanced Transmission Selection
Enhanced Transmission Selection (ETS), specified in IEEE [802.1Qaz], Enhanced Transmission Selection (ETS), specified in IEEE [802.1Qaz],
allocates bandwidth, between traffic classes, through each of the allocates bandwidth, between traffic classes, through each of the
ports of a switch or end station. (To be more precise, it modifies ports of a switch or end station. (To be more precise, it modifies
the algorithm used to select, from multiple priority-based output the algorithm used to select, from multiple priority-based output
queues at a port, the next frame to transmit. Provision is made for queues at a port, the next frame to transmit. Provision is made for
proprietary algorithms and 802.1 has also specified an algorithm in proprietary algorithms and 802.1 has also specified an algorithm in
connection with precise frame timing (AVB), but we are only concerned connection with precise frame timing (AVB), but we are only concerned
with the default DCB algorithm.) with the default DCB algorithm.)
Transmission selection occurs within the logic associated with a port Transmission selection occurs within the logic associated with a port
and requires no changes to the TRILL protocol, which is implemented and requires no changes to the TRILL protocol, which is implemented
above such port logic, as described in [RFC6325]. An RBridge above such port logic, as described in [RFC6325]. A TRILL switch
implementing the ETS standard MUST implement DCBX (see Section 4) implementing the ETS standard MUST implement DCBX (see Section 4)
signaling of ETS support and configuration. For ETS to be effective, signaling of ETS support and configuration. For ETS to be effective,
traffic in different ETS groups cannot share an output queue. traffic in different ETS groups cannot share an output queue.
INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
4. The DCB Exchange Protocol 4. The DCB Exchange Protocol
The DCB Exchange Protocol (DCBX) is specified in IEEE [802.1Qaz], The DCB Exchange Protocol (DCBX) is specified in IEEE [802.1Qaz],
which also specifies ETS as described in Section 3. which also specifies ETS as described in Section 3.
DCBX is built on the Link Layer Discovery Protocol (LLDP), which is DCBX is built on the Link Layer Discovery Protocol (LLDP), which is
specified in IEEE [802.1AB]. DCBX is used for the discovery of DCB specified in IEEE [802.1AB]. DCBX is used for the discovery of DCB
capabilities of peer switches, for the detection of inconsistent capabilities of peer switches, for the detection of inconsistent
configuration of DCB features between peer switches, and for the configuration of DCB features between peer switches, and for the
propagation of DCB features to switches configured to accept propagation of DCB features to switches configured to accept
configuration via DCBX. For purposes of TRILL protocol peering, configuration via DCBX. For purposes of TRILL protocol peering, TRILL
RBridges ignore intervening bridges, but for the purposes of LLDP and switches ignore intervening bridges, but for the purposes of LLDP and
DCBX all stations, including RBridges, 802.1 bridges, and end DCBX all stations, including TRILL switches, 802.1 bridges, and end
stations are considered peers. stations are considered peers.
RBridges implementing any of the three DCB protocols MUST also TRILL switches implementing any of the three DCB protocols MUST also
implement DCBX. implement DCBX.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
5. Congestion Notification 5. Congestion Notification
Congestion Notification (CN) can limit flows to minimize frame loss Congestion Notification (CN) can limit flows to minimize frame loss
by having congestion points that detect congestion and send by having congestion points that detect congestion send Congestion
Congestion Notification Messages (CNMs) back to reaction points in Notification Messages (CNMs) back to reaction points in end stations
end stations that can limit flows. See [802.1Q] for the specification that can limit flows. See [802.1Q] for the specification of the CN
of the CN algorithms to perform at congestion and reaction points. algorithms to perform at congestion and reaction points. Congestion
Congestion Notification is designed to operate best in minimizing Notification is designed to operate best in minimizing frame loss of
frame loss of unicast flows in a LAN composed of point-to-point unicast flows in a LAN composed of point-to-point physical links
physical links where all switches have implemented Congestion where all switches have implemented Congestion Notification.
Notification.
An RBridge that implements Congestion Notification may act as an end A TRILL switch that implements Congestion Notification may act as an
point, for example when sourcing or sinking SNMP management frames, end point, for example when sourcing or sinking SNMP management
and thus may contain one or more reaction points, as well as frames, and thus may contain one or more reaction points, as well as
implementing congestion points at its output queues. implementing congestion points at its output queues.
Reaction points are in end stations where flows originate and are the Reaction points are in end stations where flows originate and are the
mechanism to limit flows. The granularity of reaction points is mechanism to limit flows. The granularity of reaction points is
beyond the scope of CN and this document but cannot be larger than a beyond the scope of CN and this document but cannot be larger than a
priority at a MAC address. If the granularity is smaller and there priority at a MAC address. If the granularity is smaller and there
are multiple reaction points in an end station for a given priority, are multiple reaction points in an end station for a given priority,
then the end station must label outgoing frames with a Congestion then the end station must label outgoing frames with a Congestion
Notification tag (CNtag) that includes an end station flow ID. This Notification tag (CNtag) that includes an end station flow ID. This
flow ID is an opaque field to the rest or the network. flow ID is an opaque field to the rest or the network.
skipping to change at page 10, line 4 skipping to change at page 10, line 55
output queues. The functions of a congestion point are (1) to output queues. The functions of a congestion point are (1) to
conditionally send Congestion Notification Messages (CNMs) to the conditionally send Congestion Notification Messages (CNMs) to the
source of a frame and (2) to conditionally strip Congestion source of a frame and (2) to conditionally strip Congestion
Notification tags (CNtags) out of a frame being forwarded, for Notification tags (CNtags) out of a frame being forwarded, for
example if it is being forwarded out of a congestion notifiation example if it is being forwarded out of a congestion notifiation
domain. domain.
When a frame is to be inserted into an output queue with a congestion When a frame is to be inserted into an output queue with a congestion
point, the procedures specified in IEEE [802.1Q] are used to point, the procedures specified in IEEE [802.1Q] are used to
determine if a CNM should be sent to the frame's source and if so to determine if a CNM should be sent to the frame's source and if so to
determine various fields in that CNM. When a frame is to be inserted
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
determine various fields in that CNM. When a frame is to be inserted
into an output queue with a congestion point, the congestion point into an output queue with a congestion point, the congestion point
may remove any CNtag in the frame as discussed in Section 5.1. may remove any CNtag in the frame as discussed in Section 5.1.
Congestion points are implemented within the logic associated with a Congestion points are implemented within the logic associated with a
port and require no changes to RBridges for the output of native port and require no changes to TRILL for the output of native frames,
frames, as TRILL is implemented above such port logic as described in as TRILL is implemented above such port logic as described in
[RFC6325]; however, when outputting a TRILL Data frame, any CNM [RFC6325]; however, when outputting a TRILL Data frame, any CNM
generated needs to be for the TRILL encapsulated frame rather than generated needs to be for the TRILL encapsulated frame rather than
for the entire TRILL Data frame. In that case there are some for the entire TRILL Data frame. In that case there are some
differences between the details of the creation of a CNM at an differences between the details of the creation of a CNM at an TRILL
RBridge output port and at a bridge output port. This CNM also needs switch output port and at a bridge output port. This CNM also needs
to be TRILL encapsulated but this will normally happen automatically to be TRILL encapsulated but this will happen automatically as the
as the CNM is specified by [802.1Q] to be treated as a native frame CNM is specified by [802.1Q] to be treated as a native frame arriving
arriving at the port. at the port.
+-----------------------------------------------+ +-----------------------------------------------+
| Ethernet Header (possibly including VLAN Tag) | | Ethernet Header (possibly including VLAN Tag) |
+-----------------------------------------------+ +-----------------------------------------------+
| CNtag | | CNtag |
+-----------------------------------------------+ +-----------------------------------------------+
| Congestion Notification Message Fixed Fields | | Congestion Notification Message Fixed Fields |
+ - - - - - - - - - - - - - - - - - - - - - - -+ + - - - - - - - - - - - - - - - - - - - - - - -+
| Initial bytes of frame causing CNM | | Initial bytes of frame causing CNM |
+-----------------------------------------------+ +-----------------------------------------------+
| Ethernet FCS | | Ethernet FCS |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 2: Native Congestion Notification Message Figure 2: Native Congestion Notification Message
Within a contiguous part of the campus where Congestion Notification Within a contiguous part of the TRILL campus where Congestion
is enabled (see Section 5.1), you would see the same frames with the Notification is enabled (see Section 5.1), you would see the same
same tags as in a similar bridged LAN except that those frames will frames with the same tags as in a similar bridged LAN except that
be TRILL encapsulated as shown in Figures 3 and 4. The exception is those frames will be TRILL encapsulated as shown in Figures 3 and 4.
when a TRILL-ignorant bridge within the campus produces a CNM in The exception is when a TRILL-ignorant bridge within the campus
response to a TRILL data frame as shown in Figure 6. The resulting produces a CNM in response to a TRILL data frame as shown in Figure
CNM is corrected by the first RBridge it encounters, which will be 6. The resulting CNM is corrected by the first TRILL switch it
the previous-hop RBridge. encounters, which will be the previous-hop TRILL switch.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
+-----------------------------------------------+ +-----------------------------------------------+
| Link Header | | Link Header |
+-----------------------------------------------+ +-----------------------------------------------+
| TRILL Header | | TRILL Header |
+-----------------------------------------------+ +-----------------------------------------------+
| CNtag | | CNtag |
+-----------------------------------------------+ +-----------------------------------------------+
| Rest of Native Payload | | Rest of Native Payload |
+-----------------------------------------------+ +-----------------------------------------------+
skipping to change at page 11, line 42 skipping to change at page 12, line 42
| Link Trailer | | Link Trailer |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 4: TRILL Data Form of Congestion Notification Message Figure 4: TRILL Data Form of Congestion Notification Message
5.1 Congestion Notification Domains 5.1 Congestion Notification Domains
Congestion Notification (CN) reduces frame drops due to output queue Congestion Notification (CN) reduces frame drops due to output queue
overflow in a Congestion Notification Domain. There could be many overflow in a Congestion Notification Domain. There could be many
such domains, each specified for a particular priority and contiguous such domains, each specified for a particular priority and contiguous
set of network stations (end stations, RBridges, or bridges), within set of network stations (end stations, TRILL switches, or bridges),
an RBridge campus. For example, two Congestion Notification Domains, within a TRILL campus. For example, two Congestion Notification
one at priority X and one at priority Y, could cover the same set of Domains, one at priority X and one at priority Y, could cover the
contiguous stations, overlapping but different sets of such stations, same set of contiguous stations, overlapping but different sets of
or completely disjoint sets of such stations, in a campus. such stations, or completely disjoint sets of such stations, in a
campus.
CN includes mechanisms to "defend" Congestion Notification Domains, CN includes mechanisms to "defend" Congestion Notification Domains,
that is, make sure only congestion managed flows of frames enter that is, make sure only congestion managed flows of frames enter
congestion point queues. The edge of a domain, i.e. the set of congestion point queues. The edge of a domain, i.e. the set of
station ports in the domain connected by a physical link to a station station ports in the domain directly connected to a station not in
not in the domain, is determined by a combination of auto-detection
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
using LLDP (see Section 4) and management configuration. Bridges that the domain, is determined by a combination of auto-detection using
LLDP (see Section 4) and management configuration. Bridges that
implement Congestion Notification defend a domain by the following: implement Congestion Notification defend a domain by the following:
1. Prohibiting priority mapping inside the domain. 1. Prohibiting priority mapping inside the domain.
2. Mapping the priority of any frame entering the domain from a 2. Mapping the priority of any frame entering the domain from a
station outside the domain to a priority that is not a congestion station outside the domain to a priority that is not a congestion
managed priority. managed priority.
3. Prohibiting the mapping of the priority of any frame entering the 3. Prohibiting the mapping of the priority of any frame entering the
domain from a station outside the domain to the domain's priority. domain from a station outside the domain to the domain's priority.
skipping to change at page 13, line 5 skipping to change at page 14, line 5
- On native frame input, a frame with this priority is mapped to - On native frame input, a frame with this priority is mapped to
a non-CN priority and no native frame can be mapped to this a non-CN priority and no native frame can be mapped to this
priority, regardless of the priority-mapping table at the port. priority, regardless of the priority-mapping table at the port.
For TRILL Data frames, this also applies to the Inner.VLAN For TRILL Data frames, this also applies to the Inner.VLAN
priority. priority.
- If this is an end-station output port, CNtags are not added. - If this is an end-station output port, CNtags are not added.
- If this is a switch output port, CNtags are stripped including - If this is a switch output port, CNtags are stripped including
any CNtag in the encapsulated frame if a TRILL Data frame is any CNtag in the encapsulated frame if a TRILL Data frame is
being output. being output.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
o Interior: o Interior:
- On frame input, a frame in this priority is not mapped to - On frame input, a frame in this priority is not mapped to
another priority and no frame can be mapped to this priority, another priority and no frame can be mapped to this priority,
regardless of the priority-mapping table at this port. For regardless of the priority-mapping table at this port. For
TRILL Data frames, this also applies to the Inner.VLAN TRILL Data frames, this also applies to the Inner.VLAN
priority. priority.
- If this is an end-station output port, CNtags are not added. - If this is an end-station output port, CNtags are not added.
- If this is a switch output port, CNtags are strippedd including - If this is a switch output port, CNtags are strippedd including
any CNtag in the encapsulated frame if a TRILL Data frame is any CNtag in the encapsulated frame if a TRILL Data frame is
skipping to change at page 14, line 5 skipping to change at page 15, line 5
As described in Section 5.3, CNtags are always added to Congestion As described in Section 5.3, CNtags are always added to Congestion
Notification Messages (CNM) when they are created. Notification Messages (CNM) when they are created.
5.3 Congestion Notification Message Details 5.3 Congestion Notification Message Details
A Congestion Notification Message (CNM) is, under certain A Congestion Notification Message (CNM) is, under certain
circumstances, created by a congestion point, as described in IEEE circumstances, created by a congestion point, as described in IEEE
[802.1Q], when a frame is entered into the queue associated with that [802.1Q], when a frame is entered into the queue associated with that
congestion point. The CNM frame always includes a Congestion congestion point. The CNM frame always includes a Congestion
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
Notification tag (CNtag, see Section 5.2). The CNtag includes a zero Notification tag (CNtag, see Section 5.2). The CNtag includes a zero
flow ID if the frame provoking the CNM did not have a CNtag. The body flow ID if the frame provoking the CNM did not have a CNtag. The body
of the CNM itself, after the CNtag, starts with the CNM Ethertype of the CNM itself, after the CNtag, starts with the CNM Ethertype
(0x22E7) followed by the information below: (0x22E7) followed by the information below:
- CNM version information, currently zero - CNM version information, currently zero
- Quantized congestion feedback information as specified in IEEE - Quantized congestion feedback information as specified in
802.1Qau [802.1Q]
- An 8 byte opaque ID of the congestion point generating the CNM - An 8 byte opaque ID of the congestion point generating the CNM
- The priority of the frame causing the CNM - The priority of the frame causing the CNM
- The destination MAC address of the frame causing the CNM - The destination MAC address of the frame causing the CNM
- The number of bytes included from the beginning of the body of - The number of bytes included from the beginning of the body of
the frame causing the CNM the frame causing the CNM
- The first up to 64 bytes of the body of the frame causing the - The first up to 64 bytes of the body of the frame causing the
CNM CNM
Except that input bytes/frame counters are not incremented, a CNM Except that input bytes/frame counters are not incremented, a CNM
generated at an output queue for a port is treated as if it had been generated at an output queue for a port is treated as if it had been
received on that port above the EISS. CNMs are considered to be in received on that port. CNMs are considered to be in the same VLAN as
the same VLAN as the frame that provoked them and have configurable the frame that provoked them and have configurable priority that
priority that defaults to priority 6. defaults to priority 6.
It is undesirable, but not an error, for a CNM to be sent in response It is undesirable, but not an error, for a CNM to be sent in response
to a CNM frame which encounters congestion. This is normally avoided to a CNM frame which encounters congestion. This is normally avoided
by sending CNM frames with a priority which does not have congestion by sending CNM frames with a priority which does not have congestion
notification enabled. notification enabled.
As described in Section 5.4.1.3 below, when a CNM is generated by an As described in Section 5.4.1.3 below, when a CNM is generated by an
RBridge when queuing a TRILL data frame, it is generated for the TRILL switch when queuing a TRILL data frame, it is generated for the
enclosed frame, not for the entire TRILL data frame. This will cause enclosed frame, not for the entire TRILL data frame. This will cause
the CNM to be addressed to the source end station of the data. the CNM to be addressed to the source end station of the data.
5.4 Additions to TRILL to Support Congestion Notification 5.4 Additions to TRILL to Support Congestion Notification
The figure below is used in the discussion in this section. The The figure below is used in the discussion in this section. The
assumption is that a frame is generated at End Station "a" (ESa) assumption is that a frame is generated at End Station "a" (ESa)
destined for End Station "b" (ESb) and this frame is forwarded destined for End Station "b" (ESb) and this frame is forwarded
through the sequence of 802.1 bridges (Bn) and RBridges (RBn) shown. through the sequence of 802.1 bridges (Bn) and TRILL switches
For native frames from ESa, RB1 acts as the ingress RBridge, (RBridges, RBn) shown. For native frames from ESa, RB1 acts as the
encapsulating and directing them to egress RBridge RB3 for ingress TRILL switch, encapsulating and directing them to egress
decapsulation and delivery to ESb. The arrows indicate the flow of a TRILL switch RB3 for decapsulation and delivery to ESb. The arrows
data frame. Any resulting CNM would flow in the opposite direction; indicate the flow of a data frame. Any resulting CNM would flow in
however, such a CNM would be independently routed towards ESa and the opposite direction; however, such a CNM would be independently
would not be constrained to follow the same sequence of switches routed towards ESa and would not be constrained to follow the same
shown below. sequence of switches shown below.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| ESa +-->--+ B1 | + RB3 |-->--+ B3 + | ESa +-->--+ B1 | + RB3 |-->--+ B3 +
+-----+ +--+--+ +--+--+ +--+--+ +-----+ +--+--+ +--+--+ +--+--+
| | | | | |
V ^ V V ^ V
| | | | | |
+--+--+ +-----+ +--+--+ +--+--+ +--+--+ +-----+ +--+--+ +--+--+
| RB1 +-->--+ RB2 +-->--+ B2 + | ESb | | RB1 +-->--+ RB2 +-->--+ B2 + | ESb |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 5: Example Frame Path Figure 5: Example Frame Path
TRILL can make no change to the actions at any reaction points in ESa TRILL can make no change to the actions at any reaction points in ESa
or any congestion points at the output queues of B1, B2, or B3, since or any congestion points at the output queues of B1, B2, or B3, since
they are not RBridges. Any CNM generated at B2 will be in response to they are not TRILL switches. Any CNM generated at B2 will be in
a TRILL frame and will need to be corrected by the previous hop response to a TRILL frame and will need to be corrected by the
RBridge. The situation at the output queue of RB3 is actually the previous hop TRILL switch. The situation at the output queue of RB3
same as B3 since, as egress, RB3 will have decapsulated any traffic is actually the same as B3 since, as egress, RB3 will have
for ESb before it tries to insert it in an output queue. Thus the decapsulated any traffic for ESb before it tries to insert it in an
frame RB3 is enqueuing will be a native frame, a congestion point at output queue. Thus the frame RB3 is enqueuing will be a native frame,
the RB3 output can act, for such a frame, exactly as an IEEE 802.1 a congestion point at the RB3 output can act, for such a frame,
bridge congestion point, and any CNM generated in the RB3 output from exactly as an IEEE 802.1 congestion point, and any CNM generated in
that native frame will be treated as if it was received by the RB3 the RB3 output from that native frame will be treated as if it was
port. received by the RB3 port.
A CNM created at the RB1 or RB2 output queue is straightforward. A CNM created at the RB1 or RB2 output queue is straightforward.
Assume the CNM is created in response to TRILL Data frame 1 (TDF1) Assume the CNM is created in response to TRILL Data frame 1 (TDF1)
and the TDF1 encapsulates native frame 1 (NF1). The CNM would be and the TDF1 encapsulates native frame 1 (NF1). The CNM would be
created as a TRILL encapsulated CNM with the ingress RBridge of NF1 created as a TRILL encapsulated CNM with the ingress TRILL switch of
as its egress. The Inner.MacDA would be ESa. The Inner.MacSA would be NF1 as its egress. The Inner.MacDA would be ESa. The Inner.MacSA
the MAC address of the port on which the TRILL encapsulated CNM was would be the MAC address of the port on which the TRILL encapsulated
initially sent, that is, the same as the Outer.MacSA. The CNM was initially sent, that is, the same as the Outer.MacSA. The
encapsulated CNM itself would be filled in as if in response to NF1, encapsulated CNM itself would be filled in as if in response to NF1,
not TDF1. not TDF1.
Similarly, a CNM created at B3 would have ESa as its destination Similarly, a CNM created at B3 would have ESa as its destination
address and would be TRILL encapsulated when it arrived at RB3 as RB3 address and would be TRILL encapsulated when it arrived at RB3 as RB3
would be its ingress RBridge. would be its ingress TRILL switch.
5.4.1 RBridge Ingress Details 5.4.1 TRILL Switch Ingress Details
This section specifies special actions for CN at an RBridge input This section specifies special actions for CN at a TRILL switch input
port receiving a native frame, that is, the RBridge ingress function. port receiving a native frame, that is, the TRILL switch ingress
The usual 802.1Q processing on the priority of the input TRILL data function. The usual processing on the priority of the input TRILL
frame, modified as described in Section 5.1, is done. Special actions data frame, modified as described in Section 5.1, is done. Special
are required only when the native frame received is a CNM. actions are required only when the native frame received is a CNM.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
The ingress process at an RBridge, say RB2, supporting CN MUST detect The ingress process at a TRILL switch, say RB2, supporting CN MUST
the case of a native CNM created by a bridge in response to a TRILL detect the case of a native CNM created by a bridge in response to a
frame, say by B2 in Figure 4, and transform or discard it as TRILL frame, say by B2 in Figure 4, and transform or discard it as
described below. If such a CNM was generated in response to a TRILL described below. If such a CNM was generated in response to a TRILL
control (IS-IS) frame, it is discarded. No other changes are needed control (IS-IS) frame, it is discarded. No other changes are needed
in the RBridge ingress process. in the TRILL switch ingress process.
A native CNM requiring special actions is easily recognized on A native CNM requiring special actions is easily recognized on
ingress as it's MAC destination address will be the RBridge and it ingress as it's MAC destination address will be the TRILL switch and
will have the CNM Ethertype. (A CNM not addressed to the RBridge must it will have the CNM Ethertype. (A CNM not addressed to the TRILL
have been generated in response to an unencapsulated native frame, switch must have been generated in response to an unencapsulated
for example at B3 in the diagram above, and can be encapsulated by native frame, for example at B3 in the diagram above, and can be
its Ingress RBridge and generally forwarded by transit Rbridges in encapsulated by its Ingress TRILL switch and generally forwarded by
the same way as other native frame.) transit TRILL switches in the same way as other native frame.)
Such a native CNM resulting from a TRILL data frame at B2 has the Such a native CNM resulting from a TRILL data frame at B2 has the
contents generally shown in Figure 6 and listed further below. contents generally shown in Figure 6 and listed further below.
+-----------------------------------------------+ +-----------------------------------------------+
| Ethernet Header (possibly including VLAN Tag} | | Ethernet Header (possibly including VLAN Tag} |
+-----------------------------------------------+ +-----------------------------------------------+
| CNtag | | CNtag |
+-----------------------------------------------+ +-----------------------------------------------+
| CNM Ethertype and Fixed Fields | | CNM Ethertype and Fixed Fields |
skipping to change at page 17, line 5 skipping to change at page 18, line 5
1 + Outer.MacDA, MAC address of RB2 1 + Outer.MacDA, MAC address of RB2
2 + Outer.MacSA, MAC address of port on which B2, the bridge 2 + Outer.MacSA, MAC address of port on which B2, the bridge
generating this CNM, sent the CNM generating this CNM, sent the CNM
3 + Outer.VLAN tag for the designated VLAN on the RB2 to RB3 link 3 + Outer.VLAN tag for the designated VLAN on the RB2 to RB3 link
with the priority configured at B2 for CNMs (default priority 6) with the priority configured at B2 for CNMs (default priority 6)
4 + CNtag (CNtag Ethertype 0x22E9 followed by Flow ID of zero) 4 + CNtag (CNtag Ethertype 0x22E9 followed by Flow ID of zero)
+ CNM + CNM
5 o CNM Ethertype 0x22E7 5 o CNM Ethertype 0x22E7
6 o CNM version information, quantized congestion feedback 6 o CNM version information, quantized congestion feedback
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
information, and an 8 byte opaque ID of the congestion information, and an 8 byte opaque ID of the congestion
point generating the CNM point generating the CNM
7 o The priority of the TRILL encapsulated frame causing the 7 o The priority of the TRILL encapsulated frame causing the
CNM CNM
8 o The destination MAC address of the TRILL encapsulation 8 o The destination MAC address of the TRILL encapsulation
frame causing the CNM, RB3 in this case frame causing the CNM, RB3 in this case
9 o The number of bytes included below from the beginning of 9 o The number of bytes included below from the beginning of
the body of the TRILL encapsulation frame causing the CNM the body of the TRILL encapsulation frame causing the CNM
+ Initial bytes of body of TRILL encapsulation Data frame causing + Initial bytes of body of TRILL encapsulation Data frame causing
skipping to change at page 17, line 30 skipping to change at page 18, line 30
12 - Egress nickname, RB3 in this case 12 - Egress nickname, RB3 in this case
13 - Ingress nickname, RB1 in this case 13 - Ingress nickname, RB1 in this case
14 - Options, if any 14 - Options, if any
15 o Inner.MacDA, MAC address of ESb 15 o Inner.MacDA, MAC address of ESb
16 o Inner.MacSA, MAC address of ESa 16 o Inner.MacSA, MAC address of ESa
17 o Inner.VLAN tag of the TRILL encapsulated frame causing the 17 o Inner.VLAN tag of the TRILL encapsulated frame causing the
CNM CNM
18 o Optional CNtag 18 o Optional CNtag
19 o Encapsulated native frame body 19 o Encapsulated native frame body
The ingressing RBridge RB2 transforms this CNM above into the The ingressing TRILL switch RB2 transforms this CNM above into the
following TRILL encapsulated CNM. following TRILL encapsulated CNM.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
+ Outer.MacDA, MAC address of next hop RBridge (RB1) toward + Outer.MacDA, MAC address of next hop RBridge (RB1) toward
originating end station originating end station
+ Outer.MacSA, MAC address of RB2 port on which this TRILL + Outer.MacSA, MAC address of RB2 port on which this TRILL
encapsulated CNM frame is to be sent encapsulated CNM frame is to be sent
+ Outer.VLAN tag for the designated VLAN on the RB2 to RB1 link + Outer.VLAN tag for the designated VLAN on the RB2 to RB1 link
with priority copied from incoming Outer.VLAN, field #3 above with priority copied from incoming Outer.VLAN, field #3 above
+ TRILL Header to get the CNM to the right end station + TRILL Header to get the CNM to the right end station
o TRILL Ethertype 0x22F3 o TRILL Ethertype 0x22F3
o Flags, hop count, options length o Flags, hop count, options length
skipping to change at page 18, line 47 skipping to change at page 19, line 47
the body of the frame whose encapsulated form caused the the body of the frame whose encapsulated form caused the
CNM. This will be 24 smaller (but not less than zero) than CNM. This will be 24 smaller (but not less than zero) than
the same field (#9) in the CNM tag received due to dropping the same field (#9) in the CNM tag received due to dropping
the TRILL Header (8 bytes), MAC addresses (12 bytes), and the TRILL Header (8 bytes), MAC addresses (12 bytes), and
Inner.VLAN (4 bytes). Inner.VLAN (4 bytes).
+ Initial bytes of the body of the frame whose encapsulated form + Initial bytes of the body of the frame whose encapsulated form
caused the CNM, field #19 above caused the CNM, field #19 above
Because of the reduction in the number of bytes of the body of the Because of the reduction in the number of bytes of the body of the
frame that would have caused the CNM if it weren't TRILL frame that would have caused the CNM if it weren't TRILL
encapsulated, it is RECOMMENDED that bridges and RBridges encapsulated, it is RECOMMENDED that bridges and TRILL switches
implementing Congestion Notification in a RBridge campus be implementing Congestion Notification in a TRILL campus be configured
configured to include the maximum (64) number of bytes when to include the maximum (64) number of bytes when generating a CNM.
generating a CNM.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support 5.4.2 Transit TRILL Switch Details
5.4.2 Transit RBridge Details The subsections below describe transit TRILL switch support of
Congestion Notification at input and output ports. As this is a TRILL
The subsections below describe transit RBridge support of Congestion INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
Notification at input and output ports. As this is considering an
RBridge in its transit role, only the handling of TRILL Data frames switch in its transit role, only the handling of TRILL Data frames is
is discussed. If the RBridge is receiving a native frame, it will be discussed. If the TRILL switch is receiving a native frame, it will
an ingress as described in Section 5.4.2 and if it is sending a be an ingress as described in Section 5.4.2 and if it is sending a
native frame, it will be an egress as described in Section 5.4.3. native frame, it will be an egress as described in Section 5.4.3.
However, this section does apply to the output of an encapsulated However, this section does apply to the output of an encapsulated
frame that was ingressed at an RBridge and to the input, in TRILL frame that was ingressed at a TRILL switch and to the input, in TRILL
encapsulated form, of a frame to be egressed at the RBridge. encapsulated form, of a frame to be egressed at a TRILL switch.
5.4.2.1 Transit RBridge Input Port 5.4.2.1 Transit TRILL Switch Input Port
The usual 802.1Q processing on the priority of the input TRILL data The usual 802.1Q processing on the priority of the input TRILL data
frame, modified as described in Section 5.1, is done. frame, modified as described in Section 5.1, is done.
5.4.2.2 Transit RBridge Output Port 5.4.2.2 Transit TRILL Switch Output Port
As discussed in Section 5.1, a CNtag is stripped under some As discussed in Section 5.1, a CNtag is stripped under some
circumstances; however, such a CNtag will appear as part of the circumstances; however, such a CNtag will appear as part of the
encapsulated frame, not on the outside of the TRILL data frame, so encapsulated frame, not on the outside of the TRILL data frame, so
the CNtag is stripped from deeper in the frame. When there is a the CNtag is stripped from deeper in the frame. When there is a
Congestion Point enabled at an RBridge output queue a CNM is not Congestion Point enabled at a TRILL switch output queue, a CNM is not
generated as the result of trying to queue a TRILL control (IS-IS) generated as the result of trying to queue a TRILL control (IS-IS)
frame for output at an RBridge. A TRILL encapsulated CNM is generated frame for output at a TRILL switch port. A TRILL encapsulated CNM is
in response to a TRILL Data frame composed as below, when to do so is generated in response to a TRILL Data frame composed as below, when
specified by [802.1Q]. The TRILL Data frame causing the CNM is to do so is specified by [802.1Q]. The TRILL Data frame causing the
referred to as TDF1 and its encapsulated native frame as NF1. CNM is referred to as TDF1 and its encapsulated native frame as NF1.
+ Outer.MacDA - MAC address of the next hop RBridge towards the + Outer.MacDA - MAC address of the next hop RBridge towards the
egress nickname used in the TRILL Header (see below) egress nickname used in the TRILL Header (see below)
+ Outer.MacSA - MAC address of the output port on which the TRILL + Outer.MacSA - MAC address of the output port on which the TRILL
encapsulated CNM is to be sent encapsulated CNM is to be sent
+ Outer.VLAN - Designated VLAN of the link on which the TRILL + Outer.VLAN - Designated VLAN of the link on which the TRILL
encapsulated CNM is to be sent encapsulated CNM is to be sent
+ TRILL Header + TRILL Header
o TRILL Ethertype 0x22F3 o TRILL Ethertype 0x22F3
o Flags, hop count, options length o Flags, hop count, options length
o Egress nickname, from ingress nickname in TDF1 o Egress nickname, from ingress nickname in TDF1
o Ingress nickname, a nickname of the RBridge generating the o Ingress nickname, a nickname of the RBridge generating the
CNM CNM
o Options, if any o Options, if any
+ Inner.MacDA - set to the Inner.MacSA of TDF1, that is, the + Inner.MacDA - set to the Inner.MacSA of TDF1, that is, the
source MAC address of NF1 source MAC address of NF1
+ Inner.MacSA - same as Outer.MacSA of TDF1 + Inner.MacSA - same as Outer.MacSA of TDF1
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support
+ Inner.VLAN - same as the Inner.VLAN of TDF1, that is, the VLAN + Inner.VLAN - same as the Inner.VLAN of TDF1, that is, the VLAN
tag of NF1 tag of NF1
+ CNtag - with flow ID from the CNtag of NF1 or zero if NF1 did + CNtag - with flow ID from the CNtag of NF1 or zero if NF1 did
not have a CNtag not have a CNtag
INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
+ CNM - message generated for NF1 + CNM - message generated for NF1
5.4.3 RBridge Egress Details 5.4.3 TRILL Switch Egress Details
After decapsulation, processing of the decapsulated native frame is After decapsulation, processing of the decapsulated native frame is
the same as at an [802.1Q] bridge output port. As discussed in the same as at any CN equipped output port. As discussed in Section
Section 5.1, any CNtag present is stripped under some circumstances. 5.1, any CNtag present is stripped under some circumstances. If the
If the output queue is congested, then a native CNM may be generated output queue is congested, then a native CNM may be generated in
in response to the decapsulated native frame. This native CNM will response to the decapsulated native frame. This native CNM will then
then be treated as if it had been received on the port. be treated as if it had been received on the port.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
6. Management Considerations 6. Management Considerations
---TBD--- ---TBD---
7. IANA Considerations 7. IANA Considerations
This document requires no IANA actions. This section should be This document requires no IANA actions. This section should be
deleted by the RFC Editor before publication. deleted by the RFC Editor before publication.
8. Security Considerations 8. Security Considerations
See [RFC6325] for general RBridge Security Considerations. See [RFC6325] for general RBridge Security Considerations.
---more TBD--- ---more TBD---
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
9. References 9. References
Normative and informational references for this document are given Normative and informational references for this document are given
below. below.
9.1 Normative References 9.1 Normative References
[802.1AB] - IEEE, "IEEE Standard for Local and metropolitan area [802.1AB] - IEEE, "IEEE Standard for Local and metropolitan area
networks / Station and Media Access Control Connectivity networks / Station and Media Access Control Connectivity
skipping to change at page 23, line 5 skipping to change at page 24, line 5
Priority-based Flow Control", IEEE Std 802.1Qbb-2011, June Priority-based Flow Control", IEEE Std 802.1Qbb-2011, June
2011. 2011.
[802.3] IEEE, "IEEE Standard for Information technology / [802.3] IEEE, "IEEE Standard for Information technology /
Telecommunications and information exchange between systems / Telecommunications and information exchange between systems /
Local and metropolitan area networks / Specific requirements Local and metropolitan area networks / Specific requirements
Part 3: Carrier sense multiple access with collision detection Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications", (CSMA/CD) access method and physical layer specifications",
IEEE 802.3-2008, 26 December 2008. IEEE 802.3-2008, 26 December 2008.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
[802.3bd] - IEEE 802.3, "Draft Standard for Information technology / [802.3bd] - IEEE 802.3, "Draft Standard for Information technology /
Telecommunications and information exchange between systems / Telecommunications and information exchange between systems /
Local and Metropolitan Area Networks / Specific requirements Local and Metropolitan Area Networks / Specific requirements
Part 3: Carrier Sense Multiple Access with Collision Detection Part 3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications / (CSMA/CD) Access Method and Physical Layer Specifications /
Amendment: MAC Control Frame for Priority-based Flow Control", Amendment: MAC Control Frame for Priority-based Flow Control",
IEEE Std 802.3bd-2011, June 2011. IEEE Std 802.3bd-2011, June 2011.
[FCoE] - http://fcoe.com/ [FCoE] - http://fcoe.com/
[RFC793] - Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC793] - Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981 793, September 1981
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
Version History Version History
Changes from -00 to -01. Changes from -00 to -01.
Minor editorial changes. Minor editorial changes.
Changes from -01 to -02 Changes from -01 to -02
1. Update for IETF draft which is now an RFC. 1. Update for IETF draft which is now an RFC.
2. Update for all referenced 802.1 drafts that have become 802.1 2. Update for all referenced 802.1 drafts that have become 802.1
standards including the rolling of 802.1Qau into 802.1Q-2011. standards including the rolling of 802.1Qau into 802.1Q-2011.
3. Editorial changes. 3. Editorial changes.
Changs from -02 to -03 Changes from -02 to -03
Updates Author Info, version, and date. Updates Author Info, version, and date.
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support Changes from -03 to -04
Authors' Addresses 1. Update to take into account the incorporation of IEEE 802.1Qau
into 802.1Q and that adoption of the 802.1Qaz and 802.1Qau
standards.
Donald Eastlake 3rd 2. Change most occurrences of RBridge to TRILL or TRILL switch.
Huawei R&D USA
155 Beaver Street
Milford, MA 01757 USA
Tel: +1-508-333-2270 3. Minor editorial changes.
Email: d3e3e3@gmail.com
Manoj Wadekar INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
QLogic Corporation
26650 Aliso Viejo Pkwy
Aliso Viejo, CA 92656 USA
Tel: +1-949-389-6000 Authors' Addresses
Email: manoj.wadekar@qlogic.com
Anoop Ghanwani Donald Eastlake 3rd
Dell Huawei R&D USA
350 Holger Way 155 Beaver Street
San Jose, CA 95134 USA Milford, MA 01757 USA
Phone: +1-408-571-3500 Tel: +1-508-333-2270
Email: anoop@alumni.duke.edu Email: d3e3e3@gmail.com
Puneet Agarwal Manoj Wadekar
Broadcom QLogic Corporation
26650 Aliso Viejo Pkwy
Aliso Viejo, CA 92656 USA
Phone: +1-949-926-5000 Tel: +1-949-389-6000
Email: pagarwal@broadcom.com Email: manoj.wadekar@qlogic.com
Tal Mizrahi Anoop Ghanwani
Marvell Dell
6 Hamada St. 350 Holger Way
Yokneam, 20692 Israel San Jose, CA 95134 USA
Email: talmi@marvell.com Phone: +1-408-571-3500
Email: anoop@alumni.duke.edu
INTERNET-DRAFT RBridges: Qbb, Qaz, & Qau Support Puneet Agarwal
Broadcom
Phone: +1-949-926-5000
Email: pagarwal@broadcom.com
Tal Mizrahi
Marvell
6 Hamada Street
Yokneam, 20692 Israel
Email: talmi@marvell.com
INTERNET-DRAFT TRILL: Qbb, Qaz, and CN Support
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
document authors. All rights reserved. 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 Provisions
Provisions Relating to IETF Documents Relating to IETF Documents (http://trustee.ietf.org/license-info) in
(http://trustee.ietf.org/license-info) in effect on the date of effect on the date of publication of this document. Please review these
publication of this document. Please review these documents documents carefully, as they describe your rights and restrictions with
carefully, as they describe your rights and restrictions with respect respect to this document. Code Components extracted from this document
to this document. Code Components extracted from this document must must include Simplified BSD License text as described in Section 4.e of
include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. The definitive version of an
described in the Simplified BSD License. The definitive version of IETF Document is that published by, or under the auspices of, the IETF.
an IETF Document is that published by, or under the auspices of, the Versions of IETF Documents that are published by third parties,
IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be
including those that are translated into other languages, should not considered to be definitive versions of IETF Documents. The definitive
be considered to be definitive versions of IETF Documents. The version of these Legal Provisions is that published by, or under the
definitive version of these Legal Provisions is that published by, or auspices of, the IETF. Versions of these Legal Provisions that are
under the auspices of, the IETF. Versions of these Legal Provisions published by third parties, including those that are translated into
that are published by third parties, including those that are other languages, should not be considered to be definitive versions of
translated into other languages, should not be considered to be these Legal Provisions. For the avoidance of doubt, each Contributor to
definitive versions of these Legal Provisions. For the avoidance of the IETF Standards Process licenses each Contribution that he or she
doubt, each Contributor to the IETF Standards Process licenses each makes as part of the IETF Standards Process to the IETF Trust pursuant
Contribution that he or she makes as part of the IETF Standards to the provisions of RFC 5378. No language to the contrary, or terms,
Process to the IETF Trust pursuant to the provisions of RFC 5378. No conditions or rights that differ from or are inconsistent with the
language to the contrary, or terms, conditions or rights that differ rights and licenses granted under RFC 5378, shall have any effect and
from or are inconsistent with the rights and licenses granted under shall be null and void, whether published or posted by such Contributor,
RFC 5378, shall have any effect and shall be null and void, whether or included with or in such Contribution.
published or posted by such Contributor, or included with or in such
Contribution.
 End of changes. 98 change blocks. 
232 lines changed or deleted 246 lines changed or added

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