cats L. Contreras Internet-Draft Telefonica Intended status: Informational M. Watts Expires: 5 September 2024 Verizon 4 March 2024 Compute-Aware Traffic Steering for Midhaul Networks draft-lcmw-cats-midhaul-00 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 5 September 2024. 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 & Watts Expires 5 September 2024 [Page 1] Internet-Draft CATS for MH March 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. Midhaul Scenario . . . . . . . . . . . . . . . . . . . . . . 3 3. CATS framework applicability for Midhaul . . . . . . . . . . 5 4. Open points for dicussion . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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). Both FH and MH have specific needs and characterisitcs in terms of latency and bandwidth, constrained by the nature of the data payload and the protocols intrinsic fo rthe 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. 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 observed compute and network metrics observed in 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. 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.ldbc-cats-framework]. Contreras & Watts Expires 5 September 2024 [Page 2] Internet-Draft CATS for MH March 2024 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 (TMN) [ORAN-TransportManagement]. Figure 1 illustrates a packet-switched based agrgegation network in O-RAN. +----+ | DU | +----+ +----+ | RU | | +----+ +-----+ \_ .-| TNE |-. \_ ,' +-----+ `. +----+ \+-----+ +-----+ +----+ | RU |-----| TNE | | TNE |----| CU | +----+ _/+-----+ +-----+ +----+ _/ `. ,' / ----------' +----+ | RU | +----+ Figure 1: Midhaul Scenario The FH segment connecting RUs and DUs is typilcally 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 teh 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 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 & Watts Expires 5 September 2024 [Page 3] Internet-Draft CATS for MH March 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. Contreras & Watts Expires 5 September 2024 [Page 4] Internet-Draft CATS for MH March 2024 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 inidividual 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 teh same service request. 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 TMN playing the role of centralized control and management element). Figure 3 maps the CATS framework to the midhaul case. Contreras & Watts Expires 5 September 2024 [Page 5] Internet-Draft CATS for MH March 2024 +-----+ Service | CU1 | Instance +-----+ 1 | +------|--------+ | | |(C-SMA) | o o o | (C-PS) | \|/ | |Service O Site1| +--------|------+ | +-----+ Service Midhaul Segment | | CU2 | Instance +----+ +----------------|----------+ +-----+ 2 | DU | / | \ | +----+ / ..........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 3: CATS applicability to Midhaul Scenario The connectivity in the MH segment could be realized for instance by means of IETF Network Slice Services [I-D.ietf-teas-ietf-network-slices], 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 Netwwork 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 Contreras & Watts Expires 5 September 2024 [Page 6] Internet-Draft CATS for MH March 2024 the C-PS takes deicsion on which CU (or Service Instance) deliver all the DU traffic, a policy could be applies (e.g., match criteria) for mapping the DU traffic to the proper connectivty construct of the IETF Netwwork Slice Service. Note: further refinement on the procedure for slecting the path is needed in teh case of IETF Netwwork Slice Service 4. Open points for dicussion 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. * Mapping of the midhaul traffic (service) to different possible paths, as in teh case described using IETF Network Slice Services. * Need (or not) of service access processing in the case of midhaul (i.e., applying to all the traffic between DU and CU). * Actions / situations changing the service affinity in the case of midhaul (and potential interaction with O-RAN specific service orchestration capabilities). 5. Security Considerations Same security considerations as in [I-D.ldbc-cats-framework] apply also here. 6. Acknowledgements TBC 7. Informative References [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-02, 23 October 2023, . [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 Contreras & Watts Expires 5 September 2024 [Page 7] Internet-Draft CATS for MH March 2024 Progress, Internet-Draft, draft-ietf-teas-5g-ns-ip-mpls- 03, 28 February 2024, . [I-D.ietf-teas-ietf-network-slices] Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", Work in Progress, Internet-Draft, draft-ietf-teas-ietf- network-slices-25, 14 September 2023, . [I-D.ldbc-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-ldbc- cats-framework-06, 8 February 2024, . [ORAN-Arch] "O-RAN Architecture Description, V11.00", February 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, . Authors' Addresses Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Contreras & Watts Expires 5 September 2024 [Page 8] Internet-Draft CATS for MH March 2024 Mark Watts Verizon Email: mark.t.watts@verizon.com Contreras & Watts Expires 5 September 2024 [Page 9]