@techreport{fhns-rsvp-support-in-mipv6-00, number = {draft-fhns-rsvp-support-in-mipv6-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-fhns-rsvp-support-in-mipv6/00/}, author = {George Fankhauser and Stathes Hadjiefthymiades and Neda Nikaein and Lorraine Stacey}, title = {{RSVP Support for Mobile IP Version 6 in Wireless Environments}}, pagetotal = 22, year = 1998, month = nov, day = 18, 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.}, }