[DMM] WG Action: Rechartered Distributed Mobility Management (dmm)
The Distributed Mobility Management (dmm) working group in the Internet Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Distributed Mobility Management (dmm) Current Status: Active WG Chairs: Dapeng Liu liudap...@chinamobile.com Jouni Korhonen jouni.nos...@gmail.com Assigned Area Director: Brian Haberman br...@innovationslab.net Mailing list Address: dmm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmm Archive: http://www.ietf.org/mail-archive/web/dmm Charter: Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and anywhere. The IETF Distributed Mobility Management (DMM) working group (WG) specifies solutions for IP networks so that traffic between mobile and correspondent nodes can take an optimal route. DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet. Wireless network deployments have traditionally relied on hierarchical schemes that often lead to centralized deployment models, where a small number of mobility anchors manage both mobility and reachability for a mobile node. The DMM WG will consider the latest developments in mobile networking research and operational practice (i.e. flattening network architectures, the impact of virtualization, new deployment needs as wireless access technologies evolve in the coming years) and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions. A topic of particular focus will be mobility anchoring in this new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC 5213, RFC 5844, RFC , RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. For example, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node such as routing protocols. When extending protocols that are not based on Mobile IP, DMM solutions will have to be reviewed by the corresponding WGs. IPv6 is assumed to be present in both the mobile host/router and the access networks. DMM solutions are primarily targeted at IPv6 deployments and are not required to support IPv4, in particular for the case where private IPv4 addresses and/or NATs are used. DMM solutions must maintain backward compatibility: If the network or the mobile host/router does not support the distributed mobility management protocol that should not prevent the mobile host/router gaining basic access (i.e., nomadic) to the network. Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further, mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g. in virtualized environments, are in-scope and encouraged. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. The working group will produce one or more documents on the following work item topics. o Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions would apply. o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. o Exposing mobility state to mobile nodes and
Re: [DMM] AERO and Mobile IP comparison
+1 on the below comment; (for a change). Per the offline discussions and the approaches reflected in https://tools.ietf.org/agenda/90/slides/slides-90-dmm-10.pdf On 10/20/14 11:16 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote: I think that in dmm maybe we should look into 21st century protocols. That may mean designing with new concepts like control plane/data plane separation, virtualization, as in vEPC, cloud, and SDN control. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] AERO and Mobile IP comparison
Hi Behcet, -Original Message- From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Sent: Monday, October 20, 2014 11:16 AM To: Templin, Fred L Cc: dmm@ietf.org Subject: Re: [DMM] AERO and Mobile IP comparison Hi Fred, I think your draft is now Rev. 44 at https://tools.ietf.org/html/draft-templin-aerolink-44 Good that you have kept up with the revisions, but I expect to put out a -45 later today that will include a reference to 'draft-vandevelde-idr-remote-next-hop' as it might provide a useful rout optimization in some cases. I don't really have any comments on the text. But if you have been wondering why AERO reminds people Mobile IP or Proxy Mobile IP or MOBIKE? AERO is different in the NBMA virtual link model, the automatic tunneling capability, the distributed mobility management capability and the BGP- based routing system. (I demonstrated the AERO BGP routing system in a call that you missed so perhaps we should show it again at IETF91.) I classify those protocols as 20th century protocols. It seems like AERO is very much like them. I think that in dmm maybe we should look into 21st century protocols. That seems like a strong statement based on not much discussion of AERO from your side. That may mean designing with new concepts like control plane/data plane separation, How do you mean by that in a way that could not be accommodated by AERO? AERO has a simple separation of data messages from control messages. virtualization, as in vEPC, Virtualization as in placing network elements in virtual machines under the control of hypervisors? I am doing that with AERO Servers in our corporate network today. cloud, Same as above. and SDN control. On this I think I need more help in understanding what advantages you think SDN provides. And, is it specifically for infrastructure-based scenarios where there is only one L2 access technology? AERO Clients can switch freely between diverse access technologies (WiFi, 4G, SATCOM, VHF, whatever) and still receive the same mobility handling. AERO Clients can even coordinate multiple active access links, such as when WiFi and cellular are enabled at the same time. AERO can switch between VPN and non-VPN approaches. That is technology for today and into the future; not something dragged out of the past. Thanks - Fred fred.l.temp...@boeing.com Regards, Behcet On Tue, Oct 7, 2014 at 4:20 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Charlie, -Original Message- From: Charlie Perkins [mailto:charles.perk...@earthlink.net] Sent: Tuesday, October 07, 2014 1:25 PM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] AERO and Mobile IP comparison Hello Fred, A few little follow-up questions... On 10/7/2014 11:39 AM, Templin, Fred L wrote: From: Charlie Perkins [mailto:charles.perk...@earthlink.net] ... This implies local-only mobility, right? Not just local, but global also. Take for example an AERO mobile router that is connecting over an access link provided by some ISP other than its home network. In that case, the node typically remains connected to its home link by setting up a VPN connection via a security gateway connected to its home network. In that case, the AERO link is said to be extended *through* the security gateway. So, the AERO mobile router remains tethered to its home link via the VPN, but it can set up route optimization with Internet correspondents in a manner similar to MIPv6. In that case, communications with the Internet correspondent can bypass the home network. - Is the VPN setup part of AERO? The AERO Client requests a DHCPv6 Prefix Delegation as part of the VPN setup. The security gateway (acting as an AERO Server) delegates the prefix and sets up a neighbor cache entry for the Client. - How does the mobile router know whether or not to do this? The AERO Client needs to know whether it is connecting to an access link provided by the home network or by an ISP outside of the home network. One way of doing this is to examine the connection-specific DNS suffix the Client gets when it connects to the access link and comparing it to the home network DNS suffix. When I think about my laptop computer user experience, I have to perform a manual intervention to select a security gateway and set up the VPN when I am connecting via an Internet access link. That would be OK and compatible with AERO as well, but would be much better if it were automated. Whether it can be fully automated depends on what kind of security credentials are necessary to establish the VPN, e.g., whether certificates alone are sufficient or whether some kind of active badge needs to be swiped, etc. Do you know more about this? - Why would the external AERO servers admit traffic from the AERO client? The external AERO Servers are security
