The MPLS WG Archive

[David Charlap <dcharlap@fore.com>]

"Abes, Andi" wrote:
> 
> David,
> 
> The following are quoted from rsvp-tunnel-05, sections 3.1 and 3.2
> It's the description of the Path and RESV messages -
> the parts that apply to sender specification.
> Both messages contain a session object as well (qouted from 4.6.1)
	...

I never said that they didn't contain SESSION objects.  Of course they
must - otherwise you don't know what tunnels the messages apply to.

> So what does this mean:
> 
> In a path message, an LSP is identified by:
>   a. the session it belongs to -
>         IPv4 egress address + tunnel ID + extendend TunnelID.
>   b. A sender template -
>         the ingress address + LSP ID (unique for the sender).

Yes.  SESSION and SENDER_TEMPLATE.  As with straight RSVP.

> In a reserve message an LSP is identified by:
>   a. The session - same as path.
>   b. the filter spec, which is exactly the same as the sender_template

Again, exactly as in straight RSVP.

> So back to the original questions and issues:
> 
> 1. For LSP's to be belong to the same session they need
>    to share the same egress point and tunnel ID.
>    If the exteneded tunnel ID is set to the Ingress IP address, only
>    LSP's originating at the same ingress could ever belong to the
>    same session.

Yes.

> 2. For multiple LSP's to share resources, they need to:
>    a. belong to the same session (see above)
>    b. The egress router needs to assign SE style to the session.

Yes.

> Do you agree with the statements above ?

Yes.

> In light of these statements, do you still believe there
> is a bug in the rsvp-tunnel draft ?

Yes.  What you've described is correct.  But section 2.1 of
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt describes something else:

   According to [1], "RSVP defines a 'session' to be a data flow with a
   particular destination and transport-layer protocol." However, when
   RSVP and MPLS are combined, a flow or session can be defined with
   greater flexibility and generality.  The ingress node of an LSP can
   use a variety of means to determine which packets are assigned a
   particular label.  Once a label is assigned to a set of packets, the
   label effectively defines the "flow" through the LSP.  We refer to
   such an LSP as an "LSP tunnel" because the traffic through it is
   opaque to intermediate nodes along the label switched path.

Here, the draft implies that there is no difference between and LSP, a
flow and a session.  This is completely untrue.

Multiple data flows can go through a single LSP - the ingress router
will determine which flows go into which LSPs, based on whatever
administrative policies are in place (including, but not limited to
destination address, diffserv bits, or layer-4 information)

Additionally, multiple LSPs can be defined for a single session.  These
LSPs may share resources (when used in make-before-break rerouting or
creating redundant failoer paths) or they might maintain distinct
reservations (possibly for defining multiple parallel LSPs for
prioritizing traffic.)

   New RSVP SESSION objects, called LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6
   have been defined to support the LSP tunnel feature.  The semantics
   of these objects, from the perspective of a node along the label
   switched path, is that traffic belonging to the LSP tunnel is
   identified solely on the basis of packets arriving from the PHOP or
   "previous hop" (see [1]) with the particular label value(s) assigned
   by this node to upstream senders to the session.  In fact, the
   IPv4(v6) that appears in the object name only denotes that the
   destination address is an IPv4(v6) address.  When we refer to these
   objects generically, we use the term LSP_TUNNEL Session.

Again, this is inaccurate.  A tunnel is not defined by packets sharing a
common label.  An LSP is a set of packets sharing a common label.  A
tunnel (or session) is a collection of one or more LSPs to a common
destination (sharing a common tunnel ID.)

It is perfectly possible for multiple LSPs (meaning packets with
different labels) to all belong to a single tunnel.

On the data plane, the distinction doesn't matter.  The switch just
looks at the label, updates the label (push, pop, swap, etc) and
forwards the packet.

But on the control plane - at least with RSVP - the distinction is
important.  Tunnels (or sessions) can not share resources with each
other.  LSPs within a single tunnel, however, may or may not share
resources, depending on the reservation style sent out by the tunnel
endpoint (egress) router.

It is important to note that a label can not be used to identify an LSP
during LSP setup.  Labels are only assigned during Resv message
processing - which happens towards the end of the setup.  In other
words, labels are purely data-plane entities and don't identify anything
until after RSVP (or LDP, I assume) sets up the LSP.

-- David