Last Modified: 2003-02-19
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.
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.
|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|
|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|
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 independently 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 capabilities 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 result 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 solved 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 connectivity. 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 resolved... 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 examples 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 terminology predictive 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 deal. 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 enough. 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 approach - 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 Research - 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 experimental. GENERAL HANDS ... JK : general consensus in continuing work on CTP GENERAL HANDS ... 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 GENERAL HANDS ... JK : general consensus on going with proposal to goto experimental plan