Dear Anthony, I share the same concern as Luowen does for PS5, but also several info for associated with this requirements. Please my comments inline below.
Thanks. [email protected] Sent by: [email protected] 05/08/2012 06:23 PM To h chan <[email protected]> cc [email protected], "[email protected]" <[email protected]> Subject [DMM] 答复: draft requirement REQ-2: Transparency to Upper Layers Hi Antony: The last part of PS-5, does the sentence " Network resources are also wasted when the via routes are set up for many MNs that do not require IP mobility support." implicitly indicate the scenario which similar with MIP/PMIP? When I read this sentence, the MIP/PMIP tunnel appears in my mind, and yes, if MNs do not require IP mobiliy support, the MIP/PMIP tunnel will waste network resources. Cheers. h chan <[email protected]> 发件人: [email protected] 2012/05/08 01:58 收件人 "[email protected]" <[email protected]> 抄送 主题 [DMM] draft requirement REQ-2: Transparency to Upper Layers 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. >>>>>> Comments (1) What scenario is that "entire mobile networks change their point of attachment to the internet"? 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. 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. >>>>>> Comments (1) I have the same concern as LuoWen does. We should be more clear what are we referring to for the term "mobility context" here? It is because, there would always be context set up for the mobile node attaching to the network regardless if the IP mobility is required or not, such as per-MN localization information and security context. I believe that the "specific" mobility context that you're referring here is the context info that supports the MN for changing their point of attachment to the network such as the mobility tunneling info. >>>>> Proposed new text 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 including additional info to the mobility context to support the changing the point of attachment. 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. (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 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
