Editing Differentiated services (section)

==Classification and marking==
Network traffic entering a DiffServ domain is subjected to classification and conditioning.  A traffic classifier may inspect many different parameters in incoming packets, such as source address, destination address or traffic type and assign individual packets to a specific traffic class.  Traffic classifiers may honor any DiffServ markings in received packets or may elect to ignore or override those markings.  For tight control over volumes and type of traffic in a given class, a network operator may choose not to honor markings at the ingress to the DiffServ domain. Traffic in each class may be further conditioned by subjecting the traffic to [[Rate limiting|rate limiters]], [[Traffic policing (communications)|traffic policers]] or [[Traffic shaping|shapers]].{{Ref RFC|2597|rsection=3}}

The per-hop behavior is determined by the DS and ECN fields in the IP header. The DS field contains the 6-bit DSCP value.{{Ref RFC|2474}} [[Explicit Congestion Notification]] (ECN) occupies the least-significant 2 bits of the IPv4 TOS field and IPv6 traffic class (TC) field.{{Ref RFC|6088}}<ref>{{cite web|author=Worldwide |url=http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml |title=Implementing Quality of Service Policies with DSCP |publisher=Cisco |access-date=2010-10-16}}</ref><ref>[https://blog.wireshark.org/2009/09/filtering-dscp/ Filtering DSCP] {{webarchive |url=https://web.archive.org/web/20160729035642/https://blog.wireshark.org/2009/09/filtering-dscp/ |date=July 29, 2016 }}</ref>

In theory, a network could have up to 64 different traffic classes using the 64 available DSCP values. The DiffServ RFCs recommend, but do not require, certain encodings. This gives a network operator great flexibility in defining traffic classes. In practice, however, most networks use the following commonly defined per-hop behaviors:
*''Default Forwarding'' (DF) PHB — which is typically best-effort traffic
*''Expedited Forwarding'' (EF) PHB — dedicated to low-loss, low-latency traffic
*''Assured Forwarding'' (AF) PHB — gives assurance of delivery under prescribed conditions
*''Class Selector'' PHBs — which maintain backward compatibility with the IP precedence field.

===Default Forwarding===
A default forwarding (DF) PHB is the only required behavior.  Essentially, any traffic that does not meet the requirements of any of the other defined classes uses DF.  Typically, DF has best-effort forwarding characteristics.  The recommended DSCP for DF is 0.<ref name="rfc4594"/>

===Expedited Forwarding===

The IETF defines Expedited Forwarding (EF) behavior in {{IETF RFC|3246}}. The EF PHB has the characteristics of low delay, low loss and low jitter.  These characteristics are suitable for voice, video and other realtime services.  EF traffic is often given [[strict priority queuing]] above all other traffic classes.  Because an overload of EF traffic will cause queuing delays and affect the jitter and delay tolerances within the class, [[admission control]], [[Traffic policing (communications)|traffic policing]] and other mechanisms may be applied to EF traffic. The recommended DSCP for EF is 101110<sub>B</sub> (46 or 2E<sub>H</sub>).

===Voice Admit===

The IETF defines Voice Admit behavior in {{IETF RFC|5865}}. The Voice Admit PHB has identical characteristics to the Expedited Forwarding PHB. However, Voice Admit traffic is also admitted by the network using a [[Call Admission Control]] (CAC) procedure. The recommended DSCP for voice admit is 101100<sub>B</sub> (44 or 2C<sub>H</sub>).

===Assured Forwarding===

The IETF defines the Assured Forwarding (AF) behavior in {{IETF RFC|2597}} and {{IETF RFC|3260}}.  Assured forwarding allows the operator to provide assurance of delivery as long as the traffic does not exceed some subscribed rate.  Traffic that exceeds the subscription rate faces a higher probability of being dropped if congestion occurs.

The AF behavior group defines four separate AF classes with all traffic within one class having the same priority.  Within each class, packets are given a drop precedence (high, medium or low, where higher precedence means ''more'' dropping). The combination of classes and drop precedence yields twelve separate DSCP encodings from AF11 through AF43 (see table).

{| class="wikitable"
|+ Assured Forwarding behavior group
!Drop<br>probability
! Class 1 !! Class 2 !! Class 3 !! Class 4
|-
! Low
| AF11 (DSCP 10) 001010 || AF21 (DSCP 18) 010010 || AF31 (DSCP 26) 011010 || AF41 (DSCP 34) 100010
|-
! Medium
| AF12 (DSCP 12) 001100 || AF22 (DSCP 20) 010100  || AF32 (DSCP 28) 011100 || AF42 (DSCP 36) 100100
|-
! High
| AF13 (DSCP 14) 001110 || AF23 (DSCP 22) 010110 || AF33 (DSCP 30) 011110 || AF43 (DSCP 38) 100110
|}

Some measure of priority and proportional fairness is defined between traffic in different classes. Should congestion occur ''between'' classes, the traffic in the higher class is given priority. Rather than using strict priority queuing, more balanced queue servicing algorithms such as [[fair queuing]] or [[weighted fair queuing]] are likely to be used. If congestion occurs ''within'' a class, the packets with the higher drop precedence are discarded first. Re-marking a packet is sometimes used to increase its drop precedence if a stream's bandwidth exceeds a certain threshold. For example, a stream whose rate is above the Committed Information Rate (CIR) as defined in {{IETF RFC|2697}} causes the stream to be marked with a higher AF drop precedence. This allows the decision as to when to shape the stream to devices further downstream if they encounter congestion. To prevent issues associated with [[tail drop]], more sophisticated drop selection algorithms such as [[random early detection]] are often used.

===Class Selector===

{| class="wikitable"
|+ Class Selector mapping<ref name=classselector/>
! Service class
! DSCP Name
! DSCP Value
! [[IP precedence]] 
! Examples of application
|-
| Standard 
| CS0 (DF)
| 0
| 0 (000)
| [[Network Time Protocol|NTP]]<ref name=ntp/>
|-
| Low-priority data
| CS1
| 8
| 1 (001)
| File transfer ([[FTP]], [[Server Message Block|SMB]])
|-
| Network [[operations, administration and management]] (OAM)
| CS2 
| 16
| 2 (010)
| [[SNMP]], [[SSH]], [[Ping (networking utility)|Ping]], [[Telnet]], [[syslog]]
|-
| Broadcast video 
| CS3 
| 24
| 3 (011)
| {{Unbulleted list|[[RTSP]] broadcast TV|streaming of live audio and video events|[[video surveillance]]|[[video-on-demand]]}}
|-
| Real-time interactive
| CS4
| 32
| 4 (100)
| Gaming, low priority video conferencing
|-
| Signaling 
| CS5 
| 40
| 5 (101)
| Peer-to-peer ([[Session Initiation Protocol|SIP]], [[H.323]]), client-server IP telephony signaling ([[H.248]], [[MEGACO]], [[Media Gateway Control Protocol|MGCP]], [[Skinny Client Control Protocol|SCCP]])
|-
| Network control 
| CS6 
| 48
| 6 (110)
| Routing protocols ([[OSPF]], [[BGP]], [[IS-IS]], [[RIP]])
|-
| Reserved for future use
| CS7 
| 56
| 7 (111)
| 
|-
|}

DF= Default Forwarding

Prior to DiffServ, IPv4 networks could use the [[IP precedence]] field in the [[Type of service|TOS]] byte of the IPv4 header to mark priority traffic. The TOS octet and IP precedence were not widely used. The IETF agreed to reuse the TOS octet as the DS field for DiffServ networks, later splitting it into the DS field and ECN field. In order to maintain backward compatibility with network devices that still use the Precedence field, DiffServ defines the ''Class Selector'' PHB.

The Class Selector code points are of the binary form 'xxx000'.  The first three bits are the former IP precedence bits. Each IP precedence value can be mapped into a DiffServ class. IP precedence 0 maps to CS0, IP precedence 1 to CS1, and so on. If a packet is received from a non-DiffServ-aware router that used IP precedence markings, the DiffServ router can still understand the encoding as a Class Selector code point.

Specific recommendations for use of Class Selector code points are given in {{IETF RFC|4594}}.

===Configuration guidelines===
{{IETF RFC|4594}} offers detailed and specific recommendations for the use and configuration of code points.  Other RFCs such as {{IETF RFC|8622}} have updated these recommendations.

{| class="wikitable"
|+ IETF {{IETF RFC|4594}} recommendations
! Service class
! DSCP Name
!DSCP Value
! Conditioning at DS edge
! PHB
! [[Network scheduler|Queuing]]
! [[Active queue management|AQM]]
|-
|Low-latency data
| AF21, AF22, AF23
|18, 20, 22
| Using single-rate, three-color marker (such as {{IETF RFC|2697}})
| {{IETF RFC|2597}}
| Rate
| Yes per DSCP
|-
|High-throughput data
| AF11, AF12, AF13
|10, 12, 14
| Using two-rate, three-color marker (such as {{IETF RFC|2698}})
| {{IETF RFC|2597}}
| Rate
| Yes per DSCP
|-
| Network control || CS6 
|48|| [[RFC:4594#section-3.1|See section 3.1]] || {{IETF RFC|2474}} || Rate || Yes
|-
| Telephony || EF 
|46|| Police using sr+bs || {{IETF RFC|3246}} || Priority || No
|-
| Signaling || CS5 
|40|| Police using sr+bs || {{IETF RFC|2474}} || Rate || No
|-
| Multimedia conferencing
| AF41, AF42, AF43
|34, 36, 38
| Using two-rate, three-color marker (such as {{IETF RFC|2698}})
| {{IETF RFC|2597}}
| Rate
| Yes per DSCP
|-
| Real-time interactive
| CS4
|32
| Police using sr+bs
| {{IETF RFC|2474}}
| Rate
| No
|-
| Multimedia streaming
| AF31, AF32, AF33
|26, 28, 30
| Using two-rate, three-color marker (such as {{IETF RFC|2698}})
| {{IETF RFC|2597}}
| Rate
| Yes per DSCP
|-
| Broadcast video || CS3 
|24|| Police using sr+bs || {{IETF RFC|2474}} || Rate || No
|-
| OAM || CS2 
|16|| Police using sr+bs || {{IETF RFC|2474}} || Rate || Yes
|-
| Standard || DF 
|0|| Not applicable || {{IETF RFC|2474}} || Rate || Yes
|-
| Lower-effort
| LE
|1
| Not applicable
| {{IETF RFC|8622}}
| Priority
| Yes
|-
|}

sr+bs = single rate with burst size control (such as a [[token bucket]]).