About
Marking Definition
Marking is similar conceptually to "service class" designation on an airplane ticket: first, business, or economy. This value reflects the level (quality) of service you should receive. Similarly, we mark a value in a packet to indicate the service class (henceforth termed service-class) for that packet as it traverses the network. By examining the marked value, network elements can decide how to treat your packet.
People in business-class may have used a variety of means to achieve that designation. They may have paid extra, used airmiles, or been lucky and booked at the normal rate when no other seat was available. Elsewhere, someone performed the complex task of classification - determining eligibility for a particular service-class then marked the ticket with a mere designation: first-class, business-class, or economy-class. Flight-attendants are unconcerned with how eligibility was determined; they simply look at the class marked on the ticket and provide that level of service.
This dynamic plays out in the networking world. One device may perform complex classification on the data in a flow, determining an appropriate service-class. Other network elements "trust" the value marked in packets they receive and provide service appropriate for that designation.
Within the context of QoS packet processing, marking occurs after classification and before queuing and is applicable on ingress or egress.
Typically, you would create a trust boundary at the edge of the network, then classify and mark packets on the edge device. Then, you would use that marked field for classification and determination of per-hop treatment throughout the network.
 Note |
A trust boundary enables you to apply network-controlled marking on all packets as they enter the network and to remove or modify any non-default markings you did not apply. |
Imagine that your system recognizes router ports with attached VoIP devices. You could mark the differentiated services code point (DSCP) value of voice packets as EF (at the edge of the network) and employ DSCP-based classification throughout the network to determine those packets that warrant low latency treatment.
Why Mark Packets
Reasons for marking packets include the following:
-
Indicate the treatment you would like a packet to receive as it traverses the network.
-
Perform complex classification once. By marking the service class, you can use simpler, less cpu-intensive classification elsewhere in the network.
-
Perform classification at a point in the network where you have greater visibility into the flow. For example, if data is encrypted, you cannot perform complex classification such as determining the application carried within that flow. Instead, you could classify prior to encryption and mark a value in the unencrypted header that is visible to network elements along the path.
As a packet traverses networks managed by different autonomous entities (e.g., the service provider network between two enterprise offices), you may need to re-mark if the markings to service-level designations are inconsistent across those networks.
As a packet traverses different networking technologies the fields available to indicate service-class may differ. For example, you might carry service-class designation in the DSCP field of an IP packet but if this packet traverses an the multiprotocol label switching (MPLS) network only the MPLS experimental (EXP) field may be usable by network elements to determine service-class. As you enter that portion of the network, you may need to determine the appropriate marking of the MPLS EXP bits.
As a network operator you may contract to accept data from a user at a certain rate. Rather than dropping packets that exceed that rate, you can mark them as a lesser service-class.
Approaches to Marking Packets
You have two main approaches to marking packets: the set command and a policer marking action.
Note |
We only briefly touch upon "policing" actions within this chapter. |
set Command
The simplest approach to marking packets on a router is to use the set command in a policy-map definition. (A policy-map is where you specify a QoS action for each class of traffic that you have defined).
You may decide to classify all RTP ports into a traffic class and mark each packet with AF41. If so, the policy-map may look something like this:
policy-map mark-rtp
class rtp-traffic
set dscp af41
Policer Marking Action
Recall that you can use a policer to drop packets within a traffic class above a defined rate. Alternatively, you could mark packets above that rate and allow them to receive a different per-hop treatment than packets below that rate.
For example, let's say that video traffic arrives at your router marked AF41. You may decide to consider user traffic up to 2 Mbps top assured forwarding behavior and to demote any traffic exceeding 2Mbps to AF42 (and considered out of contract - non-conforming).
The policy-map might appear as follows:
class-map video-traffic
match dscp af41
!
policy-map enforce-contract
class video-traffic
police cir 2m conform-action transmit exceed-action set-dscp-transmit AF42
Scope of Marking Action
Similar to classification, marking cannot access every field within a data packet. For example, if an IP packet is encapsulated in multiprotocol label switching (MPLS), it cannot mark the DSCP within the IP header as that would require first de-capsulating from MPLS. However, you could mark the MPLS experimental (EXP) bits.
Note |
Only Layer 2 and outer Layer 3 headers are available for marking. |
Multiple Set Statements
You can configure multiple marking rules within a single class (or policer action). This allows you to mark both Layer 2 and Layer 3 fields within the same packet, or if multiple traffic types are present in the same class, define marking values for each type.
For example consider the following egress policy attached to an Ethernet subinterface:
policy-map mark-rtp
class rtp-traffic
set cos 4
set mpls exp topmost 4
set dscp af41
If an MPLS packet were forwarded through this subinterface, the Layer 2 COS field and the EXP bits in the MPLS header would be marked. If an IP datagram were encapsulated in that packet, its DSCP value would remain unchanged. However, if an IP packet were forwarded through the subinterface, its Layer 2 COS value and Layer 3 DSCP values would be marked.
For details, refer to the command pages for set cos, set mpls experimental topmost, and set dscp.
Marking Internal Designators
Cisco routers allow you to mark two internal values (qos-group and discard-class) that travel with the packet within the router but do not modify the packet's contents.
Typically, you mark these in an ingress policy and use them to classify to a traffic-class or WRED drop profile in an egress policy. For example, you may want to base your egress classification on a user's IP address but realize that encryption is configured and the user's IP address is invisible on an egress interface. You could classify their traffic on ingress (before encryption) and set an appropriate qos-group value. On egress, you could now classify based on the qos-group and choose the action accordingly.
Ingress vs. Egress Marking Actions
Certain marking values are only relevant to ingress or egress policies. For example, marking the ATM CLP bit or Frame Relay DE bit in an ingress policy is meaningless as they are discarded when the packet is decapsulated. Similarly, marking qos-group or discard-class in an egress policy is unproductive as these leave the packet unchanged and are discarded when we enqueue the packet for forwarding to the next hop.
Imposition Marking
Under special circumstances, you can mark a header field that has not yet been added to a packet (we term this behavior imposition marking).
The most common example of imposition marking is the application ofthe set mpls experimental imposition command - you can use it on an ingress interface where a packet may arrive containing an IP datagram and no multiprotocol label switching (MPLS) header. When and if the router encapsulates the datagram with a MPLS header, the EXP bits will be marked accordingly as specified by this command.
Application of the set dscp tunnel and set precedence tunnel commands (for IPv4 only) represent another example of imposition marking. If an egress policy is applied on a tunnel interface, no tunnel header exists when the policy executes. This means that any marking would apply to the original (eventually inner) IP header. Using either command, you can mark the tunnel (outer) IP header and leave the original header unchanged.
The following table lists the tunnel types and encapsulation variants that support these commands:
When a new header is added (encapsulated), any QoS marking in the inner header is copied to the outer header. For example, when an IP datagram is encapsulated with an MPLS header, the default behavior is to copy the IP Precedence bits from the IP header to the MPLS EXP bits in the newly-imposed header.
Regarding header disposition, we typically do not copy any outer marking(s) to the inner header. For example, at the endpoint for a GRE tunnel, let's say that we receive a packet with different DSCP values in the outer and inner IP headers. When we remove the outer header we do not copy its DSCP value to the inner header.
Feedback