Subject: [Anima-signaling] Take 2: Draft message on proposed change to GRASP

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Apr 2016 11:52:38 +1200

Hi,

Design team, and Joel,

Updated following the feedback received and trial implementation. Please
let me know if OK; I would like to send this to the WG tomorrow.

Short version:

We propose that when an ASA listens for negotiation or synchronization
requests, it should do so on its own transport port number rather than sharing
the generic GRASP port number as currently defined. The consequence for the
protocol is that discovery responses must include a complete transport address
(locator+protocol+port) instead of just the locator.

Long version:

We want ASAs to run as separate modules in user address space, as applications,
rather than being bundled with the GRASP engine in kernel space. To achieve this
with all ASAs listening on the same port number would require quite complicated
inter-process communication between the GRASP kernel and the indvidual ASAs.
The details of this would be different in every operating system. If we
allow each ASA to have its own port this can be avoided, and each ASA can have
its own copy of the GRASP API library if required. This will make the systems
engineering of portable ASAs much easier, and will make the adaptation of
the GRASP API library and the GRASP kernel to various operating systems easier
too.

In practice we need to indicate the protocol (TCP or UDP) as well, since
dynamic ports are assigned for a specific socket and protocol.

We propose to redefine the locator returned by GRASP discovery accordingly. For
the IPv6 case that would give the following CDDL:

locator-option /= [O_IPv6_LOCATOR, ipv6-address, transport-proto, port-number]
ipv6-address = bytes .size 16
transport-proto = IPPROTO_TCP / IPPROTO_UDP
IPPROTO_TCP = 6
IPPROTO_UDP = 17
port-number = 0..65535

We did consider making this optional, but that would raise interoperability
issues. If an implementation does choose to use the GRASP_LISTEN_PORT
for all ASAs, that could simply be returned as the port-number.

Implementation note:

When it starts up, an ASA will obtain an ephemeral port number for each
transport protocol that it supports, and that will be used in discovery
responses.

Comments?

Note: Toerless Eckert brought up this problem and outlined the proposed
solution.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 Apr 2016 19:56:36 -0400

The proposal looks fine.  I might adjust the "implementation" text 
slightly.  If someone implements multiple ASAs in a common address 
space, they can share the UDP port and demux using other fields.  This 
change allows them to be in separate spaces, without requiring it.

What I am commenting on the text "When it starts up, an ASA will ...". 
I think "will" is too strong.

Yours,
Joel