Differentiated services: test specification
version 3.10, Mar 31 1999
Editor: Tiziana Ferrari, INFN-CNAF

1. Participants

  1. CS-FUNDP (BE), CERN, EPFL (CH), Switch (CH), DFN & GMD Fokus (DE), Uni. Stuttgart (DE), RENATER (FR), GRNET (GR), HUNGARNET (HU), GARR/ INFN (IT), CTIT (NL), SURFnet (NL), Uni. of Utrecht (NL), ARNES (SI), RedIRIS (SP), Dante (UK)
  2. Vendors: CISCO, IBM, Telebit
under discussion: UKERNA (UK), Nortel, Torrent

2. Introduction

The goal of the differentiated services (diffserv) architecture is the enhancement of the IP protocol for the support of quality of service in a scalable manner, i.e. without relying on either signalling protocols or per flow state information. The diffserv architecture supports both end-to-end and intra-domain reservations, and it has been designed for both parameters and class differentiation based requirements.
According to the diffserv architecture [DS] services can be implemented through the following components:
  1. packet classification at the edge of the stub diffserv networks;
  2. packet marking or packet re-marking at network boundaries (the DS -differentiated services - field is used for the service identification);
  3. packet forwarding inside a given diffserv domain according to the current content of the DS;
  4. traffic conditioning at the network boundaries according to the requirements of each service, e.g. monitoring, policing and shaping.
Classes of services (also called Per Hop Behaviors, PHBs) can be identified through one or more code points. The actual mechanisms adopted to support a given PHB in a diffserv domain and the mapping between different PHBs at the boundaries are both transparent to the application layer. Service Level Agreements must be defined. In addition, the association of a code point to a PHB is free. Several standard PHBs are under definition at IETF (for example the Expedited Forwarding [EF] and Assured Forwarding [AF] behaviors), but generally speaking many PHBs can be arbitrarily defined and implemented, provided that a DS compliant code point is used. Just a limited set of code points will be associated to standardized PHBs. Provided that the Service Level Agreement is guaranteed, the implementation of a PHB in a diffserv domain can be any according to the equipment available (for example: it can be based on Weighted Fair Queuing (WFQ) and its variants, Class based Queuing (CBQ) etc.).

This architecture is particularly suitable in the European environment, as with diffserv each NRN could support a given set of PHBs according to its own requirements by associating a different diffserv domain to each NRN, which could be independently administered, provided that SLAs are guaranteed to provide end-to-end guarantees.
A separate diffserv domain corresponding to the TEN-155 backbone and PHBs mapping rules to be applied at the boundaries could be defined. This is an architectural issue to be addressed according to the diffserv testing results.

3. Proposal

Three different scenarios can be devised to test the diffserv architecture: In each case the test specification could be modified or provided with more details according to the availability of new prototypes implementing a reasonable set of the diffserv features  and/or to the developments in the diffserv architecture specification under definition in the diffserv working group [diffserv].

Since the diffserv mechanisms are strictly router based, the underlying ATM overlay infrastructure must provide fixed guarantees and isolation from production traffic: A proper type of ATM class of service must be defined to perform the tests. CBR is a candidate as it prevents congestion at the ATM layer from impacting the IP performance.
Applications:
A range of applications with different QoS requirements, for example a delay sensitive application and best-effort traffic generators, will be associated to different PHBs and the end-to-end performance of each traffic type will be measured, in particular in presence of several traffic classes competing for resources.
Either classical or diffserv classification capable applications can be adopted. Streams with different QoS requirements will be tested to generate a mixture of heterogenous traffic classes.
QoS sensitive Candidate applications are:

  1. MONARC (Models of Networked Analysis at Regional Centres for LHC Experiments)
  2. Condor, a high throughput computing application for the execution of batch jobs in an environment where resources (CPU) is distributed: "Condor is a software system that creates a High Throughput Computing (HTC) environment by effectively harnessing the power of a cluster of UNIX workstations on a network." Condor is a network critical application because the computing throughput depends on remote I/O operations and on remote checkpointing.
  3. DYNACORE, a project for the development of an application supporting real-time control (through a CORBA-based distributed database) and inter-scientist communication through multimedia tools.
  4. Mcast: MPEG1/2 video streaming application for Winsock2 platforms (Uni. of Athens) - under development - .

3.1 FIRST SCENARIO:  IP precedence based QoS mechanisms

The original IP protocol [RFC 791] specification defines a mechanism to differentiate packets by associating them a type identifier. In the IP header the  Type Of  Service (TOS) field  was defined for this purpose. The TOS byte is divided into 3 sub fields: IP precedence (3 bits),  IP TOS (3 bits) and 2 bits reserved for future use. IP precedence is a mechanism to associate priorities to packets.
Precedence based techniques could be considered as pre-diffserv mechanisms, as the definition of the PHB code points is TOS compatible.

IP precedence tests give the possibility to divide traffic into different classes and to reserve an amount of bandwidth on a best-effort connection for a given class of IP traffic. IP precedence could be also regarded as a tool for the implementation of  Europe wide VPNs.
As the core TEN-155 infrastructure is based on UBR connections, in order to perform significant tests, one of the following requirements must be satisfied. Requirement 1 is a basic one to carry out the tests. If possible, equipment satisfying requirement 2 must be adopted, since requirement 2 is necessary for the adoption of precedence traffic in production:

Applications: applications generating H.323 streams can be used to produce high priority traffic: in a CISCO test environment the IP precedence field is marked by a H.323 Proxy according to the policies stored in a Gatekeeper router.
Candidate platforms:
tentative list: Cabletron, CISCO and Catalyst, IBM routers, Nortel
Features:
CISCO:
The following QoS features could be tested in terms of functionality and CPU utilization:
  1. precence-to-ATM connection mapping of precedences to ATM connections
  2. Committed Access Rate (CAR): CAR is implemented on the edge of a network (at ingress and egress routers). The edge router can set the IP precedence of a given packet according to several configurable parameters, for example the MAC address, the input interface or through access lists. Re-mapping of the IP precedence field can be performed by routers on the boundary between different clouds (e.g. NRNs). The admission control function is applied to the incoming traffic: For each class the traffic is filtered through a token bucket in order to bound the traffic to the committed rate.
  3. Weighted Fair Queuing (WFQ): according to the IP precedence field, packets are queued differently. Up to 8 different queues can be set-up with WFQ. Each weight corresponds to a given bandwidth which can be shared with other queues in case of under utilization. The combination of WFQ and CAR should give the possibility to set an upper bound to the packet queuing delays.
  4. Weighted Random Early Discard (RED): RED is a mechanism to control the length of a queue through thresholds. The packet discard probability is a function of the IP precedence.
  5. BGP precedence: BGP has been extended by including some "QoS signalling" features, i.e. to advertise parameters which are used for precedence setting. Each precedence is associated to a community tag. Also reverse BGP precedence setting (from receiver to sender) is implemented.
IBM: available features, including the mapping of precedences to different ATM connections, to be investigated.
HW and SW Requirements
CISCO:
  1. C7000 with RSP7000, C7200 or C7500;
  2. VIP2-40 or VIP2-50 cards; VIP2-50 card is required for OC-3 rates;
  3. for precedence to VC mapping:
  4. CAR requires CEF to be enabled;
  5. IOS 11.1cc (it has no multicast support, but it supports NetFlow Switching).
IBM: to be investigated

3.2 SECOND SCENARIO: diffserv architecture

A network adopting the diffserv approach to provide end-to-end guarantees will be put to test.

PHBs:
The choice of PHBs depends on the equipment available: the most suitable ones in the TEN-155 environment, in particular for the supply of QoS to different kinds of backbone traffic will be selected and the related Service Level Agreement issues will be taken into consideration. The following is a tentative list:

Experimental PHBs:
Network configuration
Figure 1: differentiated services testbed

The differentiated network testbed can be divided into several diffserv clouds:

  1. a set of diffserv stub domains, each corresponding to an NRN and each supporting a given set of PHBs;
  2. a diffserv core domain interconnecting several stub networks; the configuration of a diffserv domain corresponding to the TEN-155 core network is optional, and depends on the availability of diffserv test equipment at the TEN-155 PoPs. The presence of a diffserv TEN-155 adds complexity to the model.
Point-to-point connection between diffserv capable routers can be provided through a set of ATM connection (blue lines in figure number 1). In this way native diffserv domains can be configured so that IP packets only go through diffserv capable routers.
Each diffserv stub network should have an edge diffserv capable router (for packet classification, packet labeling and policy control) and should be connected to the core through a diffserv boundary router for traffic conditioning, PHB mapping and policy control. The diffserv core domain is optional and could consist of a set of diffserv capable routers connected through a dedicated mesh of ATM VPs. CBR or an equivalent ATM class of service providing diffserv traffic isolation from the UBR connections of the production network should be selected.
Candidate platforms
Tentative list: IBM, Cabletron, Linux.
Torrent and Telebit (when the first diffserv features will be available)
Other platforms which need more investigation:
Features
IBM: Cabletron: Linux: Microsoft:
HW and SW Requirements
SW: Traditional IP traffic generators can be used to inject  IP traffic, provided that packet marking functions are implemented by the edge routers in the diffserv stub networks. Diffserv classification capable applications should be deployed if available.
The test activity will focus on EF and AF, the PHBs under standardization at IETF. More PHBs could be tested depending on the hardware/software features available on test equipment and according to the future steps of the standardization process.

HW: The preliminary phase of the test will be spent to investigate which platforms already implement the diffserv features.

IBM:

Cabletron: Routing on Linux platforms (SIMA and SRP testing):

3.3 THIRD SCENARIO: mixed  diffserv and intserv architecture

Figure 2: integration of differentiated and integrated services
The integration of the intserv and diffserv architectures in one of the topics under study at IETF [ds-is]. Mixed scenarios have the flexibility of the RSVP protocol and the scalability and simplicity of the diffserv approach. The diffserv mechanism can be used in the transit network, while the intserv architecture can be used at the edge. The diffserv part of the network may consist of one (Figure 2) or more diffserv domains.
As the diffserv architecture does not provide explicit admission control, intserv edge routers need to be informed about admission control failure in the diffserv region. In case of static service agreements admission control failure may be generated by the intserv edge routers through static configuration, otherwise the need to be informed by the adjacent diffserv router through a signalling protocol about the current diffserv resource availability. The goal is still an end-to-end QoS guarantee.
A static or dynamic mapping mechanism is defined to associate integrated services QoS classes to differentiated PHBs and vice versa, this can be performed by the application itself (upon receipt of a RESV message) and/or by an edge router. RSVP is used to establish reservations in the intserv stub networks and RSVP packets cross the diffserv region transparently. Admission control functions are performed by the intserv edge router upon receipt of a RESV message from the destination. Admission control failure can happen depending on the intserv polices stored in specific servers, or in the diffserv policies handled by bandwidth brokers.
 
Candidate platforms
Intserv region:
  1. Microsoft end nodes running DS marking capable applications;
  2. Cisco, Torrent, Telebit
Intserv edge router: CISCO, IBM (not jet)
Diffserv region: see previous scenario.
Features
During the preliminary test  phase availability of test equipment will be investigated and  more details will be added to the test program accordingly.
HW and SW Requirements
To be specified

4. Summary

4.1 Type of required equipment 4.2 Capabilities 4.3 Reference equipment
  1. SCENARIO 1: IP precedence-based QoS mechanisms
  2. SCENARIO 2: diffserv architecture other possible vendors:
  3. SCENARIO 3: mixed diffserv - intserv architecture
4.4 Schedule 4.5 Number of kits

4.6 Location/Management 4.7 Infrastructure requirements
  1. multiple DBR or SBR ATM connections per site in case of IP precedence testing (each connection should be used by a specific set of IP precedences);
  2. partial mesh between participants;
  3. bandwidth in the range [2, 15] Mbps to test the router performance when managing multiple plrecedences and managing sofisticated queuing mechanisms with a realistic amount of traffic and with multiple traffic streams with different PHBs or multiple precedences

5. Bibliography

  1. RFC 791: Internet Protocol; J.Postel, Sep 01, 1981.
  2. Differentiated Services working group home page:  http://www.ietf.org/html.charters/diffserv-charter.html
  3. Committed Access Rate (CAR),  CISCO Feature Guide, http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/car.htm
  4. Advanced QoS Services for the Intelligent Internet; CISCO White Paper,  http://www.cisco.com/warp/public/732/net_enabledi/qos_wp.htm
  5. Internet Quality of Service; CISCO support documentation;  http://www.cisco.com/warp/public/732/netflow/qos_ds.html
  6. RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers; KNichols et alt.
  7. RFC 2475: An Architecture for Differentiated Services; S.Blake et alt.
  8. A Framework for Differentiated Services; Y.Bernet et alt.;  draft-ietf-diffserv-framework-02.txt .
  9. Management of PHBs; M.Borden et alt.;  draft-ietf-diffserv-phb-mgmt-00.txt .
  10. An Expedited Forwarding PHB; V.Jacobson et alt.;  draft-ietf-diffserv-phb-ef-02.txt .
  11. Assured Forwarding PHB Group; J.Heinanen et alt.;  draft-ietf-diffserv-af-06.txt .
  12. Interoperation of RSVP/Int-Serv and Diff-Serv Networks Y.Bernet et alt.;  draft-ietf-diffserv-rsvp-02.txt.
  13. Requirements of Diff-serv Boundary Routers; Y.Bernet et alt; draft-bernet-diffedge-01.txt
  14. SRP: Scalable resource Reservation Protocol;  http://lrcwww.epfl.ch/srp
  15. SIMA: Simple Integrated Media Access;  http://www-nrc.nokia.com/sima/
  16. Winsock Generic QOS Mapping (draft): ftp://ftp.microsoft.com/bussys/wINSOCK/winsock2/gqos_spec.doc
  17. The Cost of QoS Support in Edge Devices - An Experimental Study; R.Guerin, L.Li, S.Nadas, P.Pan, V.Peris; Infocom99.
For more references about:
  1. diffserv:  IP Differentiated Services: References
  2. RSVP:  IP Resource Reservation: References