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