Subject: Re: [6lowpan] 01 version of IP over IEEE 802.15.4

From: Shoichi Sakane <[email-masked]>
Date: Wed, 09 Feb 2005 15:00:24 +0900

Hi,

>    draft-montenegro-lowpan-ipv6-over-802.15.4-01.txt

as i read the draft, let me say thank you for the great work,
and i have two comments.

1. A link fragment defined at the section 2 is always placed to the MAC
   payload in the MAC protocol data unit of IEEE 802.15.4, right ?
   If my understanding is correct, it would be better for me to describe
   that though it might be explicit thing.
   
2. in the section 8.1, "PI" is defined like below:
	PI: Prefix included in-line
   "in-line" means that the prefix included in the following IPv6 header ?
   or it included anywhere ?

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

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 09 Feb 2005 10:54:21 -0800

Sakane-san,

Thanks for your generous words.

>    that though it might be explicit thing.

Not sure I understand the question. Section two does not talk much about
fragmenation. In that respect, there is no mention of "link fragments" as
per your question. There is, however, mention of IPv6 links (which map to
IPv6 prefixes).

There is mention of link fragments in section 4, however. Even so, not all
packets will need to be fragmented (the expectation is that most will be
small enough). Only those that are fragmented use the encapsulation in
figures 2 and 3. Unfragmented packets use the simpler encapsulation format
in figure 1.

Perhaps you're asking where exactly this encapsulationn format (figs 1-3)
occurs. Yes, it is the MAC frame payload in the 15.4 MAC PDU. I agree that
it makes sense to say so explicitly. Added this as a new first paragraph in
section 4.1:

    All IP datagrams transported over IEEE 802.15.4 are prefixed by an
    encapsulation header with one of the formats illustrated below.  The
    encapsulation formats defined in this section are the payload in the
    IEEE 802.15.4 MAC protocol data unit (PDU).

>    or it included anywhere ?

It means that it is included as a non-compressed field. Notice that what follows
the encoding bit maps is not an IPv6 header, as the point is to compress it.
Rather, what follows is a smaller version of an IPv6 header comprising the
non-compressed fields as specified in section 8.2. I've added references to
section 8.2 whenever 'carried in-line' is used, as in:

E.g., this is how it reads now:

       PI: Prefix carried in-line (Section 8.2)
       PC: Prefix compressed (link-local prefix assumed)
       II: Interface identifier carried in-line (Section 8.2)
       IC: Interface identifier compressed (derived from link-layer
          address)

And added this as the new first paragraph in section 8.2:

    This scheme allows the IPv6 header to be compressed to different
    degrees.  Hence, instead of the entire (standard) IPv6 header, only
    non-compressed fields need to be sent.  The subsequent header (as
    specified by the Next Header field in the original IPv6 header)
    immediately follows the IPv6 non-compressed fields.

Hope that helps,

-gabriel

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 10 Feb 2005 11:27:54 +0900

> Not sure I understand the question. Section two does not talk much about

sorry, my fault, I meant the section 4.

> Hope that helps,

both are fine to me, thank you very much.

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 14 Feb 2005 16:24:22 -0800

Folks,

We've submitted the first *official* version of this draft (previous ones had circulated
on the alias, though).

The draft is available in anticipation of it appearing at the IETF
repository in either html or txt formats:

	draft-kushalnagar-lowpan-goals-assumptions-00.txt
	draft-kushalnagar-lowpan-goals-assumptions-00.html

To fetch it, please go here:

	http://f2.pg.briefcase.yahoo.com/gabriel_montenegro_2000

[it's in the "lowpan" directory]

tnx,

-gabriel

---

From: Soohong Daniel Park <[email-masked]>
Date: Tue, 15 Feb 2005 19:50:27 +0900

Hi Nandakishore and Gabriel

Overall looks good for me and several comments are as below;

1. similar words make an unnecessary confusion, for example
LoWPAN, LoWPANs, LoWPAN network and LoWPAN networks
I guess all above term mentions the same meaning through this
document. Personally, LoWPAN is so preferable.

2. Prior to addressing the section 4.1, the related assumption
should be indicated in the section 3. For example,

Devices within LoWPAN have a IP function to discover, control,
manage and communicate with each other. Further, IPv6 is 
considered in this document to support the unique address to 
the large number of devices.

3. Regarding the section 4.2, I am not sure why topologies
including mesh and star of IEEE 802.15.4 is a problematic.

4. In section 6
Instead of TBD, I'd propose below mention simply,

No IANA considerations are required in this document.

Thanks.

     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of gabriel montenegro
> Sent: Tuesday, February 15, 2005 9:24 AM
> To: [email-masked]
> Subject: [6lowpan] 00 version of Goals and Assumptions submitted
> 
> 
> Folks,
>

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 16 Feb 2005 23:12:18 -0800

> Overall looks good for me and several comments are as below;

thanks

> document. Personally, LoWPAN is so preferable.

Well, LoWPAN and LoWPANs are just singular and plural of the same
word. But I agree that "LoWPAN network/s" does not make much sense
because it is redundant, given that LoWPAN already includes
"network/s": low-power wireless personal area *networks*.

Modified accordingly.

> the large number of devices.

Ok, what I did was move the first numbered list under IP connectivity
to the end of section 3 as follows:

   IP technology is assumed to provide the following benefits:

   1.  The pervasive nature of IP networks allows use of existing
       infrastructure.
   2.  IP based technologies already exist, are well known and proven to
       be working.
   3.  An admittedly non-technical but important consideration is that
       intellectual property conditions for IP networking technology are
       either more favorable or at least better understood than
       proprietary and newer solutions.

Hope this helps.

> including mesh and star of IEEE 802.15.4 is a problematic.

Well, we list some items there as to why. perhaps you don't
agree with those? Or are you confused by the last paragraph
in that section, which I also found lacking. In case this is
it, I've reworded that last paragraph slightly as follows:

   As with mesh topologies, star topologies include provisioning a
   subset of devices with packet forwarding functionality.  If, in
   addition to IEEE 802.15.4,  these devices use other kinds of network
   interfaces such as ethernet, IEEE 802.11, etc., the goal is to
   seamlessly integrate the networks built over those different
   technologies.  This, or course, is a primary motivation to use IP to
   begin with.

> No IANA considerations are required in this document.

I've filled in this section.

thanks!

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 22 Feb 2005 17:54:22 -0800

Folks,

We've submitted a new version of this draft. This version adds UDP to the basic
header compression and includes more informative/clarifying text.

Draft name is:

   draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt

In anticipation of the draft being available off the IETF repository, I've
posted it here:

There, you'll find a txt as well as an html version (both dated Feb 21).

tnx,

-gabriel