The MPLS WG Archive

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

David,

Now I understand your objections - 
the wording in the sections you qouted is not 
clear enough about what is a session, a flow and how
they relate to labels.
Ok - to that I agree.

But to say it's a bug in the draft - that's taking 
it a little too far.

A little analysis of the objects involved and the 
processing rules for RSVP along with the text will
bring you to the right conclusions.

I completly agree that making the draft more explicit
as to what is permissible and possible with the 
defined objects would be very useful.

And, if the draft is taking the "reader-freindly" path -
there are quite a few more issues that need clarification
and updating:


1. Diff serv over MPLS.
2. Label stacks and implications on distributing them with RSVP 
   (the LDP world has pretty well define rules for 
    Trageted sessions and it's implications)
3. Some usage scenarios and examples would be great.





Andi.



> -----Original Message-----
> From: David Charlap [mailto:dcharlap@fore.com]
> Sent: Thursday, April 13, 2000 3:10 PM
> To: mpls@UU.NET
> Subject: Re: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt
> 
> 
> "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
>