The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Feb> msg00167



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

PID in LDP

  • From: David Charlap <david.charlap@marconi.com>
  • Date: Thu, 15 Feb 2001 16:55:16 -0500

Eric Gray wrote:
> 
> I see at least three issues here:
> 
> 1) whether or not it makes sense to transport non-IP packets
>     using (base) LDP;
> 2) whether or not it makes sense to use CR-LDP to setup LSPs
>     for multiple L3 protocols in an enterprise LAN environment;
> 3) under what circumstances will it make sense to try to route
>     non-IP packets even in an enterprise LAN environment.
> 
> I believe one answer could be made to address all of these issues:
> simply define a new FEC type for additional L3 protocols.  The
> main reason why I would advocate this approach - as opposed
> to defining an L3PID TLV, is that it can only make sense for an
> intermediate LSR to attempt to route ANY L3 packet if it knows
> how to route that L3 packet.  That would imply the analog of a
> route table entry for that L3 protocol address in each intermediate
> LSR on an LSP intended to carry packets for that L3.

This would work.

There would still, however, need to be a way to indicate that the data
in the LSP is not the same type as the FEC, however.  This way a transit
router will know not to try and forward a packet that leaves the LSP in
the middle (due to a transient condition).

If the router handles transient conditions by always dropping packets,
this isn't a problem.  If it tries to forward them, it must know what's
inside.  For instance, a raw digitized audio stream may have a packet
where the first 20 bytes resemble an IP header - nevertheless, you
wouldn't want to use those bytes for a forwarding decision.

The main reason for my advocacy of a L3PID TLV is simply because that's
what RSVP-TE already does (it's a field in the LABEL_REQUEST object).

> A secondary reason for advocating this approach is that (base)
> LDP is fundamentally a hop-by-hop LSP signaling protocol: it
> only really makes sense to signal labels between two adjacent
> LDP peers if each of them knows how to deal with inserting or
> removing packets in the corresponding LSP.

True.  CR-LDP is tunnel-oriented, but LDP is not.

-- David


  • References:
    • PID in LDP
      • From: Eric Rosen <erosen@cisco.com>
    • PID in LDP
      • From: David Charlap <david.charlap@marconi.com>
    • PID in LDP
      • From: Eric Gray <eric.gray@sandburst.com>
    • PID in LDP
      • From: David Charlap <david.charlap@marconi.com>
    • PID in LDP
      • From: Eric Gray <eric.gray@sandburst.com>