Subject: [6lowpan] link definition of rfc4861 to cover wireless non-transitive links as well

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 23 Apr 2009 21:24:11 +0200

Previous discussion indicated that link definition of RFC 4861 "Neighbor
Discovery for IPv6" is pertinent to 6LoWPAN.  I agree with it and
suggest the following 6LoWPAN definition:

    link       -  a communication facility or medium over which
                  nodes can communicate at the link layer, i.e.,
                  the layer immediately below IP (each node can
                  communicate to each other in this medium).

                  Examples are Ethernets (simple or bridged), PPP
                  links, X.25, Frame Relay, wireless links or ATM
                  networks as well as Internet-layer (or
                  higher-layer) "tunnels", such as tunnels over
                  IPv4 or IPv6 itself.

                  This is a slightly modified definition of the link
                  defined in RFC4861, in order to cover also the wireless
                  links.  Wireless links may be non-transitive (node A
                  communicates at link layer to both B and C yet B and C
                  are not on the same link).  Hidden terminal problem in
                  wireless communications is described in [reference to
                  individual draft in AUTOCONF]
                  draft-baccelli-multi-hop-wireless-communication-02

What do people think about using this link definition in 6LoWPAN?

Alex

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 24 Apr 2009 09:30:53 +0200

Hi Alex,

To answer a previous question (which RFC does the definition come from),
I think as you say the original one was from Neighbor discovery. The
definition is also present in a number of others RFCs:
RFC2460 IPv6
RFC4862 Autoconf
RFC3315 DHCPv6 
RFC4429 Optimistic DAD
RFC4436 Detecting Network Attachment v4
RFC5121 IPv6 over Wimax
...

Best,
Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexandru Petrescu
Sent: jeudi 23 avril 2009 21:24
To: 6lowpan
Subject: [6lowpan] link definition of rfc4861 to cover wireless
non-transitive links as well

                  defined in RFC4861, in order to cover also the
wireless

Alex

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

---

From: Zach Shelby <[email-masked]>
Date: Sat, 25 Apr 2009 16:00:55 +0300

Hi,

I like this, taking the RFC4861 definition and just adding the wireless 
considerations. We should also mention as part of the wireless links 
part the following:

- Wireless links considered by 6LoWPAN may not support native multicast.
- Wireless links are not static, frequent changes are to be expected 
because of radio channel fading or node mobility.

This link definition originates from the ND draft, and was just copied 
into the other drafts for consistency. I will make a ticket to update 
the link definition in nd-03. This was a good solution, thanks.

- Zach

-- 
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: Alexandru Petrescu <[email-masked]>
Date: Sun, 26 Apr 2009 21:21:32 +0200

> because of radio channel fading or node mobility.

Hi Zach,

But the definition from rfc4861 doesn't mean to ignore the 
non-static/frequent-change characteristic of the wireless links; because 
it says nodes communicate "at link layer".

Link layers do cover the non-static/frequent changes/fading channels.

Also the link definition from rfc4861 doesn't assume that link-layer 
offers or doesn't offer multicast.

(link layers of wireless links do acknowledge however that A-B-C nodes
  may form two links instead of one).

Alex