Title page

1
2
3
4
5

IEEE P802.1Qdw/D0.0
October 6, 2022

(Amendment to IEEE Std 802.1Q-2022 as amended byIEEE Std Qcz-2022, IEEE Std 802.1Qcw-2023, IEEE Std 802.1Qcj-2023, and IEEE Std 802.1Qdt-2023)

6

7

Draft Standard for
Local and metropolitan area networks—

9

Bridges and Bridged Networks

10

Amendment: Source Flow Control

11 Developed by the
12 LAN/MAN Standards Committee 
13 of the 

14 IEEE Computer Society

15 Individual contribution
16 Prepared by the Time-Sensitive Task Group of IEEE 802.1

1This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 Abstract: This amendment specifies procedures and managed objects for the signaling and remote
2 invocation of flow control at the source of transmission in a data center network
3 Keywords: Bridged Network, IEEE 802.1Q™, LAN, local area network, MAC Bridge, metropolitan
4 area network, flow control, congestion management, Priority-based flow control

T

2This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

3This is an individual contribution, subject to change.

October 26, 2022

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

1

October 26, 2022

Participants

2 <<The following lists will be updated in the usual way prior to publication>>
3 At the time this standard was submitted to the IEEE-SA Standards Board for approval, the IEEE 802.1
4 Working Group had the following membership:

Glenn Parsons, Chair
Jessy V. Rouyer, Vice ChairPaul Congdon, Editor
Jeremias Blendin, Editor

5
6
7
8
9
10

<<TBA>>

4
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 The following members of the individual balloting committee voted on this standard. Balloters may have
2 voted for approval, disapproval, or abstention.

<<TBA>>

3 When the IEEE-SA Standards Board approved this standard on XX Month 20xx, it had the following
4 membership:<<TBA>>

5<<TBA>>

6 Also included are the following nonvoting IEEE-SA Standards Board liaisons:7
8 <<TBA>>

5
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 Introduction

This introduction is not part of IEEE Std 802.1Qdw™, Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—Amendment: Source Flow Control
26This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

October 26, 2022

Contents

2 1.

Overview............................................................................................................................................ 11

3

1.3

4 3.

Definitions ......................................................................................................................................... 13

5 4.

Abbreviations..................................................................................................................................... 14

6 5.

Conformance...................................................................................................................................... 1578

Introduction............................................................................................................................ 11

5.4.1
VLAN Bridge component options ........................................................................ 15
5.4.9
Source Flow Control (SFC) operation (optional) ................................................. 15
End station requirements—SFC ............................................................................................ 15

9

5.34

10 6.

Support of the MAC Service ............................................................................................................. 16
6.10.1

11

Data indications .................................................................................................... 16

12 12.

Bridge management ........................................................................................................................... 1713

16

12.36 Source Flow Control managed objects .................................................................................. 1712.36.1 SFC entity managed object ................................................................................... 1712.36.2 SFC per-port object ............................................................................................... 1712.36.3 SFC per-port per-queue object .............................................................................. 18

17 52.

Source Flow Control .......................................................................................................................... 19

18

52.1
52.2

14
15

19
20
21
22
23
24
25
26
27

52.3

28
29
30
31
32

52.4

33
34
35
36
37
38
39
40
41
42
43

52.5

Source flow control objectives .............................................................................................. 20
Principles of source flow control ........................................................................................... 2152.2.1
Congesting flow identification .............................................................................. 2152.2.2
Source flow control signaling ............................................................................... 2252.2.3End station SFCM reception ................................................................................. 2252.2.4Proxy SFCM reception ......................................................................................... 2252.2.5Comparison to Priority-based Flow Control ......................................................... 2252.2.6Comparison to Congestion Notification ............................................................... 2252.2.7Comparison to Congestion Isolation ..................................................................... 23
Bridge Component Source Flow Control Aware Forwarding Process.................................. 23
52.3.1SFC Congestion Detection .................................................................................... 24
52.3.2SFCM Multiplexer ................................................................................................ 24
52.3.3SFCM Demultiplexer ............................................................................................ 24
52.3.4
Source port locator ................................................................................................ 24
End Station Source Flow Control Aware Forwarding Process.............................................. 24
52.4.1End Station SFCM Multiplexer ............................................................................ 25
52.4.2End Station SFCM Demultiplexer ........................................................................ 25
52.4.3End Station SFC Congestion Detection ................................................................ 25
52.4.4
End Station Tx Flow Management ....................................................................... 25
52.4.5End Station Rx Flow Management ....................................................................... 26
52.4.6
Reception Selection .............................................................................................. 26
Source Flow Control Protocol ............................................................................................... 26
52.5.1
Variables controlling operation ............................................................................ 26
52.5.2SFCP Procedures .................................................................................................. 28
52.5.3
Encoding of the SFCM PDU ................................................................................ 29
52.5.4
LLDP Source Flow Control TLV ......................................................................... 33

7This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1 Annex Z(temporary not for publication)
2
3
4

Z.1
Z.2
Z.3

October 26, 2022

Commentary............................................................................... 35

VLAN in SFCM..................................................................................................................... 35
SFCM caching security considerations.................................................................................. 35
SFCM Authentication ............................................................................................................ 368This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

October 26, 2022

Figures

2 Figure 52-1
3 Figure 52-2
4 Figure 52-3
5 Figure 52-4
6 Figure 52-5
7 Figure 52-6
8 Figure 52-7
9 Figure 52-8

Source flow control example operation ................................................................................ 19
Bridge component SFC reference diagram........................................................................... 23
End station SFC reference diagram ...................................................................................... 25
IPv4 SFCM Encapsulation.................................................................................................... 30
IPv6 SFCM Encapsulation.................................................................................................... 30
SFCM PDU........................................................................................................................... 30
Option TLV format ............................................................................................................... 31
Organizationally specific option TLV format ...................................................................... 33

9This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

October 26, 2022

Tables

2 Table 12-1
3 Table 12-2
4 Table 12-3
5 Table 52-1

SFC entity table .................................................................................................................... 17
SFC per-port table................................................................................................................. 17
SFC per-port per-queue table................................................................................................ 18
Option TLV definitions ........................................................................................................ 32

10This is an individual contribution, subject to change.

October 6, 2022

1

2
3

4
5

IEEE Standard for 
Local and metropolitan area networks—

Bridges and Bridged Networks—
Amendment: Source Flow Control

6 [This amendment is based on IEEE Std 802.1Q™-2022 as amended by IEEE Std Qcz-2022, IEEE Std
7 802.1Qcw-2023, IEEE Std 802.1Qcj-2023, and IEEE Std 802.1Qdt-2023.]
8 NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into
9 the existing base standard and its amendments to form the comprehensive standard.
10 The editing instructions are shown in bold italics. Four editing instructions are used: change, delete, insert,
11 and replace. Change is used to make corrections in existing text or tables. The editing instruction specifies
12 the location of the change and describes what is being changed by using strikethrough (to remove old
13 material) and underscore (to add new material). Delete removes existing material. Insert adds new material
14 without

disturbing the existing material. Deletions and insertions may require renumbering. If so,

15 renumbering instructions are given in the editing instruction. Replace is used to make changes in figures or
16 equations by removing the existing figure or equation and replacing it with a new one. Editing instructions,
17 change markings, and this note will not be carried over into future editions because the changes will be
18 incorporated into the base standard.

19

1. Overview

20 .

21 1.3 Introduction
22 Insert the following text at the end of 1.3 and renumber accordingly:
23
24 Thisstandard specifies protocols, procedures and management objects that support flow control of

25 congesting data flows within data center environments. This is achieved by enabling systems to signal
26 congestion and its expected duration directly to the sender end-station of congesting data flow. Source Flow
27 Control applies flow control to congesting flows of higher layer protocols at the sender end-station by
28 providing sufficient information to pause individual congesting end-to-end flows. It reduces head-of-line
29 blocking in the network compared to hop-by-hop flow control mechanism while it helps to reduce queue

11
This is an unapproved IEEE Standards draft, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 build-up and packet loss in the network. A method for PFC-based signaling to pause PFC priorities instead
2 of end-to-end flows is provided for backwards compatibility with PFC-only enabled end stations.
3 To this purpose Source Flow Control does:
4

a)

5
6
7
8

b)
c)

Defines a means for bridges to signal congestion directly to the sender of a specific traffic flow
contributing to the congestion.
Specifies for senders of traffic flows to react to congestion signals.
Defines a means for bridges connected to senders of traffic flows to react to congestion signals andconvert them to PFC signals if the sender is not capable of processing the congestion signals.

912This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

October 26, 2022

3. Definitions

2 Insert the following definitions in the appropriate collating sequence, re-numbering as appropriate:
3 3.1 Source Flow Control Signaling System: An End Station or Bridge Component conforming to the
4 Source Flow Control signaling provisions of this standard.
5 3.2 Source Flow Control Reception Station: An End Station or Bridge Component conforming to the
6 Source Flow Control signal processing provision of this standard.
7 3.3 Source Flow Control Message (SFCM): A message transmitted by a Source Flow Control Aware
8 System, conveying congesting flow information used to flow control a congesting flow.
913This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

4. Abbreviations

2 Insert the following abbreviations in the appropriate sequence, re-ordering as appropriate:
3
4
6

SFC
SFCM

Source Flow Control
Source Flow Control Message

8

14This is an individual contribution, subject to change.

October 26, 2022

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

October 26, 2022

5. Conformance

2 5.4.1 VLAN Bridge component options
3 Insert the following at the end of the lettered list in 5.4.1, renumbering accordingly:
4a)Support Source Flow Control (SFC) (5.4.9)

5 Insert the following sub-clause at the end of 5.4, renumbering as appropriate:
6 5.4.9 Source Flow Control (SFC) operation (optional)
7 A VLAN Bridge implementation that conforms to the provisions of this standard for Source Flow Control
8 (Clause 52) shall:
9a)<<TBD>>

10 A VLAN Bridge implementation that conforms to the provisions of this standard for Source Flow Control
11 (Clause 52) may:
12a)<<TBD>>

13 Insert the following at the end of Clause 5, renumbering as appropriate:

14 5.34 End station requirements—SFC
15 An end station implementation that conforms to the provisions of this standard for SFC shall
16a)<<TBD>>

17 An end station implementation that conforms to the provisions of this standard for SFC may
18

a)<<TBD>>

19

15
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

October 26, 2022

6. Support of the MAC Service

2 6.10.1 Data indications
3 Change the first paragraph of Clause 6.10.1 as follows:
4 On receipt of an M_UNITDATA.indication primitive from the PIP-ISS, if the PIP is congestion aware
5 (5.4.1.4) and the initial octets of the mac_service_data_unit contain a valid CNM encapsulation, the received
6 frame is processed according to 32.16. If the PIP is congestion isolation aware (5.4.7) and the initial octets of
7 the mac_service_data_unit contain a valid CIM encapsulation (49.4.3), the received frame is processed
8 according

to 49.4.2.6. If the PIP is Source Flow Control aware (5.4.9) and the initial octets of the

9 mac_service_data_unit contain a valid SFCM encapsulation (<<52.?.?>>), the received frame is processed
10 according to <<52.?.?>>. Otherwise, the received frame shall be discarded if
11

16This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

October 26, 2022

12. Bridge management

2 Insert a new clause 12.36 at the end of Clause 12, renumbering as appropriate

3 12.36 Source Flow Control managed objects
4 Clause 52 defines Source Flow Control (SFC). The following managed objects control the operation of SFC:

a)
b)
c)

5
6
7

SFC entity managed object (12.36.1)
SFC per-port object (12.36.2)
SFC per-port per-queue table (12.36.3)

8 12.36.1 SFC entity managed object
9 There is one SFC entity managed object per bridge or end station.

Table 12-1—SFC entity table
Name

Data typeOperations
supporteda

Conformanceb

References

sfcMasterEnable

Boolean

RW

BE<<TBD>>.

sfcSFCMTransmitPriority

unsigned integer [0..7]

RW

BE<<TBD>>

sfcAddressIPv4

IPv4 address

RW

IETF RFC 791<<TBD>>

sfcAddressIPv6

IPv6 address

RW

IETF RFC 8200<<TBD>>

sfcUDPPortUDP port number

RW

IETF RFC 798<<TBD>>

sfcHeaderTruncationLength

integer[0..512]

RW

BE<<TBD>>

a R = Read only access; RW = Read/Write accessb
B = Required for Bridge or Bridge component support of source flow control; E = Required for end station support of source flow
control.

10 12.36.2 SFC per-port object
11 There is one SFC per-port managed object for each bridge or end-station port
12

Table 12-2—SFC per-port table
Name
sfcMonitorQueues

Data type
8 bit mask

Operations
supporteda

Conformanceb

References

RW

BE<<TBD>>a

R = Read only access; RW = Read/Write access
B = Required for Bridge or Bridge component support of source flow control; E = Required for end station support of source flow
control.
b

17This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 12.36.3 SFC per-port per-queue object
2 There is a maximum one SFC per-port per-queue object for every traffic class of every bridge or end station
3 port.
4

Table 12-3—SFC per-port per-queue table
Name<<TBD>>

Data type<<TBD>>

Operations
supporteda

Conformanceb

References

RW

BE<<TBD>>

a R = Read only access; RW = Read/Write accessb
B = Required for Bridge or Bridge component support of source flow control; E = Required for end station support of source flow
control.

5618This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 Insert a new Clause “52. Source Flow Control” as follows:252. Source Flow Control

3 Source Flow Control (SFC) pauses congesting flows at the source by reacting to a Source Flow Control
4 Message (SFCM) sent across a data center network from a port with a congesting traffic class that is enabled
5 with the feature. The SFCM identifies a congesting flow at the source end station and provides a pause
6 interval for which transmissions of frames for the flow are to be paused. The receiver of the SFCM asserts
7 flow control on the traffic class used to transmit the flow or may provide more advanced implementation
8 specific per-flow control if implemented. The externally visible behavior of SFC is that the bridge or end9 station processing a received SFCM will pause the identified flow for the specified interval.
10 The models of operation in this clause provide a basis for specifying the externally observable behavior of
11 SFC and are not intended to place additional constraints on implementations; these can adopt any internal
12 model of operation compatible with the externally observable behavior specified.
13 This clause introduces the concepts and protocols essential to source flow control as follows:
14
15
16
17

a)
b)
c)
d)

The objectives for source flow control (xx).
Principles of source flow control (xx).
Source flow control aware forwarding process (xx).
Source flow control protocol (xx).

18 << elaborate more on the environment for SFC - perhaps referencing CI environments >>19 .

Figure 52-1—Source flow control example operation

SFCM
congestion

Proxy
PFC

level 0level 1

SFCM

level 2level 1level 0Figure 52-1—Source flow control example operation
20 Figure 52-1 shows an example operation of SFC. In the figure, all of the relay systems are layer-3 routers
21 and may be SFC aware. It is most important for the edge systems are SFC aware, however when all systems
22 are SFC aware different reasons for congestion may be detected. In the figure, server to server traffic is
23 flowing from left to right across a data center network. When congestion is detected SFC attempts to
24 identify the congesting flows (52.2.1). For each identified congesting flow (e.g. the red flows in Figure 52-

19This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 1), the SFC aware system sends a Source Flow Control Message (SFCM) to the sending end station. If the
2 end station is SFC aware, the SFCM is forwarded through the edge system directly to the end station (as3 seen in the middle of the diagram). If the end station is not SFC aware, the edge system should intercept the
4 SFCM and convert the message to a traditional PFC message (as seen in the lower part of the diagram). The
5 edgesystem converting the SFCM to a PFC message is known as SFC proxy mode and should be

6 implemented by the edge systems directly attached to end stations. The SFCM contains flow description
7 information necessary for the source end station or the proxy edge system to identify the traffic class of the
8 congesting flow. The flow information may also be used to identify and invoke per-flow implementation
9 specific traffic controls.

10 52.1 Source flow control objectives
11 Theoperation, procedures and protocols of source flow control are designed to meet the following

12 objectives by category:
13 Functionality
14

a)

15
16

b)

17
18
19
20
21

c)
d)
e)
f)

22
23

g)

24
25
26

h)
i)

Provide a means for low-latency flow control signaling for individual, congesting end-to-end flows
across a network.
Reduce queue build up in congesting queues with minimal side effects on other flows in the
network.
Move queueing and congestion from in the network to the edge, into the end stations.
Reduce the likelihood of frame loss.
Avoid the triggering of PFC, not replace PFC.
Invoke flow control on frames of congesting flows before the frames experience congestion in thequeue management system.
Do not keep per-flow state in the congested device other than a probabilistic data structure to limit
the messaging overhead per flow.
Specify the signaling of the estimated duration of the congestion.
Do only specify the minimum reaction to a source flow control message.

27 Compatibility
28

j)

29
30
31

k)

32
33

l)

34
35
36
37

m)
n)

Be oblivious of protocols above the network layer. Do not be specific to higher layer protocols. The
identification of the end-to-end protocol flows is left to the higher layers based on the first bytes ofthe original PDU.
Work in conjunction with higher-layer end-to-end congestion control protocols and features, such as
ECN, RoCE, DCQCN, Swift.
Optionally provide means to specify locators of the congested queue enabling receiving systems.
Systems, including intermediate systems, can use the congestion locator to decide if other passing
flows are expected to contribute to the congested queue and to signal flow control preemptively.
Work in existing lossless environments using PFC without requiring additional traffic classes.
Work in layer-2 and layer-3 networks.

38 Performance
39
40

o)
p)

41
42

q)

Reduce queueing in the network and thereby the flow completion time across the network.
SFC messages should be as small as possible to ensure low-latency forwarding as well as low
signaling overhead.
Reduce head-of-line blocking when using in an environment with PFC enabled.

43 Scale
44
45
46

r)
s)

Work in arbitrary data center network topologies with a mix of link speeds.
Limit messaging overhead by restricting the number of congestion messages per flow to a fixed
number per RTT.

20This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

t)

2

October 26, 2022

Limit the messaging overhead by signaling the expected duration of the congestion without causing
underutilization.

3 Implementation complexity
4
5

u)
v)

6

The main goal of SFC is implementational simplicity.
Require changes only on congested switches as well as sender NICs, or optional the last hop switch
at sender side. No modifications on intermediate switches are required.

7 Manageability
8
9

w)
x)

10
11

Limit the ability to configure an inoperable environment.
Provide auto discovery of SFC message processing capability between last hop switches and NICs
using existing LLDP messages and without creating additional hello and auto-configuration
protocols.

12 52.2 Principles of source flow control
13 This clause introduces the principles of source flow control. Items a) through d) describe the life of a
14 congesting flow from identification through pausing of the flow. Items e) through g) compare and contrast
15 Source Flow Control with Priority-based Flow Control (Clause 36), Congestion Notification (Clause 30)
16 and Congestion Isolation (Clause 49).
17 The following items describe the principals of source flow control:
18
19
20
21
22
23
24

a)
b)
c)
d)
e)
f)
g)

Congesting flow identification (52.2.1).
Source flow control signaling (xx).
End station SFCM reception (xx).
Proxy SFCM reception (xx).
Comparison to Priority-based Flow Control (xx)Comparison to Congestion Notification (xx).
Comparison to Congestion Isolation (xx).

25 52.2.1 Congesting flow identification
26 << reference text from Congestion Isolation and/or Congestion Notification>>
27 An essential step in the process of SFC is identifying congesting flows by an Active Queue Management
28 (AQM) scheme that supports Explicit Congestion Notification (ECN) specified in IETF RFC 3168. There
29 are many potential methods of identifying congesting flows and interoperable implementations can exist
30 using different approaches. The SFC Congestion Detection function (52.3.1) of the Source Flow Control
31 Aware Forwarding Process (52.3) is responsible for implementing the AQM. This standard defines the CP
32 algorithm (30.2.1) for detecting Congestion Controlled Flows (CCFs) in congestion aware bridges. This
33 approach may be used to detect congesting flows in a SFC aware system. A number of other possible
34 approaches, including those that support the end-to-end ECN congestion control, are discussed in IETF RFC
35 7567[B1].
36 Many modern data centers utilize encapsulated overlay networks, such as those described in IETF RFC
37 8014[B6]. An overlay network can carry multiple encapsulated flows within a single encapsulation flow.
38 The congesting and non-congesting flows identified by SFC are the outer encapsulation flow as seen by the
39 underlay network. The inner encapsulated flows might not be visible to the bridges and routers within the
40 data center network, and are therefore not separated into congesting and non-congesting flows.

21
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 52.2.2 Source flow control signaling
2 Once a frame has been identified as being part of a congesting flow, an SFCM is created and sent to the
3 origin of the congesting flow. The SFCM message carries the pause duration estimate as well enough
4 information to identify the congesting flow. The SFCM PDU is encapsulated in a UDP packet. The source
5 address and UDP port number for the UDP packet are taken from SFC configuration, and the destination
6 address is the source address of the congesting frame.
7 The congesting flow is identified at the source by examining the contents of the SFCM which contains a part
8 of the congesting frame. By default, an SFCM contains the first 48 bytes of the congesting frame’s MSDU.
9 Configuration allows the SFCM to include up to 256 octets of the congesting frame’s MSDU allowing
10 systems that support overlay networks the ability to identify encapsulated flows within the congesting flow
11 encapsulation.
12 The SFCM may contain optional congestion locators that may be used by systems to preemptively trigger
13 flow control on passing flows that are expected to contribute to the congestion point specified by the
14 congestion locator.
15 The system sending SFC frames should be configurable to limit the SFCM sending rate to a specific
16 receiver.
17 52.2.3 End station SFCM reception
18 SFCM aware end stations receive SFCM messages and parse them to identify the congesting flow. The end
19 station prohibits subsequent frames of the specified congesting flow from transmission for the specified
20 amount of time within <<XX>> ns of receiving the message. The end station prohibits transmission of
21 subsequent frames by pausing the traffic class associated with the congesting flow or alternatively, invoking
22 an implementation specific mechanism that pauses the transmission of individual frames associated with the
23 congesting flow.
24 52.2.4 Proxy SFCM reception
25 SFC may be extended to end stations that are not SFC aware, but are PFC enabled by an SFC proxy function
26 in the directly attached bridge or router. The SFC proxy function enabled on the port attached to the SFC
27 unaware end station is responsible for converting the SFCM addressed to the end station to a PFC frame that
28 pauses the appropriate traffic class. To perform this operation, the SFC proxy function must identify the
29 source port and traffic class of the congesting flow by examining the contents of the SFCM. The pause time
30 indicated in the SFCM is converted to the PFC pause time encoding and a PFC request is triggered.
31 52.2.5 Comparison to Priority-based Flow Control
32 PFC aims at eliminating frame loss. SFC does not have that goal. Instead, SFC aims at controlling the queue
33 buildup during congestion events. Limiting queue build up reduces the likelihood of packet drops because of
34 limited buffer space, it does not eliminate it though. For lossless network behavior, SFC should be used
35 together with PFC enabled on the same traffic classes in the network.
36 In contrast to PFC, which uses hop-by-hop propagation of the flow control signal, SFC signals flow control
37 directly to senders of congesting flows. Thereby, operational side effects of flow control that exist in hop-by38 hop designs, such as PFC’s head-of-line blocking are eliminated. The queue build up is moved to the sender
39 end station, minimizing the in-network side effects of flow control.
40 52.2.6 Comparison to Congestion Notification
41 <<TBD>>

22
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 52.2.7 Comparison to Congestion Isolation
2 <<TBD>>

3 52.3 Bridge Component Source Flow Control Aware Forwarding Process
4 This clause specifies the architecture of the Source Flow Control Point (SFCP) in the Forwarding Process of
5 a source flow control aware Bridge. In this architecture, a router is as a higher layer entity that relays frames
6 using layer-3 information but uses the forwarding process of the underlying source flow control aware
7 bridge to deliver frames to peers and end stations.
8 <<NOTE: the paragraph below has already been said once above - which location is better? The editors
9 believe above is better since we are specifying both end station and bridge component behavior>>
10 The models of operation in this clause provide a basis for specifying the externally observable behavior of
11 SFC, and are not intended to place additional constraints on implementations; these can adopt any internal
12 modelof operation compatible with the externally observable behavior specified. Conformance of

13 equipment to this standard is purely in respect of observable protocol.
14 Figure 8-12 illustrates the Bridge Forwarding Process at its highest conceptual level. Figure 8-16 shows the
15 specificfiltering and assignment functions of the flow classification and metering elements in the

16 Forwarding Process of a source flow control aware Bridge. Figure 52-2 focuses on the operation of a single
17 Bridge Port and the relationship of new elements to the queuing and classification functions. Four new
18 elements and two new managed tables are specified for a SFC aware Bridge as follows:
19
20
21
22

a)
b)
c)
d)

SFC Congestion Detection (52.3.1).
SFCM Multiplexer (52.3.2).
SFCM Demultiplexer (52.3.3).
Source Port Locator (52.3.4).

23

Figure 52-2—Bridge component
SFC reference diagram-()- EI SS

Queuing Frames
8.6.6

SFCM Multiplexer
52.x.xSFC Congestion Detection
52.x.xSFC proxy support (optional)...

Source Port Locator
52.x.xTransmission Selection
8.6.8

Note:
different port

PFC Initiator36.2.1

SFCM Demultiplexer
52.x.x

M_CONTROL-()- EISS

Figure 52-2—Bridge component SFC reference diagram

23
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 52.3.1 SFC Congestion Detection
2 << Reference or leverage text from Congestion Notification and/or Congestion Isolation>>
3 SFC Congestion Detection identifies frames of a congesting flow, inserts frames passed by the Queuing
4 Frames entity (8.6.6) into the appropriate queue or discards them and can generate an SFCM based on the
5 contents of the frame. As described in 52.2.1, frames of a congesting flow are identified by a suitable AQM
6 implemented by SFC Congestion Detection, such as the algorithm specified by a CP in 30.2.1.
7 Frames

given to SFC Congestion Detection by the Queuing Frames entity (8.6.6) in an

8 EM_UNITDATA.request (52.5.2.2) may be identified by the AQM as being part of a congesting flow. An
9 SFCM may be generated from the parameters obtained with the received frame. The SFCM is sent to the
10 source of the congestion flow via the SFC multiplexer.
11 On each EM_UNITDATA.request, SFC Congestion Detection and its associated AQM indicate to the SFC
12 Procedures (52.4) whether a monitored queue is congested or not congested. The AQM or other means can
13 be used to provide the queue status.
14 52.3.2 SFCM Multiplexer
15 The SFCM multiplexer inserts SFCMs generated by SFC Congestion Detection among frames received
16 from the LAN. Layer-3 encapsulated SFCMs (xx and xx) are routed to the source by a higher-layer routing
17 function that is beyond the scope of this standard.
18 52.3.3 SFCM Demultiplexer
19 The SFCM demultiplexer is part of the optional SFCM proxy mode support. It identifies SFCMs received
20 from the LAN and extracts the flow information from the content of the SFCM PDU (xx) to pass to the
21 source

port locator function (xx). An SFCM PDU may be encapsulated by two different SFCM

22 encapsulations; IPv4 and IPv6. Implementations supporting IPv4 and IPv6 encapsulations must be able to23 identify and validate IPv4 and/or IPv6 packets in the SFCM demultiplexer. The rules for validating received
24 SFCMs are specified in <<xx>>.
25 52.3.4 Source port locator
26 <<TBD - responsible for finding the source port for a given flow. The proxy function will assert PFC on that
27 source port. The port is located using layer-3 routing tables or implementation specific structures that
28 identify how to reach a particular IP address.>>

29 52.4 End Station Source Flow Control Aware Forwarding Process
30 This clause specifies the architecture of the Source Flow Control Point (SFCP) in the Forwarding Process of
31 a source flow control aware End station.
32 Figure 52-3 focuses on the operation of a single End station port and the relationship of new elements to the
33 queuing and classification functions. Five new elements and two new managed tables are specified for a
34 SFC aware Bridge as follows:
35
36
37

a)
b)
c)

End Station SFCM Multiplexer (52.4.1).
End Station SFCM Demultiplexer (52.4.2).
End Station SFC Congestion Detection (52.4.3).

24This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 Figure 52-3 also depicts a number of functions that are out of the scope of this standard and may be
2 optionally implemented by an end station. These functions are described as follows:
3
4
5

d)
e)
f)

End Station Tx Flow Management (52.4.4).
End Station Rx Flow Management (52.4.5).
Reception Selection (52.4.6).

6

Figure 52-3—End station
SFC-()- EISS reference diagram

Reception Selection

End-Station Tx Flow
Management

Input Queues...

SFCM Multiplexer
52.x.xSFC Congestion Detection
52.x.x

Queuing Frames
8.6.6

End-Station Rx Flow
Management...
Output Queues

Transmission Selection
8.6.8

Flow/TC Locator
52.x.x-(SFCM Demultiplexer
52.x.x)- EI SS

Figure 52-3—End station SFC reference diagram
7 52.4.1 End Station SFCM Multiplexer
8 <<TBD>>
9 52.4.2 End Station SFCM Demultiplexer
10 <<TBD>>
11 52.4.3 End Station SFC Congestion Detection
12 <<TBD>>
13 52.4.4 End Station Tx Flow Management
14 <<TBD>>

25
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 52.4.5 End Station Rx Flow Management
2 <<TBD>>
3 52.4.6 Reception Selection
4 <<TBD>>

5 52.5 Source Flow Control Protocol
6 Source flow control aware systems control forwarding elements, participate in SFC protocols and act upon
7 the LLDP Source Flow Control TLV as specified in this clause. This includes:
8
9
10
11

a)
b)
c)
d)

Variables controlling operation (52.5.1).
SFCP procedures (52.5.2).
Encoding of the SFCM PDU and SFCM encapsulations (52.5.3).
LLDP Source Flow Control TLV (52.5.4).

12 52.5.1 Variables controlling operation
13 The source flow control variables control the operation of the SFC entity and the SFCP entity.
14 52.5.1.1 SFC entity variables
15 Every source flow control aware system has a set of SFC entity variables to control the overall operation of
16 SFC. These variables are included in the SFC entity managed object (12.xx). These include the following:
17
18
19
20
21
22

a)
b)
c)
d)
e)
f)

sfcMasterEnable (52.5.1.1.1).
sfcSFCMTransmitPriority (52.5.1.1.2).
sfcAddressIPv4 (52.5.1.1.3).
sfcAddressIPv6 (52.5.1.1.4).
sfcUDPPort (52.5.1.1.5).
sfcHeaderTruncationLength (52.5.1.1.6).

23 52.5.1.1.1 sfcMasterEnable
24 A boolean value specifying whether SFC is enabled in this system. If sfcMasterEnable is FALSE all source
25 flow control functionality is disabled; SFCMs and LLDP Source Flow Control TLVs are not generated and
26 are ignored on receipt. If sfcMasterEnable is TRUE the other managed objects and variables specified in the
27 clause control the operation of SFC.
28 52.5.1.1.2 sfcSFCMTransmitPriority
29 An integer specifying the priority value to be used when transmitting SFCMs from the system. The default is
30 6.
31 52.5.1.1.3 sfcAddressIPv4
32 The IPv4 address, belonging to the system transmitting the IPv4 SFCM (xx), used as the IPv4 source address
33 in the IPv4 header (IETF RFC 791) of IPv4 SFCMs sent from the SFCP.

26
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 52.5.1.1.4 sfcAddressIPv6
2 The IPv6 address, belonging to the system transmitting the IPv6 SFCM (xx), used as the IPv6 source address
3 in the IPv6 header (IETF RFC 8200) of IPv6 SFCMs sent from the SFCP.
4 52.5.1.1.5 sfcUDPPort
5 <<Itis desirable to have a well-known UDP number allocated by IANA rather than using a locally

6 administrated value as described in the text below. The same value MUST be used by all systems in the data
7 center network and will require configuration if a well known number is not allocated>>
8 The destination UDP port number in the UDP header (IETF RFC 768) of IPv4 and IPv6 SFCMs sent by the
9 SFC aware system. The UDP port number must be selected from the range of dynamic port numbers,
10 between 49152 and 65535, as specified in IETF RFC 6335. The port number must be currently available for
11 use by the implementation. For example, an implementation may use UDP port 58623, if it is not currently
12 being used by any other application in the system.
13 52.5.1.1.6 sfcHeaderTruncationLength
14 The minimum number of octets that the SFCP is to return in the Encapsulated MSDU field of each SFCM
15 generated. The default value is 48. The sfcHeaderTruncationLength should be configured consistently
16 across all systems in the data center network.
17 52.5.1.2 SFCP entity variables
18 <<These are per bridge component configuration values - none identified yet. NOTE: do we want the same
19 set of traffic classes to have SFC enabled on every port? If so, we can define the TC enabled bit-mask
20 here.>>21 52.5.1.3 SFCP entity per-port variables
22 <<These are per bridge component, per-port configuration values>>
23 52.5.1.3.1 sfcMonitorQueues
24 An 8-bit value specifying which traffic classes on the port will be monitored for congestion and potentially
25 cause the generation of SFCM messages back to the source.
26 52.5.1.4 SFCP entity per-port per-traffic class variables
27 For each port and monitored queue in a source flow control aware system there is the following set of
28 variables:
29
30

g)
h)

sfcCongesting (52.5.1.4.1)<<TBD>>

31 52.5.1.4.1 sfcCongesting
32 A boolean value that is set during the processing of a frame by the EM_UNITDATA.request (xx) procedure.
33 The value is set true when the AQM indicates that the monitored queue is congested at the time the frame is
34 processed. The variable is initialized to false.

27
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 52.5.1.5 SFCP entity per-stream variables
2 <<TBD - these variables drive the logic and likely do NOT need to be per-port, per-TC, per-stream since
3 SFC does not require state>>
4 52.5.2 SFCP Procedures
5 Source flow control is implemented through the procedures of a SFCP. These include the following:
6
7
8
9
10

a)
b)
c)
d)
e)

sfcInitialize() (xx)
EM_UNITDATA.request (parameters) (xx)condTransmitSfcmPdu() (xx)pauseTimeCalc() (xx)<<TBD>>

11 52.5.2.1 ciInitialize()
12 Initializes SFC support. At initialization time the procedure performs the following:
13

a)<<TBD>>

14 52.5.2.2 EM_UNITDATA.request (parameters)
15 A SFCP offers an instance of the EISS (6.8) to the Queuing frames function (8.6.6). When called upon to
16 enqueue a frame the priority parameter specifies the target queue which represents the received priority of
17 the frame. The SFCP determines if the target queue is a monitored queue by checking if the priority
18 parameter has a corresponding bit set for the traffic classes in the sfcMonitorQueues variable.
19 If the corresponding bit in the sfcMonitorQueues variable has the value is 0 then the target queue is not
20 participating in source flow control and the frame can be enqueued on the target queue with no further
21 processing. If the corresponding bit in the sfcMonitorQueues variable has the value is 1then the target queue
22 is a monitored queue.
23 If the target queue is a monitored queue, the SFCP interacts with the AQM to determine if the frame is part
24 of a flow that is creating congestion in the monitored queue. Frames that have been determined by the AQM
25 (see 52.2.1) to be creating congestion may cause a SFCM to be transmitted. The conditions by which a
26 SFCM is transmitted are described in condTransmitSfcmPdu().
27 For each frame that is presented for queuing, the SFCP performs the following:
28

a)<<TBD>>

29 52.5.2.3 condTransmitSfcmPdu()
30 Calledby the SFCP to conditionally generate and transmit a SFCM. <<TBD - describe throttling

31 mechanism. This function can also build the SFCM message with available parameters>>.
32 NOTE—Implementations may have additional conditions to restrict or allow the creation of SFCMs for adding
33 congesting flows without risking interoperability.
34 The procedure performs the following:
35

a)<<TBD>>

28
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 52.5.2.4 pauseTimeCalc()()
2 <<TBD - determines the pause interval to put into the SFCM>>.
3 52.5.2.5 processSfcmPdu()
4 The

SFCM Demultiplexer (52.3.3) receives SFCMs from SFC aware systems and invokes

5 processSfcmPdu() to process the SFCM. The procedure performs the following actions upon receipt of a
6 SFCM:
7
8

a)<<TBD - this is bacially the heart of the demultiplexer. It parses the SFCM and either calls TC/Flowlocator or the source port locator (in proxy mode)>>

9 52.5.3 Encoding of the SFCM PDU
10 This clause specifies the method of encoding source flow control message (SFCM) PDUs. There are two
11 ways of encapsulating SFCM PDUs; a IPv4 and IPv6 SFCM PDU <<TBD - how do we know which type of
12 SFCM to send? Must be another configuration option>>. All SFCMs contain an integral number of octets.
13 The octets in a source flow control message PDU are numbered starting from 1 and increasing in the order
14 they are put into the MSDU that accompanies a request to or indication from the instance of the MAC
15 Internal Sublayer Service (ISS or EISS) used by a source flow control entity. The bits in an octet are
16 numbered from 1 to 8 in order of increasing bit significance, where 1 is the LSB in the octet.
17 Where octets and bits within a source flow control message PDU are represented using a diagram, octets
18 shown higher on the page than subsequent octets and octets shown to the left of subsequent octets at the
19 same height on the page are lower numbered; bits shown to the left of other bits within the same octet are
20 higher numbered.
21 Where two or more consecutive octets are represented as hexadecimal values, lower numbered octet(s) are
22 shown to the left and each octet following the first is preceded by a hyphen, e.g., 01-80-C2-00-00-00. When
23 consecutive octets are used to encode a binary number, the lower octet number has the more significant
24 value. When consecutive bits within an octet are used to encode a binary number, the higher bit number has
25 the most significant value. When bits within consecutive octets are used to encode a binary number, the26 lower octet number composes the more significant bits of the number. A flag is encoded as a single bit, and
27 is set (TRUE) if the bit takes the value 1, and clear (FALSE) otherwise. The remaining bits within the octet
28 can be used to encode other protocol fields.
29 52.5.3.1 IPv4 SFCM PDU encapsulation
30 The means of identifying IPv4 encapsulated SFCM PDUs consist of 2 octets containing the EtherType value
31 for IPv4 packets (08-00) as well as the associated IPv4 header decoding for a UDP datagram carrying the
32 SFCM PDU. The encoding of an IPv4 header is defined in IETF RFC 791. IP options are not included in the
33 IPv4 encapsulated SFCM PDU. The IP protocol field in the IPv4 header consists of 1 octet and identifies the
34 UDP datagram with the value 17. The encoding of a UDP header is defined in IETF RFC 768. The source
35 and destination port fields of the UDP header consists of 2 octets and identifies the encapsulated SFCM
36 PDU with the value from the sfcUDPPort variable. The IPv4 encapsulation is shown in Figure 52-4.
37 52.5.3.2 IPv6 SFCM PDU encapsulation
38 The means of identifying IPv6 encapsulated SFCM PDUs consist of 2 octets containing the EtherType value
39 for IPv6 packets (86-DD) as well as the associated IPv6 header decoding for a UDP datagram carrying the
40 SFCM PDU. The encoding of an IPv6 header is defined in IETF RFC 8200. IPv6 Extension Headers are not
41 used in the IPv6 encapsulated SFCM PDU. The next header field in the IPv6 headers indicates the upper

29
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

Figure 52-4—IPv4 SFCM Encapsulation
Octets: 1

3

23

EtherType(2 octe ts = 0 8-00)

IPv4 Head er(20 octets)

31

30+N

UDP Head er(8 octe ts)

SFCM PDU(N o ctets 66 ≤ N ≤ 530 )Figure 52-4—IPv4 SFCM Encapsulation

1 layer protocol field and consists of 1 octet identifying the UDP datagram with the value 17. The encoding of
2 a UDP header is defined in RFC 768. The source and destination port fields of the UDP header consists of 2
3 octets and identifies the encapsulated SFCM PDU with the value from the sfcUDPPort variable. The IPv6
4 encapsulation is shown in Figure 52-5.

Figure 52-5—IPv6 SFCM Encapsulation
Octets: 1

3

43

EtherType(2 octe ts = 8 6-DD)

IPv6 Head er(40 octets)

51

50+N

UDP Head er(8 octe ts)

SFCM PDU(N o ctets 66 ≤ N ≤ 530 )Figure 52-5—IPv6 SFCM Encapsulation
5 52.5.3.3 Source flow control message PDU format
6 The format of a source flow control message (SFCM) PDU is illustrated in Figure 52-6.

Figure 52-6—SFCM PDU
Option TLVs
(N octets < 80)

87+N

DE (1 bit)

4

5+N
VLAN ID(12 bits)

3 48priority(3 bits)

8

Pause
duration in µs(2 octet s)

5

Option count(4 bits)

4

4

Reserved(4 bits)

2

Reserved(4 bits)

Bits:

1

Version(4 bits)

Octets:Figure 52-6—SFCM PDU

Encapsulated
MSDU length(2 octets)

9+N

57+N+M

Encapsulated MSDU
(M octets 48 ≤ M ≤ 512)

7 52.5.3.3.1 Version
8 This field, 4 bits in length, shall be transmitted with the value 0 in this standard. If two Version fields are
9 interpreted as unsigned binary numbers, the greater identifies the more recently defined Version. The
10 Version field occupies the most significant bits of the first octet of the SFCM PDU.
11 52.5.3.3.2 Pause duration in us
12 A 16 bit unsigned integer containing the duration in microseconds that SFCM transmitter expects the
13 receiver to pause the transmission of the congesting flow. This field shall never be 0 when sent.
14 52.5.3.3.3 Option count
15 This field, 4 bits in length, shall be transmitted as an unsigned integer containing the number of option TLV
16 fields inserted in the Option TLV list. A value of 0 indicates that no option TLVs are included. The
17 maximum value is 15.

30
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

1 52.5.3.3.4 Option TLVs format
2 The option TLVs field is a list of zero, one or more, up to 15 SFCM option TLVs. The total length of the
3 options TLVs field shall not exceed 80 octets, independent of the number of SFC option TLVs. If a receiver
4 does not support an option TLV, the TLV shall be skipped and ignored.
5 Figure 52-7 illustrates the structure of an individual option TLV:

Type
(7 bits)

Bits:

7

Reserved(2 bits)

Figure 252-7—Option3TLV format

1

Require MSDU
(1 bit)Octets:8

2

Length(6 bits)

3+N

Value
(N octets < 64)

8

Figure 52-7—Option TLV format

6 52.5.3.3.4.1 Type
7 The option type is 7 bits in length and specifies the option type used. Table 52-1 specifies the details of each
8 option TLV type and the relationship to other fields of the TLV.
9 52.5.3.3.4.2 Requires MSDU
10 A single bit that indicates if this option requires the encapsulated MSDU to be present. It is 1 to indicate that
11 the MSDU is required, 0 if not. If the MSDU is not required, the sender can choose to not include the
12 MSDU. If the receiver does not support the option and the MSDU is not included, the SFC message is
13 ignored by the receiver.
14 52.5.3.3.4.3 Length
15 This field, 6 bits in length, is an unsigned integer providing the length of the option value in octets. The
16 length field can be 0.
17 52.5.3.3.4.4 Value
18 The value field contains between 0 and 63 binary octets representing the option value. Each option type has
19 a specific value field definition. When the TLV length field is 0, no value field is included.
20 52.5.3.3.5 Option TLV definitions
21 Table 52-1 provides the definition of the option TLVs and the relationship between fields of the TLV. The
22 layout of the value field and the bounds on the TLV length depend upon the option TLV type.
23
24 52.5.3.3.5.1 DSCP in MSDU
25 The DSCP in MSDU option TLV has a type field of 0. The MSDU required field is 1 since the contents of
26 the DSCP and destination IP address are obtained from the MSDU itself. This option instructs the receiver to
27 cache the outer most destination IP address and DSCP value found in the encapsulated MSDU. The length
28 of the option TLV value field is 0 and the total option TLV length is 2 octets. This option requires the MSDU
29 to be present in the SFCM.

31This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

October 26, 2022

Table 52-1—Option TLV definitions
Type

MSDU
required

0

1

DSCP in MSDU

0

N/A

1

0

DSCP / IP Prefix

6 for IPv4
18 for IPv6DSCP
(8-bits)

Addressfamily (1bit)

Address
prefix (7bits)

IP Address(4 or 16octets)2

0

TC / IP Prefix

6 for IPv4
18 for IPv6

TC (8bits)

Addressfamily (1bit)

Address
prefix (7bits)

IP Address(4 or 16octets)7-126

0Organizationallyspecific

3 < n < 64

See Figure 52-8

127

Length(octets)

Description

TLV value layout

1 52.5.3.3.5.1.1 DSCP/IP prefix
2 The DSCP/IP prefix option instructs the receiver to cache the prefix provided in the value field of the TLV.
3 The layout of value field is shown in Table 52-1. The layout contains the 8 bit DSCP/TOS value, a bit that
4 determines the address family (i.e. IPv4 or IPv6) and the IP address prefix length.
5 The next bit indicates the IP address family, with 0 signifying that the following prefix is IPv4 and 1
6 signifying it being an IPv6 prefix. The prefix length is encoded in a 7 bit field. If the IP address family is
7 IPv4 and the prefix length field value must be between 1 and 32. If the IP address family is IPv6 the prefix
8 length field value must be between 1 and 127.
9 The remainder of the option field encodes the IP address prefix. The length of the prefix is determined by the
10 length field of the option, after subtracting the first two octets of the value field that are used to encode the
11 DSCP value and the prefix length. The prefix is encoded starting with its most significant bits first. If the
12 total length of the prefix is smaller than the length of the IP address of the used address family, the parts of
13 the address that are not included are assumed to be 0.
14 52.5.3.3.5.1.2 TC/IP Prefix
15 This option instructs the receiver to cache the prefix provided in the value. The value layout starts with an 8
16 bit field to store a list of one-hot encoded TC values. The layout of the rest of the value is the same as the
17 “Cache DSCP and Prefix” option.
18 52.5.3.3.5.1.3 Organizationally Specific
19 TLVs of type 127 allow organizationally specific option TLVs. The required MSDU and length fields are the
20 samefor other option TLVs. The value field must begin with the organization’s OUI and an 8-bit

21 organizationally managed subtype field. The remainder of the value field is defined by the organization
22 supporting the TLV and must not exceed 60 octets in length.
23 Figure 52-8 illustrates the structure of an organizationally specific option TLV:
24

32
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

Figure 52-8—Organizationallyspecific option
TLV format
23
67Type = 127(7 bits)

Bits:

7

Reserved(2 bits)1

Require MSDU
(1 bit)Octets:8

2

Length(6 bits)

OUI(3 octets)

Subtype(1 octet )October 26, 2022

7+N

Organizat ionallyspecific value(N octets ≤ 60)

8

Figure 52-8—Organizationally specific option TLV format
1 52.5.3.3.6 priority
2 This field, 3 bits in length, contains the priority parameter of the EM_UNITDATA.request (6.8.1) of the
3 frame that triggered the creation of the SFCM.
4 52.5.3.3.7 DE
5 This field, 1bit in length, contains the drop_eligible parameter of the of the EM_UNITDATA.request (6.8.1)
6 for the frame that triggered the creation of the SFCM.
7 52.5.3.3.8 VLAN ID
8 This field, 12 bits in length, contains the vlan_identifier parameter of the EM_UNITDATA.request (6.8.1)
9 for the frame that triggered the creation of the SFCM.
10 52.5.3.3.9 Encapsulated MSDU length
11 This field, 16 bits in length, shall contain the length of the encapsulated MSDU field. If the length is 0 no
12 encapsulated MSDU is included. If an MSDU is encapsulated, the minimum value is 28 and the maximum
13 value is 512.
14 52.5.3.3.10 Encapsulated MSDU
15 Thisfield, a minimum of 28 octets and a maximum of 512 octets in length, contains the

16 mac_server_data_unit parameter of the EM_UNITDATA.request (6.8.1) for the frame that triggered the
17 creation of the SFCM.
18 52.5.3.4 SFCM Validation
19 A SFCM PDU received by an SFCM demultiplexer (52.3.3) shall be considered invalid and discarded if any
20 of the following condition are TRUE:
21

a)

22

An option TLV is present with the requires MSDU field set to 1 and there are fewer than 28 octets inthe Encapsulated MSDU or greater than 512.

23 The following condition shall not cause a received SFCM PDU to be considered invalid:
24
25

a)
b)

There are nonzero bits in the Version (52.4.3.4.1) field.
There are nonzero bits in the reserved fields of the SFCM PDU.

26 52.5.4 LLDP Source Flow Control TLV
27 <<TBD>>

33
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1 52.5.4.1 LLDP Source Flow Control TLV Procedures
2 <<TBD>>
3

34
This is an individual contribution, subject to change.

October 26, 2022

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control

1

Annex Z(temporary not for publication)2(temporary not for publication)

3

Commentary

October 26, 2022

Commentary

4 This is a temporary Annex, a place to record outstanding or recent technical issues and their disposition. It
5 will be removed prior to SA Ballot. Because this is not a part of the proposed standard the editor will not
6 accept comments on the text of this Annex itself, only on the issues raised. Discussion and resolution of the
7 issues will result in modification of the contents.
8 The order of discussion of issues is intended to help the reader understand first what is the draft, secondly
9 what may be added, and thirdly what has been considered but will not be included. In pursuit of this goal,
10 issues where the proposed disposition is “no change” will be moved to the end. The description of issues is
11 updated to reflect our current understanding

1 of the problem and its solution: where it has been considered

12 useful to retain an original comment, in whole or part, either to ensure that its author does not feel that it has
13 not been sufficiently argued or the editor suspects there may be further aspects to the issue, that has been
14 done as a footnote.

15

Z.1 VLAN in SFCM

16 The VLAN header information of the congesting packet is not part of the MSDU. SFCM are sent using the
17 same VLAN information the original, congesting packet has been received on.
18 However, carrying the VLAN in the SFCM frame (is perhaps) unnecessary since the actual sender of the
19 flow might be on a totally different VLAN. Each router hop along the way will potentially need to modify
20 the VLAN ID, just as it does the DA/SA MAC addresses. The routing table at each hop will be consulted to
21 properly route the packet back to the source, and the routing table relationship to a VLAN is hop-by-hop
22 dependent. Since the original packet was routed to the destination, the SFCM in the reverse direction is
23 assumed to also be routable back to the source. It isn’t clear that the VLAN has any relevance.
24 Resolution: To be resolved

25

Z.2 SFCM caching security considerations

26 An SFCM could block a DSCP/TC value across the whole network by using a 0/0 network prefix. A
27 misbehaving congestion point, or perhaps an attacher that is masquerading as the congestion point could
28 send an SFCM that could lead to denial of service.
29 Resolution: As part of SFCM validation a configurable minimum prefix length could be checked against
30 configuration. The data center is considered a single managed domain and congestion points within that
31 domain will need to have some level of trust. Stations masquerading as congestion points would need to be
32 block or mitigated using any security mechanism that prevents an impostor from sending control frames in
33 the network.

1
This annex is not intended therefore to be a complete historical record of the development of the draft. The formal record comprises
the retained drafts and dispositions of comments.

35
This is an individual contribution, subject to change.

IEEE P802.1Qdw/D0.0
Draft Standard for Local and metropolitan area networks—Bridges and Bridged Networks—
Amendment: Source Flow Control
1

October 26, 2022

Z.3 SFCM Authentication

2 How do we prevent unauthorized senders to inject SFCM into the network. Related to Z.2 above.
3 Resolution: Assume the switches in the network can be trusted. If NICs are controlled by the network
4 operator, they are to be trusted as well. Use ACLs on ports on the network connecting to non-trusted devices.
5 Use mechanisms that work today
636This is an individual contribution, subject to change.