Internet-Draft In-Network Congestion Notification October 2024
Du Expires 24 April 2025 [Page]
Workgroup:
RTGWG Working Group
Internet-Draft:
draft-du-rtgwg-in-network-congestion-notification-00
Published:
Intended Status:
Informational
Expires:
Author:
Z. Du
China Mobile

In-Network Congestion Notification

Abstract

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.

Requirements Language

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].

Status of This Memo

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.

Table of Contents

1. Introduction

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.

2. Notifying Method Between PE and P Nodes

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>

Figure 1: Topology for Congestion Notifying Procedure

A general procedure of the notifying method is described as follows:

  1. 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".

  2. 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.

  3. 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".

  4. 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.

3. IANA Considerations

TBD.

4. Security Considerations

TBD.

5. Acknowledgements

TBD.

6. References

6.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

6.2. Informative References

[I-D.li-rtgwg-tte]
Barth, C., Li, T., Smith, A., Wen, B., and L. Jalil, "Tactical Traffic Engineering (TTE)", Work in Progress, Internet-Draft, draft-li-rtgwg-tte-01, , <https://datatracker.ietf.org/doc/html/draft-li-rtgwg-tte-01>.
[RFC3168]
Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, , <https://www.rfc-editor.org/info/rfc3168>.

Author's Address

Zongpeng Du
China Mobile
No.32 XuanWuMen West Street
Beijing
100053
China