Subject: [Mipshop] Draft minutes from IETF 68

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Apr 2007 15:02:10 -0700

Hello folks,

Here are the draft minutes from the WG meeting at IETF 68. Thanks to 
Ashutosh Dutta and Telemaco Melia for taking notes.

Please send any errors/corrections to the mailing list.

Vijay
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
[email-masked]

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

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop