Transcript L2 Packet Marking_2_Haddock

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).
2
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.
3
Drop Precedence vs Class of Service

Drop Precedence is not an indication of Priority or Class of Service



Drop precedence may be changed in transit as the relationship in
time to other packets changes.



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.
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.
4
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 misordering of frames. Encoding drop_precedence in the 802.1p bits
would require all bridges in the network to perform the same mapping.
5
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 UserVLAN 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.
6
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.
7
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 misordering packets.
8
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.
9
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.
10
Drop
Precedence
Explicit in CFI
Implicit in .1p
# of Classes and
Drop levels
Up to 8 classes w/ drop
precedence available in
each
Less than 8 classes w/
drop precedence
available in some
Compatibility w/
IP (DSCP)
Map between 6 bit DSCP Map between 6 bit DSCP
and 3 bit class + 1 bit
and 3 bit encoded class
“explicit” drop
and “implicit “ drop
Compatibility w/
MPLS
Map between 3 bit EXP
and 3 bit class + 1 bit
“explicit” drop
Map (or copy) 3 bit EXP
and 3 bit encoded class
and “implicit” drop
Consequence of
packets w/ drop
marking arriving
at 802.1Q
bridges
Drop Precedence not
supported: Yellow
packets either dropped
or treated the same as
green.
No risk of misordering.
Drop Precedence not
supported: Yellow
packets either treated the
same as green or, if
inconsistent
configuration, yellow and
green may be
misordered.
11