Re: [Int-area] Submitted for your approval: IRON

["Templin, Fred L" <[e-mail]>]

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
[e-mail]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Templin, Fred L
> Sent: Tuesday, December 14, 2010 10:39 AM
> To: [e-mail]
> 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
> [e-mail]
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>