Hi all,
 Thanks a lot to everyone who commented, both on list and in private, on this 
protocol number allocation request. They were extremely valuable. Given the new 
information that has come up regarding the potential for improvements in the 
Linux kernel for better UDP performance, I think allocating a protocol number 
for this is premature. I have discussed this with the submitter and he agrees 
with my assessment. I will share my conclusion with the IESG and send a 
recommendation to IANA to close this request without allocating a protocol 


On Mar 17, 2020, at 6:34 PM, Suresh Krishnan 
<sur...@kaloom.com<mailto:sur...@kaloom.com>> wrote:

Hi all,
  IANA received an IP protocol number allocation request from Jon Maloy 
<jma...@redhat.com<mailto:jma...@redhat.com>> for the Transparent Inter Process 
Communication (TIPC) protocol. I picked up this request as Internet AD as the 
registration procedure requires IESG Approval. I had provided the information 
below to the IESG and discussed this with a favorable view of this request. I 
am recommending allocation of an IP protocol number for this. If you have any 
concerns that you think I might have overlooked, please let me know by end of 
day March 24 2020.

After several round trips of back and forth probing I had collected the 
following information regarding the protocol number request for TIPC. There 
were two main questions I had for him:

* Q1: Why did they want an IP protocol number?
* Q2: Is the protocol implemented and deployed widely?

Q1: Why did they want an IP protocol number?

There are two main reasons why they want to reserve an IP protocol number:

1)  Performance
They are currently working on adding GSO support to TIPC, including a TSO-like 
"full-size buffer pass-thru" though virtio and the host OS tap interface. They 
have experimentally implemented GSO across UDP tunnels, but performance is not 
good because of the way the tunnel GSO is implemented, and there is no 
'pass-thru' support for this in Linux. They have even done the same at the pure 
L2 level, but L2 transport is sometimes not accepted by the cloud maintainers 
or the telco operators, and hence they need an alternative. The best 
alternative, both from a performance and acceptability viewpoint would be to 
establish TIPC as a full-fledged IP protocol, apart from the traditional L2 
bearer many users are still using.

2) Currently TIPC has two user address types:

struct tipc_service_addr{
    uint32_t type;
    uint32_t instance;
    uint32_t node;
struct tipc_service_addr{
    uint32_t port;
    uint32_t node;

They want to complement this  with a new API where we have a unified address 
struct tipc_addr{
   u8 type[16];
   u8 instance[16];
   u8 node[16];

This would give a 128-bit value range for both 'type', 'instance' and 'node', 
and opens up for new opportunities:
- Users will never need to coordinate 'type' values since there will no risk of 
- Users can put whatever they want into the fields, e.g., an IPv6 address, a 
Kubernetes or Docker container id, a LUKS disk UUID or just a plain string.
For the 'node' id this has already been implemented and released, but it is not 
reflected in the API yet.

For the API extension they need a new IPPROTO_TIPC socket type which can be 
registered and instantiated independently from the traditional AF_TIPC socket 

You can find more info about this at http://tipc.io<http://tipc.io/>

Q2: Is the protocol implemented and deployed widely?

The requester provided the following information when I asked about who was 
currently using TIPC (pretty much about adoption and deployment):

I can give you a list of current or recently active code contributors and 
companies/people who have been asking for support:

For natural reasons I don't know any details about them, I can only name 
persons I have seen contributing to netdev or being active on our mailing 
lists. Huawei people sometimes use gmail addresses when posting questions and 
patches, so there are more persons than I have listed here.
Dmitry Kolmakov 
Ji Qin <jiqin...@huawei.com<mailto:jiqin...@huawei.com>>
Wei Yongjun <weiyongj...@huawei.com<mailto:weiyongj...@huawei.com>>
Yue Haibing <yuehaib...@huawei.com<mailto:yuehaib...@huawei.com>>
Junwei Hu <hujunw...@huawei.com<mailto:hujunw...@huawei.com>>
Jie Liu <liujie...@huawei.com<mailto:liujie...@huawei.com>>
Qiang Ning <ningqia...@huawei.com<mailto:ningqia...@huawei.com>>
Zhiqiang Liu <liuzhiqian...@huawei.com<mailto:liuzhiqian...@huawei.com>>
Miaohe Lin <linmia...@huawei.com<mailto:linmia...@huawei.com>>
Wang Wang <wangwa...@huawei.com<mailto:wangwa...@huawei.com>>
Kang Zhou <zhouka...@huawei.com<mailto:zhouka...@huawei.com>>
Suanming Mou <mousuanm...@huawei.com<mailto:mousuanm...@huawei.com>>

Hu Junwei is the one I see most active at the moment.

Tommi Rantala <tommi.t.rant...@nokia.com<mailto:tommi.t.rant...@nokia.com>>

Amar Nv <amar...@in..verizon.com<mailto:amar...@in.verizon.com>>
Jayaraj Wilson, 

Hewlett Packard Enterprise:

Ying Xue <ying....@windriver.com<mailto:ying....@windriver.com>>
He is my co-maintainer at netdev ans sourcefoge.
Windriver has several products in the field based on TIPC, e.g. control system 
for Sikorsky helicopters.

Christophe JAILLET 

The person contacting me to have TIPC integrated and maintained in RHEL-8.0 was
Sirius Rayner-Karlsson <akarls...@redhat.com<mailto:akarls...@redhat.com>>
He motivated it with a request from "a telco vendor", but I don't know which 
Hence, TIPC is now integrated in and officially supported from RHEL 8.1

Mikolaj K. Chojnacki 
Krzysztof Rybak <krzysztof.ry...@pl.abb.com<mailto:krzysztof.ry...@pl.abb.com>>

All (dozens of) applications based on the TSP and Core Middleware/Components 
Based Architecture (CMW/CBA) platforms is per definition based on TIPC. They 
have not yet started to use TIPC on their Kubernetes based ADP platform, but 
there is work ongoing on this.

I also see numerous other people being active, from small (I believe) 
companies, universities and private contributors. E.g.,
Innovsys Inc  http://www.innovsys.com/innovsys/
Allied Telesis https://www.alliedtelesis.com/
Telaverge Communications http://www.telaverge.com/
Ivan Serdyuk 
<local.tourist.k...@gmail.com<mailto:local.tourist.k...@gmail.com>> (seems to 
be responsible for the ZeroMQ port of TIPC)
John Hopkins University / Fast LTA, Munich 
Just to mention a few...

TIPC is currently maintained jointly by Ericsson, WindRiver, Redhat, and the 
Australian consulting company DEK Technologies https://www.dektech.com.au/


Int-area mailing list

Int-area mailing list

Reply via email to