IETF 68 MIPSHOP WG Meeting Minutes ---------------------------------- Note takers: Ashutosh Dutta and Telemaco Melia MIPSHOP Session I ----------------- 1. Agenda Bashing Fasthandovers 4068 Bis SEND Solution Fasthandover FMIPv6 on Point-to-Point link HMIPv6 Experiments with 802.21 NEMO and MONAMI6 Agenda was approved Session II: March 22nd Design Team Update PMIP Route Optimization Conclusions 2. WG status – Vijay D.went over the working group status. - Draft-ietf-mipshop-cga-cba-01.txt – made good progress - FMIPv6, Draft-ietf-mipshop-fmipv6-rfc4068bis-01.txt: WG last call after the IETF meeting MN-AR security association - HMIPv6, Draft-ietf-mipshop-4140bis-00.txt: could not make it to the archive - FMIPv6 Security: WG document – draft-ietf-mipshop-handover-key-00.txt - Draft-vidya-mipshop-handover-keys-aaa-04.txt – need a consensus - FMIPv6 over 3G CDMA network, draft-ietf-mpshop-3gfh-02.txt: Revised to bridge the gap between the draft and current 3GPP2 situation - FMIPv6 over 802.16e networks, draft-ietf-mipshop-fh80216e-01.txt - Media Independent Problem Statement, Draft-ietf-mipshop-mis-ps-00 - MIH Solution – Very much behind – slides to be presented by Robert Hancock on Thursday (Second Session) - MIH Information Elements – Do not need this in the charter. Eric: What is the output of the MIH section. What is the output expected here Chair: Not to use new transport unless there is a need Design team was created Robert Hancock (DT leader) – Design team is behind the schedule. There is no work for MIH information elements at this time. Chair: do you think we should keep it alive for the time being? Robert: This work was included in the charter when it was not clear. Proposed to remove this 3. Fast Handovers for Mobile IPv6 (FMIPv6) Rajeev Koodli draft-ietf-mipshop-fmipv6-rfc4068bis-01.txt Rajeev Koodli provided an overview of the changes that are reflected in RFC4068bis Since July 2005 there are several implementations such as fmipv6.org, lots of discussions archives, trackers. Most of these can be found online at mip4.org/issues/tracker/mipshop Various implementations: Fmipv6.org, NOKIA internal, TARZAN Rajeev then went over various issues associated with FMIPv6. These issues are all listed and updated in the issue list http://mip4.org/issues/tracker/mipshop Work on companion protocols Issue 19: Section 6.4.1 Current text: "IPv6 Address: The IP address for the unit defined by the Type field." Proposed: "IPv6 Address: The IP address defined by the Option-code field." Issue 20: Section 6.1.1: wild card access Current text, Section 6.1.1: "New Access Point Link-Layer Address … This field can also be a wildcard address with all bits set to zero." Proposed text:"New Access Point Link-Layer Address … This field can also be a wildcard address. See LLA Option in Section 6.4.3" Issue 21: Revise MH-LLA option in Section 6.4.4. Remove pad0 Include option code in length field calculation along the lines of rfc3775 Issue 22: Clarify LLA length in LLA option. Assume the format similar to RFC 2461 Issue 23: Life Time definition was put in. Issue 5: Usage clauses for HI and Hack are mentioned separately now. HI and HAck are recommended. Hesham: If there is a bogus request, prefix is valid. Typical Which packets, where do these get buffered. RK – Buffering for handover traffic vs buffering Hesham – Two separate issues RK – Router does a RS and buffers one or two packets Issue 12: Add a new code value in Section 6.2.2 Issue 17: NAR may use the link-layer address to verify if a corresponding IP address Issue 7: Role of FNA: proposal is to remove FNA altogether and let ND address resolution and reachability algorithms to forward packets. FNA Deprecated. Instead “unsolicited NA with ‘O’=”0” Remaining ones are editorials Issue 14: "The MN *SHOULD* use the NCoA if it is supplied with the NAACK option." Issue 15: Tunnel between PAR and NAR: Keep this as an option Issue 18: Sending FBack immediately in reactive mode Issue 16: PAR buffering packets. If FBU is not sent then the packets will get dropped. Issue 6: Should the specification specify a particular address assignment technique by NAR? Currently it does not specify anything Issue 9: Verify changes to REACHABLE state Hidetoshi: Signaling buffering, Send trigger between the routers using Hi and HACK RK – Unsolicited Hack, no acknowledgement 4. Distributing a Symmetric FMIPv6 Handover Key using SEND Rajeev Koodli draft-ietf-mipshop-handover-key-00.txt Rajeev Koodli gave a second presentation regarding update on SEND Keys draft, draft-ietf-mipshop-handover-key-00.txt Handover key exchange, original Changes in WG draft: Editorial issues Where to define IANA registry for Algorithm Type (AT)? RFC3972 prohibits (MUST not) Vidya: Conflict between RFC 3972 and this document about using the public key for encryption. Rajeev: Still figuring out what the issue and how it can be addressed. Laxminath Dondeti – Same key for signature and encryption, Party A encrypts and send it to B. The rest lost… JARI- Connection to TYPE field Suresh- What kind of latency do you add during handover RK – This is not done during the handover but before that Suresh – How about Reactive Handover. RK – We already got the key from the new AR beforehand Suresh – Do you assume that there is trust relationship between routers, if that is so, it is perfectly fine to do that. Vidya – There is no issue Suresh – going back and forth 5. Mobile IPv6 Fast Handovers for 3G CDMA Networks Hidetoshi Yokota draft-ietf-mipshop-3gfh-01.txt Hidetoshi Yokota provided the details of the new draft Changes from 01 draft - HREq/HRes are replaced by HI and Hack - PMIPv6 us assumed for the AR originated BU Predictive fast-handover Reactive fast-handover Network-controlled for fast handover: Mobile node is not involved explicitly Difference in message type: if the implementation is different HI and HACK can be used for different direction. Updated network controlled fast handover. PBU, PBA using same BCE Summary of change: HI and Hack Includes network-based mobility management feature Watching progress in 3GPP2 Hesham: How do you send the unsolicited HI? RK: Keep a state Hesham: Bicasting draft should be revived, as similar features are being discussed here Alex: Separate entity – Proxy MIP client Hidetoshi: He assumed that proxy MIP client is in the MAG, if PMIPv6 thinks it is different we need to think about this. 6. FMIPv6 on Point-to-Point Links Behcet Sarikaya draft-xia-mipshop-fmip-ptp-00.txt Shared Link: All MSs attached to an AR share one or more prefixes for constructing the global IPv6 addresses Point-to-point link: Each mobile node is assigned a unique prefix FMIPv6; Shared Prefix Formulating: NCoA in Point-to-Point link Proposed Solution: Aggregate prefix Modified Prefix using HI and HACK – HAck RK: 4068 should just work fine, new changes may not be needed How the new router will prepare the modified Prefix. Just an implementation issue. We may not need any changes for RFC 4068. Behcet: Wording says shared prefix only. In case of point-to-point link, this type of prefix is already supported. VD: If it just matter of adding some text to 4068bis. RK: Problem is how you can manage the prefix. What do you think should be included in the text? Behcet said he would send the appropriate text later on to Rajeev. 7. Hierarchical Mobile IPv6 Mobility Management (HMIPv6) Hesham Soliman Hesham gave an update on HMIPv6 bis: Draft-ietf-mipshop-4140bis-00 Could not submit before the draft cut-off. Objectives: Update HMIPv6 to proceed to PS Main issues – Support for IKEv2 Current Security Scheme Bootstrapping IKE negotiation: IKEv2 can be bootstrapped using Certs or an EAP method with AAA as backhaul Vijay D. Should we get WG LC? by May, can it be earlier? Gerado: Any new AAA requirement that would be needed. 8. Experiments with 802.21, Monami6 and NEMO Koshiro Mitsuya No draft K. Mitsuya from Keio university presented the results of experiments that have used 802.21 triggers. Multiple care-of address registration + IEEE 802.21. This was also presented in MOBOPTS WG. MCoA – multi-homed mobile nodes in Monami6. WIDE has several experiments using mCoA currently. 802.21, IBurst Network MR (Mobile Router) changes the interface between IBurst network and EVDO network. L2 info trace iBurst: developed by Kyocera and Arraycom Two different thresholds are used namely: L2-prepare and L2-goingdown Changes of L2 RSSI 1. RSSI of Iburst goes below than Threshold 1 (-93 dBM) 2. NEMO path via EVDO is established Handover from IBurst to EVDO No packet loss at the VoIP Yellow line, upper yellow line, and lower yellow line. PPP takes about 10 sec Without Make-before-break mitsuya@sfc.wide.ad.jp Michael Williams: What algorithm did you use to determine that link is going down Cellular Card – RRSI quality was compared with VoIP quality MIH messages between the application. Subir: Maybe there are several MIH users Answer: Maybe link going down would be different Ashutosh: What operating system was used? Mitsua: Linux and BSD 9. Handover Keys Using AAA Vidya Narayanan draft-vidya-mipshop-handover-keys-aaa-04.txt Handover Keys using AAA –status report - draft-vidya-mipshop-handover-keys-aaa- 04.txt updated Vidya gave a brief overview of this document. Since this is not yet decided whether to include this in the working group charter, not much effort has been put in yet to further advance this document Suresh: What is the goal of this document. Vijay D: One mechanism of using the security between MN and AR Gerado: Charter says AAA-based mechanism From operator’s perspective SEND may not be there, so we need to leverage AAA RK-Companion protocol refers to SEND-based. I need to have a normative reference. It does not have any specific connection. Suresh: What else is happening elsewhere in other WGs Vidya N: We need to have some consensus Vijay D: It needs extension in DIME WG. At least a couple of drafts. MIPSHOP – Session II -------------------- 1. Design Team Update Robert Hancock MSTP Design Team - Robert Hancock gave the presentation, and went over the details of the design team member meeting. The slides can be found at the following link. http://www3.ietf.org/proceedings/07mar/slides/mipshop-10.ppt#1 Admin: Design team members, Robert Hancock Lead Srinivas Sreemanthula Subir Das Juan Carlos Zuniga Telemaco Melia Sam Xia John Loughney Heejin Jang Role of Design Team – create 00 draft solution proposal Not a fundamentally hard problem – tricky issues with terminology, consistency with 802.21 Priority scenarios, flexibility, simplicity When: Ideal Case: We will have a solution draft by next IETF. (A) Worst case: too close to-call tradeoff issues – what is difficult Either case we have a draft for Chicago Meeting DT mailing list will be public As we discover the issues, bring them to the group. Engineering/Admin WG document, DT document DT wants the PS to be stable and generally agreed. Rapid conclusion to the WGLC process Role of DC draft (Design-consideration draft) Sections may use the text from the DC draft as a starting point. No plan to push for publication Engineering: DT’s scratchpad Alper: why do we talk about identifiers of MSTP user? is mobile ip a good example? Robert: no, MIH is using MSTP Alper: why do we need to do this? Robert: the issue is directly connected to the discovery mechanism problem, MIH is not a monolithic thing, there are still discussions on what the 802.21 identifier actually is. This finaly leads to how you map an MSTP user to the transport layer. Alper: why DT reviewed the PS doc? we should seprate things Robert: we had requests the DT reviewing the PS doc Bechet: DHCP and DNS, are you considering those as discovery mechanisms only? Robert: there are proposals to use DHCP as MSTP candidate solution Alper: clarification on DHCP usage, so far there are 2 drafts, one using DHCP for discovery, one using DHCP for IS only XXX: could you clarify how multi hop routing? Robert: we do not look at a solution for multihop discovery between two MIH peers Yoshi: regarding proxying of discovery mechanisms, could you clarify? Robert: an example could be DHCP relay Daniel Park: Message Routing between MIH peers Robert: Ability to discover the next hop node, which one to use/reuse. We have provided the mechanism Yoshi- Regarding Proxying of discovery mechanism, hope it is not DHCP relay mechanism Robert : it could be. Yoshi: Where will this be necessary? Robert: We do not need to define the inter-discovery mechanism 2. PMIPv6 Route Optimization Protocol Alice Qin draft-qin-mipshop-pmipro-00.txt PMIPv6 Route Optimization Protocol: A. Qin presented this draft and described the route optimization mechanism when both the CN and MN are behind the MAG. Problem Statement: PMIPv6 uses indirect routing via HA, this needs to be optimized 1. Type 1, MIPv6 enabled CN, MN is not MIPv6 enabled 2. Type 2, CN and MNs behind PMIPv6 MAG, and none is MIPv6 capable Alice presented the draft and explained how route optimization is done for both Alex: Route optimization for PMIP, thus uses many features. Conetxt transfer is not very clear. We need a problem statement. Identifying the problem statement is better. Whether that should happen here or in Netlmm. If two mobiles are under the same Mobility domain Vijay D: Netlmm WG is going to work on the base protocol now, route optimization should be carried out there. Genadi: Problem statement is needed, questions about two scenarios. In the second case, are the MAGs under the same LMA? Behcet: It could be applicable to both the cases, when MAGs are under same LMA or different LMA. 3. Next steps Chairs WG last calls on 4068bis-01.txt soon Solicit reviews for 3GPP2 fast-handover draft, send a liaison to 3Gpp2 Send draft-ietf-mipshop-fh80216e-01 to 16ng WG for review Resolve the situation on handover keys using AAA MIH problem statement draft – address the issues as soon as possible, complete the WG last call and send it to IESG Publish the first version of MIH solution document before next IETF. Milestones need to be revised