Re: [DMM] DMM solution space categorization

[Marco Liebsch <[e-mail]>]

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" <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dmm
>>> 
> 
> _______________________________________________
> dmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm