Re: [DMM] DMM solution space categorization

Jouni Korhonen <jouni.nospam@gmail.com> Mon, 21 July 2014 15:05 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C851A0178 for <dmm@ietfa.amsl.com>; Mon, 21 Jul 2014 08:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgfzPAOzlCVW for <dmm@ietfa.amsl.com>; Mon, 21 Jul 2014 08:05:08 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71EF61A01CA for <dmm@ietf.org>; Mon, 21 Jul 2014 08:04:48 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id l18so6567695wgh.2 for <dmm@ietf.org>; Mon, 21 Jul 2014 08:04:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LiIg6c56Zis2J8boT3OoI1xDKSdEg3hqK7Fg2BJOXp8=; b=MuSbSqFE2RKfjgxDivboxZadbxg9W5XxyLzm6P2MXd3zkRUkywZRFAQHIoqRLfFSDd 0WslXAVcdek46SgbPHritqeEEaKuwntus7x/R18uQLUPdeT5Ga1LKDjay1fjMG1Kyk64 Ja3ElKxqmzOdD69I7r7Ig080bM6+VRhIK+z65qNw8i7Z4W+TDRAfHDSEJ7QnsfvRao2+ tphkjjyvCvmAmBX5MJYx2BBgxqIe84Ca8QmbfqQgd3C8RbOC5kizNA6c0nxpN9ok5qNs L1lg6xq39Y1a+X6kszcdPbckNvGL08NaT2EFwp3a9t8LzMLPLVlOfrZ3dzci9dn59ow+ 53Ww==
X-Received: by 10.194.92.244 with SMTP id cp20mr24356392wjb.109.1405955086744; Mon, 21 Jul 2014 08:04:46 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:176:e84e:7a32:d5bb:8e18? ([2001:67c:370:176:e84e:7a32:d5bb:8e18]) by mx.google.com with ESMTPSA id ey16sm42853634wid.14.2014.07.21.08.04.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 08:04:44 -0700 (PDT)
Message-ID: <53CD2C09.4010203@gmail.com>
Date: Mon, 21 Jul 2014 18:04:41 +0300
From: Jouni Korhonen <jouni.nospam@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Alper Yegin <alper.yegin@yegin.org>
References: <61D0EE5C-EAE2-4724-BE98-0F5A99441B2B@yegin.org> <53CC134D.4000908@gmail.com> <4DD56805-6DD5-4596-8E74-6593B6B1E9E8@yegin.org>
In-Reply-To: <4DD56805-6DD5-4596-8E74-6593B6B1E9E8@yegin.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5WSZVnWQTxp7pqriNfcD88vh8mQ
Cc: dmm@ietf.org
Subject: Re: [DMM] DMM solution space categorization
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 15:05:11 -0000

Alper,

7/21/2014 5:38 PM, Alper Yegin kirjoitti:
> Jouni,
>
>>>
>>> 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.

I am bringing these up because they _do_ propose a framework for 
MN-Network communication.. specifically when you need to add semantical 
information into prefix/link/etc information the network advertises to 
the MNs.

- Jouni


>>
>
>
> MIF problem space is different than DMM's.
> We should not create any dependency between the two.
>
>> draft-liu-dmm-mobility-api
>>
>
> I'll add that.
>
> Alper
>
>
>> 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
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>
>