Subject: RE: RSVP-TE--RRO

From: Arumugam R <[email-masked]>
Date: Thu, 28 Sep 2000 10:32:23 +0530

Hi,
How can a single Resv message used for reserving multiple senders?. 
In Rsvp-Lsp point of view, the TE tunnel should be an unique one in the entire domain. 
Since the draft does not deal with multicasting applications, the above following 
discussion holds good only for SE style( that too during rerouting ) and not for FF style. 
Regards
Arumugam R

-----Original Message-----
From:	David Charlap [SMTP:[email-masked]]
Sent:	Thursday, September 28, 2000 2:42 AM
To:	[email-masked]
Subject:	Re: RSVP-TE--RRO

Hong Liao wrote:
> 
> On Rsvp -TE page 17 the latest version 07.txt, it says that "In resv
> message, they must appear after the associated FILTER_SPEC and prior
> to the say subsequent FILTER_SPC".
> 
> I understand that the LABEL object should be in RESV message, but in
> Resv message, in either case of FF and SE, the [<RECORD_ROUTE>] is
> optional.  Also it is optional in Path message.
> 
> So RRO in Resv is optional or not?

It's absolutely optional.  What gave you any other idea?

The requirement for positioning (in the flow descriptor, after an
associated filter spec) is because a single Resv message may reserve
resources for many different senders, and a receiver may want to record
the route to each one of them.

-- David

---

From: David Charlap <[email-masked]>
Date: Thu, 28 Sep 2000 11:08:57 -0400

> How can a single Resv message used for reserving multiple senders?.

Please reread RFC 2205.  It's explained in great detail.

> In Rsvp-Lsp point of view, the TE tunnel should be an unique one in

And if every sender specifies a different session, this is exactly what
you'll get.

But RSVP also allows multiple senders to send to the same session.  A
receiver that gets Path messages from two different senders in the same
session, it may send out a single Resv message for both of them.

Remember: A session only specifies an endpoint (egress router, tunnel
ID, and extended tunnel ID).  And there can be multiple senders can be
on the same ingress router (differentiated by the LSP ID).

> Since the draft does not deal with multicasting applications, the
> above following discussion holds good only for SE style( that too
> during rerouting ) and not for FF style.

Multiple senders in one session can and will happen for a short time
during a make-before-break operation.  It can also happen during some
kinds of failures.

During this time, when there are more than one sender for a single
session, the next-hop routers can (and probably should) send out a
single Resv message for all the senders in the session.

-- David