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> 

AGENDA:

Intro and Agenda Bashing (5 min) – chairs

Draft Status (5 min) - chairs
    
draft-ietf-seamoby-mobility-terminology-04.txt

- sent note to IESG in May, still in “evaluation”

    
draft-ietf-seamoby-card-protocol-01.txt

- need comments on remaining issues

    draft-ietf-seamoby-ctp-02.txt

- 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 
open.

- 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 
transferred?

- 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: 
Absolutely.

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 
scenarios.

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 
approach.

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 
here.

- 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 
flexibility.

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 
fine.

- 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-koodli-seamoby-hc-relocate-02.txt

- 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 
instead.

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 
algorithm.

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 
possible!

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 
SEAMOBY.

Allison: need application use case for SEAMOBY to prove SEAMOBY is 
useful.

Heshom: could we do something less controversial, like QoS? 
(chuckles)

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 
do.

- SEAMOBY going dormant. Vern looking for a chair. Work is moving to IRTF.