Subject: [6lowpan] About definitions in draft-ietf-6lowpan-usecases-02

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

As I said previously, I have difficulty understanding some terms in the 
usecases draft.

For example, it defines LoWPAN Host, LoWPAN Router and LoWPAN Node. 
However it doesn't say a LoWPAN Node may be a LoWPAN Host or a LoWPAN 
Router. (I think, commonly in IPv6, Nodes may be Host or Routers).

It defines Mesh Under and Route Over; however I can't understand the 
following: does a "Route-Over" LoWPAN contain the same IP link-local 
scope or not?  If yes then this is very difficult to udnerstand, next to 
impossible.

Also, another problem is that it defines the Route-Over and Mesh-Under 
in apple-to-orange terms ("boundaries" vs "radio range"), whereas 
Route-Over and Mesh-Under have often been easily compared, ie 
redapples-to-greenapples.

Then on the use of 'single radio transmission' to define "Route Over" - 
what is single radio transmission more precisely?  One is tempted to 
believe all nodes reachable by a single radio transmission from a 
certain node are all within the same IP link-local scope... which is ok.

>    Route Over
> 
>       A LoWPAN configuration where the link-local scope is defined by
>       those nodes reachable over a single radio transmission. [...]

But because it doesn't say from _where_ are those nodes reachable (from 
another single certain node) then one can easily also think this:  B is 
within a single radio transmission of both C and A, yet it is in two 
different link-local scopes, which is of course not the intention.

                    -----------------------
                    |radiorange|radiorange|
                    A          B          C

Knowing the above, I'm trying to offer my own definitions of terms in 
the way I'd have written it.  Of course it may not fit all the views, 
but I thought I'd share:

PHY repeating

   The act performed by a device repeating a packet at PHY level.  It
   doesn't inspect any field in any packet header.  It has one or several
   interfaces, they are all in the same IP link-local scope.

MAC forwarding

   The act performed by a bridge - inspecting the dst MAC address of
   incoming packet, exact-matching it to the first field in a table of
   tuples [dst,nexthop]
   MAC addresses and transmitting it to the identified nexthop.  In the
   process, the src and dst MAC address of the packet are potentially
   modified.  The device may have one or more interfaces but they are all
   in the same IP link-local scope.

IP routing

   The act performed by a router - inspecting the dst
   IP address of an incoming packet,
   longest-prefix matching it to the first field of each entry
   in a table of triolets
   [dst,prefixlength,nexthop] IP addresses and transmitting it to the
   identified nexthop.  In the process, neither the src nor the dst IP
   addresses of the packet are ever modified.  It has two ore more
   interfaces, each interface of the router has a different IP link-local
   scope.

IP link-local scope

   The set of IP nodes reachable by an IP packet whose dst address starts
   with 0xff02.  All nodes on a link are within the same IP link-local
   scope, and nodes outside the link are outside the scope.  Transmitting
   packets in the same link-local scope doesn't involve IP routing but
   may involve MAC forwarding.

Radio range of node

   The radio range of a node is the set of nodes reachable from it, at
   PHY layer.  For example, the radio range of a WiFi node is 50m in a
   clear-sight atmospheric area, without physical obstacles and in good
   weather.

   Obviously, all nodes in same radio range of a node could be understood
   to be in the same IP link-local scope.

   However, a single-interface node can't be part of several IP
   link-local scopes even if sits at the intersection of the radio ranges
   of several other nodes.

"Mesh-Under" LoWPAN

   A LoWPAN configuration where the IP link-local scope is extended to
   more nodes (beyond the radio range of a node) by means of MAC
   forwarding exclusively.  All nodes in a "Mesh-Under" LoWPAN are within
   the same IP link-local scope, despite the probable presence of several
   PHY radio ranges - this alleviates the non-transitivity aspect.

"Route-Over" LoWPAN

   A LoWPAN configuration where the IP link-local scope is extended to
   more nodes (beyond the radio range of a node) by means of transmitting
   IP packets, using a novel IP routing method.  This novel method
   runs on a LoWPAN Router (uses a single interface, instead of the
   typical 2-interface router) and both interfaces are in the same IP
   link-local scope (instead of the typical router having a different IP
   link-local scope for each interface).

"Routed" LoWPAN

   A LoWPAN configuration where the IP link-local scope is not extended
   beyond the radio range.  Certain nodes are manually designated as
   special.  The radio range of each special node contains the set of
   nodes in the same IP link-local scope, and each such range forms a
   unique link.  Connecting two such links is performed by means of a
   typical IP router (multiple interfaces, different link-local scope).

Comments anyone?

Alex

---

From: Dominik Kaspar <[email-masked]>
Date: Wed, 29 Apr 2009 16:00:08 +0200

Hi Alex,

Thanks for sharing your definitions on LoWPAN terminology. I agree
with you that the current definition of "LoWPAN Mesh Node" is
incomplete. We must point out that it is a general term which includes
both a LoWPAN Host or a LoWPAN Router.

The link definition of RFC4861 is indeed useful. For the Use Cases
draft, we will follow the changes in the ND draft on what a "LoWPAN
Link" is.

It might be nit-picky, but didn't you mean "IP forwarding" when you
defined "IP routing"? And I disagree with your statement that "it has
two or more interfaces, each interface of the router has a different
IP link-local scope." I think that LoWPAN nodes mostly likely won't
have more than a single physical network interface...

Greetings,
Dominik

On Thu, Apr 23, 2009 at 6:14 PM, Alexandru Petrescu
<[email-masked]> wrote:
> For example, it defines LoWPAN Host, LoWPAN Router and LoWPAN Node. However
> it doesn't say a LoWPAN Node may be a LoWPAN Host or a LoWPAN Router. (I
> think, commonly in IPv6, Nodes may be Host or Routers).
>
> following: does a "Route-Over" LoWPAN contain the same IP link-local scope
> or not?  If yes then this is very difficult to udnerstand, next to
> impossible.
>
> Also, another problem is that it defines the Route-Over and Mesh-Under in
> apple-to-orange terms ("boundaries" vs "radio range"), whereas Route-Over
> and Mesh-Under have often been easily compared, ie redapples-to-greenapples.
>
> Then on the use of 'single radio transmission' to define "Route Over" - what
> is single radio transmission more precisely?  One is tempted to believe all
> nodes reachable by a single radio transmission from a certain node are all
> within the same IP link-local scope... which is ok.
>
>>   Route Over
>>
> Knowing the above, I'm trying to offer my own definitions of terms in the
> way I'd have written it.  Of course it may not fit all the views, but I
> thought I'd share:
>
> PHY repeating
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Apr 2009 16:10:09 +0200

> both a LoWPAN Host or a LoWPAN Router.

Ok.

> draft, we will follow the changes in the ND draft on what a "LoWPAN

Which is?

> defined "IP routing"?

I was thinking of it being both forwarding and routing. ("IP routing
   scope.")

I wrote IP "routing" more to distinguish it from the immediately 
previous "MAC forwarding" because I think some people said here that MAC 
forwarding is different than IP routing...  but I don't think anybody 
said how is it different.

> And I disagree with your statement that "it has

I agree that LoWPAN nodes seem likely to have a single interface.  But 
this is new and different!

A typical router doing IP routing, has more than one interface.

Alex

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 29 Apr 2009 16:22:10 +0200

Hi Alex,

Regarding routers with one interface, it is true that regarding usual practice and deployments, it is new. However conceptually, a router is usually defined as "a node that forwards IP packets not explicitly addressed to itself". To the best of my knowledge, this is what RFCs assume when they use the router concept. Hence we should not run into problems nor need to modify standards to support the one interface scenario. Do you see scenarios / implementations where having one interface will break something?

Best,
Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: mercredi 29 avril 2009 16:10
To: Dominik Kaspar
Cc: 6lowpan
Subject: Re: [6lowpan] About definitions in draft-ietf-6lowpan-usecases-02

Ok.

Which is?

I wrote IP "routing" more to distinguish it from the immediately previous "MAC forwarding" because I think some people said here that MAC forwarding is different than IP routing...  but I don't think anybody said how is it different.

> And I disagree with your statement that "it has two or more 
> scope." I think that LoWPAN nodes mostly likely won't have more than a 
> single physical network interface...

I agree that LoWPAN nodes seem likely to have a single interface.  But this is new and different!

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Apr 2009 18:26:27 +0200

Julien Abeille (jabeille) a écrit :
> Hi Alex,
> 
> Regarding routers with one interface, it is true that regarding usual
>  practice and deployments, it is new.

I agree.

> However conceptually, a router is usually defined as "a node that
> forwards IP packets not explicitly addressed to itself".

Silence on the assumed number of interfaces isn't a favoring argument
for one-interface routers either.

A router putting a packet back on the same interface it came from sounds
  bad routing problem in the first place...

> To the best of my knowledge, this is what RFCs assume when they use 
> the router concept.

But many RFCs specify behaviour with respect to a particular
interface.

> Hence we should not run into problems nor need to modify standards to
> support the one interface scenario. Do you see scenarios /
> implementations where having one interface will break something?

I'm not sure what detail is needed to support the view that 
one-interface routers are particularly new beasts...

IP-repeating packets on the same interface is noise in the air.  It
breaks the availability of free timeslots to neighboring nodes.

Waste of memory; common routing tables (and ND-related structures too)
have a field "interface";  if all entries had the same content in that
field then why would the field be needed at all?

I will try to make a separate topic (again) on this...

Alex