TEAS WG C. Barth Internet-Draft T. Li Intended status: Standards Track V. P. Beeram Expires: 24 December 2026 R. Bonica HPE 22 June 2026 A Power Conserving Path Placement Strategy (PCPPS) draft-many-teas-power-steering-01 Abstract Many networks have a daily utilization pattern. For example, a network might be busy during the day and less busy at night. If the network is robust, it has enough capacity to satisfy demand during peak hours and excess capacity during non-peak hours. That excess capacity increases energy costs and environmental impact. This document introduces a Power Conserving Path Placement Strategy (PCPPS). When possible, PCPPS concentrates traffic onto a small set of network resources. When traffic is concentrated onto a small set of network resources, other network resources become idle and can be powered down until they are needed again. This solves the problem of excess capacity during non-peak hours. 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 24 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Barth, et al. Expires 24 December 2026 [Page 1] Internet-Draft PCPPS June 2026 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Constraint-based Shortest Path Forwarding (CSPF) . . . . . . 4 5. PCPPS and CSPF . . . . . . . . . . . . . . . . . . . . . . . 4 6. The PCPPS Metric . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Power-Sleep Capability . . . . . . . . . . . . . . . . . 5 6.2. Power Groups . . . . . . . . . . . . . . . . . . . . . . 5 6.3. Interface Power Savings Potential (PSP) . . . . . . . . . 5 6.4. Unidirectional Sleeping Bandwidth . . . . . . . . . . . . 6 7. Recovering Bandwidth . . . . . . . . . . . . . . . . . . . . 6 8. Power Groups . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Example Architecture . . . . . . . . . . . . . . . . . . 6 8.2. Definition . . . . . . . . . . . . . . . . . . . . . . . 8 8.3. Interfaces and Power Groups . . . . . . . . . . . . . . . 10 8.4. Power-Sleep Capability and Power Group Hierarchies . . . 10 9. Operational Considerations . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Many networks have a daily utilization pattern. For example, a network might be busy during the day and less busy at night. If the network is robust, it has enough capacity to satisfy demand during peak hours and excess capacity during non-peak hours. That excess capacity increases energy costs and environmental impact. This document introduces a Power Conserving Path Placement Strategy (PCPPS). When possible, PCPPS concentrates traffic onto a small set of network resources. When traffic is concentrated onto a small set Barth, et al. Expires 24 December 2026 [Page 2] Internet-Draft PCPPS June 2026 of network resources, other network resources become idle and can be powered down until they are needed again. This solves the problem of excess capacity during non-peak hours. Network operators can control the degree to which traffic is concentrated onto a small set of network resources. They can configure constraints that prevent traffic flows from being assigned to a path that does not satisfy their requirements. They can also configure the degree to which power conservation is prioritized in path placement. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology This document uses the following terms: * Path - An ordered set of links that connect a source node to a destination node. In a robust network, there are many paths from a particular source to a particular destination. * Traffic flow - A set of packets that have the same source and destination, and traverse the same path. Packets on an MPLS [RFC3031] Label Switched Path (LSP) are an example of a traffic flow. * Constraint - A rule that prevents a traffic flow from traversing some set of paths. For example, a constraint might prevent a particular traffic flow from traversing a path that contains low- speed links. * Optimization metric - The CSPF path placement algorithm uses the optimization metric to compute the best path between a source and a destination. An optimization metric is associated with the objective function [RFC4657] for which CSPF is optimizing (e.g., delay). * Sleeping bandwidth - Bandwidth on a link that is not currently available because the resources that support it have been powered down. This concept is useful for LAG adjacencies that have sleeping members. Barth, et al. Expires 24 December 2026 [Page 3] Internet-Draft PCPPS June 2026 * Sleep Status - An attribute of a hardware component. A component that is ASLEEP may consume power, but not enough to operate normally. A component that is AWAKE consumes enough power to operate normally. * Power Savings Potential (PSP) - The PSP for a component is the difference between power consumption while AWAKE and power consumption while ASLEEP. 4. Constraint-based Shortest Path Forwarding (CSPF) PCPPS leverages Constraint-based Shortest Path Forwarding (CSPF). CSPF can be centralized or distributed. When it is centralized, a Path Computation Element (PCE) calculates a path for every flow in the network. When it is distributed, each node calculates a path for each flow that originates on it. As stated in Section 3, many paths can connect a source node to a destination node. CSPF computes a path: * that does not violate any of the flow's constraints * whose links have sufficient unreserved bandwidth to support the flow * whose links have the lowest cumulative optimization metric CSPF requires the following inputs: * Information regarding traffic flows (e.g., source, destination, required bandwidth, constraints) * The network topology (i.e., nodes, node attributes, links, and link attributes) CSPF acquires this information from a Traffic Engineering Data Base (TED). Typically, an Interior Gateway Protocol (IGP) or the Border Gateway Protocol-Link State (BGP-LS) populates the TED. 5. PCPPS and CSPF As stated in Section 4, PCPPS leverages CSPF. However, when PCPPS leverages CSPF, it computes paths using a new metric, called the PCPPS metric. Section 6 describes the PCPPS metric. Barth, et al. Expires 24 December 2026 [Page 4] Internet-Draft PCPPS June 2026 Furthermore, when PCPPS leverages CSPF and CSPF cannot compute a path due to bandwidth scarcity, it can recover bandwidth by powering up network resources that were previously powered down. Section 7 describes inputs to the bandwidth recovery process. 6. The PCPPS Metric The PCPPS metric is a function of the optimization metric and a power penalty. The power penalty is computed using at least one of the parameters described in the subsections below. The formula that is used to compute the PCPPS metric is not subject to standardization and can vary from implementation to implementation. 6.1. Power-Sleep Capability Each TED interface entry includes a Power-Sleep Capability Bit. This bit determines whether the interface can be powered down when idle or nearly idle. For interfaces on the local node, this bit is administratively assigned and advertised by an IGP. For interfaces on a remote node, this bit is learned from an IGP. See [I-D.many-lsr-power-group]. If the interface is not power-sleep capable: * the PSP is equal to zero. * the optimization metric and PCPPS metric are equal. 6.2. Power Groups Each TED interface entry includes zero or more references to a Power Group. See Section 8 for a description of Power Groups. For Power Groups on the local node, this data is administratively assigned or learned from hardware. It is advertised by an IGP. For Power Groups on a remote node, this data is learned from an IGP. See [I-D.many-lsr-power-group]. 6.3. Interface Power Savings Potential (PSP) Each TED interface entry includes a PSP value, measured in milliwatts. This value represents the interface PSP. It does not include the PSPs of the Power Groups to which it is a member. Barth, et al. Expires 24 December 2026 [Page 5] Internet-Draft PCPPS June 2026 For interfaces on the local node, this value is administratively assigned or learned from hardware. It is advertised by an IGP. For interfaces on a remote node, this value is learned from an IGP. See [I-D.many-lsr-power-group]. 6.4. Unidirectional Sleeping Bandwidth Each TED interface entry includes a unidirectional sleeping bandwidth value, measured in bits per second. This value represents the sleeping bandwidth on a link. This is useful for LAG adjacencies that have sleeping members. For interfaces on the local node, this value is administratively assigned or learned from hardware. It is advertised by an IGP. For interfaces on a remote node, this value is learned from an IGP. See [I-D.many-lsr-power-group]. 7. Recovering Bandwidth When PCPPS cannot calculate a path due to bandwidth scarcity, it may wake up a sleeping link that might allow the path to be calculated. Therefore, the TED must include information regarding sleeping links. In the TED, sleeping links must be distinguishable from active links. On the local node, information regarding sleeping links is learned from hardware and advertised by an IGP. For remote nodes, information regarding sleeping links is learned from an IGP. See [I-D.many-lsr-power-group]. 8. Power Groups 8.1. Example Architecture Barth, et al. Expires 24 December 2026 [Page 6] Internet-Draft PCPPS June 2026 *------------* | LC1 | | 100 watts | *------------* / \ ------------- ------------- | | *------------* *------------* | FE1 | | FE2 | | 300 watts | | 300 watts | *------------* *------------* / \ / \ / \ / \ *----------* *----------* *----------* *----------* | INTCOMP1 | | INTCOMP2 | | INTCOMP3 | | INTCOMP4 | | 15 watts | | 20 watts | | 15 watts | | 20 watts | | 400 Gbps | | 800 Gbps | | 400 Gbps | | 800 Gbps | | (optics | | (no | | (optics | | (no | | included)| | optics) | | included)| | optics) | *----------* *----------* *----------* *----------* / \ | / \ | / \ | / \ | INT1 INT2 INT3 INT4 INT5 INT6 0 watts 0 watts 5 watts 0 watts 0 watts 5 watts No optics No optics Optics No optics No optics Optics Line Card 1 (LC1) consumes 100 watts Figure 1: Line Card 1 Figure 1 depicts a line card (LC1). LC1 contains two forwarding engines (FE1 and FE2) and four interface complexes (INTCOMP1 through INTCOMP4). INTCOMP1 supports two interfaces (INT1 and INT2). Likewise, INTCOMP3 supports two interfaces (INT4 and INT5). INTCOMP2 and INTCOMP4 support one interface each (INT3 and INT6). An interface complex includes PHY, MAC, encryption, gearbox, and other related circuitry. INTCOMP1 and INTCOMP3 also contain optics. INTCOMP2 and INTCOMP4 do not contain optics. Therefore, the interfaces that they support have their own optics. INTCOMP1 and INTCOMP3 provide 400 Gbps of forwarding capacity each, while INTCOMP2 and INTCOMP4 provide 800 Gbps of forwarding capacity each. Each hardware component has a PSP. LC1's PSP is 10 watts while FE1 and FE2 have PSPs of 300 watts. INTCOMP1 and INTCOMP3 have PSPs of 15 watts, while INTCOMP2 and INTCOMP4 have PSPs of 20 watts. INT3 Barth, et al. Expires 24 December 2026 [Page 7] Internet-Draft PCPPS June 2026 and INT6 contain optics that have PSPs of 5 watts. INT1, INT2, INT4 and INT5 do not have separate optics. Therefore, they have a PSP of 0 watts. INT1 and INT2 depend upon INTCOMP1. If INTCOMP1 fails, so do INT1 and INT2. Likewise, INT3 depends upon INTCOMP2. If INTCOMP2 fails, so does INT3. INTCOMP1 and INTCOMP2 depend on FE1. If FE1 fails, so do INTCOMP1, INTCOMP2, INT1, INT2, and INT3. Likewise, INTCOMP3 and INTCOMP4 depend on FE2. If FE2 fails, so do INTCOMP3, INTCOMP4, INT4, INT5, and INT6. FE1 and FE2 depend on LC1. If LC1 fails, so do all of the forwarding engines, interface complexes, and interfaces in the diagram. 8.2. Definition In Figure 1, LC1, FE1, FE2, INTCOMP1, INTCOMP2, INTCOMP3, and INTCOMP4 are all Power Groups. Each Power Group, except for LC1, has exactly one parent. LC1 does not have a parent. Many Power Groups can have the same parent. Each Power Group has one or more components and each component has a PSP. The PSP associated with a Power Group is equal to the sum of the PSPs associated with its components. A Power Group's PSP does not include the PSPs of its ancestors or its children. The parent-child relationship reflects dependency. One Power Group is the child of another if any one of the child components depends upon any one of the parent components. A network device's PSP characteristics can be described by any number of equivalent Power Group hierarchies. The paragraphs below demonstrate how two equivalent Power Group hierarchies can describe the PSP characteristics of the line card in Figure 1. Barth, et al. Expires 24 December 2026 [Page 8] Internet-Draft PCPPS June 2026 +============+========+===========+=====================+ | Identifier | Parent | PSP | Hardware Components | +============+========+===========+=====================+ | 1 | None | 100 watts | LC1 | +------------+--------+-----------+---------------------+ | 2 | 1 | 300 watts | FE1 | +------------+--------+-----------+---------------------+ | 3 | 1 | 300 watts | FE2 | +------------+--------+-----------+---------------------+ | 4 | 2 | 15 watts | INTCOMP1 | +------------+--------+-----------+---------------------+ | 5 | 2 | 20 watts | INTCOMP2 | +------------+--------+-----------+---------------------+ | 6 | 3 | 15 watts | INTCOMP3 | +------------+--------+-----------+---------------------+ | 7 | 3 | 20 watts | INTCOMP4 | +------------+--------+-----------+---------------------+ Table 1: A Granular Power Group Hierarchy Table 1 describes the PSP characteristics of the line card in Figure 1 using a granular Power Group hierarchy. We call it granular because each Power Group contains only one component. Therefore, each Power Group's PSP is equal to the PSP of its one and only component. +============+========+===========+=====================+ | Identifier | Parent | PSP | Hardware Components | +============+========+===========+=====================+ | 1 | None | 700 watts | LC1, FE1, FE2 | +------------+--------+-----------+---------------------+ | 2 | 1 | 15 watts | INTCOMP1 | +------------+--------+-----------+---------------------+ | 3 | 1 | 20 watts | INTCOMP2 | +------------+--------+-----------+---------------------+ | 4 | 1 | 15 watts | INTCOMP3 | +------------+--------+-----------+---------------------+ | 5 | 1 | 20 watts | INTCOMP4 | +------------+--------+-----------+---------------------+ Table 2: A Less Granular Power Group Hierarchy Table 2 describes the PSP characteristics of the line card in Figure 1 using a less granular Power Group hierarchy. We call it less granular because Power Group 1 contains three components (LC1, FE1 and FE2). Its PSP is equal to the sum of the PSPs of LC1, FE1 and FE2 (i.e., 700 watts). Barth, et al. Expires 24 December 2026 [Page 9] Internet-Draft PCPPS June 2026 Section 8.4 describes how a network device's power-sleep capability determines which of the equivalent Power Group hierarchies it should advertise. 8.3. Interfaces and Power Groups An interface is not part of a Power Group, even if it contains optics and consumes power. However, an interface can reference one or more Power Groups. When an interface references a Power Group, it MUST reference a Power Group that contains the hardware that supports it. Interfaces that reference the same Power Group share common hardware dependencies. Therefore, CSPF may treat them as a group, either diverting traffic flows away from them all or routing traffic flows through them all. A Link Aggregation Group (LAG) interface requires support from multiple interface complexes. Therefore a LAG interface references every Power Group that contains hardware that supports it. 8.4. Power-Sleep Capability and Power Group Hierarchies A network device SHOULD advertise the least granular Power Group hierarchy that can exercise its complete power-savings capability. Assume that a network contains line cards that are power-sleep capable. Those line cards contain forwarding engines and interface complexes that are also power-sleep capable. This means that the line cards, forwarding engines and interface complexes can be powered on and off independently of the chassis. In order to exercise its complete power savings capability, information regarding line card, forwarding engine and interface complex dependencies is required. Therefore, the line card must advertise the granular Power Group hierarchy in Table 1. Now assume that another network contains line cards that are power- sleep capable. Those line cards contain interface complexes that are also power-sleep capable. However, the forwarding engines are not power-sleep capable. In order to exercise its complete power savings capability, information regarding line card and interface complex dependencies is required. However, information regarding forwarding engine dependencies is not required. Therefore, the line card could advertise either the granular Power Group hierarchy in Table 1 or the less granular Power Group hierarchy in Table 2. Barth, et al. Expires 24 December 2026 [Page 10] Internet-Draft PCPPS June 2026 9. Operational Considerations Network operators must exercise care when configuring interfaces to be power-sleep capable. The network must maintain sufficient bandwidth and redundancy, even when all power-sleep capable interfaces are ASLEEP. Furthermore, interfaces that provide access to critical resources require special consideration. Critical resources include, but are not limited to, the following: * Network Management * Network Controllers * BGP Route Reflectors Putting an interface to sleep can cause protocol churn. For example, if an interface to the Designated Router (DR) on an multipoint interface is put to sleep, the backup DR becomes the DR. 10. Security Considerations TBD 11. IANA Considerations This document requires no IANA actions. 12. Acknowledgements Thanks to Joel Halpern and Carlos Pignataro for their reviews and helpful comments. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, . Barth, et al. Expires 24 December 2026 [Page 11] Internet-Draft PCPPS June 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [I-D.many-lsr-power-group] Barth, C., Li, T., Beeram, V. P., and R. P. Bonica, "Using IS-IS To Advertise Power Group Membership", Work in Progress, Internet-Draft, draft-many-lsr-power-group-02, 25 January 2026, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . Authors' Addresses Colby Barth HPE United States of America Email: Jonathan.barth@hpe.com Tony Li HPE United States of America Email: tony.li@tony.li Vishnu Pavan Beeram HPE United States of America Email: vbeeram@hpe.com Ron Bonica HPE United States of America Email: ronald.bonica@hpe.com Barth, et al. Expires 24 December 2026 [Page 12]