The MPLS WG Archive

[Paul Langille <langille@CrescentNetworks.com>]

    Hi William. In the following text I have a few 'answers'. Standard
disclaimer of course! (My answers may not be totally accurate. If this is the
case then I am sure that someone will speak up!)

"Friedeborn, William" wrote:

> A couple of points I am a little confused on in this thread about adding a
> SourceID to the Tunnel indexing scheme.
> 1. Tunnel Indexing - When I look at the current indexing scheme of
> TunnelIndex, TunnelInstance, there is nothing here that would indicate that
> this information should have any significance  other than to the node it is
> created on.

I believe that this is correct.

> In my first cut at understanding the use of Tunnels, I could see
> that the ingress node could have the Tunnel objects defined via SNMP/cli.
> The Tunnel instrumentation would pass the info down to the supporting
> protocol statemachine (LDP or RSVP), the protocols would signal down to the
> egress node creating LSR-MIB objects along the way (or on reverse trip) till
> the egress node is reached, where the LSR-MIB and Tunnel objects are
> created. Since my understanding of the LDP and RSVP protocols is not that
> detailed, I didn't see where the Tunnel indexing info fit in LDP or RSVP
> (i.e. how would this index info be passed on the LSP creation via RSVP?). It
> seemed that the intent was to use the cross-connects on each node to
> associate the Tunnel object using it. And the LSPID to track the sequence of
> cross-connects so that one could follow an LSP from node to node via the
> LSPID.

This is basically correct also. (You may need more than the LSP ID to uniquely
identify an LSP. See the following text.)

>
>
> If the intent is that a tunnel definition should have more than just local
> significance, shouldn't there be some tunnelID defined (like LSPID)? I can
> see that adding a SourceID makes it possible to pass these locally defined
> indices, but it seems odd to me that when you define a set of indices on one
> machine, that another machine should know about them.

Have a look at draft-ietf-mpls-rsvp-lsp-tunnel-05.txt and focus on the session
object and the sender template. The session object contains the  "IPv4 tunnel
end point address", "Tunnel ID", and the "Extended Tunnel ID". If you make the
Extended Tunnel ID equal to the tunnel ingress node's IP address then you have
uniquely identified the two ends of the tunnel. The Tunnel ID is used to
identify multiple tunnels between the same source and destination. (I believe
this is what you are looking for.)
If you now want to move traffic from one tunnel to another without disrupting
service (aka "make-before-brake") you would keep the same session object and
modify the LSP ID in the sender template. (This is explained much better in
draft-ietf-mpls-rsvp-lsp-tunnel-05.txt.)
I think the use of the Source ID (and the Tunnel ID) will be clearer in the next
version of the MIB. (Right Tom?)

>
>
> 2. Multiple LSPs on a Tunnel - Looking at the LSR-MIB I see that the
> cross-connect object has a XCIndex and three other indices. I assumed these
> were set up to support MP-PT, and PT-MP by keeping the XCIndex and
> OutSegmentIndex constant and varying the InSegmentIfIndex/label, the MP-PT
> case is achieved, and similarly the PT-MP could be done. (Is it
> possible/practical to have MP-MP?). In any case, it seemed that there could
> be a situation where a Tunnel had a XCIndex that referenced  more that one
> row in a XC table. I wasn't sure if the multiple rows in the XC table ment
> multiple LSPs? Or just a MP-PT or PT-MP single LSP?
>
> 3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also.

First let's get rid of one of the terms. I think that a "tunnel" and an "LSP
tunnel" in the context of the TE MIB are the same things. So throw out "tunnel".
It is too general.

So what is the difference between an LSP and an LSP tunnel? If you look in
section 2.1 of draft-ietf-mpls-rsvp-lsp-tunnel-05.txt it has the following text:

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

I think the difference is related to the signaling. To me an LSP has a 'hop by
hop' feel to it (e.g. LDP). When signaling an LSP the FEC is passed along to
each node in the path. This gives the intermediate nodes a hint about the data
that will traverse the LSP. For LSP tunnels the FEC decision is made at the head
end of  the LSP tunnel. From a signaling perspective, the nodes along the (LSP
tunnel) path do not know anything about the data traversing the LSP tunnel. The
beauty (or the confusing part) of all this is that the label swap operation is
the same for both LSPs and LSP tunnels.
Does this help or did I make it worse?

    Paul


>
>
> Hope someone can clarify the above,
> Thanks,
> Bill Friedeborn
>
>

--
Paul Langille                e-mail: langille@crescentnetworks.com
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824