In-Network Congestion Notification

In , the real-time Tactical Traffic Engineering (TTE) mechanism is proposed, which can avert congestion on a real-time basis especially when unforeseen and/or dynamic events take place. A network node will monitor the link status and trigger the path switch of some traffic, so that the network load would be more balanced. TTE is a local policy on the nodes with links protected by TTE. This document proposes a mechanism that TTE only is enabled on the PE nodes as a special case of TTE. In this case, P nodes will not be configured with the TTE backup policy. Therefore, if the links on the P node is about to become congested, no backup path could be enabled locally. So, we propose that the P node could notify the PE node about its congestion, and the PE node can trigger the TTE backup path to avoid the potential congestion on the P node. If the links on the PE node is about to become congested, it can enable the local backup path just as described in the TTE mechanism.

To notify the PE node, P nodes need some notification means. In this document, it is suggested that we can use some bits in the overlay IP header, for example, the ECN part . The ECN in this document is slightly different from the original one as it only works within the provider network, in which only the PE nodes and the P nodes will see it in the overlay IP header. The meanings of the two bits are also slightly different from the original ECN. The meanings of "00", "10", and "11" have not be changed. The "00" means the traffic is Not-ECT; the "10" means the traffic is ECN-Capable Transport (ECT); the "11" means Congestion Experienced (CE). Originally, the "01" means ECT(1), which is similar to the "10", but in this document, it is used as a response from the reverse path, which can notify the Ingress PE in the provider network that the congestion appears in the related forward path as shown in Figure 1. In other words, when receiving a packet with ECN part marked as "01" from the reverse path, the Ingress PE can be aware of the congestion of the related forward path. Figure 1 shows the topology for the notifying procedure. We have one Ingress PE (Provider Edge), one Egress PE, and one or more P nodes. There are two tunnels between the Ingress and the Egress, i.e., the tunnel1 and the tunnel2. The tunnel1 is the forward tunnel or described as the forward path, and the tunnel2 is the reverse tunnel or described as the reverse path. The P1 node is one forwarding node along the tunnel1.

| P1 Node |------------->| Egress | | PE |<------------| P |<-------------| PE | +-----------+ tunnel2 +-----------+ tunnel2 +-----------+ overlayIP if congested Response: = ECN part ECN part with ECN part as 10 changed to 11 marked as 01 underlayIP = ]]> A general procedure of the notifying method is described as follows: The Ingress PE receives a packet and encapsulates it with an overlay IP header, with the <SA, DA> pair as <IngressIP, EgressIP>. The ECN part of the overlay IP header is marked as "10". If the P node, i.e., the P1 Node, is about to be congested or has been congested, it can change the ECN part of the packet from "10" to "11", and forward the packet to the Egress PE. If the Egress PE receives a packet with the ECN part marked as "11", the Egress will send a response to the Ingress PE. One of the means is to pre-configured a reverse tunnel of the incoming packet's tunnel to bear the response. In the mechanism of this document, the Egress PE needs to send a packet to the Ingress over the reverse tunnel, in which packet the ECN part is marked as "01". The Ingress PE receives the packet with the ECN part of the overlay IP header marked as "01" over the reverse tunnel, and accordingly triggers the TTE operation for the flow along the forward path. The relationship of the forward direction tunnel and the reverse tunnel also needs to be pre-configured. Therefore, only the PE nodes in the provider network need to deploy the TTE mechanism, and the P nodes only need to mark the CE in the overlay IP header.