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.
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
