IGMP / MLD Extension for Signaling Eco-Mode
draft-contreras-pim-eco-mode-01

PIM Working Group                                        L. M. Contreras
Internet-Draft                                                Telefonica
Intended status: Standards Track                              M. Palmero
Expires: 7 January 2027                                      Independent
                                                              B. Schwarz
                                                                   CTOiC
                                                             6 July 2026

              IGMP / MLD Extension for Signaling Eco-Mode
                    draft-contreras-pim-eco-mode-01

Abstract

   This document specifies an extension to IGMPv3 and MLDv2 messages to
   indicate eco-mode preferences in the delivery of multicast content
   based on the mechanism described in [RFC9279].  The extension enables
   receivers and network elements to signal energy-aware multicast
   delivery preferences, including different eco-mode levels, so that
   multicast services can be operated consistently with energy-efficient
   network management, service-level optimisation, and telemetry-driven
   assessment of energy and carbon impact.

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

Copyright Notice

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

Contreras, et al.        Expires 7 January 2027                 [Page 1]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   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.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Relationship with Energy-Efficient Network Management . .   4
   2.  Service-Level Optimisation Use Cases  . . . . . . . . . . . .   5
     2.1.  Large-Scale Energy-Aware Multicast Distribution . . . . .   5
     2.2.  Energy-Aware Multicast Video Streaming  . . . . . . . . .   6
     2.3.  Mobile Multicast Environments . . . . . . . . . . . . . .   6
     2.4.  Carbon-Aware Multicast Delivery . . . . . . . . . . . . .   6
     2.5.  Incentive-Aware Service Behaviour . . . . . . . . . . . .   7
   3.  Eco-mode Extension  . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Eco-mode TLV format . . . . . . . . . . . . . . . . . . .   7
     3.2.  Eco-mode levels . . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Eco-mode usage  . . . . . . . . . . . . . . . . . . . . .   9
   4.  Energy Efficiency Metrics . . . . . . . . . . . . . . . . . .  10
   5.  Security and operational considerations . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Video contents currently represent the major source of traffic in
   operator's networks.  The same content can be distributed in
   multicast with different resolution adapted to the characteristics of
   subscriber's receiver.  The amount of traffic per multicast flow is
   dependent on the resolution of the encoded video: the higher the
   resolution, the higher the bit rate per multicast video flow.  This
   tends to increase as subscriber devices support higher resolutions.
   In addition to that, the distribution trees are continuously built in
   the network, in most cases proactively subscribing to channels to
   minimize access time to the content even during periods of low or
   inexistent demand.

Contreras, et al.        Expires 7 January 2027                 [Page 2]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   As of today, there is no mechanism available for subscribers to
   indicate their willingness to apply an eco-mode consumption of
   multicast content to their subscription.  Such a mechanism could
   incentivize the user to explicitly signal to the network the desire
   to receive a more energy-efficient service, or it could even be
   activated by default, forcing the user to explicitly indicate the
   opposite behavior in certain circumstances, for instance to receive
   the highest available quality of service.

   Multicast content distribution inherently optimizes bandwidth by
   delivering the same content to multiple receivers simultaneously,
   reducing redundant transmissions.  An eco-mode, when applied to
   multicast distribution, can further optimize resource utilization by
   enabling the network and the service provider to select delivery
   alternatives that reduce energy consumption or carbon impact, such as
   lower-rate representations, less energy-intensive forwarding
   resources, different delivery timing, or the aggregation of receivers
   with similar energy preferences.  By implementing an eco-mode, the
   system can reduce power usage during off-peak hours, when fewer
   receivers are active in the system, or by reducing the resolution or
   other delivery attributes of the content.

   Applications can already implement adaptive service behavior based on
   local information available at the endpoint.  However, application-
   layer optimizations often lack visibility of multicast-specific
   information such as group membership dynamics, aggregation
   opportunities across multiple receivers, multicast delivery trees, or
   network-level energy optimization policies.

   Similarly, network operators may implement energy optimization
   mechanisms without visibility of the willingness of individual
   receivers to participate in such optimizations.  The signaling
   defined in this document is intended to complement, rather than
   replace, application-level adaptation mechanisms.  Its objective is
   to provide a common and protocol-independent means for conveying
   receiver energy preferences within the multicast ecosystem so that
   multiple entities participating in service delivery can use this
   information as part of their local optimization decisions.

   Throughout this document, the term eco-mode is used as a generic
   label for energy-aware service delivery preferences.  The mechanism
   is not restricted to a single optimization technique and may be used
   to express preferences related to reduced energy consumption, lower
   carbon footprint, increased use of renewable energy, or other
   sustainability-related delivery objectives.

Contreras, et al.        Expires 7 January 2027                 [Page 3]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   This document proposes an extension of IGMP and MLD messages for
   supporting the signaling of eco-mode.  The detailed implications of
   the eco-mode in the receiver, the access network, the multicast
   controller, or the content provider are out of the scope of this
   document.  However, this document defines the information that can be
   exchanged at the multicast listener level so that such entities can
   apply local policies or interact with energy management systems.

1.1.  Problem Statement

   Current multicast delivery mechanisms provide no standardized means
   for receivers to express energy-related service preferences when
   joining a multicast group.

   While energy optimization mechanisms can be implemented within
   applications, content platforms, or network infrastructure, such
   mechanisms typically operate without explicit knowledge of whether a
   receiver is willing to accept a lower-energy delivery alternative.

   As a consequence, multicast service providers and network operators
   are forced either to assume a uniform service profile for all
   receivers or to rely on proprietary mechanisms outside the multicast
   control plane.

   The absence of a standardized signaling mechanism limits the ability
   of multicast services to apply service-level energy optimizations,
   particularly in environments where energy consumption, battery
   constraints, carbon footprint, or sustainability objectives are
   important factors.

   This document introduces an explicit receiver preference signal that
   can be used by multicast-aware systems as an input to energy-related
   service optimization policies.  The purpose of the extension is
   solely to provide a standardized input signal that such systems may
   consume.

1.2.  Relationship with Energy-Efficient Network Management

   The work in IETF GREEN Working Group is motivated by the need for
   operators to measure, report, and manage energy consumption in
   heterogeneous networks and to support operational strategies that
   improve energy efficiency while preserving functional and performance
   requirements.  The eco-mode extension defined in this document is
   complementary to such work since it provides a protocol-level signal
   at the multicast listener interface that can be consumed by energy-
   aware network management functions.

Contreras, et al.        Expires 7 January 2027                 [Page 4]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   The eco-mode signal can be interpreted as an energy-related service
   preference associated with a multicast membership operation.  It does
   not by itself define how energy savings are achieved, nor does it
   mandate a specific power-management behavior in network devices.
   Instead, it exposes receiver intent or receiver acceptance of energy-
   optimized delivery so that other functions, such as multicast service
   controllers, access nodes, application-layer controllers, telemetry
   collectors, or energy management systems, can correlate listener
   demand with energy-aware policies.

   In deployments where a GREEN framework [I-D.ietf-green-framework] or
   a network energy management system is available, the eco-mode
   information can be used as an input to policy decisions such as
   selecting a lower-energy representation of a stream, consolidating
   multicast forwarding state, avoiding unnecessary activation of
   network resources, or scheduling delivery when this is compatible
   with the application semantics.  In this sense, the extension defined
   in this document is not a replacement for device-, component-, or
   network-level energy management models.  It is a service-level signal
   that can complement such models by indicating which receivers or
   groups of receivers are willing to consume a multicast service under
   energy-optimized delivery conditions.

2.  Service-Level Optimisation Use Cases

   The eco-mode extension defined in this document can support this
   service-level perspective in multicast delivery scenarios.

2.1.  Large-Scale Energy-Aware Multicast Distribution

   Consider a multicast service with thousands of receivers.

   A subset of receivers explicitly indicates acceptance of enhanced
   energy-saving delivery policies through the eco-mode extension,
   whereas other receivers request the default service profile.

   The multicast service controller can use this information to
   associate the two receiver populations with different multicast
   distributions, for example providing distinct bitrate, resolution,
   refresh rate, or delivery schedules.

   This enables the application of energy-saving policies only to
   receivers that explicitly opt into such behavior, avoiding
   unnecessary service degradation for receivers that do not express
   such a preference.

Contreras, et al.        Expires 7 January 2027                 [Page 5]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   The eco-mode extension therefore provides a standardized mechanism
   for creating receiver populations with different energy-related
   service profiles.

2.2.  Energy-Aware Multicast Video Streaming

   A multicast service may provide several encoded representations of
   the same content, each with different bit rate, resolution, frame
   rate, or encoding complexity.  When a receiver signals an eco-mode
   level, the service can associate that receiver with a representation
   that provides an acceptable user experience while reducing the
   network, compute, or device energy required to deliver and consume
   the content.  The same signal can also be used by an access network
   or multicast controller to aggregate receivers with similar eco-mode
   preferences and avoid creating or maintaining unnecessary forwarding
   state for higher-energy representations.

2.3.  Mobile Multicast Environments

   A user equipment, residential gateway, set-top box, or constrained
   device may prefer a lower-energy multicast delivery mode because of
   local battery constraints, user policy, subscription policy, or
   application preference.  The eco-mode signal enables such an endpoint
   or its local network to express this preference at the point where
   multicast membership is established.  The actual optimisation may
   occur in a different domain, for example in an access network,
   transport network, edge platform, or content delivery infrastructure,
   but the multicast listener signal provides a service-level indication
   that can be correlated with measurements gathered in those domains.

2.4.  Carbon-Aware Multicast Delivery

   In some deployments, a service provider may have information about
   the energy source, carbon intensity, or expected energy cost
   associated with different delivery alternatives.  If a receiver
   indicates a strong eco-mode preference, the provider can apply local
   policies that favor lower-carbon delivery options when they are
   compatible with the requested service.  This document does not define
   carbon accounting procedures, nor does it define how carbon intensity
   is measured.  It only provides a compact multicast listener signal
   that can be used by systems performing such service-level
   optimisation.

Contreras, et al.        Expires 7 January 2027                 [Page 6]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

2.5.  Incentive-Aware Service Behaviour

   A provider may offer differentiated service options in which users
   selecting eco-mode receive economic, informational, or service-level
   incentives.  The signaling defined in this document can be used as a
   protocol input to such mechanisms.  The definition of incentive
   models, charging, user consent, or commercial policy is outside the
   scope of this document.

3.  Eco-mode Extension

   [RFC9279] defines a mechanism for extending IGMPv3 and MLDv2 messages
   by carrying TLVs.  This document proposes an extension for indicating
   an eco-mode preference associated with multicast listener operations.

3.1.  Eco-mode TLV format

   The format of the extension is as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Eco-Mode Type = TBD      |       Eco-Mode Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Eco-Level     | Preference    | Flags         |   Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Eco-Mode Type: 2 octets.  The type of the Eco-Mode TLV extension is
   TBD.

   Eco-Mode Length: 2 octets.  This specifies the length in octets of
   the following Value field.  The length of the Eco-Mode extension
   Value field is set to 4 octets.

   Eco-Level: 1 octet.  This field indicates the eco-mode level
   requested or accepted by the receiver.  The value 0 indicates normal
   delivery, with no explicit eco-mode preference.  The value 1
   indicates basic eco-mode, where the receiver accepts moderate energy
   optimisation if the service remains substantially equivalent.  The
   value 2 indicates enhanced eco-mode, where the receiver accepts
   stronger energy optimisation, including possible reduction of
   resolution, bit rate, refresh rate, or equivalent service parameters.
   The value 3 indicates maximum eco-mode, where the receiver accepts
   the most energy-efficient delivery mode available for the service,
   subject to local policy and application constraints.  Values 4
   through 255 are reserved for future use and MUST be ignored by
   receivers that do not understand them.

Contreras, et al.        Expires 7 January 2027                 [Page 7]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   Preference: 1 octet.  This field qualifies the optimisation
   preference associated with the Eco-Level.  The value 0 indicates a
   generic energy-saving preference.  The value 1 indicates a carbon-
   saving preference.  The value 2 indicates preference for use of
   renewable or lower-carbon energy when such information is available
   to the provider.  The value 3 indicates an operator-defined
   preference.  Values 4 through 255 are reserved for future use.

   Flags: 1 octet.  This field is reserved for future flags that qualify
   the eco-mode behaviour.  In this version of the document, the field
   MUST be set to zero by the sender and MUST be ignored by the
   receiver.

   Reserved: 1 octet.  This field is reserved for future use.  It MUST
   be set to zero by the sender and MUST be ignored by the receiver.

3.2.  Eco-mode levels

   The eco-mode indication is no longer limited to a binary value.  A
   multi-level indication enables a receiver to express the degree of
   energy-aware optimisation that it is willing to accept.  This is
   useful because different services may have different tolerance to
   energy-related adaptation.  For example, a real-time multicast video
   channel may only accept moderate bit-rate adaptation, while non-real-
   time content distribution may tolerate delayed or lower-rate
   delivery.

   The semantic interpretation of each level is service specific and
   subject to local policy.  However, the following generic
   interpretation is RECOMMENDED:

   *  Level 0: normal delivery.  The receiver does not request energy-
      optimised delivery and expects the default service behaviour.

   *  Level 1: basic eco-mode.  The receiver accepts energy optimisation
      that is not expected to materially affect the perceived service.

   *  Level 2: enhanced eco-mode.  The receiver accepts visible or
      measurable service adaptation, such as a lower-bitrate
      representation or reduced refresh characteristics, if this
      produces energy or carbon benefit.

   *  Level 3: maximum eco-mode.  The receiver accepts the most energy-
      efficient available delivery mode for the service, including more
      aggressive adaptation, subject to application and operator policy.

Contreras, et al.        Expires 7 January 2027                 [Page 8]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   When the extension is used to emulate the binary behaviour described
   in earlier versions of this document, a value of Level 0 is
   equivalent to eco-mode disabled and any non-zero level is equivalent
   to eco-mode enabled.  Implementations that only support binary eco-
   mode semantics SHOULD map any non-zero Eco-Level to an enabled eco-
   mode indication.

3.3.  Eco-mode usage

   The eco-mode is intended to be supported in both the Query and Report
   messages for IGMP and MLD.  The logic behind the inclusion of the
   eco-mode extension at both subscriber and provider side is out of the
   scope of this draft.

   In Report messages, the extension allows a multicast listener to
   indicate the eco-mode level and preference type associated with its
   membership request.  In Query messages, the extension can be used by
   a querier to indicate that eco-mode signaling is supported or to
   request updated eco-mode information from listeners.  A listener that
   does not understand the extension follows the processing rules
   defined in [RFC9279].

   The eco-mode indication is intended to be consumed by service
   controllers, multicast management systems, content distribution
   platforms, or network optimization systems.

   Examples of actions enabled by the signal include:

   *  Selection of an alternative multicast representation of the
      content.

   *  Selection of lower-bitrate delivery alternatives.

   *  Aggregation of receivers sharing similar energy preferences.

   *  Allocation of receivers to multicast groups associated with
      different service profiles.

   *  Optimization of resource activation decisions in access,
      transport, or edge infrastructures.

   *  Correlation between receiver preferences and energy-efficiency
      telemetry systems.

   This document does not mandate any of these actions and leaves policy
   decisions to local implementation.

Contreras, et al.        Expires 7 January 2027                 [Page 9]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   A network element receiving the eco-mode indication MAY use it as
   input to local policy.  Such policy can determine whether the
   receiver is associated with a lower-energy representation, whether
   multicast state is aggregated differently, whether traffic is mapped
   to an energy-aware path, or whether telemetry is exported to an
   energy management system.  This document does not prescribe those
   policy actions.

4.  Energy Efficiency Metrics

   Eco-mode signaling is only useful operationally if it can be
   correlated with measurable effects.  Implementations and deployments
   of this extension SHOULD expose metrics that allow an operator or
   service provider to assess the impact of eco-mode on the multicast
   service.  The exact definition and collection of such metrics may be
   provided by separate management models or telemetry systems.  This
   document identifies the following metrics as relevant to deployments
   of this extension:

   *  Eco-mode receiver count: the number of receivers that have
      signaled a non-zero Eco-Level for a given multicast group, source,
      interface, service, or administrative scope.

   *  Eco-mode level distribution: the distribution of receivers across
      the supported Eco-Level values.

   *  Eco-mode traffic volume: the amount of multicast traffic delivered
      to receivers operating under eco-mode, expressed in packets,
      octets, bit/s, or another locally defined unit.

   *  Estimated energy avoided: the estimated energy not consumed as a
      result of applying eco-mode policy compared with an operator-
      defined baseline.

   *  Estimated carbon avoided: the estimated carbon impact avoided as a
      result of applying eco-mode policy compared with an operator-
      defined baseline.

   *  Eco-mode service adaptation count: the number of times the
      multicast service was adapted because of eco-mode, for example by
      selecting a different representation, bit rate, or delivery
      policy.

   *  Eco-mode policy outcome: the result of applying local policy to
      the eco-mode signal, such as accepted, ignored, downgraded,
      overridden, or unsupported.

Contreras, et al.        Expires 7 January 2027                [Page 10]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

   The metrics above are intentionally defined at a high level.  This
   document does not define benchmark methodology, energy estimation
   procedures, or carbon accounting procedures.  Such procedures may
   depend on the specific service, the measurement capabilities of the
   involved devices, and the energy model used by the operator.

5.  Security and operational considerations

   The same security considerations as described in [RFC9279] apply also
   in this document.

   In addition, an attacker able to forge or modify eco-mode information
   could influence multicast service behaviour by causing receivers to
   be associated with a different delivery mode than intended.
   Depending on local policy, this could result in degraded service
   quality, incorrect accounting of energy-related metrics, or
   misleading telemetry.  Implementations SHOULD apply the same
   protection mechanisms used for IGMP/MLD messages in the deployment
   environment and SHOULD avoid making critical service decisions solely
   on the basis of unauthenticated eco-mode information.

   Operationally, eco-mode is a preference signal and not a guarantee
   that a specific energy-saving action will be applied.  Operators
   SHOULD define local policy for handling conflicts between receiver
   preferences, service requirements, application constraints, and
   energy management objectives.  For example, if receivers of the same
   group signal different Eco-Level values, the network or service
   controller needs to determine whether to provide a common
   representation, split the service into multiple groups, ignore some
   preferences, or apply an operator-defined default.  Such conflict
   resolution is deployment specific and outside the scope of this
   document.

   Operators SHOULD also ensure that eco-mode policies are observable.
   At minimum, the network should be able to determine whether eco-mode
   information was received, whether it was acted upon, and what policy
   outcome was applied.  This is necessary to make eco-mode
   operationally meaningful and to avoid situations where receivers
   signal eco-mode but no measurable energy-related action is taken.

6.  IANA Considerations

   This document defines a new extension to IGMPv3 and MLDv2 messages
   according to [RFC9279].  IANA is requested to allocate the following
   extension type to the registry.

Contreras, et al.        Expires 7 January 2027                [Page 11]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

          +================+==========+==============+===============+
          | Extension Type | Length   | Name         | Reference     |
          +================+==========+==============+===============+
          | TBD            | 4        | Eco-mode     | This document |
          +----------------+----------+--------------+---------------+

   The following sub-registry is requested for Eco-Level values:

          +=======+====================+===============+
          | Value | Name               | Reference     |
          +=======+====================+===============+
          | 0     | Normal delivery    | This document |
          | 1     | Basic eco-mode     | This document |
          | 2     | Enhanced eco-mode  | This document |
          | 3     | Maximum eco-mode   | This document |
          | 4-255 | Unassigned         | This document |
          +-------+--------------------+---------------+

   The following sub-registry is requested for Preference values:

          +=======+================================+===============+
          | Value | Name                           | Reference     |
          +=======+================================+===============+
          | 0     | Generic energy saving          | This document |
          | 1     | Carbon saving                  | This document |
          | 2     | Renewable or lower-carbon use  | This document |
          | 3     | Operator defined               | This document |
          | 4-255 | Unassigned                     | This document |
          +-------+--------------------------------+---------------+

7.  Informative References

   [I-D.ietf-green-framework]
              Claise, B., Contreras, L. M., Lindblad, J., Palmero, M.
              P., Stephan, E., and Q. Wu, "Framework for Energy
              Efficiency Management", Work in Progress, Internet-Draft,
              draft-ietf-green-framework-02, 5 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-green-
              framework-02>.

   [RFC9279]  Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda,
              "Internet Group Management Protocol Version 3 (IGMPv3) and
              Multicast Listener Discovery Version 2 (MLDv2) Message
              Extension", RFC 9279, DOI 10.17487/RFC9279, August 2022,
              <https://www.rfc-editor.org/info/rfc9279>.

Contreras, et al.        Expires 7 January 2027                [Page 12]
Internet-Draft              IGMP/MLD Eco Mode                  July 2026

Acknowledgements

   This work has been partially funded by the EXIGENCE project, co-
   funded via the Smart Networks and Services Joint Undertaking (SNS JU)
   under the European Union's Horizon Europe research and innovation
   program under Grant Agreement No. 101139120.

Authors' Addresses

   Luis M. Contreras
   Telefonica
   Ronda de la Comunicacion, s/n
   28050 Madrid
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com
   URI:   http://lmcontreras.com

   Marisol Palmero
   Independent
   Spain
   Email: marisol.ietf@gmail.com

   Benjamin Schwarz
   CTOiC
   89, rue des Poissonniers
   Paris
   France
   Email: bs@ctoic.net

Contreras, et al.        Expires 7 January 2027                [Page 13]