[6lowapp] SIP and 6LoWPAN & Some General Suggestions

[Shidan <[e-mail]>]

I don't think I have sufficient time to write anything other than a very
high level motivation I-D on the merits of SIP, as defined by RFC 3261 &
3625, for ubiquitos computing and building automation. I will start this
tonight and submit it sometime on Monday for sure. *
*
Here are some recommendations I have for this working group in general:
*
*

   - With regards to the general 6LoWAPP problem statement, I suggest the WG
   adopt the use cases of OpenHan as criteria for evaluating any application
   protocol suitable for the 6LowAPP working group. Their use cases are the
   most extensive that I have seen.


   - I think before we consider any binary encoding, we must consider how
   binary compression of application level protocols is done in current
   bandwidth constrained communications networks like GSM. I certainly think we
   would benefit from learning/involving SIGCOMM in making this decision. Power
   contraint seems to me to be a much more unique issue this WG has to deal
   with than bandwidth constraint.

Now going back to the concepts of a specific binary encoding for SIP as a
base protocol here are some ideas:

   - Any method for binary compression of HTTP would work seamlessly with
   SIP, so for example everything in section 2 of the Chopan I-D could be
   applied to all SIP messages and follow the same request/response
   model. Also, referring to the Chopan I-D, SIP already addresses sections  3,
   4 and a significant portion of 5. For these purposes, no new extensions or
   modifications to SIP need to be defined and it really becomes just a matter
   of defining the message encoding. One area that needs to be addressed with
   SIP is sleeping nodes and this is something we definitely need to think
   about more.


   - In addition, any type of binary encoding of XML, "ZigBee like" data
   representations or anything else that can or will be transported by a binary
   HTTP protocol, will also work with SIP as the mechanism is identical in
   both.


   - For security, relying solely on 802.15.4's AES is, in my opinion, not a
   good idea. for example both SIP and, as Schmidt et al outlined, IPFIX
   requires TLS and support of something like Tiny 3-TLS would also work well
   for us*.*


   - As I mentioned before, SIP as a base protocol can make gatewaying with
   XMPP and some "real-time web" REST based protocols such as FeedSync or ATOM
   Pub + PubHubSub, much more efficient. If we are defining all of this using
   HTTP you are going to be defining heavier payloads than needed. Describing
   this will take more time than I have for the motivational I-D, this is
   something in the coming months I would be happy to expand on fully if this
   WG considers it worthwhile.


   - As much as possible, the 6LowPAN framework should be abstracted to
   unify and fit commonalities in SNMP, SIP and "real time web" protocols. So
   the way we define eventing, for example, should be done in a way that lends
   to simple interfacing with systems that use any of the above.

* *I would appreciate any comments or suggestions to this note before I
start writing the motivational I-D later tonight EST.
*
*
Shidan Gouran