DMM Thursday 0900 ** Agenda bashing ** Milestone status - some changes there: Deleted 2nd milestone for practices/gap analysis We are about 6months behind Alper: not showing updated dates? Jouni: not changed yet. We can discuss it. Requirements: a couple of issues in the tracker. Can we submit it in 1 or 2 months? Sept/Oct Gap analysis: should be done by end of year. November? Discussion on whether new work is needed around time gap analysis is finished. Requirements document: WGLC ended 24th April. We had a healthy amount of comments. We closed 35 issues, 4 outstanding After closing those, we will have quick 1-week WGLC About new work: to work on a new doc/solution you need to: o Identify a gap o Get the WG to agree on the identified gap o Document the gap Once practices & gap doc is stable, we can review solutions Sri: in light of CP/DP separation, architecture isn't captured in pure centralized/distributed distinction. Distributed model should capture CP/DP separation. ** draft-ietf-dmm-requirements (Anthony Chan): About 40 tickets, many tickets had multiple items. Lots of helpful comments from different people. Resolved most tickets before -06, now down to 4. Major revisions in security considerations (REQ6) and multicast (REQ7) Ticket #34 (Charles): Problem statement should appear in an initial section. Now there is a Section 4. Ticket #38 (Charles): REQ1: change "IP session" to "flows". Charles: place in doc where talks about IP multicast session: that should also be re-worded, handle case where a node joins a multicast group, traffic flows until node leaves Should also change "IP multicast session" to "IP multicast flow" Ticket #39 (Charles) Specify that signaling reduction is at the central anchor point Ticket #40 (Charles) Editorial changes We will need -07 version to re-word multicast session. Charles suggested wording in Ticket #38. Anthony can upload version 7 today. Sri's comment on split architecture also needs to be incorporated. Sri & Alper to provide text to Anthony after -07 is out. ** Current Practices & Gap Analysis - draft-ietf-dmm-best-practices-gap-analysis (Dapeng Liu): Good progress has been made. Currently -01 version. Merged past two documents. Updated based on last meeting's comments. No major concerns, can resolve comments quickly. Outline Section 3: functions of existing mobility protocols. Existing MM functions o Anchoring o Mobility Routing o Location Management o Location Update Section 4: DMM Practices Wi-Fi Network 3GPP Network 4.2.1: Host-based DMM practices MIPv6 can be used with multiple mobility anchors Also route optimization supported Some limitations 4.2.1: Hierarchical MIPv6 Similar to MIPv6 except introduces MAP function Can reduce signaling cost, MN can select nearest MAP MN can also have different mobility anchors 4.2.2: Network-based DMM practices Proxy MIPv6 Not so easy to use network-based in distributed deployment, but you can do similar things Multiple LMAs, MN can choose the nearest LMA as optimal anchors Some optimization mechanism e.g., LR specified by PMIP 4.3: 3GPP Network Flattening Approaches Describe EPS architecture Received comments that we can add more text about gateway selection 2 special cases in this section 3GPP/LIPA (Local IP Access) 3GPP/SIPTO (similar, but with local gw) Above 2 have no mobility support 5: Gap analysis Functions that DMM needs o Multiple anchoring o Dynamic anchor assignment / re-location o Multiple IP address management Sri: multiple anchors/IP addresses, should talk about ability to identify those addresses. Should be able to say which addresses have which properties. Need to carry metadata in address assignment procedures. Should be reflected in multiple IP address. Should be 4th bullet. Juan-Carlos: can you suggest some text? Alper: first line should say simultaneous use of multiple anchors. Also, MN should be. Kostas: at least one solution, you can be anchored & tunneling in one place, but not anchored in another place. Pete: Does anchor mean tunneling? If so, should talk about point of attachment where original IP address was topologically correct. Sri: no, doesn't mean session traffic is running through it Marco: maybe need definition of anchor Carlos: point where address is topologically correct, does not imply tunneling Jouni: are people happy with identified gaps? If not, raise it on mailing list and provide text proposal. Georgios: I thought we would actually use requirements to identify the gaps. I didn't see them. Dapeng: gap is still ongoing work. We can match the gaps to the requirements. This will be a next step. Work is almost complete except for gap analysis. We can work on it. Behcet: Multiple IP address management: should clarify what kind of address, CoA, proxy address. Dapeng: mostly about selection of source address, MN's address Carlos: there is already more text in the document than the 2 or 3 words on the slide. Comments received Alper/Park: Section 4.1 Not so sure "connection manager" is the right term Accepted Juan-Carlos: there's ongoing discussions in mif, defining provisioning domain, etc. Perhaps it will be relevant for defining mapping between interface/address/application, etc. Perhaps will need to be refined, but not sure we want to wait for mif. Something more generic? Dapeng: prefer proposal to use something more generic Section 4.1: Mobility management could also be triggered due to load balancing, originally only talked about mobility Resolution: accept Should we describe the terms IP session continuity and IP address reachability The DMM charter says maintenance of stable home addresses and/or prefixes and upper level sessions is a desirable goal..., it is not a strict requirement So IP address reachability may not be in the scope Jouni: do you mean running servers? Dapeng: yes, think that's what Alper meant Sri: should capture both ideas. IP address connectivity vs. session continuity. From overall requirements should capture both. Charles Perkins: address reachability is a problem introduced by mobility, is important for people who provide services on Internet, would like to see the documents consider the problem of IP address reachability. Carlos: requirements not yet talking about this. Reachability as an IP address that is continuously in use to allow establishment of sessions is not in scope. Alper: Carlos's point covers the intention, we can rename it, as for the scope of the work, we can say that reachability & session continuity are separate requirements, we must support session continuity, and MAY consider solutions that support reachability for those small number of applications that require services. RCoAs Jouni comments: WiFi deployment "most" : remove Charles: there are 2 ways to support this: 1. more data carried, 2. more WiFi APs than BSs. We should be designing for overall Internet & that's predominantly over WiFi. Dapeng: we can just make it more generic to avoid controversy Alper: should just acknowledge that WLAN should be considered equally for the solution space as the cellular networks. Current situation is like Charlie described, it may change over time, but we shouldn't consider all cellular. Section 4.2.1: dynamic discovery: IETF doesn't have a mechanism but 3GPP does. Accepted Using CoA directly is valid. Accepted. References. Accepted. Add MOBIKE in 4.2. Accepted. Sri: don't think I agree that MOBIKE is the most deployed client. Dapeng: deployment statement is not in the draft, just mention of MOBIKE. Jouni: in end-devices, you can find MOBIKE in every Linux distribution, Windows, etc. Code is out there, just a matter of making use of it. Sri: prefer to keep marketing speak out of it Section 4.3: references updated. Accepted. Text on WiMAX? Accepted. Section 4.3: add text about use of DNS as gateway location database. Accepted. Section 5: anchor relocation. Accepted. Dynamic discovery / selection of anchors in gap analysis. 3GPP 29.303 makes it possible. We don't have such mechanism in IETF. Next steps: add WiMAX part, ready for WGLC? Jouni: what we do next will be based on identified gaps in gap analysis document. If you have something in mind, it needs to be in the document. ** draft-aliahmad-dmm-anchor-selection (Danny Moses): Starting to see discussion about anchor selection for various use cases recent demo showed one approach, always use the closest. not always optimal. Should go one level deeper: list various use cases that can give us algorithms for selecting anchors. Simple example - which is the best MA? Flip a coin? Check the load? A future HO to BS2, MA2 is connected to both BS1 & BS2, maybe MA2 would be best What if path is from home to work? Should choose MA1 (home) or MA4 (work) It is difficult to predict the mobility pattern of MN. Decision is different based on: o Applications MN is running (can they tolerate IP address changes)? o MN apps generate short flows? o MA3 is overloaded? o The user spends most of her/his connection time at home? Criteria for MA selection: o Network context o MA or access router or NW segment load o Influence on NW performance (delays, hops, bandwidth) o NW layout o Application context o Lifetime of flows generated by the apps o Sensitivity to IP address change o Mobile device (or user) context o Mobility patterns of the MD (or its user) Sam: interesting topic, but we need to talk about how MAs are discovered before we can select them. If discovered by network, there is lots of information configured by operator. If discovered by MN, there is a more limited set of MA. Network operator does not want to expose the whole list to MN. Danny: agree, 2 groups of alternatives Sam: if only 1, how do you select? Danny: would recommend network architect to provide more than one. We didn't discuss algorithms for selection. Didn't discuss whether better for network to assign or let MN do that. Something we should work on. ** PMIPv6-based distributed anchoring (Carlos Bernardos): draft-bernardos-dmm-distributed-anchoring-02 Demonstration: DMM & CDN demo PMIP tunneling from original MAAR to current MAAR Common to other approaches Routers at the edge (D-GWs) Anchor routers close to the user, assign addresses to the MNs Re-using PMIPv6 Anchors are distributed GWs, play role of LMA and MAG Does not require any host changes Behcet: how does it work without centralized anchor? Carlos: CP can be centralized Distributed Logical Interface (DLIF) concept 1st time assigned to an anchor, assigned logical interface, is re-created whenever MN moves PeteM: still have single points of failure, sub-optimal routing Carlos: routing approach possible, still have pros & cons ** Correspondent Network Homing (Alper): Use a HA near the CNs, so that as MN moves around, data path still anchored on HA, not creating a triangular route. Kostas: still have triangular routing, just looks a bit different. Alper: if HA is on the natural data path, it does not create triangular path. Kostas: maybe there are better/worse triangles, they are still triangles. Place CHA in CNet: MNs discover CHAs, allocate session IP address CHoA Call flow: New messages, DNS lookup, send BU to CHA, get allocated CHoA Application starts using CHoA Mobility & application tear-down Security considerations: Allow CHoA only for associated CN communication (this is not a VPN service) Protecting the CHoA pool o Use a large pool OR o Use authenticated BUs Kostas: security implications of assigning addresses to unknown MNs? Alper: using authenticated BUs. Kostas: don't think it's going to happen in real-life. Danny: if modify this scenario a little bit, with MN & CHA on same network, this idea is perfect. Marco: reasonable step to take the CHA location into account. Tricky to take the DMM aspects of transparent caching. CDNs work with transparent caches, need to put CHA there, which is close to MN. Alper: most CDN techniques are based on DNS Marco: CDN caches integrated in mobile network, at the AP in extreme case. If you select the anchor based on CN's IP, you get centralized anchor. That is sub-optimal. Carlos: resembles a bit the Correspondent Router drafts in the context of RO for NEMO, maybe take a look at those. Discussions were to put a router close to other guy, discussion may be useful. Ryuji: authored corresponding-router, submitted to MEXT. "Back to my MAC" uses similar solution. Very hard to see deployment of this system. As operator, do we have to go to Google to have them put in the anchor? If CN is mobile, what happens? Alper: majority of traffic is not MN-to-MN. We don't handle that. Majority of traffic is MN to server. On-demand Mobility: no time to present. Will present next time. ** draft-chan-dmm-framework (Anthony Chan): Distributed Mobility Management Framework A common framework will make it easier to compare different solutions, continue to design new protocols, make them more compatible with each other. Try to find something general enough to accommodate different protocols/solutions, incorporate centralized and distributed, host based and network-based solutions. Informational, not for standardization. Few logical functions: o Session identifier management o Location management o Mobility / Modified router Comparing framework against DMM requirements: REQ1: functions are general, support centralized vs. distributed REQ2: transparency to upper layers, model does meet requirement REQ3: IPv6, model is independent of version REQ4: Existing protocol, no problem REQ5: Coexistence REQ6: Security REQ7: Multicast Proposing for informational Jouni: what do you want to do with this document? Anthony: informational document, as companion to gap analysis Kostas: as co-author, very good idea, a number of proposals to change existing protocols, may end up with fragmentation of proposals and no high-level view. We can have a high-level understanding of how these things work. Not aiming for standards track. Better understanding, high-level view of how things work in DMM. This worked quite well in other WGs. ZhuLei: the same. Document has principles of what DMM is like. Georgios: Agree with goals of framework, but this draft is not accurate enough for developers to use certain components specified in the framework draft and defined solution. Framework draft should be protocol agnostic, but used by developers to build their solutions. ** Stateless user-plane architecture for virtualized EPC (vEPC) (Ryuji): EPC core Network Function Virtualization (NFV): virtualized EPC on hypervisor Need to signal things to vEPC, data traffic can bypass it Motivation: all state regarding MN is in cloud, need to reflect that state to user plane vEPC to core/backbone, routing protocol (BGP) can carry state in user plane Extensions to proxy Mobile IP (wg doc draft-wakikawa-netext). SDN/OpenFlow?? FORCES WG? Stateless user-plane architecture: use BGP Outline document Configuration (diagram). vEPC in cloud, EPC-E (router) interface to RAN eNB establishes GTP tunnel to anycast address of EPC-edge router BGP used to update route to TEID next-hop Aggregation can be done by BGP Address delegation: reverse lookup, destination to next-hop Backward compatibility: just terminate tunnel to SGW Alper: separate BGP part from vEPC Pete: why no changes to eNB? Can we separate BGP/DMM protocol from 3GPP link layer? Sri: why tied to EPC? Kostas: why BGP? Miya (cisco): totally feasible ** Extending Existing protocols (Fabio): Client Mobile IP Proxy Mobile IP Distributed Anchor Router (DAR). First hop router, default gateway. When MN is on-link, DAR is plain IPv6 router. If MN is not on-link, packets are tunneled to current location. Network-based solution: Control plane centralized, data plane distributed among edge routers. MAAR (Mobility Anchor Access Router), Central Mobility Database (CMD). CMD as PBU/PBA proxy - notifies old router about new location. Marco: Client solution: Session started at DAR1 continues at DAR3? IP address transferred to DAR3? Fabio: no tunnel is established with MN. ** draft-liebsch-dmm-framework-analysis (Marco Liebsch): Visibility of SDN/BGP to support mobility management, for DMM it may be beneficial. We may consider interworking with these protocols, allow optimization of performance, cost A lot of DMM proposals consider forwarding from previous anchor to current anchor. We should mitigate the changes to existing protocols, although spec should be self-contained. DMM solution should at least consider hooks for interworking with other architectures. Methodology of framework is to specify 4 functional entities: Current draft defines reference points between these 4. A function may be accomplished by an existing protocol, mobility or some other protocol. Map FE to existing protocol, identify gaps, produce extensions. Should expose attributes to external protocols for optimization according to specified reference points. Draft not updated since Atlanta, unicast framework is mature: Indirection of traffic: FE_I, FE_E. could be accomplished by routers, tunnels, forwarding. Control functions: FE_IEC, FE_MCTX. Example: Mobile IPv6, mapping to FE_MA, FE_MU C&U HA interaction to set up DMM indirection Could be context transferred, with SDN just enable routers to retrieve this information. MN-centric Model, Mobile IPv6. FE_MCTX on MN. conclusions: DMM analysis and specification of extensions should be done on a functional level Proposed functional framework enables analysis and specification beyond mobility protocol level: o Keep DMM solution extensible and deployable o Apply DMM framework to analysis Behcet: good work, but there is another framework document? Can we merge the two? Marco: the drafts are too different. This is protocol agnostic, allows exposing some info, non-mobility protocols. Motivation of two drafts are different. Up to WG to decide what to do. Alper: adoption means, all solutions being proposed should be represented in these terms? Marco: framework could identify information as well as interfaces that allow this protocol to expose information to non-mobility protocols. Current protocols are self-contained. If we could have a more optimal routing path, not rely on forwarding from previous to new, that's an option. Alper: how is that related to framework? Did it help us realize that? Marco: framework allows us to place the FE_I, FE_E on other routers (not just anchor). Alper: apply this framework to a couple of the solutions, then make the case what it means, then people would better understand the framework. Charles: strongly think we should not have 2 framework documents. Maximum number should be 1. Abstraction was from the bottom up, was everything considered? What about IP address reachability? Marco: fully agree we should converge to single document. Approaches for framework & how FEs specified were different, would be up to the WG to decide. Jouni: seems there are people in the WG willing to work on the framework. At the point We have identified that we need new work, then we can consider a framework document. Who is against having a framework document? 1 or 2 Alper: would like to see the utility. Jouni: it's not in the charter at the moment, 2 individual contributions, have been here for a long time. Will it create a fight in the WG if we go and re-charter, and put framework document in the list. Then we need to understand how it will affect the rest of the work. Sri: same concern, we have requirements, gap analysis, now with framework, how will we keep parity among the documents. If we can figure out how it will be used, then maybe ok. Marco: not arguing that we don't need self-contained protocols. Jouni: will move discussion to mailing list, we can discuss between now and next IETF Who is willing to work on this? about 20 Who is against? none. ** draft-liu-dmm-mobility-api-01 (Dapeng Liu): Was presented in IETF83 Some updates informational -> standards track. RFC 5014 defines socket API for source address selection. In DMM, people discussed a lot about SA selection, from API perspective we need 5014 extensions. IPV6_PREFER_SRC_LOCAL_HNP IPV6_PREFER_SRC_REMOTE_HNP Sri: we should wait until we have better defined semantics Dapeng: if we have some solutions specified, we need to solve this API problem. Want to keep the doc active. Sri: agree, but should move at very slow pace. Alper: this work has significant overlap with on-demand mobility (not presented today) and we support this approach. ** draft-liu-sdn-mobility (Dapeng Liu): SDN can be used to solve mobility problems. Maybe we can simplify the wireless core network significantly, we can move the anchor point from the core network, put functions in the cloud, access network can connect to the cloud, will be very simplified. Potential solutions: Enhance SDN to support mobility tunnel handling (setup, update). Routing based SDN mobility support: forwarding function detects movement event of the mobile node and notify the controller. Not sure if proper to discuss this topic here, but would appreciate comments and networking to see how to proceed.