3.2 System Architecture
3.2.2 Resource Reservation Scheme
Tunnelling is the essential part of the Mobile IP and its extensions. However, wrapping RSVP messages makes them indistinguishable on RSVP-aware routers along a tunnel path. For each end-to-end reservation, a separate RSVP session called RSVP tunnel needs to be established between the tunnel end-points, i.e., the MAP and MNs.
An Efficient RSVP-Based QoS in Access Networks
Figure 3.2: Proposed scheme signalling in inter-LMAP Handovers
Exploiting the multi-layer architecture of the proposed scheme, an end-to-end reservation inside the GMAP domain can be divided into two parts: the first part between the LMAP and MN, and the second between the GMAP and LMAP. While the former needs to be updated whenever the MN changes its point of attachment, the latter depends on the MN’s current sub-domain, remaining un- changed as long as the MN stays inside it. Since the second part is the same for all MNs belonging to a same LMAP domain, instead of having an individual RSVP tunnel for each session, only one RSVP session can be used between the LMAP and GMAP as the tunnel end-points. This can reduce the processing cost on RSVP-aware routers along the tunnel, and the amount of signalling messages passed through.
According to the process explained in the mobility management scheme, a reser- vation message, sent by the CN to MN, contains the MN’s RCoA0 as the destina- tion IP address. When the GMAP receives this message, it acts as an endpoint of the connection, replying back to the CN on behalf of the MN. At the same time, it maps the reservation request to the pre-configured RSVP tunnel be-
An Efficient RSVP-Based QoS in Access Networks
tween itself and the MN’s serving LMAP. However, instead of exchanging RSVP messages through the tunnel, it just sends a new defined RSVP object, called Session Trigger (Figure 3.3), to the LMAP asking it to reserve the resources for the MN. The object contains the CN’s IP address, the traffic specification, and the MN’s ID. Upon receipt of this information, the LMAP works as a proxy and initiates a new RSVP session destined to the MN’s current location.
Figure 3.3: Trigger Session Object format
When the LMAP receives this object, it tries to find the MN’s LCoA base on the MN’s ID, and establishes an end-to-end RSVP session between itself and the MN. When the MN receives a Path message originated by the LMAP, it replies back by a Resv message. Figure 3.4 depicts the operation of proposed scheme when the MN operates as the receiver of the flow.
In order to remove the reservation, the Delete Session object is defined with the same structure as the Trigger Session object, but different class type. The object can be used by either of the RSVP tunnel end points to inform the other end about the necessity of removing the resources assigned for an individual flow. Contrary to the conventional RSVP tunnel wherein all the end-to-end RSVP messages, including the set-up and refresh, are encapsulated and sent through the tunnel, in the proposed scheme only the new defined objects are exchanged between two end-points, resulting in a significant reduction of signalling overhead between tunnel end-points.
For the sake of simplicity, the static threshold-based mechanism is used to pre- allocate resources for each tunnel Ct, in which the maximum amount of resources authorised by administration polices is assigned, Ct = ψmax. However, one can
use the dynamic threshold-based mechanism. In this method the constant value is assigned to the tunnel, and afterwards, based on the monitoring and predicting
An Efficient RSVP-Based QoS in Access Networks
Figure 3.4: Operation of the proposed Scheme (MN as a receiver)
of the future demand the extra chunk of resources B can be added, or released. ψmin ≤ Ct = ψmin+−B × i ≤ ψmax, where i = 0, 1, ... (3.1)
In order to increase the efficiency of the resources assigned to the RSVP tunnels, they can be used by the best-effort traffic, if there were no demand for them. When the MN is the sender of the flow, the main concept is the same as the previous part. The MN starts the resource reservation process by sending a Path message to the CN. Upon receiving the message, the LMAP acts as an RSVP proxy and sends a Resv message to the MN, on behalf of the CN. At the same time, it maps the session to the RSVP tunnel between itself and the GMAP by sending the Trigger Session object. The object includes the MN’s ID, CN’s IP address and Sender TSpec of the received Path. When the GMAP receives this object, it initiates an end-to-end RSVP session between itself and the CN.
An Efficient RSVP-Based QoS in Access Networks