Subject: ITU-T Q5/13 Liason re PW over UDP

From: Stewart Bryant <[email-masked]>
Date: Mon, 21 Jun 2004 09:25:40 +0100

It has not yet appeared on the IETF Liaison web page, but the following
Liaison statement is in the process of being sent from ITU-T Q5/13 to IETF-PWE3

As you can see we been asked recommend the correct method of multiplexing
a PW over UDP.

- Stewart

Q5/13 is extending ITU-T Recommendations specifying interworking LSPs (PWs) over 
MPLS networks, to networks based on UDP/IP.
We understand that your charter also defines UDP/IP as a possible packet 
switched network infrastructure.
Due to the lack of an interworking LSP label, a connection de-multiplexing 
mechanism must be devised for this case.
Our analysis has uncovered five possibilities for using UDP port numbers as 
connection de-multiplexers, namely:

1.	Use of destination port as application de-multiplexers, and source + 
destination socket as connection de-multiplexers. This method (used by HTTP) 
restricts a pair of end-points to a single simultaneous connection, and hence is 
not relevant for interworking LSPs (PWs).

2.	Use of destination port number to identify a protocol setup message, and 
implicit allocation of port numbers by originator. This method (used by telnet) 
is limited to asymmetric applications, and so is not relevant for interworking 
LSPs (PWs).

3.	Use of destination port number to identify a control protocol, and explicit 
allocation of port numbers (either downstream or upstream). This method (used by 
FTP) could be applicable to interworking LSPs (PWs), but would require the 
development of a new control protocol. Such a protocol could be based on a 
subset of targeted LDP.

4.	Use of destination port number as application de-multiplexer, and source port 
number as connection de-multiplexer. This method (used by the 
draft-ietf-pwe3-tdmoip-01.txt) is possibly the simplest to implement, but 
non-standard.

5.	Use of destination port number as connection de-multiplexer, and optionally 
source port number as application de-multiplexer. This method (the first part of 
which is used by RTP) seems to violate both conventional usage of destination 
port numbers as application de-multiplexers, and common sense by differentiation 
between different sources based on destination port.

Since we have to complete our draft Recommendation shortly, we would appreciate 
that you inform us of your preferred method.

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 21 Jun 2004 13:19:37 +0200

Stewart and all,
Please see some personal comments on the assumed liaison text inline below
(marked [Sasha]).

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Monday, June 21, 2004 10:26 AM
> To: [email-masked]; Scott Bradner
> Cc: Thomas Narten; Danny McPherson; Peterson, Jon
> Subject: [PWE3] ITU-T Q5/13 Liason re PW over UDP
> 
> 
> We understand that your charter also defines UDP/IP as a 
> possible packet switched network infrastructure.
> Due to the lack of an interworking LSP label, a connection 
> de-multiplexing mechanism must be devised for this case.
>
[Sasha] As a general comment, I'd say that the method
used for demultiplexing PWs over UDP/IP should not be architecturally
different from the other demultiplexing methods used in PWE3, 
e.g. MPLS or L2TPv3. In particular:
1. The demultiplexers exist in the PWE3 data plane, and
   are distributed using manual configuration or some control
   protocol.
2. The demultiplexer value for each direction of the PW is
   allocated by the corresponding egress PW
3. If a control protocol is used, the demultiplexer value is 
   distributed from the egress to the ingress PE for each 
   direction of the PW.
In addition, one should avoid using architectural elements
that have not been specified in the PWE3 Architecture.
> not relevant for interworking LSPs (PWs).
[Sasha] IMO the PWE3 architecture does not define any "applications"
and/or "application de-multiplexers". 
> is limited to asymmetric applications, and so is not relevant 
[Sasha] AFAIK, Telnet uses a well-know port on the server side and
a dynamically (for the duration of the connection) allocated
port on the client side. Since PWs are not client-server
applications, I agree that this method is inappropriate.
> development of a new control protocol. Such a protocol could 
[Sasha] I'd say that a more relevant example is establishment over
a L2TPv2/v3 over UDP Tunnel/Control Connection. This technique
(described in RFC 2661) results in:
- each peer allocating a locally free UDP port as the de-multiplexer 
  value for the direction of the connection for which it is the receiver
- using the allocated value as the Source UDP port in all the messages
  it sends save from the SCCRQ message (which is sent to the well-known
  port)
- using the similar value allocated by the peer as the Destination UDP port
  in all the messages it sends save from the SCCRQ message which is sent 
  to the well-known port because the peer allocation is not known yet.
> draft-ietf-pwe3-tdmoip-01.txt) is possibly the simplest to 
> implement, but non-standard.
>
[Sasha] In addition top referring to a non-existent "PWE3 application",
this method does not specify which side ALLOCATES the demultiplexer.
> between different sources based on destination port.
[Sasha] Leaving aside the emotional side, I'd like to point out that
in the PWE3 architecture de-multipexers are commonly used to
identify the DESTINATION PW endpoints in the egress PEs in the
data plane, so that this method fully complies with my
common sense (for whatever it is worth). In addition
it can be easily combined with a suitable control protocol
(see my comment to method #3). Hence I would say that this is
definitely the preferable method.
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 21 Jun 2004 16:25:43 +0300

Sasha and all, 

> > Q5/13 is extending ITU-T Recommendations specifying interworking
LSPs 
> > (PWs) over MPLS networks, to networks based on UDP/IP.
> > We understand that your charter also defines UDP/IP as a possible 
> > packet switched network infrastructure.
> [Sasha] As a general comment, I'd say that the method used 
> for demultiplexing PWs over UDP/IP should not be 
> architecturally different from the other demultiplexing 
> methods used in PWE3, e.g. MPLS or L2TPv3. In particular:
>    allocated by the corresponding egress PW 3. If a control 
>    protocol is used, the demultiplexer value is 

Mostly agree.
However, please note that the usage in PWE has followed that of MPLS 
in downstream allocation of PW labels.
This does not necessarily carry over to the UDP case, but may.

> >
> > Our analysis has uncovered five possibilities for using UDP port 
> > numbers as connection de-multiplexers, namely:
> > 
> > destination socket as connection de-multiplexers. This 
> method (used by 
> > HTTP) restricts a pair of end-points to a single simultaneous 
> > connection, and hence is not relevant for interworking LSPs (PWs).
> >

PWE3 doesn't define the application demux - this is a feature of UDP/IP
and TCP/IP.
A UDP/IP PWE IWF may have to handle FTP or HTTP or whatever
in addition to the PWs.

> > implicit allocation of port numbers by originator. This method (used

> > by telnet) is limited to asymmetric applications, and so is not 
> > relevant for interworking LSPs (PWs).
> >
> [Sasha] AFAIK, Telnet uses a well-know port on the server 
> side and a dynamically (for the duration of the connection) 
> allocated port on the client side. Since PWs are not 
> client-server applications, I agree that this method is inappropriate.

You are correct (the various cases are analyzed in the original ITU
contribution).

> > allocation of port numbers (either downstream or upstream). 
> > This method (used by FTP) could be applicable to interworking LSPs
(PWs), but would require 
> > the development of a new control protocol. Such a protocol could be 
> > based on a subset of targeted LDP.
> >
> [Sasha] I'd say that a more relevant example is establishment 
> over a L2TPv2/v3 over UDP Tunnel/Control Connection. This 
> technique (described in RFC 2661) results in:
>   it sends save from the SCCRQ message (which is sent to the
well-known port)
>   to the well-known port because the peer allocation is not known yet.

OK - this is a valid analogy too.

The use of FTP is perhaps somewhat better known,
and interesting in that you can have upstream allocation (port command)
or downstream allocation (pasv command).

> > draft-ietf-pwe3-tdmoip-01.txt) is possibly the simplest to
implement, 
> > but non-standard.
> >
> [Sasha] In addition top referring to a non-existent "PWE3 
> application", this method does not specify which side 
> ALLOCATES the demultiplexer.

As above, the application demux is not a PWE function,
it is a UDP/IP function.

In this case the upstream side allocates.

> > source port number as application de-multiplexer. This method (the 
> > first part of which is used by RTP) seems to violate both
conventional 
> > usage of destination port numbers as application de-multiplexers,
and 
> > common sense by differentiation between different sources based on 
> > destination port.
> >
> [Sasha] Leaving aside the emotional side, I'd like to point 
> out that in the PWE3 architecture de-multipexers are commonly 
> used to identify the DESTINATION PW endpoints in the egress 
> PEs in the data plane, so that this method fully complies 
> with my common sense (for whatever it is worth). In addition 

I note that you don't disagree that conventional (i.e. except RTP)
usage is for destination UDP ports to identifiy applications,
of which PWE is one.

Also, downstream allocation could be used but the label
still placed in the SOURCE port.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 21 Jun 2004 17:47:08 +0200

Yaakov and all,
Thank you for a prompt response.
Please see some answers imline below.

With best regards,
                                   Sasha Vainshtein

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Monday, June 21, 2004 3:26 PM
> To: Sasha Vainshtein; [email-masked]
> Cc: Thomas Narten; [email-masked]; Danny McPherson; Scott 
> Bradner; Peterson, Jon
> Subject: RE: [PWE3] ITU-T Q5/13 Liason re PW over UDP
> 
> 
> Sasha and all, 
> 
[Sasha] Since we allocate the PW demultiplexers downstream in MPLS
and L2TPv3,  a very strong justification is, IMO, required to do 
things differently over UDP. 
> PWE3 doesn't define the application demux - this is a feature 
> of UDP/IP > and TCP/IP.
[Sasha] I have probably missed something. Until now I have
been under impression that a PW IWF hanldes only PW traffic 
and nothing else?
... snipped ... (we seem to agree on this one0!
> 
> > > 3.	Use of destination port number to identify a 
> control protocol,
> and explicit
> > - using the similar value allocated by the peer as the 
> Destination UDP
> port
[Sasha], Well, I can add that TFTP (that presumably is no
less known than FTP) uses exactly the same scheme AND 
downstream Transfer Identification (TID) allocation;
each side places its local TID as the Source UDP port
and the peer TID - as the Destination UDP port in all
the packets it generates excluding the request for
intiation of transfer (WRQ or RRQ) which are sent to
the TFTP well-known port - see RFC 783 for details.
> As above, the application demux is not a PWE function,
[Sasha] But who needs this function? PWE3 can do without
(as it does in the L2TPv3 and MPLS use cases), so why make
life more complicated?
> still placed in the SOURCE port.
[Sasha] I DO disagree and on several counts.
1. RTP, TFTP and L2TPv2 are quite conventional, IMO.
   What's more, they are among the most widely deployed
   UDP protocols AFAIK. 
2. All the UDP-based protocols that deal with bi-directional
   traffic SWAP the source and destination UDP ports for the
   two directions of traffic (some UDP protocols, e.g., SYSLOG,
   are unidirectional by nature so this does not apply). 
   And this is done in a perfect match with the following
   spec (quoted from RFC 768):
<quote>
	Source Port is an optional field, when meaningful, it indicates the
port
	of the sending  process,  and may be assumed  to be the port  to
which a
	reply should  be addressed  in the absence of any other information.

<end quote> 
3. As I have said already, since the demultiplexer (as a data plane
   enity) is used to identify the DESTINATION (e.g., the PE-to-CE
   direction of an attachment circuit of a PW end point), placing
   it in the SOURCE port contradicts the common sense (at least,
   mine).
4. While upstream allocation of the demultiplexer is probably
   possible, it is both more complicated and only rarely justified
   (the only example so far has been the FTP "passive" mode).
   In the PWE3 case I do not see any justification for it.

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 22 Jun 2004 14:25:35 +0300

Sasha, 

The text got so crowded that I wiped everything
and we can start with a clean slate.

[Sasha] I have probably missed something. 
Until now I have been under impression that a PW IWF handles 
only PW traffic and nothing else?

There may be cases where the same IP address
that is connected to the PW also handles other IP traffic.

This is certainly useful for TFTP for SW upgrades,
but I do not see precluding the same box being
a http server or whatever.

These are NOT PWE applications, and it is no complication
to talk about non-PWE applications in this context;
it is definitely something that we need to consider.

[Sasha] Since we allocate the PW demultiplexers downstream in MPLS and
L2TPv3,  
a very strong justification is, IMO, required to do things differently
over UDP. 

MPLS uses downstream allocation because it can have a common label
space for all incoming connection-oriented interfaces,
in which case only the downstream LSR knows which labels are in use. 

In the UDP/IP case we have IP addresses as well to differentiate, 
and so the defining requirement disappears.

Without this requirement, it seems strange to force control traffic 
to travel in the opposite direction from the data.

[Sasha] As I have said already, since the demultiplexer (as a data plane
enity) 
is used to identify the DESTINATION (e.g., the PE-to-CE direction of 
an attachment circuit of a PW end point), placing it in the SOURCE port 
contradicts the common sense (at least, mine).

As I have already said, the demux identifies a connection
between a source and a destination, and so either interpretation is
possible.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 22 Jun 2004 15:18:10 +0200

Yaakov and all,
Please see a few more answers inline below.

With best regards,
                                   Sasha Vainshtein

> Sent: Tuesday, June 22, 2004 1:26 PM
> Cc: Thomas Narten; Danny McPherson; [email-masked]; Scott 
> Bradner; Peterson,Jon
[Sasha] OK.
> it is definitely something that we need to consider.
[Sasha] IMHO this only means that ALL the local UDP ports must be 
allocated from a single (per local IP address of the device) local pool.
> and so the defining requirement disappears.
[Sasha] Please note that L2TP (both v2 and v3) also uses downstream
allocation of demultiplexers. 
> to travel in the opposite direction from the data.
... snipped ...

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 24 Jun 2004 12:55:45 +0300

> It  seems to me that the current PWE3 control protocol ( LDP 
> ) uses IP as transport , and could easily advertise UDP port 
> numbers. Then this method would fit in quite easily. ( with 
> the exception that IP firewalls would now have to understand 
> LDP ... ) I think this is probably the easiest scheme to use.

I agree.

Please note that we might want to have a label range
specification during the initialization phase,
since UDP port numbers are only 16 bits.

> How about single sided signaling FEC 129 ?  There is a client 
> server in that case ...  This method should work fine with 
> the FEC 129 model as well a s FEC 128. But this is really a 
> special case of #3 above where the remote port is always the 
> same one. I think that we would probably use too many well 
> known ports with this method.

I assume you mean signaling via LDP.
If this is adopted, then we can decide whether generalized PWid is
required.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Sun, 27 Jun 2004 08:39:37 +0300

> I would like  to understand why the  requirements are not met 
> by  one of the following methods: 
> 
> a. L2TPv3
> 
> b. MPLS-in-GRE or even MPLS-in-IP

No one said that these methods DON'T solve the problem,
it is just that the PWE charter states that there are potentially
three PSNs over which PWs can run, namely pure IP, L2TPv3, and MPLS.
Most of PWE work to date has focused on L2TP and MPLS,
so the time has come to specify what we meant when we said "IP".

At least in the TDM arena, methods based on UDP port numbers
with no additional overhead
have been widely deployed for over 6 years now, 
and seem to work well.
We may decide now that this is not a good idea,
but we would need to explain why not.

Y(J)S

---

From: Eric Rosen <[email-masked]>
Date: Mon, 28 Jun 2004 10:24:30 -0400

Eric> I would like  to understand why the  requirements are not met 
Eric> by  one of the following methods: 
Eric> 
Eric> a. L2TPv3
Eric> 
Eric> b. MPLS-in-GRE or even MPLS-in-IP

Yaakov> No one said that these methods DON'T solve the problem,

Good.

Yaakov> it is just that the PWE charter states that there are potentially
Yaakov> three PSNs over which PWs can run, namely pure IP, L2TPv3, and MPLS.
Yaakov> Most of PWE work to date has focused on L2TP and MPLS,
Yaakov> so the time has come to specify what we meant when we said "IP". 

I think  this interpretation is  far-fetched.  L2TP and  MPLS_in-IP/GRE both
apply to the case where the PSN is  IP, and the only other kind of PSN being
considered is  MPLS.  So I don't think  the charter requires us  to pursue a
UDP-based solution. 

Yaakov> At least in the TDM arena, methods based on UDP port numbers with no
Yaakov> additional overhead have been widely deployed for over 6 years now,

So, now  I see  why you  want to pursue  this!  Are  you submitting  a draft
specifying the signaling procedures?