Subject: PHP

From: "Sandeep B" <[email-masked]>
Date: Wed, 17 Apr 2002 20:35:32 +0000

David,

You mention using 0x0800 as L3PID no matter what intermediate L2 protocol is 
carrying this traffic. Lets say we have a LDP session running over another 
RSVP Session and this session is a VPN for a frame relay circuit carrying IP 
traffic. Wouldn't we use a L3PID of LDP-MPLS (0x8847) instead of IP for the 
RSVP session.

My understanding was that this particular RSVP session should get 
information from LDP protocol on ingress that this session would be used for 
MPLS traffic and it should setup LSP with L3PID of MPLS. I assume this is 
what you meant by -

David> "It is the responsibility of the ingress and egress nodes to be able 
to map between the interface's local encapsulation (PPP, or whatever) and 
standard Ethertype values"

-Sandeep

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: David Charlap <[email-masked]>
Date: Wed, 17 Apr 2002 17:04:27 -0400

Sandeep B wrote:
> 
> You mention using 0x0800 as L3PID no matter what intermediate L2
> protocol is carrying this traffic. Lets say we have a LDP session
> running over another RSVP Session and this session is a VPN for a
> frame relay circuit carrying IP traffic. Wouldn't we use a L3PID of
> LDP-MPLS (0x8847) instead of IP for the RSVP session.

No.  When you tunnel one LSP through another, you should push a new
label onto the label stack.  The labeled packet's payload is still IP.

You do not send the entire labeled packet - headers and all - into the
inner LSP.

For example, given this topology:

             /\       /\            /\       /\
	____/ A\_____/ B\__________/ C\_____/ D\____
         1  \  /  2  \  /     3    \  /  4  \  /  5
             \/       \/            \/       \/

Router A is an ingress router for the outer LSP.
Router B is an ingress router for the inner LSP.
Router C is an egress router for the inner LSP.
Router D is an egress router for the outer LSP.

An unlabeled IP packet arrives at router A on segment 1.

The packet that is sent from A to B on segment 2 should be a labeled
packet with one label.  Assuming an interface that uses generic
encapsulation, it will look like:

	SHIM HEADER (with one label)
	IP packet

The packet that is sent from B to C on segment three should be a labeled
packet with two labels.  It should look like:

	SHIM HEADER (with two labels)
	IP packet

Please note that the payload under the shim header is still the IP
packet.  Which is why the L3PID should still be 0x0800.

It is not what you were describing:

	SHIM HEADER (with one label)
	SHIM HEADER (with one label)
	IP packet

In this configuration, the payload of the first shim header would be
another shim header - making the L3PID for the inner LSP 0x8847.  But
this is not how hierarchical LSPs are supposed to be established.

-- David

---

From: "Vach Kompella" <[email-masked]>
Date: Wed, 17 Apr 2002 14:31:51 -0700

David,

So what if they are not "IP packets" but "Ethernet packets" or "Frame Relay
packets" in the PWE3 sense of the word.  As the PE LER for, say, a martini
ethernet pipe, do you want to know about the protocol of the customer packet?
If you penultimate-pop the outer label, you end up with a VC label.  As the
penultimate hop, you certainly don't want to mess with the VC label.  You just
want to pass it on to the next hop and let it send it down the appropriate PE-CE
link.  What do you say is the "ethertype" of the packet with the VC label?

I think I understand your point about the label stack being treated as a single
stack, but it precludes different meanings being given to a label, as in
forwarding label vs. demux label.

-Vach

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of David
> Charlap
> Sent: Wednesday, April 17, 2002 2:04 PM
> To: [email-masked]
> Subject: Re: PHP
>
>
> Sandeep B wrote:
> >

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Apr 2002 00:26:25 -0700 (PDT)

On Wed, 17 Apr 2002, Vach Kompella wrote:

> packets" in the PWE3 sense of the word.

Perhaps you are all agreeing, in different ways (not unusual).

> 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).

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.)

> 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.

Kireeti.

---

From: Markus Jork <[email-masked]>
Date: Thu, 18 Apr 2002 10:37:59 -0400

> and signal LSPs used for draft-martini with 0x8847.

It looks to me as if the L3PID signaling seemed like a good idea at the
time but turned out to be not particularly useful. The problem is that
it is often unknown what type of traffic is carried on an LSP. For
example an RSVP LSP can be used to carry IP traffic and at the same time
also labeled traffic from a targeted LDP session that runs over the RSVP LSP.
The type of traffic underneath the LDP label (either IP or some L2
protocol) cannot be known by the RSVP ingress router. So part of the
traffic across the RSVP LSP is known to be IP, the other part is
unknown. What L3PID is the right one to use? Currently, these LSPs are
signaled with a L3PID of IP.

The L3PID as currently defined in RSVP-TE does not have any practical
value as far as I can tell. Maybe it should be redefined to only
apply to packets with a label stack of 1 while all other packets on
the LSP with label stack > 1 are simply of unknown protocol type.
That way the L3PID is at least useful for the penultimate hop to check
whether it's ok to do PHP.

Markus

---

From: David Charlap <[email-masked]>
Date: Thu, 18 Apr 2002 11:27:02 -0400

Kireeti Kompella wrote:
> 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.

> 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.

> 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

---

From: David Charlap <[email-masked]>
Date: Thu, 18 Apr 2002 11:33:24 -0400

Markus Jork wrote:
> 
> It looks to me as if the L3PID signaling seemed like a good idea at
> the time but turned out to be not particularly useful. The problem
> is that it is often unknown what type of traffic is carried on an
> LSP.  For example an RSVP LSP can be used to carry IP traffic and
> at the same time also labeled traffic from a targeted LDP session
> that runs over the RSVP LSP.

The L3PID of the inner LSP is known, because it is signaled as IP.

The ingress router for the inner LSP also knows the L3PID of the outer
LSP, since it must participate in the signaling for the outer LSP.

I would argue that it should not shunt incompatible traffic into that
LSP.  Don't allow a non-IP LSP to tunnel through an IP-LSP.

If the inner LSP is meant to carry traffic of many different types, then
it should be signaled as such.  With an L3PID meaning "unknown".  Which
would mean, of course, that the egress of such an LSP would not be able
to handle a packet that only has one label - since it won't know the
actual L3PID after popping that last label.  But this would be OK, if
there's another label on the stack - either indicating an outer LSP to
use for forwarding, or indicating the L2/L3 PID.

Of course, the whole argument falls apart when you realize that the two
LSPs (inner and outer) don't both have to be RSVP.  I don't think L3PID
is signaled with LDP or CR-LDP.

-- David

---

From: Eric Rosen <[email-masked]>
Date: Thu, 18 Apr 2002 12:18:49 -0400

David> I would argue that it should not shunt incompatible traffic into that
David> LSP.  Don't allow a non-IP LSP to tunnel through an IP-LSP. 

What would be the point of this? 

I  admit I've  never  quite understood  the  role of  the  L3PID in  RSVP-TE
signaling. 

In practice, the only situations in which PHP causes a packet's bottom label
to be  popped off are  situations in which  the payload is an  "ordinary" IP
packet.  If the  payload is a layer 2  frame encapsulated via draft-martini,
or a VPN packet encapsulated according to one of the L3VPN schemes, then PHP
will never result in the bottom label being popped off.

So in practice, PHP always results in either an IP packet or an MPLS packet,
and the  appropriate ethertype (IP or  MPLS) can then be  applied before the
packet is transmitted to its next hop.

---

From: David Charlap <[email-masked]>
Date: Thu, 18 Apr 2002 13:24:47 -0400

Eric Rosen wrote:
> 
> I  admit I've  never  quite understood  the  role of  the  L3PID in
> RSVP-TE signaling.

It's so the egress router will know what to do with the packet after
popping the last label.

If you don't provide this (like LDP doesn't) then you must either assume
everything is IP, or you must use some out-of-band mechanism for
distributing this information.  Either way, it pretty much defeats the
multiprotocol capabilities of MPLS.

> In practice, the only situations in which PHP causes a packet's
> bottom label to be  popped off are  situations in which the payload
> is an "ordinary" IP packet.

Why are you forcing it to be IP?  Why can't people using other L3
protocols also send traffic through LSPs?

> If the payload is a layer 2 frame encapsulated via draft-martini,
> or a VPN packet encapsulated according to one of the L3VPN schemes,
> then PHP will never result in the bottom label being popped off.

There are more non-IP protocols than VPNs.

And why is it so superior to carry the L3 protocol ID in every single
packet, instead of signaling it once when the LSP is established?

-- David

---

From: Eric Rosen <[email-masked]>
Date: Thu, 18 Apr 2002 13:48:10 -0400

Eric> I  admit I've  never  quite understood  the  role of  the  L3PID in
Eric> RSVP-TE signaling.

David> It's so the egress router will know what to do with the packet after 
David> popping the last label. 

... assuming  that the  bottom label represents  the RSVP-TE  tunnel, rather
than a route of some particular  L3 protocol.  If you run, say, directed LDP
through the  RSVP-TE tunnel  to assign  labels to L3  routes (of  various L3
protocols),  then you  don't need  the L3PID,  since the  bottom  label will
identify the L3 protocol.

David> If you  don't provide  this (like LDP  doesn't) then you  must either
David> assume everything is  IP, or you must use  some out-of-band mechanism
David> for  distributing  this  information.   Either way,  it  pretty  much
David> defeats the multiprotocol capabilities of MPLS. 

It's not that  you have to assume  that everything is IP, it's  just IP gets
special treatment;  it's the only sort  of unlabeled packet that  can be put
into an RSVP-TE tunnel.  Other L3s  just need to get labeled first. (Another
alternative, if you wanted to put multiple L3s into a single RSVP-TE tunnel,
would be to require that L3  packets in the tunnel first get encapsulated in
something that provides an L3PID.) 

David> And why is it so superior to carry the L3 protocol ID in every single
David> packet, instead of signaling it once when the LSP is established? 

Carrying the  L3 protocol id  in ever packet  allows packets of  multiple L3
protocols to  use a single RSVP-TE  tunnel.  Signaling the  L3PID "once" for
each protocol  requires multiple RSVP-TE  tunnels.  As these  tunnels create
state in the core routers, it seems like  a very bad idea to set up an extra
RSVP-TE tunnel simply to help with the L3 identification.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Apr 2002 15:05:32 -0700 (PDT)

> introduced.  Perhaps something like this:

It's been done -- check out the G-PID in generalized signaling (only
for L1 and L2).

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Apr 2002 15:08:28 -0700 (PDT)

On Thu, 18 Apr 2002, Markus Jork wrote:

> time but turned out to be not particularly useful.

It's not that bad, but it is less than optimal.  One could use IP
LSPs for IP, IP VPNs, etc., where the payload is IP; and establish a
parallel set of LSPs for non-IP traffic.

> Maybe it should be redefined to only

That was my suggestion when this topic came up 2+ years ago, got
little traction.  I still like it, though :-)

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 18 Apr 2002 15:15:37 -0700 (PDT)

> packet is transmitted to its next hop.

How does one distinguish IPv4 from IPv6?

One could use the 'check first nibble' hack :-(  It would be neater
to use the L3PID.

Kireeti.

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 18 Apr 2002 15:26:02 -0700

I like that idea.  Since, from a need-to-know point of view, the outer LSP
doesn't care, why make it visible?

-Vach

> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Thursday, April 18, 2002 3:08 PM
> To: Markus Jork
> Cc: Vach Kompella; David Charlap; [email-masked]
> Subject: Re: PHP
>
>
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 22 Apr 2002 10:28:31 -0400

Kireeti> One could use  IP LSPs for IP, IP VPNs, etc.,  where the payload is
Kireeti> IP; and establish a parallel set of LSPs for non-IP traffic. 

I think the impact on the core makes this one a non-starter. 

Markus> Maybe it should  be redefined to only apply to  packets with a label
Markus> stack of 1 while  all other packets on the LSP with  label stack > 1
Markus> are simply of unknown protocol type. 

Isn't this really the de facto standard interpretation?

Eric> So in practice,  PHP always results in either an IP  packet or an MPLS
Eric> packet, and the appropriate ethertype (IP or MPLS) can then be applied
Eric> before the packet is transmitted to its next hop. 

Kireeti> How does one distinguish IPv4 from IPv6? 

Kireeti> One could use the 'check first  nibble' hack :-( It would be neater
Kireeti> to use the L3PID. 

Well, I wouldn't want to have to  set up a separate TE tunnel just to handle
the IPv6 traffic, so I'd recommend the "check first nibble" hack.

---

From: Eric Rosen <[email-masked]>
Date: Tue, 23 Apr 2002 11:17:25 -0400

Eric> Well, I wouldn't want  to have to set up a separate  TE tunnel just to
Eric> handle the  IPv6 traffic,  so I'd recommend  the "check  first nibble"
Eric> hack.  

Actually, there is a real  interoperability issue lurking here which we need
to get clear on. 

In  conjunction with  php, "check  first nibble"  could mean  either  of the
following: 

1. The penultimate  node pops the last  label off the stack,  creates a data
   link layer frame with IPv4 as the protocol type, and transmits the frame.
   The receiver  of the  frame checks the  first nibble  to see what  the IP
   version is  and treats  the packet as  IPv4 or  IPv6 depending on  the IP
   version.

2. The penultimate node pops the stack,  checks the first nibble to see what
   the IP version  is, and creates a data link layer  frame with either IPv4
   or IPv6  as the protocol type, depending  on the value of  the IP version
   field. 

What I meant was 1; I'm not sure which Kireeti meant.

---

From: Markus Jork <[email-masked]>
Date: Tue, 23 Apr 2002 11:47:54 -0400

> What I meant was 1; I'm not sure which Kireeti meant. 

I certainly would have expected option 2!

Markus

---

From: Eric Rosen <[email-masked]>
Date: Tue, 23 Apr 2002 12:02:13 -0400

Markus> I certainly would have expected option 2! 

Well, the problem with option 2  is that MPLS forwarding likes to obtain the
data link  header as  a result  of the label  lookup.  So  I would  say that
option 2 isn't really an option.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Apr 2002 12:31:05 -0400

>option 2 isn't really an option.

But when you remove the last label, it is then necessary to do some IP 
header processing such as TTL decrementing or, at the least, 
inheriting.  Granted, there are different models (uniform, pipe, 
short-pipe) for handling TTL, but several of the models clearly presume 
that the LSR popping the last label must handle the TTL.  To handle the 
TTL, the LSR must know what type of packet is underneath (IPv4 or IPv6 or...).

Could you clarify how you'd envision the appropriate behavior here if the 
MPLS forwarding can't look underneath the MPLS shim header, when it is 
popping the last one?

This isn't a limitation in the MPLS forwarding layer which I am familiar with.

Thanks,
Alia

---

From: Eric Rosen <[email-masked]>
Date: Tue, 23 Apr 2002 13:00:44 -0400

Eric> the problem with option 2  is that MPLS forwarding likes to obtain the
Eric> data link header as a result of the label lookup

Alia> But when you remove the last label, it is then necessary to do some IP 
Alia> header  processing  such  as   TTL  decrementing  or,  at  the  least,
Alia> inheriting. 

You are correct, but that does not contradict my statement. 

It's clear  that performing  the TTL  processing when you  pop off  the last
label requires manipulating  the IP header.  But the  MPLS specs say nothing
about using the contents of the header to help choose the outgoing data link
header, except  in the case  where the label  lookup indicates that  the LSR
itself is the packet's next hop.

So  an implementation  that is  compliant with  the  existing specifications
cannot necessarily  be relied  upon to  perform option 2  when a  single LSP
carries both IPv4 and IPv6, and PHP is used.

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 23 Apr 2002 10:14:35 -0700 (PDT)

> What I meant was 1; I'm not sure which Kireeti meant.

I meant 2.  One could do 1, I suppose, but that pushes the hack to
the IP stack.  2 keeps the hack within the MPLS stack.

Kireeti.

---

From: Markus Jork <[email-masked]>
Date: Tue, 23 Apr 2002 13:25:40 -0400

> carries both IPv4 and IPv6, and PHP is used.

Ok, but we are talking about bending the rules of existing specifications
anyway (signaling IPv4 but sending both, IPv4 and IPv6). If you want
to play tricks like that, you better have the hardware to handle it
(including correct TTL processing).

Markus

---

From: Markus Jork <[email-masked]>
Date: Tue, 23 Apr 2002 11:47:54 -0400

Markus