Current Meeting Report
2.7.2 Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting (seamoby)
NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It
may now be out-of-date. Last Modified:
Pat Calhoun <email@example.com>
James Kempf <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Allison Mankin <firstname.lastname@example.org>
Transport Area Advisor:
Allison Mankin <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: (un)subscribe seamoby your_e-mail_address
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
that could be useful to transfer is AAA information, security context,
QOS properties assigned to the user, Robust Header Compression
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
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
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
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
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
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
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|
Request For Comments:
|RFC3132|| ||Dormant Mode Host Alerting ('IP Paging') Problem
|RFC3154|| ||Requirements and Functional Architecture for an IP
Mobile Node Alerting Protocol
Current Meeting Report
Seamoby Working Group
Thursday, March 21st, 3:30PM - 5:30PM
[Editor's note: When I did not know a name, I used someone, or some guy. When two or more people whose names I did not know were talking, I tried to be consistent with the tags. I inserted [too fast] where the minute taker's buffer got full, and subsequently dumped]
John L : Wants a hum to ask for consensus that we are happy with the direction we are going in. (Process), basically.
David [IEEE guy]: What direction are we going on, in respect to 802.1f
Pat said he would get Bob involved.
Jim said he would go to the 802.11 meeting in July to inform them of what's going on here.
[General "Who's going to be on the design team" comments]
AD[but not Allison . . ]: If your design team is not the whole WG, there will be complaints.
Jim: I understand.
George: Wants information provided to the whole group when standards bodies or other companies start driving processes that affect us.
Allison: If it is going to be an RFC then it will come back here, but joint ventures usually fail.
Chairs: We just don't want to duplicate effort. (As in EAP)
Pat: Input was provided to IEEE during the ballot process, but it was ignored.
David: 11f passed ballot, and is going through re-circulation ballot. Between the two of us (Pat + Bob) and Dave, we will keep up with the proceedings in 802.11
Heesham wanted a question mark removed. Jim explained what a question mark was.
Allison: [re comments of where things are going] Interest of IESG. Informational documents. She's going to straighten it out.
******* Marco Liebsch - NEC Heidelberg
******* DMHA design issues & framework discussion (IP Paging)
Current Design Issues
RFC 3154 requires mobility independence + support for existing protocols.
Different paging protocol for each mobility protocol
Problems: Ignores 4.7 for RFC3154, will have different extensions.
Advantages: Takes advantage of mobility specifics for IP paging
Dormant mode location tracking as well as paging trigger packet detection is part of paging, and independent of the mobility protocol.
Problems: Mobile node has to keep track of two bindings of location information. There are stateful entities in the DMA and TA . . fail-over becomes complicated. Security between mobile host and TA/DMA
Advantages: It's a cellular/VLR like system with active mode location maintained by the mobility protocol and dormant mode location maintained by the TA in foreign network. Allows having DMHA separated from mobility, but has strong requirements on fail-over handling. IP paging separated from mobility management. Allows flexible deployment of DMA function.
Partition the protocol into a core mobility protocol independent part and a separate mobility protocol dependent parts.
Problems: Distributed functionality . . . SA is distributed.
UNABLE TO UNDERSTAND NAME: Proposal 3 looks simpler, but it really has higher signaling requirements. He claims to have data to support his claims.
Problems: Mobile may have to leave dormant mode to update SA.
What happens if the mobile host has multiple interfaces? Some which use an IP mobility protocol and others don't?
May require the host to wake up from dormant mode when it moves paging area
Additional security association between DMA/TA and PA required.
Keeps location info and state maintenance in one node
Implicit SA between MN and mobility agent could be taken.
Easier fail-over handling.
ANY COMMENTS? -- none
Mode 1: DMA received paging trigger packets (is tunnel end-point)
DMA is distributed
Heesham: Wanted clarification that DMA could be an alternate CoA.
Heesham: Have you considered the security issues of doing that? What about a return routability test?
Speaker: For the registration?
Heesham: Will you use the DMA as an alternate CoA? Would it be able to request another binding?
Speaker: We assume that the binding does not exist when it's in dormant mode.
Heesham: I don't think you can take it for granted that this will work.
Speaker: I agree with you that we need to take care of this.
Problem: Unnatural paging trigger packet processing at DMA having the HoA as MN identifier within IP-IP encapsulated packets
Problem: Is there a risk of getting routing loops in case of not synchronizing binding caches.
Mode 2: DMA in Capturing mode (distributed on routers)
Requires a protocol between distributed DMAs and Tracking Agent additional security association between DMAs and TA.
More distributed approach, efficient fail-over handling required.
Allowing both modes to be deployed would allow high degree of flexibility.
Heesham: [Some question I didn't quite catch]
Heesham: If I'm on link A, and I'm dormant and move to link C, how does it send the packet to me on the link that I'm on?
Heesham: So, you're mapping paging areas to links or subnets?
Speaker: The mobile node has to send paging area updates to the tracking agent every time it moves.
Heesham: So, if you have to do a paging update, why don't you just send a binding update?
Chairs: We're not doing only mobile IP. This protocol is designed to work even if you're not using mobile IP.
Heesham: [doesn't seem to understand]
Speaker: Let's take it to the list.
Question: Support for different IP versions?
Implementation consideration: What's to be handled in the kernel, what can be in user space?
Some guy: I don't understand either of these questions. Do you mean application layer?
John: Comment about first question: I think most of us realize that IPv6 will be deployed in mobile environments fairly soon. And applications should be able to support both v4 and v6 (since v4 will be around for a while longer)
How to handle individual paging areas and meet RFC 3154 requirements.
Jim: I think this is a very interesting issue, and worth looking into. I think it might be like host routes, and very hard to implement, but it's definitely worth looking at.
In General: Allow stationary hosts go dormant and to use paging?
More specific: DMHA filtering vs filtering for DMHA
Allow routers to enter dormant mode and to use paging?
Signaling over UDP equivalent to "application layer signaling"
Appropriate mechanism for fail-over handling w.r.t support of robustness
Improvement on support of hosts having no explicit L2 paging Security support - as soon as the framework is agreed on, appropriate solutions should be studied and specified.
We can discuss all this on the list. We need to start on draft-ietf-seamoby-dmha-framework-00.txt
We've been talking about paging quite a bit
If we focus on one topic, we'll get good technical discussion. Example: Mipv6 security discussion.
Relation to seamoby: 3 technical topics currently, all of which are a significant amount of work.
So: we need to focus on one.
We're going to drop DMHA. We encourage a DMHA bof at the next ietf.
Pat: We're at a point where we're building 3 protocols, and we need to free up cycles.
George: But it's been so much fun.
Steve Deering (mystery guest) - CAR discovery
I was asked to look at the two drafts on CAR Discovery, and was asked, as an old IP bigot to look at them (from an IP level). I'm nervous about this because I have no background in the problems you're trying to solve.
Part of being an IP guy is to avoid contamination about L2 things. (L2s come and go . . IP is forever)
I don't see how network controlled hand-off can handle the technological and administrative heterogeneity and scale of the Internet.
Heesham: I've been trying to say the same thing for so long.
A mobile node may have as CARs many different kinds of routers
public cellular routers
one or more wireless lan ARs
one or more ARs accessible over wired links.
one or more ARs accessible over satellite links, infrared links, etc.
there's a potential for many access routers to be visible
The notion that your CAR will look at the list and make the decision for the mobile is absurd. (It can't possibly scale)
No one AR can make the complex multi-dimensional trade-offs entailed in deciding when to move and where to move. (price / usability / etc)
The only entity in a position to know the existence of all the possible CARs is the MN itself. (It could collect them all and "tell" the AR but . . )
The only entity in a position to know how to weigh the various attributes offered by the CARs is the human using or owning the MN
Challenging enough to figure out how to teach the MN how to do automatic selection.
Crazy to think about teaching every AR with which the MN establishes a transitory relationship.
Placing authority in the MN, instead of current AR, seems the obvious solution, and conforms to (at least some) IP "principles" (eg, "smart host, dumb network", "end-to-end" the effectiveness of the MN's decisions will depend greatly on the quality of the information that it can acquire about it's CARs
An AR or a group of ARs under common or collaborating operators may well be able to provide info to let the MN take operator's desires into account. ("please move to ARx ASAP" the "seamlessness" of the hand-off will depend on the willingness of a current AR to provide context transfer to an MN requested next AR.
CharlieP: I'm curious: couldn't in some cases the AR's decide where you're going?
Deering: Yes, see the sub bullet. But, it can't do anything other than ask the mobile . .
Charlie: What if the AR kicks the node out, and moves it to another AR.
Deering: It could, but the mobile doesn't have to accept it. It AR can't know what all ARs the mobile has access to.
Charlie: Yes it does.
John: Generally, nodes do not participate in routing. I can see that that can be a role in CAR discovery.
Deering: I wouldn't generalize this as a mobile node participating in routing.
George: I think you're right to ignore the link layers. But, there could be a link layer that lets you talk to multiple ARs at a time. Or, there could be a link layer that only lets you talk to one. You can possible solve the problem at the IP layer, but you can't ignore the specifics o f the link layer.
Someone: Automatic selection very difficult to do, but it really depends on what the situation is.
David: At least in one homogeneous link layer (802.11) You can't have another access point tell you what to do. What happened last week in the 802.11 meetings, they're further going down the path that the mobile is controlling itself (not the network controlling the mobile)
Deering: Are the CAR documents intended to allow mobile to 802.11 networks? If so, then they don't work.
Heesham: Network control vs mobile control - the reason from deviating from the mode where the mobile sent the packet from the router . . . we should make this a general policy.
CAR Discovery Requirements
Do you still want to hear these requirements?
One small note There was a small change to the issues draft. There is now a time based classification of Anticipated . . . [too fast]
The requirements discussed henceforth in this talk are meant to be satisfied by ANY CAR DISCOVERY solution. These requirements are not specific to a particular solution.
1) Mapping AP identifiers to IP addresses of ARs.
Once an AP identifier is forwarded as an input to the CAR discovery protocol, it MUST map the identifier to the IP address of the AR which the AP is connected to.
Deering: So, my cellular router is going to tell me the IP address of an 802.11 AP that I just found?
Heesham: We need to clarify this requirement more.
Requirement 3: SUPPORT FOR HANDOFFS FROM PRIVATE AND SITE LOCAL ARs
Needs to be separated for ipv4 <-> ipv6, sitelocal ipv6 -> ipv6, public ipv4 private ipv4 and combinations of above
Comment: Too many combinations.
George: Doesn't this degenerate into the problem of communicating between all these things. This isn't relevant to CAR in particular.
Speaker: The discussion started because of the question that [too fast]
comment: What about the different cases where the identification is necessary? And, the ARs could be on different spaces. It just makes the text longer.
how many people are for the requirement?
Deering: The mobile needs to be able to identify it's CARS, but whether or not the ARs need to identify each other isn't clear. So, what do you mean?"
Guy: Must identify IP address won't work because it could be an IP address in a private space.
Heesham: Mention the entities involved, because right now it is too confusing.
Jim: We've talked enough. Let's take it to the list.
Pat: We've been going down one path, and Steve's brought up an alternative. (Try to get the mobile node to participate). Rough consensus: yes
Jim: We need someone who has time to donate to do this.
Guy: We already have the problem description.
Michael: In San Diego we had a draft called <> with network initiated and mobile node initiated transfers. What happened? What religion overtook this group to make it happen now.
Pat: Steve is very inspirational.
Some guy will do requirements document.
John: I do not think the thing Steve was asking for was to have a document with the union of all possible ideas in it.
Jim: Should we drop the network model? (3 hands)
John: I'd like to suggest that there are people interested in both models. We can have a pseudo draft, not a WG draft, to start some discussion.
Michael: most of the applicability of a document like this is for a homogeneous case. But, our application is probably not going to be homogeneous . . I just wanted to be very clear that in a particular case for homogeneous network transfer is probably the best way. I don't want to preclude that case.
Steve: Same thing. There are times when information from the ARs might help the mobile node make a better decision. I wasn't advocating killing this work, but it just needs to fit into a basic model.
Jim: there is some considerable amount of evidence that information from the network helps to optimize mobile IP. What I'm saying is that there is some indication that network assistance is helpful, but in inter technology situations it may not be available.
Requirement 6: SCOPE
People were not too sure about interdomain. People now want interdomain to be a must too.
Jist of it: Stay a SHOULD.
New Requirement 1:
PROVIDING MN's REQUIREMENTS FOR DETERMINATION OF CARS:
The car discovery solution must provide a means for the MN to express it's requirements for the determination of CARs. The MN preference solution should be logically separate from the CAR information distribution solution in order to maintain separation of security requirements.
Heesham: Something about QOS. So . . . what kind of list will the mobile node provide to this router? It sounds alright but the realization sounds quite difficult.
Speaker: A simple case would be: "I want to watch a porno site, do you allow it?"
Guy: It gives ultimate control to the mobile node to decide where it's going .. .
Someone: The issues draft matches the requirements . So, that's why it's here.
Pat: Steve is saying the network provides information and the node selects. This seems opposite.
Someone: It doesn't say that there is a transfer of requirements from one box to another.
George: Heesham was right when he said, you need to state "how far are you willing to go"
Heesham: And, what kind of privacy and confidentially.
Guy: The line here is that there is a problem and a harder problem. This as it stands is well worded. too fast.
New Security Requirements
CAR discovery MUST ensure that the AR claiming to be it's GAAR is a genuine AR
CAR discovery MUST/SHOULD ensure that this genuine AR is it's GAAR.
Steve: People keep saying that this is neutral as to who is making the solution, but that says that the AR has to be genuine. Why does it have to be an AR? It could be a mobile.
Security Requirement 2
A solution to CAR discovery MUST provide means for secure capability exchange between AR and it's GAARs.
Someone; It would be better to add MN/AR to not bias the solution (like Steve Said)
Security Requirement 3
A solution to CAR discovery MUST provide secure means for the expression of MN requirements to car [too fast]
Security Requirement 4 -- too long.
Security on CAR information capabilities distribution MUST conform and interoperate with existing IETF security policies and protocols on the security of routing information distribution. Security on communication of MN preferences to ARs must conform and [too fast]
Requirement 5 - FORMAT OF CAPABILITIES
The capabilities MUST be described in a standard format which is TBD.
George: This needs to be modular. but you will probably end up defining some minimal capabilities. Then you need a VERY big vendor specific space :)
Guy: Time to define the formats? There is already work being done in this area. We need to start out with a study about what's already available in the market.
DEPENDENCE ON A MOBILITY MANAGEMENT PROTOCOL
CAR discovery MUST NOT depend on a particular mobility [too fast]
Requirement 10 EFFECT OF CHANGES IN NETWORK TOPOLOGY
A CAR discovery protocol MUST be adaptive to changes in physical topology as well as logical topology.
George: What does it mean?
Heesham: I don't understand it either.
If ARs are used to handle hot spots.
New Requirement 2 - RE_USE OF EXISTING PROTOCOLS FOR CAR DISCOVERY
The car discovery solution must re-use existing protocols wherever possible.
Contention free requirements
DMHA design issues & framework discussion
An IP curmudgeon’s observations on seamoby CAR Discovery
CAR Discovery Requirements