Re: [DMM] I-D Action: draft-ietf-dmm-distributed-mobility-anchoring-02.txt

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sun, 13 November 2016 13:46 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5717C129488 for <dmm@ietfa.amsl.com>; Sun, 13 Nov 2016 05:46:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 UAqHfg4hRP61 for <dmm@ietfa.amsl.com>; Sun, 13 Nov 2016 05:46:14 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDE8E1294B2 for <dmm@ietf.org>; Sun, 13 Nov 2016 05:46:13 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id uADDkBi6013816 for <dmm@ietf.org>; Sun, 13 Nov 2016 14:46:11 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8AFD0201B6C for <dmm@ietf.org>; Sun, 13 Nov 2016 14:46:11 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 81298200BEA for <dmm@ietf.org>; Sun, 13 Nov 2016 14:46:11 +0100 (CET)
Received: from [132.166.84.111] ([132.166.84.111]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id uADDk9vD007974 for <dmm@ietf.org>; Sun, 13 Nov 2016 14:46:10 +0100
To: dmm@ietf.org
References: <147470052331.9303.17268383454852773218.idtracker@ietfa.amsl.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b34254d2-e0d0-1a66-a7ec-90432891035a@gmail.com>
Date: Sun, 13 Nov 2016 22:46:08 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <147470052331.9303.17268383454852773218.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/sXGOntnxM9TdJOZNdyOwpIo5j1o>
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-distributed-mobility-anchoring-02.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 13 Nov 2016 13:46:16 -0000

Hi Anthony,

Thank you for this new version of this draft.

I am happy that NEMO has now its own section.

However, I would like to further illustrate the route update procedure 
for a moving network.  Maybe the text below can be put in a new appendix.

What do you think?

Alex

Illustration of a Route Update Procedure for Moving Networks
------------------------------------------------------------

This section decribes a potential route update procedure for a moving
network; the scenario does not use the protocol Mobile IP, and does not 
involve any tunnel.  The procedure involves a hierarchical topology of 
three fixed routers: R1 is connected to the Internet, and two Access 
Routers (AR1 and AR2) are each wired to R1; moreover, each AR offers 
wireless access to other mobile entities interested to connect to the
nternet.

               ^ To the Internet
               |
               | wired link
              +--+
              |R1|
              +--+
              /  \
             /    \
            /      \ wired links
           /        \
        +---+      +---+
        |AR1|      |AR2|
        +---+      +---+
          |         |
          |         | wireless links
          o         o


The moving network is made of one Mobile Router (MR) and one Local
Fixed Node (LFN):


        o wireless link
        |
        |
      +--+       +---+
      |MR|       |LFN|
      +--+       +---+
        |          |
        |          |
        ------------- wired links


The routing tables of R1, AR1, AR2, as well as the addresses on the
interfaces are depicted below:

                             ^@gw
                             |                  R1 Routing Table
                             |i0                1:1:1::/48 *        i1
                            +--+                1:1:2::/48 *        i2
                            |R1|                1:2::/32   1:1:1::2 i1
                            +--+                1:3::/32   1:1:2::2 i2
                i1;1:1:1::1 /  \ i2;1:1:2::1    default    @gw      i0
                           /    \
               i1;1:1:1::2/      \i1;1:1:2::2
   AR1 Routing Table     /        \             AR2 Routing Table
   1:1:1::/48 *     i1 +---+     +---+          1:1:1::/48 *        i1
   1:2:1::/48 *     i2 |AR1|     |AR2|          1:3:1::/48 *        i2
   default    1:1:1::1 +---+     +---+          default    1:1:2::1 i1
                         |         |
              i2;1:2:1::1|         |i2;1:3:1::1
                         o         o

The addresses on the moving network are depicted below.  The MR self
configures an IPv6 address on its interface i1 that is derived from
the prefix advertised by AR1 on AR1's interface i2.  Moreover, the LFN
and other fixed computers inside the moving network are using the
fixed stable prefix 1:2:1:1::/64.  Remark, this prefix is 'aggregated'
in the prefix of AR1.

                          o
                          |
               i1;1:2:1::2|
                        +--+       +---+
                        |MR|       |LFN|
                        +--+       +---+
                          |          |
                          |          |
                          -------------
                           1:2:1:1::/64

When connecting the moving network to AR1, there is a need for LFN to
become reachable; there is a need for an additional routing table
entry in AR1.  This entry E is "1:2:1:1::/64 1:2:1::2 i2".  This entry
can be installed during other protocol message exchanges performed by
MR, e.g. DHCPv6-PD, or other.

When the moving network moves to AR2 there are several new steps that
need to be performed:
- E must disappear from AR1 Routing Table
- a new E' must be added to AR2 Routing Table; the E' must be
   "1:2:1:1::/64 1:3:1::2 i2"
- a new E" must be added to the R1 Routing Table; the E" must be
   "1:2:1:1::/64 1:1:2::2 i2"

These steps may be triggered by the SLAAC, DHCPv6-PD, OSPF and/or BGP
operations initiated by MR.


Le 24/09/2016 à 16:02, internet-drafts@ietf.org a écrit :
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Distributed Mobility Management of the IETF.
>
>         Title           : Distributed Mobility Anchoring
>         Authors         : H Anthony Chan
>                           Xinpeng Wei
>                           Jong-Hyouk Lee
>                           Seil Jeon
>                           Alexandre Petrescu
>                           Fred L. Templin
> 	Filename        : draft-ietf-dmm-distributed-mobility-anchoring-02.txt
> 	Pages           : 45
> 	Date            : 2016-09-23
>
> Abstract:
>    This document defines distributed mobility anchoring to meet diverse
>    mobility needs in 5G Wireless and beyond.  Multiple anchors and nodes
>    with mobility functions work together to provide IP mobility support.
>    A network or network slice may be configured with distributed
>    mobility anchoring depending on the needs of mobility support.  In
>    the distributed mobility anchoring environment, multiple anchors are
>    available for mid-session switching of an IP prefix anchor.  Without
>    an ongoing session, i.e., no IP session continuity required, a flow
>    of a mobile node can be re-started using a new IP prefix which is
>    allocated from a new network of the mobile node and is therefore
>    anchored to the new network.  With an ongoing session, the anchoring
>    of the prior IP prefix may be relocated to the new network to enable
>    IP session continuity.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchoring-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-distributed-mobility-anchoring-02
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>