include the IP header DSCP value in any of its cryptographic calculations. Still, in tunnel mode, IPsec can protect the inner IP header.
The second concern is about a potential for a denial-of-service attack, where a domain and its classes may be flooded with excess traffic causing the ongoing flows to suffer from the congestion. There is no simple solution to this problem, except that all ingress nodes must enforce the service provisioning policy. Having the ingress nodes do a careful analyze and classification of the incoming traffic can prevent the core of the domain to become congested.
2.5 Integrated Services over Differentiated Services
IntServ, RSVP and DiffServ can be seen as complementary technologies in the pursuit of end-to-end QoS. Together, these mechanisms can facilitate deployment of multimedia applications. IntServ enables hosts to request per-flow, quantifiable resources, along end-to-end data paths and to obtain feedback regarding admissi-bility of these requests. DiffServ enables scalaadmissi-bility across large networks. There are a number of work in progress efforts, which are directed towards these ag-gregated control models, including aggregation of RSVP [5], the RSVP DCLASS Object [11] to allow Differentiated Services Code Points (DSCPs) to be carried in RSVP message objects, and operation of Integrated Services over Differentiated Services networks [12].
From the perspective of IntServ, DiffServ regions of the network are treated as virtual links connecting IntServ capable routers or hosts located on the edges of the DiffServ region. Within the DiffServ regions of the network, routers imple-ment specific PHBs and aggregate traffic control. The total amount of traffic that is admitted into the DiffServ region will receive a certain PHB and may be limited by policing at the edge. As a result the DiffServ regions of the network will be able to support the IntServ style services requested by nodes outside the DiffServ region.
In the framework, the support of end-to-end Integrated Services over the Diff-Serv regions of the network is addressed. The goal is to enable seamless inter-operation. The primary benefit of combining the Integrated Services and the Dif-ferentiated Services architectures is the increased scalability and flexibility, pro-vided through the aggregate traffic control of DiffServ.
2.5.1 Reference Model
The ISSLL working group has studied the use of IntServ in a DiffServ-capable network. The reference model is based on Figure 2.3.
Sender Receiver
DiffServ Region
Non−DiffServ Region Non−DiffServ Region
BR 1 BR 2 ER 2
ER 1
0000 00 1111 11 0000 1111 000 111
1 0 1 0 1 0 1 0
00 00 00 00
11 11 11 11
Figure 2.3: The IntServ over DiffServ Reference Architecture
The reference network includes a DiffServ region in the middle of a larger network supporting IntServ end-to-end. The DiffServ region contains a mesh of routers, at least some of which provide aggregate traffic control. The regions out-side the DiffServ region, the non-DiffServ regions, contain meshes of routers and attached hosts, at least some of which support the Integrated Services architec-ture. For simplicity, only one stationary receiver and sender are discussed here.
The edge routers (ER1, ER2), which are adjacent to the DiffServ region interface to the border routers (BR1, BR2) in the DiffServ region.
This model does not fix the sizes of the different regions and their structure.
At the other extreme, the Non-DiffServ regions could be only the sending and receiving nodes themselves—and possibly the closest router—while all routers between these two are DiffServ enabled. Basically, the more DiffServ routers the network has, the more scalable the service is. On the other extreme, the DiffServ region is minimal.
The basic requirements and assumptions are:
Both the sender and the receiver use RSVP to communicate their quantita-tive QoS requirements.
RSVP messages are forwarded even if some router on the path, or the whole DiffServ region, is not RSVP aware.
There is a mechanism for mapping RSVP-based reservations to DSCPs.
Depending on the scenarios, routers in the DiffServ region may be able to produce RSVP messages, even though the forwarding operation is purely based on the DSCPs.
There is a Service Level Agreement (SLA) between the Non-DiffServ re-gions and the DiffServ region. The SLA defines the capacities of the Diff-Serv region, the resource types and capacities for each type of RSVP-based reservation.
2.5 Integrated Services over Differentiated Services 23 The functionality of the framework is the following. The sender requests a QoS-enabled service from the network by sending the RSVP Path message. The message is forwarded through the first subnetwork and arrives at the edge router ER1. This router performs standard RSVP processing and installs the Path state.
The Path message is sent onward to the DiffServ region, where the message is forwarded transparently, and then processed at ER2 according to the standard RSVP processing rules.
When the Path message reaches the receiver, that host generates an RSVP Resv message, indicating the resources needed to support the indicated traffic.
The Resv message is carried back towards the DiffServ network and the sending host. At ER2, the Resv message is subjected to standard RSVP/IntServ process-ing, and ER2 may reject the reservation request if resources on the downstream interface are deemed insufficient.
If the message is not rejected, it will be carried transparently through the Diff-Serv network region, and arrives at ER1. In ER1, the Resv message triggers admission control processing. ER1 compares the resources requested to the re-sources available in the DiffServ network region at the corresponding DiffServ service level. If ER1 approves the request, it updates its internal tables to indicate the reduced capacity, and sends the Resv message upstream towards the sender.
When the sender receives the Resv message, it knows that the request was admitted and it can start sending traffic. The sender can then use a default DiffServ code point to mark the packets of the admitted flow, or it can get the proper code point with the Resv message in the DCLASS Object [11]. Note that any RSVP node in the IntServ regions may reject the reservation request due to inadequate resources or policy, and then initiate appropriate error messages.
The resource management in the DiffServ regions can be performed by one of the following methods.
Statically Provisioned DiffServ Network Region
In this architecture, no devices in the DiffServ network region are RSVP aware.
The DiffServ network region is statically provisioned. There is a Service Level Specification (SLS), a static contract, for the transmit capacity at each of a num-ber of standard DiffServ service levels. The transmit capacity may be simply an amount of bandwidth or it could be a complex profile involving a number of factors such as burst size, peak rate, or time of day.
It is helpful to consider each edge router in the non-DiffServ network as con-sisting of two halves, a standard IntServ half, which interfaces to the network regions of customers and a DiffServ half, which interfaces to the DiffServ net-work region. The IntServ half is able to identify and process traffic on per-flow granularity.
The DiffServ half of the router can be considered to consist of a number of virtual transmit interfaces, one for each DiffServ service level negotiated in the SLS. The router contains a table that indicates the transmit capacity provisioned, per the SLS at each DiffServ service level. This table, in conjunction with the default mapping, is used to perform admission control decisions on IntServ flows, which cross the DiffServ network region.
RSVP-Aware DiffServ Network Region
In this architecture, the edge routers of the non-DiffServ network are standard RSVP routers. The border router, BR1 in Figure 2.3, is RSVP aware. In addition, there may be other routers in the DiffServ network region, which are RSVP aware.
Note that, although these routers are able to participate in some form of RSVP signaling, they classify and schedule traffic in aggregate, based on DSCP, not on the per-flow classification criteria used by standard RSVP/IntServ routers. This approach exploits the benefits of RSVP signaling while maintaining much of the scalability associated with DiffServ.
In the preceding method, there is no signaling between the DiffServ network region and network elements outside it. The negotiation of an SLS is the only explicit exchange of resource availability information between the two network regions. ER1 is configured with the information represented by the SLS and as such is able to act as an admission control agent for the DiffServ network region.
Such configuration does not readily support dynamically changing SLSs, since ER1 requires reconfiguration each time the SLS changes. It is also difficult to make efficient use of the resources in the DiffServ network region. This is because the edge-based admission control does not consider the availability of resources in the DiffServ network region along the specific path that would be impacted, that is, some cross-over router may be congested within the DiffServ region.
By contrast, when the DiffServ network region is RSVP aware, the admission control agent is part of the DiffServ network. As a result, changes in the capacity available in the DiffServ network region can be indicated to the IntServ-capable nodes outside the DiffServ region via RSVP. By including RSVP routers inside the DiffServ network region, it is possible to simultaneously improve the efficiency of resource usage in the DiffServ region and to improve the level of confidence that the resources requested at admission control are indeed available at this particular point in time. However, this can affect the scalability of the network region.
This benefit of RSVP signaling is referred to as ”topology aware admission control”. A further benefit of supporting RSVP signaling in the DiffServ network region is that it is possible to make changes in the provisioning of the DiffServ network region—for example, allocating more or less bandwidth to the premium service queue in a router—in response to resource requests from outside the
Diff-2.6 Real-Time Transport Protocol 25