In-Network Congestion Notification
draft-du-rtgwg-in-network-congestion-notification-00

RTGWG Working Group                                                Z. Du
Internet-Draft                                              China Mobile
Intended status: Informational                           21 October 2024
Expires: 24 April 2025

                   In-Network Congestion Notification
          draft-du-rtgwg-in-network-congestion-notification-00

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.

Copyright Notice

   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

Du                        Expires 24 April 2025                 [Page 1]
Internet-Draft     In-Network Congestion Notification       October 2024

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notifying Method Between PE and P Nodes . . . . . . . . . . .   2
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

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.

Du                        Expires 24 April 2025                 [Page 2]
Internet-Draft     In-Network Congestion Notification       October 2024

   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

Du                        Expires 24 April 2025                 [Page 3]
Internet-Draft     In-Network Congestion Notification       October 2024

       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, March 1997,
              <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, 3 May 2023,
              <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, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

Du                        Expires 24 April 2025                 [Page 4]
Internet-Draft     In-Network Congestion Notification       October 2024

Author's Address

   Zongpeng Du
   China Mobile
   No.32 XuanWuMen West Street
   Beijing
   100053
   China
   Email: duzongpeng@foxmail.com

Du                        Expires 24 April 2025                 [Page 5]