Subject: [6lowpan] Terminology

From: Zach Shelby <[email-masked]>
Date: Tue, 12 May 2009 12:37:34 +0300

Hi,

I am working on an updated terminology set for the nd draft. The 
terminology is now split with 6LoWPAN general terminology now in its own 
section. I would like comments on this updated set (below) where I have 
tried to find a solution based on the constructive discussions we had on 
the list.

After looking through all the background RFCs in detail, it actually 
turns out this is not as hard as we thought. RFC4861 actually does cover 
the wireless case as it defines assymetric properties of wireless links 
including non-transitivity (see Section 2.2). In fact RFC4861 actually 
mentions that the protocol (ND) will presumably be extended in the 
future to deal with links that are assymetric (non-reflexive, 
non-transitive). That is what we are doing with ND for 6LoWPAN!

Therefore I have now defined link as being non-transitive and complex 
NBMA, which can be somewhat overcome using link-layer mesh techniques or 
by with IP routing. This greatly simplifies the definition of a subnet 
(whew!), as we keep the RFC4291 where subnet <= link. As we are 
performing IP routing to overcome the non-transitive nature, the subnet 
does exhibit one aspect of multi-link subnet mentioned in RFC4903.

IP routing has been defined as Alex recommended as it has specific 
properties to 6LoWPAN. In the architecture section of nd-03 we will 
include LoWPAN IP routing examples including topology and what is in the 
table.

General 6LoWPAN Terminology:

    This section defines additional general terms related to the 6LoWPAN
    architecture used in this specification:

    IP Routing

       The forwarding of datagrams at the IP layer between arbitrary
       source-destination pairs, during which the hop limit is
       decremented.  In the LoWPAN context, IP routing is performed by
       LoWPAN Routers on a single interface within the same link to
       overcome the non-transient nature of the link.  Exact match search
       is performed on the dst address of the IP packet to find the next-
       hop to the destination.  Referred to as routing in this document.

    Link

       The link is a communication facility or medium over which nodes
       can communicate at the link-layer, i.e., the layer directly below
       IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy
       wireless links such as IEEE 802.15.4, which is a special type of
       link as described in [RFC4861] exhibiting severe assymetric
       reachability with both non-reflexive and non-transitive qualities.
       Furthermore complex Non-broadcast Multi-Access (NBMA) behaviour is
       exhibited as these links do not support native multicast, and
       broadcast reaches only a subset of nodes on the link.  The use of
       link-layer mesh technology (see Mesh Under) emulates transitivity
       across the link but still has problems with non-reflexitivity.
       Multicast on a link-layer mesh is usually implemented as a
       broadcast flood.

    Link-local

       Standard IPv6 link-local scope as defined in [RFC4291] and
       [RFC4861] is supported by the 6LoWPAN link and subnet model.
       Link-local scope is achieved by setting the hop limit to 1, using
       link-local prefix or link-local multicast scope.  If a link is
       non-transient then link-local scope includes only a subset of
       nodes on the link (the set of nodes within assymetric radio range
       of a node).  Nodes in the link-local scope of a node are its
       neighbors, and this link-local scope may be different for each
       node on a link.

    LoWPAN Host

       A node that only sources or sinks IPv6 datagrams.  Referred to as
       a host in this document.

    LoWPAN Node

       A node that composes a LoWPAN and is used to refer to both hosts
       and routers.  Referred to as a node in this document.

    LoWPAN Router

       A node that forwards datagrams between arbitrary source-
       destination pairs using a single 6LoWPAN interface performing IP
       routing on that interface.

    Mesh Under

       A term referring to a configuration where the link-local scope is
       defined by the boundaries of the LoWPAN and includes all the
       6LoWPAN interfaces within it.  Forwarding and multihop routing
       functions are achieved at the link layer.  In this configuration
       the link may still exhibit assymetric behaviour.

    Route Over

       A term referring to a configuration where the link is non-
       transient and the link-local scope reaches only a subset of the
       LoWPAN nodes.  IP routing is performed by LoWPAN Routers to
       overcome to the non-transient nature of the link.  This
       configuration may consist of both routers nad hosts.

    Subnet

       A subnet is the collection of interfaces having the same IPv6
       subnet prefix on a link, as defined in [RFC4291].  A LoWPAN is
       made up of the interfaces of LoWPAN Nodes and Edge Routers sharing
       the same subnet prefix.  Due to the non-transient nature of
       6LoWPAN links, IP routing may be used on the link to provide
       transitivity.  This exhibits a multi-link subnet feature with
       regard to hop limit as defined in [RFC4903], and thus 6LoWPAN
       applications should make no assumptions about the hop limit as it
       may be decremented in a LoWPAN.

-- 
http://www.sensinode.com
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: "Burnett, Peter" <[email-masked]>
Date: Tue, 12 May 2009 11:53:00 +0200

Zach,
I'm wondering if the term 'non-reflexive' in RFC4861 should have been 'non-symmetric'. Mathematically, an equivalence relationship is defined as being reflexive, symmetric and transitive. Symmetric is the property which is untrue on a unidirectional link not reflexive.
Apologies if this is nonsense, I'm new to this list.
Thanks
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: 2009 May 12 10:38
To: 6lowpan
Subject: [6lowpan] Terminology

Hi,

    IP Routing

    Link

    Link-local

    LoWPAN Host

    LoWPAN Node

    LoWPAN Router

    Mesh Under

    Route Over

    Subnet

--
http://www.sensinode.com
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.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Dominik Kaspar <[email-masked]>
Date: Wed, 13 May 2009 09:44:00 +0200

Hi,

Would 'non-reflexive' (better called 'irreflexive') reachability mean
that a node can not reach itself? If so... I think the term still
makes sense, because 6LoWPAN nodes usually cannot send and receive at
the same time (except if they had two physical radio interfaces).

By the way, typo: assymetric -> asymmetric.

Greetings,
Dominik

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 May 2009 11:58:13 +0200

Dominik Kaspar a écrit :
> Hi,
> 
> Would 'non-reflexive' (better called 'irreflexive') reachability

'Irreflexive' sounds good to my dictionary, and to me better than
non-reflexive.

'Reachability' is absent from many dictionaries.

Alex

> mean that a node can not reach itself? If so... I think the term
> still makes sense, because 6LoWPAN nodes usually cannot send and
> receive at the same time (except if they had two physical radio
> interfaces).
> 
> Greetings, Dominik
>> Zach, I'm wondering if the term 'non-reflexive' in RFC4861 should
>> have been 'non-symmetric'. Mathematically, an equivalence
>> relationship is defined as being reflexive, symmetric and
>> transitive. Symmetric is the property which is untrue on a
>> unidirectional link not reflexive. Apologies if this is nonsense,
>> I'm new to this list. Thanks Peter
>> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Zach Shelby Sent:
>> 2009 May 12 10:38 To: 6lowpan Subject: [6lowpan] Terminology
>> 
>> Hi,
>> 
>> terminology is now split with 6LoWPAN general terminology now in
>> its own section. I would like comments on this updated set (below)
>> where I have tried to find a solution based on the constructive
>> discussions we had on the list.
>> 
>> After looking through all the background RFCs in detail, it
>> actually turns out this is not as hard as we thought. RFC4861
>> actually does cover the wireless case as it defines assymetric
>> properties of wireless links including non-transitivity (see
>> Section 2.2). In fact RFC4861 actually mentions that the protocol
>> (ND) will presumably be extended in the future to deal with links
>> that are assymetric (non-reflexive, non-transitive). That is what
>> we are doing with ND for 6LoWPAN!
>> 
>> Therefore I have now defined link as being non-transitive and
>> complex NBMA, which can be somewhat overcome using link-layer mesh
>> techniques or by with IP routing. This greatly simplifies the
>> definition of a subnet (whew!), as we keep the RFC4291 where subnet
>> <= link. As we are performing IP routing to overcome the
>> non-transitive nature, the subnet does exhibit one aspect of
>> multi-link subnet mentioned in RFC4903.
>> 
>>  include LoWPAN IP routing examples including topology and what is
>> in the table.
>> 
>> 
>> 
>> 
>> This section defines additional general terms related to the
>> 6LoWPAN architecture used in this specification:
>> 
>> IP Routing
>> 
>> The link is a communication facility or medium over which nodes can
>> communicate at the link-layer, i.e., the layer directly below IP
>> ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy 
>> non-transient then link-local scope includes only a subset of nodes
>> on the link (the set of nodes within assymetric radio range of a
>> node).  Nodes in the link-local scope of a node are its neighbors,
>> and this link-local scope may be different for each node on a link.
>> 
>> 
>> LoWPAN Host
>> 
>> A node that only sources or sinks IPv6 datagrams.  Referred to as a
>> host in this document.
>> 
>> LoWPAN Node
>> 
>> subnet prefix on a link, as defined in [RFC4291].  A LoWPAN is made
>> up of the interfaces of LoWPAN Nodes and Edge Routers sharing the
>> same subnet prefix.  Due to the non-transient nature of 6LoWPAN
>> links, IP routing may be used on the link to provide transitivity.
>> This exhibits a multi-link subnet feature with regard to hop limit
>> as defined in [RFC4903], and thus 6LoWPAN applications should make
>> no assumptions about the hop limit as it may be decremented in a
>> LoWPAN.
>> 
>> 
>> -- http://www.sensinode.com 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. _______________________________________________ 6lowpan
>> mailing list [email-masked] 
>> The information contained in this message may be confidential and
>> legally protected under applicable law. The message is intended
>> solely for the addressee(s). If you are not the intended recipient,
>> you are hereby notified that any use, forwarding, dissemination, or
>> reproduction of this message is strictly prohibited and may be
>> unlawful. If you are not the intended recipient, please contact the
>> sender by return e-mail and destroy all copies of the original
>> message. _______________________________________________ 6lowpan
>> mailing list [email-masked] 
> _______________________________________________ 6lowpan mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 May 2009 12:40:51 +0200

Zach, thanks for consolidating our recent discussions.  I have comments
on the proposed terminology.  I mainly agree with most terms.  I point
where I don't agree.

Zach Shelby a écrit :
> terminology is now split with 6LoWPAN general terminology now in its
>  own section. I would like comments on this updated set (below) where
>  I have tried to find a solution based on the constructive
>  turns out this is not as hard as we thought. RFC4861 actually does 
> cover the wireless case as it defines assymetric properties of 
> wireless links including non-transitivity (see Section 2.2).

YEs.

> In fact RFC4861 actually mentions that the protocol (ND) will 
> presumably be extended in the future to deal with links that are 
> assymetric (non-reflexive, non-transitive). That is what we are doing
>  with ND for 6LoWPAN!

YEs, it seems straightforward and obvious to agree.  I agree with it, 
makes sense and is concrete.

However, just a note to say this is what AUTOCONF and MANET WGs also 
claim(ed).  Despite this obviousness, it is not stipulated in neither of 
the three Charters.

By my reading, nothing in the three Charters makes think about the 
necessity to extend ND to deal with non-transitive links, although many 
people's conversations assume it so.

This was just a note.

>  NBMA, which can be somewhat overcome using link-layer mesh 
> source-destination pairs, during which the hop limit is decremented.
>  In the LoWPAN context, IP routing is performed by LoWPAN Routers on
> a single interface within the same link to overcome the non-transient
>  nature of the link.  Exact match search is performed on the dst 
> address of the IP packet to find the next- hop to the destination. 
> Referred to as routing in this document.
> 
> Link
> 
> ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy wireless
>  links such as IEEE 802.15.4, which is a special type of link as 
> described in [RFC4861] exhibiting severe assymetric reachability with
>  both non-reflexive and non-transitive qualities. Furthermore complex
>  Non-broadcast Multi-Access (NBMA) behaviour is exhibited as these 
> links do not support native multicast, and broadcast reaches only a 
> subset of nodes on the link.  The use of link-layer mesh technology 
> (see Mesh Under) emulates transitivity across the link but still has
>  problems with non-reflexitivity. Multicast on a link-layer mesh is 
> usually implemented as a broadcast flood.
> 
> Link-local
> 
> Standard IPv6 link-local scope as defined in [RFC4291] and [RFC4861]
>  is supported by the 6LoWPAN link and subnet model. Link-local scope
>  is achieved by setting the hop limit to 1, using link-local prefix
> or link-local multicast scope.  If a link is non-transient then

non-transient?  or non-transitive?

> link-local scope includes only a subset of nodes on the link (the set
>  of nodes within assymetric radio range of a node).

you mean the link-local scope covers the symmetric range, not the
asymmetric range.  I think?

> Nodes in the link-local scope of a node are its neighbors, and this 
> link-local scope may be different for each node on a link.

'Link' being different than 'link-local' scope starts to be difficult to
grasp.

I hear you  saying the link-local scope may not cover the entire
link, only the part of it which is fully transitive and reflexive.  It
leads me more and more to think a non-transitive link is actually two
links.  Each link with its own link-local scope, each fully transitive 
and symmetric.  (If so, the problem left is to fit a router with a 
single interface connecting to two links simultaneously (the parts of a 
non-transitive link).)

> A node that composes a LoWPAN and is used to refer to both hosts and
>  routers.  Referred to as a node in this document.
> 
> LoWPAN Router
> 
> A node that forwards datagrams between arbitrary source- destination
>  pairs using a single 6LoWPAN interface performing IP routing on that
>  interface.
 >
> Mesh Under
> 
> defined by the boundaries of the LoWPAN and includes all the 6LoWPAN
>  interfaces within it.  Forwarding and multihop routing functions are
>  achieved at the link layer.  In this configuration the link may
> still exhibit assymetric behaviour.
> 
> Route Over
> 
> A term referring to a configuration where the link is non- transient
>  and the link-local scope reaches only a subset of the LoWPAN nodes.
>  IP routing is performed by LoWPAN Routers to overcome to the 
> non-transient nature of the link.  This configuration may consist of
>  both routers nad hosts.

nit: nad, should be and.

> Subnet
> 
> A subnet is the collection of interfaces having the same IPv6 subnet
>  prefix on a link, as defined in [RFC4291].  A LoWPAN is made up of 
> the interfaces of LoWPAN Nodes and Edge Routers sharing the same 
> subnet prefix.  Due to the non-transient nature of 6LoWPAN links, IP
>  routing may be used on the link to provide transitivity.  This 
> exhibits a multi-link subnet feature with regard to hop limit as 
> defined in [RFC4903], and thus 6LoWPAN applications should make no 
> assumptions about the hop limit as it may be decremented in a LoWPAN.

If a hop limit is decremented within the subnet then this is not a
single subnet...

ND messages on the same link (subnet) don't decrement the Hop Limit.

Alex

---

From: Dominik Kaspar <[email-masked]>
Date: Wed, 13 May 2009 12:42:19 +0200

Hi Alex,

Indeed, 'reachability' is not listed in many directories. However, the
IETF seems to accept it as a word. For instance:

RFC 1273 "Measurement Study of Changes in Service-Level Reachability
in the Global TCP/IP Internet"
RFC 5549 "Advertising IPv4 Network Layer Reachability Information with
an IPv6 Next Hop"

Cheers,
Dominik

On Wed, May 13, 2009 at 11:58 AM, Alexandru Petrescu
<[email-masked]> wrote:
>>> source-destination pairs, during which the hop limit is decremented.  In the
>>> LoWPAN context, IP routing is performed by LoWPAN Routers on a single
>>> interface within the same link to overcome the non-transient nature of the
>>> link.  Exact match search is performed on the dst address of the IP packet
>>> to find the next- hop to the destination.  Referred to as routing in this
>>> document.
>>>
>>> Link
>>>
>>> links such as IEEE 802.15.4, which is a special type of link as described in
>>> [RFC4861] exhibiting severe assymetric reachability with both non-reflexive
>>> and non-transitive qualities. Furthermore complex Non-broadcast Multi-Access
>>> (NBMA) behaviour is exhibited as these links do not support native
>>> multicast, and broadcast reaches only a subset of nodes on the link.  The
>>> use of link-layer mesh technology (see Mesh Under) emulates transitivity
>>> across the link but still has problems with non-reflexitivity. Multicast on
>>> a link-layer mesh is usually implemented as a broadcast flood.
>>>
>>> Link-local
>>>
>>> Standard IPv6 link-local scope as defined in [RFC4291] and [RFC4861] is
>>> supported by the 6LoWPAN link and subnet model. Link-local scope is achieved
>>> by setting the hop limit to 1, using link-local prefix or link-local
>>> multicast scope.  If a link is non-transient then link-local scope includes
>>> only a subset of nodes
>>> A term referring to a configuration where the link-local scope is defined
>>> by the boundaries of the LoWPAN and includes all the 6LoWPAN interfaces
>>> within it.  Forwarding and multihop routing functions are achieved at the
>>> link layer.  In this configuration the link may still exhibit assymetric
>>> behaviour.
>>>
>>> Route Over
>>>
>>> A term referring to a configuration where the link is non- transient and
>>> the link-local scope reaches only a subset of the LoWPAN nodes.  IP routing
>>> is performed by LoWPAN Routers to overcome to the non-transient nature of
>>> the link.  This configuration may consist of both routers nad hosts.
>>>
>>> Subnet
>>>
>>> prefix on a link, as defined in [RFC4291].  A LoWPAN is made

---

From: Zach Shelby <[email-masked]>
Date: Wed, 13 May 2009 16:19:06 +0300

Dominik,

I would prefer using the RFC4861 terminology exactly, here is the text 
from Section 2.2 page 9:

    asymmetric reachability
                   - a link where non-reflexive and/or non-transitive
                     reachability is part of normal operation.  (Non-
                     reflexive reachability means packets from A reach B,
                     but packets from B don't reach A.  Non-transitive
                     reachability means packets from A reach B, and
                     packets from B reach C, but packets from A don't
                     reach C.)  Many radio links exhibit these
                     properties.

Here is an updated link definition including examples (in brackets):

    Link

       The link is a communication facility or medium over which nodes
       can communicate at the link-layer, i.e., the layer directly below
       IP ([RFC4861]). 6LoWPAN assumes the use of low-power and lossy
       wireless links such as IEEE 802.15.4, which is a special type of
       link as described in [RFC4861] exhibiting severe asymmetric
       reachability with both non-reflexive (A can reach B, but B can't
       reach A) and non-transitive (A can reach B, and B can reach C, but
       A can't reach C) qualities.  Furthermore complex Non-broadcast
       Multi-Access (NBMA) behaviour is exhibited as these links do not
       support native multicast, and broadcast reaches only a subset of
       nodes on the link.  Such a wireless link may consist of multiple
       overlapping link-local scopes.

       The use of link-layer mesh technology (see Mesh Under) emulates
       transitivity across the link but still has problems with non-
       reflexitivity.  Multicast on a link-layer mesh is usually
       implemented as a broadcast flood.

- Zach

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

---

From: Zach Shelby <[email-masked]>
Date: Wed, 13 May 2009 16:46:29 +0300

Alex,

> on the proposed terminology.  I mainly agree with most terms.  I point

Good we're getting close here.

There are several hard facts that we have to live with in this WG, which 
I try to capture in these definitions:
1. A LoWPAN must have a common subnet prefix, this is how compression works!
2. The wireless links we work with are non-transitive, non-reflexive. It 
is made up of overlapping broadcast scopes.
3. L3 routing inside LoWPANs is a reality (vendors are doing it, ROLL is 
designing it)

So we have two options (#1 is what I am proposing, #2 was used in nd-02):
1. Model the whole wireless channel as a non-transitive link, made up of 
overlapping broadcast scopes (link-local scopes). A LoWPAN is a subnet, 
which may be a multi-hop subnet.
2. Model each broadcast scope as a link. A LoWPAN is a subnet, which is 
a multi-link subnet as it is made up of a whole bunch of overlapping links.

Considering RFC4861, RFC4903 and IETF terminology on a whole #1 is 
easier to swallow.

>>  NBMA, which can be somewhat overcome using link-layer mesh techniques 
>> or by with IP routing. This greatly simplifies the definition of a 
>> subnet (whew!), as we keep the RFC4291 where subnet <= link. As we are 
>> performing IP routing to overcome the non-transitive nature, the 
>> subnet does exhibit one aspect of multi-link subnet mentioned in RFC4903.
>>
>> IP Routing
>>

non-transitive, thanks.

> asymmetric range.  I think?

symmetric, exactly.

> 'Link' being different than 'link-local' scope starts to be difficult to

This is exactly what a non-transitive link is according to RFC4861 
definition. This is also the reality with wireless links the 6lowpan WG 
is dealing with - it covers the situation well using IETF terminology.

> single interface connecting to two links simultaneously (the parts of a 

You can't split this non-transitive link into a clean set of transitive 
ones just like that. It doesn't work, especially from the 
single-interface router point of view.

A - B - C

A can reach B, B can reach C, but A can't reach C.

B is a LoWPAN Router. From its perspective, its link-local scope 
includes both A and C. It does not have two links by any means. It is 
forwarding between two nodes on the same link (and in the same 
link-local scope) who don't have transitivity between each other (A and C).

> If a hop limit is decremented within the subnet then this is not a

I don't agree. Read RFC4903 again. It exhibits one aspect of a 
multi-link subnet. However as I am proposing we model the 6LoWPAN as a 
non-transient link what we have here is actually a multi-hop subnet, 
which is a lesser evil than a multi-link subnet.

> ND messages on the same link (subnet) don't decrement the Hop Limit.

LoWPAN IP Routers do decrement the hop limit, and all nodes in a LoWPAN 
are inside a subnet because this is the 6lowpan wg.

This is something we just can't change in 6lowpan - the whole concept 
behind the compression is that there is a shared prefix across the 
LoWPAN, which is why we can compress addresses. So we are stuck with 
LoWPAN = subnet.

If the subnet term is a problem, then I did make a suggestion earlier to 
stop calling it a subnet all together and just call it a LoWPAN... or 
supernet? Neighborhood?

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 May 2009 22:32:16 +0200

Zach Shelby a écrit :
[...]
>> single interface connecting to two links simultaneously (the parts of 
>> a non-transitive link).)
> 

B in LL scopes of both A and C, B has a single interface... could it be 
that B forwards a packet from A to C without A hearing it too?

Node A receiving its own packet could be easily qualified as noise.

Otherwise nodes should have a means to know on _which_ link-local scopes 
are they, and send data on only one scope.  But I think there's only one 
link-local address per interface, and only a scope_id field in the 
respective C struct.

Sorry for insisting on this, it is IMHO.  I will agree with the WG further.

Alex

---

From: Zach Shelby <[email-masked]>
Date: Thu, 14 May 2009 00:27:41 +0300

Alexandru Petrescu wrote:
>>> links.  Each link with its own link-local scope, each fully 
>>> transitive and symmetric.  (If so, the problem left is to fit a 
>>> router with a single interface connecting to two links simultaneously 
>>> (the parts of a non-transitive link).)
>>
>> You can't split this non-transitive link into a clean set of 
>> transitive ones just like that. It doesn't work, especially from the 

A's link-layer can hear when B forwards the packet (unless it went to 
sleep immediately)..

> Node A receiving its own packet could be easily qualified as noise.

However, as the IP destination is the unicast address of C, the 
link-layer destination is the MAC address of C. Thus A's link-layer will 
discard it. Medium access control schemes of wireless link-layers are 
able to deal with extra transmissions from multihop forwarding. Of 
course because you are forwarding with a single interface, your channel 
capacity decreases with more hops (this is the multihop penalty of all 
such schemes, including Mesh Under).

> link-local address per interface, and only a scope_id field in the 

Not needed, the link-layer deals with this using MAC addressing and the 
MAC algorithm. A node just tracks who are its neighbors.

> Sorry for insisting on this, it is IMHO.  I will agree with the WG further.

No problem, as a WG we needed to re-assure we agree on the terminology. 
In fact I think you helped make a big improvement with the link and 
LoWPAN IP routing definitions.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 May 2009 11:41:03 +0200

Zach Shelby a écrit :
>> Zach Shelby a écrit : [...]
>>>> I hear you  saying the link-local scope may not cover the 
>>>> entire link, only the part of it which is fully transitive and 
>>>> reflexive.  It leads me more and more to think a non-transitive
>>>>  link is actually two links.  Each link with its own link-local
>>>>  scope, each fully transitive and symmetric.  (If so, the 
>>>> problem left is to fit a router with a single interface 
>>>> connecting to two links simultaneously (the parts of a 
>>>> non-transitive link).)
>>> 
>>> transitive ones just like that. It doesn't work, especially from 
>>> the single-interface router point of view.
>>> 
>>> A - B - C
>>> 
>>> includes both A and C. It does not have two links by any means. 
>>> It is forwarding between two nodes on the same link (and in the 
>>> same link-local scope) who don't have transitivity between each 
>>> other (A and C).
>> 
>> B in LL scopes of both A and C, B has a single interface... could 
>> it be that B forwards a packet from A to C without A hearing it 
>> too?
> 

Ok.

> link-layer destination is the MAC address of C. Thus A's link-layer 
> will discard it.

Ok when the IP and MAC addresses are not multicast.

When they are, like when A sends an RS to "all-nodes" IP address 
(converted into "all-nodes" MAC address) B repeats back this packet to A 
(because in the same link-local scope as A), in addition to forwarding 
it to C.  This could lead to more noise, maybe even an RA generated by A.

> Medium access control schemes of wireless link-layers are able to 
> deal with extra transmissions from multihop forwarding.

I agree MAC schemes could alleviate the B transmits back to A problems.
  And these schemes are part (supposedly?) of the Mesh-Under concept.
Which makes think that Route-Over wouldn't work without Mesh-Under at 
the same time.

> Of course because you are forwarding with a single interface, your
> channel capacity decreases with more hops (this is the multihop
> penalty of all such schemes, including Mesh Under).

Ok.

>> Otherwise nodes should have a means to know on _which_ link-local 
>> scopes are they, and send data on only one scope.  But I think 
>> there's only one link-local address per interface, and only a 
>> scope_id field in the respective C struct.
> 
> Not needed, the link-layer deals with this using MAC addressing and 
> the MAC algorithm. A node just tracks who are its neighbors.

Ok.  Some questions rest about how does the link layer deal with 
link-layer multicast addresses, when they are used by RS and NS, such 
that to avoid noise amplification on non-transitive links.

Alex

---

From: Zach Shelby <[email-masked]>
Date: Thu, 14 May 2009 13:01:49 +0300

Alexandru Petrescu wrote:
>>>>> link, only the part of it which is fully transitive and reflexive.  
>>>>> It leads me more and more to think a non-transitive
>>>>>  scope, each fully transitive and symmetric.  (If so, the problem 
>>>>> left is to fit a router with a single interface connecting to two 
>>>>> links simultaneously (the parts of a non-transitive link).)
>>>>
>>>> includes both A and C. It does not have two links by any means. It 
>>>> is forwarding between two nodes on the same link (and in the same 
>>> B in LL scopes of both A and C, B has a single interface... could it 
>>> be that B forwards a packet from A to C without A hearing it too?
>>

Multicast with link-local scope, is simply a link-layer broadcast and is 
not retransmitted. So the above does not occur. Thus this kind of 
multicast used by RAs and NSs is not a big problem. We should still keep 
the frequency of these down.

If you try to do a multicast with scope > 2, then you have a flooding 
problem unless multicast is implemented in some other way. This is why 
we use the Whiteboard approach in 6lowpan-nd, to avoid the need to flood 
the LoWPAN.

>> Medium access control schemes of wireless link-layers are able to deal 
>> with extra transmissions from multihop forwarding.
> 

This has nothing to do with mesh-under. Every wireless link-layer 
implements medium access control, for example CSMA in the case of IEEE 
802.15.4.

> that to avoid noise amplification on non-transitive links.

You use link-local scope and it is not a problem (RS and NS are 
link-local messages). You of course want to keep the amount of ND 
signaling on a whole as low as possible - which is a goal of 6lowpan-nd.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 May 2009 13:00:39 +0200

Zach Shelby a écrit :
[...]
>  problem unless multicast is implemented in some other way. This is 
> why we use the Whiteboard approach in 6lowpan-nd, to avoid the need 
> to flood the LoWPAN.

6lowpan-ND  Whiteboard instead of link-layer multicast... maybe we
should make another thread...

For example it says:
> Another consequence [of forming address from MAC] is that the 
> link-local address is presumably unique on the Extended LoWPAN,

This is not a very safe assumption IMHO.

At least because the uniqueness assumed with IPv6 addresses formed from
short 16bit addresses is a uniqueness relative to a "PAN id" (and not to
a LoWPAN, not an Extended LoWPAN), even less globally unique.  And we
don't know anything about the uniqueness of PAN-IDs, do we?

> which enables the use of Optimistic Duplicate Address Detection 
> (oDAD) [RFC4429] over the Transit Link and the LoWPAN.

AFAIK oDAD does use the typical ND link-local multicast messages, so
does 6LoWPAN use ND link-local multicast messages or not?

(Transit Link on Edge Router overlaps its link-local scope over the
  LoWPAN)

> To simplify address resolution it is assumed that nodes within a 
> LoWPAN use addresses in a homogeneous way and that the unicast IPv6 
> address IIDs resolve directly to a corresponding link-layer address.

I just suppose it unsafe to assume an IPv6 address IIDs address resolves
directly into a MAC address, IMHO.  Because:

-it prohibits the use of manually assigned link-local addresses.
-it requires link-layers to have MAC addresses (not all have).
-in particular for IPv6-over-802.15.4 it is difficult to
  distinguish an IID to correspond to a short (16bit) or normal MAC
  address.  What is the MAC address from which this IPv6 address was
  formed?
              fe80::21:70ff:feb8:8252
  After removing the fffe and the fe80 - is there a short 16bit MAC
  address in there concatenated to the PAN ID?  Or is it a locally unique
  manually assigned 48bit MAC address?  Or a locally-unique self-derived
  non-standard USB address?

> Upon a registration flow, an edge router doing DAD

Doing DAD or DAD?

> If successful, this address is returned in an Address Option of the 
> RC with the 'A' flag set and the assigned IPv6 address formed from 
> the generated link-layer address with the defualt prefix inline.

This is typically a DHCPv6 function (a router forming an address for a
host and sending it for assignment on interface).  One would expect the
draft to refer DHCPv6 and say why not, no?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 May 2009 13:05:43 +0200

Zach Shelby a écrit :
[...]
> not retransmitted.

I am not sure what you mean (in general?  802.15.4 in particular?) but 
multicast with link-local scope maps into link-layer multicast, and is 
not simply link-layer broadcast.  Some link-layers do support link-layer 
multicast and it is all an advantage to ND.

For example to each IP link-local multicast address corresponds a MAC 
link-layer multicast address (like 33:33::1).  Moreover, IPv6 stacks 
simply don't work with link-layer addresses which use MAC broadcast 
addresses (48 1 bits).

Alex

  So the above does not occur. Thus this kind of

---

From: Zach Shelby <[email-masked]>
Date: Thu, 14 May 2009 14:26:56 +0300

Hi,

Now you are off of terminology, good. Let's leave the terminology alone 
for a while. On 6lowpan-nd we need to concentrate on the protocol 
details and implementation aspects. I changed the name of this thread. 
But lets please not re-tread on old subjects here. How about we do our 
best on nd-03 to make things crystal clear and then do another comment 
round? OK?

Some of your criticism here is on the very foundations of what this WG 
was chartered to do, and how e.g. IEEE 802.15.4 and similar link-layers 
work. Those we can't do anything about, so no use arguing about them.

Alexandru Petrescu wrote:
>> why we use the Whiteboard approach in 6lowpan-nd, to avoid the need to 
>> flood the LoWPAN.
> 

Again we are down to a link-layer reality. We don't have link-layer 
multicast available.

> This is not a very safe assumption IMHO.

In 6lowpan-nd we are performing DAD across the entire LoWPAN before 
removing the optimistic flag on an address. So it is unique after that, 
regardless of being short.

>> which enables the use of Optimistic Duplicate Address Detection (oDAD) 
>> [RFC4429] over the Transit Link and the LoWPAN.
> 

Over the transit link, which is the backbone link in an Extended LoWPAN. 
So it works exactly as in standard RFC4861. I'll fix that to say 
"backbone link".

> directly into a MAC address, IMHO.  Because:

It is not unsafe, it is the basic way that 6lowpan works.

> -it prohibits the use of manually assigned link-local addresses.

Not true at all. Please read IEEE 802.15.4 and RFC4944 specs. e.g. IEEE 
802.15.4 MAC implementations let you assign any address you want to the 
interface. So you can change your 64-bit or 16-bit address any time you 
want.

> -it requires link-layers to have MAC addresses (not all have).

The kinds of link layers we are dealing with in 6lowpan do have MAC 
addresses.

>  non-standard USB address?

That does not conform to RFC4944. Anyways, there are only two ways to 
derive the IID in RFC4944. You can tell them apart using the U/L flag in 
addition to the 16-bit zero field in-between the PAN-ID and 16-bit short 
address. I don't see a problem here.

>> Upon a registration flow, an edge router doing DAD

DAD

>> If successful, this address is returned in an Address Option of the RC 
>> with the 'A' flag set and the assigned IPv6 address formed from the 
>> generated link-layer address with the defualt prefix inline.
> 

This is claim and defend addressing. It is just a random number 
generated on behalf of the node (and then checked with DAD)... After 
this point it is completely up to the node to defend this address. The 
Whiteboard keeps absolutely no state regarding the generation, just a 
standard whiteboard entry. We have talked about this many times before. 
The node itself could just as well perform the random 16-bit address 
generation and then try to register it (thus performing DAD) on a 
trial-and-error basis.

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

---

From: Zach Shelby <[email-masked]>
Date: Thu, 14 May 2009 14:32:53 +0300

Alexandru Petrescu wrote:
> Zach Shelby a écrit :
> [...]
>> Multicast with link-local scope, is simply a link-layer broadcast and 
>> is not retransmitted.
> 

In general, for the types of link-layer this WG deals with. Please see 
RFC4944, RFC4919, IEEE 802.15.4. Link-local scope multicast is mapped to 
a broadcast (0xffff)... see page 4 of RFC4944. Other wireless 
link-layers are similar.

>> multicast used by RAs and NSs is not a big problem. We should still 
>> keep the frequency of these down.
>>
>> we use the Whiteboard approach in 6lowpan-nd, to avoid the need to 
>> flood the LoWPAN.
>>

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 May 2009 17:20:30 +0200

Zach, I may miss something big, but here goes my comment anyways...

Zach Shelby a écrit :
>> not simply link-layer broadcast.  Some link-layers do support 
>> link-layer multicast and it is all an advantage to ND.
> 

Unless I miss something big I'm afraid there may be an error both in 
what is said above, and in rfc4944.

rfc4944 doesn't seem to say a link-local scope multicast address is 
mapped into 0xffff, but probably into something like 0x8001.

BEsides, it doesn't seem to say what IP address corresponds to the 16bit 
MAC broadcast address 0xffff.  If the rule used for mapping ff02::1 into 
0x8001 were used to map 0xffff into an IP address then that would be 
ff02::9f, which is different than the all-nodes link-scoped multicast 
address ff02::1.

In short, by rfc4944:

ff02::1 maps into   0x8001
  0xffff maps into ff02::9f

HEre's the relevant rfc4944 text:

rfc4944 says "An IPv6 packet with a multicast destination address (DST),
    consisting of the sixteen octets DST[1] through DST[16], is
    transmitted to the following 802.15.4 16-bit multicast address:
    100 dst[15] dst [16]"

rfc4944 later says "   This document creates a new IANA registry
    for the 16-bit short address fields as used in 6LoWPAN packets.
    [...]
    This registry MUST include the addresses 0xffff (16-bit broadcast
    address accepted by all devices currently listening to the channel)
    and 0xfffe as defined in [ieee802.15.4]."

Additionally, when it talks use of link-layer broadcast to immitate 
link-layer multicast, it doesn't say which IP link-scoped multicast 
address is mapped into 0xffff.

> Hence, IPv6 level multicast packets MUST be carried as link-layer
> broadcast frames in IEEE 802.15.4 networks. [...]
> 
> 2.  A short destination address is included in the frame, and it MUST
>  match the broadcast address (0xffff).

With real link-layer multicast there are several multicast addresses, 
like 33:33::1, 33:33::2, etc.  Each corresponds to IP link-scope 
multicast address which is ff02::1, ff02::2, etc.

For example NS is sent to 33:33::1/ff02::1
whereas RS is sent to     33:33::2/ff02::2

Now, with the above rfc4944 step 2, are both RS and NS sent to 0xffff? 
Or only RS?  rfc4944 is silent about this, yet of paramount importance 
to implementer.

Alex
PS: there is more error in rfc4944 saying that "IPv6 level multicast 
packets MUST be carried as link layer broadcast frames" - because only 
the link-local scoped IP multicast packets should, and not the 
globally-scoped multicast packets.
PPS: there is even more error in rfc4944 requiring every byte in the IP 
multicast address (bytes 1 to 16) to correspond to "100 DST[15] DST[16]" 
because globally multicast packets (i.e. group ff0e::1) I doubt should 
be multicast at link-layer, they should be unicasted to the router.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 May 2009 17:43:24 +0200

> mapped into 0xffff, but probably into something like 0x8001.

That depends.
Section 9 addressing is explicitly for mesh-under only (section 9,  
first sentence) -- if there is an actual multicast framework under/in  
the adaptation layer, it was considered useful to map the L3 multicast  
addresses to different MAC addresses as well.
If not, all multicast maps to 0xffff broadcast.

> BEsides, it doesn't seem to say what IP address corresponds to the  
> 16bit MAC broadcast address 0xffff.  If the rule used for mapping  
> ff02::1 into 0x8001 were used to map 0xffff into an IP address then  
> that would be ff02::9f, which is different than the all-nodes link- 
> scoped multicast address ff02::1.

No, section 9 addressing only uses 16-bit addresses of the form  
100xxxxx xxxxxxxx.
0xffff is 11111111 11111111, so it is not section 9 addressing.

> whereas RS is sent to     33:33::2/ff02::2

We don't use Ethernet's 48-bit MAC addresses in 4944.
(Let's try to focus the discussion on the 6lowpan list to 6lowpan,  
please.)

> packets MUST be carried as link layer broadcast frames" - because  
> only the link-local scoped IP multicast packets should, and not the  

This is the non-mesh-under multicast case. No error.

> PPS: there is even more error in rfc4944 requiring every byte in the  
> IP multicast address (bytes 1 to 16) to correspond to "100 DST[15]  
> DST[16]" because globally multicast packets (i.e. group ff0e::1) I  
> doubt should be multicast at link-layer, they should be unicasted to  
> the router.

Not with mesh-under multicast.

Discussing mesh-under multicast is always a bit difficult because  
there is no actual system instance to discuss it relative to.
One could argue that putting currently unused functionality into 4944  
might have been premature, but it might also help commonality of any  
mesh-under multicast solutions that arise.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 May 2009 18:31:02 +0200

Thanks for enlightening about this.

Carsten Bormann a écrit :
> That depends. Section 9 addressing is explicitly for mesh-under only
> (section 9, first sentence) -- if there is an actual multicast
> framework under/in the adaptation layer, it was considered useful to
> map the L3 multicast addresses to different MAC addresses as well. If
> not, all multicast maps to 0xffff broadcast.

Let me see I understand correctly.

If mesh-under and multicast adaptation layer then:

   ff02::1 maps into 0x8001
   ff02::2 maps into 0x8002

Else:

   ffXX:X:X:X:X:X:X:X map into 0xffff

Right?

If yes I disagree with mapping all IP multicast addresses into 0xffff
MAC broadcast, because ff0e::1 global-scoped IP address shouldn't be
sent to link-layer broadcast - it may be considered noise.

>> For example NS is sent to 33:33::1/ff02::1 whereas RS is sent to
>> 33:33::2/ff02::2
> 
> We don't use Ethernet's 48-bit MAC addresses in 4944. (Let's try to
> focus the discussion on the 6lowpan list to 6lowpan, please.)

How about suggesting IEEE 802.15.4 to use Ethernet's MAC multicast
features?  Is there already an IEEE activity doing this?

>> PS: there is more error in rfc4944 saying that "IPv6 level
>> multicast packets MUST be carried as link layer broadcast frames" -
>> because only the link-local scoped IP multicast packets should, and
>> not the globally-scoped multicast packets.
> 

There is an error in sending a global-scoped IP multicast packet to a
link broadcast address - one's neighbors may have not subscribed to that
global group yet they receive the packet.

I disagree doing so.

[...]
> there is no actual system instance to discuss it relative to.

I agree!

>  mesh-under multicast solutions that arise.

It could have also been formulated as a requirement document, instead of
a hardly implementable mapping method.

Something like: if you need IPv6 to work on this adaptation layer then
the adaptation layer should be link-layer multicast capable - please
design the multicast-capable adaptation layer and tell me the multicast
addresses you're using so that I can map the IP multicast addresses onto
them...

I guess this could have solved many problems about non-transitive
single-interface multiple-linkscope routers too.

Alex

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 May 2009 19:00:52 +0200

> If mesh-under and multicast adaptation layer then:

Correct.

>  ffXX:X:X:X:X:X:X:X map into 0xffff

Correct (for valid values of X).

> sent to link-layer broadcast

That's what 4944 says, though (and it would even work quite well for a  
route-over solution with e.g. SMF).

> - it may be considered noise.

I don't understand that sentence.  Noise is an L1 concept.

> features?  Is there already an IEEE activity doing this?

I don't think we want to suggest IEEE to make the MAC layer *more*  
complicated.

> global group yet they receive the packet.

In many adaptation layers, including Ethernet, multiple IP multicast  
addresses are mapped to one L2 multicast address.  Mapping all IP  
multicast addresses to one L2 broadcast address is just slightly more  
extreme.  In any case, you have to filter at L3 as well.  (Yes, that's  
really ugly with fragmentation, but sending fragmented multicasts is  
not very useful on a wireless network in any case.)

> single-interface multiple-linkscope routers too.

You lost me completely here, but since we are not redesigning 4944  
just yet, I don't think we need to discuss this further right now.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 May 2009 21:59:23 +0200

Carsten Bormann a écrit :
>> ff02::1 maps into 0x8001 ff02::2 maps into 0x8002
> 
> Correct.
> 
>> Else:
>> 

Ok, I agree on this interpretation, thanks for clarification.

>> If yes I disagree with mapping all IP multicast addresses into 
>> 0xffff MAC broadcast, because ff0e::1 global-scoped IP address 
>> shouldn't be sent to link-layer broadcast
> 
> That's what 4944 says, though (and it would even work quite well for 
> a route-over solution with e.g. SMF).
> 

Ok, noise is an L1 concept.

At L3 what I've seen reported in the past is "ARP storm" over
non-multicast capable Ethernet links (with broadcast address 0xffffffff)
which disappeared when multicast-capable addresses (33:33:x:x:x:x)
started to appear, together with the MUST join a group before receiving
data from it, and used extensively by ND.

ND using 0xffff addresses, and nodes free from the requirement to join
groups, looks as a return to the past and its inefficiencies, maybe risk 
of "LoWPAN ND storm".

> I don't think we want to suggest IEEE to make the MAC layer *more* 

How about suggesting 802.15 subgroups to re-use the 802.3 MAC layer, as
802.16 did.  That should be more complete than the adaptation layer.

>>>> multicast packets MUST be carried as link layer broadcast 
>>>> frames" - because only the link-local scoped IP multicast 
>>>> packets should, and not the globally-scoped multicast packets.
>> There is an error in sending a global-scoped IP multicast packet to
>>  a link broadcast address - one's neighbors may have not subscribed
>>  to that global group yet they receive the packet.
> 
> addresses are mapped to one L2 multicast address.

Ok, true...

> Mapping all IP multicast addresses to one L2 broadcast address is 
> just slightly more extreme.  In any case, you have to filter at L3 as
>  well.  (Yes, that's really ugly with fragmentation, but sending 
> fragmented multicasts is not very useful on a wireless network in any
>  case.)
> 
>> It could have also been formulated as a requirement document, 
>> instead of a hardly implementable mapping method.
>> 
>> Something like: if you need IPv6 to work on this adaptation layer 
>> then the adaptation layer should be link-layer multicast capable - 
>> please design the multicast-capable adaptation layer and tell me 
>> the multicast addresses you're using so that I can map the IP 
>> multicast addresses onto them...
>> 

WEll no, we aren't redesigning 4944.  We could provide comments
on it though, it's an RFC, and it's used as basis for LoWPAN ND which is
further used by ROLL.

If RFC 4944 had a multicast-capable adaptation layer, or required 
802.15.4 to offer such, then probably the ER wouldn't be required to do 
the otherwise unnecessary proxying.

In LoWPAN ND the ER proxies ND on its egress interface, on behalf of 
each LoWPAN nodes, i.e. sending an MLD Report for each node.  Hundreds 
of thousands of such reports - why?  It would be simpler if ER separated 
the links and had two multicast-capable links.

    ---------------
   |Upstream Router|
    ---------------
          |
          |Egress
         ---
        |ER |
         ---
          |
         0  0
        0 0   0  (nodes)

>    Edge routers are introduced to scale the Neighbor Discovery
>    Operations by reducing the amount of costly multicast ND messages
>    over a LoWPAN subnet that may cover hundreds or thousands of nodes.

At the cost of what?  Moving the problem from LoWPAN to ER's Egress 
interface - why?

Alex