>I actually believe that this change makes GRASP a more robust >protocol; for example I can now run two copies of the Python prototype >in one machine, and they can negotiate with each other quite nicely >using a dynamic port.
This design would help to structure the ASAs within an Autonomic Node. Collaboration function/ASA could be easier to communication among ASAs. Sheng >Regards > Brian > > >On 03/05/2016 15:11, Liubing (Leo) wrote: >> 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
