Results and discussion

This section presents briefly two proprietary protocols designed for QoS signaling in an IP network. The protocols discussed are YESSIR and Boomerang.

YESSIR (YEt another Sender Session Internet Reservations) [140] is a source reservation protocol that seeks to simplify the process of establishing re-served flows while preserving many unique features introduced in RSVP. Simplic-ity is measured in terms of control message processing, data packet processing, and user-level flexibility. Features such as robustness, advertising network service availability and resource sharing among multiple senders are also supported in the proposal.

The proposed mechanism generates reservation requests by senders to reduce the processing overhead. It is built as an extension to the Real-Time Trans-port Control Protocol (RTCP), taking advantages of Real-Time Protocol (RTP).

YESSIR also introduces a concept called partial reservation.

YESSIR was designed for one-way, sender-initiated end-to-end resource reservation. It also uses soft state to maintain states. It supports resource query (similar to RSVP diagnosis message), advertising (similar to RSVP Adspec), shared reservation, partial reservations and flow merging.

To support multicast, YESSIR simplifies the reservation styles to individual and shared reservation styles. Individual reservations are made separately for each sender, whereas shared reservations allocate resources that can be used by all senders in an RTP session. While RSVP supports shared reservation (SE and WF styles) from the receiver’s direction, YESSIR handles the shared reservation style from the sender’s direction, thus, new receivers can re-use the existing reservation of the previous sender.

The authors have shown that the YESSIR one-pass reservation model has bet-ter performance and lower processing cost, compared with a regular two-way

2.9 Other Proprietary QoS Signaling Protocols 33 signaling protocol [141]. The bandwidth consumption of YESSIR is somewhat lower than that of, for example, RSVP, because it does not require additional IP and transport headers. Bandwidth consumption is limited to the extension header size.

YESSIR requires support in applications since it is an integral part of RTCP.

Similarly, it requires network routers to inspect RTCP packets to identify reser-vation requests and refreshes. Routers unaware of YESSIR forward the RTCP packets transparently. YESSIR does not have any particular support for mobility and the security of YESSIR relies on RTP/RTCP security measures.

Boomerang [58] is a another resource reservation protocol for IP networks.

The protocol has only one message type and a single signaling loop for reserva-tion set-up and tear-down, has no requirements on the far end node, but, instead, concentrates the intelligence in the initiating node.

In addition, the Boomerang protocol allows for sender- or receiver-oriented reservations and resource query. Flows are identified with the common 5-tuple and the QoS can be specified with various means, for example, service class and bit rate. Boomerang messages are in the initial implementation transported in ICMP ECHO / REPLY messages. Boomerang can only be used for unicast ses-sions, no support for multicast exists.

The authors of Boomerang have shown that the processing of the protocol is considerably lower than with the ISI RSVP daemon implementation [58]. How-ever, this is mainly due to the limited functionality provided by the protocol com-pared to RSVP.

Boomerang messages are quite short and consume a relatively low amount of link bandwidth. This is due to the limited functionality of the protocol, for ex-ample, no security-specific information or policy-based interaction are provided.

Being sender-oriented, the bandwidth consumption mostly affects the downstream direction, from the sender to the receiver. Also, there is no need to store backward information, which reduces the signaling required.

The Boomerang protocol has similar deployment issues as any host- network-host protocol. It requires an implementation at both communicating nodes and in routers. Boomerang-unaware routers should be able to forward Boomerang mes-sages transparently. Still, often firewalls drop ICMP packets making the protocol useless.

Chapter 3

Mobility Management

This chapter studies the different mechanisms to support a mobile user moving through various networks. The emphasis is on the mobility management on the IP layer and the layers above. Link layer connection management is out of scope, since this thesis discusses IP layer mechanisms de-coupled from specific link and physical layers.

3.1 Mobile Entities

Mobility is a vague term as such, and several levels of mobility [116] can be identified. User mobility refers to the ability of a user to access services from different physical hosts. This usually means, the user has an account on these different hosts or that a host does not restrict users from using the host to access services. An example of user mobility would be a campus network, where a student can log into the campus network from several workstations and still get her files, emails, and other services automatically.

Personal mobility has been defined in [142] as ”the ability of end users to originate and receive calls and access subscribed telecommunication services on any terminal in any location, and the ability of the network to identify end users as they move. Personal mobility is based on the use of a unique personal identity (i.e., personal number).”

Personal mobility complements user mobility with the ability to track the lo-cation of the user and provide the user’s current lolo-cation to allow sessions to be initiated by and towards the user by anyone on any other network. Personal mobility is also concerned with enabling associated security, billing and service subscription authorization made between administrative domains.

Personal mobility support typically amounts to the maintenance and update of some sort of address-mapping database, such as a Session Initiation Protocol

35

(SIP) server or DNS server. It is also possible for the personal mobility support function to take part in forwarding control messages between the end user and her correspondent rather than simply acting as a database. SIP is a protocol for ses-sion initiation in IP networks. It includes registration procedures, which partially support personal mobility, the ability for the network to route a session towards a user at a local IP address.

Host mobility, often called terminal mobility, refers to the function of allow-ing a mobile node to change its point of attachment to the network, without inter-rupting the IP packet delivery of that host. There may be different sub-functions depending on what the current level of service is being provided. In particular, support for host mobility usually implies active and idle modes of operation, de-pending on whether the host has any current sessions or not. Access network procedures are required to keep track of the current point of attachment of all the mobile nodes. In active mode, the location of a mobile node is followed at the finest level, while the location of a mobile node in idle mode is only known at the level of larger paging areas. Accurate location and routing procedures are required in order to maintain the integrity of an ongoing communication.

Host mobility is logically independent of user mobility, although in real net-works, at least the address management functions are often required to attach the host to the network in the first place. In addition, if the network wishes to deter-mine whether access is authorized, and if so, who to charge for it, then this may be tied to the identity of the user of the terminal, or some other identifier.

Host mobility can be divided into two sub-categories, global and local mo-bility or macro and micro momo-bility, respectively. Global momo-bility refers literally to ’mobility over a large area’. This includes mobility support and associated ad-dress registration procedures that are needed when a mobile node moves between IP domains. Handovers between administrative domains typically involve global mobility protocols. Mobile-IP can be seen as a means to provide global mobility.

Local mobility refers to ’mobility over a small area’. Usually this means mo-bility in an IP domain with an emphasis on support for active mode using han-dover, although it may include idle mode procedures also. Local mobility pro-tocols exploit the locality of movement by confining movement-related changes and signaling to the access network. HAWAII [155], Cellular IP [24, 173], and Hierarchical Mobile IP [177] are examples of local mobility schemes, with the assumption that Mobile IP is used for global mobility.

Juntong Liu presents in his thesis [109] from 1998 a highly integrated archi-tecture for handling the mobility of IP nodes. The archiarchi-tecture resembles very much the current state of the work on IP mobility in the IETF, where Mobile IP provides the global information for reaching nodes, and a second protocol is opti-mized to handle efficiently the local mobility of nodes. The thesis also discusses

3.2 Mobile IP 37