1 / 11

L2 Packet Marking for Drop Precedence Stephen Haddock May 6, 2003 (updated November 10, 2003)

L2 Packet Marking for Drop Precedence Stephen Haddock May 6, 2003 (updated November 10, 2003). Why mark drop precedence?. Allows a service provider to offer dual-rate service analogous to that enabled by IETF RFC 2597 Assured Forwarding for Differentiated Services, without requiring:

thalia
Download Presentation

L2 Packet Marking for Drop Precedence Stephen Haddock May 6, 2003 (updated November 10, 2003)

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. L2 Packet Marking for Drop Precedence Stephen Haddock May 6, 2003 (updated November 10, 2003)

  2. Why mark drop precedence? • Allows a service provider to offer dual-rate service analogous to that enabled by IETF RFC 2597 Assured Forwarding for Differentiated Services, without requiring: • A) that customer traffic be IP packets, and • B) the service provider to modify customer packets beyond the addition/removal of the provider tag. • The value proposition of a dual-rate service is: • A) Customer traffic up to a specified rate (typically called a Committed Rate) is accepted on the provider network with a high probability of delivery. • B) Customer traffic exceeding the committed rate will be accepted on the provider network with a lower probability of delivery (higher drop precedence).

  3. Typical Marking Mechanisms • A traffic stream of packets are “colored” to indicate their drop precedence using a 2-rate 3-color marker: • Packets are colored green if they conform to a token bucket profile defined by a Committed Rate and Committed Burst Size. • Packets are colored yellow such that the sum of green and yellow packets conform to a token bucket profile defined by a Peak Rate and Peak Burst Size. • Remaining packets are colored red. • In the presence of congestion, red packets are dropped with a higher probability than yellow, which in turn are dropped with a higher probability than green. • In a network supporting two levels of drop precedence, all red packets are dropped.

  4. Drop Precedence vs Class of Service • Drop Precedence is not an indication of Priority or Class of Service • Priority/CoS may be assigned on the basis of an application, a user, or other criteria, but once assigned becomes an intrinsic property of the packet. • Drop precedence is a temporal property of the frame, depending solely upon the relationship in time to other frames in the same class, as compared to a token bucket profile. • Drop precedence may be changed in transit as the relationship in time to other packets changes. • Congestion points can cause an increase in “burstiness” which may cause remarking to a higher drop precedence. • Shaping may allow remarking to a lower drop precedence. • Order need not be maintained between frames with different priority/CoS marking, however order must be maintained between frames with different drop precedence marking.

  5. Don’t use user_priority bits for Drop Precedence • Encoding both priority/CoS and Drop Precedence on the user_priority bits is not compliant with 802.1D. • Redefining “user_priority” to encode both priority/CoS and Drop Precedence would ripple throughout document and the standards for all MACs that carry user_priority. • Especially troublesome in changing ordering constraints and queue assignment. • Could redefine the Provider Tag so that the “802.1p” bits do not contain “user_priority”, but a bit-field that maps to user_priority and drop_precedence. Issue is: • Reduces the number of available classes of service. • Currently the mapping from 802.1p bits to queues can be done independently at every bridge in the network without causing mis-ordering of frames. Encoding drop_precedence in the 802.1p bits would require all bridges in the network to perform the same mapping.

  6. Proposed Marking Mechanism for Provider Bridges • Drop Precedence marking should be independent/orthogonal to user_priority. • A single bit is sufficient to provide two levels of drop precedence, which is sufficient to enable a dual-rate (Committed and Peak) service. • There is no need for the 802.1Q Canonical Format Indicator in a Provider Tag. • If a packet requiring the CFI bit set has a User-VLAN tag, there is no added information in replicating that bit in a Provider Tag. • Require that any packets requiring a CFI bit contain a User-VLAN tag when transported across a Provider Bridged Network • For Provider Tags, define the bit between the Priority and ID fields (the CFI bit of a VLAN tag) to be a Drop Precedence bit.

  7. Backward Compatibility Issues • What do existing bridges do if CFI is set? • Non-standard option 1: Ignore the CFI bit. • Drop precedence not supported. • Cannot guarantee green transported preferentially. • Non-standard option 2: Discard if CFI is set. • Drop precedence not supported. • Green always transported, but yellow always dropped. • Non-standard option 3: Always transmit CFI=0. • Same as #1. • Standard (802.3): Ignore unless de-tagging, then discard. • Same as #1 in core, same as #2 at edge.

  8. Backwards Compatibility Comparison • Encoding Drop Precedence into Traffic Class: • BEST: Properly configure Traffic Class to queue mappings in each switch: • Yellow packets treated same as green • WORST: Default configuration (or mis-configuration): • Packets are mis-ordered • Using CFI bit for Drop Precedence • BEST and WORST: Drop precedence not supported: • Yellow packets treated same as green, or • Yellow packets always discarded. • In all cases only a single rate service can be supported. The only difference is the risk of mis-ordering packets.

  9. Summary • Recommend using “CFI” bit in Provider Tags to indicate drop precedence. • Maintains the number of Traffic Classes supported by the current standard. • Retains “fool-proof” Traffic Class configuration properties of the current standard. • Any configuration of switches with any number of queues supported will not cause packet mis-ordering. • Consequence of having non-drop-precedence-aware bridges in the network is that multiple levels of drop precedence cannot be used.

  10. Relationship to MPLS • An MPLS label has 3 bits (EXP bits) available for encoding both Traffic Class and Drop Precedence • Encoding both properties into the 3 “802.1p” bits allows a one-to-one correspondence between the MPLS EXP and 802.1p bits. • Using the CFI bit would require a mapping between Ethernet TC/DP encoding and MPLS TC/DP encoding. • So what? If use the 802.1p bits then need a TC/DP mapping table everywhere. If use CFI then only need the mapping in switches supporting MPLS.

More Related