Measurement Method for Bandwidth of SRv6 Forwarding Path
draft-liu-spring-srv6-bandwidth-measurement-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Yisong Liu , Changwang Lin , Yuanxiang Qiu | ||
| Last updated | 2024-04-29 | ||
| RFC stream | (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-spring-srv6-bandwidth-measurement-00
SPRING Working Group Y. Liu
Internet Draft China Mobile
Intended status: Standards Track C. Lin
Expires: October 30, 2024 New H3C Technologies
Y. Qiu
New H3C Technologies
April 29, 2024
Measurement Method for Bandwidth of SRv6 Forwarding Path
draft-liu-spring-srv6-bandwidth-measurement-00
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 30, 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
(http://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
Liu, et al. Expires October, 2024 [Page 1]
Internet-Draft SRv6 Path Bandwidth Measurement April 2024
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
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 head node and
controller can obtain the actual minimum available bandwidth of the
forwarding path in real-time.
Table of Contents
1. Introduction ................................................ 3
2. Terminology ................................................. 3
3. Bandwidth Measurement Operation ............................. 4
3.1. The Processing Flow of Head Node ....................... 4
3.2. The Processing Flow of intermediate Node ............... 5
3.3. The Processing Flow of Egress Node ..................... 5
4. Definition of Minimum Available Bandwidth Option ............ 6
5. Definition of Minimum Available Bandwidth TLV ............... 7
6. Usecases of Bandwidth Measurement ........................... 7
7. IANA Considerations ......................................... 9
7.1. Destination Options and Hop-by-Hop Options Registry .... 9
7.2. Segment Routing Header TLVs Registry ................... 9
7.3. STAMP TLV Types Registry ............................... 9
8. Security Considerations ..................................... 9
9. References ................................................. 10
9.1. Normative References .................................. 10
9.2. Informative References ................................ 10
10. Acknowledgments ........................................... 10
Authors' Addresses ............................................ 11
Liu, et al. Expires October, 2024 [Page 2]
Internet-Draft SRv6 Path Bandwidth Measurement April 2024
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].
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 head 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 paths. 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 head 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 head 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].
Liu, et al. Expires October, 2024 [Page 3]
Internet-Draft SRv6 Path Bandwidth Measurement April 2024
3. Bandwidth Measurement Operation
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.
This minimum bandwidth information is carried over IPv6 extension
header in a compare-and-replace manner across network devices along
the path.
When the egress node 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 egress node can reflect the head
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 Head Node
The head 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 head node needs to add an IPv6
extension header with the Minimum Available Bandwidth Option when
encapsulating SRv6 header.
Initially, the head node fills in the minimum available bandwidth
field as the minimum available bandwidth of the path on the head
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 head node should encapsulate the Minimum
Available Bandwidth Option in HBH. If only the minimum bandwidth of
each segment node 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 October, 2024 [Page 4]
Internet-Draft SRv6 Path Bandwidth Measurement April 2024
3.2. The Processing Flow of intermediate Node
After receiving the packet, the 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 node according to the
updated IPv6 packet.
3.3. The Processing Flow of Egress Node
After the 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
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 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 head node. The encapsulation
format of the reflection packet is outside the scope of this
document.
Liu, et al. Expires October, 2024 [Page 5]
Internet-Draft SRv6 Path Bandwidth Measurement April 2024
4. Definition of 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.
- Reserved: 16 bits. MUST be 0 on transmission.
Liu, et al. Expires October, 2024 [Page 6]
Internet-Draft SRv6 Path Bandwidth Measurement April 2024
5. Definition of 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 SR
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.
6. 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 head node A.
Liu, et al. Expires October, 2024 [Page 7]
Internet-Draft SRv6 Path Bandwidth Measurement April 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 October, 2024 [Page 8]
Internet-Draft SRv6 Path Bandwidth Measurement April 2024
bandwidth of the active candidate path becomes less than 150Mbps,
and the service traffic can be switched to CP2.
7. IANA Considerations
7.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 |
+-------+-----------------------------------+---------------+
7.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 |
+-------+----------------------------------+----------------+
7.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 |
+-------+----------------------------------+----------------+
8. 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 October, 2024 [Page 9]
Internet-Draft SRv6 Path Bandwidth Measurement April 2024
9. References
9.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>.
[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>.
9.2. Informative References
TBD
10. Acknowledgments
The authors would like to thank the following for their valuable
contributions of this document:
TBD
Liu, et al. Expires October, 2024 [Page 10]
Internet-Draft SRv6 Path Bandwidth Measurement April 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
Liu, et al. Expires October, 2024 [Page 11]