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

From: Luca Martini <[email-masked]>
Date: Mon, 21 Jun 2004 17:02:29 -0600

Comments in line.
Luca

Stewart Bryant wrote:

> 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).
>
Telnet and  TCP port numbers  ???  Telnet aways goes to port 23 and uses 
the source port for connection demultiplexing.
Since the PW must have a control protocol somewhere this method could be 
used.

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

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

Luca

> 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.
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 25 Jun 2004 10:49:02 -0400

> As you can see we been asked recommend the correct method of multiplexing

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