[c-nsp] Static MPLS labels/tunnels

[Phil Mayers]

On 11/20/2010 07:19 PM, Roman A. Nozdrin wrote:
> On 20.11.2010 14:43, Phil Mayers wrote:
>> Quick question - this is for my curiosity rather than anything, as I've
>> never done this before.
>>
>> We have a few RAD IP-Mux boxes (E1->IP). They claim to support MPLS, and
>> allow you to specify an outgoing and incoming MPLS label for a circuit.
>> They don't seem to support any dynamic protocol e.g. LDP, BGP or so forth.
>>
>> Not that I want to, but: how would one configure the interfaces on a
>> 6500/sup720? That is, give the network:
>>
>> mux1 == 6500-1 == (cloud of P-routers) == 6500-2 == mux1
>>
>> ...what do I type in on 6500-1 and 6500-2 to configure an LSP and bind a
>> fixed label mapping into and out of that LSP?
>
> Sounds pretty interesting. As RAD mux uses IP as a transport proto it
> might not be necessary to use xconnect. I think you should use the IP of
> the remote RAD as an LSP destination address at both sites.

We're running them in production in TDM-over-IP mode without a 
problem[1]. It's not necessary; I'm just curious ;o)

In case anyone is wondering, they seem to implement RFC 5087; the MPLS 
stuff is section 4.2

I don't think the intent is to use the IP of the RAD mux at all (except 
perhaps as a "dummy" target for the LSP); I think what you do is 
something like this:

  1. mux A transmits Ethernet(src=muxA,dst=routerA)/MPLS(label=N)/payload
  2. router A receives MPLS frame; performs imposition, forwards
  3. repeat across the LSP
  4. router B performs final pop (still one label, for the mux)
  5. mux B received Ethernet(src=routerB,dst=muxB)/MPLS(label=N)/payload

That is, no IP traffic need be exchanged at all.

So, basically I'm asking:

How on a 6500/sup720 can you configure a static MPLS binding to forward 
packets arriving with label N at router A, ingress interface X to emerge 
from router B, egress interface Y, label N?

The answer that Tassos gave may be correct; I just don't know how to 
"dummy up" the IPs in the label binding commands. Alternatively I would 
have thought you could do something like this:

int TunnelX
   ! LSP commands
mpls route label N interface INGRESS TunnelX

Cheers,
Phil

[1] When I say "running without a problem" - there is no FEC in the 
protocol, so loss of a single IP packet can cause an E1 error condition 
if that packet happened to contain control channel octets. This has 
required a pretty fast deployment of QoS on the network!