Subject: RE: [seamoby] Seamoby Charter Last Call

From: "Hamid Syed" <[email-masked]>
Date: Mon, 14 May 2001 11:05:02 -0400

Pat,

few comments on WG milestones..

-Hamid

> -----Original Message-----
> From:	Pat Calhoun [SMTP:[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). 
> 
> 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
	[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.
> Jul 01  Submit Handoff Candidate Discovery Problem Statement
> Sep 01  Interim Meeting to review Inter Access Point Context Transfer and
> 	Handoff Candidate Discovery Requirements
	[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??
> 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 09:31:00 -0700

> milestone here should reflect it.

What is the inter access point requirement I-D?

> access point ct. are we going to discuss the requirements for the next few

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.

PatC