1 / 32

802.1ad Drop Precedence Architecture Proposal v3

802.1ad Drop Precedence Architecture Proposal v3. Stephen Haddock March 16, 2004. DE. DE. PRI. PRI. MAC. MAC. Network. Network. Bridge Model. Relay. EISS. Assume that the EISS carries a 3-bit Priority parameter (PRI) and a single bit Drop Eligible parameter (DE).

igibson
Download Presentation

802.1ad Drop Precedence Architecture Proposal v3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. DE DE PRI PRI MAC MAC Network Network 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. DE DE PRI PRI Drop Precedence Relay Model 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. DE PRI S-TAG S-TAG MAC MAC Network Network Bridge Model DE Relay PRI EISS • Now consider how to encode PRI:DE in the S-TAG.

  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. PRI only Bridge 7 6 5 4 3 2 1 0 Identical to 802.1Q Traffic Class Mapping Proposed default DP mapping: Encoded Value PRI only Bridge PRI w/ DP Bridge 7: 6: 5: 4: 3: 2: 1: 0: 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

  14. 802.1Q-2003

  15. 802.1D – Appendix G, Table G-2

  16. BK BK BK BE BE BE BE BE CL CL CL VO VO VO VO 802.1D Table G-3

  17. 8q 5q 6q 7q 4q Allowable pairings for drop precedence 2 2 2 2 2 2 2 2 0 0 0 0 0 0 0 0 4 4 4 4 4 4 4 4 6 6 6 6 6 6 6 6

  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. 8q 5q 6q 7q 4q If we can change table 8-2 … 0 0 0 0 0 0 0 0 2 2 2 2 2 2 2 2 4 4 4 4 4 4 4 4 6 6 6 6 6 6 6 6

  20. Default drop precedence table 0 0 2 2 2 4 4 4 4 6

  21. BE BE BE BE EE EE EE BE CL CL CL CL CL CL VO VO New table G-3 (with color)

  22. 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 New default EISS mapping: Encoded Tag Field PRI : DE Ingress EISS 6:G 6:Y 4:G 4:Y 2:G 2:Y 0:G 0:Y 7 6 5 4 3 2 1 0

  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. 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. Mapping Example 1 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

  28. 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?) Mapping Example 2 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

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

  31. 802.1D – Appendix G, Table G-1

  32. 802.1D – Appendix G, Table G-3

More Related