The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Apr> msg00149



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

PHP

  • From: David Charlap <David.Charlap@marconi.com>
  • Date: Thu, 18 Apr 2002 11:27:02 -0400

Kireeti Kompella wrote:
> David wrote:
> 
>> Please note that the payload under the shim header is still the IP
>> packet.  Which is why the L3PID should still be 0x0800.
> 
> David's point is, an LSP used to carry IP is signaled with an L3PID
> of 0x0800, no matter what L2 protocol the LSP is carried *over* and
> no matter how deep the label stack is (correct me if I misread you,
> David).

That would be correct.

> However, if an L2 protocol is carried *over* the LSP (e.g., Frame
> Relay over MPLS using draft-martini), then the LSP should not be
> signaled (strictly speaking) with an L3PID of IP.  (Note: the
> payload under the shim header (label stack) is no longer IP.)

Also correct.  If they payload is non-IP, then the L3PID should
represent whatever that payload is.

>> What do you say is the "ethertype" of the packet with the VC label?
> 
> One could use the convention of "ethertype of 0x8847 means dunno",
> and signal LSPs used for draft-martini with 0x8847.

If the LSP is carrying L2 traffic, then obviously the concept of
ethertypes is meaningless, since Ethernet is an L2 protocol.

Ideally, I'd think that a new object, used to indicate the presence of a
non-L3 payload (with various C-Types specifying different layers, and
the object payload indicating the protocol ID at that layer) should be
introduced.  Perhaps something like this:

    C-TYPE = 1 --> L1 LSP
        payload = parameters defining the L1 characteristics.
            This would include the L1 type (SONET, SDH, RS-232, etc.),
            and parameters for defining the configuration of that L1
            type (bit-rate, framing params, etc.)

        This would be useful for signaling circuit-emulation LSPs,

    C-TYPE = 2 --> L2 LSP
        payload = ID's indicating L2PID (Ethernet, 802.11, PPP, etc.)

    C-TYPE = 3 --> L3 LSP
        payload = IDs indicating L3PID (IP, AppleTalk, etc.)

        This object would be redundant with the L3PID in
        LABEL_REQUEST, but is here for completeness.

    C-TYPE = 4 --> L4 LSP
        payload = IDs indicating L4PID (TCP, UDP, etc.)

        It might someday be convenient for these kinds of protocols
        to run directly over MPLS, without the IP layer.  Imagine a
        proxy that establishes an LSP with a matching proxy somewhere
        else.  This C-TYPE would be a placeholder for such future
        functionality.

It might make sense to define C-TYPEs for all 7 layers, but I can't
imagine what an L5, L6, or L7 LSP might be used for.

-- David


  • Follow-Ups:
    • PHP
      • From: Kireeti Kompella <kireeti@juniper.net>
  • References:
    • PHP
      • From: Kireeti Kompella <kireeti@juniper.net>