Subject: [6lowpan] Working Group Charter

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 18 Apr 2006 17:54:28 -0500 (CDT)

I started to think about the working group charter, (a topic that appears
to have drifted off into the ether since the IETF meeting).

I suggest replacing the first three paragraphs of the current working
group charter, (i.e., everything down to "The required work includes ...")
<http://www.ietf.org/html.charters/6lowpan-charter.html> with the
following:

- - - - - -

  The IP over IEEE 802.15.4 Working Group will develop an architecture,
  protocols, and other technologies that will interconnect IEEE 802.15.4
  networks with IPv4 and IPv6 networks.  The Working Group will
  demonstrate independent, interoperable implementations of these standards.

  IEEE 802.15.4 wireless personal-area networks, (wireless PANs), are
  dramatically different than the environments in which IP is
  traditionally deployed.

  o  Many nodes in wireless PANs are severely resource-constrained.
     Often, these nodes will use eight-bit processors with only a 
     few tens-of-kilobytes of program storage and a few kilobytes of
     temporary storage.

  o  Many wireless PAN nodes are powered by batteries.  As such,
     each node is able to transmit only a relatively fixed number
     of bits over its lifetime.  The cost of unnecessary network overhead
     is much higher in battery-powered wireless PANs, because it directly
     reduces the lifetime of the network.

- - - - - - - -

A few comments about why I chose the language I did:

o	As a matter of personal style, I made the language more direct
	and eliminated a fair amount of verbiage that didn't seem to
	directly support our cause.

o	I more explicitly mentioned IEEE 802.15.4.  It appears to me that
	our focus doesn't include any other wireless PAN technology.
	Yes, our solution should provide a good model for other technologies,
	but I haven't seen anyone thinking about anything other than
	802.15.4.  If I'm wrong, someone should say something.

o	I wanted to remind us that we are, in fact, developing an
	architecture for wireless PAN/IP interconnections.  We are doing
	this because we largely don't have any models upon which to
	build.  Our current approach is to distribute these architectural
	design decisions throughout a number of documents, so it is
	useful to remember that they should cumulatively create a
	complete, consistent architecture.  (My thoughts on the need
	for an architecture document are left as an exercise for the
	reader...)

o	I described our objective as "interconnecting" wireless PANs
	and IP networks, rather than "running IP over" wireless PANs.
	I think that the former may provide a stronger motivation for
	why this work is important.

o	I believe that we really must develop a solution that gracefully
	interconnects with both IPv4 and IPv6 networks.  Note that this
	language doesn't specify how this will be done, just that we have
	to ensure that it works.  We may decide to use one or more
	existing IPv4/IPv6 transition strategies, but we shouldn't just
	assume that at least one will magically work and ensure
	interoperability without any thought on our part.

o	I wanted us to remember that we aren't done until we can demonstrate
	two independent, interoperable implementations.  Of course,
	from my perspective, these implementations ought to be complete
	systems, not just bits and pieces, (e.g., a format implementation,
	a neighbor discovery implementation, etc.).

Yes, we all agree that the rest of the charter needs to be revised,
but I don't have any proposed language for the rest of the charter (yet).

And finally, I don't claim that my suggested language is right, just that
we ought to be thinking about this.

More free advice from,

-tjs

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 18 Apr 2006 20:02:38 -0500 (CDT)

> Date: Tue, 18 Apr 2006 17:54:28 -0500 (CDT)
> From: "Timothy J. Salo" <[email-masked]>
> Subject: [6lowpan] Working Group Charter
> 
> ... I suggest replacing the first three paragraphs ...

Oops, I forgot a paragraph.

> 	[...]

o	In many markets, minimizing the cost of wireless PAN nodes
	is critical.  For example, the difference in cost between
	32 KB of ROM and 64 KB of ROM may make the difference between
	a product that is competitive and one that is not.  Of course,
	this extra 32 KB of RAM will reduce the battery life of the
	node, as well.

- - - - - -

Sooner or later, someone will figure out that we have no intention of
actually implementing IPv6 in wireless PANs, (e.g., mobile IP, IPsec,
a bunch of MIBs, etc.).  We should be prepared to explain why.

[Speaking of MIBs, will wireless PAN/IP gateways have MIBs?]

-tjs

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 18 Apr 2006 19:18:34 -0700 (PDT)

> actually implementing IPv6 in wireless PANs

If this is the case there is hardly any point in developing IPv4 PAN at all. It
should be IPv6 only as it was from the start.

Peter

> 	this extra 32 KB of RAM will reduce the battery life of the

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Geoff Mulligan <[email-masked]>
Date: Tue, 18 Apr 2006 22:20:32 -0600

What do you mean "that we have no intention of actually implementing
IPv6 in wireless PANs".  We have every intention of implementing IPv6 in
wireless PANs!  In fact WE (Invensys and some other companies) already
have and WE (Invensys) have it deployed in a significant number of homes
in pilots in the US right now.

I do not agree with the wording for your suggested Charter changes,
though I do truly appreciate that someone is starting some sort of
exchange on the list.

	geoff

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 19 Apr 2006 13:28:42 +0900

> in pilots in the US right now.

Count me as one of 6lowpan-implementor in Aais Pacific. 
It is about to be widely spreaded around IPv6 world...

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: "Timothy J. Salo" <[email-masked]>
Date: Tue, 18 Apr 2006 23:33:14 -0500 (CDT)

> Subject: Re: [6lowpan] Working Group Charter
> From: Geoff Mulligan <[email-masked]>
> Date: Tue, 18 Apr 2006 22:20:32 -0600
> 
> wireless PANs!

The working group arguably isn't implementing IPv6 from two perspectives:

o	I don't think the IETF accepts the notion that implementing
	a subset of IPv6 is actually implementing IPv6.  But, I could
	be wrong.  I may ask this on question on the main IETF mail list.
	Having said that, the working group intends to implement
	only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc).

o	The protocol described in the format specification is not
	IPv6.  If you fed it into an IPv6 stack, nothing good would
	happen.  It is, however, a protocol that can easily be
	transformed into [a subset of] IPv6.

>  In fact WE (Invensys and some other companies) already have and WE
> (Invensys) have it deployed in a significant number of homes in pilots
> in the US right now.

See above.

> though I do truly appreciate that someone is starting some sort of

Feel free to suggest alternative language and ideas.

-tjs

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 19 Apr 2006 00:42:06 -0600

> 	only a subset of IPv6, (e.g., no IPsec, no mobile IP, etc).

Too bad that we have to rehash this again because you are coming late to
this discussion.  We dealt with this issue already and the IESG said
that an implementation that did not include IPsec and the like was still
an implementation of IPv6.
> 	transformed into [a subset of] IPv6.

If you do not use header compression then an IPv6 packet in the payload
of the 6lowpan frame format will work perfectly fine and everything good
will happen.  The 6lowpan compressed headers are never intended to be
passed uncompressed out of a 6lowpan.

---

From: Philip Levis <[email-masked]>
Date: Wed, 19 Apr 2006 00:37:19 -0700

> passed uncompressed out of a 6lowpan.

I might be, as Geoff puts it, merely rehashing old arguments, and if  
so, I apologize.

I don't think there's any question as to whether you can implement  
IPv6 on 802.15.4. It's a link layer, after all. Sure, the headers  
might be big, but you can compress them, etc. Even IPSec is possible;  
without hardware support, it might be an energy nightmare and your  
crypto time might be the throughput bottleneck, but it's possible,  
and hardware support could make it not a big deal.

If you take the IPv6 over 15.4 route (no pun intended), under the  
assumption of low-power embedded devices, I'd argue that it's not the  
data plane that changes, but rather the control plane. E.g., many  
existing IP routing approaches become problematic, predominantly due  
to the fact that the assume any-to-any connectivity as an end goal,  
while in PANs this is less commonly the case. I think this gets to  
the point raised earlier, of whether the group considers 802.15.4  
networks being used as transmit networks, which is a very very  
important consideration.

Coming from the world of TinyOS and sensor networks, I'd argue that  
it's pretty clear that a set of protocols and mechanisms enabling IP  
devices to directly communicate with PAN devices would be very useful  
(why I'm here). The most common case for this is management, as it's  
a situation where a user definitely wants to talk to a specific  
*node*, i.e., an address, rather than use some other naming scheme  
(e.g., "the lights in the living room"). The advantage that a direct  
IP-level protocol transcoder would provide is that it would preclude  
the need for application-level protocol stacks to even communicate  
with nodes within a network. Furthermore, you can begin to use all of  
the basic IP tricks and techniques when managing these networks  
(e.g., firewalls).

That being said, if the plan is not to push IPv6 into the PAN, then  
this raises the simple question of what L3 protocols will run within  
the PAN.

Phil

http://csl.stanford.edu/~pal

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Apr 2006 10:29:51 -0500

I do not think it is the question of whether or not IPv6 can be 
implemented, the answer is of course it can be. Even IPsec/ MIPv6 can 
implemented as Phil said. From IP point of view this is another L2, and 
that's where I would like to comment.
  It seems that there is a fundamental problem in forming WGs on 
specific link layers, we have 6lowpan and 16ng as examples. In the past 
this was not followed, e.g. we did not have 3G related WGs although 3G 
has had much bigger impact.
  The question we should ask is what is the model to follow in 6lowpan? 
This seems to be not well defined so far and the discussions can help it 
clarify. However, as Timo said, the requirements should come from the 
industry, they should be real problems to be solved, so far we are not 
seeing this.
  As an example of the model, for example, for 16ng, we have WiMAX and 
to a lesser extent IEEE 802.16 that produce the requirements for any 
IETF standardization. WiMAX is taking the link spec from IEEE and 
defining a full-fledged cellular network using this link.
  We might probably need to define what a sensor network is and then 
derive the requirements for 6lowpan WG to do IETF-domain standardization.
  Hope this helps,

--behcet

---

From: Peter Sherbin <[email-masked]>
Date: Wed, 19 Apr 2006 10:00:39 -0700 (PDT)

> industry, they should be real problems to be solved, so far we are not 

Here is an industry input. I am working on a case where I need 10M - 100M mobile
sensors size of 1/10 of a penny spread accross North America to provide updates
every 10 min on their location / physical status for the duration of three - five
years. All of them must have full length IPv6 addresses.

When should I expect the solution from this WG?

Peter

---

From: "Timothy J. Salo" <[email-masked]>
Date: Wed, 19 Apr 2006 12:21:41 -0500 (CDT)

> Date: Wed, 19 Apr 2006 00:42:06 -0600
> 	[...]
> an implementation of IPv6. ...

Could you provide a reference for this guidance?

Here is what the chair of the IETF and the IESG said when I posed the
question about subsetting IPv6 to the main IETF mail list:

> Date: Wed, 19 Apr 2006 12:12:46 +0200
> From: Brian E Carpenter <brc@>
> Cc: "Timothy J. Salo" <salo@>, [email-masked]
> Subject: Re: IPv6 Subsets?
> 
> You might also want to look at RFC 4294
> (IPv6 Node Requirements).
> 
>     Brian

And, here is what one of our Area Directors, (also a member of the
IESG), said:

> Date: Wed, 19 Apr 2006 11:14:20 +0300
> From: Jari Arkko <jari.arkko@>
> To: "Timothy J. Salo" <salo@>
> Cc: juha.wiljakka@ [email-masked]
> Subject: Re: IPv6 Subsets?
> 
> RFC 4294 contains the most recent summary information
> on what nodes should support from IPv6. The detailed
> MUST/SHOULD/MAY requirements are in the IPv6
> specifications themselves.
> 
> (RFC 3316 that Juha pointed to is a discussion of issues
> related to running IPv6 over cellular interfaces. The
> type of the interface that you are using does impact what
> you need to support, at least in terms of what IPv6 over
> Foo you need to support, what configuration options
> make sense, etc.)
> 
> --Jari

Note that Jari is also a co-author of RFC 4294.

Having said that, I believe that, at least from an engineering perspective,
implementing a subset of IPv6, [a smaller subset than is permitted under
RFC 4294], may make sense for wireless PANs.  However, if we conclude that
this is a good idea, we need to understand that implementing a subset of
IPv6 conflicts with the prevailing view of many in the IETF.  As such, if
we want to implement less of IPv6 than is permitted under RFC 4294, we
should start preparing our arguments about why wireless PANs are different
from other environments.

-tjs

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Apr 2006 13:24:19 -0500

>When should I expect the solution from this WG?
If you have 802.15.4 radio and MAC layer on them then use the format 
draft to implement an IP stack. Build your application including routing 
on top yourself.
If you don't then nothing applies here maybe TinyOS might help you.

Regards,
--behcet

---

From: [email-masked]
Date: Wed, 19 Apr 2006 18:53:41 +0000

yo...  have you solved the power problem?  small, (nearly) always on
 for three/five years  is a tough nut to crack.  tried it at least
 three different times in the past 10 years.  kind of doable w/ active RFIDs
 but the life expectancy is much shorter.  

--bill

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 19 Apr 2006 13:40:22 -0600

we have not solved the power problem.  We have found some techniques for
building sensors that are not always on that look to have a 6-7 year
battery life - 1) these devices are not considered part of the mesh
routing and 2) they communicate with the core of mesh which is always
on.

power is going to be one of the hardest problems, but in our view of the
application space, wireless does not equate to only battery operated.

	geoff

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Sun, 23 Apr 2006 16:43:59 -0700

Hello Timothy,

IESG had approved 6lowpan wg  sometime ago and I am sure they
were aware of some of the cases of IPv6 that are not directly
or efficiently applicable for 802.15.4 networks. IPv6 is still useful
for standardization of these devices. Sensors or 802.15.4 radio interface
capable devices will be deployed large in numbers; the applications
will expand from mere collection information from the end devices and
they would often require to interoperate with regular devices on the
Inernet. IPv6 is the sane and standard way to interoperate in that case
without building numerous application gateways  from different vendors.

As one of the design-team members of RFC4294, I can say that IPv6
node requirements document is a guide line for generic IPv6 node builders.
6lowpan devices can implement generic IPv6 protocol, but due to the
nature of power usage, device processing power, 802.15.4 network is
quite different than regular fixed ethernet or wifi network for which IPv6
protocols are generally applicable.  IPv6-over-foo needs to be developed
and optimized for other type of interfaces and that's what 6lowpan is
aiming for. The format document has consulted the IPv6-node-requirement
document as well as far as I remember.
It is the same reason, we are trying to optimize IPv6 Neighbor discovery
protocol for this type of network.  If you read the 6lowpan goals document
and 6lowpan Neighbor discovery draft, you can see explanations how
6lowpan is different than regular Internet networks.

-Samita

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Sun, 23 Apr 2006 19:30:17 -0700

Hi Phil,

> to the fact that the assume any-to-any connectivity as an end goal,

Agree that IPv6 routing may be redundant in 802.15.4 network.
The format document suggests alternative routing (Mesh) at L2.

Thus, in practice, IPv6 would be useful for addressing, auto-configuration
, device management and running applications while routing within the
PAN takes place at the L2 layer. From IPv6 perspective, a PAN is a
L3 subnet. However, the IPv6 router at the 6lowPAN junction is responsible
for routing a packet to the Internet if the destination address suggests so;
here the IPv6 6lowPan router acts as a default gateway.

> networks being used as transmit networks, which is a very very

Good point. As mentioned earlier, 802.15.4 L2 layer can be used for
data routing within the PAN.

> the basic IP tricks and techniques when managing these networks

Agree.

> this raises the simple question of what L3 protocols will run within

By L3 protocols do you mean any routing protocols?  Other than that,
format doc already talks about running UDP, at the last interim folks
brought up
needs for running a simple TCP stack as well for running different existing
apps. I'd think it really depends what sort of applications folks will run
on top of 802.15.4 networks?  There might be devices other than sensors,
which
will run 802.15.4 radio for a different type of applications where
node-to-node
communications might be necessary. Any ideas?

Thanks,
-Samita