Skip to main content

Measurement Method for Bandwidth of SRv6 Forwarding Path
draft-liu-ippm-srv6-bandwidth-measurement-00

Document Type Active Internet-Draft (individual)
Authors Yisong Liu , Changwang Lin , Yuanxiang Qiu , Yao Liu , Yanrong Liang
Last updated 2024-11-26
Replaces draft-liu-spring-srv6-bandwidth-measurement
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-ippm-srv6-bandwidth-measurement-00
IPPM Working Group                                           Yisong Liu
Internet Draft                                             China Mobile
Intended status: Standards Track                                 C. Lin
Expires: May 26, 2025                              New H3C Technologies
                                                                 Y. Qiu
                                                   New H3C Technologies
                                                                Yao Liu
                                                        ZTE Corporation
                                                               Y. Liang
                                                        Ruijie Networks
                                                      November 26, 2024

          Measurement Method for Bandwidth of SRv6 Forwarding Path
               draft-liu-ippm-srv6-bandwidth-measurement-00

Abstract

   This document proposes a method for measuring the actual bandwidth
   of SRv6 forwarding paths. Carrying the bandwidth information from
   bottleneck nodes along the packet path in the IPv6 extension header
   of data packets or active measurement packets, the SRv6 headend node
   and controller can obtain the actual minimum available bandwidth of
   the forwarding path in real-time.

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 May 26, 2025.

Liu, et al.              Expires May, 2025                     [Page 1]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Revised BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Revised BSD License.

Table of Contents

   1. Introduction...................................................2
   2. Terminology....................................................3
      2.1. Requirements Language.....................................3
   3. Bandwidth Measurement Mechanism................................4
      3.1. The Processing Flow of SRv6 Headend Node..................4
      3.2. The Processing Flow of SRv6 Intermediate Node.............5
      3.3. The Processing Flow of SRv6 Egress Node...................5
   4. Format Definition of Minimum Bandwidth Information.............6
      4.1. Minimum Available Bandwidth Option........................6
      4.2. Minimum Available Bandwidth TLV...........................7
   5. Usecases of Bandwidth Measurement..............................7
   6. IANA Considerations............................................9
      6.1. Destination Options and Hop-by-Hop Options Registry.......9
      6.2. Segment Routing Header TLVs Registry......................9
      6.3. STAMP TLV Types Registry..................................9
   7. Security Considerations........................................9
   8. References....................................................10
      8.1. Normative References.....................................10
      8.2. Informative References...................................10
   9. Acknowledgments...............................................11
   Authors' Addresses...............................................12

1. Introduction

   Segment routing (SR) [RFC8402] is a source routing paradigm that
   explicitly indicates the forwarding path for packets at the ingress
   node. The ingress node steers packets into a specific path according
   to the Segment Routing Policy (SR Policy) as defined in [RFC9256].

Liu, et al.               Expires May, 2025                   [Page 2]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

   An SR Policy may have multiple candidate paths that are provisioned
   on the head node. Only the active candidate path MUST be used for
   forwarding traffic that is being steered onto that policy except for
   certain scenarios such as fast reroute where a backup candidate path
   may be used. A candidate path can be represented as a segment list
   or a set of segment lists. If a set of segment lists is associated
   with the active path of the policy, then the steering is per flow
   and weighted-ECMP (W-ECMP) based according to the relative weight of
   each valid segment list.

   Due to the different services carried by each node on the segment
   list path, and the differences in device forwarding capabilities,
   certain nodes on the forwarding path may experience traffic
   congestion when the network traffic is high. The actual maximum
   forwarding traffic of this path will become smaller than expected.
   Once this situation occurs, if the SRv6 headend node does not adjust
   the forwarding path in a timely manner and continues to forward to
   the SR policy path according to the initial preset bandwidth, it
   will inevitably cause packet loss beyond the bandwidth.

   To solve this problem, this document proposes a method for measuring
   the actual bandwidth of SRv6 forwarding path. Carrying the bandwidth
   information from bottleneck nodes along the packet path in the IPv6
   extension header of data packets or active performance measurement
   packets, the SRv6 headend node and controller can obtain the actual
   minimum available bandwidth of the forwarding path in real-time.

   When the actual available bandwidth or remaining bandwidth of the
   forwarding path does not meet the forwarding quality requirements,
   the controller or SRv6 headend node can quickly perceive and select
   a new path for the service traffic.

2. Terminology

   The definitions of the basic terms are identical to those found in
   Segment Routing Policy Architecture [RFC9256] and Simple Two-Way
   Active Measurement Protocol [RFC8762].

2.1. Requirements Language

   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
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Liu, et al.               Expires May, 2025                   [Page 3]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

3. Bandwidth Measurement Mechanism

   Add Minimum Available Bandwidth Option for IPv6 extension headers to
   carry the minimum bandwidth information of the SRv6 forwarding path.
   The format of Minimum Available Bandwidth Option is detailed in
   Section 4.1.

   This minimum bandwidth information is carried over IPv6 extension
   header in a compare-and-replace manner across network devices along
   the path.

   When the SRv6 egress endpoint receives the message carrying
   bandwidth information, it parses the bandwidth field to obtain the
   actual minimum available bandwidth of the path. If it is an active
   measurement message of RTT, the SRv6 egress endpoint can reflect the
   SRv6 headend node of the minimum available bandwidth in the
   reflection packet of active performance measurement. Otherwise, the
   measurement results can also be reported to the controller.

3.1. The Processing Flow of SRv6 Headend Node

   The SRv6 headend node needs to add SRv6 encapsulation to the data
   packets forwarded through the SR policy path or the active
   performance measurement packets of the SR policy path. After
   enabling the bandwidth measurement function, the SRv6 headend node
   needs to add an IPv6 extension header with the Minimum Available
   Bandwidth Option when encapsulating SRv6 header.

   Initially, the SRv6 headend node fills in the minimum available
   bandwidth field as the minimum available bandwidth of the path on
   the SRv6 headend node.

   The Minimum Available Bandwidth Option can be encapsulated in the
   Hop-by-Hop Options header (HBH), in the Destination Options header
   (DoH), or in the SRH TLV. The specific encapsulation position is
   determined based on measurement requirements.

   If the minimum available bandwidth of all IPv6 nodes passing through
   needs to be measured, the SRv6 headend node should encapsulate the
   Minimum Available Bandwidth Option in HBH. If only the minimum
   bandwidth of each segment endpoint on the SRv6 path needs to be
   measured, it is recommended to encapsulate the Minimum Available
   Bandwidth Option in DOH or in SRH TLV.

Liu, et al.               Expires May, 2025                   [Page 4]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

3.2. The Processing Flow of SRv6 Intermediate Node

   After receiving the packet, the SRv6 intermediate node parses the
   bandwidth value carried in IPv6 extension header and compares it
   with the actual bandwidth supported locally.

   If the local available bandwidth is smaller than the bandwidth value
   carried in the option, replace the bandwidth value in the option
   with the local available bandwidth. If the local available bandwidth
   is greater than or equal to the bandwidth value carried in the
   packet, the bandwidth value in the packet will not be modified.

   Afterwards, send the message to the next SRv6 endpoint according to
   the updated IPv6 packet.

3.3. The Processing Flow of SRv6 Egress Node

   After the SRv6 egress node receives the packet, before removing the
   SRv6 encapsulation, it needs to first parses the bandwidth value
   carried in the IPv6 extension header and compare it with the actual
   bandwidth supported locally.

   If the local available bandwidth is smaller than the bandwidth
   carried in the message, the local available bandwidth is used as the
   minimum available bandwidth for the SRv6 forwarding path. Otherwise,
   the minimum available bandwidth of the SRv6 forwarding path is the
   value obtained from the packet.

   After obtaining the minimum available bandwidth of the path, the
   SRv6 egress node also needs to reflect the measurement results.
   There are following reflect methods:

   1) The measurement results are reported to the controller through
      Netconf or gRPC.

   2) If it is an active measurement message of RTT, the SRv6 egress
      node needs to send reflection packets to the head node. So, extend
      the active measurement response message and carry the actual
      bandwidth obtained in the reflection packet.

      For example, when measuring the performance of SRv6 paths through
      STAMP testing, extend the STAMP TLV (see Section 5) and bring back
      the bandwidth of the forward path in the TLV.

   3) Customize an IP packet that carries the measured bandwidth
      information and sends it to the SRv6 headend node. The
      encapsulation format of the reflection packet is outside the scope
      of this document.

Liu, et al.               Expires May, 2025                   [Page 5]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

4. Format Definition of Minimum Bandwidth Information

4.1. Minimum Available Bandwidth Option

   Minimum Available Bandwidth Option in the Hop-by-Hop Options Header
   and Destination Options Header is defined to carry the actual
   minimum available bandwidth of the SRv6 forwarding path. The
   encapsulation format in DOH and HBH 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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   | Option Type   |  Opt Data Len |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Minimum available bandwidth                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 1: Minimum Available Bandwidth Option
   where:

   - Option Type: 8-bit identifier of the type. The encoding format
      references Section 4.2 of [RFC8200]. The value is to be assigned
      by IANA.

   - Opt Data Len: The length of the Option Data Fields of this option
      in bytes.

   - Minimum available bandwidth: 4-octet unsigned integer. The field
      is used to carry the minimum bandwidth value.

   The Minimum Available Bandwidth Option also can be encapsulated in
   the SRH TLV. The encapsulation format in SRH TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length   |           Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Minimum available bandwidth                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 2: Minimum Available Bandwidth TLV
   Where:

   - Type: TBA

   - Length: 4

   - Minimum available bandwidth: 4-octet unsigned integer. The field
      is used to carry the minimum bandwidth value.

Liu, et al.               Expires May, 2025                   [Page 6]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

   - Reserved: 16 bits. MUST be 0 on transmission.

4.2. Minimum Available Bandwidth TLV

   Minimum Available Bandwidth TLV is defined to carry the actual
   minimum available bandwidth of the SR forwarding path in the STAMP
   reflection packet. The encapsulation format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |STAMP TLV Flags|    Type=TBA   |         Length=4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Minimum available bandwidth                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 3: STAMP Minimum Available Bandwidth TLV
   Where:

   - STAMP TLV Flags: The STAMP TLV Flags follow the procedures
      described in [RFC8972] and this document.

   - Type: Type (value TBA) for the Minimum Available Bandwidth TLV.

   - Length: A 2-octet field equal to the length of the bandwidth
      field.

   - Minimum available bandwidth: 4-octet unsigned integer. The field
      is used to carry the minimum bandwidth value.

   If the STAMP session reflector supports bandwidth measurement
   function, after obtaining the minimum available bandwidth of the
   SRv6 forwarding path, the Minimum Available Bandwidth TLV must be
   encapsulated in the reflection packet and the U Flag [RFC8972] MUST
   be set to 1. Otherwise, this TLV MUST NOT be carried in the
   reflection packet.

5. Usecases of Bandwidth Measurement

   Taking the SRv6 policy multipath scenario shown in Figure 4 as an
   example, for the traffic from node A to node E, the controller
   issues two candidate paths CP1 and CP2 to SRv6 headend node A.

Liu, et al.               Expires May, 2025                   [Page 7]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

         +-----+                             +-----+
         |     |                             |     |
         |  G  +--------+                 +--+  H  |
         |     |        |                 |  |     |
         +--+--+     +--+--+              |  +-----+
                     |     |              |
            +--------+  B  +--------------------+
            |        |     +--------+     |     |
            |        +-----+        |     |     |
         +--+--+     +-----+     +--+--+  |  +--+--+
         |     |     |     |     |     +--+  |     |
         |  A  +-----+  C  +-----+  D  +-----+  E  |
         |     |     |     |     |     |     |     |
         +--+--+     +--+--+     +-----+     +--+--+
     Ingress|           |        +-----+        | Egress
      Node  |           +--------+     |        |  Node
            +--------------------+  F  +--------+
                                 |     |
                                 +-----+
                          Figure 4: SRv6 Network

     SR Policy POL1
       Candidate Path CP1
         Preference 200
         Segment List 11 <SID-A,SID-B,SID-E>, Weight 1, 100M
         Segment List 12 <SID-A,SID-B,SID-D,SID-E>, Weight 1, 100M
       Candidate Path CP2
         Preference 100
         Segment List 21 <SID-A,SID-C,SID-F,SID-E>, Weight 1, 100M
         Segment List 22 <SID-A,SID-F,SID-E>, Weight 1, 100M

   The preset bandwidth for the segment list paths of CP1 and CP2 is
   100Mbps. CP1 is the active candidate path, and CP2 is the backup.
   Normally, CP1 can forward 200Mbps traffic. If the active candidate
   path has traffic congestion and no longer meets forwarding
   requirements (The bandwidth must be greater than 150Mbps), it is
   necessary to promptly sense and switch to the backup candidate path.

   For this requirement, the available bandwidth measurement function
   can be enabled on the SRv6 policy.

   Because the traffic from node G to node H also passes through nodes
   B and D. If the traffic from node G to node H is relatively high,
   the link between node B and node D will be traffic congestion. For
   example, there is traffic congestion on node D. The actual available
   bandwidth of node D drops to below 50Mbps, that is, the available

Liu, et al.               Expires May, 2025                   [Page 8]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

   bandwidth of the active candidate path becomes less than 150Mbps,
   and the service traffic can be switched to CP2.

6. IANA Considerations

6.1. Destination Options and Hop-by-Hop Options Registry

   IANA has allocated a value for the Minimum Available Bandwidth
   Option Type from the IETF Review TLV range in the "Destination
   Options and Hop-by-Hop Options" registry [RFC8200] as follows.

     +=======+===================================+===============+
     | Value | Description                       |   Reference   |
     +=======+===================================+===============+
     | TBA   | Minimum Available Bandwidth Option| This document |
     +-------+-----------------------------------+---------------+

6.2. Segment Routing Header TLVs Registry

   IANA has allocated a value for the Minimum Available Bandwidth TLV
   Type from the IETF Review TLV range in the "Segment Routing Header
   TLVs" registry [RFC8754] as follows.

     +=======+==================================+================+
     | Value | Description                      |   Reference    |
     +=======+==================================+================+
     | TBA   | Minimum Available Bandwidth TLV  | This document  |
     +-------+----------------------------------+----------------+

6.3. STAMP TLV Types Registry

   IANA has allocated a value for the Minimum Available Bandwidth TLV
   Type from the IETF Review TLV range in the "STAMP TLV Types"
   registry [RFC8972] as follows.

     +=======+==================================+================+
     | Value | Description                      |   Reference    |
     +=======+==================================+================+
     | TBA   | Minimum Available Bandwidth TLV  | This document  |
     +-------+----------------------------------+----------------+
7. Security Considerations

   This document does not introduce any security considerations. The
   security considerations specified in [RFC8762] and [RFC8972] also
   apply to the extensions defined in this document.

Liu, et al.               Expires May, 2025                   [Page 9]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

8. References

8.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/info/rfc2119>.

   [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/info/rfc8174>.

   [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version
             6(IPv6) Specification", STD 86, RFC 8200, DOI
             10.17487/RFC8200, July 2017, <https://www.rfc-
             editor.org/info/rfc8200>.

   [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
             Decraene, B., Litkowski, S., and R. Shakir, "Segment
             Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
             July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8754] Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
             Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
             (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
             <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
             Two-Way Active Measurement Protocol", RFC 8762, DOI
             10.17487/RFC8762, March 2020, <https://www.rfc-
             editor.org/info/rfc8762>.

   [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
             and E. Ruffini, "Simple Two-Way Active Measurement
             Protocol Optional Extensions", RFC 8972, DOI
             10.17487/RFC8972, January 2021, <https://www.rfc-
             editor.org/info/rfc8972>.

   [RFC9256] Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
             P. Mattes, "Segment Routing Policy Architecture", RFC
             9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-
             editor.org/info/rfc9256>.

8.2. Informative References

   TBD

Liu, et al.               Expires May, 2025                  [Page 10]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

  9. Acknowledgments

   The authors would like to thank the following for their valuable
   contributions of this document:

   TBD

Liu, et al.               Expires May, 2025                  [Page 11]
Internet-Draft     SRv6 Path Bandwidth Measurement        November 2024

Authors' Addresses

   Yisong Liu
   China Mobile
   Beijing
   China

   Email: liuyisong@chinamobile.com

   Changwang Lin
   New H3C Technologies
   Beijing
   China

   Email: linchangwang.04414@h3c.com

   Yuanxiang Qiu
   New H3C Technologies
   Beijing
   China

   Email: qiuyuanxiang@h3c.com

   Yao Liu
   ZTE Corporation
   China

   Email: liu.yao71@zte.com.cn

   Yanrong Liang
   Ruijie Networks
   China

   Email: liangyanrong@ruijie.com.cn

Liu, et al.               Expires May, 2025                  [Page 12]