The MPLS WG Archive

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

Eric Gray wrote:
> 
>     I fail to see why you have demonstrated a real need to tell
> intermediate LSRs what kind of traffic they are forwarding on a
> specific LSP.
> 
>     It seems to me that you need only to indicate if the packets are
> something that the intermediate LSR might know how to forward or not.
> Since you stipulate that you would only need to be able to make this
> distinction when using CR-LDP, then this is only needed for CR-LDP.

I stipulate that streaming media applications only make sense over
CR-LDP.

But there is a second category of non-IP traffic, namely legacy LAN
traffic.  While an ISP core network won't be seeing this (except as part
of a VPN connection), an enterprise network might.

In such a situation, merely knowing whether or not the packet can be
routed isn't enough.  The router also has to know what the packet is, so
it can locate appropriate addressing information.

I realize that most MPLS work is focussing on ISP core networks, but you
shouldn't assume that those are the only networks that will ever want to
use it.  An optional TLV to carry L3PID information isn't a big deal.

>     CR-LDP defines a FEC which carries the meaning you seek.

Where?  I just re-read it again and didn't find this.

> Second:
> 
>     Have you looked at proposals for transporting compressed headers
> over MPLS?  With such an approach, it is difficult to see what the
> real advantage is in omitting the IP header when transporting data via
> an LSP.

The means of encapsulating streaming data in an LSP I mentioned is just
an example.  I did not mean to suggest it as the way things should be
done.

-- David



> David Charlap wrote:
>> Eric Rosen wrote:
>>>
>>> It seems to me that label explosion occurs whether the LSPs are set
>>> up in an unsolicited manner or whether they are set up explicitly.
>>> You must be assuming that the number of labels needed to represent
>>> VPN or layer 2 tunnels is just a small fraction of the total number
>>> of labels per node.
>>
>> Who said anything about VPN?  You know as well as I do that a private
>> address is meningless outside of its own network.  If a transient
>> condition would cause such a packet to hit a router without an NHLFE,
>> there's no way the packet is going to be forwarded, no matter how
>> it's encoded.
>>
>> I explicitly said that a PID field is needed for non-IP traffic.
>> This is not an IP packet with a private address being tunneled across
>> a public network.
>>
>> There are two uses for non-IP traffic I can think of:
>>
>> 1: Streaming data (like voice).
>>
>>    It makes sense for media server or media gateway to strip off as
>>    much overhead as possible (like IP headers) and just send the PCM
>>    (or MPEG, or H.323, or whatever) stream directly in the LSP.
>>
>>    A transit router won't be able to forward these packets without
>>    the labels, since there's no address information in the data
>>    stream, but it will be able to identify the traffic as something
>>    that is not routable.
>>
>>    Of course, this is really not applicable for LDP, but CR-LDP,
>>    since some level of QoS will be desired for these applications.  I
>>    doubt customers would be happy if this traffic was treated like
>>    all other traffic to the destination.
>>
>>    Yes, DiffServ and the EXP bits can be used, but not everyone is
>>    going to support DS, and DS may not provide the required
>>    granularity.  (Imagine 20 different streams, each with a different
>>    QoS requirement?)
>>
>>    In this situation, you're not changing the potential for label
>>    explosion, because a customer in this scenario is going to have to
>>    be using CR-LDP and L-LSPs anyway.  Tacking on an extra TLV so
>>    that the content can be identified is not a big deal.
>>
>> 2: Legacy LAN traffic.
>>
>>    If someone wants to connect two legagy Netware (or Appletalk,
>>    etc.) servers across the internet, it would be nicer to pass the
>>    packets in an LSP instead of tunneling them through IP.  A transit
>>    router may know how to route these.  (Probably not in an ISP core,
>>    but possibly in an enterprise network.)
>>
>>    I can't imagine this being a large amount of traffic, however.