| Internet-Draft | In-Network Congestion Notification | October 2024 |
| Du | Expires 24 April 2025 | [Page] |
This document describes an in-network congestion notification mechanism for the provider network, to enable the real-time Tactical Traffic Engineering on the provider edge node.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In [I-D.li-rtgwg-tte], 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 [RFC3168].¶
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.¶
+-----------+ tunnel1 +-----------+ tunnel1 +-----------+ | Ingress |------------>| P1 Node |------------->| Egress | | PE |<------------| P |<-------------| PE | +-----------+ tunnel2 +-----------+ tunnel2 +-----------+ overlayIP<SA,DA> if congested Response: =<IngressIP,EgressIP> ECN part ECN part with ECN part as 10 changed to 11 marked as 01 underlayIP<SA,DA> =<clientIP,serverIP>
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.¶
TBD.¶
TBD.¶