Subject: [seamoby] Seamoby Charter Last Call

From: Pat Calhoun <[email-masked]>
Date: Sat, 12 May 2001 12:22:58 -0700

All,

Below is the proposed Seamoby Charter. The WG last call will be completed
on May 29th (given the long weekend in the US).

We had proposed to write up a set of issues that we had found with the
Mobile IP protocol, but our AD stated that this work really needs to occur
in the MIP WG. So I would ask that all interested parties take up that
activity on the MIP mailing list.

Please send any comments to the list.

Thanks,

PatC
----
Context Transfer, Handoff Candidate Discovery and Dormant Mode Host 
Alerting (seamoby) 

Chair(s):

Pat Calhoun <[email-masked]>

Transport Area Director(s): 

Scott Bradner <[email-masked]>
Allison Mankin <[email-masked]>

Transport Area Advisor: 

Allison Mankin <[email-masked]>

Mailing Lists: 

General Discussion:[email-masked] 
To Subscribe: [email-masked] 
In Body: (un)subscribe seamoby your_e-mail_address 
Archive: http://www.diameter.org/cgi-bin/lwgate/seamoby/ 

History 

During the fast handoff discussions within the Mobile IP WG, a need for a new
protocol was identified that would allow state information to be transferred
between edge devices (e.g. Foreign Agents). Examples of state information that
could need to be transferred is AAA information, security context, QOS
properties assigned to the user, Robust Header Compression information, etc. 

SDOs that work on wireless, such as 3GPP, 3GPP2, IEEE and others, are hoping 
that the IETF will be able to provide a set of protocols that will enable
them to provide real-time services over an IP infrastructure, and, along 
with Mobile IP, SeaMoby is expected to provide such protocols. Furthermore, 
the protocols developed by the Seamoby Working Group must allow for 
real-time services to work with minimal disruption across heterogeneous 
wireless, and wired, technologies.

It is expected that SDOs working on wireless technologies will provide their
input into the WG during the requirements gathering and protocol design 
phase. 

Description 

There are a large number of IP access networks that support mobility of hosts.
For example, wireless Personal Area Networks (PANs) and LANs, satellite and
cellular WANs. The nature of this roaming is such that the communication path
to the host changes frequently, and rapidly. In many situations, the change of
communications path includes a change in communications media between the host
and access networking, including changes from a wireless to a wired
connection and changes between wireless technologies even under common
administration.

Although the protocol used to actively re-direct the IP packet flows during a
change in a mobile's point of attachment is handled by other Working Groups,
there is a need for preserving the context of its active IP flows. The IP flow
context includes, but is not limited to security context, policy, QOS,
congestion indication/management, header compression and accounting. 

The SeaMoby Working group will analyze the requirements and tradeoffs for the
goal of transferring context information from a mobile's old access to the new
access point (versus accessing needed context over a distance). 

Depending on the results of the requirements analysis, the SeaMoby Working
Group will develop a protocol (or start from an existing protocol such as
Contract Net Protocol (CNP) or the IEEE's 802.11f) to transfer the context
information for a session. The context information to be transferred includes
QOS, header compression state, policy, security context, congestion management
state, AAA information, etc. Transferring context state is expected to 
provide a more robust handoff to the user, and applications. Quality of 
service (QOS) state may include both diffserv and intserv information, as 
needed. 

While other IETF Working Groups are developing protocols to provide "fast
handoff" solutions, the mechanisms currently under development are designed 
to hand off a mobile to the first available handoff candidate. The Seamoby 
Working Group has documented that "seamless" handoffs can be achieved by 
ensuring that a handoff occurs to a candidate that can best support a given 
mobile, and this work in not within the scope of the "fast handoff" protocols
being developed. Seamoby will define the work in a problem statement, and 
if needed, will define the requirements and the protocol for a handoff 
candidate discovery protocol, which could be used with any mobility 
management protocol.

Lastly, the Working Group will define the requirements for Dormant Mode Host 
Alerting (DMHA) at the IP layer (also known as IP Paging) in networks, and a
protocol will be developed to tackle this problem. DMHA is typically used in
networks that support mobile devices that periodically enter dormant mode to 
reduce power consumption. DMHA enable network devices to track a mobile that 
has moved from its last point of attachment, while in dormant mode, allowing 
the mobile's packets to be delivered.

All work produced by the Working Group will support both IPv4 and IPv6, will
follow the congestion control principles in RFC2914 (BCP41), and will undergo 
a security review prior to WG last call. 

The Working Group will coordinate closely with the aaa, cnrp, impp, mobileip,
pilc, and rohc working groups. 

Goals and Milestones:

Jun 01  Submit I-D on Dormant Mode Host Alerting Requirements
Jul 01  Submit Handoff Candidate Discovery Problem Statement
Sep 01  Interim Meeting to review Inter Access Point Context Transfer and
	Handoff Candidate Discovery Requirements
Oct 01  Dormant Mode Host Alerting Protocol to IESG for consideration as a
	Proposed Standard
Oct 01  Submit requirements analysis for Inter Access Point Context Transfer 
	Protocol to IESG for consideration as Informational
Oct 01  Submit Handoff Discovery Requirements I-D to IESG for consideration 
	as Informational
Nov 01  Candidate Inter Access Point Context Transfer Protocols
	are submitted, with accompanying comparison against requirements
Nov 01  Candidate Handoff Discovery Protocols are submitted, with  
	accompanying comparison against requirements
Dec 01  Dormant Mode Host Alerting Protocol MIB to IESG for consideration as a
	Proposed Standard
Feb 02  Inter Access Point Context Transfer Protocol to IESG for consideration
	as a Proposed Standard
Feb 02  Handoff Discovery Protocol to IESG for consideration as a Proposed 
	Standard
Jun 02  Submit Inter Access Point Context Transfer Protocol MIB to IESG for 
	consideration as a Proposed Standard
Jun 02  Submit Handoff Discovery Protocol MIB to IESG for consideration as a
	Proposed Standard

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 14 May 2001 12:57:26 -0400

James:

  A good suggestion. The original ct problem statement had
a reference architecture and terminology definitions. They
were removed for two reasons: there was too much detail in 
the problem statement, and there was still much contention
over the term "access point", even though it was clearly
defined. The latter is the important issue here. 

  I like the term "access point", and if the wg wants to give
it a specific meaning, great.

Thanks,
Gary

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Monday, May 14, 2001 12:46 PM
> To: [email-masked]; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Subject: RE: [seamoby] Seamoby Charter Last Call
> 
> 
> Gary/Pat,
> 
> 
> >> > > 
> >> > > To me, point of access doesn't necessarily imply an 
> >> actual device, but
> >> > > more of a connection point (e.g. ethernet port). Would 
> >> access device
> >> > > work better? It is commonly used in many other WGs.
> >> > 
> >> > As I tried to point out, you could call it "fred" as far as 
> >> I am concerned,
> >> > but the term does matter to some people. 
> >> 
> >> but using fred would require that people read drafts to 
> >> recognize "fred". 
> >> Please keep in mind that people that do not follow our 
> >> working group, let
> >> alone read the specs, will read the charter. These people 
> have to know
> >> what's we are up to. So my use of the word "access point" was 
> >> intended to
> >> make the charter understandable to such people.
> >> 
> >> Keep in mind that the words used in the charter do not 
> >> necessarily reflect
> >> what other words the group has decided is more appropriate in 
> >> the specs.
> >
> >No, but it would be nice if the words in the charter reflected the
> >consensus of the wg. And "access point" has been a contentious 
> >term (BUT NOT for me). If it's contentious within the group,
> >it will be contentious outside the group?
> >
> 
> 
> Maybe we need a terminology draft, or at least, define this term
> somewhere so that it can be referred to. I'm suprised nobody
> has done a generalized terminology draft for wireless terms 
> before in the MIP 
> group.
> 
> 		jak
> 
>

---

From: "Hamid Syed" <[email-masked]>
Date: Mon, 14 May 2001 13:22:07 -0400

> From:	Pat Calhoun [SMTP:[email-masked]]
> Sent:	Monday, May 14, 2001 12:31 PM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]
> Cc:	'Pat Calhoun'; [email-masked]
> Subject:	Re: [seamoby] Seamoby Charter Last Call
> 
> On Mon, May 14, 2001 at 11:05:02AM -0400, Hamid Syed wrote:
> > 	[Syed, Hamid [WDLN2:AN22:EXCH]]  I am assuming that the inter acces
> > point requirement I-D would be submitted in the same time frame.
> Probably, a
> > milestone here should reflect it.
> 
> What is the inter access point requirement I-D?
	[Syed, Hamid [WDLN2:AN22:EXCH]]  requirements I-D for context
transfer. Sorry, I tried to use the term "inter access point"as it is used
in the charter.
> > 	[Syed, Hamid [WDLN2:AN22:EXCH]]  This is kind of late for inter
> > access point ct. are we going to discuss the requirements for the next
> few
> > months??
> 
> If you believe that the charter needs to be revised, now is the time. I
> felt
> more comfortable having dates where we would end up early as opposed to
> late.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  I agree...I was just trying to
understand if there is any oustanding issue for the ct requirements I-D that
can keep us busy in the same document for next 4 months. If not, then why
not go for something in next couple of months as the WG milestone. We can
then move forward towards solutions.

	-Hamid

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 14 May 2001 12:50:32 -0500

Arthur,
 
You aren't crazy at all. A paper title'd "Just what the _ _ _ _  is this
mobility thing" would be an excellent IETF informational draft. The
exploration of the topics you mention below would be excellent content. Such
a paper would likely be a good crash course for some of the other folks who
haven't been exposed to the topics and why things should be defined as such.

Judging from the points you bring up, you do seem to have a PHD grasp on the
topic and it sounds to me like you should follow through and do it. You can
sign me up for reviewing it and providing even pre-draft feedback. 
 
My first feedback is that as you go through each peice of functionality, it
would be good to identify the particular layer that you feel each function
is appropriate for i.e. "who or what is moving" and the ramifications in
terms of functionality with the layers for each proposed solution at each
layer. You might even break the mold and discuss the ramifications in terms
of business as well.
 
Don't forget QoS interactions and your earlier "layer 1,2 - get physical"
points. I think your paper would be an excellent WG input for NSIS too.
 
The biggest problem I see is that the layer 5'ers want to do node mobilty
and the layer 3'ers want to do user mobility and the layer 1,2'ers - well -
no comment other than "vertical psychosis has been the norm for years in
some of the traditional SDOs". 
 
Thanks - this was quite a refreshing old fart.
 
Glenn

-----Original Message-----
From: Arthur Ross [mailto:[email-masked]]
Sent: Monday, May 14, 2001 11:27 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'Pat Calhoun'; [email-masked]
Cc: [email-masked]
Subject: RE: [seamoby] Seamoby Charter Last Call

At 7:09 -0700 05/14/2001, Gary Kenward wrote: 

> The SeaMoby Working group will analyze the requirements and 

> tradeoffs for the 

> goal of transferring context information from a mobile's old 

> access to the new 

> access point (versus accessing needed context over a distance). 

I understand what was intended here, but the role of the "access 

point" has been a topic of great debate. To some, an "access point" 

is a box in a specific network solution. There is no simple alternative 

(that I have been able to come up with), but in the requirements documents 

we have used "point of access" instead of "access point". 

Indeed - While I don't think that the SeaMoby charter is the right place to 

raise it, this seems to me to be a microcosm of a MAJOR ISSUE confronting 

the world if IP - one that should be addressed at the highest level, namely:

the UNDERLYING ARCHITECTURAL ABSTRACTIONS. 

<RANT> 

We talk at great length about hosts, mobile nodes, etc., but the notion of
"host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were big 

computers that filled rooms, had squads of people caring for & feeding them,
and the protocols were designed with that implicit mindset. But nowadays,
when the 

embodiments of the "hosts" may cost just pennies, may be flyspeck-sized, and
may 

be found in all sorts of non-traditional, often low-tech kinds of
places/things, 

the concepts need revision. 

My strong feeling is that the questions to be addressed should be things
like: 

* What are the entities that are the endpoints of the communication? When 

the address space is large enough [IPv6] to give every cell of every human 

being and every grain of sand on earth its own IP address, perhaps the 

model and uses of it need to be re-thought. 

* What is MEANT by "mobility"? Or alternatively what is it that is moving? 

I can envision many possible answers/opinions. 

* How are those endpoints identified for various purposes? A major example: 

paging - IP address, as in MIP, is [perhaps] meaningful for routing 

purposes, but meaningless in the application context. One could envision 

a concept whereby there are various "views" of the endpoint space 

applicable for different sorts of applications (e.g. routing, logical, 

name-based, geographic, organizational hierarchy, demographic group, 

etc.). In this light, paging/addressing might be viewed/implemented 

as a kind of distributed database query. 

* What is the nature of the "identity" associated with, say, individual 

humans, that provides the basis/data for authentication? I'm thinking 

of something like a great-grandson of the SIM card concept, for example 

[... or maybe you will begin every session with a request to "spit in the 

little spitoon" on your laptop for the DNA analysis that authenticates 

the session. ;-) ]. 

* Is a broader concept of the "addressable individual" needed? [I have in 

mind functional pseudo-persons, associated with business & organization 

roles, databases of various kinds, etc.] 

* Is a "discovery" functionality needed? I.e. a generic method for exposing 

the internal structure of subnets and/or databases? I.e. a way of creating 

the local streetmap of an unfamiliar neighborhood? This might be especially 

important if the "mobile" entities have internal, time-varying structure 

[think, for a simple example, of folks in vehicles on the highway, each 

potentially with his PDA, phone, medical monitoring device, plus the 

"smart car" itself, etc., all of which are communicating through a 

wireless gateway of some kind; just such things are currently under 

development]. 

* What are the business and regulatory models? Giant electro-political 

hot potato, but very important, IMHO. The regulatory folks need to clean 

up their act if the mythical "wireless Internet" is to be anything other 

than hype and snake oil. 

I have in mind here a complete re-think of the spectrum license auction 

notion. I personally believe that auctioning the ether was, and still is, 

a bad idea, not in the long term public interest. The pro-auction 

argument is that real estate-like ownership is a prerequisite if 

investors are going to pony up the huge capital expenditures needed to 

build the "next generation" networks. The fallacy here, IMHO, is the 

PSTN-centric mindset. If what you are talking about is universal, 

readily-available wirless IP service, starting from a telephone network 

is very obviously a bad way of doing it. IMHO wireless IP access 

should be viewed, for regulatory purposes, as more like a public utility 

than the proverbial "walled garden" for which the owner charges at the 

tollbooth. You could make a lot of money by letting someone charge for the 

air we breathe too, but in neither case is it good public policy. 

There are many aspects to this, and many ways of pulling it off, as I 

have tried to convince the FCC for some time now. 

* What replaces the "walled garden" wireless air interfaces? Good question. 

I have some opinions as to what it MIGHT be, but other opinions may 

[read: "undoubtedly will"] differ. This will be, I hope, the subject of 

this new "wireless internet" discussion group. 

Just one crazy old fart's opinion ... 

</RANT> 

[My apologies if you get this more than once due to list redundancies.] 

-- Best regards, 

-- ahmr