The MPLS WG Archive

[Dimitry Haskin <dhaskin@nexabit.com>]

> 
> Dimitry Haskin wrote:
> > 
> > The last paragraph on Page 3:
> > 
> > ...  To be definite, in the original RSVP protocol [3], a session
> > was defined as a data flow with a particular destination and
> > transport layer protocol.  In the RSVP-TE specification, however, a
> > session is implicitly defined as the set of packets that 
> are assigned
> > the same MPLS label value at the originating node of an LSP-tunnel.
> > 
> > 
> > I believe there is an issue with the RSVP-TE session 
> definition in the
> > above statement.  To my reading, nowhere the RSVP-TE draft  implies
> > that a set of packets have to be assigned the same MPLS label at the
> > originating node in order to constitute a session. (If my reading is
> > incorrect, then I've an issue with the RSVP-TE spec.) Moreover,
> > Section 2.5 (Rerouting LSP Tunnels) of the RSVP-TE 
> specification seems
> > to clearly imply that multiple LSPs can belong to a single session.
> > Another example where multiple LSPs belonging to the same 
> RSVP session
> > can originate at the same note is a load sharing multipath tunnel
> > between ingress and egress LSRs.  In summary, this at the 
> first glance
> > an insignificant matter has significant implementation implications.
> 
> I think you may have found a bug in this draft.
> 
> Under RSVP, whether MPLS or not, a session is defined as the set of
> paths that share a common destination.  The difference is that with
> MPLS, a destination is defined as the tunnel endpoint 
> address, tunnel ID
> and extended tunnel ID.  (Instead of the destination address, protocol
> and port of non-MPLS RSVP.)
> 
> This is explicitly spelled out in the new definition of the SESSION
> object.  See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, section 
> 4.6.1.  It
> is further spelled out in the reroute rules (section 2.5) - 
> which could
> not work if the two tunnels were in different sessions.  The reroute
> algorithm depends on the fact that two tunnels (the original 
> and the new
> one) will have different labels - otherwise the two tunnels could not
> coexist during between the time of the second tunnel's 
> creation and the
> first's destruction.
> 
> It should further be noted that labels are not assigned until after
> reservations are made.  They are propagated in the Resv message. 
> Therefore, any definition of session that depends on labels is
> meaningless, since sessions are created during Path message 
> processing.
> 
> BTW, this bug is also reflected in the
> draft-ietf-mpls-rsvp-lsp-tunnel-05.txt document.  In section 2.1, it
> defines "session" and "flow" to be synonymous.  This must be 
> incorrect, because during the reroute processing, two flows share a common
> session.  More accurately, a session is defined as one or more flows to
> a common destination (as described by the SESSION object), however,
> normal MPLS operation will only have one flow per session, 
> except during tunnel rerouting.

As I've mentioned, another important example of such an arrangement is a
session that utilizes multiple MPLS paths for load sharing purposes. Such
paths can merge at some downstream LSR. LSP merging decision is more
straightforward and is in line with the classical RSVP if LSPs that can be
merged are identified with the same session object.

While on the merging topic, I believe the following statement on Page 43 in
RSVP-TE spec is to be revisited:

          0x02  Merging permitted

                This flag permits transit routers to merge this session
                with other RSVP sessions for the purpose of reducing
                resource overhead on downstream transit routers, thereby
                providing better network scalability.


I would think that the intention was to permit merging of LSPs that belong
to the same session as opposed to merging LSPs from different sessions.
I've difficulties to see how merging of sessions is achieved within the RSVP
framework. 

> -- David
>