[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