Subject: RE: RSVP in a mobile environment (e.g. MANET): how to improve latencies?

From: "Andreas Terzis" <[email-masked]>
Date: Sat, 1 Apr 2000 12:53:48 -0800

Guilhem,

We had a paper in INFOCOM'99, which proposed using RSVP tunnels
to either statically or dynamically allocate resources between
base stations for mobile hosts moving between neighboring cells.

The pointer to the paper is: 
http://www.cs.ucla.edu/~terzis/pubs/infocom99.ps.gz

cheers,

-andreas
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Guilhem
> Tardy
> Sent: Friday, March 31, 2000 1:13 PM
> To: [email-masked]
> Subject: RSVP in a mobile environment (e.g. MANET): how to improve
> latencies?
> 
> 
> Hi!
> 
> I have been working on wireless networks for a while (more specifically
> Mobile-IP and MANET) and Qos management in those environments. As an
> exercice, I started to look at possible ways to improve latencies of
> re-reservation with RSVP when a host roams (i.e. when the topology
> changes), under the assumption that the physical and link layers would
> notify the RSVP process *beforehand*. This is feasible as the MAC
> constantly compares signals from various neighboring nodes and decides
> at a given threshold to effectively switch to a new correspondent,
> right?
> 
> It might be a bit premature, but I would very much like to discuss with
> anyone of you the scheme found below. I introduced two new objects for
> the Path message, which shall be of the form ClassNum = 11bbbbbb. A
> slightly expanded version (with a short introduction and a couple of
> figures) can be found at http://gt89.dgrc.crc.ca/QoS/t.html
> 
> I am only aware of another study called "MRSVP" by A. K. Talukdar, B. R.
> Badrinath and A. Acharya, which takes the point of view of reserving in
> advance at multiple potential neighbours, where I would prefer to act a
> little bit later, only when a node is sure to roam (hence a single new
> reservation). This is particularly important when bandwidth is very
> limited, roaming is unpredictable (e.g. many neighbours, all moving) and
> frequent. A typical case is a mobile ad-hoc network (MANET) or other
> nomad networks (e.g. Bluetooth). There might have been some other
> studies since then, and I would like to hear about it, too.
> 
> Please send your replies directly to me, as well.
> Best regards,
> Guilhem Tardy.
>                                     phone: (613) 993-8232
> Network Systems and Technologies    fax:   (613) 998-9648
> Communications Research Center      email: [email-masked]
> 3701 Carling Ave. #28/2B            web:   http://www.crc.ca/
> Ottawa (Ontario) K2H 8S2
> 
> 
>       Terminology:
> 
>       path state   {SENDER_TEMPLATE, PHOP, SESSION, IFin, IFout} as
> defined by
>                    the Path messages, {NHOP} as defined by the Resv
> messages
>       #{1..n}      first common node between the current and forthcoming
> route
>       []           forthcoming anchor
>       #s{1..n}     first common node towards the source between the
> current
>                    and forthcoming route
>       #d{1..n}     first common node towards the destination between the
> current
>                    and forthcoming route
> 
>       Note: * {1..n} is an optional index respective to several routes
> for multicast
>             * parentheses as in "dest->#(->src)" mean that a packet
> would be merged at # and not forwarded
>             * curly braces as in "{->[],->src}" mean that a packet could
> be forwarded to either of both
> 
> 
>       The specific rules are as follows:
> 
> [host mobility]
> 
>     [reservation, host=dest]
> 
> a. Path(w/ obj) dest->[]
>         pck.{srcaddr=src, destaddr=[]}, SESSION=dest
>         'obj' specifies the reservation made to this flow (i.e. style
> and
>         corresponding descriptors)
> b. Resv []->#{->dest(->src),(->src)}
>         pck.{srcaddr=dest, destaddr=phop}
>         [] substitutes to dest for making the necessary reservations
> c. ( ResvTear dest->#(->src) )
>         optionally, dest tears down its current reservations before
> roaming
>         (note: # should discard this message, because it doesn't match
> the new state,
>         in particular for the outgoing interface)
> d. roaming
> e. Resv dest->[](->src)
>         pck.{srcaddr=dest, destaddr=phop}
> 
> If 'obj' indicates the need of confirmation, by the means of the current
> dest address
> specified in a RESV_CONFIRM (b.), this will trigger one or many
> Confirmation messages
> processed by dest (e.g. for tearing down corresponding reservations and
> deciding
> eventually on roaming), while possible ResvErr messages will be
> forwarded to [].
> 
> 
>     [path, host=src]
> 
> a. Path(w/ obj) src->[]
>         pck.{srcaddr=src, destaddr=[]}, SESSION=[]
>         'obj' specifies the dest address of a session
> b. Path []->#(->dest)
>         pck.{srcaddr=src, destaddr=dest}, SESSION=dest
>         [] substitutes to src for sending the Path message
> c. Resv (dest->)#{->[],->src}
>         pck.{srcaddr=dest, destaddr=phop}
>         # immediately sends Resv refreshes upon reception of a Path with
> a new PHOP address
> d. ( PathTear src->#(->dest) )
>         optionally, dest tears down its current paths before roaming
>         (note: # should discard this message, because it doesn't match
> the new state,
>         in particular for the incoming interface)
> e. roaming
> f. Path src->[](->dest)
>         pck.{srcaddr=src, destaddr=dest}, SESSION=dest
> 
> 
> [router mobility]
> 
>     [reservation & path]
> 
> a. Path host->phop->#s->#d(->dest)
>         pck.{srcaddr=src, destaddr=dest}, SESSION=dest
>         phop looks for another route towards dest (the message sent to
> phop,
>         despite routing default, cannot be forwarded out the same
> interface)
> b. Resv (dest->)#d->#s{->host(->src),(->src)}
>         pck.{srcaddr=dest, destaddr=phop}
>         #d immediately sends Resv refreshes upon reception of a Path
> with a new PHOP address
> c. ( ResvTear host->#s(->src) )
>         optionally, dest tears down its current reservations before
> roaming
>         (note: #s should discard this message, because it doesn't match
> the new state,
>         in particular for the outgoing interface)
> d. roaming
>

---

From: ana <[email-masked]>
Date: Mon, 03 Apr 2000 17:54:31 +0200

Hi Guilhem,
we had also a paper in the First Workshop on IP Quality of Service for
Wireless and Mobile Networks (IQWiM´99). We propose to use Mobile IP and
Resource Reservations in Advance (using RSVP) for guaranteeing QoS in mobile
environments.

You can find a reference to this paper at:
http://www.darmstadt.gmd.de/mobile/publications/abstracts/PajaresBerierWolfSteinmetz1999a.html

Best wishes,
-ana