Implementing SIP under BSD

[Christian Huitema <[e-mail]>]

As mentioned in a previous message, we are now implementing SIP in
the BSD "socket" environment. We took the "IP multicast" release as a
starting point, and are now proceeding.

Indeed, implementing a spec is a good way to understand it, and we now
have a first batch of lessons and questions. Let's start from the
simple ones, and proceed to the more dubious cases.

1) Good news. I found a reason why the order of SRC and DST address
should remain the way it is in the SIP spec: because it makes "routing
by LSR encapsulation" marginally faster. Suppose you have to
encapsulate a packet:
		<control, SRC, DST><data>
That can easily be done in preparing the LSR header in an auxiliary
mbuf:
	<updated-control, SRC, new-dest><lsr-control>
then peeling 16 bytes out of the previous mbuf, chaining and
resubmiting.

2) Another piece of good news. Inserting SIP at the level 2 requires
exactly the following modification in "ip_input.c":
 
/* When IP v4 is present, as we want to keep as much code unchanged as 
 * possible, we will only add in the "ip" code, just before the test of 
 * the header length, the linese:
 */
   if (ip->ip_v == 6){
      sip_process(m, 3, (void *) ifp);
      goto next;
   }

To reuse the IPv4 driver, one only has to be careful and provide the
32 bit address of the next hop to the interface -- no modification
needed.

3) Moderately good news. There are many local addresses that doing
a linear search does not make much sense. It is easier to maintain a
single routing table, and to consider "local delivery" as just one
particular destination. That can be accelarated by mean of caches, etc.
In fact, we maintain four particular classes of interfaces: local
delivery, downgrade to IP (IPAE), route over IP and route using LSR.
Otherwise, vanilla IP interfaces can be used.

4) By the way, what is the value IPPROTO_SIP? And what are the payload
types for SIP_ICMP(1?), SIP_IGMP (2?), SIP_REASSEMBLY and SIP_LSR?

5) Implementing multicast at the SIP level is not a big problem.
However, we end up with two multipoint routers in the same machine
(IPv4 and SIP), and that poses a set of problems as these two routers
use incompatible versions of IGMP. I propose the following conventions:

	a) If the C bit is set, the IPv4 router is responsible for
	local delivery.
	b) Only multicast addresses with the C bit set can be locally
	downgraded.
	c) If a SIP host receives an IGMP Host Membership Report
	message  with a "reserved" word set to a non null value, then
	this is interpreted as a membership to an IPv4 class D address.
	d) All class D addresses can be converted to SIP by prepending
	a constant prefix:

 |1|   7   |  4 |  4 |  16 bits   |             32 bits            |
 +-+-------+----+----+------------+--------------------------------+
 |1|1111111|0000|1110|     0      |        class D address         |
 +-+-------+----+----+---------------------------------------------+


6) We dont find a compelling need to use a different SIP address for
each physical interface -- we could certainly do with one address per
system. The only reasons I see are:
	a) make routing towards multihomed hosts more precise,
	b) be compatible with IP for reusing ARP.
On the other hand, it makes mobility harder (need to have a temporary
address within the new attachment's space), and is IMHO somewhat at
odds with geographical addressing. On the other hand, actually
defining several address for a station and selecting prefered source
addresses depending of interface is not a real big problem..

7) OH yes. IPAE. The whole idea of IPAE is to prepend to the 32 bits
IPv4 address a 32 bits "routing directive" that would enable
hierarchical routing. Fine. But how is the IPAE driver going to obtain
the magical 32 bits "routing directive"? I could think of three
alternatives:

	a) ARP like. Upon reception of a packet, check a local cache
	of IP addresses for obtaining the corresponding SIP address.
	If absent in cache, send a query message, e.g. to a name server
	resolver that would look for an "AA" record associated to
	x.y.z.t.in-addr.arpa. On reception of the response, update the
	cache and forward the packet.

	b) Routing table. Consider that IPv4 will only pass to the SIP
	interface packets that are associated with a "next hop"
	address, e.g. through smtg like
		route add destination gateway
	where gateway is in a space "reserved for sip", e.g. some not
	yet used class A, or class B network. Or a CIDR address.

	c) ICMP. Send the first packet using some random mapping, then
	receive an ICMP "redirect". This merely reports the problem to
	a "default router" somewhere, and is in fact probably
	analoguous to the "name server" solution. One should note that
	this will not work for computing the network source.

I must say that I do not believe too much in the "routing table"
approach. We will probably initially implement a variant of (c). For
elegance and coherency, we may have to define a new ICMP message.

We expect to release an alpha version by mid january. That code will
be in the public domain. Anybody interested in prealpha delivery (i.e.
interested in developping parts of it) should contact me.

Christian Huitema