110 likes | 265 Views
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:
E N D
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: • 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).
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.
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.
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.
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.
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.
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.
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.
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.