. 48
( 132 .)


scale IP networks but has been used to some limited extent within intranets to support
VoIP and video streaming. The problem with RSVP is that it does not scale well for
large networks for routers. To keep an update path and reservation state information for
thousands of connections takes up a lot of processing power and storage space. Another

problem with RSVP is that is generates a lot of extra messages, which in turn may lead
to congestion on the network.

5.8.5 RSVP for GPRS
Provision of QoS within the GRPS core network will be largely based on DiffServ (and
controlled by PDP), the reason for this being scalability. When handling many thousands
or tens of thousands of sessions, RSVP is not well suited for the reasons stated above.
The place where RSVP can play a role, however, is between the UE, GGSN and the
external network. To provide QoS end-to-end, QoS must be supported in every domain
between sender and receiver. Since the PDP context creation goes only as far as the
GGSN, separate end-to-end QoS mechanisms are required for the domain external to
UMTS. This is illustrated in Figure 5.41.
Figure 5.42 shows the signalling ¬‚ow for a UE originated call (3GPP TS 23.207
V5.7.0). The UE ¬rst establishes a PDP context across the UMTS network by send-
ing a create PDP context request to the SGSN. The SGSN will then establish the PDP
context with the GGSN and request the creation of radio access bearers between it and
the UE. Assuming the request is satis¬ed, the SGSN sends a reply to the UE accepting
the request. The UE will then start RSVP reservation procedures end-to-end. For data in
the uplink direction, ¬rst a path message is sent from the UE, then the receiver makes a
reservation request, and ¬nally the UE acknowledges the reservation. In Figure 5.42 the
GGSN is RSVP-aware and uses the request to reserve bandwidth on its external network
interface. In the second request, the reservation of bandwidth for the downlink direction
is shown. The path message from the external host with traf¬c to send is received by
the UE. This contains the traf¬c speci¬cation for the sender. Assuming the UE wants to
establish end-to-end QoS, it must ¬rst request the appropriate QoS characteristics from
its UMTS bearer. It does this by sending a modify request PDP context to the SGSN.
The SGSN will then attempt to satisfy the request and signal back to the UE. Now that
the UE has a bearer which can handle the traf¬c, a reservation request is sent back to the
sender. Assuming the reservation succeeds, a reservation con¬rm message is sent back to
the UE.

End-toEnd QoS
Differserve or RSVP

Radio Access
Core IP External IP network
Network Diffserve or
ATM or
Diffserve QoS RSVP QoS
Diffserve QoS

PDP context controlled

Figure 5.41 End-to-end GPRS QoS


Activate PDP Context Request
Create PDP Context Request
Create PDP Context Response

RAB Establishment
Activate PDP Context Accept

Uplink RSVP Resv RSVP Resv
RSVP Resv-Conf RSVP Resv-Conf

Modify PDP Context Request
Update PDP Context Request
Downlink Update PDP Context Response
Modify PDP Context Accept
RSVP Resv-Conf
RSVP Resv-Conf

Figure 5.42 End-to-end reservation

All the RSVP messages in this case are tunnelled across the UMTS network, which will
be unaware of their contents. The only UMTS components using RSVP in this case are
the UE and the GGSN. It is also possible to have a GGSN which is not RSVP-aware. In
this case the GGSN will forward the RSVP message but not enforce or perform resource
or policy control for the QoS requests.

5.8.6 IntServ versus DiffServ
The type of services provided by IntServ and DiffServ are quite different. Whereas IntServ
looks to provide separate QoS service for each ¬‚ow, DiffServ only distinguishes traf¬c
into ¬‚ow classes. IntServ provides a greater degree of control to the application in terms
of requesting QoS but at a price in terms of complexity of processing within the router
and extra protocol information packets to be sent. DiffServ relies on the network being
very carefully scaled to provide enough bandwidth for a particular class, and practical
applications would likely require the network to be somewhat over-dimensioned to take
into account the variances in the load it may suffer. With DiffServ the traf¬c can be
policed at the network boundary device, which is considerably more scalable a solution
than provision of a controlling mechanism within each of the routers.
Given all these factors and the fact that bandwidth on networks is becoming more
readily available at lower costs, DiffServ will be the preferred choice over RSVP and
IntServ for voice and data integration for networks with a small geographical span. For

example, it is not uncommon to have the GGSN and SGSN in the same building or even
room. In this case all components can be networked using gigabit or even 10-gigabit, both
available for Ethernet, and use DiffServ and 802.1p4 to differentiate between real-time
and non-real time traf¬c.
Of course the two types of service are not mutually exclusive and it would be possible
to have a differentiated service to run voice and data over a network and use RSVP to
allocate bandwidth when streaming video from a server. Another application of RSVP is
the reservation of bandwidth for the Internet connection leaving the operator™s premises.
As this is a likely bottleneck in communications, careful control of access to this resource
is desirable.

Many of the applications that are run over networks require security. Internet banking,
e-commerce or email access all may require the message transfer to be protected against
snooping or forgery. Since data services for UMTS will be provided over IP networks
there are a number of tried and tested security protocols available to choose from. The
two most popular security protocols are transport layer security (TLS) and IP security
(IPSec). The former provides privacy and authentication for World Wide Web users and
through its use security is provided for 99% of all e-commerce applications. IPSec is
the preferred choice for virtual private networks, a system that allows a corporation to
use the Internet (or any other public IP network) as if it is private by encrypting the
messages sent.

5.9.1 Transport layer security (TLS) and WAP security
TLS and WTLS were designed to provide secure access to Web and WAP services,
respectively. Using WTLS provides weaker security than TLS and was only introduced
as a stop gap to provide encryption for WAP devices that had limited processing power.
TLS will eventually be able to replace WTLS as the preferred choice for wireless security
with the advent of WAP 2.0 and GPRS. Transport layer security (TLS)
TLS is an open protocol, largely based on the secure sockets layer (SSL) version 3.0
protocol, which was developed by Netscape. TLS has now been standardized by the
IETF. TLS supersedes and incorporates all the functionality of SSL; however, the two
are not interoperable. The rationale for TLS/SSL, and its widest application, is for the
provision of a secure connection between a web browser and server for the transfer of

802.1p is a datalink layer protocol that allows for prioritization of traf¬c at this layer.

Handshake Alert
Cipher Spec HTTP
Protocol Protocol

Record Protocol



Figure 5.43 TLS protocol stack

sensitive data, such as credit card numbers, through the HTTP protocol. A session that
is protected by TLS/SSL uses port 443, instead of the usual HTTP port of 80, and is
identi¬ed by using https instead of http in the URL, for example:


Figure 5.43, shows that the TLS/SSL protocol stack consists of a number of protocols.
It utilizes TCP to provide reliable and secure end-to-end connections and de¬nes four
different protocols to support this service, namely the record, change cipher spec, alert and
handshake protocols. The record protocol provides basic security services to the protocols
above, signi¬cantly HTTP. The other three protocols are for management of the secure
The record protocol provides con¬dentiality and integrity through encryption and
authentication. The keys for both are de¬ned by the handshake protocol when the session
is started.
Application data to be transferred securely is ¬rst split into blocks of a maximum size
of 16 kB, which may then be compressed. Next, a message authentication code (MAC)
is calculated for the data, based on the shared secret authentication key. The resulting
message including the MAC is encrypted using a symmetric encryption algorithm, again
based on the shared encryption key. There are several encryption algorithms permitted,
including the data encryption standard (DES) and triple DES (TDES).
Finally, a record header is added to the result to provide some information about the
compressed data.

Change cipher spec protocol
This is a 1-byte message. Its only function is to update the cipher suite being used on the

Alert protocol
This passes alert messages, which are errors with regard to the current connection, for
example, if an incorrect MAC was received, or an inappropriate message was received.
Alert messages are classi¬ed as either level 1, which is a warning, or level 2, which is

fatal and causes the connection to be terminated. The alert messages are also compressed
and encrypted.

Handshake protocol
The functions of the handshake protocol are:

• to provide two-way authentication between the client and server, which is done through
digital certi¬cates;
• to negotiate the encryption and authentication algorithms to be used;
• to negotiate the encryption and authentication keys to be used.

The process of establishing a secure session involves four phases. In phase one, the
client and server establish each other™s security capabilities. The client ¬rst sends a
client hello, message which contains:

• the TLS/SSL version it is using;
• an identi¬er for the session;
• a list of the encryption, authentication and compression algorithms supported.

The server then replies with a server hello containing the same information, but with
the server having picked an encryption, authentication and compression algorithm from
the list supplied by the client. This also contains the chosen method of key exchange.
The second phase involves server authentication and key exchange. First, the
server sends its certi¬cate message, such as issued by Verisign or Digicert. If
required, a server key exchange message is now sent, depending on the key exchange
mechanism. The server may also optionally request a certi¬cate from the client, using
a certi¬cate request message. The server closes this phase with a server hello done
message. Note that both Internet Explorer and Netscape Navigator, as well as WAP
browsers from vendors such as Openwave, have the public keys for Verisign and others
hardwired in. Therefore, servers furnishing certi¬cates from Verisign can be immediately
authenticated by a client.
In phase three, once the client is satis¬ed that the certi¬cate from the server is
valid, the client sends its certi¬cate in a certi¬cate message. Next, the client sends a
client key exchange message, which is dependent on the type of key exchange being
used. For example, with the RSA scheme, the client generates a 48-byte key, encrypts
it using the public key enclosed in the server certi¬cate, and sends it to the server. This
key is then used to generate a master key. Finally, the client may send a certi¬cate verify
message to provide explicit veri¬cation for the client certi¬cate.
The closing phase, phase four, is the ¬nal part of the establishment of the secure connec-
tion. The change cipher spec message, as previously described, and the ¬nished message
are exchanged by the client and server. Once this is completed, the client and server may
now exchange encrypted data.




. 48
( 132 .)