Dear PCErs,

During some interoperability tests, we found an issue with the PCEP 
protocol and RFC5440 which manifests when using specific (although 
common) operating systems and we would appreciate your feedback to 
evaluate our options.

RFC5440 states (section 5)  that PCEP operates over TCP using a 
registered TCP port (4189) and all PCEP messages MUST be sent using the 
registered TCP port for the source and destination TCP port. Moreover, 
only one active connection between to given hosts/peers may be active at 
a time.
Although this is conceptually valid, I fail to see the reasoning behind 
the first restriction, and I see the second one as a direct consequence 
of the first.

The use case is as follows: assume a PCE host, with a PCEid address (in 
line with the "NodeID" "RouterID", or Loopback address, lo:0, defined as 
an IP address such that it is valid provided there is some connectivity, 
etc.)
The PCE creates a socket which is listening for TCP/PCEP connections 
("binding" to either the INADDR_ANY, 0.0.0.0 or restrict it to such 
PCEid address, but in any case to the port 4189).  At the same time it 
should also be able to have/initiate persistent TCP/PCEP connections to 
other peers (say, as a client), ideally keeping the same loopback 
address (NodeID) as the source IP address, while forcing the source port 
to what the RFC requires.

The main problem is that using that single PCEid address, it is not 
possible, or at least not possible in a portable way, to "bind" or 
associate several sockets to the same (local address, local port) pair. 
Of course,it should be theoretically possible, given that TCP 
connections would still be different considering the tuple (srcaddr, 
4189, dstaddr, 4189) but in practice it isn't:

After the first "listening" socket, the PCE would, for each persistent 
peer,
(i) create a socket SOCK_STREAM,
(ii) bind it to nodeid/4189 and
(iii) connect to remote peer/4189.

The first bind system call may fail depending on how the server is 
listening for connections (even worse, it some systems the bind system 
call may hijack the listening socket) or the second peer bind would fail 
since it would try to  bind to the same local address/port. For example, 
the GNU/Linux man page for bind is clear: ip(7) "Only one IP socket may 
be bound to any given local (address, port) pair". In technical terms, 
PCEP requires duplicate bindings at the socket level. Some systems may 
implement SO_REUSEPORT (1) socket option which could allow that, 
although it main use is to bind multicast addresses, or enable some sort 
of load sharing amongst TCP listeners in several threads. Unfortunately 
this is not implemented for example in GNU/Linux, although some 
non-official patches have been proposed (2). It is not clear whether it 
will be integrated or not.

Our workarounds seem to be either: allow clients to bind to port 0 
(ephemeral port) and use such allocated (dynamic) port (which is not 
compliant with RFC), or set IP aliases so each bind uses a different 
local address (we may need as many local addresses as peers, and some 
"mapping" to uniquely identify a PCE).

For what is worth, in my humble opinion the standard RFC is too strict 
requiring that all (client) sockets bind to port 4189


In summary we would appreciate your views on this:

a) what's the reasoning to force clients to bind on 4189 rather than say 
like in http? -- sometimes it is argued that this simplifies management 
such as firewall rules, etc. but I do not agree --

b) why limit to a single PCEP connection between two peers (other than a 
direct consequence of a) ), rather than allowing several parallel 
connections, provided that hosts use a single IP address and thus they 
can be identified?

c) As potential PCE implementers, have you encountered this issue, did 
you work around it? Are we missing something obvious?



Any feedback is appreciated

Best regards,

Ramon


(1) http://wiki.treck.com/Socket_Options

(1) http://marc.info/?l=linux-netdev&m=127165882728524&w=2 
<http://marc.info/?l=linux-netdev&m=127165882728524&w=2>

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01