You may add the framework draft to that category as well. draft-liebsch-dmm-framework
Marco On 20.07.2014, at 15:11, "Jouni Korhonen" <[email protected]> wrote: > And then there is the "Distributed mobility management deployment models and > scenarios": > > draft-liu-dmm-deployment-scenario > > Forgot that.. sprry. > > - Jouni > > > > 7/20/2014 10:06 PM, Jouni Korhonen kirjoitti: >> >> Alper, >> >> Thanks for doing the categorization work. We should also try to look >> these how they fit under the proposed new milestones. See below: >> >> >> 7/19/2014 11:44 AM, Alper Yegin kirjoitti: >>> * >>> * >>> >>> I've updated the list with the I-Ds suggested by Behcet/Fred/Jouni. >>> >>> Please see below for my opinions about how each category relates to the >>> overall work. >>> Comments welcome. >>> * >>> * >>> * >>> * >>> *1. Per-flow IP address configuration according to mobility needs* >> >> "Exposing mobility state to mobile nodes and network nodes" >> >>> Apps indicating their mobility needs to the IP stack on the MN, and >>> associated IP configuration signaling between the MN and the network. >>> >>> draft-bhandari-dhc-class-based-prefix-03 >>> draft-korhonen-dmm-prefix-properties-00.txt >>> draft-yegin-dmm-ondemand-mobility-02 >> >> Then we have a number of I-Ds from MIF: >> >> draft-kk-mpvd-ndp-support >> draft-kkb-mpvd-dhcp-support >> draft-kkbg-mpvd-id >> >> These intend to build the overall method of conveying the signaling >> between the network and the mn. There are no spacific use cases >> described for mobility yet but those are then amendments for the above. >> >> draft-liu-dmm-mobility-api >> >> Above has extensions to RFC5014 for applications to check prefix >> properties. >> >> >>> This category is essential, given that we all agree mobility will be >>> treated on a per-flow basis. >>> (and once we dive into the category, I'd say the aforementioned I-Ds are >>> complementary). >>> >>> >>> >>> *2. Mobility solution selection * >> >> In my optinion this also fits under "Exposing mobility state to mobile >> nodes and network nodes". >> >>> MN determining the type of mobility solution(s) it'd apply to a given >>> flow. >>> >>> draft-yegin-ip-mobility-orchestrator-00 >>> >>> In recognition of L4+ mobility solutions (such as MPTCP, SIP, apps >>> having their own), this also becomes essential for a DMM solution. Some >>> people may argue, discussion is very welcome. >>> >>> >>> >>> *3. IP anchor selection* >> >> "Enhanced mobility anchoring" >> >>> MN selecting the IP anchor node after it decides to use IP anchoring >>> (whether in the access network or the core network). >>> >>> draft-aliahmad-dmm-anchor-selection-00.txt >>> >>> This category is supporting the Category 4, 5 and 6. This is about more >>> intelligent way of picking the IP anchor once the type of anchor is >>> determined. >>> This may produce a standalone I-D, or may be folded into individual >>> solutions in those categories. >>> >>> >>> *4. Access network anchoring* >> >> Still related to "Enhanced mobility anchoring". Many of these I-Ds >> handle the anchor change issues (like tunneling between the anchors). >> >>> Anchoring IP address within the access network using IP-in-IP tunneling. >>> >>> draft-bernardos-dmm-cmip-01 >>> draft-bernardos-dmm-pmip-03 >>> draft-bernardos-dmm-distributed-anchoring-04 >>> draft-chan-dmm-enhanced-mobility-anchoring-00 >>> draft-sarikaya-dmm-for-wifi-00.txt >>> draft-seite-dmm-dma-07.txt >>> draft-xuan-dmm-nemo-dmm-02.txt >>> draft-korhonen-dmm-local-prefix-01 >>> >>> The need for this category is well-understood. The challenge is having >>> plethora of solutions. Though the main concept is common… >>> >>> >>> *5. Corresponding node/network anchoring* >> >> Still under "Enhanced mobility anchoring". >> >>> Anchoring IP address on the Corresponding Node or Corresponding Network. >>> >>> Mobile IPv6 route optimization >>> draft-yegin-dmm-cnet-homing-02 >>> draft-xiong-dmm-ip-reachability-01 >>> draft-templin-aerolink-29 >>> >>> This category of solutions are also needed (for their ability to produce >>> better paths and different applicability with respect to the Category 4) >>> >>> >>> *6. Host-route based intra-domain solutions* >> >> "Forwarding path and signalling management" >> >>> Non-tunneling solutions. >>> >>> draft-chan-dmm-enhanced-mobility-anchoring-00 >>> draft-matsushima-stateless-uplane-vepc-02 >>> draft-mccann-dmm-flatarch-00 >>> draft-sarikaya-dmm-for-wifi-00.txt >>> >>> Solutions in this category are competing with the Category 4 type >>> solutions. There are various pros and cons. IMHO, we cannot resolve that >>> contest, hence we should produce solution for both categories and let >>> the industry pick and choose. Given that these solutions are isolated >>> from the other components (categories), standardizing both should not >>> have adverse impact on the overall DMM complexity. >>> >>> Alper >> >> - JOuni >> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmm >>> > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
