Re: I-D Action: draft-ietf-dmm-requirements-07.txt

Sri,

Thanks for the comments. We are replying under different sections in separate emails.
-----------------------------------------------
Regarding your comments on Section 1, this section has been revised and reorganized in version 08 to avoid misunderstanding. Also our responses in-line. Please check.

1.  Introduction

   In the past decade a fair number of mobility protocols have been
   standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
   Although the protocols differ in terms of functions and associated
   message formats, they all employ a mobility anchor to allow a mobile
   node to remain reachable after it has moved to a different network.
   The anchor point, among other tasks, ensures connectivity by
   forwarding packets destined to, or sent from, the mobile node.  It is
   a centrally deployed mobility anchor in the sense that the deployed
   architectures today have a small number of these anchors and the
   traffic of millions of mobile nodes in an operator network are
   typically managed by the same anchor.

   Distributed mobility management (DMM) is an alternative to the above
   centralized deployment.  The background behind the interests to study
   DMM are primarily in the following.

   (1)  Mobile users are, more than ever, consuming Internet content;
        such traffic imposes new requirements on mobile core networks
        for data traffic delivery.  The presence of content providers
        closer to Internet Service Providers (ISP) network requires
        taking into account local Content Delivery Networks (CDNs) while
        providing mobility services.  Moreover, when the traffic demand
        exceeds available capacity, service providers need to implement
        new strategies such as selective traffic offload (e.g.
        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
        alternative access networks (e.g.  WLAN) [Paper-
        Mobile.Data.Offloading].  A gateway selection mechanism also
        takes the user proximity into account within EPC [TS.29303].
        These mechanisms were not pursued in the past owing to charging
        and billing reasons.  Assigning a gateway anchor node from a
        visited network in roaming scenario has until recently been done
        and are limited to voice services only.  Charging and billing
        require solutions beyond the mobility protocol.

        Both traffic offloading and CDN mechanisms could benefit from
        the development of mobile architectures with fewer levels of
        routing hierarchy introduced into the data path by the mobility
        management system.  This trend towards so-called "flat networks"
        works best for direct communications among peers in the same
        geographical area.  Distributed mobility management in a truly
        flat mobile architecture would anchor the traffic closer to the
        point of attachment of the user.

   (2)  Today's mobile networks present service providers with new
        challenges.  Mobility patterns indicate that mobile nodes often
        remain attached to the same point of attachment for considerable
        periods of time [Paper-Locating.User].  Specific IP mobility
        management support is not required for applications that launch
        and complete their sessions while the mobile node is connected
        to the same point of attachment.  However, currently, IP
        mobility support is designed for always-on operation,
        maintaining all parameters of the context for each mobile
        subscriber for as long as they are connected to the network.
        This can result in a waste of resources and unnecessary costs
        for the service provider.  Infrequent node mobility coupled with
        application intelligence suggest that mobility support could be
        provided selectively, thus reducing the amount of context
        maintained in the network.

   In addition, considerations in the study of DMM are in the following.

   (1)  To optimize handovers from the perspective of mobile nodes, the
        base protocols have been extended to efficiently handle packet
        forwarding between the previous and new points of attachment.
        These extensions are necessary when applications have stringent
        requirements in terms of delay.  Notions of localization and
        distribution of local agents have been introduced to reduce
        signaling overhead at the centralized routing anchor point
        [Paper-Distributed.Centralized.Mobility].  Unfortunately, such
        protocols have not been deployed today.

   (2)  Most existing mobility protocols have not been designed for
        multiple-interface hosts which are capable to use multiple
        interfaces simultaneously.  Retrofitting the required
        functionality can result in an unnecessary increase in the
        protocol complexity.

   (3)  IP multicast support, including optimizations, have been
        introduced as an effective transport method for multimedia data
        delivery, but by "patching-up" procedure after completing the
        design of reference mobility protocol, leading to network
        inefficiency and non-optimal routing.

   The distributed mobility management (DMM) charter addresses two
   complementary aspects of mobility management procedures: the
   distribution of mobility anchors in the data-plane towards a more
   flat network and the selective activation/deactivation of mobility
   protocol support as an enabler to distributed mobility management.
   The former aims at positioning mobility anchors (e.g., HA, LMA)
   closer to the user; ideally, mobility agents could be collocated with
   the first-hop router.  The latter, facilitated by the distribution of
   mobility anchors, identifies when mobility support must be activated
   and when sessions do not require mobility management support -- thus
   reducing the amount of state information that must be maintained in
   various mobility agents of the mobile network.  It can then avoid the
   unnecessary establishment of mechanisms to forward traffic from an
   old to a new mobility anchor.

   This document compares distributed mobility management with
   centralized mobility management in Section 3.  The problems that can
   be addressed with DMM are summarized in Section 4.  The mandatory
   requirements as well as the optional requirements are given in
   Section 5.  Finally, security considerations are discussed in Section
   6.

   The problem statement and the use cases [I-D.yokota-dmm-scenario] can
   be found in [Paper-Distributed.Mobility.Review].

The following have contributed to the revisions in draft 08: Pierrick, Dapeng, and Jouni


From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Sunday, August 25, 2013 10:04 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Please see inline for some comments.

Regards
Sri

....



1.  Introduction



   In the past decade a fair number of mobility protocols have been

   standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].

   Although the protocols differ in terms of functions and associated

   message formats, we can identify a few key common features:



   o  a centralized mobility anchor providing global reachability and an

      always-on experience to the user;



   o  extensions to the base protocols to optimize handover performance

      while users roam across wireless cells; and



   o  extensions to enable the use of heterogeneous wireless interfaces

      for multi-mode terminals (e.g. smartphones).



[Sri] Currently defined mobility protocols support handovers and multiple access technologies  ? Not sure, how these two "common features" make the case for DMM  If the point is about centralized anchor's, you don't need the other two points.



Accept and revised in version 08



   The presence of the centralized mobility anchor allows a mobile node

   to remain reachable after it has moved to a different network.  The

   anchor point, among other tasks, ensures connectivity by forwarding

   packets destined to, or sent from, the mobile node.  In practice,

   most of the deployed architectures today have a small number of

   centralized anchors managing the traffic of millions of mobile nodes.

   Compared with a distributed approach, a centralized approach is

   likely to have several issues or limitations affecting performance

   and scalability, which require costly network engineering to resolve.



[Sri] All 3G/4G systems are based on this model and they are running fine. Again, we don't need to argue against centralized model to justify distributed model. Please simply state distributed model can be useful in certain deployments and hence the motivation for this work.


Accept and revised in version 08


   To optimize handovers from the perspective of mobile nodes, the base

   protocols have been extended to efficiently handle packet forwarding

   between the previous and new points of attachment.  These extensions

   are necessary when applications have stringent requirements in terms

   of delay.  Notions of localization and distribution of local agents

   have been introduced to reduce signaling overhead at the centralized

   routing anchor point [Paper-Distributed.Centralized.Mobility].

   Unfortunately, today we witness difficulties in getting such

   protocols deployed, resulting in sub-optimal choices for the network

   Operators.

[Sri] I assume this is about hierarchical models / Chaining ? What are these "difficulties in getting such protocols deployed" ?

Accept and revised in version 08



   Moreover, the availability of multiple-interface host and the

   possibility of using several network interfaces simultaneously have

   motivated the development of even more protocol extensions to add

   more capabilities to the mobility management protocol.  In the end,

   deployment is further complicated with the multitude of extensions.

[Sri] Not sure I follow. Mobile IP protocols are in general access agnostic. Not sure, what are the extensions that we have added on access-basis.



Re-organize Section 1 in version 08 to clarify.



   As an effective transport method for multimedia data delivery, IP

   multicast support, including optimizations, have been introduced but

   by "patching-up" procedure after completing the design of reference

   mobility protocol, leading to network inefficiency and non-optimal

   routing.



[Sri] Multicast related extensions have nothing to do with multi-access support/host's capability to support multiple interfaces. Can you clarify ? This text is not clear.

Re-organize Section 1 in version 08 to clarify.





   Mobile users are, more than ever, consuming Internet content; such

   traffic imposes new requirements on mobile core networks for data

   traffic delivery.  The presence of content providers closer to

   Internet Service Providers (ISP) network requires taking into account

   local Content Delivery Networks (CDNs) while providing mobility

   services.  Moreover, when the traffic demand exceeds available

   capacity, service providers need to implement new strategies such as

   selective traffic offload (e.g. 3GPP work items LIPA/SIPTO

   [TS.23.401]) through alternative access networks (e.g.  WLAN) [Paper-

   Mobile.Data.Offloading].

[Sri] Please add reference to IETF SIPTO doc, RFC6909, before 23.401 :)



Accept and revised in version 08



A gateway selection mechanism also takes

   the user proximity into account within EPC [TS.29303].  These

   mechanisms were not pursued in the past owing to charging and billing

   reasons.   Assigning a gateway anchor node from a visited network in

   roaming scenario has until recently been done and are limited to

   voice services only.  Charging and billing require solutions beyond

   the mobility protocol.



   Both traffic offloading and CDN mechanisms could benefit from the

   development of mobile architectures with fewer levels of routing

   hierarchy introduced into the data path by the mobility management

   system.  This trend towards so-called "flat networks" works best for

   direct communications among peers in the same geographical area.

   Distributed mobility management in a truly flat mobile architecture

   would anchor the traffic closer to the point of attachment of the

   user.



   Today's mobile networks present service providers with new

   challenges.  Mobility patterns indicate that mobile nodes often

   remain attached to the same point of attachment for considerable

   periods of time [Paper-Locating.User].  Specific IP mobility

   management support is not required for applications that launch and

   complete their sessions while the mobile node is connected to the

   same point of attachment.

 However, currently, IP mobility support is

   designed for always-on operation, maintaining all parameters of the

   context for each mobile subscriber for as long as they are connected

   to the network.  This can result in a waste of resources and unnecessary costs for the service provider.

[Sri]  Is the intent of this is text is about routing based approaches ?

If a mobile is attached to the network, it does have some state at the anchor. Also, if we consider the home link in mobility models, there is no state for the mobile node when it is at home. In case of DMM, or with the current models, if the gateway selection is based on the MN's location and when there is no node mobility, there should not be any state at the anchor. CDMA



We are probably talking about the same thing. Revise in 08 to clarify.



 Infrequent node mobility

   coupled with application intelligence suggest that mobility support

   could be provided selectively, thus reducing the amount of context

   maintained in the network.



   The distributed mobility management (DMM) charter addresses two

   complementary aspects of mobility management procedures: the

   distribution of mobility anchors towards a more flat network and the

   dynamic activation/deactivation of mobility protocol support as an

   enabler to distributed mobility management.

[Sri] Not sure, I follow this point on Dynamic activation/de-activation. Can you clarify.



Re-organize Section 1 in version 08 to clarify.



The former aims at

   positioning mobility anchors (e.g., HA, LMA) closer to the user;

   ideally, mobility agents could be collocated with the first-hop







Chan (Ed.), et al.      Expires February 3, 2014                [Page 5]



Internet-Draft                  DMM-Reqs                     August 2013





   router.  The latter, facilitated by the distribution of mobility

   anchors, aims at identifying when mobility support must be activated

   and identifying sessions that do not require mobility management

   support -- thus reducing the amount of state information that must be

   maintained in various mobility agents of the mobile network.  The key

   idea is that dynamic mobility management relaxes some of the

   constraints of previously-standardized mobility management solutions

   and, by doing so, it can avoid the unnecessary establishment of

   mechanisms to forward traffic from an old to a new mobility anchor.



[Sri] The DMM model should not exclude the case of centralized anchor and distributed data plane. This is sub-case of DMM.



Revise Section 1 in version 08 to clarify distribution for "data-plane".



   This document compares distributed mobility management with

   centralized mobility management in Section 3.  The problems that can

   be addressed with DMM are summarized in Section 4.  The mandatory

   requirements as well as the optional requirements are given in

   Section 5.  Finally, security considerations are discussed in Section

   6.



   The problem statement and the use cases [I-D.yokota-dmm-scenario] can

   be found in [Paper-Distributed.Mobility.Review].

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