Subject: Re: [Anima] Proposed change to GRASP

From: Sheng Jiang <[email-masked]>
Date: Tue, 3 May 2016 02:02:37 +0000

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-masked]] 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-masked]
>https://www.ietf.org/mailman/listinfo/anima

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 2 May 2016 22:39:34 -0400

Sheng, unless I have misunderstood Brian rather thoroughly, the port
numbers in the proposal are TCP or UDP port numbers.  They are not some
other number / name space.  The point is to be able to leverage the 
kernel demuxing which relies on those port numbers to get traffic to 
multiple user space ASAs.

Yours,
Joel

On 5/2/16 10:02 PM, Sheng Jiang wrote:
> 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-masked]] 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
>> 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:
>>
>> 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.
>>
>> 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-masked] https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________ Anima mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/anima
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 3 May 2016 03:11:16 +0000

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

> From: Anima [mailto:[email-masked]] 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
> 
> 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.
> 
> >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
> >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.
> >
> >since dynamic ports are assigned for a specific socket and protocol.
> >
> accordingly.
> port-number
> >= 0..65535
> >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:
> >
> >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.
> >

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 3 May 2016 03:56:03 +0000

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 May 2016 16:05:00 +1200

Thanks, Bing and Joel.

Of course if the WG agrees to this change, we will have to explain
it carefully in the next version of the draft, although some of
the material perhaps belongs in the Reference Model.

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.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 May 2016 16:09:40 +1200

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

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 3 May 2016 09:14:37 +0000

> Sent: 03 May 2016 04:03
> To: Brian E Carpenter <[email-masked]>; Anima WG
> <[email-masked]>
[...]
> or there could be other mechanism to manage it so that the uniqueness

We need some "common point" to start with. When a node comes up and hasn't established any AN neighborship, it needs to know which port number to use. 

For the bootstrap case, intuitively, that ASA port number should be well known. However, that doesn't help with other ASAs. 
Maybe there should be a common port for general negotiation, from which we then derive the other port numbers dynamically? 

The way I see it right now, on every node there will be a "management ASA", or "meta ASA", which must be on every node, and is used for controlling the other ASAs. We could define a port number for that with IANA, and have all other ports negotiated dynamically. Now Stuart would probably say we should use mDNS for such a purpose...  

Michael

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 3 May 2016 09:50:11 +0000

>in one machine, and they can negotiate with each other quite nicely

This design would help to structure the ASAs within an Autonomic Node. Collaboration function/ASA could be easier to communication among ASAs.

Sheng

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

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 3 May 2016 09:57:34 +0000

>We need some "common point" to start with. When a node comes up and
>hasn't established any AN neighborship, it needs to know which port number
>to use.
>
>For the bootstrap case, intuitively, that ASA port number should be well
>known. However, that doesn't help with other ASAs.
>Maybe there should be a common port for general negotiation, from which
>we then derive the other port numbers dynamically?
>
>The way I see it right now, on every node there will be a "management ASA",
>or "meta ASA", which must be on every node, and is used for controlling the
>other ASAs. We could define a port number for that with IANA, and have all
>other ports negotiated dynamically. Now Stuart would probably say we
>should use mDNS for such a purpose...

I agree the need for a management ASA. But I am not sure it needs a fixed port number. Dynamic port number could work well for management ASA, too. The "discovery ASA", if there will be one, needs a fixed port number. However, it could just use the GRASP port number, I guess. Or you mean a management ASA includes discovery function to discover ASAs on other node?

Sheng

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 May 2016 08:51:22 -0400

Michael Behringer (mbehring) <[email-masked]> wrote:
    > hasn't established any AN neighborship, it needs to know which port
    > number to use.

I thought that the discovery process for the ASAs ran on the well-known GRASP
port.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 May 2016 07:52:08 +1200

> I thought that the discovery process for the ASAs ran on the well-known GRASP

Yes. The dynamic port only comes in when the ASA starts to listen for
specific requests for (unicast) synchronization or negotiation.

   Brian