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