RSVP Support for Mobile IP Version 6 in Wireless Environments
draft-fhns-rsvp-support-in-mipv6-00

Document Type Expired Internet-Draft (individual)
Last updated 1998-11-18
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-fhns-rsvp-support-in-mipv6-00.txt

Abstract

This draft describes a specific problem encountered when using RSVP (Resource Reservation Protocol) over optimised routes in MIPv6 (Mobile IP Version 6). The address translation in the MIP's binding cache creates a mismatch between the flow-id of the packets sent from correspondent node to mobile node and the flow-id signalled by RSVP. We discuss several solutions to this problem: (1) By modifying RSVP at mobile and correspondent nodes to become aware of MIPv6 address- ing, we provide a simple repair that allows RSVP flows to be esta- blished between the fixed network and mobiles; (2a) By adding optional objects to RSVP messages, a performance enhancement is pro- posed to make handovers smooth and seamless; (2b) A different tech- nique with the same goal is called flow extension and it provides flows with fixed flow-ids from the correspondent node into the wire- less access network at the expense of forwarding traffic inside the access network, whenever the mobile node moves. We conclude that the minimal solution (1) is a requirement in order to make MIPv6 and RSVP interoperable; our favored approach requires only minor changes to the correspondent and mobile node's RSVP and MIP specification. However, for well performing and uninterrupted operation we strongly recommend one of the solutions (2a or 2b) that support fast re-establishment or preservation of resource reserva- tions when mobile nodes move.

Authors

George Fankhauser (gfa@acm.org)
Stathes Hadjiefthymiades (shadj@di.uoa.gr)
Neda Nikaein (nikaein@eurecom.fr)
Lorraine Stacey (lstacey@lucent.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)