Congestion Notification Domain Defense

A congestion notification domain defense provides a means of defending a congestion notification domain against incoming frames from outside of the domain. Domain defense assumes:

• That every bridge along a path between two congestion aware end-stations, using a particular CNPV, is properly configured for congestion notification and therefore belongs to the congestion notification domain
• That every bridge ensures that frames not configured for a CNPV use different queues than the CNPV configured queues for those devices

Domain defense protects the boundaries of a congestion notification domain by preventing frames not in a congestion controlled flow from entering congestion point controlled queues. Domain defense takes advantage of the ability to change the priority value based upon whether or not the port‘s neighbor is also configured with the same CNPV. If a frame with the same priority as the CNPV is not in the congestion controlled flow, the frame priority is changed to the configured alternate priority for that CNPV.

A default domain defense mode is configured at each congestion point port.

There are four possible domain defense modes depending upon whether the CNPV is configured for the congestion point, whether a given congestion point knows the congestion notification state of its neighbor, and where the congestion point port is located in the congestion notification domain:

• Disabled – The domain defense mode state on a port for which congestion notification is disabled. The priority is not a CNPV. Congestion notification does not control priority remapping of input frames on this port. CN-TAGs are neither added by an end station nor removed by a bridge. Disabled mode is only set administratively.
• Edge – The domain defense mode configured on a congestion point port that resides at the edge of the congestion notification domain. All frames ingressing the edge of a congestion notification domain by definition do not belong to a congestion controlled flow for this domain. On this port for the given CNPV, congestion notification controls priority remapping. The input frame priority parameters are remapped to an alternate (non-CNPV) value. CN-TAGs are not added by an end station, and are removed from frames before being output by a bridge. This mode is optional for an end station.

  The end result is that ports configured for edge domain defense protect the congestion notification domain by reassigning the 802.1p priorities of non-CNPV ingressing frames to alternate priorities when they are the same as an edge port CNPV.

  When configured for LLDP dynamic congestion notification, a port will be auto configured as edge when the neighbor is not configured for this CNPV.

• Interior – The domain defense mode configured on a congestion point port that resides within the congestion notification domain between the flow‘s source reaction point and the destination end-station. This port does not yet know whether its neighbor is able to receive a CN-TAG in frames sent to it. On this port for the given CNPV, the input frame priority parameters are not remapped. CN-TAGs are not added by an end station, and are removed from frames before being output by a bridge.

  The Interior defense mode is a transition state within an LLDP dynamic congestion notification configuration. Once the port completes congestion notification negotiation with its neighbor, the defense mode transitions to interior-ready.

• Interior-Ready – The domain defense mode configured on an interior congestion port that knows its neighbor is able to receive a CN-TAG in frames sent to it. On this port for the given CNPV, the input frame priority parameters are not remapped. CN-TAGs can be added by an end station, and are not removed from frames by a bridge.
  

  Note

  Manually configuring congestion notification domain defense on S-Series bonding ports has no affect. Both hardware and software bonding ports are automatically configured for interior-ready. 7100-Series Hardware bonding ports must be manually configured for congestion notification domain defense to interior-ready.

Congestion Notification Domain Defense Mode Overview provides a dynamic domain defense mode configuration overview.

Congestion Notification Domain Defense Mode Overview

In Congestion Notification Domain Defense Mode Overview, there are two packet flow sources. One of the flow sources is a reaction point configured for CNPV 6 and mapped to queue 6 (Server 1). The second flow source is not configured for congestion notification (Server 2).

There are two paths between the two packet flow sources and the destination. The first path is from the two flow sources to the destination through switches A and B. The second path is from the flow sources to the destination through switches A and C, an IP network cloud, and switch B.

There are three flow discussions that can be derived from Congestion Notification Domain Defense Mode Overview.

• Server 2 non-congestion notification flow – The 802.1p priority 6 frame sourced at Server 2 is a non-CN frame because its source is not a reaction point within a congestion notification domain. As the frame enters port 2 Switch A, because port 2 is a domain edge port, and the frame priority agrees with CNPV for this domain, the frame priority (6) is changed to the alternate priority value (priority 4). The frame transits the remainder of the path to the destination incapable of triggering congestion notification.
• Server 1 congestion notification flow (Switch A/Switch B path) – The CNPV 6 frame sourced at Server 1 (reaction point) is a congestion notification frame. As the frame transits to the destination, both ingress ports are configured for the interior-ready defense mode because they have successfully negotiated CNPV 6 with their peers. The CNPV value is not changed to an alternate priority when ingressing interior-ready ports. The frame exits the congestion notification domain for CNPV 6 at port 2, Switch B, and arrives at the destination with its priority unchanged.

  Should congestion occur at port 4 of Switch A or port 2 of Switch B, a CNM PDU will be sent back to the reaction point which will back off the flow transmit rate so long as it receives CNM PDUs from the congestion point.

• Server 1 congestion notification flow (IP Network path) – The CNPV 6 frame sourced at Server 1 (reaction point) is a congestion notification frame. As the frame transits to the destination, Switch A and Switch C ingress ports are configured for the interior-ready defense mode because they have successfully negotiated CNPV 6 with their peers. The frame leaves the congestion notification domain at port 2, Switch C. The CN-Tag (if present) is stripped and the priority is unchanged. Assuming there are no policy or other reasons why the priority would be changed in the IP Network cloud, the frame arrives at port 3, Switch B with a priority of 6. Because port 3, Switch B is configured for edge defense and the frame priority is the same as the congestion notification domain CNPV 6, the frame priority is changed to the alternate priority 4 no longer capable of triggering congestion notification within this domain. The frame transits to the destination with a priority of 4.

  Should congestion occur at port 3, Switch A or port 2, Switch C, a CNM PDU will be sent back to the reaction point which will back off the flow transmit rate so long as it receives CNM PDUs from the congestion point. Should congestion occur at port 2, Switch B, congestion notification is not triggered because the priority is now alternate priority 4.

Port defaults for domain defense are determined by priority choice. See Priority Choice for details.

Defaults for domain defense can be administratively configured by priority on a port or for all priorities on a port. A default domain defense can be globally configured per CNPV for all ports using the set dcb cn priority defense command. A default domain defense can be set on a port basis for all CNPVs on that port using the set dcb cn port-priority defense command.