A Power Conserving Path Placement Strategy (PCPPS)
draft-many-teas-power-steering-01

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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [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, <https://www.rfc-editor.org/rfc/rfc4657>.

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, <https://www.rfc-editor.org/rfc/rfc8174>.

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, <https://datatracker.ietf.org/doc/html/
              draft-many-lsr-power-group-02>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/rfc/rfc3031>.

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]