Current Meeting Report
Slides


2.7.2 Context Transfer, Handoff Candidate Discovery, and (seamoby)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 26-Oct-01
Chair(s):
Pat Calhoun <pcalhoun@diameter.org>
James Kempf <kempf@docomolabs-usa.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Allison Mankin <mankin@isi.edu>
Mailing Lists:
General Discussion:seamoby@cdma-2000.org
To Subscribe: majordomo@cdma-2000.org
In Body: (un)subscribe seamoby your_e-mail_address
Archive: http://www.diameter.org/cgi-bin/lwgate/seamoby/
Description of Working Group:
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 mobility devices. Examples of state information that could be useful to transfer is AAA information, security context, QOS properties assigned to the user, Robust Header Compression information, etc.

Further, Standards Defining Organizations (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.

In addition to Context Transfer, the working group has identified two more technologies that are important for use as tools for providing real-time services over IP wireless infrastructure: Handoff Candidate Discovery and Dormant Mode Host Alerting (aka "IP paging"). Another technology, micro-mobility, in which routing occurs without the Mobile IP address change, was determined by WG discussions to require research; it has been removed by the present rechartering and the topic has been addressed to the IRTF Routing Research Group. The present charter (revised from its original form) is to define and then possibly develop the three technologies. The WG will ensure that its deliverables are compatible with the Mobile IP Working Group's mobility management technology.

Context Transfer

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 chage 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 the Mobile IP WG, there is a need for preserving the context of its active IP flows. The IP flow context that might be useful to transfer could include, but not be limited to security context, policy, QOS (diffserv or intserv as needed) header compression, and accounting/AAA information.

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 device. Depending on the results of the requirements analysis, the SeaMoby WG 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.

Handoff Candidate Discovery

Second, while the Mobile IP Working Group in particular is developing protocols to provide "fast handoff" solutions, the mechanisms currently under development assume that a set of candidates has already been chosen and and that handoff should be initiated to all of them. However, the selection of suitable candidates is not part of the Mobile IP WG's overall scope. The Seamoby Working Group has documented that "seamless" handoffs can best be achieved by considering multiple handoff candidates and selecting one or more of them as targets for context transfer. This problem is within scope of Seamoby. Specifically, 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.

Dormant Mode Host Alerting

Third, 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. Protocols developed will be accompanied by MIBs.

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

Goals and Milestones:
Done   Submit I-D on Layer 3 Paging Requirements & Needs assesment
Done   Submit revised charter to IESG with any changes needed especially with respect to the micro-mobility evaluation
Done   Submit I-D on Dormant Mode Host Alerting Requirements to IESG for consideration as Informational
Done   Submit Inter Access Point Context Transfer Problem Statement to IESG
Jul 01   Submit Handoff Candidate Discovery Problem Statement to IESG
Sep 01   Interim Meeting to review pending Inter Access Point Context Transfer and Handoff Candidate Discovery work
Sep 01   Candidate Mode Host Alerting Protocol Protocols are submitted, with accompanying comparison against requirements
Oct 01   Submit Inter Access Point Context Transfer Protocol Requirements 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
Jan 02   Dormant Mode Host Alerting Protocol 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
May 02   Dormant Mode Host Alerting Protocol MIB 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
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC3132 Dormant Mode Host Alerting ('IP Paging') Problem Statement
RFC3154 Requirements and Functional Architecture for an IP Mobile Node Alerting Protocol

Current Meeting Report

Milestone review

------
Paging Assessment Update

Four volunteers, each assigned a different protocol proposal.
There was an effort to calibrate the results across assessments.

All protocols had good points; all had problems.
Security was a particular problem.
- Some recommend IPSEC, some new, details lacking.

draft-ohba-seamoby-last-hop-dmha-02.txt
+ Good ...
- Ties paging agent directly to last hop subnet, so no subnet-independent

Q: The second item is not correct because we don't mention subnet-dependent PA. The PA in our protocol can go anywhere.
A: OK.

draft-koodli-paging-00.txt
+ c

draft-sarikaya-seamoby-mipv6hp-00.txt
draft-guri-seamoby-lahap-00.txt
+ Good layer 2 integration
- No v4 support

Q: Was combining these a good idea? These were completely different proposals.
A: That is a fair statement. We'll cover it later.
Behcet Sarikaya: Do you have any slides on draft-guri-seamoby-lahap-00.txt?
James Kempf: No.

draft-renker-paging-ipv6-01.txt
+ Lots of details.
...

Next Step recommendations
1) another round of assessments or
2) Start work toward common protocol -- Allison et al

Marco Leibsch will be the draft editor.


Q: How should contributors put in recommendations.
A: If it is short, send it to the list. If it is lengthy, contribute as an ID.
Pat Calhoun: Rather than having folks submit draft, people should submit proposed text to the list.

Q: How will we incorporate material from the other drafts?
James Kempf: Look at the assessment draft and see what is missing from the
Renker draft and submit the relevant pieces of the other drafts as changes to specific sections.
Pat Calhoun:Assessment draft going to last call.
Jari Malnin: Last call will be a good idea for reviewing the assessment draft. Especially the security area needs a lot of attention.

ACTION ITEM: WG chairs will find somebody to do security assessment.

Q: Question about unifying ideas and the feedback of the assessment. Are the comments going into the 2nd version of the assessment?
A: The assessment draft is complete as it is. People can submit proposals during last call for changes.

-----------
CT Problem Statement

There were MAJOR comments from the IESG. It is going back to the IESG after WG Last Call completes.

------------
General Requirements for Context Transfer

There were a LOT of comments which we did NOT accept. Some changes were substantial so this doc will go through ANOTHER WG last call.

...
Section 4.13 expanded greatly.

Q: Is WILL NOT part of the standard terms?
A: No, is SHOULD be a MUST NOT.
Q: So if the CT solution verifies the CT info prior to transfer it is NOT acceptable?
A: We'll take that up on the mailing list.

New requirement
4.16 The CT solution MUST include methods for interworking w/any IETF IP handover solution.

4.17 The CT solution MUST be scalable.

Pat Calhoun: That's kind of hard to quantify...
Scott Bradner: 3.5lbs of scalability.

------------
CT Next Steps

Follow the same process as DMHA
Due date for protocols is Feb 1st/

These dates give time to submit an ID in time for IETF-53.

Pat Calhoun: Are there things we should change about the DMHA process?
James Kempf: We REALLY encourage people to volunteer. We really appreciate the volunteers who worked through the assessment process.

---------
CAR Discovery Issues update
dis-cardiscovery-issues-01.txt

What's CAR discovery?
- Discover AR's that an MN can hand over to.

Changes from 00.txt
PAAR -> GAAR
New section to to illustrate GAARs separated by several domains
Example scenarios to justify CAR
New section demonstrating that existing protocols don't do this

Requirements:
MUST: L2 id -> L3 id.
MUST L2 devices of different technologies.
MUST: L2 devices in private/site-local spaces.
MUST: Capability communication between GAARs.
MUST&TBD: Standard format for capabilities.
SHOULD: Protocol applicability -- Interdomain as well as Intra-domain scope.
MUST NOT: Introduce new network elements for CAR discovery.
SHOULD: Minimize involvement of ARs which are not GAARs in CAR discovery.
MUST NOT: Depend on particular mobility protocol.

Q: Support for L2 devices in private/site-local spaces makes no sense at all.

A: We think it can be done.

Phil Neumiller: You might consider a new requirements. We have MANET and MIP and there is very little bridging. This could fill this gap.

A: So you want to support mobile routers also?

PN: We don't want to preclude mobile ARs.

A: I don't think we preclude that now, but if you want to add a SHOULD for that we could do that.

Pat Calhoun: Looking at requirements I see something that's not on there.

The mobile provides its view of the network. There are some DoS attacks possible from this.

A: I don't see why we need to preclude that. If the MN's are suitably authenticated, it should not be a problem.

PC: Authentication is not the issue. An MN can still inject erroneous information about what the network looks like.

Scott Bradner: It is a long policy in the IETF for nodes not to know about network topology. It would have to be a REALLY GOOD idea to take advantage of MN knowledge of network topology.

James Kempf: Are you talking about Localized Mobility Mangement?

James Kempf: It sounds like there may be some overlap w/MANET.

Phil Neumiller: MIP and MANETs are going to collide. This is an ideal place to deal with these requirements.

Pat Calhoun: Is Scott Corsen (co-chair of MANET) here? Do you know anything about this work?

Scott Corsen: Right now there is no specific item for this work. There have been submissions but none have been accepted.

PC: Any work that people try to submit there should be redirected to here.

Concensus call:
SHOULD to MUST for Inter domain as well as Intra-domain scope?
[plenty of hands in support, none in dissent]

Slide discussion on issue involving MN detection of network topologies:



Pat Calhoun: (Draws diagram with overlapping circles to represent service areas).

A malicious dot (representing the MN) tells local cells about far away cells. This could "confuse" the local cells.

Some discussion about how critical the problem is, and discussion on possible solutions.

James Kempf: There is clearly a problem to be solved.

Scott Bradner: Once you start down the path of letting the MN know about topology, it gets you into the problem of what path to take and you don't want to go there.

Comments about whether or not MNs do continuous scanning.

Comment from an author: Neither proposal has this problem.

Security association discussion...

George Tsirtsis: What is the usefulness of know somebody is a neighbor other than to create an SA? Hesham Soliman: I am very concerned that the direction to go is to have routers discover for each other, but we've found this doesn't scale. Why doesn't each router just advertise for itself?

Pat Calhoun: It sounds like there are a lot of people who need to read and comment on the problem statement. We appear to be trying to discuss multiple problems.

Ajoy Singh: I don't see that we have a strong scaling requirement.
This is how CDMA and GSM work today.

In the "Slide discussion on issue involving MN detection of network topologies:" discussion thread, there was the following point made:

- MN providing information to AR in order to aid CAR discovery is not to be precluded, if such a protocol does not compromise security and reliablity of information.


------------
CAR Next Steps

We wanted avoid a lengthy requirements phase, but that's sounding like it might be a problem.

Is everybody comfortable with the requirements discussed?
Comment: If we add the MANET issues we should be OK.

Discussion about inter- v.s. intradomain discovery.

George Tsertsis: Automatic discovery of AR's from separate domains is not a GOOD THING.

The discussion ended with moving this issue to the list.


-------
Following stuff has to happen before IETF-53

DMHA Protocol Design First Draft
CT Protocol Submission Complete and base Protocol Selected
CAR Problem Statement and Requirements Complete

Meeting adjourned at 10:15 Mountain Standard Time.

Slides

Agenda
General Requirements for Context Transfer
CAR Discovery Issues Update
Seamoby Paging Protocol: Assessment and Next Steps