The MPLS WG Archive

["Abes, Andi" <aabes@quarrytech.com>]

Let's clear things a little:

The RSVP-TE session object includes the following:
- Tunnel ID,
- Eggress LSR IP address
- Extended tunnel ID.

The extended tunnel ID can either be 0 or contain the IP address of the
source.

Ok, now what does that mean.
I understand it as such:
A session identifies the "tunnel" that ends at the specified egress. 
This could mean many ingress LSR's if the extended ID is 0, or just
one specific ingress if the extended ID contains its IP address.

This basicaly means that a "session" can have many ingress points which can
share 
resources while traversing the network towards the egress.

In the same spirit as in the original RSVP, although with no support for
explicit
multicast - many senders can send traffic to the same session, and each is
identified
by the "sender_template" - by the IP address of the sender (in oRSVP).
The "deviation" in RSVP-TE is that there could be many senders in one host,
such that it is not enough to denote the ingress IP address, but the LSP ID
is also needed. Each "Sender"
is assigned a label,a "flow_spec" and optionaly an Explicit Route.
The reroute is performed on LSP basis - not Tunnel.


So - 
a session is a COLLECTION of LSP's that are targeted at the same egress
point, that were 
assigned to the same administrativly selected "Tunnel ID"
In order for LSP's to share resources, they have to be assigned to the
same "TunnelID".

I agree that the wording in the applicability draft is somewhat lacking,
but the RSVP-TE draft itself is clear about this - if you dig hard  
looking at the implications of the object formats.

Andi.