JANET QoS Suggested DSCP Marking Scheme

The JANET QoS Development Project

Duncan Rogerson, Victor Olifer

JANET (UK), 2007

013 (12/07)

ST/QoS/DOC/002

Page 1 of 9

Contents
Preface.............................................................................................................................................3 1. A use of DSCP on JANET..........................................................................................................4 2. Recommended DSCP values ......................................................................................................6 3. DSCP values for private use .......................................................................................................8 References.......................................................................................................................................9

013 (12/07)

ST/QoS/DOC/002

Page 2 of 9

Preface
The purpose of this document This document suggests a common scheme for the use of DiffServ Code Points (DSCPs) within the JANET community. The JANET backbone does not currently make use of DiffServ QoS and hence does not interpret DSCP markings, passing them without alteration [4]. If this situation should change in the future, the current intention is that the backbone will interpret DSCP values as described below. (This scheme may change due to factors such as further experience or changes in industry best practice as such, updates to this document may become necessary.) It should be stressed that the DSCP scheme described in this document is in no way mandatory; it simply describes the scheme that would be adopted on the backbone should circumstances dictate that JANET deploy DiffServ within the backbone. Regional Networks and sites are, of course, free to deploy DiffServ as they see fit. However, the adoption of a co-ordinated scheme across the whole of JANET could make end-toend deployment of DiffServ more straightforward. Common interpretation of DSCP values would potentially remove, or at least lessen, the need for their re-marking at domain boundaries, such as between site and Regional Network, or Regional Network and JANET backbone. Those deploying DiffServ within their part of the JANET community may, therefore, wish to bear this scheme in mind when deciding how to make use of DSCP values in their network.

Intended audience Network administrators and engineers of JANET sites and Regional Networks.

Acknowledgements The authors would like to express their gratitude to the JANET QoS Development project participants for their various contributions and valuable discussions that resulted in writing this document. Special thanks to Tim Chown (University of Southampton), Steve Williams (Swansea University) and Rina Samani (JANET(UK)) for feedback and useful comments.

013 (12/07)

ST/QoS/DOC/002

Page 3 of 9

1. Use of DSCP on JANET

In the DiffServ model [1, 2] DSCP is an IP packet field whose value indicates the desired QoS treatment for the packet. A DSCP value is a signalling mechanism within a DiffServ domain. The setting of this field in an IP packet allows a network node to make a decision about what QoS treatment the network should give the packet. Setting the DSCP is known as classifying the packet. Each intermediate node on the network then treats the packet based on the value of the DSCP field, without the need for the packet to be classified at each stage. (However, note that this does not mean that an intermediate node cannot re-classify a packet and change the DSCP value.) The DiffServ standards define 64 DSCP values. Some of them are recommended for marking particular classes of QoS services, e.g. value 46 is usually recommended for real-time traffic with the strictest latency requirements [3]. To use DSCP requires some sort of trust between routers. Generally, DSCP values are assigned by the edge routers of an administrative domain (e.g. a Regional Network) and used by the core routers of the same domain. If there is no trust relationship between domains, the edge routers of each domain may re-assign DSCP values of ingress packets if they are already marked with a non-default (non-zero) value. This would prevent, for example, one domain transmitting all the packets with a DSCP value indicating priority treatment into another domain and overloading that networks priority service. A worse example could be where the DSCP value for low priority in one domain is used to mean higher priority in another. Without inspecting and re-marking the inbound DSCP values, both networks would give the opposite treatment to packets than was intended. However, the scenario where two domains trust each other and use consistent DSCP values is somewhat easier to handle. Both domains will give packets the same QoS treatment without any intervention on their edge routers. Some applications (e.g. VoIP or videoconferencing) mark packets by non-default DSCP values when they are generated by the applications host computer. This might be an IP phone or a videoconferencing client although the default DSCP marking may not be consistent with the network scheme. So while this may at first sight remove the need for an intermediate node (for example, a router) to classify the packet, the intermediate node may actually need to inspect the packets and re-mark the DSCP field. The JANET QoS Policy Framework [4] includes several principles that aim to build robust, consistent and manageable QoS treatment when and where it is necessary and found appropriate. Some of these principles impact directly on the way in which DSCP should be used on JANET. They are:

013 (12/07)

ST/QoS/DOC/002

Page 4 of 9

The JANET core has sufficient bandwidth headroom and is QoS-neutral (i.e. DSCP values are transmitted transparently across the network, and are not used to give packets different treatment). Either the cores of Regional Networks are overprovisioned and QoS-neutral or those Regional Networks that implement QoS do so outside of the scope of the current JANET QoS model. QoS treatment might be configured on access links between site access routers and corresponding Regional Network edge routers on a case by case basis: for example, where a site link is congested and the site and Regional Network work together to prioritise certain traffic. Regional Network edge routers which are involved in providing QoS elevated treatment must classify traffic based on the IP addresses of end nodes. The same requirement is applicable to a site access router if it supports QoS towards an Regional Network edge router. Classification based only on DSCP values of packets must be excluded. This requirement aims to protect this service from unauthorised access, which might easily happen if DSCP values assigned by a third party are the only attribute used to give packets preferential treatment. It is a crucial requirement for providing robust and consistent QoS.

Despite the fact that DSCP values on their own do not give direct and immediate access to elevated QoS services on access links between sites and Regional Networks, according to the JANET QoS Policy Framework, the role of DSCPs on JANET is not completely diminished. DSCP values might be of use in different situations, for example: to indicate special and consistent QoS treatment within two or more site networks, which trust each other and are connected through JANET. This could be two labs and two video studios which have congested interfaces within their LANs or at their edge access routers, and want to fix this problem at the site network level, based on DSCP value. In such a case, mutually agreed and trusted DSCP values that indicate appropriate QoS treatment could be very helpful. For example, let us consider two labs which have been independently using QoS within their LANs for preferential treatment of real-time traffic. If they decide to exchange this traffic through JANET without any co-ordination with their Regional Networks or JANET NOC then they may find themselves in one of two possible situations. The first is if both labs have been using the same DSCP value to mark their real-time traffic. If the Regional Networks involved have not deployed DiffServ, neither site needs to change any QoS configuration within their network, or re-mark packets coming from the partner source on their edge router(s). Neither the JANET backbone nor a Regional Network will interpret or change the DSCP marking. If the labs are not going to ask the Regional Networks involved for any help with QoS treatment of their traffic in the foreseeable future then they can choose to use a private DSCP value; otherwise a recommended public value would be more appropriate (see both ranges of recommended DSCP values for public and private use below).

013 (12/07)

ST/QoS/DOC/002

Page 5 of 9

In the second possible situation, the two labs might be using different DSCP values for the same kind of preferential treatment. To provide consistent treatment one (or both) of them will have to amend their QoS configuration at the edge of their network to re-mark the DSCP to ensure appropriate treatment. This extra configuration may only be necessary at one site, if that site re-marks both incoming and outgoing DSCP values. Again, this situation assumes that the Regional Networks involved do not interpret or change DSCP values. to complement IP addresses as an identification attribute to help edge routers with admission control procedures. In some cases IP addresses might not be enough to identify a sender unambiguously and DSCP might act as an additional discriminator to select the correct flow for differential treatment. For example, the hosts behind a NAT that appear as a single IP address might be able to use the DSCP field as an additional flow identifier, or the same host might generate different streams with different QoS needs: for example, a videoconferencing server which at the same time does directory replication or a desktop PC running a voice client at the same time as a large file upload. Techniques such as Deep Packet Inspection or treatment based on TCP/UDP port numbers could also solve this kind of problem; however, DSCP inspection may well be a more efficient method in terms of router CPU resources.

2. Recommended DSCP values

The role of DSCP values on JANET as described in the previous section means that there is no strict need for all JANET users and network administrators to use the same DSCP values within all sites for some classes of applications. Any QoS deployment on JANET in the foreseeable future will be implemented on a case by case basis, either within a Regional Network or at the boundary between site and Regional Network/JANET. Those involved in such deployments would agree upon the DSCP values to be used (or confirm that all parties had chosen to adopt the scheme suggested here). Naturally, deployment of QoS wholly within a single site needs no co-ordination with external parties. Co-ordination only becomes necessary when a DSCP value is expected to be interpreted by a party outside the site. Even if two parties which decide to provide QoS between themselves had already implemented QoS using different DSCP values, they might decide not to change their internal DSCP standardisation but instead re-mark incoming traffic on edge routers. This requires each site to know how the other interprets DSCP values within its network i.e. co-ordination effort as mentioned above. If all parties adopt the same DSCP scheme, this minimises the effort required when deploying QoS between two domains. Currently there is an informational RFC 4594, Configuration Guidelines for DiffServ Service Classes, which includes recommended DSCP values for the Internet community. It seems

013 (12/07)

ST/QoS/DOC/002

Page 6 of 9

reasonable to use this RFC as a reference document for the JANET community and to complement it with JANET-specific DSCP values. RFC 4594 describes 12 different QoS classes and uses 20 DSCP values for marking packets intended for treatment by those classes. At first glance differentiation might seem too granular, possibly resulting in too complex QoS configuration. However this does not need to be so, as diverse marking does not mean that QoS treatment has to be configured with the same level of granularity. Please note that marking traffic with fine granularity makes it possible to organise differential treatment with any desirable granularity, from coarse to fine. For example, one can organise only two queues for a router output interface, a priority and a best effort queue, but serve all 12 classes by allocating them between the two queues accordingly. The opposite situation, when a source of traffic uses very few DSCP values to differentiate traffic needs, is potentially more dangerous, because if the network administrator of a transit network wishes to use a granular traffic treatment then he or she will not be able to do so as there is not enough information about traffic differentiation. The recommended DSCP values for the JANET community which are based on RFC 4594 and existing and emerging JANET services are in the following table:
Service Class Name Network Control and OAM DSCP Name CS6 DSCP Value* 110000 (48) Application Examples Network routing and OAM (e.g. SNMP, Ethernet CFM, proprietary NMS traffic) Signalling (e.g. H.323, SIP) IP Telephony bearer Videoconferencing Interactive control (e.g. CAM), real-time elearning, games, e-arts Streaming video and audio on demand Broadcast TV & live events Transactional applications, database access, interactive data applications Bandwidth channels Undifferentiated applications Mirror service, remote backups, etc

Signalling Telephony Multimedia Conferencing Real-Time Interactive

CS5 EF AF41, AF42, AF43 CS4

101000 (40) 101110 (46) 100010 (34), 100100 (36), 100110(38) 100000 (32)

Multimedia Streaming Broadcast Video Low-Latency Data

AF31,AF32, AF33 CS3 AF21,AF22, A23

011010 (26), 011100 (28), 011110 (30) 011000 (24) 010010 (18), 010100 (20), 010110 (22)

High-Throughput Data Standard (Best Effort) Low-Priority Data (LBE)

AF11,AF12, A13 DF (CS0) CS1

001010 (10), 001100 (12), 001110 (14) 000000 (0) 001000 (8)

*) Decimal value in brackets

Please note that there are three DSCP values among the recommended values in the table above which it is particularly important to use in the recommended way. They are:

013 (12/07)

ST/QoS/DOC/002

Page 7 of 9

DSCP 46: EF (Expedited Forwarding) DSCP 0: Best Effort DSCP 8: LBE (Less than Best Effort).

Their significance is a result of the widespread practice of using a minimal set of different QoS classes within routers for treating traffic: Best Effort for common treatment plus IP Premium for any privileged treatment and/or LBE for background treatment. In such cases DSCP values Best Effort (0), EF (46) and LBE (8) are normally used for mapping ingress traffic onto those two or three types of QoS treatment within routers. Breaching these recommended DSCP values might very likely result in mis-treatment of traffic in any network which supports QoS. The table above reflects the current situation and might be updated when new QoS benefiting services appear on JANET and/or on the basis of experience gained from QoS implementation on JANET.

3. DSCP values for private use

Not all possible DSCP values are listed in the table above. The remaining values were left for private/experimental use where traffic is supposed to be treated in a particular way which differs from all the application classes listed in the table. DSCP values reserved for private/experimental use are: 001001 (9), 001011 (11), 001101 (13), 001111 (15) 010000 (16), 010001 (17), 010011 (19), 010101 (21), 010111 (23) 011001 (25), 011011 (27), 011101 (29), 011111 (31) 100001 (33), 100011 (35), 100101 (37), 100111 (39) 101001 (41), 101010 (42), 101011 (43), 101100 (44), 101101 (45), 101111 (47) 110001 (49), 110010 (50), 110011 (51), 110100 (52), 110101 (53), 110110 (54), 110111 (55) 111000 (56), 111001 (57), 111010 (58), 111011 (59), 111100 (60), 111101 (61), 111110 (62), 111111 (63) Please note that only values in the 111xxx range can be used by equipment which only supports the IP Precedence bits and not the full DSCP field. All other values might cause clashes with DSCP-marked traffic within such equipment; for example, the value 101001 will be treated similarly to the value 101100 as both values have 101 in the IP Precedence three bits.

013 (12/07)

ST/QoS/DOC/002

Page 8 of 9

References
1. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss, An Architecture for Differentiated Services, RFC 2475, December 1998 2. K. Nichols, S. Blake, F. Baker, D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998 3. B. Davie, A. Charny and others, An Expedited Forwarding PHB (Per-Hop Behavior), RFC 3246, March 2002 4. The JANET IP QoS Policy Framework, 012 (12/07), JANET(UK), December 2007 http://www.ja.net/documents/development/network-engineering/qos/ qos-policy-framework.pdf

013 (12/07)

ST/QoS/DOC/002

Page 9 of 9