Fwd'd here from the intarea list. -----Original Message----- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, December 17, 2010 11:01 AM To: int-a...@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.temp...@boeing.com > -----Original Message----- > From: int-area-boun...@ietf.org > [mailto:int-area-boun...@ietf.org] On Behalf Of Templin, Fred L > Sent: Tuesday, December 14, 2010 10:39 AM > To: int-a...@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.temp...@boeing.com > _______________________________________________ > Int-area mailing list > int-a...@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list int-a...@ietf.org https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
