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

From: "Abes, Andi" <[email-masked]>
Date: Thu, 13 Apr 2000 13:24:37 -0400

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)

(4.6.1)
LSP_TUNNEL_IPv4 Session Object

      Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel end point address               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |      Tunnel ID                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(4.6.2.1. LSP_TUNNEL_IPv4 Sender Template Object)

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MUST be zero                 |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(3.1 - path message)
      <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                               [ <ADSPEC> ]
                               [ <RECORD_ROUTE> ]
(3.2 - resv message)

      <FF flow descriptor list> ::= <FF flow descriptor>
                               | <FF flow descriptor list> <FF flow
descriptor>

      <FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
                               [ <RECORD_ROUTE> ]

      <SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>

      <SE filter spec list> ::= <SE filter spec>
                               | <SE filter spec list> <SE filter spec>

      <SE filter spec> ::=     <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]

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).

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

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.

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.

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

Andi.

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Tuesday, April 11, 2000 7:47 PM
> To: [email-masked]
> Subject: Re: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt
> 
> 
> "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
>

---

From: David Charlap <[email-masked]>
Date: Thu, 13 Apr 2000 15:09:39 -0400

> 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.

>         the ingress address + LSP ID (unique for the sender).

Yes.  SESSION and SENDER_TEMPLATE.  As with straight RSVP.

>   b. the filter spec, which is exactly the same as the sender_template

Again, exactly as in straight RSVP.

>    LSP's originating at the same ingress could ever belong to the

Yes.

>    b. The egress router needs to assign SE style to the session.

Yes.

> Do you agree with the statements above ?

Yes.

> 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