[6lowpan] "Link-Local Routing" versus "Network-Layer Routing"
"Timothy J. Salo" <salo@saloits.com> Fri, 13 July 2007 20:28 UTC
Return-path: <6lowpan-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RkT-00039P-En; Fri, 13 Jul 2007 16:28:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9RkQ-0002vk-6o for 6lowpan@lists.ietf.org; Fri, 13 Jul 2007 16:28:18 -0400
Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9RkM-0006Js-My for 6lowpan@lists.ietf.org; Fri, 13 Jul 2007 16:28:18 -0400
Received: from [127.0.0.1] (mpls.saloits.com [216.243.132.62]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l6DKRrNJ011391; Fri, 13 Jul 2007 15:28:05 -0500 (CDT) (envelope-from salo@saloits.com)
Message-ID: <4697E041.1020807@saloits.com>
Date: Fri, 13 Jul 2007 15:27:45 -0500
From: "Timothy J. Salo" <salo@saloits.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: rsn@ietf.org, 6lowpan <6lowpan@lists.ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc:
Subject: [6lowpan] "Link-Local Routing" versus "Network-Layer Routing"
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org
The document "Routing Requirements for Low Power And Lossy Networks" (draft-culler-rl2n-routing-reqs-01) contains lots of good information and identifies a number of topics that require additional thought. This e-mail responds to Section 3, "'Route over' versus 'Mesh under,", which includes the following language: > Clearly routing techniques can be defined at the link layer (also > referred as to the "Mesh Under" approach). By contrast, the "Route > over" approach exclusively relies on IP routing over a network made > of a variety of nodes interconnected by links of various nature. The > aim of this document is to define the routing requirements L2Ns at > the IP layer. As such, it pertains to collections of IEEE 802.15.4 > devices, but is not limited to communication within a single IP link. > It pertains to IP level routing among multiple such PANs, routing > among IEEE 802.15.4 PANs and other links, and routing in other low > power (wireless) networks. In short, we are using a model that the 6lowpan Working Group is developing a link-layer routing protocol. Of course, being the IETF, we don't want to actually say that, which apparently motivated the creation of the opaque term "mesh under". I propose an alternative model of the 6lowpan routing activity that, I claim, fits the facts just as well as does the link-layer routing model. More importantly, this alternative model will be more useful is helping us think about and write about the type of routing being developed by the 6lowpan Working Group. The 6lowpan "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" draft specifies that the link-local portion of an IPv6 address is actually the 64-bit or 16-bit [link-layer] address used by 802.15.4. Stated differently, if I give you a 64-bit or a 16-bit address as used in the 6lowpan format document, you won't be able to tell me whether it is really an 802.15.4 link-layer address or an IPv6 link-local address (because, as specified in the format document, a particular address is used for both purposes). For that matter, the routing protocol won't be able to tell you whether the address is a link-layer or a [elided] network-layer address. In some sense, all I am suggesting is that we emphasize the network-layer use, rather than the link-layer origin, of these 64-bit and 16-bit 802.15.4/link-local addresses. Given this context, I propose that the type of routing that the 6lowpan Working Group is developing can be better described as [IP, network-layer] "link-local routing". That is, it is really network-layer routing, but its scope is restricted to a single IPv6 link. And, because the scope of this routing protocol is restricted to a single IPv6 link, the protocol transports only elided IPv6 addresses, namely only the link-local portion of the IPv6 addresses. I will try, in the next few days, to draft alternative language for Section 3 of the Culler draft that describes the 6lowpan routing work as creating a network-layer, link-local, routing protocol. -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan
- [6lowpan] "Link-Local Routing" versus "Network-La… Timothy J. Salo
- Re: [6lowpan] "Link-Local Routing" versus "Networ… gabriel montenegro
- Re: [6lowpan] "Link-Local Routing" versus "Networ… Timothy J. Salo
- Re: [6lowpan] "Link-Local Routing" versus "Networ… Timothy J. Salo
- Re: [RSN] Re: [6lowpan] "Link-Local Routing" vers… Jonathan Hui
- Re: [RSN] Re: [6lowpan] "Link-Local Routing" vers… Timothy J. Salo
- Re: [RSN] Re: [6lowpan] "Link-Local Routing" vers… Jonathan Hui
- RE: [RSN] Re: [6lowpan] "Link-Local Routing" vers… Pascal Thubert (pthubert)
- Re: [RSN] Re: [6lowpan] "Link-Local Routing" vers… Jonathan Hui
- RE: [RSN] Re: [6lowpan] "Link-Local Routing" vers… Pascal Thubert (pthubert)