On 03/05/2016 15:56, Sheng Jiang wrote:
> Oops... Thanks the explanation from Bing and Joel. This design can certainly
> help the efficiency of ASA communication. However, since we are going to use
> a TCP/UDP port for each ASA, this actually brings me another question: how
> many ASA may we expect in total? This may not be essential for this design,
> but it is a necessary discussion point regarding to the granularity of ASA.
Right, there is no design limit on ASAs or objectives, but there is probably
a practical limit in any implementation. I have no idea what the limits should
be.
Brian
>
> Regards,
>
> Sheng
>
>> -----Original Message-----
>> From: Liubing (Leo)
>> Sent: Tuesday, May 03, 2016 11:11 AM
>> To: Sheng Jiang; Brian E Carpenter; Anima WG
>> Subject: RE: [Anima] Proposed change to GRASP
>>
>> 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
