1. 802.1ad Drop Precedence Architecture Proposal v3
Stephen Haddock
March 16, 2004

2. Bridge Model
MAC
MAC
Relay DE
PRI DE
PRI
EISS
Network
Network
Assume that the EISS carries a 3-bit Priority parameter (PRI) and a single bit Drop Eligible parameter (DE).
PRI is identical to the current priority parameter.
Discuss how these parameters are generated at each port later – focus on the drop precedence functionality in the Relay first.
The architectural model of an 802.1D bridge is a set of MACs interconnected by a MAC Relay Entity. The MAC Relay Entity consists of a Learning Process, a Filtering Data Base, and a Forwarding Process. The interface between the MAC Relay Entity and the MACs is the Internal Sublayer Service (ISS). The ISS separates the received data frame into parameters that are passed to the MAC Relay Entity, and creates a transmit data frame from parameters that are passed from the MAC Relay Entity. For frames the relevant parameters are:
destination_address
source_address
mac_service_data_unit (body of the frame that is theoretically opaque to the Relay, beginning with the first byte after the Source Address and ending with the last byte before the FCS)
frame_check_sequence

3. Objectives
Maintain current frame ordering constraints
The probability of dropping a yellow frame (DE set) shall be greater than or equal to the probability of dropping a green frame (DE clear) in the same traffic class.
Never promote yellow (DE set) to green (DE clear).
Relative priority between any two frames will never be reversed. (mapping to equal priority is OK).

4. Drop Precedence Relay Model
PRI DE
PRI
Ingress
Forwarding
Queuing
Transmission
0 or more
Ingress
Flow
Meters
1 to 8
Traffic
Class
Queues
Scheduler

5. Ingress Rules (discussion points)
Zero or more flow meters may be implemented per ingress port.
Meters do not change the PRI value.
No restrictions on how an individual packet is directed to a specific flow meter (e.g. may be based on S-VID, PRI, a combination thereof, or something else).
If flow meters are implemented, not all flows are required to go through a meter.
The DE value shall not be changed for packets not going through a meter.
Flow meters may be buffered (shaper) or unbuffered (policer).
Flow meters may set the DE parameter and may drop packets, but shall not clear the DE parameter.

6. Ingress Rules (incorporate in 8.6.1)
Zero or more flow meters may be implemented per ingress port.
Meters do not change the PRI value.
No restrictions on how an individual packet is directed to a specific flow meter (e.g. may be based on S-VID, PRI, a combination thereof, or something else).
A bridge supporting metering at a given port shall be capable of metering at line rate.
Not all flows are required to go through a meter, but at a minimum, a bridge supporting metering at a given port should be capable of metering all the frames received on that port. Finer grain metering may be supported.
The DE value shall not be changed for packets not going through a meter.
Flow meters may be buffered (shaper) or unbuffered (policer).
Flow meters may set the DE parameter and may drop packets, but shall not clear the DE parameter.

7. Queuing Rules (incorporate in 8.6.5)
One to eight queues may be implemented per egress port.
Individual packets are directed to a specific queue according the PRI bits and the priority-to-traffic-class mapping table currently specified in 802.1D-2004.
Some or all queues may implement a drop precedence aware queue management algorithm (e.g. queue depth threshold for packets with DE set, RED, WRED, …)
Queues may discard packets. When drop precedence is supported, the probability of dropping a packet with DE set shall be greater than the probability of dropping a packet with DE clear.
Queues shall not change the PRI value or the DE value.
There may be meters in front of the queues. If these meters are implemented, they may set the DE value.

8. Transmission Rules (incorporate in 8.6.6)
As specified in 802.1D-2004 a strict priority scheduling algorithm shall be supported, and other scheduling algorithms may be supported.
The scheduler shall not change the PRI value.
An optional scheduling algorithm may incorporate a flow meter (i.e. rate-based scheduling or shaping). Such a scheduler may set the DE parameter. Otherwise The DE parameter is not modified by the scheduler.

9. Minimal Implementation
Minimal compliant implementation has no drop precedence awareness:
Zero flow meters at any ingress port.
One to eight queues at each egress port with no drop precedence aware queue management algorithms.
No rate based scheduling algorithms, or at least no algorithms that modify the DE value.
Therefore the PRI and DE values pass through the Relay unchanged.
Only change from an 802.1D-2004 compliant bridge is the ability to carry the DE value through the Relay.

10. Implementation Consideration
Just as a 802.1D bridge may support fewer than 8 traffic classes, and 802.1ad bridge may support fewer than 8 traffic classes and only a subset of those traffic classes support drop precedence.
If the number of PRI:DE combinations that are supported is 8 or fewer, an implementation may choose to carry PRI:DE through the Relay in a 3 bit field.
There is a potential loss of information in encoding PRI:DE to a 3 bit field, but no more so than occurs when encoding PRI:DE as a 3 bit field in a S-tag.
Therefore the difference between this implementation and the architectural model is not externally observable, so it is an allowed implementation.

11. Bridge Model Now consider how to encode PRI:DE in the S-TAG. Relay MAC
EISS
Network
Network
Now consider how to encode PRI:DE in the S-TAG.
The architectural model of an 802.1D bridge is a set of MACs interconnected by a MAC Relay Entity. The MAC Relay Entity consists of a Learning Process, a Filtering Data Base, and a Forwarding Process. The interface between the MAC Relay Entity and the MACs is the Internal Sublayer Service (ISS). The ISS separates the received data frame into parameters that are passed to the MAC Relay Entity, and creates a transmit data frame from parameters that are passed from the MAC Relay Entity. For frames the relevant parameters are:
destination_address
source_address
mac_service_data_unit (body of the frame that is theoretically opaque to the Relay, beginning with the first byte after the Source Address and ending with the last byte before the FCS)
frame_check_sequence

12. Encoding: Conclusions from conf calls
If figure out how to make PRI:DE encoded in 3 bit field work, then should be simple to add option use CFI for DE.
Encoding issues are very simple if every bridge uses the same encoding, but need to consider the case where connecting “domains” that use different encoding.
Having a restricted set of allowed mappings is acceptable. There should also be specified default mappings (similar to the current priority-to-traffic-class mapping table).

13. Proposed default DP mapping:
Encoded
Value
PRI only
Bridge
PRI w/ DP
Bridge 7 6 5 4 3 2 1
PRI only
Bridge 7: 6: 5: 4: 3: 2: 1: 0: 7 6 5 4 3 2 1
6/7 green
6/7 yellow
4/5 green
4/5 yellow
0/3 green
1/2 green
1/2 yellow
0/3 yellow
Identical to 802.1Q
Traffic Class Mapping

14. 802.1Q-2003

15. 802.1D – Appendix G, Table G-2 user_priority Acronym Traffic type 1 BK
Background 2 -
Spare
0 (Default) BE
Best Effort 3 EE
Excellent Effort 4 CL
Controlled Load 5 VI
Video, < 100 ms delay 6 VO
Voice, <10 ms delay 7 NC
Network Control

16. 802.1D Table G-3 8tc 7tc 6tc 5tc 4tc 3tc 2tc 1tc 1 BK 2 -- BE 3 EE 4
User
Pri
8tc
7tc
6tc
5tc
4tc
3tc
2tc
1tc 1 BK 2 -- BE 3 EE 4 CL 5 VI 6 VO 7 NC VO CL BE BK

17. Allowable pairings for drop precedence
8tc w/ 0dp
7tc w/
1dp
6tc
2dp
5tc
3dp
4tc w/ 4dp 1 2 3 4 5 6 7 2 2 2 2 2 2 2 2 4 4 4 4 4 4 4 4 6 6 6 6 6 6 6 6 8q 5q 6q 7q 4q

18. If we can change Table 8-2 …
Swap priority 0 and 2
Current table has two traffic classes that are lower priority than the default priority
1=“background” and 2=“spare” are lower than 0=“best effort”
Change would make only one traffic class lower priority than the default
Select new default for the cases where there are 7, 6, and 5 traffic classes

19. If we can change table 8-2 …
8tc w/ 0dp
7tc w/
1dp
6tc
2dp
5tc
3dp
4tc w/ 4dp 1 2 3 4 5 6 7 2 2 2 2 2 2 2 2 4 4 4 4 4 4 4 4 6 6 6 6 6 6 6 6 8q 5q 6q 7q 4q

20. Default drop precedence table
8tc w/ 0dp
7tc w/
1dp
6tc
2dp
5tc
3dp
4tc w/ 4dp 1 2 3 4 5 6 7 2 2 2 4 4 4 4 6

21. New table G-3 (with color)
8tc w/ 0dp
7tc w/
1dp
6tc
2dp
5tc
3dp
4tc w/ 4dp
3tc w/ 3dp
2tc w/ 2dp
1tc w/ 1dp BK BE -- EE CL VI VO NC VO CL EE BE

22. New default EISS mapping:
PRI : DE
Egress EISS
7:G
6:G
5:G
4:G
3:G
2:G
1:G
0:G
7:Y
6:Y
5:Y
4:Y
3:Y
2:Y
1:Y
0:Y
Encoded
Tag Field
PRI : DE
Ingress EISS 7 6 5 4 3 2 1
6:G
6:Y
4:G
4:Y
2:G
2:Y
0:G
0:Y

23. Old Slides

24. Encoding PRI:DE in the S-tag
Using the old CFI bit for DE in the S-tag allows PRI:DE to be carried without loss of information.
But does not “grandfather in” existing equipment.
Encoding PRI:DE in what is currently the 3-bit priority field of the S-tag (call it the Priority/Drop-Precedence or PDP field) is friendlier to existing equipment.
All ports connected to a LAN must use the same mapping between PDP and PRI:DE.
There will be a loss of information bridging between LANs that use different mappings between PDP and PRI:DE.
It is possible to allow both as configurable options.
Is support of one mode required and the other optional? If so, which is required?

25. Mapping observations -- 1
Things will “just work” if constrain all ports use the same mapping between PDP and PRI:DE.
PDP  PRI:DE  PDP mapping does not result in any lost information.
If ports on each end of a network link need to use the same mapping , the it follows that all ports of all bridges on a network use the same mapping.
Interoperability only assured if all switches must support all possible mappings, or if a constrained set of required mappings is specified.
But are we willing to live with the constraint that all ports of all bridges connected in a network must have the same mapping? (Particularly problematic at connection between two different Service Providers.)

26. Proposed Mapping Rules
Packet order within a priority shall be maintained
Means two values of PRI:DE that differ only in the DE value cannot be mapped to two PDP values that are interpreted as having different priority.
Relative priority between packets shall be maintained through all mapping tables
No packet that is initially tagged as higher priority than a second packet shall ever be mapped in a fashion that tags it a lower priority than the second packet.
When two values of PRI:DE that differ only in DE are mapped to a single PDP, packets with DE set may be transmitted (effectively clearing DE) or discarded.
Do we specify discard vs. transmit in the standard, or let the implementation decide, or mandate that an implementation must be configurable to do either?

27. Mapping Example 1 8/0 port 4/4 port
7 Priority7
Priority6
5 Priority5
4 Priority4
3 Priority3
2 Priority2
1 Priority1
0 Priority0
4/4 port
7 Gold-G
Gold-Y
5 Silver-G
4 Silver-Y
3 Bronze-G
2 Bronze-Y
1 Lead-G
0 Lead-Y
PRI information is permanently lost going from 8/0 to 4/4.
DE information is lost (or packets are discarded) going from 4/4 to 8/0.
Traffic going between a 8/0 port and a 4/4 port get the same effective behavior as if both ports were 4/0.
Key:
m/n  m Priority values of which
n have Drop Precedence.
G (Green)  low discard probability.
Y (Yellow)  high discard probability.
Dashed arrow  map or discard

28. Mapping Example 2 A 6/2 port B 6/2 port
7 Control
VoIP
5 EF
4 AF1-G
3 AF1-Y
2 AF2-G
1 AF2-Y
0 Default
B 6/2 port
7 Control
Platinum
5 Gold-G
4 Gold-Y
3 Gaming
2 Silver-G
1 Silver-Y
0 Other
PRI information is permanently lost going from A port to B port.
EF traffic that travels from network A through B and back to A will end up higher priority than EF traffic local to A.
(Conceivable that traveling A  B  C  B  A could result in a packet originally at EF ending up at Control, thus violating Mapping Rule 2.)
Alternative mapping would map EF to Gold and AF1 to Gaming, resulting in a loss of DE information instead of PRI.
(Should one of these mapping alternatives be required by the standard?)
Key:
m/n  m Priority values of which
n have Drop Precedence.
G (Green)  low discard probability.
Y (Yellow)  high discard probability.
Dashed arrow  map or discard

29. Issues
Investigating the consequences of going from any given mapping to any other gets complex, and leads to network behavior that is certainly not obvious and possibly not desirable.
Are the Proposed Mapping Rules sufficient to preserve interoperability (and hopefully sanity)?
Do we need further rules (such as “when collapsing two PRI values to one PDP, always map to a PDP which is interpreted as the higher of the two priorities”)?
Do we try to describe the network behavior resulting from various mapping combinations, or do we let Service Providers sort it all out?
Should we simplify the situation by specifying a small set of mappings that must be supported, or would that undermine the implicit objective of grandfathering existing equipment?

30. Note on placement of PRI:DE – PDP mapping function
I’ve assumed it is between the ISS and EISS (therefore in section 6.x of 802.1ad) so the PRI:DE values are passed across the EISS.
It could as easily go on the other side of the EISS in the Ingress and Transmission portions of the Relay (sections and respectively) which means the PDP value is passed across the EISS.
There is precedent for either solution:
The VID value passed across the EISS is taken exactly from the packet if tagged or priority-tagged, or null if untagged. It is translated to the default PVID or port-protocol ID in the Ingress portion of the Relay.
The current priority value is taken from a tagged packet or, if packet is untagged, is “regenerated” prior to being passed across the EISS.
The functionality is the same either way.

31. 802.1D – Appendix G, Table G-1 # of Qs Traffic Types 1
{BK, BE, EE, CL, VI, VO, NC} 2
{BK, BE, EE} {CL, VI, VO, NC} 3
{BK, BE, EE} {CL, VI} {VO, NC} 4
{BK} {BE, EE} {CL, VI} {VO, NC} 5
{BK} {BE, EE} {CL} {VI} {VO, NC} 6
{BK} {BE} {EE} {CL} {VI} {VO, NC} 7
{BK} {BE} {EE} {CL} {VI} {VO} {NC}

32. 802.1D – Appendix G, Table G-3 # of Qs Defining Traffic Type 1 BE 2 VOCL 4 BK 5 VI 6 EE 7 NC 8 -
Priority 