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
