Evaluation of the two approaches

As stated before, the minimal solution to the problem of IPv6 and RSVP integration requires the modification and the interfacing of the RSVP daemon and the IPv6’s binding cache at CNs and MTs. This solution requires less changes when compared to an approach that tries to fix the routing problem at intermediate routers. It is important to note that interfacing IPv6 and RSVP requires changes to both standards. For advanced solutions, where perfor-mance and smooth handovers in wireless environments are important, we have proposed two solutions:

1. Triggers/Objects: PATH messages are triggered on the arrival of binding update mes-sages and home address objects in RESV and PATH mesmes-sages enable intermediate routers to recognize flows and to reuse resources even when the MT’s care-of address changes.

2. Flow Extension: This approach keeps the reservation unchanged until it reaches the wireless access network.

A qualitative comparison of the two approaches is shown in Table 4.1. A quantitative evaluation of these advanced solutions depends on different parameters such as traffic char-acteristics and network topologies and is subjected to future investigations. Although a min-imalist solution would enable the operation of RSVP over mobile IP, we strongly recom-mend the use of one of the solutions that support fast re-establishment or preservation of the reservations when mobile terminals move. Only such enhancements can guarantee good performance and uninterrupted operation.

4.7. CONCLUSION 73 Triggers/Objects Flow extension

Changes to CN yes yes

(needed for minimal solution) (needed for minimal solution)

Changes to intermediate yes no

routers (RSVP object extension)

Changes to MR no yes

(forwarding of late packets (interception of binding update is also an option here) messages, flow forwarding)

Changes to MT yes yes

(needed for minimal solution) (needed for minimal solution)

Changes to HA no no

Supports multicast delivery yes yes

Bandwidth efficient yes yes

End-to-end delay always shortest path only a slight increase (but re-establishment of in delay

resources requires a round-trip)

Lossless handover yes yes

(with forwarding of late packets)

Handover delay round trip faster

Implementation complexity moderate higher

Table 4.1: Comparison of different solutions for the problem of RSVP support in Mobile IPv6

Without quantitative evaluation, we can just observe that Triggers/Objects is a quick and simple solution that might be able to provide sufficiently good service. The flow extension approach is a little more complex but has the advantage of faster deployment. In multi-provider environments where we cannot control the whole path end-to-end, a solution that modifies only CNs, MRs and MTs has a big advantage. We should also mention that a combination of the two enhancements is possible and useful for large wireless networks and roaming services.

4.7 Conclusion

We presented an overview of the mobility management mechanism used in the wireless IP system. Other issues like address configuration and terminal authentication which are closely related to mobility were not presented here. [HPFM98] and [SALM⁺98] provide more in-formation about these issues. We also studied the effect of mobility on the QoS. We saw that during inter-subnet handover, QoS guarantees may not be preserved. One of the major prob-lems is the interworking of RSVP with IPv6. IPv6 proposes the use of temporary addresses, called care-of-address, in case of inter-subnet mobility. In RSVP, all the reservations are identified with the IP source and destination addresses. Moreover, the RSVP module is not aware of mobility so all the flow states and reservations are based on the MT’s fixed address,

74 CHAPTER 4. MOBILITY MANAGEMENT the home address.

We identified three different problems. The first problem was the routing problem for RSVP control messages. The second problem was the flow mismatch problem where the intermediate routers can not identify the packets belonging to an RSVP session when an MT obtains a new temporary address. The third problem was a timing problem where we want to reserve resources along the new path quickly when an MT moves to another network. If the reservation of resources in the new path can not be taken effect immediately, QoS traffic will be temporarily exchanged over the best effort channel. We proposed a complete minimal solution with some optional enhancements to resolve these problems. These solutions have also been proposed to the IETF as an Internet draft [FHNS98]. As a summary, we proposed several modifications in order to improve the inter-subnet handover:

Old MRs can forward packets to the new location of the MT, reducing potential packet losses during inter-subnet handover.

Mobile IP and RSVP may interact to minimize QoS degradation during handover.

QoS can be reserved quickly within the wireless network even when the MT moves to another access network. This can be achieved by the previous MR or the MT informing the new MR about its QoS requirements.

Simulations may provide more insight on the performance of our solutions for the sup-port of RSVP supsup-port in mobile IPv6 environments. The performance of the solutions will certainly depend on different parameters such as traffic characteristics, mobility patterns of the terminals and network topologies. It is a point that needs further investigation. Finally our contributions here are the participation at the problem identification and the proposal of solutions to resolve the problem of RSVP support in mobile IPv6 in a multicast scenario [FHNS98] [FHNS99].

Chapter 5