2.8.17 Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting (seamoby)

Last Modified: 2003-06-18

Pat Calhoun <pcalhoun@bstormnetworks.com>
James Kempf <kempf@docomolabs-usa.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: seamoby@ietf.org
To Subscribe: seamoby-request@ietf.org
In Body: (un)subscribe your_e-mail_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/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
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
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
Done  Submit Handoff Candidate Discovery Problem Statement to IESG
Sep 01  Candidate Mode Host Alerting Protocol Protocols are submitted, with accompanying comparison against requirements
Done  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
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
  • - draft-ietf-seamoby-ct-reqs-05.txt
  • - draft-ietf-seamoby-cardiscovery-issues-04.txt
  • - draft-ietf-seamoby-card-requirements-02.txt
  • - draft-ietf-seamoby-mobility-terminology-04.txt
  • - draft-ietf-seamoby-card-protocol-03.txt
  • - draft-ietf-seamoby-ctp-03.txt
  • Request For Comments:
    Dormant Mode Host Alerting ('IP Paging') Problem Statement (RFC 3132) (34985 bytes)
    Requirements and Functional Architecture for an IP Mobile Node Alerting Protocol (RFC 3154) (31534 bytes)
    Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network (RFC 3374) (28245 bytes)

    Current Meeting Report

    Context Transfer, Handoff Candidate Discovery, 
    and Dormant Mode Host Alerting WG (seamoby)
    Thursday, July 17 at 1530-1730
    CHAIRS:	Pat R. Calhoun <pcalhoun@airespace.com> 
    		James Kempf <kempf@docomolabs-usa.com> 
    Intro and Agenda Bashing (5 min) – chairs
    Draft Status (5 min) - chairs
    - sent note to IESG in May, still in “evaluation”
    - need comments on remaining issues
    - need comments on remaining issues
        <other drafts>
    - can drop requirements, card discovery, card requirements?
    Issues with CTP (30 min) - John Loughney
    - wasn’t able to fix some issues before ID draft cutoff, so 11 remain 
    - going for Experimental, so this takes some pressure off
    - identified support for ESP, removed header compression (it’s in 
    another draft)
    - additional issues may be rejected, based on Experimental draft status.
    - Interoperability with other Handover protocols will be deferred if 
    there’s interest later.
    - several related issues because protocol is underspecified 
    (parameter types and message fields) – text for changes will be sent to 
    mailing list.
    - we will expire context based on timer after transfer is complete.
    - How does MN know there’s context at an access router that needs to be 
    - Race condition between CoA and CTAR processing
    - will take a vacation and then work these issues on mailing list – goal is 
    September finish
    Pat: we had the same issue on how the MN knows.
    Charlie: should we take care to be compatible with Fast Handover in MIP? A: 
    James: this will go forward into IRTF Mobility group to work on unified 
    approach to handover.
    Issues with CAR (30 min) - Marco Liebsch and Ajoy Sing
    - discussing version 2 of this specification
    - using R-flag for CARD Request rate limiting
    - is per-MN state allowed for DoS protection? May need allow different ARs to 
    configure different rates – DT recommends R-flag, no objections voiced.
    - Drop CARD protocol message piggybacking with FMIPv6?  
    James – this is one of the things that makes protocols complex. Leave it in 
    and figure out how to make it simpler during Experimental work. Need to 
    cooperate with IRTF Mobility RG. Discuss FMIPv6 application 
    Rajeev: agreed.
    - Inter-AR CARD protocol transport: UDP or ICMP? Proposal is to move to 
    ICMP for now, as a consistency thing. Any objections?
    Heshom: what if you want to only secure certain types of traffic? 
    Between ARs it might make sense to leave it as UDP. What’s the benefit of 
    changing? Just easier to implement?
    Allison: think about your security requirements if you use ICMP 
    James: the problem is that we can’t construct an IPSec SA using ICMP in the 
    general case (although some implementations allow it).
    Allison: even though this is going Experimental, we can’t turn off 
    security requirements – mandatory to implement needs to be there.
    - Drop lifetime field in capability AVP parameter for static 
    capabilities and save 32 bits for each static capability? We can save lots of 
    bandwidth if we do this, and processing isn’t onerous.
    - Unsolicited CARD Reply message addressing should be different for v4 and 
    v6? Should multicast be proposed?
    James: what about volume of traffic on wireless interface? Other 
    protocols using multicast have a lot of constraints, and we don’t know our 
    volume very well (what periodicity, etc.). It’s going to take a lot of 
    work, and isn’t likely to be right enough for the IESG to be happy.
    Greg Daley: periodically multicast, but broadcast isn’t the right answer 
    here – just wastes bandwidth for nodes that don’t use CARD.
    Q: don’t have lots of experience with IETF process, but we won’t 
    recommend operators to use this – depends on scenarios.
    Heshom: Lots of traffic from nodes moving in and out.
    Dirk Trassan: How much work if we leave this out now? Leave this for the 
    IRTF? Will look like a hack.
    James: I agree.
    Pat: how many people are in favor of a statement that WG considered 
    multicast, thinks it has value, and wants to leave this open for future 
    experiments? Small number in favor, none opposed.
    - Link layer triggers for unsolicited CARD Reply? Not needed for the draft – 
    take this text out?
    James: Yes
    - Use only one of Preferences/Requirements Sub-Options? Recommend 
    keeping them separately.
    James: Yes, based on no comments.
    - Request ARs to support ONLY reverse address translation via flag? 
    Rajeev: if you use a proxy, do you still need this flag? A: yes, you still 
    need it.
    Rajeev: means “give me the prefix”? A: yes.
    James: any objections?
    Charlie Perkins: we need to verify stuff on the mailing list, right? 
    James: right. Room seems to like this.
    - Protection of broadcast unsolicited CARD Reply messages?
    James: for this version of the RFC, multicast is TBD. If we do that, we can 
    use IPSec and have a lot easier time getting through the process. 
    Don’t have to have a solution for multicast – use IPsec between host 
    and router.
    Heshom: can’t be protected by IPsec, why? A: multicast.
    James: SEND found out you can’t do stuff like this using public keys.
    Heshom: as long as nodes don’t ignore router certificate...
    James: should discuss this on the mailing list – too complicated to close 
    - Are link-local unicast addresses OK for CARD protocol messages? Room 
    seems to accept.
    - Remove per-session state from ARs? Recommend keep signaling failure 
    recovery, but make this SHOULD? Room seems to accept.
    - Add detail on signaling failure recovery? Room seems to accept.
    - 8 bit CARD option length not enough? Propose going to 16 bits.
    Heshom: why do you think this isn’t enough? A: gives us lots of 
    Q: Use word as unit of measure for the length?
    Q: what about 64-bit alignment?
    James: take this one to the list...
    - Standards language in Experimental drafts? Already clarified. Should be 
    - Remove appendix from CARD protocol specification?
    James: this adds a lot of complexity in this draft. A: this could be 
    future work.
    Allison: save the appendix for the IRTF draft. Think about exhausted 
    reviewers who have already read the document up to the appendix.
    Dirk Trasson: you could refer to a conference paper.
    James: maximum two-page appendix?
    Sense of the room: hummm to shorten to two pages.
    - IPSec specifications – discuss on list.
    ROHC Header Compression CT draft (20 min) – Rajeev Koodli
    - Draft specifies a transfer of a context at the access router for header 
    compression/decompression in both directions.
    - has been reviewed with Carsten Boorman (RoHC chair)
    - single message that contains both uplink and downlink context – need new 
    RoHC profiles for each of these, matching 3095.
    - headers may be of different types (IPv6/TCP, IPv6/UDP/RTP, ...). 
    Identified by IANA-assigned number.
    - defines new extensions for IP address (from MN to AR) and New Tunnel (PAR 
    to new MN’s new IP address) – not necessary if packets are tunneled to NAR 
    Heshom: this tunnel extension is added at the access router? A: yes.
    Heshom: also for packets from the Home Agent? A: yes.
    - After relocation, PAR must stop ACKing updates to reference state in 
    uplink and tunnel packets toward NAR.
    Q: how much time to establish IP header state in a router? Is starting over 
    faster? A: example in the draft – depends heavily on RTT... 
    Heshom: is this overkill? We’ve done simulations before, this isn’t 
    atomic, no guarantees that you’ve completed? A: as long as your updates are 
    added to most recently acknowledged state...
    James: this is why we’re going Experimental. Can’t argue and decide, have to 
    measure to know.
    Heshom: what if context transfer failed? How does MN know? This isn’t a 
    static context – could be significant damages...
    Jose: also think this is overkill. What is HC context? Not defined in 
    3095. Implementation must add an interface that provides context. A: we 
    don’t try to export layer two information - only IP and up. Jose: have 
    to export a lot... IP version, etc. A: but you can demonstrate that this 
    works. Jose: you’re redefining the compression algorithm...
    Pat: this is too much like NASes in the mid-90s – when we started 
    sharing filters between NASes, we had to define a filter description 
    language. Why is this different?
    Pat: let’s take this to the list.
    Charlie: I don’t agree that redefining compression is true. We have proof by 
    example this works. Characterizing compression isn’t changing the 
    Pat: but what if two ARs have different capabilities?
    Charlie: then just deny the transfer.
    Carsten: in 3095, we have compression on a channel. HC is L2 state with 
    multiple profiles (TCP/IP, etc., with four profiles defined 
    currently). Handover creates a new channel, some context fields must 
    change, context WAS active before handover so race conditions are 
    Next Steps (10 min) – chairs
    - WG Chairs will add brief notice to CARD draft saying we’ve gotten 
    concerns about complexity and security that we’re solving in an 
    experimental context, not in a standards definition context.
    - CT and CARD drafts have unresolved issues – add today’s and go to 
    SEAMOBY review board, then to IESG.
    - ROHC CT – Rajeev work with Carsten, go to WG in September. Do it here or in 
    ROHC? This needs to go to IESG with base spec as application of 
    Allison: need application use case for SEAMOBY to prove SEAMOBY is 
    Heshom: could we do something less controversial, like QoS? 
    John Loughney: QoS not sufficiently baked – less than RoHC.
    Carsten: given that this needs an interface into RoHC, probably won’t have 
    one until end of fall.
    Charlie: does anyone doubt that this is a 
    performance-enhancing mechanism? 
    James: probably has someone doubting each individual application. How to 
    prove this to IESG? Maybe it goes to the IRTF and we find out it 
    doesn’t work?
    Charlie: we can show you convincing examples of this for years.
    Q: header compression is complex example, but there are certain things we 
    have to do in every case. There is no magic. If RoHC is the example, this 
    isn’t wrong.
    John Loughney: I understand why IESG wants to see an example of CTP use. 
    What is most baked solution out there? Please write it up and submit it.
    Charlie: instead of going through a standards process in another WG with an 
    educational process, can’t we submit an individual draft with a 
    performance evalution?
    James: Pat, Allison and I need to talk about this and see what we’re going to 
    - SEAMOBY going dormant. Vern looking for a chair. Work is moving to IRTF.


    CARD Protocol Issues
    Header Compression Context Relocation in IP Mobile Networks
    Context Transfer Protocol
    ROHC CT issues