[e2e] Multiple Address Service for Transport (MAST)

[Shivkumar Kalyanaraman]

perhaps synergistic with this is a evolutionary multi-path architecture
(BANANAS) we proposed at SIGCOMM FDNA workshop this week:

http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#bananas

it has nothing to do with mobility, but could perhaps be relevant in the
emerging debate on multi-homing, multi-exit, multi-path on the existing
IP routing infrastructure...

best
-Shiv
===
Shivkumar Kalyanaraman
Associate Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
110, 8th Street, Room JEC 6003, Troy NY 12180-3590
Ph: 518 276 8979   Fax: 518 276 4403
WWW: http://www.ecse.rpi.edu/Homepages/shivkuma

A goal is a dream with a deadline -C. Knight


On Fri, 29 Aug 2003, Dave Crocker wrote:

> Howdy,
>
> I've just posted a new mobility/multi-homing proposal as an
> internet-draft to the multi6a at percival.cs.ucla.edu mailing list. The
> multi6 mailing list is the most appropriate venue for
> discussing this proposal.
>
> However, it is an end-to-end proposal that is a bit unusual, so I
> thought it worth sending a notice to this list.
>
> The I-D name is:
>
>         draft-crocker-mast-proposal-00.txt
>
> It is also available at:
>
>       <http://brandenburg.com/specifications/draft-crocker-mast-proposal-00.txt>
>
>
> Herewith the abstract for the proposal:
>
>      Classic Internet transport protocols use a single source IP
>      address and a single destination IP address, as part of the
>      identification for an individual data flow.  TCP includes
>      these in its definition of a connection and its calculation
>      of the header checksum.  Hence the transport service is tied
>      to a particular IP address pair. This is problematic for
>      multi-homed hosts and for mobile hosts.  Both have multiple
>      IP addresses but cannot use more than one, for any single
>      transport association (context).  Multiple Address Service
>      for Transport (MAST) defines a mechanism that transparently
>      supports association of multiple IP addresses with any
>      transport association.  It requires no change to the IP
>      infrastructure, and no change to IP modules or transport
>      modules in the end-systems. Instead, it defines a wedge
>      layer between IP and transport that operates only in the end
>      systems and affects only participating hosts.
>
> As the document notes a couple of times, this is an extended proposal,
> rather than a complete specification. It's being put forward in the
> current form to solicit comments about the approach and the design, and
> to find out whether folks are interested in pursuing it further.
>
> d/
> --
>  Dave Crocker <mailto:dcrocker at brandenburg.com>
>  Brandenburg InternetWorking <http://www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
>