Subject: Re: [6lowpan] 6lowpan Architecture Questions

From: Geoff Mulligan <[email-masked]>
Date: Thu, 02 Nov 2006 23:36:11 -0700

Ron,
  These are excellent points.

I would like to hear from other on the list about the idea of supporting
extremely small devices (4K) (smaller than the extremely small devices
that we have been targeting (32K)).  I would not like to choose to miss
a potential market segment (potentially large market segment), but is it
reasonable to got after a 4k device which probably could not possibly
ever accept a 1280 byte (minimum size ipv6) packet.  

I think question 2 is going to be critical as we move to the next phase
of this working group.  Hopefully we will finish the format document and
start on rechartering.  One of the top areas that I think we need to
look at is the idea of utilizing Manet and how the design will impact
6lowpan (memory, power, other costs).  And whether or not we choose to
use the manet approach and protocols, should we down select to a single
protocol or some small set and if so what is the criteria for this
selection.

Please consider what criteria you think we should use to evaluate the
available mesh protocols.

While the IETF doesn't appear to embrace architecture docs, it is
critical for us to agree on some set of use-cases so that we can focus
our efforts on providing real solutions.

So again, please consider for our rechartering and new work items,
should we generate a set of use-cases?  What is the format for this?
Should we support extremely small devices?  And finally what criteria
should we use to determine the selection/evaluation of mesh routing
protocols (which probably begs for a use-case analysis.)

Folks, please start to participate in these discussions.  It is only
with your input that we will have a successful working group and will
create a standard that is useful in the market.

	geoff

On Fri, 2006-10-27 at 09:07 -0500, Ron Strich wrote:
> 1. Many sensor and control devices will be too small to support a full
> mesh/ip adaptation implementation.  Some of these devices may be as small as
> 4K of flash and 100s of bytes of RAM and may only be used in a point to
> point (P2P), simple star, or very simple mesh implementation (please see the
> attached pdf drawing).  Incorporation of these very small devices, I
> believe, is important to the broad adoption of 6lowpan.
> 
> Should we consider how to support these extremely limited devices?  Should
> we make it easy for these simple protocol implementations at this level to
> adapt to 6lowpan? If we want to include these small devices, should we
> consider a more constrained design (limited payload, P2P/star only) that
> would simplify the adaptation layer?
> 
> 2. How will the group evaluate what mesh, P2P or star protocols should be
> supported?  As David pointed out, we may not be allowing for future
> capabilities in the current structure of the adaptation layer should we want
> to support multiple types of L2 protocols.
> 
> 3. Related to the pending mesh protocol evaluation, is the evaluation of any
> functionality related to the "cost" of those technical choices in terms of
> power, code size, complexity, RAM, instructions executed, etc?
> 
> 4. As was mentioned on the list a while ago, neither the Problem Statement
> nor the Format documents discuss the overall 6LoWPAN architecture.  As we
> move forward with our next working group items, shouldn't we create a
> document to describe the high level architecture which might well encompass
> the criteria for evaluation of the protocols and costs mentioned above?
> 
> Ron Strich
> Mobile: 228.369.4332
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan

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

---

From: "Ron Strich" <[email-masked]>
Date: Fri, 3 Nov 2006 07:11:05 -0600

Geoff,

I agree that "use case" is a better term than architecture, especially
considering the historical issues that Carsten has raised.  But I also
believe that the incorporation of very small devices into a 6lowpan "use
case" is important to the adoption of 6lowpan.  Cost is also important
consideration for 6lowpan adoption.  An extra $0.01 in cost imposed by
6lowpan, has a potential $100 million annual impact to the adoption of
wireless communications to the micro controller industry at today's
production rates.

Ron

-----Original Message-----
From: Geoff Mulligan [mailto:[email-masked]] 
Sent: Friday, November 03, 2006 12:36 AM
To: Ron Strich
Cc: '6lowpan'
Subject: Re: [6lowpan] 6lowpan Architecture Questions

Ron,

	geoff

---

From: Abhijit Rao <[email-masked]>
Date: Sat, 4 Nov 2006 03:30:07 -0800 (PST)

Geoff,
  Here is one format for preapring the Use Cases.
   
  Use Case: <Title>
  Category:
  Goals to be achieved by this use case:
  Roles <To make it very general use actors>:
  Needs (Preconditions):
  Context (Triggers) - Optional:
  Usage Scenarios: <Add steps to each usage scenario>
  Postconditions - Optional:
   
  We put together all the use cases and then classify them in terms of priority and/or life-term. And hopefully that should also help us identify the functional requirements / components
   
  Here is a sample that I prepared
   
  Use Case:  Intermittent Data acquisition from a LowPAN device
  Category(s): Healthcare
  Goals to be achieved by this use case: Obtain data for monitoring at the client machine in the local network. Summary of the data acquired maybe stored. The Profile of the LowPAN device is fixed.
  Roles <To make it very general use actors>: Andy – responsible for setting up and managing the client machine.
  Roy – Installs the LowPAN device and is responsible for its functioning
  Amin – LowPAN device is devoted to Amin
  Malin – Unauthorized entity trying to get into the network
  Dr Brad – Entity that specifies the policies and profile for LowPAN device and Amin. Also recipient of summary of data acquired.
  Needs (Preconditions): the device is operational and ready to be used
  Context (Triggers) - Optional: 
  Usage Scenarios: 
  - Identifying Amin and Preparing Amin
  - Setting up the LowPAN device for data acquisition- preparing the policies
  - Authorized Data acquisition and control
  - Unauthorized data acquisition and control
  - Device Tracking
  - Device maintenance
  Post conditions - Optional:
   
  We should have a master pool of Categories and Roles – so that all the use cases have a common basis.
   
  Other use cases could be
  -         Large  scale deployment of LowPAN devices (real-time monitoring)
  -         LowPAN device as a Utility (such as Gas, Electricity) Usage Monitor (Command / Response driven – Profile is being pushed)
  -         LowPAN device being used in Home Network Monitoring (Mobile home owner can access theis LowPAN device in his home)
  -         Touch less access control system at a Building 
   
  Abhijit
  
Ron Strich <[email-masked]> wrote:
  Geoff,

Ron

-----Original Message-----
From: Geoff Mulligan [mailto:[email-masked]] 
Sent: Friday, November 03, 2006 12:36 AM
To: Ron Strich
Cc: '6lowpan'
Subject: Re: [6lowpan] 6lowpan Architecture Questions

Ron,

geoff

 
---------------------------------
Get your email and see which of your friends are online - Right on the  new Yahoo.com

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Sun, 5 Nov 2006 15:26:07 -0800

Hi Carsten, Ron and all:

Agree, it is a good point that we did not clearly discuss the topology for
6lowpan architecture. During 6lowpan-nd discussion, we discussed and
agreed on different supporting topologies for 6lowpan ( both at interim 05
and at Dallas IETF meeting). Section 4 of 6lowpan-nd draft captures that
text (see below). If we decide to have a separate architecture document,
then we can use these portion of the text.

---------------------------------------------------------------------------------------------
4.  Assumptions about Topology and Address Mapping

   In order to minimize the multicast packets we need to make some
   assumptions that tie together the L2 functional elements and the L3
   functional elements.  We also state our understanding of how IPv6
   would map to a LowPan network:
   o  One PAN-ID defines one LowPan Network.
   o  Each LowPan corresponds to one IPv6 subnet as PAN-ID may be used
      to determine a subnet.
   o  There is one PAN co-ordinator or PAN group leader per one LowPan.
   o  The IPv6 router which sits in the boundary of the LowPan is a PAN
      co-ordinator.
   o  There can be multiple co-ordinators in the LowPan.
   o  When a device connects to the LowPan at layer 2, it finds out a
      (unicast) layer 2 address for its co-ordinator.
   o  By recursive construction, the previous item implies that a co-
      ordinator knows its co-ordinator from when it connected to the
      LowPan, hence there is distributed knowledge of unicast addresses
      that lead all the way to the PAN co-ordinator.
   o  The IPv6 router assigns addresses through prefix advertisement.
   o  The other FFDs in the network do not act as a IPv6 router, but
      they generally route data packet in the L2 layer (Mesh layer
      routing).
   o  Star topology assumes that each node is one hop away from the PAN
      co-ordinator.
   o  This document defines a mesh topology (see diagram below).  In
      mesh topology, each node is capable of forwarding.  Thus it can be
      assumed as a network of full functional devices (FFDs) with one
      PAN co-ordinator and multiple co-ordinators.

Chakrabarti & Nordmark  Expires December 26, 2006               [Page 6]

Internet-Draft    LowPan Neighbor Discovery Extensions         June 2006

   o  FFDs may or may not be more than one hop away from the PAN co-
      ordinator.
   o  We assume that the 64-bit EUI-64 addresses are used as link-layer
      address in the lowpan, since these addresses never change for a
      given node.  Appendix A discusses some additional considerations
      should we apply this to the 16-bit addresses.

   This document currently supports the following topologies:

            1)  Star  Topology

                 PAN-C
                    O
                 /  |   \
                o   o    o  <------- RFDs or FFDs

           2) Mesh Topology

            Example-1                               Example-2

                   O    PAN-C                     O <--  PAN-C
              /    |      \      o             /  |    \
             /     |       \   /              /   |     \
            FFD----FFD----- FFD              FFD--FFD-----FFD
             \     |\       /  \              \    | \    /|
              \    | \     /|   o              \   |  \  / |
               \   |  \   / |                   \  |   \/  |
                \  |   \ /  |                    \ |   /\  |
                 \ |    \   |                     \|  /  \ |
                  \|   / \  |                      |/     \|
                   FFD    \ |                      FFD    FFD
                /  | \     FFD
               o   0  o    / \
                           o  o  <--RFDs

   Each FFD may act as simple co-ordinators but there is only one PAN
   co-ordinator in the mesh LowPan topology.

------------------------------------

Thanks,
-Samita

On 10/27/06, Carsten Bormann <[email-masked]> wrote:
> Ron,
>
> good input.
>
> Let me just pick up on one of these points:
>
> The IETF is quite wary about "architecture" documents.
>
> (The OSI reference model is the textbook example here:
> ISO did an architecture ["reference model"], and then, only when
> defining the protocols, found out that the architecture didn't make
> sense.
> But it was too late to fix the architecture, so the bad layers limped
> on until OSI finally died.
> The really funny thing, of course, is that, in 2006, people are
> *still* citing the layers of the defunct reference model...)
>
> In the IETF, we tend to standardize functional components and leave
> it to the market how to build "architectures" out of these.
> Of course, that is not always possible.
> Also, it may be necessary to have an (really: one or more)
> architectures in mind when building components.
>
> So, I'd welcome discussion of architecture(s).  I'm just not sure we
> actually want to "standardize" them.
>
> Gruesse, Carsten
>
>