Hi, I think MIP6 and derivatives could very well be a part of the solution. However, we need to place them into scenarios where the anchors are allocated dynamically on an as-needed basis and garbage collected when they are no longer needed. This may introduce some new requirements.
-Pete Rajeev Koodli wrote: > > Hi Jouni, All, > > Sorry if this has been captured before.. > > Shouldn't there be a very basic requirement that should first outline > why MIP6 and derivatives could not be deployed in scenarios suitable for > DMM? I reckon this assumes a clear description of what DMM is exists. > > Thanks. > > -Rajeev > > > > On 5/17/12 4:56 PM, "jouni korhonen" <[email protected]> wrote: > >> >> Few comments/questions here: >> >> On May 7, 2012, at 8:58 PM, h chan wrote: >> >>> REQ-2: Transparency to Upper Layers The DMM solutions SHALL enable >>> transparency above the IP layer. Such transparency is needed for the >>> application flows that cannot cope with a change of IP address and >>> when mobile hosts or entire mobile networks change their point of >>> attachment to the Internet, but SHOULD NOT be taken as the default >>> behavior. >> >> "SHALL enable" but "SHOULD NOT be taken as the default behavior" seem >> to conflict. So, what is really meant here? Does this mean something >> like "MUST implement, SHOULD use" type of solution? Or can one leave >> transparency completely away if the applications/hosts just don't care >> whether IP changes or not? >> >>> >>> REQ-2M (Motivation for REQ-2) >>> The goal of this requirement is to >>> enable more efficient use of network resources and more efficient >>> routing by not invoking mobility support when there is no such need. >> >> Does this still mean the mobility support must be implement even if it >> is not used? >> >>> >>> RELEVANT problem: PS5: Wasting resources to support mobile nodes not >>> needing mobility support IP mobility support is not always required. >>> For example, some applications do not need a stable IP address during >>> handover, i.e. IP session continuity. Sometimes, the entire >>> application session runs while the terminal does not change the point >>> of attachment. In these situations that do not require IP mobility >>> support, network resources are wasted when mobility context is set up. >>> Network resources are also wasted when the via routes are set up for >>> many MNs that do not require IP mobility support. >>> >>> OTHER related problem O-PS1: Mobility signaling overhead with >>> peer-to-peer communication While mobility management enables a mobile >>> host to be reachable, the hosts may then communicate directly so that >>> the mobility support is no longer needed. Taking the need of mobility >>> support as the default behavior will waste network resources. O-PS2: >>> Lack of user-centricity Centralized deployment compared with >>> distributed mobility management may be less capable to support >>> user-centricity. Example in the lack of user-centricity is to provide >>> mobility support to all mobile nodes by default regardless of whether >>> the user needs it or not. >> >> I have issues to parse O-PS2.. the motivation makes sense though but >> the title "lack of user-centricity" is somewhat confusing.. what >> does forced/always-on mobility support has to do with user centricity? >> >> - Jouni >> >> >>> >>> (The above has been drafted with contributions, inputs and >>> discussions from various people. Additional contributions and >>> comments are most welcome.) >>> >>> H Anthony Chan >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
