



cats                                                        L. Contreras
Internet-Draft                                                Telefonica
Intended status: Informational                                  M. Watts
Expires: 8 January 2026                                          Verizon
                                                                T. Jiang
                                                            China Mobile
                                                             7 July 2025


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

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.  This
   document described the usage of Computing-Aware Traffic Steering
   (CATS) within Midhaul (MH) networks in the O-RAN architecture.  It
   details how CATS can enhance traffic steering decisions between
   Distributed Units (DUs) and Centralized Units (CUs) by considering
   both compute resource metrics (e.g., CPU and memory utilization of CU
   instances) and network performance metrics (e.g., bandwidth, latency,
   reliability).

   The document discusses the integration of CATS with O-RAN management
   frameworks, and the interplay with the Transport Network Manager
   (TNM) in O-RAN using standard interfaces defined by IETF (as for
   example the one for Network Slice Services for connectivity
   provisioning).

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 8 January 2026.




Contreras, et al.        Expires 8 January 2026                 [Page 1]

Internet-Draft                 CATS for MH                     July 2025


Copyright Notice

   Copyright (c) 2025 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.

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 . . . . . . . . . . . . . . . . . . . . . . . . .  11
   4.  Open points for discussion  . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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.










Contreras, et al.        Expires 8 January 2026                 [Page 2]

Internet-Draft                 CATS for MH                     July 2025


   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.

   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.










Contreras, et al.        Expires 8 January 2026                 [Page 3]

Internet-Draft                 CATS for MH                     July 2025


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

                         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 8 January 2026                 [Page 4]

Internet-Draft                 CATS for MH                     July 2025


                                 +-----+
                                 | 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 8 January 2026                 [Page 5]

Internet-Draft                 CATS for MH                     July 2025


   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 8 January 2026                 [Page 6]

Internet-Draft                 CATS for MH                     July 2025


   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 8 January 2026                 [Page 7]

Internet-Draft                 CATS for MH                     July 2025


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

   In the O-RAN architecture, the Service and Management Orchestrator
   (SMO) is responsible for RAN domain management and provides
   orchestration and management services.

   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 SMO and the TNM is currently under definition.  The interplay



Contreras, et al.        Expires 8 January 2026                 [Page 8]

Internet-Draft                 CATS for MH                     July 2025


   between TNM and SMO allows an integrated management of both the
   transport network and RAN elements, enhancing end-to-end service
   orchestration and operational efficiency.

   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 [ORAN-Transport].  In summary, TNM can
   incorporate standardized transport network data models and protocols
   to enrich O-RAN capabilities and interoperability.  Figure 5
   represents the relationship between O-RAN SMO and the TNM.

             +-----------+               +-----------+
             |           |      TNM-I    | Transport |
             | O-RAN SMO |<------------->|  Network  |
             |           |   (Interface  |  Manager  |
             +-----------+ to be defined)+-----------+

                 Figure 5: Interworking between SMO and TNM

   The SMO defines the O1 interface for management functions such as
   fault, configuration, performance, and security management of O-RAN
   Network Functions (NFs), including O-DU and O-CU.  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.

   The O-RAN architecture also defines the O-Cloud entity as the
   component concerned with infrastructure and workload-related metrics
   such as fault management, performance management (including possibly
   resource utilization, availability, throughput, latency), and
   configuration status of the cloud platform itself and the hosted
   O-RAN Network Functions.  The SMO and the O-Cloud interact by means
   of the O2 interface.














Contreras, et al.        Expires 8 January 2026                 [Page 9]

Internet-Draft                 CATS for MH                     July 2025


       +-----------------------------------------------------+
       |                                                     |
       |                        SMO                          |
       |                                                     |
       +-----------------------------------------------------+
          ^       ^                  ^                 ^
          |       |                  | TNM-I           |
          |       |                  v                 |
       O2 |    O1 |             +---------+            | O1
          |       |             |         |            |
          |       |             |   TNM   |            |
          |       |             |         |            |
          |       |             +---------+            |
          |       v                  ^                 v
          |  +----------+            |            +----------+
          |  |          |            v            |          |
          |  |   O-DU   |-(TNE1) ######### (TNE2)-|   O-CU   |
          |  |          |                         |          |
          |  +----------+                         +----------+
          |  @@@@@@@@@@@@                         @@@@@@@@@@@@
          |       ^                                    ^
          |       |                                    |
          v       v                                    v
       +-----------------------------------------------------+
       |                                                     |
       |                       O-Cloud                       |
       |                                                     |
       +-----------------------------------------------------+

       <---> management and control interfaces
       @@@@@ virtualized infrastructure
       ##### connectivity path

                       Figure 6: SMO, O-Cloud and TNM

   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, enforce the steering path for
   connecting DU and CU-UP.

   When mapped to the CATS framework, this has the follwing
   implications:

   *  The compute-related metrics are provided by the O-Cloud component.

   *  The network-related metrics are provided by the TNM component.




Contreras, et al.        Expires 8 January 2026                [Page 10]

Internet-Draft                 CATS for MH                     July 2025


   *  Two cases can be considered:

      -  The processing of both kind of metrics is performed by the SMO,
         who finally determines the association of DU and CU-UP
         instances based on the metrics before.  This means that the SMO
         gets network-related metrics from TNM (and probably some
         adidtional information, like topology), and that the CATS Path
         Selector functional component resides in the SMO.

      -  The TNM gets from the SMO the compute-aware metrics performing
         the processing of both kind of metrics.  Additional information
         can be required from SMO (for instance the location of the data
         center sites and/or the association policy).  This means that
         the CATS Path Selector functional component resides in the TNM.

   *  After the association decision, the TNM for enforcing the steering
      path in the network (in the first case, instructed by the SMO,
      while in the second taking the enforcement decision by its own).

   These approaches do not prevent other possible alternatives of
   mapping CATS entities in an O-RAN scenario.

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





Contreras, et al.        Expires 8 January 2026                [Page 11]

Internet-Draft                 CATS for MH                     July 2025


             "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 7: 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 8.

                   "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 8: Enforcement of the path steering leveraging on match-
                                 criteria






Contreras, et al.        Expires 8 January 2026                [Page 12]

Internet-Draft                 CATS for MH                     July 2025


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

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-10, 24 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cats-
              framework-10>.

   [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-04, 3 March
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              teas-5g-network-slice-application-04>.




Contreras, et al.        Expires 8 January 2026                [Page 13]

Internet-Draft                 CATS for MH                     July 2025


   [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-
              18, 3 April 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-teas-5g-ns-ip-mpls-18>.

   [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-25, 9 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              ietf-network-slice-nbi-yang-25>.

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

Authors' Addresses

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






Contreras, et al.        Expires 8 January 2026                [Page 14]

Internet-Draft                 CATS for MH                     July 2025


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


   Tianji Jiang
   China Mobile
   Email: tianjijiang@yahoo.com











































Contreras, et al.        Expires 8 January 2026                [Page 15]
