Subject: RE: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt

From: "Abes, Andi" <[email-masked]>
Date: Tue, 11 Apr 2000 19:15:00 -0400

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.

---

From: David Charlap <[email-masked]>
Date: Tue, 11 Apr 2000 19:46:47 -0400

"Abes, Andi" wrote:
> 
> 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.

You're confusing a few things here, I think.

Each sender (actually, each PHOP node along the path from each sender)
is assigned a label by its NHOP node during Resv processing.

FLOWSPEC objects contain the Qos parameters (could be "best effort" if
the CoS CType is used) and are also signalled from NHOP to PHOP during
Resv processing.

Explicit route objects are signalled from PHOP to NHOP during Path
processing.  They are not assigned to senders, but are generated by
senders.  (Or ingress routers in the MPLS world.)

-- David