Subject: RE: [seamoby] Seamoby Charter Last Call

From: "Gary Kenward" <[email-masked]>
Date: Mon, 14 May 2001 10:09:13 -0400

Looks fine. Comments included below.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Saturday, May 12, 2001 3:23 PM
> To: [email-masked]
> Subject: [seamoby] Seamoby Charter Last Call
> 
> 
> 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). 

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 soltuion. 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".

> 
> 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

Why so late?

> 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: Pat Calhoun <[email-masked]>
Date: Mon, 14 May 2001 07:03:31 -0700

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

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.

> > 	Handoff Candidate Discovery Requirements

There is no penalty for being early.

PatC

---

From: Arthur Ross <[email-masked]>
Date: Mon, 14 May 2001 09:27:28 -0700

At 7:09 -0700 05/14/2001, Gary Kenward wrote:
>is a box in a specific network solution. There is no simple alternative

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