Alex, Do you have a specific change to the text in mind? The charter text uses systematically "mobile host/router" to make sure mobile routers are not forgotten. However, charter also allows solutions that are not specifically tailored to mobile routers.
Jouni -- Jouni Korhonen Broadcom (Sent from my mobile..) > Alexandru Petrescu <[email protected]> kirjoitti 8.10.2014 kello > 14.38: > > Hello, > > I would like to comment on reusing prior work. > > Citing RFC3963 and RFC 5177 (v4 and v6 extensions to Mobile IP for network > mobility) seems logical to me, since they're about Mobile IP too. > > Citing RFC 4888 and RFC 4889 (NEMO Route Optimization PS and solution > analysis) seems logical to me, since the charter says "optimal" routes. > > Currently there is discussion in the DMM WG sketching potential solutions. > When they're ready they'll certainly compare to these two sets of RFCs, and > will have to answer same questions: does it work with Mobile Router (not just > Mobile Host)? does it offer optimal routes? does it modify CN? is it > subject to 'stalemate' situations (RFC4888 section 2.7)? does it involve > multiple encapsulations? does it permit nestedness? > > Alex > > Le 03/10/2014 21:38, The IESG a écrit : >> The Distributed Mobility Management (dmm) working group in the Internet >> Area of the IETF is undergoing rechartering. The IESG has not made any >> determination yet. The following draft charter was submitted, and is >> provided for informational purposes only. Please send your comments to >> the IESG mailing list (iesg at ietf.org) by 2014-10-13. >> >> Distributed Mobility Management (dmm) >> ------------------------------------------------ >> Current Status: Active WG >> >> Chairs: >> Dapeng Liu <[email protected]> >> Jouni Korhonen <[email protected]> >> >> Assigned Area Director: >> Brian Haberman <[email protected]> >> >> Mailing list >> Address: [email protected] >> 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 5555, 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 both informational architectural and >> standards track protocol solutions 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 network nodes: >> define solutions that allow, for example, mobile nodes to select >> either a care-of address or a home address depending on an >> application' mobility needs. In order to enable this >> functionality, the network-side control functions and other >> networking nodes must also be able to exchange appropriate >> control information, as well as to the mobile nodes and their >> applications. >> >> The working group may decide to extend the current milestones based on >> the new information and knowledge gained during working on other >> documents listed in the initial milestones. Possible new documents and >> milestones must still fit into the overall DMM charter scope as outlined >> above. >> >> Milestones: > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
