Skip to main content

Compute-Aware Traffic Steering for Midhaul Networks
draft-lcmw-cats-midhaul-02

Document Type Active Internet-Draft (individual)
Authors Luis M. Contreras , Mark T Watts , Tianji Jiang
Last updated 2024-10-21
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lcmw-cats-midhaul-02
cats                                                        L. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                                  M. Watts
Expires: 24 April 2025                                           Verizon
                                                                T. Jiang
                                                            China Mobile
                                                         21 October 2024

          Compute-Aware Traffic Steering for Midhaul Networks
                       draft-lcmw-cats-midhaul-02

Abstract

   Computing-Aware Traffic Steering (CATS) takes into account both
   computing and networking resource metrics for selecting the
   appropriate service instance to forwarding the service traffic.

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

Contreras, et al.         Expires 24 April 2025                 [Page 1]
Internet-Draft                 CATS for MH                  October 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Midhaul Scenario  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  CATS framework applicability for Midhaul  . . . . . . . . . .   6
     3.1.  Control plane interactions between O-RAN and IETF
           management entities . . . . . . . . . . . . . . . . . . .   8
     3.2.  Example of connectivity based on IETF Network Slice
           Service . . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Open points for discussion  . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The radio functional split architecture proposed by O-RAN [ORAN-Arch]
   functionally separates the processing of the mobile radio signal
   originally performed in a single radio base station by placing
   functionality in three entities, namely the Radio Unit (RU), the
   Distributed Unit (DU) and the Centralized Unit (CU).  Both DU and CU
   are typically deployed as service functions on virtualized compute
   nodes in the network.

   The network segment between RU and DU is known as Fronthaul (FH),
   while the network segment between DU and CU is known as Midhaul (MH),
   or F1 interface according to 3GPP terminology.  Both FH and MH have
   specific needs and characteristics in terms of latency and bandwidth,
   constrained by the nature of the data payload and the protocols
   intrinsic for the support of the radio functional split.  More
   details can be found in [ORAN-Req].  The requirements on the FH are
   much stringent that the ones in MH.

Contreras, et al.         Expires 24 April 2025                 [Page 2]
Internet-Draft                 CATS for MH                  October 2024

   In the current O-RAN framework, a DU selects a CU and then creates
   the association DU <–> CU-UP (CU User Plane) in a dynamic way.  Such
   association is established before a UE (or end device) comes to
   register with the mobile operator via the DU, and then the associated
   CU.  From an architectural point of view, it is possible to consider
   scenarios where traffic flows from the DUs can be delivered to
   different CUs depending on the compute and network metrics observed
   during runtime.  It is in these situations where CATS proposition can
   play a distinctive role at the time of ensuring proper delivery of
   the midhaul traffic and its processing.  Thus, the DU <–> CU-CP can
   be dynamic in a way that a DU might optimally select a CU based on
   compute and network metrics.

1.1.  Terminology

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

   In addition, this document uses the terms defined in
   [I-D.ietf-cats-framework].

2.  Midhaul Scenario

   The connection of RU, DU and CU can be performed by means of an IP-
   based aggregation network.  In O-RAN terminology [ORAN-Transport],
   the aggregation routers acting as PE-nodes are called Transport
   Network Elements (TNEs).  The control and management of the TNEs is
   performed by a Transport Network Manager (TNM)
   [ORAN-TransportManagement].  Figure 1 illustrates a packet-switched
   based aggregation network in O-RAN.

                                      +----+
                                      | DU |
                  +----+              +----+
                  | RU |                 |
                  +----+              +-----+
                        \_          .-| TNE |-.
                          \_     ,'   +-----+  `.
                  +----+    \+-----+         +-----+    +----+
                  | RU |-----| TNE |         | TNE |----| CU |
                  +----+   _/+-----+         +-----+    +----+
                         _/       `.           ,'
                        /           ----------'
                  +----+
                  | RU |
                  +----+

Contreras, et al.         Expires 24 April 2025                 [Page 3]
Internet-Draft                 CATS for MH                  October 2024

                         Figure 1: Midhaul Scenario

   The FH segment connecting RUs and DUs is typically static in the
   sense that RUs are anchored with the same DU along the time.
   However, in the case of MH, the association between DUs and CUs could
   be more dynamic, subject to runtime situations such as DU and CU
   load, protection, workload migration (in the case of virtualized CU),
   energy efficiency, etc.

   It is in these situations where the steering of the flows between DU
   and CU can take into consideration both service (including compute)
   and network metrics, as proposed by CATS.  The focus in this document
   refers to the user plane of DU and CU connection (i.e., CU-UP).

   The CUs can be deployed in different regions of the network,
   representing different service instances deployed in distinct service
   sites.  For the illustration of the scenario, Figure 2 considers a
   number of CU instances in different Data Centers (DCs) and a DU
   running on a server, all of them interconnected by an aggregation
   network.  Note that the DU could also run as an instance in a DC or
   even be a physical appliance.

Contreras, et al.         Expires 24 April 2025                 [Page 4]
Internet-Draft                 CATS for MH                  October 2024

                                 +-----+
                                 | CU1 |
                                 +-----+
                                    |
                             +------|--------+
                             |      |  DC 1  |
                             |      o o o    |
                             |       \|/     |
                             |        O      |
                             +--------|------+
                                      |                  +-----+
                     Midhaul Segment  |                  | CU2 |
      +----+         +----------------|----------+       +-----+
      | DU |        /                 |           \         |
      +----+       /        ..........O PE1        \    +---|----------+
         |        |       .                         |   | o o o   DC 2 |
    +--------+    | PE4 .                      PE2  |   |  \|/         |
    | server |----|---O.........................O---|---|---O          |
    +--------+    |     .                           |   |              |
                  |      .           PE3            |   +--------------+
                   \      ..........O   Carrier    /
                    \               |   Network   /
                     +--------------|------------+
                                    |
                           +--------|------+
                           |        O      |
                           |       /|\     |  +-----+
                           |      o o o-------| CU3 |
                           |      |   DC 3 |  +-----+
                           +------|--------+
                                  |
                               +-----+
                               | CU4 |
                               +-----+

                       Figure 2: Midhaul Scenario

   The aggregation network is IP-based, so the MH is realized by means
   of packet-switching technologies.  This is consistent with the
   assumption in CATS that the underlay technology is IP/MPLS network.
   Figure 3 (according to the specification of the F1 / midhaul
   interface in [TS38.470] by 3GPP) illustrates the concern of CATS in
   the connection between DU and CU User Plane (CU-UP), considering as
   example an MPLS-based VPN connectivity.

Contreras, et al.         Expires 24 April 2025                 [Page 5]
Internet-Draft                 CATS for MH                  October 2024

   Connectivity view:
             +------+      +-------+          +-------+     +-------+
             |      |      |       |          |       |     | CU-UP |
             |  DU  |<---->| TNE-1 |<-------->| TNE-2 |<--->| (at   |
             |      |      | (PE1) |          | (PE2) |     |Site X)|
             +------+      +-------+          +-------+     +-------+

   Protocol view:
           +----------+                                    +----------+
   F1-U    |Radio prot|                                    |Radio prot|
   payload +----------+                                    +----------+

        ----------------------------------------------------------------

           +----------+                                    +----------+
           |  GTP-U   |                                    |  GTP-U   |
           +----------+                                    +----------+
   3GPP    |   UDP    |                                    |   UDP    |
   encap   +----------+   +----------+      +----------+   +----------+
           |   IP     |   |   IP     |      |   IP     |   |   IP     |
           +----------+   +----------+      +----------+   +----------+

        ----------------------------------------------------------------

                          +----------+     +----------+
   CATS                   |MPLS (VPN)|     |MPLS (VPN)|
   concern                +----------+     +----------+

                        Figure 3: CATS concern

3.  CATS framework applicability for Midhaul

   The DU traffic cannot be separated in different flows.  That is, the
   payload between DU and CU cannot be discriminated in individual flows
   since the payload represents a pre-processed analog radio signal,
   which will be entirely processed by the CU for obtaining the
   particular end-user flows.  In this situation, the steering decision
   for the selection of a particular CU instance applies to the entire
   DU traffic.  This simplifies the traffic classification since all the
   traffic from a DU is forwarded to the CU until any change is needed.

   Note: Since all the midhaul traffic has the same service instance as
   destination (until any change applies), it is not necessary in this
   particular case the usage of CS-ID for accessing the service.  The
   traffic classification is simple because all packets belong to the
   same service request.

Contreras, et al.         Expires 24 April 2025                 [Page 6]
Internet-Draft                 CATS for MH                  October 2024

   The PE nodes (being TNEs in O-RAN terminology) in Figure 2 play the
   role of CATS-Forwarders.  Each DC is expected to count with a CATS
   Service Metric Agent (C-SMA), while the network part is expected to
   count with a CATS Network Metric Agent (C-NMA).  These agents will
   report different metrics and data to the CATS Path Selector (C-PS),
   which in this case can be assumed to be part of the TNM (i.e.,
   considering that a centralized deployment model is followed, with the
   TNM playing the role of centralized control and management element).

   Example of metrics related to compute could be the CPU average
   utilization or the memory usage of every CU-UP instance
   [ORAN-OCloud].

   Figure 4 maps the CATS framework to the midhaul case.

Contreras, et al.         Expires 24 April 2025                 [Page 7]
Internet-Draft                 CATS for MH                  October 2024

                                +-----+ Service
                                | CU1 | Instance
                                +-----+ 1
                                   |
                            +------|--------+
                            |      |        |(C-SMA)
                            |      o o o    |
           (C-PS)           |       \|/     |
                            |Service O Site1|
                            +--------|------+
                                     |                  +-----+ Service
                    Midhaul Segment  |                  | CU2 | Instance
     +----+         +----------------|----------+       +-----+ 2
     | DU1|        /                 |           \         |
     +----+       /        ..........O CF1        \    +---|----------+
        |        |       .                         |   | o o o        |(C-SMA)
   +--------+    | CF4 .         (C-NMA)      CF2  |   |  \|/         |
   | server |----|---O.........................O---|---|---O  Service |
   +--------+    |     .                           |   |      Site 2  |
                 |      .           CF3            |   +--------------+
                  \      ..........O   Carrier    /
                   \               |   Network   /
                    +--------------|------------+
                                   |
                          +--------|------+
                  (C-SMA) |Service O      |
                          |Site 3 /|\     |  +-----+ Service
                          |      o o o-------| CU3 | Instance
                          |      |        |  +-----+ 3
                          +------|--------+
                                 |
                              +-----+ Service
                              | CU4 | Instance
                              +-----+ 4

           Figure 4: CATS applicability to Midhaul Scenario

3.1.  Control plane interactions between O-RAN and IETF management
      entities

   The connectivity between O-RAN radio functional entities is assumed
   to be managed by a Transport Network Manager (TNM) in charge of the
   control and management of the network.  The interplay between the
   O-RAN Service and Management Orchestrator (SMO) and the TNM is
   currently under definition.  The TNM function is assumed to be
   performed following IETF specifications.  That role could be played,
   for instance, by the Network Slice Controller as defined in [RFC9543]
   for the provision of network slice services.  Figure 5 represents the

Contreras, et al.         Expires 24 April 2025                 [Page 8]
Internet-Draft                 CATS for MH                  October 2024

   relationship between O-RAN SMO and the TNM.

             +-----------+   Interface   +-----------+
             |           | to be defined | Transport |
             | O-RAN SMO |<------------->|  Network  |
             |           |               |  Manager  |
             +-----------+               +-----------+

                 Figure 5: Interworking between SMO and TNM

   For the specific case of CU-UP instance selection, every instance can
   be associated to various kinds of runtime information, i.e.,
   including both (i) network metrics like bandwidth, delay, path-loss,
   reliability, etc., and (ii) compute or service metrics (of the CU-UP)
   like CPU load, memory, storage, service-load, etc.  That information
   can assist on the selection of the most convenient CU-UP instance for
   a given DU.  After the selection of a given instance, the O-RAN SMO
   will proceed to the necessary configurations on the O-RAN functional
   entities and instruct the TNM for performing the traffic steering of
   the service flows.  The TNM, in consequence, represents the CATS
   entities necessary for the selection of the steering path and the
   forwarding of the traffic on it.

3.2.  Example of connectivity based on IETF Network Slice Service

   The connectivity in the MH segment could be realized for instance by
   means of IETF Network Slice Services [RFC9543], as described in
   [I-D.ietf-teas-5g-network-slice-application] and
   [I-D.ietf-teas-5g-ns-ip-mpls], according to the Service Level
   Objectives of the Midhaul traffic.  With that connectivity in place
   for each of the possible CUs as Service Instances, the C-PS could
   decided which slice to use for delivering the traffic to a specific
   CU.  Note that the realization of the IETF Network Slice Service
   could be performed either by means of a common slice for connecting
   the DU with all the CUs, or a slice per DU to CU connection.  Once
   the C-PS takes deicsion on which CU (or Service Instance) deliver all
   the DU traffic, a policy could be applied (e.g., usage of the IP
   address of the CU-UP instance as match criteria in
   [I-D.ietf-teas-ietf-network-slice-nbi-yang]) for mapping the DU
   traffic to the proper connectivty construct of the IETF Network Slice
   Service.

   Thus, the IETF Network Slice Service could be defined as hub-and-
   spoke from each DU to any of the CU-UP instances, and realized, e.g.,
   by means of a VPN.  A potential definition of the slice service using
   [I-D.ietf-teas-ietf-network-slice-nbi-yang]) could be as follows in
   Figure 6:

Contreras, et al.         Expires 24 April 2025                 [Page 9]
Internet-Draft                 CATS for MH                  October 2024

             "connection-groups": {
               "connection-group": [
                 {
                   "id": "matrix1",
                   "connectivity-type": "ietf-vpn-common:hub-spoke",
                   "connectivity-construct": [
                     {
                       "id": "1",
                       "p2mp-sender-sdp": "du1",
                       "p2mp-receiver-sdp": [
                         "cu-up1",
                         "cu-up2",
                         "cu-up3",
                         "cu-up4"
                       ],
                       },

                       "status": {}
                     }
                   ]
                 }
               }

      Figure 6: Definition of the CATS steering paths as IETF NEtwork
                               Slice Service

   Moreover, based on the metrics collected for both network and
   compute, the C-PS could take the decision of steering the traffic of
   the DU towards a particular CU-UP instance, properly configuring the
   math criteria, setting it to the destination IP address of the CU-UP
   instance of interest, as exemplified in Figure 7.

                   "service-match-criteria": {
                     "match-criterion": [
                       {
                         "index": 1,
                         "match-type": "ietf-nss:destination-ip-prefix",
                         "value": ["2001:db8::1/64"],
                         "target-connection-group-id": "matrix1"
                       }
                     ]
                   }

     Figure 7: Enforcement of the path steering leveraging on match-
                                 criteria

Contreras, et al.         Expires 24 April 2025                [Page 10]
Internet-Draft                 CATS for MH                  October 2024

4.  Open points for discussion

   This version is an initial attempt of applicability of CATS for
   Midhaul scenarios as defined in O-RAN.  The followoing are identified
   open points for further discussion, which will be elaborated in next
   versions of the document.

   *  Actions / situations changing the service affinity in the case of
      midhaul (and potential interaction with O-RAN specific service
      orchestration capabilities).

   *  Provide insights of control plane interactions (O-RAN SMO with TNM
      as IETF NSC [RFC9543])

5.  Security Considerations

   Same security considerations as in [I-D.ietf-cats-framework] apply
   also here.

6.  Acknowledgements

   TBC

7.  References

7.1.  Normative References

   [RFC9543]  Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
              Makhijani, K., Contreras, L., and J. Tantsura, "A
              Framework for Network Slices in Networks Built from IETF
              Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
              <https://www.rfc-editor.org/info/rfc9543>.

7.2.  Informative References

   [I-D.ietf-cats-framework]
              Li, C., Du, Z., Boucadair, M., Contreras, L. M., and J.
              Drake, "A Framework for Computing-Aware Traffic Steering
              (CATS)", Work in Progress, Internet-Draft, draft-ietf-
              cats-framework-04, 17 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cats-
              framework-04>.

Contreras, et al.         Expires 24 April 2025                [Page 11]
Internet-Draft                 CATS for MH                  October 2024

   [I-D.ietf-teas-5g-network-slice-application]
              Geng, X., Contreras, L. M., Rokui, R., Dong, J., and I.
              Bykov, "IETF Network Slice Application in 3GPP 5G End-to-
              End Network Slice", Work in Progress, Internet-Draft,
              draft-ietf-teas-5g-network-slice-application-03, 10 June
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              teas-5g-network-slice-application-03>.

   [I-D.ietf-teas-5g-ns-ip-mpls]
              Szarkowicz, K. G., Roberts, R., Lucek, J., Boucadair, M.,
              and L. M. Contreras, "A Realization of Network Slices for
              5G Networks Using Current IP/MPLS Technologies", Work in
              Progress, Internet-Draft, draft-ietf-teas-5g-ns-ip-mpls-
              13, 11 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-
              ns-ip-mpls-13>.

   [I-D.ietf-teas-ietf-network-slice-nbi-yang]
              Wu, B., Dhody, D., Rokui, R., Saad, T., and J. Mullooly,
              "A YANG Data Model for the RFC 9543 Network Slice
              Service", Work in Progress, Internet-Draft, draft-ietf-
              teas-ietf-network-slice-nbi-yang-16, 28 August 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              ietf-network-slice-nbi-yang-16>.

   [ORAN-Arch]
              "O-RAN Architecture Description, V11.00", February 2024.

   [ORAN-OCloud]
              "O-Cloud Information Model, V01.00", June 2024.

   [ORAN-Req] "O-RAN Xhaul Transport Requirements, V01.00", February
              2021.

   [ORAN-Transport]
              "O-RAN Xhaul Packet Switched Architectures and Solutions,
              V07.00", February 2024.

   [ORAN-TransportManagement]
              "O-RAN Management interfaces for Transport Network
              Elements, V07.00", October 2023.

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

   [TS38.470] "F1 general aspects and principles, V16.2.0", 2020.

Contreras, et al.         Expires 24 April 2025                [Page 12]
Internet-Draft                 CATS for MH                  October 2024

Authors' Addresses

   Luis M. Contreras
   Telefonica
   Email: luismiguel.contrerasmurillo@telefonica.com

   Mark Watts
   Verizon
   Email: mark.t.watts@verizon.com

   Tianji Jiang
   China Mobile
   Email: tianjijiang@chinamobile.com

Contreras, et al.         Expires 24 April 2025                [Page 13]