Subject: [6lowpan] Comments on draft-ietf-6lowpan-routing-requirements-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Feb 2009 17:31:59 +0100

[Where should I post this message, to 6LoWPAN or to ROLL list?  Both?]

Dear WG members,

draft-ietf-6lowpan-routing-requirements-00 lists a Problem Statement,
some Scenarios and a set of Routing Requirements.  Generally I find it a
well written document, with many meaningful details.

There are very many parts of this document to which I silently agree,
even some parts I wholehartedly agree.  I like the distinction
route-above mesh-under, and many other parts too.

Some high-level questions:
-is there a requirement to connect a 6LoWPAN network to the Internet?
-is the 6LoWPAN using addressing architecture and longest-prefix match
  based routing as in the Internet?
-how many interfaces will a 15.4 device have potentially?

Following are detail questions and comments.  I believe they're not as
important as the items mentioned above.

> 1.  Problem Statement

Is this _the_ problem statement or should I better go read
draft-ietf-6lowpan-problem-08?  They differ largely...

> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" 
> [3]) briefly mentions four requirements on routing protocols;
> 
> (a) low overhead on data packets
> 
> (b) low routing overhead

What is routing more generally?  Is it the act a router performs when
presenting with a packet, searching in a routing table, maybe exploring
its ND structures, maybe sending ND messages and then emitting the packet?

Or is it exchanging IP datagrams containing prefixes and metrics and
reachability information, such that nodes have a common view of the
network paths?

I think this is worth discussing, in order to better target what the
work should follow this problem statement and reqs.

Are the low overhead requirements put on the database construction
messages?  Or on the individual act of forwarding a packet?

> On the other hand, the route-over approach relies on IP routing and 
> therefore supports routing over possibly various types of 
> interconnected links (see also Figure 1).

At several places in the draft, when link 'types', device 'types' are
mentioned, I'm tempted to believe 6LoWPAN considers links other than
802.15.4 links?  Is it so?  Should 6LoWPAN routing protocol work also
with aseptic point-to-point links?

Or are the 'types' limited within the relatively large scope of 802.3
compatible MACs (I believe 802.15.4 and 802.16 to fit within).

This is of paramount importance in setting the scope.

> The most significant consequence of mesh-under routing is that 
> routing would be directly based on the IEEE 802.15.4 standard,

Which 'routing' is directly based on 802.15.4 standard?  The 'IP
routing' is based on that standard?  This brings back to defining what
routing is.

Maybe better call 'mesh-under routing' 'mesh-under switching'.

IP routing and addressing may be fundamentally different than mesh-under
addressing and switching - in the way hosts get and maintain their
addresses and in the way routers/switches search their databases (exact
match vs longest-prefix).

> When a route-over protocol is built in the IPv6 layer, the Dispatch 
> value can be chosen as one of the Dispatch patterns for 6LoWPAN, 
> compressed or uncompressed IPv6, followed by the IPv6 header.

Sorry, I can't parse this.

A route-over protocol would act both at IP layer and
application/transport layers.  Depends what a routing protocol is.  For
example ICMP Redirect, or NEMOv6 or ND act at IP layer, whereas RIPng is
over UDP.

'followed by'... when reading left to right or reverse?

> For route-over, a default route to the ER could be inserted into the
>  routing system.

In the routing system of the 6LoWPAN network?  Or in the routing system
of the fixed Internet network?

> IP-based low-power WPAN technology is still in its early stage of

'WPAN'?

> a.  Network Properties:
> 
> *  Number of Devices, Density and Network Diameter: These parameters
>  usually affect the routing state directly (e.g. the number of
> entries in a routing table or neighbor list).  Especially in large
> and dense networks, policies must

What is 'large' and 'dense'?  Is it about physical dimensions?  Or IP
dimensions?

Density sounds as a physical characteristic (many devices in a small
area) whereas Diameter sounds as a pure IP term (max number of IP hops).

The number of entries in the routing table mostly depends on the planned
addressing architecture.  One can have a very high-diameter network with
a very hierarchical addressing structures, many default routes, and very
few entries in the routing tables (maybe only 1 per hop).

Is the addressing architecture for 6LoWPAN networks planned?

Is the addressing architecture following the Internet model?

> b.  Node Parameters:

How many interfaces does a 6LoWPAN node typically have?  This is of
paramount importance deciding whether any type of repeating/bridging
needs to happen.

> *  Throughput: The maximum user data throughput of a bulk data 
> transmission between a single sender and a single receiver through an
>  unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as 
> follows [19]: [...]
> 
> In the case of 915 MHz band:

Sorry, for my clarification:  is 915MHz the width of band centered on
the 2.4GHz mentioned above?  Or is it the central frequency (thus
replacing the "2.4GHz" mentioned above)?

> [R02] 6LoWPAN routing protocols SHOULD cause minimal power 
> consumption by the efficient use of control packets (e.g., minimize 
> expensive multicast which cause broadcast to the entire LoWPAN) and 
> by the efficient routing of data packets.

YEs, but multicast may be more efficient than broadcast - is it
sufficient?  I think it is sufficient to rely on multicast and avoid
unnecessary duplication such as in broadcast.

'Efficient routing of data packets' - is it also efficient search in the
routing table?  That may be part of 'routing' too.

> possibliy

Nit: iy

> [R03] 6LoWPAN routing protocol control messages SHOULD not create 
> fragmentation of physical layer (PHY) frames.

Err... I think PHY frames aren't fragmented... not sure I understand
this requirement?

Sounds as if one wants an UDP control packets to not be sent in several
pieces, because of overhead involved fragmenting/reassembling.

Then make sure first IP doesn't fragment.

> Therefore, 6LoWPAN routing should not cause packets to exceed the 
> IEEE 802.15.4 frame size [81bytes].

Is this a requirement on the mesh-under link-layer switching protocol?
Or on the 'route-above' protocol?  If the latter - I think this
requirement is a violation of layer independence :-)

It sounds very special to me to limit the size of the messages of an IP
routing protocol.

Knowing that IP can fragment too.

> [R05] The design of routing protocols for 6LoWPANs must consider the
>  end-to-end latency requirements of applications and IEEE 802.15.4 
> link latency characteristics.

'Routing'?  Or 'Transport'?  end-to-end is what Transport typically
takes care of, not routing.

If Routing: which routing?  The forwarding ahppening at a node?  Or the
convergence time?  The exchange of routing messages?

> Some routing protocols are aware of the hop count of a path.

I think all of them are, no?

> In homes, buildings, or infrastructure, some nodes will be installed
>  with mains power.  Such power-installed nodes MUST be

If they have mains power - will they use Power-Line Communications?

> Building monitoring applications, for instance, require that the 
> mobile devices SHOULD be capable of leaving (handing-off) from an old
>  network joining onto a new network within 15 seconds [17].

Should such a mobile device change its IP address or is it free to
change it?

> [R13] 6LoWPAN routing protocol SHOULD support various traffic 
> patterns; point-to-point, point-to-multipoint, and multipoint-to- 
> point, while avoid excessive multicast traffic (broadcast in link 
> layer) in 6LoWPAN.

It's called multicast at link-layer too (802.3); thus it avoids
unnecessary packet duplication, thus it avoids duplication of
broadcasted packets and thus avoids excessive traffic.

If we talk IPv6 and recent link layers then I mostly forget the term
'broadcast' and use multicast instead.

> 6LoWPAN routing protocols should be designed with the consideration 
> of forwarding packets from/to multiple sources/destinations.

Sorry, what do you mean?  An IP packet with multiple src fields?

> Current WG drafts in the ROLL working group explain that the workload
>  or traffic pattern of use cases for 6LoWPANs tend to be highly 
> structured, unlike the any- to-any data transfers that dominate 
> typical client and server workloads.

Sorry, what do you mean by 'any-to-any' data transfers?  Any
relationship to 'IP anycast'?

> [R14] 6LoWPAN protocols SHOULD support secure delivery of control 
> messages.  A minimal security level can be achieved by utilizing AES-
>  based mechanism provided by IEEE 802.15.4.

Isn't AES superstrong and thus computation intensive and thus
energy intensive?

Intuitively speaking, maybe SHA-1 is sufficient for reduced needs in
constrained environments.

> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending 
> "Hello" messages.

ND doesn't send Hello messages, but NS, NA, RS and RA.

> [R18] If the routing protocol functionality includes enabling IP 
> multicast, then it may want to employ coordinator roles, if any, as 
> relay points of group-targeting messages instead of using link-layer
>  multicast (broadcast).

link-layer multicast no broadcast.

Nit: 'MAC sub-layer' appears only once and in the figure they're
      all 'layers'.

Alex

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 12 Feb 2009 11:38:05 +0900

Dear Alex,

Thank you very much for your detail comments.
I think your comments help us clarify many points on the draft.
I'm just about to leave to other town for a domestic biz trip. I will
get back to you asap.
Thanks,

-eunah

On Thu, Feb 12, 2009 at 1:31 AM, Alexandru Petrescu
<[email-masked]> wrote:
>> The 6LoWPAN problem statement document ("6LoWPAN Problems and Goals" [3])
>> briefly mentions four requirements on routing protocols;
>>
>> therefore supports routing over possibly various types of interconnected
>> links (see also Figure 1).
>
>> The most significant consequence of mesh-under routing is that routing
>> would be directly based on the IEEE 802.15.4 standard,
>
>> When a route-over protocol is built in the IPv6 layer, the Dispatch value
>> can be chosen as one of the Dispatch patterns for 6LoWPAN, compressed or
>> uncompressed IPv6, followed by the IPv6 header.
>
>
>>  unslotted IEEE 802.15.4 2.4 GHz channel in ideal conditions is as follows
>> [19]: [...]
>>
>> [R02] 6LoWPAN routing protocols SHOULD cause minimal power consumption by
>> the efficient use of control packets (e.g., minimize expensive multicast
>> which cause broadcast to the entire LoWPAN) and by the efficient routing of
>> data packets.
>
>> Therefore, 6LoWPAN routing should not cause packets to exceed the IEEE
>> 802.15.4 frame size [81bytes].
>
>>  end-to-end latency requirements of applications and IEEE 802.15.4 link
>> latency characteristics.
>
>> Building monitoring applications, for instance, require that the mobile
>> devices SHOULD be capable of leaving (handing-off) from an old
>> [R13] 6LoWPAN routing protocol SHOULD support various traffic patterns;
>> point-to-point, point-to-multipoint, and multipoint-to- point, while avoid
>> excessive multicast traffic (broadcast in link layer) in 6LoWPAN.
>
>> 6LoWPAN routing protocols should be designed with the consideration of
>> forwarding packets from/to multiple sources/destinations.
>
>> structured, unlike the any- to-any data transfers that dominate typical
>> client and server workloads.
>
>> [R16] For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello"
>> messages.
>
>> multicast, then it may want to employ coordinator roles, if any, as relay
>> points of group-targeting messages instead of using link-layer
>>  multicast (broadcast).
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Mon, 16 Feb 2009 19:28:59 +0900

Dear Alex,

Thank again for your detail comments. As I told you before, it helps
us to refine our draft.
Some of your comments are about fundamental of 6LoWPAN, so I guess
other 6LoWPANers may help me to give you some answers.
Anyway, I put my thoughts in line.

> well written document, with many meaningful details.

Thank you very much for your possitive comments. :)

> route-above mesh-under, and many other parts too.

Thanks again. :)

> -is there a requirement to connect a 6LoWPAN network to the Internet?

Do you mean in terms of routing? Or a general view of 6LoWPAN?
The birth of 6LoWPAN is to make the Low-power low rate network (based
on IEEE 802.15.4) look like an IPv6 link.

If you only meant routing, the reachability can be achieved by mesh
routing (or mesh switching in your comment below) or route-over.

I don't know if it answers your question.

>  based routing as in the Internet?

Alex, I think RFC 4944 may help your curiosity of 6lowpan fundamental.
Although the header compression format is updating in 6lowpan now, you
can find a basic needs of 6lowpan in the RFC.
If I shortly explain, an IPv6 Interface Identifier is obtained from
the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 link-local
address for an IEEE 802.15.4 interface is formed by appending the
Interface Identifier to a certain prefix (see Section 6 and Section 7
of RFC 4944). With regard to routing, I understand the answer is 'yes'
in the case of route-over.
Please kindly let me know if you already checked the RFC and your
intention from the question was different from my answer. :)

> -how many interfaces will a 15.4 device have potentially?

Well, currently, as I follow up, one interface only for a sensor node
in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4
+ 802.11 or others).

> draft-ietf-6lowpan-problem-08?  They differ largely...

First of all, just for your information, draft-ietf-6lowpan-problem-08
is now RFC 4919.
The section 1, problem statement of our draft is focusing on routing
in 6LoWPANs, and RFC 4919 states general problem of 6LoWPAN, including
a brief requirement as you refered in the below.

> reachability information, such that nodes have a common view of the

I would say that it include all the functionalities needed for the
selection of a path from source to destination.
However, I should be careful use the term 'router' here.
Although 6lowpan nodes may perform such routing functionality for the
reachability, it's different from traditional term of 'router'.
In route-over, they call 6lowpan nodes performing routing as 'routers'
- One radio hop is a single IP link.
However, in mesh-under, only one 6lowpan router exists in one 6lowpan
(ER in Figure 2 of the draft) - Whole 6lowpan is One IPv6 link.
To cover the both case, please understand in this way; 6LoWPAN node
may perform such a 'routing-related functionalities'.

> messages?  Or on the individual act of forwarding a packet?

I would say 'on both'.
> This is of paramount importance in setting the scope.

Oh, link 'type'. ;) Currently 6lowpan is clearly based on 802.15.4,
although some talks that 6LoWPAN can run on top of other radios with
similar characteristics. And, for route-over (as ROLL WG is working
on), the benefit which have been insisted is that the routing
mechanism is link-independent. Mesh-under of 6lowpan is 802.15.4
dependent.
But I don't know what is 'aseptic' point to point links.

> routing' is based on that standard?  This brings back to defining what

Ah~ I think we should change the wording. I meant that the
requirements of 6lowpan routing inherit the stringent characterisitcs
of 802.15.4. I will change the text to make it clear. Thanks. :)

> match vs longest-prefix).

Agreed. Either term is okay by me. Just due to the specific
characteristics of 6lowpan configuration,
multi-hop path selection can be achieved in mesh-under. I will ask
others if mesh-under switching is better to be clarified.

> 'followed by'... when reading left to right or reverse?

When I read the text again, it can be confusing. I will try to rephrase it.
6LoPWAN provides compressed or uncompressed IPv6 header.
It just wants to explain the relationship between 6lowpan header and
routing header.
You will get the information from RFC 4944.

> of the fixed Internet network?

6lowpan. I will also try to rephrase it to be clear. thanks. :)

>> IP-based low-power WPAN technology is still in its early stage of
wireless personal area network.
6lowpan = IPv6 over Low power WPAN. But, actually i think it's better
to just use 6LoWPAN, to keep the consistancy of the document.
I will change it.

> What is 'large' and 'dense'?  Is it about physical dimensions?  Or IP

It is about physical dimensions.

> few entries in the routing tables (maybe only 1 per hop).

I fully agree with you. I will discuss woth co-authors and modify the
text, since in the case of appropriate hierarchical addressing
structures, what the text of the draft says may not be true.

> Is the addressing architecture following the Internet model?

can be both, i think. It's dependent on 6lowpan scenario.

> paramount importance deciding whether any type of repeating/bridging

In my view, currently one interface for 15.4, for normal 6lowpan nodes.

> replacing the "2.4GHz" mentioned above)?

it is the central frequency.

> unnecessary duplication such as in broadcast.

multicast may be more efficient. However, 802.15.4 does not support multicast.
for 6lowpan's view, IP multicast is expensive in terms of energy usage
for 6lowpan nodes.

> routing table?  That may be part of 'routing' too.

Good point. :)

> Nit: iy

thanks. ;)

> Then make sure first IP doesn't fragment.

It means 6lowpan packet should not occur fragmentation. text will be
modified to make it clear. thanks.

> Knowing that IP can fragment too.

Yes, I know your argument. :) But it's 6lowpan specific requirement,
and as I know many 6lowpaners are agreed on this one. I got a comment
from one roll routing requirement author that this requirement can be
considered in roll as well. I may make a chance to see you to explain
some detail of 6lowpan before the meeting, if you are interested in?
;)

> convergence time?  The exchange of routing messages?

Erm.. maybe we should consider your comments more deeply. Carles, one
of the authors suggested to remove 'end-to-end' from the text. The
text meant all the mechanisms that are used to perform routing
functions.

> I think all of them are, no?

The text is to explain that simple hop-count is not enough for
6lowpan. There exist Link quality based routing metrics than number of
hops.

> If they have mains power - will they use Power-Line Communications?

Not necessarily. For communication with sensors/actuators, 802.15.4
radio communication is used, but supported by affluent power instead
of small battery..

> Should such a mobile device change its IP address or is it free to

Actually, I don't aware such a case that 6lowpan nodes need to change
the IP address yet.
We just give the example of ROLL documents which are targeting
specific applications, to explain some relavent work.

> 'broadcast' and use multicast instead.

As I explained before, we would like to avoid IP multicast. I will
revise the text to make it clear as 'IP multicast'.

> Sorry, what do you mean?  An IP packet with multiple src fields?

No, it means that  some applications may have multiple sources that
transmit data to one destination; or a single source may transmit data
to several destination nodes; etc.

> relationship to 'IP anycast'?

No. but if IP anycast is used, it will be one way to implement
any-to-any data transfer.

> constrained environments.

The IEEE 802.15.4 specification mandates support of AES. So, it is
given as an example of secure mechanism utilized from 802.15.4
features.

> ND doesn't send Hello messages, but NS, NA, RS and RA.

Ah~ Good point. we will make it clear for the revision.
> link-layer multicast no broadcast.

I don't know if 'link-layer multicast' is a proper term when 802.15.4
does not provide multicast.

> Nit: 'MAC sub-layer' appears only once and in the figure they're

Thanks. we will change it. ;)

Thank you very much to spend your time to review the documents.
We will gather a bit more comments and will soon post the revision
applying your comments.
Your comments are always appreciated. :)

Best Regards,
-eunah

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Feb 2009 15:51:26 +0100

[I cut ROLL from the distribution list, because it seems I post too much
  on the ROLL list]

Thanks for the message.  I mainly agree with you.  I commented on some 
of the text, below.

Eunsook "Eunah" Kim a écrit :
[...]
> I don't know if it answers your question.

If a network running 6LoWPAN routing system (designed according to 
6lowpan-routing-requirements) is connected to the Internet - will 
anything break?

> intention from the question was different from my answer. :)

Yes, thanks for posting rfc4944, I checked it.

Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or 
exact-match (as some VLAN switch protocols do).

Will the 6LoWPAN addressing architecture be local to the network, or 
integrated in the Internet.

How is a link-local scoped solicited node multicast address mapped into 
an 802.15.4 address?

rfc4944 says rightmost 2 bytes go into a 802.15.4 16-bit multicast address.

But rfc4291 says a solicited node multicast address has the rightmost 3 
octets as significant (FF02:0:0:0:0:1:FFXX:XXXX).

Will NS/NA and DAD work ok on these links?

> in 6LoWPAN. A gateway usually have more than one interface (e.g., 15.4

Well a sensor node which is supposed to do routing with only one 
interface will be different than a PC doing routing with two interfaces 
(the typical case).

> First of all, just for your information, draft-ietf-6lowpan-problem-08

Ok, thanks.

>> messages?  Or on the individual act of forwarding a packet?

Ok.

> But I don't know what is 'aseptic' point to point links.

Sorry, I meant 'aseptic' to say point-to-point links over which ND is 
not run actually, no need for ND nor DAD.  They have specific ways in 
which the IPv6 link-local address is formed.  They're often independent 
on the link layer technology.  PPP over IPv6 (RFC) is an example.

> of 802.15.4. I will change the text to make it clear. Thanks. :)

Sure.

> others if mesh-under switching is better to be clarified.

Ok.

> You will get the information from RFC 4944.

Ok.

> 6lowpan. I will also try to rephrase it to be clear. thanks. :)

Sure, it answers my question.

> to just use 6LoWPAN, to keep the consistancy of the document.

Ok, I meant to say WPAN surprisingly appears there first, without 
explanation.

> It is about physical dimensions.

I think Diameter has a physical sense only if it's a circle.  I don't 
think networks have a physical shape of a circle.  I may be wrong though.

> structures, what the text of the draft says may not be true.

Sure, thanks.

> In my view, currently one interface for 15.4, for normal 6lowpan nodes.

This is a distinguishing characteristic, routing with only one interface.

> it is the central frequency.

Ok.

> for 6lowpan's view, IP multicast is expensive in terms of energy usage

Ok.

> text meant all the mechanisms that are used to perform routing

I agree.

> 6lowpan. There exist Link quality based routing metrics than number of

Ok.

> specific applications, to explain some relavent work.

Ok.

> to several destination nodes; etc.

That's much clearer.

> does not provide multicast.

Maybe that's a requirement to put on 802.15.4 not on 6LoWPAN.

I mean it would be difficult to revive the 'broadcast' concept back into 
IPv6 documents, I suppose.

Alex

---

From: Hamid Mukhtar <[email-masked]>
Date: Tue, 17 Feb 2009 02:41:33 +0900

On Mon, Feb 16, 2009 at 11:51 PM, Alexandru Petrescu
<[email-masked]> wrote:
> Thanks for the message.  I mainly agree with you.  I commented on some of the text, below.
>
> If a network running 6LoWPAN routing system (designed according to 6lowpan-routing-requirements) is connected to the Internet - will anything break?
>
> Will the 6LoWPAN router use longest-prefix match (as IP protocols do) or exact-match (as some VLAN switch protocols do).
>
> Will the 6LoWPAN addressing architecture be local to the network, or integrated in the Internet.

RFC4944's HC1 supports both link-local and global addressing i.e. all
128 bits can be carried inline or the elided suffix can be derived
from lower-layers.

The new HC scheme also supports both types of addressing.

>
> How is a link-local scoped solicited node multicast address mapped into an 802.15.4 address?
>
> But rfc4291 says a solicited node multicast address has the rightmost 3 octets as significant (FF02:0:0:0:0:1:FFXX:XXXX).
>

The new HC format can handle this scenario
http://tools.ietf.org/html/draft-ietf-6lowpan-hc

it supports compression of the Solicited-Node Multicast Address
(FF02::1:FFXX:XXXX).

> Well a sensor node which is supposed to do routing with only one interface will be different than a PC doing routing with two interfaces (the typical case).
>
> Sorry, I meant 'aseptic' to say point-to-point links over which ND is not run actually, no need for ND nor DAD.  They have specific ways in which the IPv6 link-local address is formed.  They're often independent on the link layer technology.  PPP over IPv6 (RFC) is an example.
>
> Ok, I meant to say WPAN surprisingly appears there first, without explanation.
>
>>>> a.  Network Properties:
>>>>
> I think Diameter has a physical sense only if it's a circle.  I don't think networks have a physical shape of a circle.  I may be wrong though.
>
> I mean it would be difficult to revive the 'broadcast' concept back into IPv6 documents, I suppose.
>
> Alex
>
>
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

Regards,
Hamid

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Tue, 17 Feb 2009 19:19:17 +0900

Alex,
Thanks again. :) I put my answers in line.

> 6lowpan-routing-requirements) is connected to the Internet - will anything
> break?
>

Basically, no I don't think so. But, I would like to explain two
scenarios to consider.
Let's consider the network like this: (a
6lowpan:A)--(gateway/ER)--(outside ipv6 network:B)

1. mesh-under: every node in A does routing (switching/forwarding/or
other proper term) with
MAC address within A. It is not directly do routing to a node in B.
This mechanism is used for this limited situation,
and many existing sensor networks based on 802.15.4 have been deployed
fitting in the concept.

2. route-over: basically, it should be the same as traditional IPv6
routing, except the gateway
needs to work on compression/decompression of IP/UDP.. headers.

[snip..]
> exact-match (as some VLAN switch protocols do).

In route-over, every intermediate node which performs routing
fucntions is called 6lowpan router.
I didn't see a runing route-over solution for 6LoWPAN yet.
In my opinion, it will use as IP protocols do. (I understand that's
the concept of route-over. I think ROLL people may answer it more
clearly)
In mesh-under, generally, one IPv6 router exists in one 6lowpan.
6lowpan nodes in the lowpan will perform routing functions but not use
IPv6 address. Whole 6lowpan is one IPv6 link, and the IPv6 router of
6lowpan will act as a normal IPv6 router to communicate with other
IPv6 router outside of the 6lowpan, but the functionality for inside
of 6lowpan routing would differ (not use IPv6 addresses).

I would like to know it helps you to understand better.

> integrated in the Internet.

Both are supported. As Hamid already explained, the current 6LoWPAN
format documents (RFC 4944 and HC1) supports both link-local and
global addressing.

>[snip..]
> Sorry, I meant 'aseptic' to say point-to-point links over which ND is not
> run actually, no need for ND nor DAD.  They have specific ways in which the
> IPv6 link-local address is formed.  They're often independent on the link
> layer technology.  PPP over IPv6 (RFC) is an example.
>

Oh, we need ND, and you already know the draft. :)

> I think Diameter has a physical sense only if it's a circle.  I don't think
> networks have a physical shape of a circle.  I may be wrong though.
>

I also need to check. Maybe Carles (one of the co-authors who works on
routing parameters) can answer it? ;)

[snip..]
>>>> relay
Yes, i also think that it's great if 802.15.4 supports link-layer multicast.
As it does not, 6lowpan wants to avoid IP multicast which causes link
broadcast as much as possible.
I should think what else term can be used instead of broadcast if it
is not acceptable termniology.

> Alex

Thanks again for your valuable comments. I'm working on revision to
apply your considerations and comments. :)
I will soon upload it. But please feel free to give your opinion in
any moment. :)

-eunah

-eunah

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 17 Feb 2009 13:56:43 +0100 (CET)

Hi Alex and list,

Just a small comment, adding to Eunah's answers. Please see inline.

[...]

>> think

Sure.

'Large' and 'dense' refer to physical dimensions.

'Network diameter' is actually a term used in graph theory. It refers to
the maximum distance between any two vertices of the graph. In my opinion,
'network diameter' can be thought of from several points of view,
depending on the layer at which the related graph is derived. For
instance, communication between two nodes may be possible through a link,
but depending on the routing strategy, such link may not be found out or
used. Hence, the physical layer graph and the network layer graph may not
be identical.

Thanks Alex for the comment. We will try to address the fact that some of
the mentioned parameters are mainly phisycal ones, while 'network
diameter' may not.

Carles

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Feb 2009 16:27:35 +0100

> The new HC scheme also supports both types of addressing.

I have no doubts the header compression scheme can accommodate both 
global and link-local addresses.

By 'local' I meant also Unique Local IPv6 Unicast Addresses (rfc4193).

The discussion was around how is the IPv6 addressing architecture 
designed for a 6LoWPAN network.

> it supports compression of the Solicited-Node Multicast Address

Ok, thanks for the message, I will check the HC draft.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Feb 2009 16:38:00 +0100

Eunsook "Eunah" Kim a écrit :
> Alex, Thanks again. :) I put my answers in line.
> 
>>>> Some high-level questions: -is there a requirement to connect a
>>>> 6LoWPAN network to the Internet?
>>> The birth of 6LoWPAN is to make the Low-power low rate network
>>> (based on IEEE 802.15.4) look like an IPv6 link.
>>> 
>>> If you only meant routing, the reachability can be achieved by
>>> mesh routing (or mesh switching in your comment below) or
>>> route-over.
>>> 
> scenarios to consider. Let's consider the network like this: (a 
> other proper term) with MAC address within A. It is not directly do
> routing to a node in B. This mechanism is used for this limited
> situation, and many existing sensor networks based on 802.15.4 have
> been deployed fitting in the concept.

Makes sense to me, providfed the 6lowpanA) network is always connected
at the left of that particular gatewayER, never elsewhere.

> routing, except the gateway needs to work on
> compression/decompression of IP/UDP.. headers.

I was not aware of that constraint.  You seem to imply the 'route-over'
capability requires the use of Header Compression.  I will have to check
the HC 6LoWPAN draft.

>> Will the 6LoWPAN router use longest-prefix match (as IP protocols
>> do) or exact-match (as some VLAN switch protocols do).
>> 
> 
> fucntions is called 6lowpan router. I didn't see a runing route-over
> solution for 6LoWPAN yet. In my opinion, it will use as IP protocols
> do. (I understand that's the concept of route-over. I think ROLL
> people may answer it more clearly) In mesh-under, generally, one IPv6
> router exists in one 6lowpan. 6lowpan nodes in the lowpan will
> perform routing functions but not use IPv6 address. Whole 6lowpan is
> one IPv6 link, and the IPv6 router of 6lowpan will act as a normal
> IPv6 router to communicate with other IPv6 router outside of the
> 6lowpan, but the functionality for inside of 6lowpan routing would
> differ (not use IPv6 addresses).

I wouldn't call the route-over 'routing' (or perform routing functions)
if it didn't use IP addresses.  It's confusing.

> 
>> [snip..]
>>>>> On the other hand, the route-over approach relies on IP
>>>>> routing and therefore supports routing over possibly various
>>>>> types of interconnected links (see also Figure 1).
>>>> At several places in the draft, when link 'types', device
>>>> 'types' are mentioned, I'm tempted to believe 6LoWPAN considers
>>>> links other than 802.15.4 links?  Is it so?  Should 6LoWPAN
>>>> routing protocol work also with aseptic point-to-point links? 
>>>> Or are the 'types' limited within the relatively large scope of
>>>> 802.3 compatible MACs (I believe 802.15.4 and 802.16 to fit
>>>> within).
>>>> 
>>> Oh, link 'type'. ;) Currently 6lowpan is clearly based on
>>> 802.15.4, although some talks that 6LoWPAN can run on top of
>>> other radios with similar characteristics. And, for route-over
>>> (as ROLL WG is working on), the benefit which have been insisted
>>> is that the routing mechanism is link-independent. Mesh-under of
>>> 6lowpan is 802.15.4 dependent. But I don't know what is 'aseptic'
>>> point to point links.
>> Sorry, I meant 'aseptic' to say point-to-point links over which ND
>> is not run actually, no need for ND nor DAD.  They have specific
>> ways in which the IPv6 link-local address is formed.  They're often
>> independent on the link layer technology.  PPP over IPv6 (RFC) is
>> an example.
>> 
> 
>>>>> *  Number of Devices, Density and Network Diameter: These
>>>>> parameters usually affect the routing state directly (e.g.
>>>>> the number of entries in a routing table or neighbor list).
>>>>> Especially in large and dense networks, policies must
>>>> What is 'large' and 'dense'?  Is it about physical dimensions?
>>>> Or IP dimensions?
>> I think Diameter has a physical sense only if it's a circle.  I
>> don't think networks have a physical shape of a circle.  I may be
>> wrong though.
>> 
> 
> I also need to check. Maybe Carles (one of the co-authors who works
> on routing parameters) can answer it? ;)
> 
> [snip..]
>>>>> [R18] If the routing protocol functionality includes enabling
>>>>> IP multicast, then it may want to employ coordinator roles,
>>>>> if any, as relay points of group-targeting messages instead
>>>>> of using link-layer multicast (broadcast).
>>> I don't know if 'link-layer multicast' is a proper term when
>>> 802.15.4 does not provide multicast.
> Yes, i also think that it's great if 802.15.4 supports link-layer
> multicast. As it does not, 6lowpan wants to avoid IP multicast which
> causes link broadcast as much as possible. I should think what else
> term can be used instead of broadcast if it is not acceptable
> termniology.

Well, at IEEE 802 link-layer, broadcast means 'ff:ff:ff:ff:ff:ff'
address, whereas multicast means '33:33:0:0:0:X' address.  Anything
different has too many meanings.

I would actually appreciate a lot if this link-layer multicast
requirement went back to IEEE 802.15.4 instead of being addresses in an
IETF draft.  It risks being specified for the sake of specifying it, but
implementations may simply go on and not use neither broadcast nor
multicast.

Just some thoughts.

Alex

---

From: Hamid Mukhtar <[email-masked]>
Date: Wed, 18 Feb 2009 11:44:03 +0900

On Wed, Feb 18, 2009 at 12:27 AM, Alexandru Petrescu
<[email-masked]> wrote:
> I have no doubts the header compression scheme can accommodate both global
> and link-local addresses.
>
> The discussion was around how is the IPv6 addressing architecture designed
> for a 6LoWPAN network.
>

For the 6LoWPAN side the IIDs are derived from the lower-layers. As
per my understanding of 6LoWPAN, the Unique Local Addresses (ULAs) are
not utilised for local communication i.e. for local communication the
addresses are link-local addresses with prefix elided. However, for
communication with nodes outside 6LoWPAN the 6LoWPAN node's prefix can
either be a global prefix or a ULA's prefix.

Regards,
Hamid

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Wed, 18 Feb 2009 11:59:21 +0900

Dear Alex,

There are misunderstanding, so I would like to clarify them.
Thanks.

> capability requires the use of Header Compression.  I will have to check

Oh, no. ROUTING mechanism WON"T require header compression/decompression.
Routing will be included after IP/UDP, or where the routing protocol
is designed in.
I just gave you an example of 6lowpan network to communicate with non-6lowpan.
Just what I want to say was you need decoding 6lowpan_header for the
communication.
It's not the routing role.

>> In route-over, every intermediate node which performs routing fucntions is
>> called 6lowpan router. I didn't see a runing route-over

Mesh-under doesn't use IP address. Route-over uses IP address.
As I understand, Route-over for LoWPAN or LLNs is the same like other
IP based routing.
So far, mesh-under was widely-understood way to make a multi-hop
connection in LoWPAN,
and ROLL was born to make IP based routing for it. So it uses IP
address for routing.

> implementations may simply go on and not use neither broadcast nor

6lowpan is on 802.15.4, and IP multicast will go all nodes in the lowpan
which is energy-expensive for lowpan nodes. Thus, i think
such a restraint of all-nodes receiving packets is necessary to be considered
when we design a solution for lowpan.
And, in my opinion, this is well-agreed issue for 6lowpaners.
(RFC 4944 also mentioned it)
If we avoid to say broadcasting issue,
can you help me to find how we contain such a requirement, based on
IETF conventional way? :)

Thank you much,
-eunah

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 12:39:20 +0100

Hamid Mukhtar a écrit :
>>>> [I cut ROLL from the distribution list, because it seems I post
>>>>  too much on the ROLL list]
>>>> 
>>>> Eunsook "Eunah" Kim a écrit : [...]
>>>>>> Some high-level questions: -is there a requirement to 
>>>>>> connect a 6LoWPAN network to the Internet?
>>>>> Do you mean in terms of routing? Or a general view of 
>>>>> 6LoWPAN? The birth of 6LoWPAN is to make the Low-power low 
>>>>> rate network (based on IEEE 802.15.4) look like an IPv6 link.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> If you only meant routing, the reachability can be achieved 
>>>>> by mesh routing (or mesh switching in your comment below) or
>>>>>  route-over.
>>>>> 
>>>> If a network running 6LoWPAN routing system (designed according
>>>>  to 6lowpan-routing-requirements) is connected to the Internet 
>>>> - will anything break?
>>>> 
>>>>>> -is the 6LoWPAN using addressing architecture and 
>>>>>> longest-prefix match based routing as in the Internet?
>>>>> Although the header compression format is updating in 6lowpan
>>>>>  now, you can find a basic needs of 6lowpan in the RFC. If I
>>>>>  shortly explain, an IPv6 Interface Identifier is obtained 
>>>>> from the 64-bit or 16-bit IEEE 802.15.4 address. The IPv6 
>>>>> link-local address for an IEEE 802.15.4 interface is formed 
>>>>> by appending the Interface Identifier to a certain prefix 
>>>>> (see Section 6 and Section 7 of RFC 4944). With regard to 
>>>>> routing, I understand the answer is 'yes' in the case of 
>>>>> route-over. Please kindly let me know if you already checked
>>>>>  the RFC and your intention from the question was different 
>>>>> from my answer. :)
>>>> Will the 6LoWPAN router use longest-prefix match (as IP 
>>>> protocols do) or exact-match (as some VLAN switch protocols 
>>>> do).
>>>> 
>>> RFC4944's HC1 supports both link-local and global addressing i.e.
>>>  all 128 bits can be carried inline or the elided suffix can be 
>>> derived from lower-layers.
>>> 
> For the 6LoWPAN side the IIDs are derived from the lower-layers.

Ok, but there should be freedom for manual configuration of global
addresses as well.  Or for use of DHCPv6.

> As per my understanding of 6LoWPAN, the Unique Local Addresses (ULAs)
>  are not utilised for local communication i.e. for local 
> communication the addresses are link-local addresses with prefix 
> elided.

Not sure why should the f80 prefix be elided.

> However, for communication with nodes outside 6LoWPAN the 6LoWPAN 
> node's prefix can either be a global prefix or a ULA's prefix.

Well yes, that's a good principle, but rfc4944 seems to be saying only
/64 prefixes are valid (supposedly /56 are not ok).  Which is not good.
  I will comment separately for this RFC.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 18 Feb 2009 14:31:40 +0100

Eunsook "Eunah" Kim a écrit :
> Dear Alex,
> 
> There are misunderstanding, so I would like to clarify them. Thanks.
> 
>>> 2. route-over: basically, it should be the same as traditional 
>>> IPv6 routing, except the gateway needs to work on 
>> I was not aware of that constraint.  You seem to imply the 
>> 'route-over' capability requires the use of Header Compression.  I 
>> will have to check the HC 6LoWPAN draft.
>> 
> 
> Oh, no. ROUTING mechanism WON"T require header 
> compression/decompression. Routing will be included after IP/UDP, or 
> where the routing protocol is designed in. I just gave you an example
>  of 6lowpan network to communicate with non-6lowpan. Just what I want
>  to say was you need decoding 6lowpan_header for the communication. 
>>> fucntions is called 6lowpan router. I didn't see a runing 
>>> route-over solution for 6LoWPAN yet. In my opinion, it will use 
>>> as IP protocols do. (I understand that's the concept of 
>>> route-over. I think ROLL people may answer it more clearly) In 
>>> mesh-under, generally, one IPv6 router exists in one 6lowpan. 
>>> 6lowpan nodes in the lowpan will perform routing functions but 
>>> not use IPv6 address. Whole 6lowpan is one IPv6 link, and the 
>>> IPv6 router of 6lowpan will act as a normal IPv6 router to 
>>> communicate with other IPv6 router outside of the 6lowpan, but 
>>> the functionality for inside of 6lowpan routing would differ (not
>>>  use IPv6 addresses).
>> I wouldn't call the route-over 'routing' (or perform routing 
>> functions) if it didn't use IP addresses.  It's confusing.
>> 
> 
> Mesh-under doesn't use IP address. Route-over uses IP address. As I 
> understand, Route-over for LoWPAN or LLNs is the same like other IP 
> based routing. So far, mesh-under was widely-understood way to make a
>  multi-hop connection in LoWPAN, and ROLL was born to make IP based 
> routing for it. So it uses IP address for routing.

I think we're in principle in agreement on this one.

>>> [snip..]
>>>>>>> [R18] If the routing protocol functionality includes 
>>>>>>> enabling IP multicast, then it may want to employ 
>>>>>>> coordinator roles, if any, as relay points of 
>>>>>>> group-targeting messages instead of using link-layer 
>>>>>>> multicast (broadcast).
>>>  multicast. As it does not, 6lowpan wants to avoid IP multicast 
>>> which causes link broadcast as much as possible. I should think 
>>> what else term can be used instead of broadcast if it is not 
>>> acceptable termniology.
>> requirement went back to IEEE 802.15.4 instead of being addresses 
>> in an IETF draft.  It risks being specified for the sake of 
>> specifying it, but implementations may simply go on and not use 
>> neither broadcast nor multicast.
>> 
>> Just some thoughts.
>> 
>> Alex
>> 
> 
> 6lowpan is on 802.15.4, and IP multicast will go all nodes in the 
> lowpan which is energy-expensive for lowpan nodes.

You mean broadcast (not multicast)?

Broadcast may happen as you say: a broadcast message goes to all nodes
in the lowpan.  But multicast happens differently: the multicast message
goes only to the nodes having previously subscribed for it.

The same multicast concept is valid for link-layer and for IP.

In this sense, multicast may be less energy-intensive than broadcast.

I can understand 802.15.4 doesn't provide link-layer multicast, but I
can't understand why.

> Thus, i think such a restraint of all-nodes receiving packets is
> necessary to be considered when we design a solution for lowpan. And,
> in my opinion, this is well-agreed issue for 6lowpaners. (RFC 4944
> also mentioned it)

I think there may be a misunderstanding with rfc4944.  It is not clear
in rfc4944 whether or not link-layer multicast is available or not in
802.15.4, and whether the rfc4944 adaptation layer provides link-layer
multicast or not, to the IPv6 stack.

> If we avoid to say broadcasting issue, can you help me to find how we
>  contain such a requirement, based on IETF conventional way? :)

Sorry, I don't know precisely :-)

First, I am trying to identify whether a conventional IEEE 802.3
multicast-capable MAC is specified to run somehow over IEEE 802.15.4.

And if yes, then maybe that is all that is needed for an IPv6 stack
running over 802.15.4 links, by reusing more of the rfc2464
IPv6-over-Ethernet.

If not, and if 802.15.4 doesn't want to specify the link-layer multicast
behaviour, then maybe the adaptation layer would specify the link-layer
multicast behaviour.

In all this, I think a liaison person to IEEE 802.15.4 group could
provide advice.  Maybe that person is already determined.

Until a working link-layer multicast behaviour is specified for 802.15.4
links, ND can only work as ptp link.  And DHCPv6, SLAAC (stateless 
autoconf) and OSPF too - only ptp links.

Alex