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

From: Shidan <[email-masked]>
Date: Sat, 17 Oct 2009 17:00:36 -0400

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

---

From: Shidan <[email-masked]>
Date: Sat, 17 Oct 2009 17:36:44 -0400

Sorry for the typo, I meant involve the WG responsible for SIGCOMP not the
conference.
---
Shidan Gouran

On Sat, Oct 17, 2009 at 5:00 PM, Shidan <[email-masked]> wrote:

>    - With regards to the general 6LoWAPP problem statement, I suggest the
>    WG adopt the use cases of OpenHan as criteria for evaluating any application
>    - 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
>    - 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.
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 18 Oct 2009 00:07:04 +0200

On Oct 17, 2009, at 23:36, Shidan wrote:

> SIGCOMP

SigComp (RFC 3320) is essentially a virtual machine for shipping  
decompression code to a peer.
Constrained nodes (as in 8 MHz 10K RAM) won't be able to run such a  
virtual machine, I'd say.

Actually, the whole idea of using complex encodings full of encoding  
alternatives (the fact that any of these are text-based is secondary  
to that) and then compressing them with a data compression algorithm  
is something that may be appropriate out of backwards compatibility,  
but not for a new design that emphasizes minimal code complexity.

Apart from this little nit (sorry, I was involved in RFC 3320), I'm  
looking forward to your draft.

BTW, right now the score is:

16 Oct 2009  draft-martocci-6lowapp-building-applications
16 Oct 2009  draft-shelby-6lowapp-encoding
14 Oct 2009  draft-schmitt-6lowapp-ipfix-ws
11 Sep 2009  draft-frank-6lowapp-chopan
13 Jul 2009  draft-bormann-6lowpan-6lowapp-problem

48 more hours to go...

Gruesse, Carsten

---

From: Shidan <[email-masked]>
Date: Sun, 18 Oct 2009 22:49:05 -0400

Thanks for the info Carsten, that makes sense.
We have submitted the motivational I-D for SIP as a 6LoWAPP protocol and it
can be found here:
http://www.ietf.org/id/draft-roychowdhury-6lowappsip-00.txt

<http://www.ietf.org/id/draft-roychowdhury-6lowappsip-00.txt>---
Shidan Gouran

On Sat, Oct 17, 2009 at 6:07 PM, Carsten Bormann <[email-masked]> wrote:

> Constrained nodes (as in 8 MHz 10K RAM) won't be able to run such a virtual
> machine, I'd say.
>
> alternatives (the fact that any of these are text-based is secondary to
> that) and then compressing them with a data compression algorithm is
> something that may be appropriate out of backwards compatibility, but not
> for a new design that emphasizes minimal code complexity.
>
> Apart from this little nit (sorry, I was involved in RFC 3320), I'm looking
> forward to your draft.
>

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 19 Oct 2009 10:28:55 -0400

From: Carsten Bormann <[email-masked]>
   Date: Sun, 18 Oct 2009 00:07:04 +0200

I agree with you.

Would you say that this description includes using XML with
EXI for compression?  EXI in schema-informed mode is not
exactly a data compression algorithm, but it isn't entirely
unlike one either.
                                 -Richard Kelsey