Subject: Re: [6lowpan] 6lowpan routing and subnets (was: 6lowpan-ND vs. ROLL)

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Apr 2009 20:39:49 +0200

Switched to 6lowpan from ROLL...

Carsten Bormann a écrit :
[...]
> (If you think that routing within a subnet is not something that 
> immediately comes to mind when hearing "route-over", I'm with you,
> but again that is the current terminology.)

TErminology may be so, but I haven't agreed with it, and I believe it
could be subject to change when there's a couple of different queriers.

>>> With the backhaul model, in a mesh under network the link and
>>> subnet are equivalent as the link spans the entire LoWPAN.
>> 
>> But do you mean when there's no backhaul model
> 
> (I don't tend to think about the case where there is no Edge Router
> -- is that what you mean?)

I meant when there _is_ an ER and the entire "subnet" covers both the
wireless lowpan nodes _and_ the wired ER interfaces.  That's what the ND
doc says, that there's a single "subnet" for both.  In this case, ER and
6lowpan nodes doing "IP routing" within a single subnet is difficult to
understand to me.

>> the link and subnet are not equivalent?
> 
> In a pure mesh-under world (which the cited text is talking about),
> they are equivalent -- making them equivalent is exactly the job of a
> full mesh-under protocol. In a route-over world (with or without
> embedded mesh-under islands), they aren't.

It's strange...

>>> In this document, a LoWPAN subnet is defined to be a collection
>>> of LoWPAN links interconnected by routers that have the same
>>> subnet prefix.
>> 
>> Let's exemplify collection with two members:
>> 
>> How does a router connect two links, yet has a single interface,
>> and has the same subnet prefix on both (on both "what")?
> 
> ("Two links" sounds as if the extent of a "link" is independent from
>  one's point of view, which in a radio network it isn't.  A 6lowpan
> node typically has exactly one interface and thus one link.)

MAC layers should offer a link abstraction to the IP stack.  I could
have two WiFi APs in a room, all radio hear each other, yet there are
different IP links, allowing to build a typical IP subnet on each such link.

> By making the on-link decision (i.e., L2-address the host via ND vs.
>  L2-address the next-hop router via the routing protocol) based on
> the routing information instead of just using the prefix.

A routing protocol based on L2 addresses... is it an IP routing protocol?

>> Is that a dumb repeater?
> 
> No.  Forwarding of a packet received is based on L2 address matching
>  (possibly followed by reassembly) followed by a consultation of the
> L3 FIB.

I get the first part "forwarding based on MAC address exact match" but
if forwarding is done so then why consulting the L3 FIB?

>> Is that an application-layer (UDP) repeating all packets it
>> receives? (no routing table entry, only one interface).
> 
> No.  The forwarding is at L3, e.g., no interpretation of IPv6
> fragment headers or destination options headers is involved in the
> forwarding.

But you said above the forwarding is based on L2 address matching, thus
not at L3... I'm sure there's a logic in what you said, and I may have
missed something by too much dissection.

But it would be very helpful to make a picture about a single-interface
router presented with a packet in input, name the examined field, name
the type of search (exact match?) and name a typical entry in that table.

Alex

---

From: Zach Shelby <[email-masked]>
Date: Sat, 11 Apr 2009 15:21:17 +0300

Thread moved to 6lowpan... diverging into ND ;-)

Alexandru Petrescu wrote:
> Zach Shelby a écrit :
>> Hi,
>>
>> Alexandru Petrescu wrote:
>>> Richard Kelsey a écrit :
>>>> From: Carsten Bormann <[email-masked]> Date: Fri, 10 Apr 2009
>>>> 19:00:42 +0200
>>>>
>>>> (I don't tend to think about the case where there is no Edge
>>>> Router -- ...)
>>>>
>>>> I have a question on this, stemming from my lack of familiarity
>>>> with the details of IP routing.
>>>>
>>>> Suppose I have a 6LowPAN/ROLL network being used for energy 
>>>> management in a home.  The network includes the electric meter,
>>>> which has a backhaul connection back to the utility. The utility,
>>>> being very protective of its backhaul network, has a firewall in
>>>> the meter to keep out everything except the utility's own
>>>> traffic.   Given the presence of the firewall, does it still make
>>>> sense to use the meter as an Edge Router?
>>>
>>> I don't think it would make much sense because Edge Router as 
>>> currently specified by 6LoWPAN ND seems to not be doing any routing
>>> at all - but a sort of bridging, and firewalls are very much rules
>>> on the IP fields, and less if at all rules on the MAC fields.
>>
>> That is not true. In 6LoWPAN the edge router is an IP router just
>> like any other, and is a natural place to use a firewall.
> 
> Yes, but, pictorially speaking:
> 
>                   |egress(backbone)            \
>                 ------                          |
>                | ER   |                         |
>                 ------                           > single IPv6 subnet
>                   |ingress                      |
>                  o  o                           |
>                o   o  (lowpan nodes)           /
> 
> ND doc:
>> This document also specifies the seamless integration of an extended 
>> LoWPAN and multiple edge routers on a shared backbone link (e.g. 
>> Ethernet) to form a single IPv6 subnet.
> 
> The ND document says that ER egress interface and the LoWPAN nodes form
> a single subnet - that is not a typical router.  A typical router is
> connected to two or more different subnets.

Actually, that is only a special case that occurs with an Extended 
LoWPAN with multiple ERs interconnected by a common backbone link.

In the simple LoWPAN case the LoWPAN subnet only covers the 6lowpan 
interfaces and not the egress. Therefore in this example it works 
exactly like a standard CPE.

Even in the Extended LoWPAN case you will have route table entries for 
destinations in the LoWPAN maintained by some routing algorithm (e.g. 
ROLL). There is no reason why you can't use a firewall there either.

Anyways, this stuff doesn't need to be completely "typical". I mean we 
are not installing an F-Secure firewall on a Windows PC here. These are 
application-specific embedded devices most of the time. You can use an 
embedded Linux box with Linux firewall features to achieve a 6LoWPAN 
Edge Router. Of course the 6lowpan wireless interface driver and ER 
features need to be implemented.

- Zach

> In this sense, it's difficult to consider ER to be a typical router
> doing a typical firewall.
> 
> Alex
> 
> 

-- 
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: Richard Kelsey <[email-masked]>
Date: Sat, 11 Apr 2009 13:48:08 -0400

Date: Sat, 11 Apr 2009 15:21:17 +0300
   From: Zach Shelby <[email-masked]>

   >>>> From: Carsten Bormann <[email-masked]> Date: Fri, 10 Apr 2009

   [Is an Edge Router an IP router? ... Yes.]

In the network I was describing, the meter has no more
horsepower than the other devices on the network.  It has a
small micro with around 4k of RAM.  It certainly isn't
something as powerful as an embedded Linux box.  Is it
unreasonable to expect it to act as an Edge Router?  If not,
how should its connection between the LowPAN and the utility
backhaul be handled?
                               -Richard Kelsey

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 11 Apr 2009 11:19:42 -0700

Hi Richard,

If both egress routers are advertising default routes, then I see no  
problem with the stub network deciding which to choose. If they have  
different costs, then definitely the two should be advertising  
different costs. If the meter network only wants to accept traffic to  
a particular prefix, then it should only be advertising that.

I do think we need to better define what exactly is an Edge Router in  
and out of a 6lowpan context. In general, I think of an Edge Router as  
nothing more than a router that routes between an L2N network to a non- 
L2N network. In the 6lowpan context, we typically associate an Edge  
Router with one that also maintains the "whiteboard" for nodes in the  
6lowpan network. However, I'm not sure we need to bind them together.

Specific to the 6LoWPAN ND draft, you do bring up an important case -  
one where two or more Edge Routers are not connected by a "backbone"  
network. I think there are interesting questions there that are not  
dealt with in the current 6LoWPAN ND draft (e.g. how is the whiteboard  
information distributed between edge routers if at all? can we have a  
particular whiteboard specific for a prefix maintained at only the  
Edge Router that advertises that prefix? do whiteboards have to be  
maintained at edge routers?). We should probably open a new thread on  
this topic in the 6LoWPAN ML...

--
Jonathan Hui

On Apr 10, 2009, at 1:01 PM, Richard Kelsey wrote:

>   From: Carsten Bormann <[email-masked]>
>   Date: Fri, 10 Apr 2009 19:00:42 +0200
>
>   (I don't tend to think about the case where there is no
>    Edge Router -- ...)
>
> I have a question on this, stemming from my lack of
> familiarity with the details of IP routing.
>
> management in a home.  The network includes the electric
> meter, which has a backhaul connection back to the utility.
> The utility, being very protective of its backhaul network,
> has a firewall in the meter to keep out everything except
> the utility's own traffic.  Given the presence of the
> firewall, does it still make sense to use the meter as an
> Edge Router?
>                            -Richard Kelsey
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Zach Shelby <[email-masked]>
Date: Sun, 12 Apr 2009 13:42:49 +0300

Hi,

Thread now on 6lowpan only.

Jonathan Hui wrote:
> different costs, then definitely the two should be advertising different 
> costs. If the meter network only wants to accept traffic to a particular 
> prefix, then it should only be advertising that.

Agreed.

> nothing more than a router that routes between an L2N network to a 
> non-L2N network. In the 6lowpan context, we typically associate an Edge 

Yep, I agree it needs to be a generic term usable in both 6LoWPAN and IP 
contexts (e.g. in roll).

Proposal 1: We call it an Access Router (AR) and agree to share that 
term with ROLL. An AR is simply a router that routes between L2N and 
non-L2N networks.

Proposal 2: We define Whiteboard as an additional feature that SHOULD be 
implemented in an Access Router but MAY be implemented on any other node 
in the network (e.g. in the ad-hoc LoWPAN case).

> particular whiteboard specific for a prefix maintained at only the Edge 
> Router that advertises that prefix? do whiteboards have to be maintained 
> at edge routers?). We should probably open a new thread on this topic in 
> the 6LoWPAN ML...

The Whiteboard is specific to a LoWPAN (= a prefix). Whiteboard 
information is not distributed between different LoWPANs (there is no 
point). In an extended LoWPAN multiple whiteboards on ARs are part of 
the same LoWPAN (same prefix) and use a backbone link to perform DAD and 
claim/defend node addresses across the whole LoWPAN.

A Whiteboard does not need to be located at an AR, but it is a logical 
place in most cases. In the Extended LoWPAN case the whiteboard needs to 
be located on nodes which have a shared backbone link (usually ARs).

We discuss that a little in the ND draft but I think it can be expanded 
to make that clear with an example.

- Zach

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

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 12 Apr 2009 20:08:26 +0200

Zach Shelby a écrit :
>> If both egress routers are advertising default routes, then I see 
>> no problem with the stub network deciding which to choose. If they 
>> have different costs, then definitely the two should be advertising
>>  different costs. If the meter network only wants to accept traffic
>>  to a particular prefix, then it should only be advertising that.
> 
> Agreed.
> 
>> I do think we need to better define what exactly is an Edge Router 
>> in and out of a 6lowpan context. In general, I think of an Edge 
>> Router as nothing more than a router that routes between an L2N 
>> network to a non-L2N network. In the 6lowpan context, we typically 
>> associate an Edge Router with one that also maintains the 
>> "whiteboard" for nodes in the 6lowpan network. However, I'm not 
>> sure we need to bind them together.
> 
> Yep, I agree it needs to be a generic term usable in both 6LoWPAN and
>  IP contexts (e.g. in roll).
> 

I agree with the term AR, and it simply routes between L2N and non-L2N
networks.  In this sense it would (1) no longer state its egress and the
L2N interface share the same IPv6 subnet (as the current 6lowpan ND
document states) and (2) would need a definition at least distinguishing
it from the AR of rfc3753 "mobility terminology".

> Proposal 2: We define Whiteboard as an additional feature that SHOULD
>  be implemented in an Access Router but MAY be implemented on any 
> other node in the network (e.g. in the ad-hoc LoWPAN case).

I'm interested in the 'whiteboard' conceptual data structure.

>> Specific to the 6LoWPAN ND draft, you do bring up an important case
>>  - one where two or more Edge Routers are not connected by a 
>> "backbone" network. I think there are interesting questions there 
>> that are not dealt with in the current 6LoWPAN ND draft (e.g. how 
>> is the whiteboard information distributed between edge routers if 
>> at all? can we have a particular whiteboard specific for a prefix 
>> maintained at only the Edge Router that advertises that prefix? do 
>> whiteboards have to be maintained at edge routers?). We should 
>> probably open a new thread on this topic in the 6LoWPAN ML...
> 
>  point). In an extended LoWPAN multiple whiteboards on ARs are part 
> of the same LoWPAN (same prefix) and use a backbone link to perform 
> DAD and claim/defend node addresses across the whole LoWPAN.
> 
> A Whiteboard does not need to be located at an AR, but it is a 
> logical place in most cases. In the Extended LoWPAN case the 
> whiteboard needs to be located on nodes which have a shared backbone 
> link (usually ARs).
> 
> We discuss that a little in the ND draft but I think it can be 
> expanded to make that clear with an example.

YEs, 'whiteboard' is presented at length in the ND draft.  Reading it 
let me represent what I understand:

One entry in the whiteboard is for one unique node, and contains these 
fields:

IPv6 Prefix
IPv6 address1(128bit)
IPv6 address2(128bit)
Interface ID (64bit)
Owner Interface Identifier(64bit)
Transaction ID1 (16bit)
Transaction ID2 (16bit)
Transaction ID3 (16bit)
Transaction ID4 (16bit)
Lifetime(32bit)

I've put an entry "IPv6 Prefix" because you mentioned it above, and 
makes sense to have a unique prefix for all nodes in the lowpan, be it a 
subnet.  But it would be helpful to say whether it is a 'prefix length' 
attached to the IPv6 address1/2 fields below it, or is it an independent 
bitstring (of what length?), etc.

There are two IPv6 addresses in each entry because the draft says 
whiteboard is similar to a MIPv6 Binding Cache, which has 2, but I'm not 
sure this was the intention.

Also the draft says that the node may have several addresses, but I'm 
not sure the intention to have n IPv6 addresses in each entry - or is it?

Also there's an IID and an OII, but I doubt the intention is to have two 
  64bit identifiers.

At times it is _implied_ that a MAC address could be in the whiteboard, 
but it is not clear whether yes or no, and whether a 48bit address or a 
16bit 'short' address.

I think this could be clarified further.  I personally see the en entry 
in the whiteboard conceptual data structure to contain only the following:

IPv6 address
Prefix length
MAC short address
MAC address
lifetime
TID1
TID2
TID3
TID4

Alex

---

From: Jonathan Hui <[email-masked]>
Date: Sun, 12 Apr 2009 11:26:19 -0700

Hi Zach,

On Apr 12, 2009, at 3:42 AM, Zach Shelby wrote:
> information is not distributed between different LoWPANs (there is  
> no point). In an extended LoWPAN multiple whiteboards on ARs are  
> part of the same LoWPAN (same prefix) and use a backbone link to  
> perform DAD and claim/defend node addresses across the whole LoWPAN.

Be careful about your definition of a "LoWPAN". Just because a LoWPAN  
is defined by a single prefix doesn't mean that a PAN cannot support  
multiple prefixes.

In Richard's case, I see two different Access Routers *not* connected  
over a backbone but advertise different prefixes to the same PAN.  
Nodes in the PAN may be multihomed and configure addresses for the two  
different networks. If we define a whiteboard to manage addresses for  
a particular prefix, then we have two whiteboards and let's assume  
that each resides at their respective advertising Access Router. I  
think there's an open question as to how RRs are sent - in particular,  
how does an RR get sent to the appropriate whiteboard? This is not  
considered in the current ND draft.

> expanded to make that clear with an example.

I do think we need to be more clear. The draft is confusing because it  
makes concrete statements like: "The edge router maintains a  
whiteboard of all hosts in the network." There's a bunch of  
assumptions that can be made from this statement. The obvious is that  
the whiteboard is located at an edge router. Another is that the  
whiteboard is not bound to a particular prefix, but maintains  
information for all hosts.

--
Jonathan Hui

> This e-mail and all attached material are confidential and may  
> contain legally privileged information. If you are not the intended  
> recipient, please contact the sender and delete the e-mail from your  
> system without producing, distributing or retaining copies thereof.

---

From: Zach Shelby <[email-masked]>
Date: Mon, 13 Apr 2009 09:16:53 +0300

Hi,

Jonathan Hui wrote:
>>> dealt with in the current 6LoWPAN ND draft (e.g. how is the 
>>> whiteboard information distributed between edge routers if at all? 
>>> can we have a particular whiteboard specific for a prefix maintained 
>>> at only the Edge Router that advertises that prefix? do whiteboards 
>>> have to be maintained at edge routers?). We should probably open a 
>>> new thread on this topic in the 6LoWPAN ML...
>>
>> the same LoWPAN (same prefix) and use a backbone link to perform DAD 
>> and claim/defend node addresses across the whole LoWPAN.
> 
> Be careful about your definition of a "LoWPAN". Just because a LoWPAN is 
> defined by a single prefix doesn't mean that a PAN cannot support 
> multiple prefixes.

I agree completely. You can have several LoWPANs (L3 concept) running 
over the same PAN (L2 concept specific to IEEE 802.15.4).

> over a backbone but advertise different prefixes to the same PAN. Nodes 
> in the PAN may be multihomed and configure addresses for the two 
> different networks. If we define a whiteboard to manage addresses for a 
> particular prefix, then we have two whiteboards and let's assume that 
> each resides at their respective advertising Access Router. I think 
> there's an open question as to how RRs are sent - in particular, how 
> does an RR get sent to the appropriate whiteboard? This is not 

Yep, this will be a common case. A router will need to specifically 
choose which LoWPAN it wants to advertise routes for so it is 
advertising a consistent prefix information set of context IDs. This way 
a host can choose which LoWPAN to participate in by choosing the router 
advertising that prefix. Hosts could then multihome as you suggest. Yes, 
we need to discuss that in the draft more. As the draft is now we don't 
have sufficient information advertised in RAs to allow routers to 
advertise prefixes for multiple LoWPANs simultaneously.

>> place in most cases. In the Extended LoWPAN case the whiteboard needs 
>> to be located on nodes which have a shared backbone link (usually ARs).
>>
> makes concrete statements like: "The edge router maintains a whiteboard 
> of all hosts in the network." There's a bunch of assumptions that can be 
> made from this statement. The obvious is that the whiteboard is located 
> at an edge router. Another is that the whiteboard is not bound to a 
> particular prefix, but maintains information for all hosts.

Agreed. Will make a ticket for this.

>> please contact the sender and delete the e-mail from your system 
>> without producing, distributing or retaining copies thereof.
> 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 13 Apr 2009 10:24:16 -0400

Date: Mon, 13 Apr 2009 09:16:53 +0300
   From: Zach Shelby <[email-masked]>

   > defined by a single prefix doesn't mean that a PAN cannot support 

   I agree completely. You can have several LoWPANs (L3 concept)
   running over the same PAN (L2 concept specific to IEEE 802.15.4).

This would seem to put the hop-by-hop PAN routing in L2 in
order to allow full use of the wireless mesh.  This would be
problematic.  The alternative is to have L3 keep track of
LoWPAN and PAN addressing and routing separately in order to
allow use of a next hop in one LowPAN when routing to a
destination in a different LowPAN.

                                 -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 13 Apr 2009 10:40:29 -0400

From: Jonathan Hui <[email-masked]>
   Date: Sun, 12 Apr 2009 11:26:19 -0700

   that each resides at their respective advertising Access Router.

Ouch.  I have been worrying about where to find the space to
store one whiteboard and now there are two.  Does the
whiteboard have to be on a LoWPAN device or can it be on
some other router reachable via a backhaul network?

                                     -Richard Kelsey

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 13 Apr 2009 07:41:42 -0700

Hi Richard,

> destination in a different LowPAN.

The current definition of LoWPAN is simply a collection of interfaces  
in the same PAN that are assigned addresses with the same prefix. It  
doesn't have anything to do with the definition of a link. As such, a  
LoWPAN can consist of either a mesh-under or route-over configuration.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 13 Apr 2009 07:46:27 -0700

Hi Richard,

> some other router reachable via a backhaul network?

In the current 6LoWPAN ND model, there needs to be a whiteboard entry  
for every IPv6 address assigned to an interface in the PAN. That's  
true whether or not the information is spread across one or multiple  
white boards. If you're worried about code space, then yes, of course,  
that part is duplicated. But if you want the network to function with  
Access Router A or Access Router B or both and the whiteboard is  
located at an Access Router, then both have to implement it any way.

The 6LoWPAN ND model does support a Relay option. There's a question  
of whether or not there can be multiple Relay hops. If we did that,  
then this would start to look awfully close to DHCPv6.

--
Jonathan Hui

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 13 Apr 2009 08:00:23 -0700

This is  very interesting and relevant question.
In the scenario given, the utility side of the meter is likely a mesh also, 
and it needs to be isolated from the home side (we're using SUN and HAN to 
describe these two - Smart Utility Network and Home Area Network - in the 
context of 802.15.4 work).  The general desire of the utility to maintain a 
secure SUN is one reason, and the general desire of consumers to keep their 
HAN private is another (and the general 'we don't want a ninth grader with a 
laptop crashing the grid' concern may figure in, too ;-).   From either 
perspective the meter forms an "edge" from the point of view as 
entrance/egress between two logically separate networks. As pointed out, 
this is still a resource constrained device (although in some 
implementations it is has a bit more to play with than a typical thermostat 
or light dimmer).

On the SUN side mesh the meter is keeping track only of it's adjacent 
neighbors; on the HAN there are likely fewer neighbors, in the home 
situation. But consider the same situation in an industrial context, where 
you have the same need for the in-prem network to be separated from the 
utility side, but the in-prem mesh might be thousands of nodes.  I would 
expect again that the meter/gateway is keeping track only of adjacent 
neighbors.   This is what we see happening now.

Not sure if that helps in the discussion, so FWIW.
-Ben

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 13 Apr 2009 12:30:24 -0400

From: Jonathan Hui <[email-masked]>
   Date: Mon, 13 Apr 2009 07:46:27 -0700

   > some other router reachable via a backhaul network?

   The 6LoWPAN ND model does support a Relay option. There's
   a question of whether or not there can be multiple Relay
   hops. If we did that, then this would start to look
   awfully close to DHCPv6.

Given the limited RAM available on typical 6LoWPAN devices,
it would be nice if the whiteboard could either be on a
router reached via a backhaul network or stored in a
distributed fashion on the LoWPAN itself.  I am not familiar
enough with the issues involved to have a sense of the
possibilities or implications of either of these approaches.
Both would seem to add significant complexity.

                              -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 14 Apr 2009 18:16:59 +0200

Hi Benjamin:

Seems that the SUN should be protected at L2 and the HAN would not possess the appropriate keys, is that right? If so the SUN and HAN would operate as 2 different networks in ship in the night wouldn't they? 

That's how I'd expect it in the industrial space with 2 different profiles. In fine what we see is that the security really defines what a PAN is and the network boundaries.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Benjamin A. Rolfe
>Sent: lundi 13 avril 2009 17:00
>To: [email-masked]

---

From: "Robert Assimiti" <[email-masked]>
Date: Mon, 20 Apr 2009 19:16:26 -0400

Hello,

I was going over the second spin of Draft-IETF-6lowpan-usercases.

I am a bit unclear on the definition of the LoWPAN link. A LoWPAN Link is coined as:

“A low-power wireless link which is shared by a link-local scope in a LoWPAN. In a LoWPAN, a link can be a very instable set of nodes, for instance the set of nodes that can receive a packet

that is broadcast over the air in a route over LoWPAN, or the set of nodes currently reachable in an L2 mesh in a mesh under LoWPAN. Such a set may vary from one packet to the next 

as the nodes move or as the radio propagation conditions change.”

It is clear that we are targeting point-to-point and point-to-multipoint here, but there is nothing that indicates the directionality of the link. 

Is the definition here (since it is a wireless context) considered unidirectional or bi-directional? 

Also, the definition given in RFC4861 does not really apply here.

 Thanks for anyone that could offer a clarification.

"The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum 

Robert Assimiti

Executive Staff Engineer

Office: [678]-202-6859

Mobile: [404]-578-0205

[email-masked]

This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Apr 2009 17:12:39 +0200

Hi Robert, let me give my oppinion on this.

Robert Assimiti a écrit :
> /“//A low-power wireless link which is shared by a link-local scope in a 
> LoWPAN. In a LoWPAN, a link can be a very instable set of nodes, for 
> instance the set of nodes that can receive a packet/
> /that is broadcast over the air in a route over LoWPAN, or the set of 
> nodes currently reachable in an L2 mesh in a mesh under LoWPAN. Such a 
> set may vary from one packet to the next /
> /as the nodes move or as the radio propagation conditions change.”/
> 
> It is clear that we are targeting point-to-point and point-to-multipoint 
> here, but there is nothing that indicates the directionality of the link.

I am not sure what you mean being clear we're targetting ptp and 
pt-to-mpt links...

I am aware ROLL WG targets the point-to-multipoint types of traffic (not 
the links).

I think 802.15.4 link may be a point-to-point link, or a 'star' 
topology, which one may interpret as being a point-to-multipoint link.

Whereas I understand very well running IP over a point-to-point link, I 
don't see how would it run over a point-to-multipoint link, never saw 
this before.

As for the link-local scope mentioned in the paragraph above, I think it 
comes from what a "link-local scope" is for link like an Ethernet link. 
  But, it is not clear at all what a link-local scope would be on a 
802.15.4 star topology made of a point-to-multipoint link: would a 
packet sent by the center reach all edges?  Or only one?  Would a packet 
from an edge to another have a dst address the center or the edge?  Two 
dst addresses?

I prefer to think that a LoWPAN subnet is covered by an IP link-local 
scope, has at least one single IPv6 subnet prefix; and that IP packets 
addressed to a link-local IPv6 address reaches all nodes in the LoWPAN, 
without being 'IP-forwarded'.

If such LoWPAN subnet sit on a 802.15.4 link then that 802.15.4 link 
should offer link-layer multicast support to the LoWPAN subnet, such 
that the words "link-local scope" to have a meaning for a 802.15.4-based 
LoWPAN.  This is not the case today.

> unidirectional or bi-directional?

This is a good  question.  I do suppose 6LoWPAN WG uses links which are 
bidirectional and symmetric.

Alex

> *"The nice thing about standards is that there are so many to choose 
> from." - Andrew S. Tanenbaum *
> 
> *Robert Assimiti*
> 
> *Executive Staff Engineer*
> 
> *Office: [678]-202-6859*
> 
> *Mobile: [404]-578-0205*
> 
> [email-masked]*
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> This e-mail (including any attachments to it) is confidential, 
> proprietary, legally privileged, subject to copyright and is sent for 
> the personal attention of the intended recipient only. If you have 
> received this e-mail in error, please reply to advise us immediately, 
> delete it and destroy any printed copies of it. You are notified that 
> reading, disclosing, copying, distributing or taking any action in 
> reliance on the contents of this information is strictly prohibited. No 
> employee is authorized to conclude any binding agreement on behalf of 
> NIVIS LLC with another party by e-mail without express written 
> confirmation by an officer of the company. Although we have taken 
> reasonable precautions to ensure no viruses are present in this e-mail, 
> we cannot accept responsibility for any loss or damage arising from the 
> viruses in this e-mail or attachments.
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Robert Assimiti" <[email-masked]>
Date: Wed, 22 Apr 2009 16:19:44 -0400

Hello Alex. I think this definition needs to be revised in order to accommodate not only the context of a 802.15.4 PAN but also the context of wireless subnets in general.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Wednesday, April 22, 2009 11:13 AM
To: Robert Assimiti
Cc: [email-masked]
Subject: Re: [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02-

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Apr 2009 15:52:40 +0200

Robert Assimiti a écrit :
> Hello Alex. I think this definition needs to be revised in order to
> accommodate not only the context of a 802.15.4 PAN but also the
> context of wireless subnets in general.

I agree.  The definition in question is the following:

>    LoWPAN Link
> 
>       A low-power wireless link which is shared by a link-local scope in
>       a LoWPAN.  In a LoWPAN, a link can be a very instable set of
>       nodes, for instance the set of nodes that can receive a packet
>       that is broadcast over the air in a route over LoWPAN, or the set
>       of nodes currently reachable in an L2 mesh in a mesh under LoWPAN.
>       Such a set may vary from one packet to the next as the nodes move
>       or as the radio propagation conditions change.

At least the formulation "link shared by a link-local scope" is 
confusing.  Maybe a "link connecting nodes  which are part of the same 
link-local scope"(?)

Then it says "broadcast over the air in a route over LoWPAN" which is 
less understandable again...

Then there are more definitions which are less understandable.  The 
Route Over is some of the less clear:

>    Mesh Under
> 
>       A LoWPAN configuration where the link-local scope is defined by
>       the boundaries of the LoWPAN and includes all nodes within.
>       Forwarding and multihop routing functions are achieved at L2
>       between mesh nodes.
> 
>    Route Over
> 
>       A LoWPAN configuration where the link-local scope is defined by
>       those nodes reachable over a single radio transmission.

What is a single radio transmission?  Is it that non-link-local scope 
implies several radio transmissions?

> Due to the time-varying characteristics of wireless communication,
> the neighbor set may change over time even when nodes maintain the 
> same physical locations. 

Excuse-me but I really don't understand this: time-varying 
characteristics of wireless communications - do you mean TDD?

 > Route Over [...] Multihop is achieved using IP routing.

Multihop with IP routing means also that the router forwards between two 
different links (each with its own link-local scope).  However, the 
"Route Over" definition above uses a single link-local scope.

I'll write separately about mesh under.

Alex

> 
> 
> 
> -----Original Message----- From: Alexandru Petrescu
> [mailto:[email-masked]] Sent: Wednesday, April 22, 2009
> 11:13 AM To: Robert Assimiti Cc: [email-masked] Subject: Re:
> [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02-
> 
>> /“//A low-power wireless link which is shared by a link-local scope
>> in a LoWPAN. In a LoWPAN, a link can be a very instable set of
>> nodes, for instance the set of nodes that can receive a packet/ 
>> /that is broadcast over the air in a route over LoWPAN, or the set
>> of nodes currently reachable in an L2 mesh in a mesh under LoWPAN.
>> Such a set may vary from one packet to the next / /as the nodes
>> move or as the radio propagation conditions change.”/
>> 
>> It is clear that we are targeting point-to-point and
>> point-to-multipoint here, but there is nothing that indicates the
>> directionality of the link.
> 
> I am aware ROLL WG targets the point-to-multipoint types of traffic
> (not the links).
> 
> Whereas I understand very well running IP over a point-to-point link,
> I don't see how would it run over a point-to-multipoint link, never
> saw this before.
> 
> As for the link-local scope mentioned in the paragraph above, I think
> it comes from what a "link-local scope" is for link like an Ethernet
> link. But, it is not clear at all what a link-local scope would be on
> a 802.15.4 star topology made of a point-to-multipoint link: would a
>  packet sent by the center reach all edges?  Or only one?  Would a
> packet from an edge to another have a dst address the center or the
> edge?  Two dst addresses?
> 
>  scope, has at least one single IPv6 subnet prefix; and that IP
> packets addressed to a link-local IPv6 address reaches all nodes in
> the LoWPAN, without being 'IP-forwarded'.
> 
>  that the words "link-local scope" to have a meaning for a
> 802.15.4-based LoWPAN.  This is not the case today.
> 
> This is a good  question.  I do suppose 6LoWPAN WG uses links which
> are bidirectional and symmetric.
> 
> Alex
> 
>> 
>> 
>> *"The nice thing about standards is that there are so many to
>> choose from." - Andrew S. Tanenbaum *
>> 
>> *Robert Assimiti*
>> 
>> proprietary, legally privileged, subject to copyright and is sent
>> for the personal attention of the intended recipient only. If you
>> have received this e-mail in error, please reply to advise us
>> immediately, delete it and destroy any printed copies of it. You
>> are notified that reading, disclosing, copying, distributing or
>> taking any action in reliance on the contents of this information
>> is strictly prohibited. No employee is authorized to conclude any
>> binding agreement on behalf of NIVIS LLC with another party by
>> e-mail without express written confirmation by an officer of the
>> company. Although we have taken reasonable precautions to ensure no
>> viruses are present in this e-mail, we cannot accept responsibility
>> for any loss or damage arising from the viruses in this e-mail or
>> attachments.
>> 
>> 
>> _______________________________________________ 6lowpan mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>> 
> 
> 
> 
> 
> reliance on the contents of this information is strictly prohibited.
> No employee is authorized to conclude any binding agreement on behalf
> of NIVIS LLC with another party by e-mail without express written
> reasonable precautions to ensure no viruses are present in this
> e-mail, we cannot accept responsibility for any loss or damage
> arising from the viruses in this e-mail or attachments.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 23 Apr 2009 16:29:07 +0200

Hi all,

To be sure I understand: is the lowpan link concept different from the link definition in IPv6?
link - a communication facility or medium over which nodes can
       communicate at the link layer, i.e., the layer
       immediately below IP.  Examples are Ethernets (simple
       or bridged), PPP links, X.25, Frame Relay, or ATM
       networks as well as Internet-layer (or higher-layer)
       "tunnels", such as tunnels over IPv4 or IPv6 itself.

Best,
Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: jeudi 23 avril 2009 15:53
To: Robert Assimiti
Cc: [email-masked]
Subject: Re: [6lowpan] [6loWPAN] 6loWPAN Design and Application Spaces for 6loWPANs - 02-

>       or as the radio propagation conditions change.

At least the formulation "link shared by a link-local scope" is confusing.  Maybe a "link connecting nodes  which are part of the same link-local scope"(?)

Then it says "broadcast over the air in a route over LoWPAN" which is less understandable again...

>       those nodes reachable over a single radio transmission.

What is a single radio transmission?  Is it that non-link-local scope implies several radio transmissions?

> Due to the time-varying characteristics of wireless communication, the 
> neighbor set may change over time even when nodes maintain the same 
> physical locations.

Excuse-me but I really don't understand this: time-varying characteristics of wireless communications - do you mean TDD?

 > Route Over [...] Multihop is achieved using IP routing.

Multihop with IP routing means also that the router forwards between two different links (each with its own link-local scope).  However, the "Route Over" definition above uses a single link-local scope.

Alex

>> /"//A low-power wireless link which is shared by a link-local scope 
>> in a LoWPAN. In a LoWPAN, a link can be a very instable set of nodes, 
>> for instance the set of nodes that can receive a packet/ /that is 
>> broadcast over the air in a route over LoWPAN, or the set of nodes 
>> currently reachable in an L2 mesh in a mesh under LoWPAN.
>> Such a set may vary from one packet to the next / /as the nodes move 
>> or as the radio propagation conditions change."/
>> 
> addressed to a link-local IPv6 address reaches all nodes in the 
> LoWPAN, without being 'IP-forwarded'.
> 
>> _______________________________________________ 6lowpan mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>> 
> 
> 
> 
> 
> e-mail, we cannot accept responsibility for any loss or damage arising 
> from the viruses in this e-mail or attachments.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Apr 2009 18:34:33 +0200

>        "tunnels", such as tunnels over IPv4 or IPv6 itself.

Excellent point!  I think no, the LoWPAN link shouldn't be any different 
from the IPv6 link definition listed above.  Which RFC is that btw?

However, the wireless quirk is this famous non-transitivity wireless 
problem (or 'hidden' terminal problem) which says that a set of nodes 
which can communicate at link-layer pairwise can't necessarily 
communicate at link-layer from any node to any node - i.e. there can be 
three nodes forming two different "linked" links.  This effectively 
makes the above IPv6 link definition irrelevant to any wireless link.

Were the above IPv6 link definition to say "a medium over which each 
node can communicate at the link layer to each other node", or similar, 
then the wireless quirk wouldn't apply and we'd be happily be using that 
IPv6 link definition, I think.

Alex