Sheng, unless I have misunderstood Brian rather thoroughly, the port
numbers in the proposal are TCP or UDP port numbers. They are not some
other number / name space. The point is to be able to leverage the
kernel demuxing which relies on those port numbers to get traffic to
multiple user space ASAs.
Yours,
Joel
On 5/2/16 10:02 PM, Sheng Jiang wrote:
Hi, Brian & Signaling design team,
Thanks for your hard work and the latest design. It looks useful to
quickly classify or identify the ASA in the receiver side. However,
may I proposed the rename "GRASP port number" to be "ASA type
number", or something else without "port number"? The introduction is
easily to be misread. Actually, you have created a new namespace. The
word "transport port number" is misleading. We should have a more
explicit name.
One question: does this new namespace also need to be managed by IANA
or there could be other mechanism to manage it so that the uniqueness
could be guaranteed?
Best regards,
Sheng
-----Original Message----- From: Anima
[mailto:[email protected]] On Behalf Of Brian E Carpenter
Sent: Saturday, April 30, 2016 4:26 AM To: Anima WG Subject:
[Anima] Proposed change to GRASP
Hi,
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 be able 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 each 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:
If someone implements multiple ASAs in a common address space, they
can share a unicast port and demultiplex incoming messages using
other fields (the Session ID and the Objective name). This change
allows them to be in separate spaces, without requiring it.
When it starts up, an ASA can obtain an ephemeral port number for
each transport protocol that it supports, and that will be used in
discovery responses.
This change has already been tested out in the prototype Python
code.
Comments?
Note: Toerless Eckert brought up this problem and outlined the
proposed solution. Joel Halpern made very helpful comments.
Brian + co-authors
_______________________________________________ Anima mailing list
[email protected] https://www.ietf.org/mailman/listinfo/anima
_______________________________________________ Anima mailing list
[email protected] https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
