1 / 12

Provider Bridge support for Drop Precedence

Provider Bridge support for Drop Precedence. Arjan de Heer IEEE802.1 Interim meeting January 2004. QoS in 802.1D/Q. The QoS for a frame is realized by: Defining a mapping of p-bits values into queues Selecting a scheduling mechanism Current 802.1D defines:

nat
Download Presentation

Provider Bridge support for Drop Precedence

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. Provider Bridge support for Drop Precedence Arjan de Heer IEEE802.1 Interim meeting January 2004

  2. QoS in 802.1D/Q • The QoS for a frame is realized by: • Defining a mapping of p-bits values into queues • Selecting a scheduling mechanism • Current 802.1D defines: • A recommended mapping of p-bits values into queues (depending on the number of available queues) • Strict priority scheduling as the default algorithm for the scheduler • If the default QoS settings do not suit your needs, you can: • Change the mapping • Change the scheduling mechanism • Use DP encoding (future) • Changing these settings should be done consistently throughout the whole network Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  3. Dropping Precedence • Dropping Precedence is not supported in current standards, there are two options on the table: • Encode the DP in the p-bits • Encode the DP in the CFI bit • Whatever option is chosen, the default configuration of the bridge should remain according to the current 802.1D/Q, to ensure proper interworking in default configuration • CFI bit set to 0, when adding tag • Ignore CFI bit (should be 0) on received frames • Perform recommended p-bits to queue mapping Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  4. Using p-bits or CFI bit? • backwards compatibility with ‘default’ bridges is used as an argument used to advocate for both options • Maintaining desired levels of Service using your own QoS scheme, while connecting bridges in default configuration is most unlikely • So what is the benefit of this backwards compatibility? • Support both encoding in p-bits and in CFI bit in the standard • Interworking should be simple • Interworking is guaranteed by the requirement that a bridge using the CFI bit must suppor p-bits/CFI bit remapping at all of its ports • Default re-mapping sets CFI bit to 0 (or does not change anything?) Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  5. Using CFI-bit • Current proposal: CFI=0 (low DP, green frame), CFI=1 (high DP, yellow frame) • The reason for this is that it gives green frames a higher chance to get through a non-standard bridge that does drop frames with CFI=1. • New proposal: CFI=1 indicates low DP (green frame), CFI=0 indicates high DP (yellow frame) • Without provisioning a bridge only sees frames with CFI=0 (like normal bridges), they are all treated the same by a non DP bridge • Suppose we have a DP aware (CFI bit) network supporting several services • we add a bridges that support DP encoding in P-bits at the edge • But we forget to program the re-mapping table at the CFI bridge • ‘CFI’ bridge will only receive yellow frames (CFI=0) from CFI/DPI ‘p-bits’ bridge, least impact on existing services Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  6. Using p-bits • Encoding DP in p-bits requires one to: • Combine two p-bit values in one priority • Define which value indicates Low DP and which High DP • Any pair of values can be combined, and any of the two can be used to indicate low DP • This requires provisioning: • To map both p-bits values into the same queue • For the queue, what value indicates the high DP (yellow frame) and what value indicates the low DP (green frame) Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  7. Current p-bits proposal • Current proposal: • Combine p-bit values such that the chance to get reordering because of bridges in default mode is minimized • This implies combining 1 and 2. However this has the disadvantage that this class is treated with the least priority by default • Reordering still possible, depending of number queues in ‘default’ bridge Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  8. New p-bits proposal • Use LSB p-bit to indicate dropping precedence, set is low DP (green frame), reset is high DP (yellow frame). • Combining 0&1, 2&3, 4&5, 6&7 with the lower value indicating high DP (yellow) • Simple to implement • Marking always means setting bit to 0 • queues that use DP, simply look at the last bit • Similar to use of CFI bit • But this may lead to reordering when not provisioning part of the network. Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  9. Proposal • Default mapping of priorities into queues remains the same • Bridges that support CFI bit DP encoding must support remapping of the CFI and DP bit at each port. By default this table does always set CFI bit to 0. • Each queue can be provisioned to take DP into account: • This can mean either look at LSB p-bit or CFI bit • Default is not to look at it • DPbit=1 indicates low DP (green frame) • Optionally: To support other encodings of DP in p-bits, each queue can be provisioned with a value for high and a value for low DP. Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  10. Standard • Provider Bridge may support DP • If supported, DP must be provisionable per queue • Default should be no support of DP for all queues • May support encoding in p-bits or CFI bit • If encoding in p-bits • Must support using the LSB for DP encoding • May support other encodings • LSB/CFI=1 indicates low DP (green), LSB/CFI=0 indicates high DP (yellow) • Provider Bridge may have priority + CFI bit re-map table at each port • Default table does always set CFI to 0 • If DP is encoded in CFI bit, the provider bridge must have such a table Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  11. If preventing problems with existing bridges is important • CFI-bit encoding • CFI=0 low DP (green frame), CFI=1 high DP (yellow) frame • Still mandatory Priority/CFI re-mapping table at each port • P-bit encoding • Support combination of 1&2, 0&3, 4&5, 6&7 with lower value indicating higher DP(yellow frames). • DP encoding different from proposal from last meeting, but this gives green frames higher priority if ending up in different queue than yellow frames • May support other encodings Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

  12. If preventing problems with existing bridges is important • Provider Bridge may support DP • If supported, DP must be provisionable per queue • Default should be no support of DP for all queues • May support encoding in p-bits or CFI bit • If encoding in p-bits • Must support the combination of 1&2, 0&3, 4&5, 6&7 with the lower value indicating the higher DP (yellow frame) • May support other encodings • If encoding using CFI bit CFI=0 indicates low DP (green frame), CFI=1 indicates high DP (yellow frame) • Provider Bridge may have priority + CFI bit re-map table at each port • Default table does always set CFI to 0 • If DP is encoded in CFI bit, the provider bridge must have such a table Provider Bridge Support for Drop Precedence - IEEE802.1 Interim meeting, January 2004

More Related