[DMM] DMM solution space categorization

Alper Yegin <alper.yegin@yegin.org> Sat, 19 July 2014 08:44 UTC

Return-Path: <alper.yegin@yegin.org>
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 6EA341A03BE for <dmm@ietfa.amsl.com>; Sat, 19 Jul 2014 01:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 lLExUWzdDAZQ for <dmm@ietfa.amsl.com>; Sat, 19 Jul 2014 01:44:09 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA081A02EC for <dmm@ietf.org>; Sat, 19 Jul 2014 01:44:08 -0700 (PDT)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0MAvmU-1XIHcP1lEC-00A1Xa; Sat, 19 Jul 2014 10:44:07 +0200
From: Alper Yegin <alper.yegin@yegin.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9983CEBA-6F91-4F17-A1FD-F9A0FF116669"
Date: Sat, 19 Jul 2014 11:44:03 +0300
Message-Id: <61D0EE5C-EAE2-4724-BE98-0F5A99441B2B@yegin.org>
To: dmm@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:IabX4ekpc+haQAt94Cdv2p+xxN6uzWlRK4WuqgF85Kw twKWrcev51z0Oq//fXo4vski+Sj3pPSkJMFlDpmcVALvPO7rzf m0KkDM56ONqfnoK3/z3bqpvCLo9Rwz11IvHaph6quuXLnzIiKL 9884cjdQU3Thbt7kjEMBhr3vxQvL/OffgPuuhRvMj3iiMZosZI zEuCUqqcHc+1o3Lw4KVveyrwmczMyiTpPOnYgpz2Z8kUlruMwc R4atZDzFuSTIVp3TJRi8GbfsCibyQVNu6o2BIzzrCfB/ic9lbQ lTGqH9vsO2cqZtzsl0mlsJ+mQPKpobmXZvYB6zP8EVrxchXoGy DxIOGP2ABXl60iBLCcpUwI5cqysb/ldnxMLJ41XJMxsayDXqD2 W2cHA/96Fk/mw==
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/jOWjLC6Zta7LklgZ5hQ_LnN3CnQ
Subject: [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: Sat, 19 Jul 2014 08:44:10 -0000


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

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

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 

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

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

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

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

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