The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

        Hi,

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

        

Yes, your
understanding of the MIB seems correct. Initially the intent
of the TE MIB was for its information to be available at the ingress
and
egress. However, some implementations may choose to make intermediate
tunnel hop information available at midpoints along the tunnel's path.
There
is nothing in the standards which precludes this. However, since this
is
an optional behavior, we did not make it mandatory in the MIB.

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

        

I think
that this is an implementation issue. For example, if
one's device supports RSVP, then one may obtain this information
at intermediate nodes by capturing the recorded route.

        

--Tom