Context Transfer, Handoff Candidate Discovery,
and Dormant Mode Host Alerting WG (seamoby)
Thursday, July 17 at 1530-1730
CHAIRS: Pat R. Calhoun <email@example.com>
James Kempf <firstname.lastname@example.org>
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
- can drop requirements, card discovery, card requirements?
Issues with CTP (30 min) - John Loughney
- wasnt 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 (its in
- additional issues may be rejected, based on Experimental draft status.
- Interoperability with other Handover protocols will be deferred if
theres interest later.
- several related issues because protocol is underspecified
(parameter types and message fields) text for changes will be sent to
- we will expire context based on timer after transfer is complete.
- How does MN know theres 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
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
- 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. Whats the benefit of
changing? Just easier to implement?
Allison: think about your security requirements if you use ICMP
James: the problem is that we cant construct an IPSec SA using ICMP in the
general case (although some implementations allow it).
Allison: even though this is going Experimental, we cant 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 isnt 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 dont know our
volume very well (what periodicity, etc.). Its going to take a lot of
work, and isnt likely to be right enough for the IESG to be happy.
Greg Daley: periodically multicast, but broadcast isnt the right answer
here just wastes bandwidth for nodes that dont use CARD.
Q: dont have lots of experience with IETF process, but we wont
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?
- 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
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.
Dont have to have a solution for multicast use IPsec between host
Heshom: cant be protected by IPsec, why? A: multicast.
James: SEND found out you cant do stuff like this using public keys.
Heshom: as long as nodes dont 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 isnt 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
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 MNs 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? Weve done simulations before, this isnt
atomic, no guarantees that youve completed? A: as long as your updates are
added to most recently acknowledged state...
James: this is why were going Experimental. Cant argue and decide, have to
measure to know.
Heshom: what if context transfer failed? How does MN know? This isnt 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
dont 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: youre 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: lets take this to the list.
Charlie: I dont agree that redefining compression is true. We have proof by
example this works. Characterizing compression isnt 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 weve gotten
concerns about complexity and security that were solving in an
experimental context, not in a standards definition context.
- CT and CARD drafts have unresolved issues add todays 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 wont have
one until end of fall.
Charlie: does anyone doubt that this is a
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
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
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, cant we submit an individual draft with a
James: Pat, Allison and I need to talk about this and see what were going to
- SEAMOBY going dormant. Vern looking for a chair. Work is moving to IRTF.