Subject: [Tsvwg] architecture for transport layer mobility

From: Wesley Eddy <[email-masked]>
Date: Fri, 8 Oct 2004 14:37:02 -0400

At the San Diego meeting last August, Allison closed the meeting by
talking very broadly about hosts having multiple addresses, and how this
affects the transport layer [1].  One of the potential uses is for
handling host mobility at the transport layer.  This has been done
experimentally several times in several different transport protocols,
but not within any specific unified architecture.

For example, over the years there have been mobile SCTP, TCP, and DCCP
proposals that all have used different code for supporting movement
detection (finding out when the local host has moved) and doing location
management (providing some way for the mobile node to be reached for new
connections).  These are two common problems for all transport layer
mobility protocols, which happen to be independent of the particular
transport protocol used.  It makes sense to define a common framework to
provide this functionality, so that individual transports don't have to
worry about it.

As a first step, we've begun exploring a simple architecture to provide
these two services using existing standards (eg neighbor discovery,
dynamic DNS, etc), and described our architecture in:

http://www.ietf.org/internet-drafts/draft-eddy-tlmarch-00.txt

We would appreciate any feedback from the community on this, and would
welcome the opportunity to speak breifly in Washington if the group is
interested.  We feel that while there is little new here, providing the
common framework for transport protocols to easily develop mobility
support with little replication of effort, is an important step.
Additionally, this draft attempts to provide a detailed comparison of
the architectural differences between transport layer mobility and
Mobile IP, the predominant mobility protocol which operates at a
completely different layer and has different deployment and stack-design
considerations.

-Wes

[1] See meeting notes at http://www.ietf.org/proceedings/04aug/261.htm
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Fri, 08 Oct 2004 13:11:05 -0700

This work is being explored in the Multi6 WG; it might be useful to 
check with their current state.

In particular, one of their early conclusions was that there were 
multiple layers at which this problem _could_ be fixed (transport, net, 
shim under net, etc.), but that some were more appropriate than others 
(I think they concluded that transport solutions to mobility weren't as 
useful in the general sense since they need to be recapitulated for each 
transport design).

Joe

Wesley Eddy wrote:

> ------------------------------------------------------------------------
>

---

From: "Seok J. Koh" <[email-masked]>
Date: Mon, 11 Oct 2004 09:47:58 +0900

Hello Wesley,

I think this kind of work will be very useful so to foster the further refinements
of the existing several approaches for transport and network layer mobility.
Basically, this will help service providers offer a lot of mobility solutions to users.

Two minor comments on your draft:
1) We may consider SIP (session initiation protocol) as a candidate location 
management scheme in the application layer

2) As such, a transport layer mobility may be used tegether with the other network 
or application layer mobility schemes such as Mobile IP and SIP, if necessary.
On use of MIP and mSCTP, you might refer to this I-D.
http://www.ietf.org/internet-drafts/draft-sjkoh-mobile-sctp-mobileip-04.txt

Seok J. Koh
http://protocol.knu.ac.kr/

----- Original Message ----- 
From: "Wesley Eddy" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, October 09, 2004 3:37 AM
Subject: [Tsvwg] architecture for transport layer mobility

-Wes

---

From: "Seok J. Koh" <[email-masked]>
Date: Mon, 11 Oct 2004 10:00:15 +0900

Hi Joe,

> useful in the general sense since they need to be recapitulated for each 

The above opinion may come from the network-layer point of view.
We note that the Transport Layer Mobility (TLM) does not try to add 
a new transport protocol just for mobility. Instead, we consider the case 
in which the user's host (and its peering server) are already equipped with 
the newly developed transport protocol such as SCTP or DCCP.

The point is that in this case, the SCTP, DCCP or any new scheme could be
used for supporting the mobility, possibly with the other existing schemes 
(such as DDNS, MIP, SIP, etc)

Regards,

Seok

----- Original Message ----- 
From: "Joe Touch" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, October 09, 2004 5:11 AM
Subject: Re: [Tsvwg] architecture for transport layer mobility

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 11 Oct 2004 12:01:02 -0400

> the newly developed transport protocol such as SCTP or DCCP.

Right.  The main idea behind the draft was that we boil "mobility
support" down into three components:

1) movement detection - using mechanisms like link triggers, neighbor/router
discovery, etc to determine when a new network is available, and using some
form of autoconfiguration to obtain an address and routing configuration.

2) location managment - maintaining some globally reachable "address".  In
Mobile IP, it's just the IP address.  In this draft, we use the hostname in
DNS, which may be preferable for a number of reasons.  Other proposals use
SIP, or a "host identity", etc.

3) binding updates - transport protocols are bound to some address, and
if the location management is such that the address changes with
location, then bindings need to be updated to maintain existing
connections.  Some congestion control state should be reset too for new
paths, etc.

We view #1 and #2 as independent of individual transport protocols.  These
are services that an operating system or daemon can handle in one place.  The
only modifications that transports have to support in this architecture are
some form of #3, which are mechanisms like ADDIP and Change Primary in SCTP.

In short summary, our goal was to combat precisely the problem that Joe
brought up of every transport having to be modified, by making the
required modifications as light as possible, while avoiding burdening the
infrastructure with warts like HAs, FAs, and handover-smoothing goop.

-Wes

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Oct 2004 10:21:17 -0700

Wesley Eddy wrote:
> We view #1 and #2 as independent of individual transport protocols.

My point is that Multi-6 views #3 as independent of transport protocols 
as well, and that they have a number of documents discussing 
alternatives for #1, #2, and #3.

> These

One issue is whether to burden the infrastructure with mobility support 
or to burden each transport protocol implementation. I like the idea of 
minimizing the impact on transport protocols, and certainly 
orthogonalization is a step in the right direction, but is this _really_ 
something that needs to happen at the transport layer?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Oct 2004 10:24:03 -0700

> The above opinion may come from the network-layer point of view.

It came from a discussion about the desire to have a single solution,
rather than to proscribe requirements for each new protocol being 
designed, as Eddy is doing. It's simpler to fix a problem once than to 
provide a set of 'rules for current and future protocol mods'.

Yes, it does come from the view that the network provides one set of 
services, and the transport provides a different set of services. And 
that the complexity of a network layer solution isn't different from 
that of a transport solution, except that a single network solution 
could be used by multiple transport protocols, and that the same is not 
true for transport solutions.

> the newly developed transport protocol such as SCTP or DCCP.

That works only where _each_ new protocol has support for mobility. Any
new protocol would need to incorporate mobility as well.

> (such as DDNS, MIP, SIP, etc)

There can be interactions between schemes implemented at multiple layers
as well.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 11 Oct 2004 13:46:35 -0400

On Mon, Oct 11, 2004 at 10:24:03AM -0700, Joe Touch wrote:
> >in which the user's host (and its peering server) are already equipped 
> >with the newly developed transport protocol such as SCTP or DCCP.
> 

Not really.  Transports are build to suit classes of applications.  View
"robust to mobility" as we would other transport features like "ordered
byte stream", "congestion-controlled", "reliable datagram service",
"multi-streaming", etc.  We don't put features into transports for
applications that don't want them (at least we shouldn't).  Just because
SCTP does multi-streaming doesn't mean we now have to build it into TCP
...  TCP applications figure out their own way to do that if they have
to.  Mobility could work similarly, either use a mobility-robust transport,
or do it yourself at a higher layer (if your application wants it).  In
this case, we'd only be building the binding updates into transports for
long-lived types of applications that we expect mobile hosts to use.
That may or may not be a large group of protocols.

Building mobility support too low, as in the network layer, is a
*terrible* idea, as it has unforseen consequences at higher layers that
haven't been built with mobility specifically in mind.  As evidence, TCP
congestion control can be observed to exhibit quite inappropriate
behavior when Mobile IP moves a host between two widely differing
networks.

-Wes

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 11 Oct 2004 14:00:12 -0400

> alternatives for #1, #2, and #3.

Yep, I think there is room for a lot of views here though, given the number
of layers and slots between layers where people have been cramming mobility
schemes.  Certainly some are more palletable than others ...
 
> something that needs to happen at the transport layer?

A question I think is better: Given the Internet architecture, where is
the best place to build mobility support?  Or: How can we build mobility
support into the architecture without screwing it up?

-Wes

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Oct 2004 11:09:28 -0700

> On Mon, Oct 11, 2004 at 10:24:03AM -0700, Joe Touch wrote:
....
> behavior when Mobile IP moves a host between two widely differing

That can be said of any transport layer service, given particular link 
conditions; e.g., TCP works horribly over paths that have wireless hops. 
Does that mean we need TCP to be aware of wireless hops? Or does that 
mean that we should have a link that 'plays nice' (ala the recent PILC BCP).

TCP and other transport protocols need to know addresses, and thus 
address mobility, only as an artifact of using the address as a 
connection identifer. IMO, mobility support should happen at the network 
layer; if the transport layer needs to detect and adjust to changing 
path properties, then make it more agile or deploy sub-path enhancements 
to 'play nice'.

Much of the rest of this overal direction seems to be pushing transport 
protocols to provide telco-like services (rapid handover, etc.); IMO, 
being different from telco-service is the defining useful property of 
the Internet, not something to be 'patched over'.

Joe

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 12 Oct 2004 08:58:42 +0200 (CEST)

Hello
 
the mobility support is becoming a hot issue.
The mobility is always more request from people,
but when we think mobility in Internet 
 
IMO we can't forget
1) the telco approach: continuity in communication or if you want in session, especially for real time application
2) the congestion problem... if we change network, maybe we change the throughput too, the link capacity and other...
3) the security problems... there are some good papers about all the possible intrusion made take advantages from mobility

/Sal

Joe Touch <[email-masked]> wrote:

....

Joe

> ATTACHMENT part 1.2 application/pgp-signature name=signature.asc

---------------------------------
Nuovo Yahoo! Messenger E' molto più divertente: Audibles, Avatar, Webcam, Giochi, Rubrica… Scaricalo ora!