Subject: [manet] routing + rsvp

From: John Peter Tapsell <[email-masked]>
Date: Wed, 3 Jul 2002 12:44:03 +0100

Hey,
<nl>  When you have routing over an ad-hoc network and use rsvp, what happen
when a routing path breaks?  (Say a node moves away, or gets shut down) 
<nl><nl>

As far as i can gather, the routing layer will try to re-establish the link
and notify the rsvp layer.  This will then try to repair the path, failing
if it can't get the reservation..
<nl><nl>

But do the end points know?  Or is it just dealt with on the nodes near the 
tear?  I'm after as much detail as possible.. :) 
<nl><nl>

Thanks :)
<nl><nl>

JohnFlux

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 3 Jul 2002 10:35:54 -0400

> when a routing path breaks?  (Say a node moves away, or gets 

According to RFC 2205,

2.3 Soft State

      RSVP takes a "soft state" approach to managing the reservation
      state in routers and hosts.  RSVP soft state is created and
      periodically refreshed by Path and Resv messages.  The state is
      deleted if no matching refresh messages arrive before the
      expiration of a "cleanup timeout" interval.  State may also be
      deleted by an explicit "teardown" message, described in the next
      section.  At the expiration of each "refresh timeout" period and
      after a state change, RSVP scans its state to build and forward
      Path and Resv refresh messages to succeeding hops.

      Path and Resv messages are idempotent.  When a route changes, the
      next Path message will initialize the path state on the new route,
      and future Resv messages will establish reservation state there;
      the state on the now-unused segment of the route will time out.
      Thus, whether a message is "new" or a "refresh" is determined
      separately at each node, depending upon the existence of state at
      that node.

When a path breaks, the new PATH messages have to find a new path, with the appropriate flow descriptors, at each hop on this new path. And subsequent RESV messages will flow back upstream on this new path. In other words, the "flow" (i.e. the "pretend-circuit") will break and will need to be re-established.

And if RSVP-enabled hops don't exist throughout, non-RSVP hops could be used. What does that say about QoS?
 
> if it can't get the reservation..

I don't see that in RSVP. I don't see anything in the routing protocols that notifies RSVP of anything. Unless I'm forgetting something pretty fundamental about RSVP.

RSVP is not a routing protocol. It depends on some sort of constraint-based routing to be at its best, or on adequate headroom being available at all hops of a route, so that reservations can be made successfully.

It's not clear to me that RSVP can work in a general MANET case, although it can probably work if the MANET hosts stay put and if they are RSVP capable.

Same applies to diffserv, as far as I can tell.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 3 Jul 2002 10:35:54 -0400

According to RFC 2205,

2.3 Soft State

 

Bert