802.1ad Drop Precedence Architecture Proposal

1
802.1ad Drop Precedence Architecture Proposal

• Stephen Haddock
• March 16, 2004

2
Bridge Model
Relay
EISS

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

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
Ingress
Transmission
Queuing
Forwarding
0 or more Ingress Flow Meters
1 to 8 Traffic Class Queues
Scheduler
5
Ingress Rules (discussion points)

1. Zero or more flow meters may be implemented per
   ingress port.
2. Meters do not change the PRI value.
3. 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).
4. If flow meters are implemented, not all flows are
   required to go through a meter.
5. The DE value shall not be changed for packets not
   going through a meter.
6. Flow meters may be buffered (shaper) or
   unbuffered (policer).
7. 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)

1. Zero or more flow meters may be implemented per
   ingress port.
2. Meters do not change the PRI value.
3. 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).
4. If flow meters are implemented, not all flows are
   required to go through a meter.
5. The DE value shall not be changed for packets not
   going through a meter.
6. Flow meters may be buffered (shaper) or
   unbuffered (policer).
7. 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)

1. One to eight queues may be implemented per egress
   port.
2. 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.
3. 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, )
4. Queues may discard packets. The probability of
   dropping a packet with DE set shall be greater
   than or equal to the probability of dropping a
   packet with DE clear.
5. Queues shall not change the PRI value or the DE
   value.

8
Transmission Rules (incorporate in 8.6.6)

1. As specified in 802.1D-2004 a strict priority
   scheduling algorithm shall be supported, and
   other scheduling algorithms may be supported.
2. The scheduler shall not change the PRI value.
3. 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 PRIDE combinations that are
  supported is 8 or fewer, an implementation may
  choose to carry PRIDE through the Relay in a 3
  bit field.
• There is a potential loss of information in
  encoding PRIDE to a 3 bit field, but no more so
  than occurs when encoding PRIDE 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
DE
Relay
PRI
EISS

• Now consider how to encode PRIDE in the S-TAG.

12
Encoding Conclusions from conf calls

• If figure out how to make PRIDE 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
802.1Q-2003
14
Proposed default mapping
PRI only Bridge
PRI w/ DP Bridge
Encoded Value
7 6 5 4 3 2 1 0
6/7 green 6/7 yellow 4/5 green 4/5 yellow 0/3
green 1/2 green 1/2 yellow 0/3 yellow
7 6 5 4 3 2 1 0
15
Proposed default EISS mapping
PRI DE Ingress EISS
Encoded Tag Field
7G 7Y 5G 5Y 3G 2G 2Y 3Y
7 6 5 4 3 2 1 0
16
Old Slides
17
Encoding PRIDE in the S-tag

• Using the old CFI bit for DE in the S-tag allows
  PRIDE to be carried without loss of information.
• But does not grandfather in existing equipment.
• Encoding PRIDE 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 PRIDE.
• There will be a loss of information bridging
  between LANs that use different mappings between
  PDP and PRIDE.
• It is possible to allow both as configurable
  options.
• Is support of one mode required and the other
  optional? If so, which is required?

18
Mapping observations -- 1

• Things will just work if constrain all ports
  use the same mapping between PDP and PRIDE.
• PDP ? PRIDE ? 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.)

19
Proposed Mapping Rules

• Packet order within a priority shall be
  maintained
• Means two values of PRIDE 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 PRIDE 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?

20
Mapping Example 1

• 8/0 port
• 7 Priority7
• Priority6
• 5 Priority5
• 4 Priority4
• 3 Priority3
• 2 Priority2
• 1 Priority1
• 0 Priority0

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

• 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

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
21
Mapping Example 2

• A 6/2 port
• 7 Control
• VoIP
• 5 EF
• 4 AF1-G
• 3 AF1-Y
• 2 AF2-G
• 1 AF2-Y
• 0 Default

• 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?)

• B 6/2 port
• 7 Control
• Platinum
• 5 Gold-G
• 4 Gold-Y
• 3 Gaming
• 2 Silver-G
• 1 Silver-Y
• 0 Other

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
22
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?

23
Note on placement of PRIDE PDP mapping function

• Ive assumed it is between the ISS and EISS
  (therefore in section 6.x of 802.1ad) so the
  PRIDE 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 8.6.1 and 8.6.6 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.