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


On Tue, May 12, 2009 at 11:53 AM, Burnett, Peter
<[email protected]> wrote:
> 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 protected] [mailto:[email protected]] On Behalf Of 
> Zach Shelby
> Sent: 2009 May 12 10:38
> To: 6lowpan
> Subject: [6lowpan] Terminology
>
> 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.
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> 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.
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to