Congestion Notification (CN) Configuration (S-, 7100-Series)

Note

Note

CN is supported on the S-Series S140 and S180 modules and the 7100-Series platform. On non-supported S-Series modules, the Congestion Notification Domain Defense can be configured for either edge or disabled only. When edge configured, flows ingressing non-supported S-Series modules are remapped on ingress. Flows ingressing a supported S-Series module and egressing a non-supported S-Series module, on the same chassis, generate Congestion Notification Messages because congestion notification logic is performed on the ingress module.

Congestion Notification (CN), as defined in IEEE 802.1Q-2011 allows a device to detect congestion at a switch congestion point (egress transmit queue) and transmit a Congestion Notification Message (CNM) PDU back to the reaction point (flow source). The reaction point backs off the traffic rate to alleviate the congestion. Congestion notification supports long lived data flows in a network with delay due to limited bandwidth. It allows for applications that are latency-or-loss-sensitive to run over Ethernet technologies experiencing egress transmit queue congestion.

As the use of Ethernet technologies in the data center expands, prevention of packet loss by some applications becomes more critical. Congestion notification was created to:

For congestion notification to work, it must be supported at all egress queues for each switch that is in the path from the source to the destination. Congestion notification is applied to an egress queue by configuring an 802.1p value as a Congestion Notification Priority Value (CNPV) that is mapped to the transmit queue using CoS. This collection of egress queues configured for congestion notification make up the Congestion Notification Domain (CND).

Each transmit queue that has been configured for congestion notification is monitored to detect congestion. When congestion is detected, a CNM PDU is generated at the congestion point and sent back to the source with the details of the queue and flow that triggered the message. The source can then use this information to back off the transmission rate for the application that triggered the CNM PDU.

SNMP supports the congestion notification IEEE Standard MIB: IEEE8021-CN-MIB

Congestion Notification Overview provides a Congestion Notification overview.

Click to expand in new window
Congestion Notification Overview
Graphics/Congestion_Notification_Overview.png
1 Reaction Point (flow source) 3 Switch B 5 Flow Destination
2 Switch A 4 Congestion Point (Tx queue)    

Congestion Notification Overview identifies the congestion notification reaction point (callout 1). A reaction point is the source of a congestion controlled flow. A congestion controlled flow consists of frames, all with the same CNPV, and all assigned to a single transmit flow queue in the originating end station. A CNPV is an 802.1p priority mapped to a congestion notification egress queue of each device in the flow.

The reaction point is:

The reaction point is connected to a destination device (callout 5) by traversing switches A and B (callouts 2 and 3). All egress ports on switches in the path between the reaction point and the destination are configured as congestion points (callouts 4). All congestion points are configured for a CNPV. In our example, CNPV 6 is mapped to transmit queue 6 for all congestion points.

Up to either four or seven 802.1p priorities, depending upon the S-Series chassis, and up to seven 802.1p priorities on the 7100-Series device that are mapped to a port‘s transmit queues can be configured as CNPVs. At least one 802.1p priority on a port must be a non-congestion aware priority. Any non-congestion aware priority can be used as a congestion notification alternate priority. When a packet that does not belong to a congestion controlled flow has the same priority as a CNPV configured on a congestion notification domain edge ingress port, it must be remapped to an alternate priority to defend against a false triggering of a congestion notification by a non-congestion controlled flow.

In Congestion Notification Overview, the reaction point tags the traffic with the CNPV 6 mapped to queue 6 and transmits it to the destination. The congestion point at switch B identifies congestion and creates a CNM PDU packet that is sent back to the reaction point. When the reaction point receives the CNM PDU, it uses the information contained in the CNM PDU to back off the reaction point transmission rate for the queue associated with the congestion controlled flow that triggered the CNM PDU.

A CN-TAG helps the source identify the flow. The CN-TAG is optional for packets transmitted by the source and, if present, may contain a flow-ID. All CNM PDU packets sent from the congestion point back to the reaction point contain a CN-TAG. The transmit queue that detects the congestion will use the flow-ID from the CN-TAG, if it is present, when generating the CNM PDU back to the source. If the congestion controlled flow does not contain a CN-TAG, congestion notification sets the flow-ID to 0.

The traffic monitored by congestion notification must be isolated to its own CNPV. Traffic that does not support congestion notification must not be placed on a CNPV mapped queue. The source of this non-congestion aware priority traffic would not understand the CNM PDU being transmitted back from the congestion point, defeating the purpose of congestion notification. LLDP may be used to auto-determine the port‘s capability. The information that LLDP provides ensures that non-supported flows are not placed in the congestion aware traffic classes mapped to a CNPV.

Congestion notification advertises its support and state via a TLV type 127 defined in LLDP. If a non-congestion aware priority frame ingresses a congestion notification domain edge port, with the same priority as a configured CNPV on that port, congestion notification will use an alternate priority value to remap the packets to a non-CNPV queue. This alternate priority is configurable for each CNPV.

Using LLDP and alternate priority settings, devices can be configured to remap a priority for all ports away from a congestion notification configured queue and rely upon LLDP to dynamically determine which ports support congestion notification. The protection of the congestion notification domain from non-CN capable port traffic is referred to as congestion notification domain defense. See Congestion Notification Domain Defense for a detailed discussion of domain defense.