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:
RFC | Status | Title |
|
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