From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 788D921F1D2 for ; Sun, 25 Jan 2015 15:21:47 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id rl12so5949487iec.0 for ; Sun, 25 Jan 2015 15:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rm38fga9Ka8r9a6yAUKxdPNl4+wXzT5PkDp7MYrICcE=; b=G+69PTHpbAFVCDE19EYHvzxxPXuKSCxdcWc3S74lBKCw7yYytUPeb8AgJdFQbQA610 HzBd5HdSG7h4XqsUKygjRRSv4gLZaDJjK71BpyehPTdpkcAfNoFmrtH+DlGKpAc2L4r5 c4ocBBOEs+Tn/DHiDeA05+4e7wh45dp/GS8WtihoWPexQifPLU5hzCidLdxXIOVSAFzI NMn5k9YAVT+v0mqPY1O8GnLgN57q5IdJudDhI58wEz5ZepOfm11dz1FVIz5g9TDZd86E 3T4SwbfOoC+khZbr68fkc3bwbkAYVYARl82SOzjJ17TtOtfv5Tkf/rPBIbBHfrjXVn+H WNuA== MIME-Version: 1.0 X-Received: by 10.50.117.41 with SMTP id kb9mr13497671igb.37.1422228107255; Sun, 25 Jan 2015 15:21:47 -0800 (PST) Received: by 10.64.142.42 with HTTP; Sun, 25 Jan 2015 15:21:47 -0800 (PST) In-Reply-To: <1422217048.025611275@apps.rackspace.com> References: <54B5D28A.3010906@gmail.com> <7B1EA8F0-FCB6-4A37-950F-2558FC751DE8@gmail.com> <54C038D0.1000305@gmail.com> <54C0BD22.3000608@gmail.com> <54C13F47.1010203@gmail.com> <1422111577.328132080@apps.rackspace.com> <1422217048.025611275@apps.rackspace.com> Date: Sun, 25 Jan 2015 15:21:47 -0800 Message-ID: From: Aaron Wood To: David Reed Content-Type: multipart/alternative; boundary=089e011605cc1f6705050d8249de Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Recording RF management info _and_ associated traffic? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2015 23:22:16 -0000 --089e011605cc1f6705050d8249de Content-Type: text/plain; charset=UTF-8 On Sun, Jan 25, 2015 at 12:17 PM, wrote: > There is no reason why one cannot set up an enterprise network to support > roaming, yet maintaining the property that IP addresses don't change while > roaming from AP to AP. Here's a simple concept, that amounts to moving > what would be in the Ethernet bridging tables up to the IP layer. > > > > All addresses in the enterprise are assigned from a common prefix (XXX/16 > in IPv4, perhaps). Routing in each access point is used to decide whether > to send the packet on its LAN, or to reflect it to another LAN. A node's > preferred location would be updated by the endpoint itself, sending its > current location to its current access point (via ARP or some other > protocol). The access point that hears of a new node that it can reach > tells all the other access points that the node is attached to it. > Delivery of a packet to a node is done by the access point that receives > the packet by looking up the destination IP address in its local table, and > sending it to the access point that currently has the destination IP > address. > I'm not familiar with routing protocols. Do any of the current ones do this, or is this an idea for a new protocol? -Aaron --089e011605cc1f6705050d8249de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 25, 2015 at 12:17 PM, <<= a href=3D"mailto:dpreed@reed.com" target=3D"_blank">dpreed@reed.com>= wrote:

There is no reason why one cannot set up an enterprise = network to support roaming, yet maintaining the property that IP addresses = don't change while roaming from AP to AP.=C2=A0 Here's a simple con= cept, that amounts to moving what would be in the Ethernet bridging tables = up to the IP layer.

=C2=A0

All addresses in the enterprise are assigned from a common pref= ix (XXX/16 in IPv4, perhaps).=C2=A0 Routing in each access point is used to= decide whether to send the packet on its LAN, or to reflect it to another = LAN.=C2=A0 A node's preferred location would be updated by the endpoint= itself, sending its current location to its current access point (via ARP = or some other protocol). =C2=A0 The access point that hears of a new node t= hat it can reach tells all the other access points that the node is attache= d to it.=C2=A0 Delivery of a packet to a node is done by the access point t= hat receives the packet by looking up the destination IP address in its loc= al table, and sending it to the access point that currently has the destina= tion IP address.


I'm n= ot familiar with routing protocols.=C2=A0 Do any of the current ones do thi= s, or is this an idea for a new protocol?

-Aaron= =C2=A0
--089e011605cc1f6705050d8249de--