The MPLS WG Archive

["Friedeborn, William" <wfriedeb@netplane.com>]

What I am puzzeled about is the existence of the Tunnel objects on the intermediate nodes that you are modeling. From section 2. in the draft-ietf-mpls-te-mib-03.txt

 

 An explicitly routed LSP (ERLSP) is referred to as an
   MPLS tunnel.  It consists of one in-segment and/or one
   out-segment at the ingress/egress LSRs, each segment
   being associated with one MPLS interface.  These are
   also referred to as tunnel segments.  Additionally, at
   an intermediate LSR, we model a connection as
   consisting of one or more in-segments and/or one or
   more out-segments.  The binding or interconnection
   between in-segments and out-segments in performed
   using a cross-connect. These objects are defined in
   the MPLS Label Switch Router MIB [LSRMIB].

 

I took this to mean that the Tunnel objects can be brought into existence by either an SNMP request or by a signaling entity at the ingress/egress nodes. In the case of an SNMP request, the creation of the tunnel (MPLS_TE_MIB) objects in the head end node would be the trigger that caused the creation of the LSR-MIB objects in the head end, and kick off the protocols to signal the lsp to the other nodes (assuming the SignalingProto object is LDP or RSVP). In the intermediate nodes, the LSR-MIB objects are created till the egress node is reached, at which point the Tunnel objects are created here (as this is the egress end). (Actually, the sig proto reaches egress node, Tunnel objects/LSR-MIB created and intermediate nodes filled in on return trip). In the case where it is a signaling entity that is creating the Tunnel objects, I could see that the ingress/egress node knows that the LSP is an Originating/Terminating LSP and could create the Tunnel objects.

 

What is it in the signaling protocol (RSVP or LDP) that would tell the intermediate node that the LSP being created should have objects other than LSR-MIB objects created?

 

Thanks,

Bill
[Friedeborn, William]  -----Original Message-----
From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
Sent: Friday, June 09, 2000 12:34 PM
To: Friedeborn, William
Cc: arun Viswanathan; cheenu Srinivasan
Subject: RE: Additional Index for TE-MIB: mplsTunnelTable

At 12:24 PM 6/9/00 -0400, Friedeborn, William wrote:

Sorry for the long interval between the posting and this question. But, in "draft-ietf-mpls-te-mib-03.txt"
 
7. Example of Tunnel Setup
 
   This section contains an example of which MIB objects
   should be modified if one would like to create
   loosely routed, unidirectional traffic engineered
   tunnel, which spans two hops of a simple network.
   Note that these objects should be created on the
   "head-end" LSR.
 
States that this is created on the head end LSR, how are the objects propagated to the intermediate nodes in your scenario?

        Via the signaling protocol.

        --Tom

Thanks,
Bill

-----Original Message-----

From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]

Sent: Friday, June 02, 2000 2:39 PM

To: mpls@UU.NET

Cc: Cheenu Srinivasan; arun Viswanathan

Subject: Additional Index for TE-MIB: mplsTunnelTable

    Hi,

I would like to modify the mplsTunnelEntry to include

a few more objects as well as indexes. I wanted to

bring these changes to the list for discussion before

adding them to the TE MIB due to the fact that they

constitute a significant change, and we did not want to

surprise anyone. This change comes from my implementation

experience with the current version of the MIB, so it is

grounded in an actual implementation.

I would like to add five additional values to the mplsTunnelTable

as well as augment the current indexes with two more indexes:

mplsTunnelSrcAddrType     INTEGER,

mplsTunnelSrcAddrIPv4   InetAddresIPv4,

mplsTunnelSrcAddrIPv6   InetAddresIPv6,

     Now let me explain why. When you want to examine the tunnel
     entry at a midpoint, it is possible for tunnelId/tunnelInstance
     collisions to occur because the mplsTunnelId + mplsTunnelInstance
     variables are not guaranteed to be unique within an MPLS domain.
     A simple example of this occurs when LSR A has tunnelId = 1,
     tunnelInstance = 0 and LSR B has tunnelId = 1, tunnelInstance = 0
     which utilize the same next hop, LSR C. If one examines the
     tunnel table at LSR C, it is impossible to distinguish both tunnels;
     hence, the third index. A fourth index is required because we need
     to support V6 addresses.

     An additional benefit of the added indexes is that one can now
     sort tunnelEntries based on src address, which is quite useful
     at mid-points and tunnel tails. For this same reason, it might be
     useful to add the tunnel destination address to the indexes of
     this table as well.
     
     --Tom