Subject: IP PW labeling

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 12 Nov 2003 04:18:25 +0200

Hi everyone, 

Last night an important point came up once again,
one we have been avoiding for too long.

For the MPLS case we have a single agreed upon
method of putting the PW label onto the packet.
It is placed in an MPLS-style "inner label"
which is at the bottom of the stack.

We have never resolved where the PW label goes
for the IP case.

There are at least three possibilities.

1) Using the UDP source or destination port field.
   The problem is that using the UDP destination port
   (which is what RTP does) is non-standard use,
   since this field should be an application
   demuxer, not a PW demux. Although PWE devices
   may not be general purpose servers expected
   to respond in the completely standard way to 
   socket identifiers, it would not be unusual
   for certain UDP port numbers to be used,
   e.g. TFTP for SW upgrade, SNMP for management.
   Alternatively, we could use a well known UDP 
   destination port number identifying the PWE service, 
   and the IDP source port for PW label.

   This is the most efficient method in that
   it does not require any additional overhead.
   
2) We can use L2TPv3 as the demuxing mechanism.
  This has been discussed at length in the past,
  and seems to be a clean solution, even if nothing
  else of the L2TP is needed.

3) We can use "MPLS-light", i.e. slap on an MPLS-style
  inner label before the control word.

Which of these methods does the WG want to endorse?
Or do we want to allow everyone to pick what they want?

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 12 Nov 2003 17:26:18 +0200

Yaakov and all,
Please see some comments inline.
 
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]]
Sent: Wednesday, November 12, 2003 4:18 AM
To: [email-masked]
Subject: [PWE3] IP PW labeling

Hi everyone,

For the MPLS case we have a single agreed upon
method of putting the PW label onto the packet.
It is placed in an MPLS-style "inner label"
which is at the bottom of the stack.
[[Sasha]] Please note that this method comes complete with a signaling
protocol (Martini LDP extension). This protocol is now a WG document that
have completed its WG Last Call and, to the best ofmy knowledge, has gained
the de-facto industry acceptance even before that. A signaling protocol
serves as an extremely powerful tool, e.g., by allowing shutdown of one
endpoint of the PW if the other one has failed etc.

We have never resolved where the PW label goes
for the IP case.
[[Sasha]] The architecture draft suggests several options..  

1) Using the UDP source or destination port field.
   The problem is that using the UDP destination port
   (which is what RTP does) is non-standard use,
   since this field should be an application
   demuxer, not a PW demux. Although PWE devices
   may not be general purpose servers expected
   to respond in the completely standard way to
   socket identifiers, it would not be unusual
   for certain UDP port numbers to be used,
   e.g. TFTP for SW upgrade, SNMP for management.
[[Sasha]] I do not see any problem here nor does usage of some well-known
UDP port numbers (You should probably add NTP,Radius and more to your list)
prevent successful usage  of destination UDP port as a PW demultiplexer. The
real  problem with using UDP is that it only admits manual configuration.
   Alternatively, we could use a well known UDP
   destination port number identifying the PWE service,
   and the IDP source port for PW label.

2) We can use L2TPv3 as the demuxing mechanism.
  This has been discussed at length in the past,
  and seems to be a clean solution, even if nothing
  else of the L2TP is needed.
[[Sasha]] L2TP provides both demultiplexing and a control protocol. This is
its main advantage, and the L2TPExt WG has adopted a series of WG items
describing signaling detailsfor may specific L2 services (FR, HFLC, Ethernet
etc.). 

3) We can use "MPLS-light", i.e. slap on an MPLS-style
  inner label before the control word.
[[Sasha]] IMO the data plane of such a proposal is fully covered by the
MPLS-in-IP/GRE/IPSec and it can go along with the same Martini-extended LDP
as the control protocol. I can see a problem for the vendors (and,possibly,
customers), who can find required degree of understanding of MPLS and LDP in
devices that actually are not parts of any MPLS network problematic.
Additional advantage of L2TPv3 is that it inherently established
bi-directional connections (suitable for PWs) while LDP establishes
uni-directional PW LSPs, and additional logic (described in somedetail in
the PWE3 control protocol draft) is required to "pair" these into
bi-directional PWs). 

The bottom line: IMO, the real difference is not in the data plane (unless
we consider UDP checksums an advantage even if, as we know, they are
routinely disabled) but in the complexity and flexibility of a control plane
(or the consequences of not having one altogether). 

Y(J)S