Re: SIP API spec

[Christian Huitema <[e-mail]>]

Bob,

In your spec, you mention a "SIP_FLOWID" option. When doing our
implementation, we do indeed feel the need for such an option, but also for at
least three other options:

1- An option to set the "Maximum number of hops" field in the header,
analoguous to the IP_MULTICAST_TTL option that was defined for multicast IP.

2- An option to set a "path MTU". That can be useful for datagram sockets which
have to use the reassembly protocol; it instructs "sip_output()" to send a
sequence of segments instead of a single datagram.

3- An option to set a "source route", using the loose source route protocol.

In fact, the "final state" of the SIP interface (when IP is removed) should
authorize the programmer to set up all required functions, including those
which are "multicast specific" -- multicast loop, add membership, drop
membership, multicast interface.

Note that the isolation of one specific "SIP_FLOWID" option is contradictory
with the current architecture where:


     A single socket option, IP_OPTIONS, is supported at  the  IP
     level.   This socket option may be used to set IP options to
     be included in each outgoing datagram.   IP  options  to  be
     sent  are set with setsockopt (see getsockopt(2)).  The get-
     sockopt(2) call returns the IP options set in the last  set-
     sockopt  call.  IP options on received datagrams are visible
     to user programs only using raw IP sockets.  The  format  of
     IP  options given in setsockopt matches those defined in the
     IP specification with one exception: the list  of  addresses
     for  the  source  routing options must include the first-hop
     gateway at the beginning  of  the  list  of  gateways.   The
     first-hop  gateway address will be extracted from the option
     list and the  size  adjusted  accordingly  before  use.   IP
     options  may  be  used  with any socket type in the Internet
     family.

So, we clearly have a design choice here. Either individual socket options for
Flow-id, TTL, MTU and LSR, in the "multicast" tradition, or one global
SIP_OPTIONS, like the old IP.

As far as a new name for "gethostbyname" is needed, we had chosen
"sip_name2addr" in our "bind" code -- which we ought to adapt to the new
interface specification!

Christian Huitema