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 :
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).

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.

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

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

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).)

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.

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









_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to