[Softwires] FW: Submitted for your approval: IRON
"Templin, Fred L" <Fred.L.Templin@boeing.com> Fri, 17 December 2010 23:34 UTC
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA283A6B80 for <softwires@core3.amsl.com>; Fri, 17 Dec 2010 15:34:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.488
X-Spam-Level:
X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoL1qK8WfqaX for <softwires@core3.amsl.com>; Fri, 17 Dec 2010 15:34:39 -0800 (PST)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 37A753A6C62 for <softwires@ietf.org>; Fri, 17 Dec 2010 15:34:39 -0800 (PST)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id oBHNaQu6025281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <softwires@ietf.org>; Fri, 17 Dec 2010 17:36:26 -0600 (CST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id oBHNaQBR021088 for <softwires@ietf.org>; Fri, 17 Dec 2010 15:36:26 -0800 (PST)
Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id oBHNaPhW021071 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for <softwires@ietf.org>; Fri, 17 Dec 2010 15:36:25 -0800 (PST)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Fri, 17 Dec 2010 15:36:25 -0800
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "softwires@ietf.org" <softwires@ietf.org>
Date: Fri, 17 Dec 2010 15:36:23 -0800
Thread-Topic: Submitted for your approval: IRON
Thread-Index: AcuZvtMh3tC7vNZATBS1Ufdodlo+tgB/eBygAJfI/WAACc8XEA==
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C68040374@XCH-NW-01V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [Softwires] FW: Submitted for your approval: IRON
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Dec 2010 23:34:40 -0000
Fwd'd here from the intarea list. -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, December 17, 2010 11:01 AM To: int-area@ietf.org Subject: Re: [Int-area] Submitted for your approval: IRON IRON source code is now available for your testing and experimentation pleasure. A pre-IRON demonstration code using the linux ISATAP driver as a surrogate NBMA link is available here: http://isatap.com/iron/iron-0.1.tgz The code can be used to demonstrate IRON route optimization using 5 linux laptops (2 clients, 2 servers and 1 relay). The first release of the actual IRON linux kernel driver module is available here: http://isatap.com/iron/iron-1.3.tgz This code implements the VET NBMA interface model with basic IPv4/UDP/SEAL/IPv6 encapsulation. SCMP and SEAL segmentation/reassembly will be added in the next release. Comments and suggestions welcome. Fred fred.l.templin@boeing.com > -----Original Message----- > From: int-area-bounces@ietf.org > [mailto:int-area-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Tuesday, December 14, 2010 10:39 AM > To: int-area@ietf.org > Subject: [Int-area] Submitted for your approval: IRON > > Submitted for your approval, the Internet Routing Overlay > Network (IRON) is a comprehensive new routing and addressing > system for the Internet. The IRON architecture builds on the > mechanisms of VET and SEAL, and expands upon the architectural > principles established in RANGER. Relevant documents include: > > http://tools.ietf.org/html/draft-templin-iron > http://tools.ietf.org/html/draft-templin-intarea-seal > http://tools.ietf.org/html/draft-templin-intarea-vet > http://www.rfc-editor.org/rfc/rfc5720.txt > > The IRON system uniquely combines a hybrid routing/mapping system > that benefits from the both the shortest-path routing afforded by > pure dynamic routing systems and the routing scaling suppression > afforded by pure mapping systems. IRON therefore targets the elusive > "sweet spot" that pure routing and pure mapping systems alone cannot > satisfy. > > The IRON system requires a deployment of new routers/servers > throughout the Internet and/or provider networks to maintain > well-balanced virtual overlay networks. These routers/servers can > be deployed incrementally without disruption to existing Internet > infrastructure and appropriately managed to provide acceptable > service levels to customers. > > End-to-end traffic that traverses an IRON virtual overlay network > may experience delay variance between the initial packets and > subsequent packets of a flow. This is due to the IRON system > allowing longer path stretch for initial packets followed by timely > route optimizations to utilize better next hop routers/servers for > subsequent packets. Such delay variance is no different than for > routing fluctuations that can occur within ordinary Internet routing. > > IRON virtual overlay networks also interact favorably with existing > and emerging services within the native Internet. In particular, > customers serviced by IRON virtual overlay networks will receive > the same service enjoyed by customers serviced by non-IRON service > providers. Internet services already deployed within the native > Internet also need not make any changes to accommodate IRON virtual > overlay network customers. > > The IRON system operates between routers within provider networks > and end user networks. Within these networks, the underlying paths > traversed by the virtual overlay networks may comprise links that > accommodate varying MTUs. While the IRON system imposes an additional > per-packet overhead that may cause the size of packets to become > slightly larger than the underlying path can accommodate, IRON routers > have a method for naturally detecting and tuning out all instances of > path MTU underruns. In some cases, these MTU underruns may need to be > reported back to the original hosts; however, the system will also > allow for MTUs much larger than those typically available in current > Internet paths to be discovered and utilized as more links with larger > MTUs are deployed. > > Finally, and perhaps most importantly, the IRON system provides an > in-built mobility management and multihoming capability that allows > end user devices and networks to move about freely while both > imparting minimal oscillations in the routing system and maintaining > generally shortest-path routes. This mobility management is afforded > through the very nature of the IRON customer/provider relationship, > and therefore requires no adjunct mechanisms. The mobility management > and multihoming capabilities are further supported by forward-path > reachability detection that provides "hints of forward progress" in > the same spirit as for IPv6 ND. > > What does all of this mean to the intarea? It means that there is > now a unified solution proposal at hand that naturally accomodates > the growth profiles and mobility/multihoming challenges that the > Internet now faces. Moreover, it provides a comprehensive transition > to IPv6 with full incremental deployment capability and with little > or no disruption to the existing Internet. And finally, IRON is a > complete solution rather than a piecemeal combination of adjunct > mechanisms. > > IRON is therefore hereby submitted for your approval. > > Fred Templin > fred.l.templin@boeing.com > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
- [Softwires] FW: Submitted for your approval: IRON Templin, Fred L
- [Softwires] FW: Submitted for your approval: IRON Templin, Fred L