Network-based Mobility Extensions (NetExt) Bof THURSDAY, March 26, 2009 1300-1500 Afternoon Session I in Imperial A Bof chairs: Rajeev Koodli Basavaraj Patil Acknowledgment for the meeting minutes: Samita Chakrabarti Harsh Verma ----------------------------------------------- 1. Bof Overview and Scope - Chairs - Background – Bar BoF discussion held at Dublin IETF , dinner meeting at IETF73, work on problem statements initiated - PMIP6 is one of the protocols for IP Mob management in emerging network architectures (LTE/SAE in 3GPP, Wimax) - A few improvements/deployment considerations need to be addressed · Multi-interface support · Localized routing · Inter-technology handovers - Objective today: Discuss if we have consensus w.r.t the proposed extensions to PMIP6 and whether to form a wg to work on the same - Ground rules: . Assume PMIP6 as the basis [ no MIP6 interaction] . Not a placeholder for all NETLMM related topis Hesham - Is that a realistic rule? Jari – clarified that will take into account for new MIP6 features, but we already have a charter in the general WG. Jari - if we develop a new feature, it should not become harder or we should provide a mechanism. This WG will only deal with the problem but not provide a solution The intent here was that we are not going identify any new work Sri - Be careful of formulating Ground Rules Jari – Interaction with MIP6 Vijay – had a comment on which is a concern that PMIP6 is still not a deployable protocol. There are still a few more items.. Rajiv – MN involvement is not the same as protocol-level changes. The question to ask is can we not design a protocol without host changes for the problem in question? What breaks and what doesn’t? Domagoj – comment – if something has to be done on the MN side, why can it not be taken care of Hesham – No changes to the MN approach – if we have to change it we will change it. Rajiv - We do not want to design disincentives. It is too early to say that host changes are needed. Jari – If we have a proposal that allows us to do things, it will go into the charter and others will not. ..................... 2. Multi-interface support for PMIP6 ( Vijay Deverapalli) I-D: draft-jeyatharan-netext-multihoming-ps-01 -Using PMIP6 to specify multi-interface network mobility is under-specified. Scenario1 - setting up mobility sessions on demand: additional mobility session for a particular service Scenario 2 – Flow mobility MN may bring up another interface is another access is available and then move some flows to the other interface for load balancing Scenario 3 : attachment to a new MAG and multi-interfaces of MN -- handover of sessions from if1 to if2 and MAG-old to MAG-new Parvez – There are 3 different scenarios, but what about an MN attaching to multiple PDNs? Should it use the same address? Vijay – different IP addresses for different interfaces Dave - Scenario 2: If the MN wants to move flows from one IF to the other, is the same IP address used on both interfaces?? Sri – If there are interfaces with a virtual node, it is possible. Sri – Ques on Scenario 1 – If the interface is hidden, it would be an extension to 5213 and 5213 does not prevent it Hesham – This is not rocket science. It is not a new problem. Rajeev – this is not a new protocol, but there are obviously implementation issues Hesham – does not make any sense from the perspective of no MN changes Raj – there may be things that could b done at another layer which could accomplish the same thing. We are not re-inventing a new protocol. Jonne – Sc 1: you cannot distinguish different PDNs, so what will be needed here? Vijay – just to first see if there is a problem and can it be solved with an access service mechanism. Rajeev – it could be a PDN, but this is for a new additional session ??? – assign multiple Try to assign two interfaces, it does not work. Tricks people do to hide Rajeev – it is difference between protocol and what you need to do for implementation ??? - It requires Mobile Intervention. Not sure if we can do this at IETF Kent – Need a document what can change in implementation and what cannot be changed. Ans(Raj): We will look into that but the current BOF is to describe the problem Raj – we will have to deal Dave – Are we talking about changes to some proprietary info about MN or dependencies of RFCs? Sri – Would you consider? Dave – there is no RFC Jabber - Vidya says that we do not want to modify MN in any way to support this feature ........................ 3. PMIPv6 localized routing (Marco Liebsch) I-D: draft-liebsch-netext-pmip6-ro-ps-00 Obj: establish and maintain forwarding data for two MNs (during handovers) without going through MN’s LMA. Fundamental difference to host mobility, such as MIPv6 RO. MNs have no control on setting up localized routes is correct Discussion – Kent – Are Handovers also covered in Detection and Setup When you are doing Handover, you want to establish and maintain the optimized routing. Is the scope MAG to MAG or LMA to LMA? Raj – the base spec allows you to do Localized Routing Marco – if you handle everything locally Carlos – use of EnableMAGLocalRouting Flag within the scope of the work should be clarified. We are only assuming PMIP MNs. This Flag is used for optimizing between a PMIP and regular host. Sri – No, this is not so. Sri – Is the focus on lack of signaling? Parvez - Should send an email on his point Raj – granularity of localized routing may be discussed ??? – IPv4 mobile node support is covered? Ans: LMM may cover IPv4 address. So it is possible. Rajeev – the flow can be between any two end-points and not restricted to hosts that are PMIP6 MNs only .................... 4. Inter technology handovers (Suresh Krishnan) I-D: draft-krishnan-netext-intertech-ps-00 See slides for PS overview. Discussion Chan Wah – What is the timeframe for Predictive Handovers? Suresh – Does not matter, can be a second or a day Suresh – Access Network may be separate from Mobility Provider. Sri – Implementation Specific Issues – is Prefix an issue? If we move to a new prefix, the app will break Let’s say we have a Virtual Interface sitting on top of two physical interfaces Hesham – agree with points, what happens when there are two different access technologies? Carlos – problem of not knowing the other interface, it goes beyond the scope of IETF, as we do not want to deal with Layer 2 Suresh - We are only trying to agree on what the problem is Telemaco – testing the scenarios, DHCP does not work. Kent – Not sure if single radio Vs multiple radio was discussed, Sri – Predictive handover will not network when there is single radio Summary: Lot of discussion and issues related to single radio, dual radio, lower layer information and how apps are bound to an interface etc. .................... 5. Bulk re-registrations (Domagoj Premec) I-D: draft-premec-netlmm-bulk-re-registration-02 - Comparison using 500000 MNs and 20 MAGs - ML Discussion summary - Issues with LMA Selection [ runtime selection functionality] Kent, Sri: Support dynamic LMA selection – good idea. Let’s talk about re-registration solutions. Hidetoshi –Support Jonne – Support ...................... 6. Runtime LMA selection (Domagoj Premec on behalf of Jouni Korhonen) I-D: draft-korhonen-netext-redirect-ps-00 General consesus on the problem statement and support for doing this work in Netext. ..................... 7. Open discussion Sri: Need document on intertechnology interface handover on multiple interfaces Hesham: Talking only about multihoming issues. How do you move PMIPv6 over interfaces? Can’t move. Raj: That’s the problem we would like to solve; some people believe it is solvable. George: Be careful when you say it’s done. It may be done in a SDO but it is not the same as in IETF. DT: On the issue of multiple-interfaces, don’t move the the address from interface to interface over ANs – it can only move from virtual interface to virtual interface. James kempf: Local routing and such are good ideas. Jari: With regards to multihoming and handover, agree that there is a problem. Don’t have to solve in one way only Vidya: multihoming within PMIP protocol – PMIP was not chartered for that. Multihoming/Handover cannot be solved without mobile node involvement. Parviz: Don’t like that we are coming to IETF with a solution Speaker: Moving IP-addresses is not the right thing to do. Sri: Let’s focuss on session continuity. ................ Questions to the WG about various work items: - Localized forwarding, bulk-registration, Runtime LMA selection – no controversy and consensus to work on these problems - On the question about multihoming/flow mobility and, inter-technology handovers there was a split about whether Netext should extend PMIP6 with these features Jari also asked a question about whether host based MIP6 should be used as the means to address multihoming and intertechnology handovers Vs PMIP6 There was again about equal support for enabling these features using host based MIP6 vs using PMIP6. More discussion on these features to be continued on the ML.