Internet-Draft Structured Flow Label March 2022
Filsfils, et al. Expires 8 September 2022 [Page]
6437 (if approved)
Intended Status:
Standards Track
C. Filsfils, Ed.
Cisco Systems, Inc.
A. Abdelsalam, Ed.
Cisco Systems, Inc.
S. Zadok
X. Xu
W. Cheng
China Mobile
D. Voyer
Bell Canada
P. Camarillo
Cisco Systems, Inc.

Structured Flow Label


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.

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

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.

Table of Contents

1. Introduction

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.

2. Structured Flow Label Format

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


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.

4. Seamless Migration from RFC6437

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.

5. Benefits

6. IPv6 End-to-End Absolute Loss Measurements

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].

7. Programmed Sampling of packets

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].

8. Postcard-based Telemetry using packet Marking (PBT-M)

This section describes the usage of FLC bits to enable packet marking for PBT-M [].

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 [].

9. Acknowledgements


10. References

10.1. Normative References

Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, , <>.

10.2. Informative References

Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, T., Li, Z., Shin, J., and K. Lee, "In-Situ OAM Marking-based Direct Export", Work in Progress, Internet-Draft, draft-song-ippm-postcard-based-telemetry-11, , <>.
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, , <>.
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <>.
Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, , <>.

Appendix A. Entropy

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:

Authors' Addresses

Clarence Filsfils (editor)
Cisco Systems, Inc.
Ahmed Abdelsalam (editor)
Cisco Systems, Inc.
Shay Zadok
Xiaohu Xu
Weiqiang Cheng
China Mobile
Daniel Voyer
Bell Canada
Pablo Camarillo Garvia
Cisco Systems, Inc.