<<

. 47
( 132 .)



>>

Figure 5.38 DS domain

The packet is then forwarded across the DS domain with a pro¬le based on this value.
A simple example of a PHB is where the PHB guarantees a minimal bandwidth allocation
of X% of a link to a collection of packets with the same DS codepoint. A more complex
PHB would guarantee a minimal bandwidth allocation of X% of a link, with proportional
fair sharing of any excess link capacity. The ATM Forum is studying a proposal to map
DiffServ PHBs to the ATM available bit rate (ABR) service to provide end-to-end QoS
for IP traf¬c. One of the codepoints is reserved to provide a PHB of best try; this will be
for non-real-time traf¬c with no QoS requirements.
It is important with DiffServ that traf¬c entering the network is managed correctly. If
all hosts are allowed to send traf¬c into the network with a codepoint providing a high
priority then the network will become congested and the QoS provision has failed. The
boundary device must control which traf¬c coming into the network is marked with which
codepoint and possibly shape the traf¬c coming in to ensure the network will not suffer
from congestion.


5.8.2 Expedited forwarding
Expedited forwarding (EF) is a PHB behaviour de¬ned in RFC 2598 where packets are
expected to be treated with highest priority. Each router must allocate a ¬xed minimum
bandwidth on each outgoing interface for the expedited traf¬c. Packets marked with the EF
codepoint must be given preferential treatment over any other traf¬c and suffer minimal
delay and jitter. In this case, packets are expected to be buffered for a minimum amount
of time. For EF behaviour to operate successfully the allocation of available ¬‚ows into the
network must be managed so as not to overload the total expedited bandwidth available.
This is because EF traf¬c will typically be time-sensitive interactive media traf¬c such
as voice or video carried over UDP/IP. For this type of traf¬c it is inappropriate to
throttle back on the sender since this will result in unacceptable delay. A router suffering
congestion within an EF ¬‚ow will have no alternative than to drop packets hence the
need to shape expedited traf¬c as it enters the DS domain. The DS codepoint for EF is
de¬ned as 101110.
5.8 QOS FOR THE GPRS CORE NETWORK 219


5.8.2.1 Assured forwarding

The assured forwarding (AF) PHB is de¬ned within RFC 2597. In this case four different
classes of PHB are speci¬ed each of which corresponds to a different level of service
in terms of minimum bandwidth available. Even though bandwidth is allocated for each
class this allocation is not guaranteed in the face of congestion. If buffers allocated for
a given class ¬ll up, packets will be discarded and congestion control will come into
operation.
Within each class packets can be classi¬ed with low, medium or high drop probability.
In the face of congestion the router will choose packets from the buffer for dropping based
on this drop precedence, packets with a higher drop precedence having a higher probability
of being dropped. One possible use of the drop probability is with non-conforming ¬‚ows.
Senders that transmit above their allocated data rate (non-conforming ¬‚ows) could have
their packets marked with high drop precedence so that they will be more likely to be
discarded in times of congestion. Table 5.12 shows the DS codepoints for the AF PHB
groups.


5.8.2.2 Default PHB

The default PHB maps to a best effort service. In this case the packet will be delivered
as quickly as possible but with no guarantees. The recommended codepoint for default
PHB is 000000 but any packet not covered by a standardized or locally de¬ned PHB will
also be mapped to default PHB.


5.8.2.3 DiffServ for GPRS

DiffServ is ideally suited to provide QoS within the GPRS core network. This is because:

• the core network is a closed network;
• the core network is usually short span and therefore can be over-scaled using gigabit
technologies;
• ingress and egress ¬‚ows to the network are controlled by the SGSN and GGSN.

The 3GPP does not stipulate how UMTS traf¬c classes should be mapped to differenti-
ated service codepoints. TS 23.107 (QoS Concept and Architecture) states: ˜The mapping

Table 5.12 AF PHB DS codepoints
Drop precedence Class 1 Class 2 Class 3 Class 4
Low 001010 010010 011010 100010
Medium 001100 010100 011100 100100
High 001110 010110 011110 100110
220 IP APPLICATIONS FOR GPRS/UMTS


Table 5.13 Mapping UTMS class to DS codepoint
UMTS QoS class DS codepoint
Conversational Expedited Forwarding EF 101110
Streaming Assured forwarding class 1 AF1 (001xxx)
Interactive Assured forwarding class 2 AF2 (010xxx)
Background 000000 (default behaviour)


from UMTS QoS classes to DiffServ codepoints will be controlled by the operator™.
Table 5.13 shows a possible mapping using both the EF and AF PHB classi¬cations.
Conversational class using EF has the highest precedence. This type of traf¬c will
typically carry VoIP telephone conversations. The bandwidth requirements for each traf¬c
¬‚ow may be relatively modest (typically < 20 kbps) but the delay and jitter constraints
will be very tight. The next class, streaming, will be traf¬c such as streamed video
(one-way). In this case the bandwidth requirements may be high but the delay and jitter
requirements are not so crucial. This is because the packets can be buffered at the receiver.
The interactive traf¬c class representing traf¬c ¬‚ows such as web access needs some
reasonable service in terms of delay but with more modest bandwidth requirements than
streaming. Finally, all other traf¬c will be handled as background. It is important to note
that each router must have bandwidth allocated for every PHB group including the default,
otherwise services such as FTP may fail in the face of network congestion.



5.8.3 QoS and the integrated services (IntServ)
The IntServ model for IP networks de¬nes a single network service (based on IP) capa-
ble of carrying audio, video, and real-time and non-real-time data traf¬c. This is very
much akin to the service de¬nition capabilities of the Integrated services digital network
(ISDN) but for a packet switching environment. The IETF IntServ working group has
been responsible for de¬ning and describing the service capability and interfaces to the
underlying network but does not work on the details of how this might be achieved. For
example, it is not part of their remit to look at the modi¬cation of routing or transport pro-
tocols. However, certain recommendations on the use of protocols developed elsewhere
to provide an integrated service have been produced. IntServ de¬nes two basic types of
service: controlled load and guaranteed service. Both types of services can be requested
by a host from the network for a given traf¬c speci¬cation (TSpec). The TSpec de¬nes
parameters such as average required data rate and maximum burst size. The network will
be expected to exercise some type of admission control to determine if it can provide the
service.


5.8.3.1 Controlled load
Controlled load service is de¬ned as being the same QoS that would be achieved when
sending data on an unloaded network element with other traf¬c within the network not
signi¬cantly impinging on the data ¬‚ow. The network must be working well within its
5.8 QOS FOR THE GPRS CORE NETWORK 221


limits and each packet must suffer little or no average queuing delay or packet loss due
to congestion at each router. These requirements are expected to be met within timescales
larger than the burst time, therefore short-term delays (less than the burst size) will be
considered to be statistically anomalous. In terms of end-to-end service the following
must be met:

• A very high percentage of packets are expected to be delivered successfully.
• The transit delay suffered by a very high percentage of packets will not be signi¬cantly
more than the minimum transit delay, this minimum delay being the total processing
time within each of the routers.

Notice how the controlled load service is somewhat vague in its de¬nitions. Its purpose
is to de¬ne a network in which service levels will not be degraded signi¬cantly as network
load is increased. Applications can be tested at low loads and if working successfully can
be expected to keep working as the network traf¬c increases since new load into the
network will be policed effectively.


5.8.3.2 Guaranteed service
Guaranteed service carries packets across the network within a given maximum end-to-
end queuing delay. To request the guaranteed service the applications must provide both
a traf¬c speci¬cation and a requested maximum delay.


5.8.3.3 RSVP and IntServ
Both the controlled load and guaranteed services for IntServ imply some degree of admis-
sion control and resource reservation to make sure that suf¬cient bandwidth and buffer
space are available within the network. The exact mechanism to carry out this control is
beyond the scope of the IntServ working group but they have produced a recommendation
on how to use RSVP to provide integrated services (RFC 2210).



5.8.4 Resource reservation protocol (RSVP)
RSVP (RFC 2205) was de¬ned to address the issues of sending time-sensitive traf¬c over
IP networks. For example, when a host has real-time video to send, it can use RSVP
to request an appropriate level of service from the network to support this request. If a
part of the network does not support RSVP, it cannot reserve the level of service. In this
case RSVP can tunnel the packets through this section of the network until an RSVP
router is again reached, which will continue the level of service. This enables RSVP
to be implemented progressively as is required on the Internet. RSVP requests network
resources in a single direction, therefore for a full duplex path two separate reservations
need to be established. RSVP can support QoS for both unicast and multicast traf¬c.
222 IP APPLICATIONS FOR GPRS/UMTS



Policy Control Admission Control




Reservation
RSVP Daemon

Routing


Data
Packet Classifier Packet Scheduler


Figure 5.39 Resource reservation


An overview of RSPV operation within a network node is shown in Figure 5.39. Each
node is capable of resource reservation and has a number of procedures to support it.
Policy control ensures that a user has the required authority to make the reservation.
Admission control keeps track of the resources to ensure that the resources are available
to provide the requested QoS. If either of these controls fail, an error is returned to
the originator of the RSVP request. The packet classi¬er determines the QoS for each
packet by checking to see if it belongs to a reserved ¬‚ow and marking it appropriately. The
packets once classi¬ed can be fed into the packet scheduler, which orders the transmission
to achieve the required QoS for each data ¬‚ow.
Reservations are implemented using two message types: path message and resv mes-
sage. A path message comes from the sender and contains ¬‚ow information, describing
the data that it wishes to send, such as data format, source address and source port, as
well as the traf¬c characteristics. This path message is used to set up a set of virtual paths
between the source and destination stations. When an RSVP-aware router or host receives
the path message it stores the immediate upstream address of the node it received the
path message from, as well as information about the traf¬c ¬‚ow that is to be sent from
the source. This information, called the path state, is used when reservation requests are
sent from the destination hosts. When a receiving host wishes to make a reservation to
receive data for the particular ¬‚ow it sends a resv message to its immediate upstream
RSVP neighbour. The upstream neighbour will check to see if the request is allowed.
If the request is permitted then it will forward the request to its upstream neighbour
(as identi¬ed in the path state) until the request reaches the source or is rejected due to
admission failure.
A good example of RSVP operation is when providing QoS for a multicast session,
as illustrated in Figure 5.40. Computer A sends a path message to all members of the
multicast group, in this case computers B and C. The path message is received by the
router, which stores the information in a table. The router now knows that when B or
C replies to the message, the next hop back to the source is router to A. Note that the
path message does not set up the reservation requirements. Now suppose that B wishes to
receive information from the multicast group. It will now send a resv message back to the
5.8 QOS FOR THE GPRS CORE NETWORK 223


(1) Path
Message
(2) Resv
(1) Path Message Workstation B
Message
(3) Resv Router (1) Path
Message Message
Workstation A

(4) Resv
Message Workstation C

Figure 5.40 An example of RSVP


router asking for the required QoS. When the router gets the resv message it will reserve
that requested amount of resources for B. The router also forwards the resv message to
A (using the path state information) to ensure that resources are also reserved on that
link. When C wishes to join the group, it will also send a resv message to the router.
The router will reserve the required resources for the link router to C. However, in this
case the router does not need to forward the request to A since a link has already been
established (through B™s request). However, if C™s resv request is larger than B™s then the
router will have to forward the request to A, so that A can increase the reservation of the
link A to router. As mentioned before, there are two main points to note:

1. The required resources must physically be available or the link will not be
established.
2. The stations must have the required authority to request the desired resources.

RSVP supports three traf¬c types:

1. Best effort: this is traditional IP traf¬c. Applications include ¬le transfer (such as
email) and disk mounting.
2. Rate sensitive: this type of traf¬c will give up timeliness for throughput. For example,
an application requests 100 kbps of bandwidth and then wishes to send 200 kbps for
an extended time. In this implementation, the routers can delay the traf¬c. H.323
videoconferencing is such an application since it encodes at almost a constant rate.
3. Delay sensitive: this type of application requires data to arrive quickly and will allow
the data rate to change accordingly. MPEG-2 video requires this system since the
amount of data transfer depends on the amount of change in the picture from one
frame to the next.

In practice RSVP has not been used widely to support QoS over the Internet and large-

<<

. 47
( 132 .)



>>