Hi all, I did not dig in the details, but the 16ng group had some discussions about the link definition for IPv6 over 802.16, which has similarities with our case (it is wireless): http://www.ietf.org/rfc/rfc5154.txt http://www.ietf.org/rfc/rfc5121.txt http://www.ietf.org/rfc/rfc4968.txt
They ended up with a definition which escapes the transitivity discussion: RFC 5154: Link Topological area bounded by routers, which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet as specified from [RFC4903]. Hope this helps, Julien -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Benjamin A. Rolfe Sent: samedi 2 mai 2009 18:56 To: 6lowpan Subject: Re: [6lowpan] non-transitive links and one-interface routers Hi, I may be easily confused but I think this thread might confuse the more robust thinker too. Maybe thinking in terms of context will help. Within 802.15.4 in the context of the PHY layer, "link" is used to describe a data path between two PHY entities - thus we know for, example in the definition of Link Quality Indicator (LQI) is as Zach interprets it because LQI is defined in the PHY specification clause. In the MAC specification clause, "link" is used in the context of connecting MAC layer entities. With 15.4 this is simple since the MAC "peer" is a direct neighbor, as the MAC provides no forwarding or other multi-hop mechanisms. The term "logical link" is used to describe the data path the PHY+MAC provides to the logical link control layer (LLC) above the MAC. In the 802 architecture, the OSI/RM Data Link layer maps to the LLC and the part of the MAC; the Physical maps to the PHY and part of the MAC, and 802 scope covers only Physical and Data Link layers (IEEE 802-2001 "Overview and Architecture" Figure 1). Some 802 standards provide MAC layer mechanisms supporting multi-hop (forwarding, bridging, etc). The path between two LLC layer entities may traverse multiple lower layer links. The OSI/RM is more general but consistent that a "logical link" provides the path between two network layer entities, which in the real world might encompass many Physical paths. I believe this general usage of logical link is consistent with RFC-4861 ("the layer directly below IP") but I might be wrong. Hope that helps. -Ben ----- Original Message ----- From: "Zach Shelby" <[email protected]> To: "Robert Assimiti" <[email protected]> Cc: "6lowpan" <[email protected]> Sent: Saturday, May 02, 2009 3:29 AM Subject: Re: [6lowpan] non-transitive links and one-interface routers Robert, I agree 100%, and this is the approach we have taken already for a long time in the working group. I propose we define this as a "Wireless Link", which has a different definition rfc4861 link. The link definition in the current drafts did need improvement, and we should put it in perspective of the current rfc4861 link assumptions. These architectural and terminology definitions need to go into their own "6LoWPAN Architecture" draft ASAP. This way there is a single place to work on these... they are currently in the ND draft for lack of a better place. - Zach Robert Assimiti wrote: > Hello Alex, > > Thanks for the very constructive discussion. > > It seems that we are trying to reconcile legacy IETF link definitions with > the realities of the wireless media. > > Well, I am afraid that we will need a new definition. > Looking at the definitions of a link in most wireless standards (802.15.4, > Zigbee, ISA100.11a, etc) you will find that a link in the wireless context > is quite different that a link over wired media. > > In you depiction of the three nodes, R1 communicates with R3 over 2 > wireless links (or at least what is regarded as a link in most wireless > standards). > > A wireless link is characterized typically by: > > 1. Direct connectivity between two wireless nodes > > 2. Characterized by various quality indicators > > 3. Uni-directional (R1 -> R2 is one link, and R2 -> R1 is 1 link). > Uni-directionality is typically imposed by inherent variance of quality > indicators in the wireless world. Just because R1 -> R2 have a certain > quality indicator, it does not mean that R2 ->R1 will be characterized by > the same indicator. > > > When it comes to the definition of a link, a one-glove-fits-all approach > cannot reconcile the differences (physics) between wired and wireless > medias. > > > "The nice thing about standards is that there are so many to choose > from." - Andrew S. Tanenbaum Robert Assimiti > Executive Staff Engineer > Office: [678]-202-6859 > Mobile: [404]-578-0205 > [email protected] > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Alexandru Petrescu > Sent: Thursday, April 30, 2009 8:31 PM > To: Zach Shelby > Cc: 6lowpan > Subject: Re: [6lowpan] non-transitive links and one-interface routers > > Zach Shelby a écrit : >> Hi, >> >> Alexandru Petrescu wrote: >>> Zach Shelby a écrit : >>>> Alex, >>>> >>>> Alexandru Petrescu wrote: >>>>> one-interface routers and links (again) >>>>> >>>>> Let me first describe one-interface routers as I understand are >>>>> proposed in 6LoWPAN: >>>>> >>>>> +------------------------+---------------+ | >>>>> | | 2001:db8:1::1/128 2001:db8:1::2/128 >>>>> 2001:db8:1::3/128 _|eth0 _|eth0 >>>>> _|eth0 |R1 | |R2 | |R3 | --- >>>>> --- --- >>>>> >>>>> R1 sends an IP packet to R3 but this reaches only R2. R2 picks >>>>> the packet, looks at the dst address, finds it's not for self, >>>>> consults routing table, finds a host-based route and sends it >>>>> to R3. This can work ok. >>>> Exactly, you pictured this nicely. This is how LoWPAN Routing >>>> works. I'll get back to the definition of that in your other >>>> thread. >>> Ok... >>> >>> If we say the dashed line is The Link then we're in the ND case, >>> any node can talk to any other node at link-layer, no IP routing >>> throughout. >>> >>> But if it is not The Link, and it is not two times The Link - then >>> what is it? >>> >>> What is the link definition needing a LoWPAN single-interface IP >>> router? >> The definition used in the other thread for a LoWPAN link, which in a >> wireless network may be non-transient, I think covers this case. > > The definition in the thread, inheriting from rfc4861 and other rfcs, is > _not_ a non-transitive link. That link is clearly defined as linking > all nodes in the medium: all nodes communicate at link-layer, one-by-one, > any node to any node: > >> 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 > > This says that a wireless link is also a link. The fact that "wireless > link_s_ may be non-transitive" is alleviated by the fact that "link - ... > each node can communicate to each other in this medium". > > Maybe we shouldn't use "Wireless links" above but "Wireless media" because > "link" is the term being defined. > >> Because the link is non-transient R1 and R2 can communicate, R2 and >> R3 can communicate, but R1 and R3 can't. > > A 'non-transitive' link is different from the Link definition we mentioned > above, because nodes on that link can all communicate to each other at > link-layer. That Link is not non-transitive, it is transitive. > > How would one define a 'non-transitive' link? As two serially connected > Links? This implies the middle router has two interfaces - which we don't > want. > > So, what is the definition of a 'non-transitive' Link? > > (I'm not sure how to explain this better, but we don't seem to agree). > > Alex > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > > > This e-mail (including any attachments to it) is confidential, > proprietary, legally privileged, subject to copyright and is sent for the > personal attention of the intended recipient only. If you have received > this e-mail in error, please reply to advise us immediately, delete it and > destroy any printed copies of it. You are notified that reading, > disclosing, copying, distributing or taking any action in reliance on the > contents of this information is strictly prohibited. No employee is > authorized to conclude any binding agreement on behalf of NIVIS LLC with > another party by e-mail without express written confirmation by an officer > of the company. Although we have taken reasonable precautions to ensure no > viruses are present in this e-mail, we cannot accept responsibility for > any loss or damage arising from the viruses in this e-mail or attachments. > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
