Combined notes from Pierrick and Wen Luo Introduction ---------------------------------------------------------------------- Chair: the meeting will focus on DMM and rechartering discussion CP: 1H meeting for presentation and rechartering discussion is not enough. Should schedule another meeting in the week Jouni: I'll relay to the AD. Behcet seconds Charlie and stresses that the agenda has been extended to include other item than distributed mobility Per-Host Locators for Distributed Mobility Management ----------------------------------------------------- Marco Liebsch (ML) presents draft-liebsch-mext-dmm-nat-phl This a new draft. The goal is to provide IP session continuity after mobility anchor relocation key features: - No change in mobility protocols - address both PMIP and MIP - Replace tunnel by NATs -> two NATs level Sri Gundavelli: How the status is created on the NAT? ML: current mechanism only focuses on the data plane. For the control plane, different mechanisms could be studied. We can have a database maintaining the mapping, similar to LISP. The issue on dynamic update of the binding. We have thought about but not yet write down. It depends on whether you consider the ingress router and NAT on the pMAG. SG: can we assume a signalling protocol between those entity? ML: Yes, we can assume SG: so, it is not a pure database signalling but state creation ML: yes Pete McCan: on the forwarding plane, we can do NAT, tunnel, or even routing? ML: the advantage we see here, is that we can use routing reusing the existing routing plane. You don't need per host state on all these router. You just need state on the Ingress Router (IR). PMC: right. The point is that the solution doesn't look very distributes, it looks like an additional layer of hierarchy. The architecture between the Ingress Router and the pMA may be more distributed. ML: I don't think it is an additional hierarchy in mobility anchors. It's router which needs Per-host state, true. But it needs to state only after anchor relocation, which means: on the pMA the identifier is routable, it don't need to state there. It's only when the MN moves that you need to create a state on the Ingress Router. Approaches to Distributed mobility management using Mobile IPv6 and its extensions ---------------------------------------------------------------------------------- Raj Patil presents draft-patil-mext-dmm-approaches Already presented during previous meeting Scope: the draft discusses solutions how deploy DMM Raj reminds "well-known" issues of centralize architectures Raj argues that we can take existing protocols and their extensions (HMIP, PMIP) we don't need new protocols but it�s worth providing a BCP. No question/comment PMIP Based Distributed Mobility Management Approach --------------------------------------------------- Wen Luo (WL) presents draft-liu-dmm-pmip-based-approach Solution in few words: - MN to CN comm. via MAG to MAG direct path. - Traffic anchored at the MAG close to the CN - LMA used only as a locator Charles Perkins: how can the cn distinguish between the pMAG and a malicious node sending out this update? WL: do you mean there is a security issue? CP: Yes WL: CN and MN are in the same PMIP domain. SG: How does the MN know the MAG-CN?. WG: get it from the LMA. SG: so, how does the LMA know? WL: both the MN and CN register to the LMA as PMIP does, they are in the same PMIP domain SG: But the CN has no security relation with the LMA WL: if the CN register to the LMA, the LMA knows the CN-CoA. SG: it�s true if both MNs are anchored at same LMA but what if the CN has no relation to the LMA? WL: you mean using two different LMA? SG: not only, the CN may be a fixed node, so not anchored at the LMA. WL: ok, I can consider it further Marco Liebsch (ML): already commented in last IETF, but if you�re considering that both the MN and CN are registered to the same LMA, what are the difference with LR designed in netext WG? WL: we have some difference in handover considerations between this solution and the one in netext. ML: you could consider direct tunnel to CN which is not registered to the PMIP domain. In this case, CN is a generic IPv6 node and you establish a direct route to it. That�s something new. WL: In this case the MAG of the MN does not know the CoA of the CN. So, it operates as the PMIP does. ML: ok, some addition Bruno: If CN and MN are in same LMA, HMIP has same benefits. So I don�t see any reason to not use HMIP. WL: HMIP is complicated and hard to deploy Use of Proxy Mbile IPv6 for Distributed Mobility Control -------------------------------------------------------- Ji-In Kim (JIK) presents draft-sjkoh-mext-pmip-dmc Solution in two words: - The MN and the CN are in the same PMIP domain -> communication between two MNs - the initiator gets location of its correspondent up to a centralized location database (partial distribution) or floods the network to query all MAGs (fully distributed solution) - new messages to achieve this: PBQ/PBA - then inter-MAG tunnelling - Address both partial and full DMM approaches SG: How does the nMAG knows the LMA for the MN? In other words, how do you know where to send PBQ? JK (clarifying the question for JIK): here, you cannot make an assumption that that CN and the MN are in same PMIP domain: the CN can be generic IPv6 node, e.g. a node in the Internet. In this case, how does it work? SG: yes, how do you enforce this assumption? JIK: the LMA is the anchor point, so the CN sends a packet where the destination home address is the LMA, so,... SG: no, the destination address belongs to one of the LMA prefixes. But how do you know the LMA which has allocated that prefix: LMA is hosting P1, P2, P3 prefixes. When the CN sends a packet to P1::/, how do you know the LMA corresponding to that prefix. JIK:... JK: You should discuss offline or in the ML Dapeng Liu: for the Full distributed approach. How do you do the authentication if there is no LMA there. JIK: the SD-PMIP [note: fully distributed] is the worst case. So, the MAG replies to the CN, so,... DP: do you mean that the MAG does the authentication of the MN? JIK: mhhh... JK: ok, let�s continue discuss on the ML or offline Re-chartering discussion ------------------------ Introduction: The discussion is based on AD's email (sent on the October, 28th), based on a proposal from a group of motivated people. Jouni reminds that a short sentence on distributed mobility management already exist in the charter. We already had discussed on the ML (Jouni posted a summary). The discussion has been motivated by 3GPP architecture and evolution. It�s a good thing but protocol designed here must not address only 3GPP needs. Reusing existing mobility protocol should be the priority. Non anchored solution are also in the scope. DMM should not break anything. Focus on IPv6 based solution, but we'll not ignore IPv4 . Summarizing the discussion, it is suggested a 4 steps process: 1. address problem statement and requirement. 2. gap analysis with centralized approaches. 3. BCP reusing current protocols and existing extensions. 4. specify new extensions if needed. Open discussion: CP: [Charlie says again that 1H long meeting is not enough to discuss such issues. According to Charlie, posting the claim for rechartering only 2 or 2 weeks before the IETF does not give enough time for discussion.] Shorten the WG to DMM may be problematic. MEXT is the right place to address improvement of Mobile IP and, considering what 4G networks should do, it�s clear that Mobile IP has some design inadequacies that need to be remedied. [Charlie made a proposal to AD for that]. It seems that there are enough people to support effort on other issues than DMM, at least to identify remaining issues: Charlie thinks that we should not short the WG down. Charlie suggests to try to identify other work items before next IETF. Jari Arkko (JA): We do not have enough time to reach a conclusion during this meeting. Jari clarifies that it is not shorting down MEXT, but, here it is to focus on one topic. Jari has nothing against adding new things in the charter IF there is significant interest. But we need to see interest and demonstrated interest we�ve not seen that for everything in the past. CP: appreciate what Jari said. Because we have not enough time to discuss during IETF 82 meeting, Charlie suggests to have a ML discussion to see if there is people to support effort on redesign of (P)MIPv6. Then make a decision on IETF 83. JA: discuss what people want to do (and if there is energy on the WG to work on) is useful now, we'll focus on that. Raj Patil: agree on continue enhanced mobility protocol as Charlie said. There are extensions that can be still be specified. Think there are enough people that are able to support the effort. JA: Jari reminds that there is not so much remaining items in the charter: AD's sponsored security document is going to the IESG. Other documents in the security space would be too. Jari is not in favour to include vague items like "improving protocols". If people have good, and precise, ideas and energy to work on, there is no objection to include these items in the charter. Anthony Chan: [going back to the DMM discussion] Jouni's slides summarize too much previous discussion. Anthony says that large number of people discussed the DMM stuff on an ad-hoc mailing list (called DMM); they have issued couple of documents (including the current charter proposal). Also, I-D exists on problem statement and use-cases. Anthony suggests to get this as an input to going further. Anthony stresses the need for a problem statement and requirement and volunteers to continue to work on. JK: it's an open process; everybody is encouraged to provide inputs and inject their own ideas. JA: Clearly we take off-list work. Recharter text is based on that work. The question is: do you have opinion about the charter here? Do you want a tiny version? What is it the charter want to say? HC: stresses the need to have a clear understanding on what the issues are. The evolution of network architecture gives the framework and may impact mobility design. For example, introduction of CDN. Also, there no clear definition of distributed mobility. Thus, need a document which clearly defines the problem. Hannes: In previous WG session there were a discussion on the lack of deployment for Mobile IP. Last week, Charlie gave a presentation on a workshop. Encourage people to share their views/thoughts, on the ML, to get a better understanding on the problems and what the issues are. PMC: some of these issues, especially, when we talk about a MN using a CoA without tunnelling are getting into details inside some of the mobile operating systems. Pete suggest either people from the IETF or outside the IETF can get involved in the discussion. Involve either some of the major operating systems, vendors,... So we could develop a system architecture at the same time we develop protocols for the network side. We could involved outside entities in a way we did not in the past. JK: yes. Good input. Behcet Sarikaya (BS): [Behcet seconds Charlie]. I [Behcet] don't like non-anchored solutions. JK: Is there a reason for that? BS: Yes I'll explain. [Behcet likes the slides] Also, I'd like to see problem statement and requirements to really understand motivation for CP/DP separation, distribution,... Behcet suggest to start focusing on MIP. Then, if there is interest, consider PMIP (or whatever) as well. ML: fully agree that this work should not be specific to 3GPP architecture but 3GPP has no problem on using MIP/PMIP. The problem is on the deployment. But looking at the proposal we have on the table so far to address distributed mobility, some of them tries to address different aspects of the problem. So, Marco fully agrees we should work on a joint view of the problem, then agree on some design goals/requirements. We may agree on mechanisms which may easily apply to MIP/PMIP. Or, we may reach the conclusion we need support of other protocols, like Diameter, or Radius. Modify these protocols is Out of the WG scope but we should cooperate with corresponding WG. First step is problem statement getting design goals and requirements, then define how to touch MIP/PMIP. DL: Dapeng responds to Behcet: we should not preclude PMIP or non-anchored solutions at this step, we should consider both possibilities. SG: It is fundamental to not define new signalling semantics. Anything we do must be based on MIP/PMIP protocols semantic. This should be the based criteria. Ryuji Wakikawa (RW): comment on the second bullet of (slide?). It's not clear. Do people want to define one protocol covering HA/LMA distribution? Because, we use to say "Anchor point". Anchor point may be HA/LMA/MAG, so there may be different solutions. Sentence stating optimal tunnel between mobility anchors: this is pretty much PMIP. Charter is vague, maybe you assume some solution. Ryuji suggests to revise the charter to clearly identify what we want to work on. JK: Jouni has the same feeling but reminds that the charter has still not converge to what we want to have. CP: Charlie suggest to consider the extreme cases: 1) completely hierarchical solution 2) completely non-anchored solution. We can make lot of progress just considering extreme cases and figure out how it works. HC: want to clarify 2nd bullet: many solutions for deployments of anchors, the fundamental is geographical distribution which can be more or less flatten, which may lead to lot of anchors. It is up to the deployment. The issue is to make them work together. CP: Of course there are many possibilities. But it impacts the solution space when you decide the level of distribution. MN may use different anchors at the same time, so inducing lot of signalling. So, lot of anchors and lot of signalling. PMC: Pete advocates to relax the requirement of maintaining the same IP address for the MN during the session (even when PoA handover). JK: yes, it is what we have today. JA: It is hard to draw for a conclusion, but there are few things it can be asked to the room; on what the charter should include: four things if you like to see these in the charter or not. Q1: First one will be this narrow scope that only operational document that describing how to use current protocols in a distributed fashion, no extensions. Q2: Second one is more or less like this on the screen now which is basically all of the above and also possibly some extensions related to DMM. Q3: The third question is we should include both proxy and client mobility, and Q4: fourth thing is if you want more open ended MIPv6 improvement. JCZ: do we need support of the OS and manufacturers support? Refer to long discussion within netext on logical interface JA: everything we do need support from manufactures. Q1: narrow definition of the charter focusing on operational considerations or wider scope including protocol extensions Consensus on wider 'Q2' scope Q3: include both Client Based and Network Based mobility solutions in this work. Consensus on including both Client an Network. ML: says it would be more natural to start with narrow scope, then move to wider scope if necessary JA: Jari agrees and says that the charter should reflect this. Q4: enhance deployability of MIP. JA: it is unclear on Enhance deployability of MIP; it might be interested but we need more details on what it can be proposed JK: we'll continue discussion on the mailing list and work on the charter text. Clear concensus for Q2 & Q3. Additional document presentations --------------------------------- No time to present o Distributed Mobility Management Protocol with Multicast Support (draft-sarikaya-mext-multicastdmm) - Behcet Sarikaya (Huawei) o global HAHA (draft-kuntz-dmm-summary-01) - Ryuji Wakikawa (Toyota) o Negotiation of security protocol for Mobile IPv6 operation (draft-patil-mext-sec-negotiate-03) - Bruno Faria