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:[email protected]] On Behalf Of Alexandre Petrescu
Sent: Sunday, November 13, 2016 7:46 AM
To: [email protected]
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, [email protected] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to