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

From: Guilhem Tardy <[email-masked]>
Date: Fri, 31 Mar 2000 16:12:45 -0500

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