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

[h chan <[e-mail]>]

I have added the route update procedure for a moving network into draft-ietf-dmm-distributed-mobility-anchoring-03

I rephrased it in a few relevant sessions inside the main body instead of putting it a separate appendix. Hope it becomes more coherent this way.

Please check. 

H Anthony Chan

-----Original Message-----
From: dmm [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
Sent: Sunday, November 13, 2016 7:46 AM
To: [e-mail]
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-distributed-mobility-anchoring-02.txt

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, [e-mail] 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-a
> nchoring/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anchor
> ing-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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dmm