| Internet-Draft | Structured Flow Label | March 2022 |
| Filsfils, et al. | Expires 8 September 2022 | [Page] |
This document defines the IPv6 Structured Flow Label. The seamless nature of the change to [RFC6437] is demonstrated. Benefits of the solution are explained. Use-cases are illustrated.¶
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 8 September 2022.¶
Copyright (c) 2022 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.¶
The IPv6 header [RFC8200] contains a 20-bit field called "Flow Label" (FL) where the left-most bit is number 19 and the right-most bit is number0.¶
1 0
9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Flow Label
¶
The FL usage is specified in [RFC6437], briefly for entropy purpose.¶
Instead of using FL as a single 20-bit entropy structure, this document updates [RFC6437] and defines the 20-bit FL field as a structure of two fields:¶
This document shows that updating [RFC6437] is a seamless migration operation, simply because a majority of chipsets deployed in the Internet and private domains do not use FL as documented in [RFC6437]: they use a subset of the 20 bits of the FL as entropy, i.e. as documented in this document.¶
This document further shows that even if a chipset were to use the full FL as a 20-bit entropy input for ECMP hash, then the change proposed in this document would not cause any significant backward incompatibility.¶
The seamless nature of the change being explained, the document then explains the benefits of the Structured Flow Label definition. Three use-cases are provided. Several more are expected in the future in separate documents.¶
We define the Structured Flow Label as shown in Figure 2¶
1 0
9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FLC | FLE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Structured Flow Label Format
¶
Where:¶
[19, 16]: per-packet Control not included in ECMP hash¶
[15, 0]: per-flow Entropy included in ECMP hash¶
FLE is defined as per [RFC6437]: i.e. [RFC6437] is strictly preserved, the only change is that it defines the usage of the 16 low-order bits [15, 0] instead of the full 20-bit of the Flow Label.¶
FLC is defined as follows: the 4-bit FLC field in the IPv6 header is used by the network for group-based policy marking. The value of the FLC bits in a received packet or fragment might be different from the value sent by the packet's source. FLC is not included in the ECMP hash computation. The definition of FLC is modeled on the definition of the "Traffic Class" [RFC8200].¶
In the same way that "Traffic Class" is not an input for ECMP hash, FLC is not an input for ECMP hash.¶
This section provides design recommendation of how customer packets are being forwarded within an operator network.¶
All customer packets are typically encapsulated at the edge of the operator network as illustrated in Figure 3.¶
+------------------------------------------+
| Operator IPv6 network |
| |
+---+ +-+--+ +------+ +-----+ +-+--+ +---+
| A |<>-<>| R1 |<>-----<>| R2 |<>---<>| R3 |<>--<>| R4 |<>-<>| Z |
+---+ +-+--+ +------+ +-----+ +-+--+ +---+
| +--------+ +--------+ +--------+ |
| | IP6(R1,| | IP6(R1,| | IP6(R1,| |
| | R4,| | R4,| | R4,| |
| | FL)| | FL)| | FL)| |
+--------+ | +--------+ +--------+ +--------+ | +--------+
|Pkt(A,Z)| | |Pkt(A,Z)| |Pkt(A,Z)| |Pkt(A,Z)| | |Pkt(A,Z)|
+--------+ | +--------+ +--------+ +--------+ | +--------+
| |
+------------------------------------------+
Figure 3: Packet forwarding within operator IPv6 network
¶
When a customer packet is received at the edge router (R1) of operator IPv6 network, the packet is encapsulated using an outer IPv6 header. The outer IPv6 header defines the source edge router that encapsulates the packet (R1) and the destination edge router (R4) which has to decapsulate the packet before being forwarded towards its final destination.¶
R1 also sets the Flow Label (FL) of the outer IPv6 header which is computed based on the hash of the customer packet. Every subsequent router (R2 and R3) within the operator network forwards the packet based on the information of the outer IPv6 header.¶
For example, ECMP hash calculation on routers R2 and R3 is performed using the outer IPv6 header information (R1, R4, FL).¶
Cisco and Broadcom report that the norm for their products:¶
The authors believe that the same is likely for other vendors and are gathering data for future versions of this document.¶
Even if a chipset were to use the 4 most-specific bits of the FL field as input for ECMP hash while the 4-most specific bits of the FL field were used by other nodes in the network as FLC semantics (hence, per-packet marking, potentially not per-flow constant), still the impact would not be significant. Let us take an example to illustrate this.¶
Let us assume that:¶
We can have the following two scenarios:¶
Scenario-1: Routers compliant to this document¶
These routers will only use FLE for ECMP decision and hence all packets of flow F will be routed on the same path.¶
Scenario-2: Routers implementing RFC6437¶
These routers will use the full 20-bit (FLC+FLE) for ECMP decision. This could (but not always) lead to having S1 packets taking a different path from the ones of S2.¶
However, the scenario-2 is unlikely as per the chipset implementation reported in this doc.¶
FLC of 4 bits provides up to 200 to 400% improvement packet marking capability for operator controlled use-cases¶
Several use-cases will illustrate the usage of these FLC bits:¶
This section describes the usage of FLC bits to enable packet loss measurements [RFC8321] for IPv6 networks. We re-use the same reference topology from RFC8321 for our illustration (Figure 4).¶
+-------+ +------+ +-------+ +-------+
--<>| R1 |<>----<>| R2 |<>----<>| R3 |<>----<>| R4 |<>---
+-------+ +------+ +-------+ +-------+
. .
. End-to-End Loss .
<----------------------------------------->
Figure 4: End-to-End Absolute Loss Measurement
¶
In order for an operator to enable End-to-End packet loss measurements between routers R1 and R4 for a given flow:¶
The flow selection, flow identification, counters update, counters collection and counters correlation considerations are out of the scope of this doc. They can be realized using the techniques described in [RFC8321].¶
An operator can detect End-to-End packet loss by deploying the solution described in Section 6}.¶
In some cases, the operator needs to identify the node(s) or the link(s) where the packet loss happens. In order to so, the operator would need to collect packet loss measurement from each hop on the packet path. Figure 4 shows the combination of End-to-End and per-hop measurements.¶
+------+ +-------+ +-------+ +-------+
--<>| R1 |<>----<>| R2 |<>----<>| R3 |<>-----<>| R4 |<>---
+------+ +-------+ +-------+ +-------+
. . . . .
. . . . .
. <-------> <--------->
. Node Loss Link Loss
. .
. End-to-End Loss .
<------------------------------------------->
Figure 5: End-to-End and Per-Hop Loss Measurements
¶
If the operator detects End-to-End packet loss, it will do the following:¶
The SDN controller aspects, flow sampling, flow selection, flow identification, counters update, counters collection and counters correlation considerations are out of the scope of this doc. Some of these considerations can be realized using the techniques described in [RFC8321].¶
This section describes the usage of FLC bits to enable packet marking for PBT-M [I-D.song-ippm-postcard-based-telemetry].¶
PBT-M enables each router along the packet path exports its telemetry data to the telemetry collector in the form of postcards as illustrated in Figure 6. In PBT-M a single bit is needed to mark the packet which then matched by each node to trigger telemetry export from intermediate routers.¶
+-----------------------+
+------------>| Telemetry Collector |<--------------+
| +-----------------------+ |
| ^ ^ |
| Postcard | Postcard | Postcard | Postcard
| | | |
+------+ +------+ +------+ +------+
--<>| R1 |<>----<>| R2 |<>-----<>| R3 |<>-----<>| R4 |<>---
+------+ +------+ +------+ +------+
Figure 6: Postcard-Based Telemetry using packet Marking (PBT-M)
¶
An operator that wants to deploy PBT-M, can do the following:¶
The SDN controller aspects, flow sampling, flow selection, flow identification, postcard generation, postcard collection and postcard correlation and postcard processing considerations are out of the scope of this doc. Some of these considerations are defined in [I-D.song-ippm-postcard-based-telemetry].¶
TBD¶
Section 5.1.1 of [RFC8085] discusses the usage of UDP for Source Port Entropy and states that 14 bits of Entropy are sufficient for most ECMP applications:¶