Re: [netlmm] Network-based mobility - NETLMM DT Solution Vs A solution based on MIP6

[Marco Liebsch <[e-mail]>]

Hi Vidya,

I see that a MIPv6-based solution could suit some scenarios. However,
we should also consider extensions to very basic NetLMM, in particular
to support route optimization.
MIPv6 provides complex support for end-to-end route optimization,
which might not be appropriate for a NetLMM setup in some scenarios,
where the LMA might play some role in coordinating RO. Regarding your
points 2 and 3, I don't see any reason why DNS and DHCP cannot
be used to support LMA assignment in the DT solution.

In general, I see some advantage in a transport-based protocol for
NetLMM, such as the DT protocol draft; in particular regarding
extensions for optimization to suit all deployment scenarios.

I'd like to see one solution that suits various scenarios, neither
a single solution with limited support, nor multiple solutions for
various scenarios.

marco

Narayanan, Vidya wrote:

>All,
>This is an effort to kick start a discussion of the merits of each
>approach and reach an agreement on the deltas and the importance of the
>deltas. I have purposely avoided the use of the term "PMIPv6", since
>there appears to be multiple interpretations of that among different
>people. The comparison here is between the proposed NETLMM DT solution
>(as in draft-giaretta-netlmm-dt-protocol-02) vs a solution that would be
>based on using the Mobility Header (and hence be closely aligned to
>MIP6). This is not intended to get into the degree of closeness to MIP6.
>
>
>What does the NETLMM DT Solution bring, by being totally different from
>MIP6?
>------------------------------------------------------------------------
>------ 
>
>1. The protocol can be evolved to using a reliable transport protocol
>like SCTP at some point. 
>2. The protocol can run over IPv4 without changes. 
>
>While these seem like good goals, what is the practical need for the
>above goals? For instance, is IPv4 signaling a necessity for a NETLMM
>solution? 
>
>
>What does a solution based on MIP6 bring? 
>------------------------------------------
>A solution that uses the Mobility Header can re-use a number of already
>defined options, some of them directly and some with minor changes. The
>industry is seeking a network-based local mobility solution that can
>still provide a number of features that a host-based mobility solution
>can provide. So, over time, we will find ourselves addressing these
>requirements and re-inventing these for NETLMM. 
>
>Mobility options that can be re-used with an MH-based protocol like
>PMIPv6: 
>
>1. MN ID Mobility Option
>
>This option can pretty much be used with no changes. 
>
>2. DNS-based HA lookup
>
>While some scenarios may not need this mechanism, it may make sense in
>some deployments to use DNS for this purpose, even with PMIP6. 
>
>3. DHCP-based HA lookup 
>- Home Network Identifier Option
>- Home Network Information Option
>- DHCP Relay Agent MIP6 Option, MIP6 HA sub-option
>
>Same as 2. 
>
>4. DNS Update Mobility Option
>
>This can be used to update the DNS server with the address assigned to
>the MN within the domain in which PMIP is deployed. 
>
>5. DSMIP6 Options
>- IPv4 HoA Mobility Option
>- IPv4 address acknowledgement Mobility Option
>- NAT Detection Mobility Option
>
>These options can be used without changes. 
>
>5. HA Switch message
>
>Also useful for the same purpose as in MIP6 and can be used without
>changes. 
>
>6. Other HA reliability messages
>
>We need to wait for this work to stabilize a bit more before we can
>tell, but we must be able to leverage off a lot of this work. 
>
>7. Multiple CoA Registration 
>- BID Mobility Option
>
>Can be used to signal the addition of a location of the MN, rather than
>a replace of location. 
>
>8. Flow bindings support
>- Flow ID Option
>
>When the edge is aware of the QoS needs of the MN (can happen via
>out-of-band mechanisms), flow bindings can be conveyed to the HA using
>the same mechanism as in MIP6. 
>
>9. NEMO Support
>- Prefix registration
>- Prefix Assignment
>
>The extensions defined for NEMO support can largely be re-used to
>register prefixes for the end node. 
>
>Other points: 
>-------------
>
>1. Mechanisms such as the association phase for MAG-LMA discovery
>described in the NELTMM DT protocol are potentially useful in certain
>deployments of a network-based mobility solution. However, this should
>be feasible to do in either approach. 
>
>Thoughts? 
>
>Regards,
>Vidya
>
>
>_______________________________________________
>netlmm mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/netlmm
>  
>


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