The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

neil.2.harrison@bt.com wrote:
> 
> Can I just check something here David.....in the martini-trans ID
> I believe only LDP is allowed for signalling XoverMPLS LSPs.  If
> so, then how can we signal the payload 'X' of the LSP for such
> XoverMPLS cases?  I always assumed that the 'multiprotocol' aspects
> would be taken care of by label semantics in lieu of no PID field
> in the MPLS header.

That would be correct.

> So am I right one cannot signal this and only configure it?

I don't know of any way to signal an association between these labels
and the protocols they represent.  If they're not pre-defined by
standards, they will have to be configured.

> And why is RSVP-TE say prohibited for the setting up the inner
> LSP?

It's not.

But the inner LSP isn't going to be able to know a-priority that it will
only be used for tunneling other LSPs through it.  It will have to be
able to correctly de-encapsulate a packat that arrives at the egress
node with only one label on it.  In RSVP-TE, the L3PID field in the
LABEL_REQUEST tells it how to do this.  If you signal the LSP with
something that the egress switch can't de-encapsulate, the LSP will
probably be rejected.

If you know that the egress switch will never receive a one-label packet
(which is beyond the scope of signaling protocols), then you can simply
set up the inner LSP as an IP tunnel.  Now, it will behave the way LDP
does - requiring that a protocol-identifying label be at the bottom of
the label stack.

In LDP, it is assumed that this packet must be IP, so the problem never
comes up.  Anything that's not IP must have a second protocol-
identifying label on the stack.

-- David