The MPLS WG Archive

[Arumugam R <arumugamr@future.futsoft.com>]

Thanks for the comments. Also added the inline comments.

-----Original Message-----
From:	David Charlap [SMTP:david.charlap@marconi.com]
Sent:	Thursday, September 28, 2000 8:39 PM
To:	mpls@uu.net
Subject:	Re: RSVP-TE--RRO

Arumugam R wrote:
> 
> 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
> the entire domain.

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)

[$$] If the Same Ingress Router (Behaving Like multiple senders) establishes 
multiple Sessions ( TE tunnels) with the Egress Router, then all the sessions 
will be having different Tunnel Id isn't.
      Between Ingress and Egress there can be a number of tunnels established based 
on policy considerations, depending on the traffic parameters required for each 
of them. But each tunnel should have an unique reservation along all the nodes 
between the Ingress and Egress, which can be achieved only by an unique Tunnel Id.
     Only during the reroute condition the Ingress of tunnel assigns a different LSP-ID 
for avoiding double counting of resources. All other occasions the nodes 
maintain reservations only based on the unique Tunnel Id, Egress Address pair I suppose.
Please correct me if I am wrong.    .

> 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