Compute-Aware Traffic Steering for Midhaul Networks
draft-lcmw-cats-midhaul-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Luis M. Contreras , Mark T Watts | ||
| Last updated | 2024-03-04 | ||
| 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-00
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, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-5g-network-slice-application-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-
ns-ip-mpls-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slices-25>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ldbc-cats-
framework-06>.
[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,
<https://www.rfc-editor.org/info/rfc2119>.
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]