Hi Sheng,
I guess pure text is not easy to clearly describe the logic. Brian had noticed
the issue of how to explain it to the WG when we had private discussion.
So let me quote Toerless' drawing. Maybe it's more easy to be understood.
Before quoting the drawings, let me make a short explanation:
1. As Joel replied, the port numbers are not "name space" or "identifier" of
the ASAs, they are used in TCP/UDP when communicate with the ASAs.
2. Although the port numbers are defined as "port-number = 0..65535" in the
locater option, in practice, as we know they only have a limited range to avoid
collision with other applications. For IANA registration, I guess no need for
ASAs? Or maybe only the meta-ASAs (such as bootstrapping) need to be registered?
***Now the drawings***
If we allocate ports for each ASA, then the OS kernel can de-multiplex ASAs by
ports, thus directly interact with the ASAs through syscall (via the userland
GRASP Lib ). In this case, the basic GRASP Daemon/Engine could be implemented
in the OS kernel space, it handles generic GRASP messages (not toward a
specific ASA) such as Discovery, Flood etc.
|<----- one binaery ------->
per ASA
__________ __________ ________
| Userland | | Userland | | |
| ASA |---- | GRASP Lib|--- syscall --- | Kernel |
| _________| ^ |__________| /|________|
| ------/
API _____________ /
| GRASP |
| Daemon |
|_____________|
Without ASA ports, there will be no way for the OS kernel to do the
de-multiplexing. Thus, the GRASP Daemon needs to be in the userland for
de-multiplexing (de-multiplex by Session ID). Then, IPC will be involved
between ASA and GRASP daemon, as the figure shows below. And IPC is something
we'd better not get involved in, to avoid unnecessary additional
standardization work.
|<----- one binaery ------->
per ASA
__________ __________ ______________ ________
| Userland | | Userland | | Userland | | |
| ASA |----| GRASP Lib|---IPC -- | GRASP daemon | --- | Kernel |
| _________| ^ |__________| |______________| |________|
|
API
Best regards,
Bing
> -----Original Message-----
> From: Anima [mailto:[email protected]] On Behalf Of Sheng Jiang
> Sent: Tuesday, May 03, 2016 10:03 AM
> To: Brian E Carpenter; Anima WG
> Subject: Re: [Anima] Proposed change to GRASP
>
> 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
