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

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-19

Pat Calhoun <pcalhoun@bstormnetworks.com>
James Kempf <kempf@docomolabs-usa.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
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 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
  • - 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-02.txt
  • - draft-ietf-seamoby-card-protocol-01.txt
  • - draft-ietf-seamoby-ctp-01.txt
  • Request For Comments:
    RFC3132 I Dormant Mode Host Alerting ('IP Paging') Problem Statement
    RFC3154 I Requirements and Functional Architecture for an IP Mobile Node Alerting Protocol
    RFC3374 I Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network

    Current Meeting Report

    Seamoby, Mar, 20, 2003
    *Draft Status
    JK : 
    mobility terminology draft will be sent to iesg soon to be published as 
    informational, maybe 2 wks
    context transfer problem statemnet done -> RFC3374
    Alper : what happens if someone wants to add to mobility terminalogy ?
    JK : this should be refered for general terminalogy, specific items 
    should be in specific WG drafts
    JK : carddiscover, ct-reqs are in AD evaluation, awaiting comments
    JK : car requirements comments -> doesn't align well with security 
    comments (Allision)
    JK : card protocol, ctp protocol will be discussed
    JK : as John is not here start with Ajoy
    * CARD protocol
    Ajoy :
    description of CARD protocol
    proposal on 2 operation modes to keep design flexibility
    server based CARD protocol - Network assisted mode
    MN orchestrated CARD
    most of discussion so far on ML has been server based solution but that is 
    not the only important issue
    WG issues 
    issue 1 : support of AP authorization at AR
    	AP authorization is not supported in the current draft
    	does this belong to scope of the CARD protocol
    PC : do we care about interoperability btw APs and ARs.
    AS : don't think that is in Seamoby scope
    difficult to authorize whether the AP is authorized or not
    PC : but do we care about interoperability ? 
    AS : no
    issue 2 : do we need server or not ? 
    characteristisc os server based approach 
    	able to provide seamless handoff even if CAR info is not avaiable in 
    current AR cache
    	server provides built in authorization function by using scope -id -> 
    inbuilt authorization (sort of)
    	introduces single point of failure this can be solved by 
    integrating with AAA server
    Alper : don't understand how AAA server helps ?
    AS : we don't introduce extra points of failure if we add this to AAA 
    server as AAA server is already is there
    Alper : only looks like moving problem to another place, making a bigger 
    single point of failure, doesn't solve the basic problems,
    JK : as a general point it is a single point of failujre
    JL : it is a process running on a server, processes are able to die 
    issue 2 : handover base approach
    - no server required
    - seamless ho not possible until AR cache is populated
    - AR cache is only updated when MN performs active L3 handoff
    - additional protocol complexity for validating 
    PC : you are assuming dormant HO is more common than active HO, so don't 
    think this is true
    JK : depends on how you implement it, but don't see any dormant HO which 
    cannot do L3 HO signaling
    HS : where is the source of information that most handoffs is mostly 
    dormant :
    AS : from current voice network
    HS : please send link 
    issue 3 : DoS
    - possible to minimize by rate limiting the number of AR server 
    requests as well as MN-AR requests
    issue 4 : cache contamination issue
    AS : by properly using scope id it is possible to solve this problem
    	need configuration, algorithm etc.
    JL : just as a point of suggestion, IPv6 group has realized that scoping is 
    an impossible problem,
    NSIS has also been told to not do scoping, so I suggest don't do any 
    scoping unless you have a real workable solutions
    Coven : If you can push everything down to AR at boot type won't it work ? 
    Mark ? : Scoping is only to make sure cache contamination not be done ..
    JL : that's what site local tried and showed can't be done
    issue 5 : piggybacking CARD options
    - piggyback CARD onto FMIPv6 messages 
    - do we need to have some text to clarify
    - do we need to restrict piggybacking to FMIPv6 or should it be also with RS / 
    RA ?
    - "P" bit is used to discover the piggybacking capability of the CARD 
    communications peers
    Alper : I assume that your saying adding more info to RS / RA ? Why 
    change FMIPv6 spec ? Just add options to RA / RS ?
    AS : if we want CARD to be used, I think it should be tied with FMIPv6 as 
    much as possible so htat is widely adapted
    Alper : keep it separateHS : don't know why you are calling it 
    piggybacking ? Nodes will understand or ignore ? What's the problem ? 
    AS : we have to ensure implementers implement it. We don't want some 
    vendor's implementation to use CAR? FMIPv6 but some not used CARD ?
    Alper : piggybacking is the wrong term
    JK : this function is defined by ICMP so let's move on
    Issue 6 : What is function of lifetime ?
    - lifetime flag supports indication of dynamic / static 
    AS : - think we need it but can remove it 
    IPR issues : do we need an IPR free draft ?
    JK : it's better to try to be free.
    PC : can we know which sections have it ?
    AS : caching and pre-filtering..
    JK : maybe separate those out and not make it a base draft item
    JL : it would be nice to know what the parties are and how they will be 
    licensed ..
    JK : people in WG should notify 
    PC : without knowing what the IPR is it's hard to progress.. we need to 
    know what the IPRs and then WG should decide whether to go on or not..
    JL : I thought procedure was to add standard IPR section to doc and then 
    submit to secretariat
    Erik N : most prefer not to have IPR, but it is upto the WG. If the WG 
    feels that the only reasonable solution is to use the solution with IPR, 
    then that is the way to go.
    Dirk : Cache Contamination Issue discussion
    cache entries might exist for ARs that are not geographically 
    adjactent to the AR
    problems : 
    memory consuption
    processing overhead
    problem with sleeping interface scenario
    	you have 2 interface, A, B, B is sleeping
    	getting CARs for interface B
    	will end up scanning on A for CARs only visible from B
    this is only a problem for MN if the MN rceives a wrong L2-L3 mapping 
    Solution Proposals :
    P1 : backend server
    	configure backend server to used scope
    problems :
    malicious MN can req all "scope" ARs
    resolve L2-L3 requests would still happen in the backend for 
    out-of-scope ARs aoltohough with negative server response 
    rate limiting could effect actual semantics of protocol
    how to configure scope
    how to deal with dynamic changes in scope
    aging out of cache entries
    P2 : learning approach (dycard approach)
    - after ho send triplet (L2_new, L2-Old, IP_old) to new AR
    - if new cache entry new AR contacts old AR to verify etc.
    - assumes list of authenticated local APs withing each AR
    problesms ;
    -consumes BW
    - check with old AR
    - contaimination possible by provisioning triple at 
    geographically distant ARs 
    - "aging out" of cache entries would not help since an aged out AP could be 
    provided and stored again, assuming a succesufl check with old AR
    AS : if scope is limited to exactly to the neighbors this problem is 
    D : then this is static configuration with its problems
    AS : if you have a scope, then you can configure cache to ensure size etc 
    are correctly configured. 
    AS : reduce the scope or bigger scope (with cache contamination) is a 
    decission to be made 
    ? : I don't understand how the scope id affects the MN ?
    D : in order to keep my cache contamination low, operator would 
    configure scope very small, but MN may try to get an AR outside of that 
    scope, eg. an AR for the whole of SF 
    ? : there may be an entry of an old AR, but so what ? Not convinced that we 
    need to keep cache 100% clean ?
    D : ? 
    Coven : 1) MN can always contaminate cache w/o knowing scope , 2) can we do 
    better, such as dycard
    AS : more difficult problem of dycard is that any MN can say any router on 
    the internet is a CAR. Service provide does not want to be at the mercy of 
    the MN..
    Server based approach does not have this weakness. Dycard is too 
    dynamic. Different from routing protocols they have implicit 
    Dirk : new AR will have the ability to ignore based on 
    authentication etc. if MN sends 3 reports, AR should easily be able to 
    identify malicious nodes and ignore it..
    AS : the network does not have any control ..
    Dirk : i'm checking with the old AR all the time so this is 
    PC : while service providers may care about this, some operators will not.
    C : everything depends on security, but if SA don't exist all schemes fail
    AS : routing protocols have a more restricted case .
    PC : OSPF ASs can be very large so don't think this is true
    *** Context Transfer Protocol v01
    JK : make sure you align terminology with the terminology draft
    JL : main issues
    - choice of transport
    - security modesl
    = message types and semantics
    - intra-domain / inter-domain discussions
    - failure model needs to be specified
    - handling multiple contexts when their reliability and / or 
    performance requirements are different
    Updates : 
    - added text on protocol overview, quite stable
    - improved the def of the messages
    - addes examples and singaling flowsw
    What's stable : 
    protocol overview
    msssages and defs
    JL : want some comments on these .
    TO DO : 
    more text on interaction with FMIP
    clarify autentication vs authorization
    clarify secure and non-secure context transfer  (what it means etc.)
    reliability details
    better def of feature profile types & examples
    better clarification of scenarios
    SOME OPEN ISSUES for consensus :
    WG consensue on transport protocol : (UDP ?)
    WG consensus if the scenarios are sufficient
    WG consensus on reliability needs
    JL : authors feel individual contexts have different relibility needs
    JL : need review from WG and info on how it would be used
    Alper : is this protocol dealing with one context transfer from old AR to 
    new AR, various contexts realted to mobility, eg. state on old AR, PANA 
    state on old server, 802.11 state on APs etc. What is the approach to how to 
    transfer these contexts ? Do we assume peer-to-peer for these things ? Or 
    single batch protocol ? 
    JL : personally : I want to do this peer to peer, walk before run... some 
    people have discussed using a centralized server
    Alper : that approach makes sense, just clarify in text, so that we show the 
    CTP is applicable to other entities rather than just ARs
    CP : aren't we being motivated by ARs ?
    JL : initial motiviations from ARs, but Alper wants to show that 
    interesting context may be on other entities..
    CP : reliability of contetxt transfer, as well being motivated by moving 
    context btw ARs... but there also seems to be concept that state is built up 
    at an AR, if consequently if context failure fails you always have the 
    option of being able to rebuild context at the new AR. So this should 
    guide us in our design...
    JK : are you suggesting that be an invariant..
    CP : we don't have to have "absolue guarantee" of transfer
    CP : clarifying interaction with FMIP.. I remebmer initial 
    discussions during SEAMOBY there was a strong feeling that SEAMOBY should be 
    independent from FMIP ? May be that has changed ? Can we guage the WG's 
    feeling ? 
    CP : One more thing, are we finished with requirements doc ? 
    JK : we'll go back to this ...
    PC : I don't think we need to have this discussion that different 
    reliability requirements...
    ? : I thought I heard someone form IEEE about context transfer ? During EAP ? 
    JL : don't know..
    Rajeev K : maybe yet another comment on reliability.. most of the 
    features we are trying to context, will have the ability to 
    reestablish. Draggging out context transfer for reliability may make this 
    more complicated.
    JL : I'm hearing discussion that context transfer should be a one-shot 
    JK : other way to this is to tie this with FMIP signaling 
    RK : context batching... think this is unnecessary at this stage.. 
    JL : I think that is what Alper was saying..
    RK : OK. so we are agreed that we don't say anything in the draft ..
    RK : doesn't this put constraints in the design ?
    JL : I think future proof is important.. but just if it is extensibel it is 
    JK : people read this group and post to ML... PLEASE !!
    PC : protocol abuse will occur.
    ?? : Isn't reliability and use of UDP contradictory ?
    JL : not the point i was going for. Is TCP helpful as retx etc can get in 
    the way..
    *** MOVING FORWARD ****
    JK : CARD Architecture
    backend : learning based approach, server based approach
    frontedn : ICMP is basic consensus, maybe add to FMIP signaling (?)
    JK : Main problems is in backend.
    JK : Reorganization  ? Freshness date is passed we are going stale. 
    Reorganization suggestion : 
    - use requirements draft as guideline, drop publication
    	requirements aren't helpful for research, research questions are ..
    - frameworkd for research on both server-based and learning-based 
    - focus on IPv6 drop IPv4 
    	wireless ISPs already have proprietary solutions anyway
    - submit protocol to IESG for publication as experimental after Vienna
    Proposal for experimental draft
    - complete CARD front end in Seamoby
    	integrate FMIP and CARD
    	one host to router IETF protocol for CARD
    - inter-router protocol Backend supporting both serfver based and 
    learning so people can use it as a vehicle for experiments
    - if deployment interest, restart in INTERNET area for PS
    - simulations to compare server-based and learning-based
    - develope design approache to solve AP auth/authz problem
    	PS must solve
    - utilize framework to implement different approaches
    - joinw tihe MIP IRTF 
    - return later for PS if needed
    Context Transfer Interest
    - not much interest ?
    - no response on list to chair's extensive review of DT CT draft
    - competition from IAPP for 802.11 reduces market interest
    	other tech have their own
    - is anybody interested in this work ?
    	if not, let's drop it
    	if so, do something similar to CARD
    		use requirements draft as a guideline drop publication
    		focus on IPv6
    		submit at Vienna for experimental
    JL : about interest for Context Transfer, I would like WG's comments ..
    JL : I would not concentrate only on IPv6.. as both 3GPP2, 3GPP will be 
    doing WLAN interop soon, so that will use IPv4. Just make framework able to 
    carry v4 and v6 ... Then if there is interest they will be able to use it.
    JK : why not use IAPP ? 
    JL : cannot use with 3GPP/ 3GPP2 entities such as GGSN ? I have never 
    heard SDOs discuss IAPP ? Session continuitiy ...
    PMcCann : Session continuity is really for IP address continuity. Don't see 
    any need for inter-technology handoff..
    ??? : 3GPP is currently unable to say anything about this. So there is no 
    discussion on protocol yet.
    JK : don't have any real interest, so maybe just make 
    JK : general consensus in continuing work on CTP
    JK : general consensus in going with proposal to goto experimental plan
    JK : now let's discuss CARD plan
    Marco : Is it intended to have 2 doc for front / backend or 1 doc ?
    JK : 1 doc but without specifying one of the backend
    NV : Not comfortable with removing IPv4
    JL : Is it that hard to support both IPv4/v6 if it is frameworky  ?
    3GPP/ 3GPP2 : inter-tech handover will happen in near future
    JK : anyone else interested in CARD work ? At least from ML, there does 
    seem to be some interest at least from research perspective
    JK : general consensus on going with proposal to goto experimental plan


    Cache Contamination Issue
    Context Transfer Protocol
    Candidate Access Router Discovery Protocol