Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-02.txt

From: [email-masked]
Date: Thu, 06 Sep 2012 15:30:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Distributed Mobility Management Working Group of the IETF.

	Title           : Requirements for Distributed Mobility Management
	Author(s)       : H Anthony Chan
	Filename        : draft-ietf-dmm-requirements-02.txt
	Pages           : 17
	Date            : 2012-09-06

Abstract:
   This document defines the requirements for Distributed Mobility
   Management (DMM) in IPv6 deployments.  The traditionally hierarchical
   structure of cellular networks has led to deployment models which are
   in practice centralized.  Mobility management with logically
   centralized mobility anchoring in current mobile networks is prone to
   suboptimal routing and raises scalability issues.  Such centralized
   functions can lead to single points of failure and inevitably
   introduce longer delays and higher signaling loads for network
   operations related to mobility management.  The objective is to
   enhance mobility management in order to meet the primary goals in
   network evolution, i.e., improve scalability, avoid single points of
   failure, enable transparent mobility support to upper layers only
   when needed, and so on.  Distributed mobility management must be
   secure and compatible with existing network deployments and end
   hosts.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dmm-requirements-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-requirements-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: h chan <[email-masked]>
Date: Thu, 6 Sep 2012 23:03:41 +0000

Please check the updated REQ1 in draft-ietf-dmm-requirements-02:

   REQ1:  Distributed deployment

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed deployment for mobility management
          of IP sessions so that traffic does not need to traverse
          centrally deployed mobility anchors and thus can be routed in
          an optimal manner.

          Motivation: This requirement is motivated by current trends in
          network evolution: (a) it is cost- and resource-effective to
          cache and distribute content by combining distributed mobility
          anchors with caching systems (e.g., CDN); (b) the
          significantly larger number of mobile nodes and flows call for
          improved scalability; (c) single points of failure are avoided
          in a distributed system; (d) threats against centrally
          deployed anchors, e.g., home agent and local mobility anchor,
          are mitigated in a distributed system.

   This requirement addresses problems PS1, PS2, PS3, and PS4 in the
   following.

   PS1:  Non-optimal routes

         Routing via a centralized anchor often results in a longer
         route.  The problem is especially manifested when accessing a
         local server or servers of a Content Delivery Network (CDN).

   PS2:  Divergence from other evolutionary trends in network
         architecture

         Centralized mobility management can become non-optimal with a
         flat network architecture.

   PS3:  Low scalability of centralized route and mobility context
         maintenance

         Setting up routes through a central anchor and maintaining
         mobility context for each MN therein requires more resources is
         more difficult to scale in a centralized design, thus reducing
         scalability.  Distributing the route maintenance function and
         the mobility context maintenance function among different
         network entities can increase scalability.

   PS4:  Single point of failure and attack

         Centralized anchoring may be more vulnerable to single points
         of failures and attacks than a distributed system.  The impact
         of a successful attack on a system with centralized mobility
         management can be far greater as well.

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Thu, 6 Sep 2012 23:08:04 +0000

Please check this updated REQ1 in draft-ietf-dmm-requirements-02:

   REQ2:  Transparency to Upper Layers when needed

          DMM solutions MUST provide transparent mobility support above
          the IP layer when needed.  Such transparency is needed, for
          example, when, upon change of point of attachment to the
          Internet, an application flow cannot cope with a change in the
          IP address.  Otherwise, support for maintaining a stable home
          IP address or prefix during handovers may be declined.

          Motivation: The motivation of this requirement is to enable
          more efficient use of network resources and more efficient
          routing by not maintaining context at the mobility anchor when
          there is no such need.

   This requirement addresses the problems PS5 as well as the other
   related problem O-PS1.

   PS5:  Wasting resources to provide mobility support to nodes that do
         not need such support

         IP mobility support is not always required, and not every
         parameter of mobility context is always used.  For example,
         some applications do not need a stable IP address during a
         handover to maintain IP session continuity.  Sometimes, the
         entire application session runs while the terminal does not
         change the point of attachment.

   O-PS1:  Mobility signaling overhead with peer-to-peer communication

           Wasting resources when mobility signaling (e.g., maintenance
           of the tunnel, keep alive, etc.) is not turned off for peer-
           to-peer communication.  Peer-to-peer communications have
           particular traffic patterns that often do not benefit from
           mobility support from the network.  Thus, the associated
           mobility support signaling (e.g., maintenance of the tunnel,
           keep alives, etc.) wastes network resources for no
           application gain.  In such a case, it is better to enable
           mobility support selectively.

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Thu, 6 Sep 2012 23:09:58 +0000

Please check this updated REQ3 in draft-ietf-dmm-requirements-02:

   REQ3:  IPv6 deployment

          DMM solutions SHOULD target IPv6 as the primary deployment
          environment and SHOULD NOT be tailored specifically to support
          IPv4, in particular in situations where private IPv4 addresses
          and/or NATs are used.

          Motivation: This requirement is to be inline with the general
          orientation of IETF work.  DMM deployment is foreseen in mid-
          to long-term horizon, when IPv6 is expected to be far more
          common than today.  It is also unnecessarily complex to solve
          this problem for IPv4, as we will not be able to use some of
          the IPv6-specific features/tools.

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Thu, 6 Sep 2012 23:11:08 +0000

Please check this updated REQ4 in draft-ietf-dmm-requirements-02:

   REQ4:  Existing mobility protocols

          A DMM solution SHOULD first consider reusing and extending
          IETF-standardized protocols before specifying new protocols.

          Motivation: Using IETF protocols is easier to deploy and to
          update.

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Thu, 6 Sep 2012 23:11:48 +0000

Please check this updated REQ5 in draft-ietf-dmm-requirements-02:

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Thu, 6 Sep 2012 23:13:14 +0000

REQ5:  Compatibility

          The DMM solution MUST be able to co-exist with existing
          network deployments and end hosts.  For example, depending on
          the environment in which DMM is deployed, DMM solutions may
          need to be compatible with other deployed mobility protocols
          or may need to interoperate with a network or mobile hosts/
          routers that do not support DMM protocols.  Furthermore, a DMM
          solution SHOULD work across different networks, possibly
          operated as separate administrative domains, when allowed by
          the trust relationship between them.

          Motivation: The motivations of this requirement are (1) to
          preserve backwards compatibility so that existing networks and
          hosts are not affected and continue to function as usual, and
          (2) enable inter-domain operation if desired.

   This requirement addresses the following related problem O-PS2.

   O-PS2:  Complicated deployment with too many MIP variants and
           extensions

           Deployment is complicated with many variants and extensions
           of MIP.  When introducing new functions which may add to the
           complexity, existing solutions are more vulnerable to break.

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Thu, 6 Sep 2012 23:14:41 +0000

Please check this updated REQ6 in draft-ietf-dmm-requirements-02:

   REQ6:  Security considerations

          DMM protocol solutions MUST consider security aspects,
          including confidentiality and integrity.  Examples of aspects
          to be considered are authentication and authorization
          mechanisms that allow a legitimate mobile host/router to use
          the mobility support provided by the DMM solution; signaling
          message protection in terms of authentication, encryption,
          etc.; data integrity and confidentiality; opt-in or opt-out
          data confidentiality to signaling messages depending on
          network environments or user requirements.

          Motivation: Mutual authentication and authorization between a
          mobile host/router and an access router providing the DMM
          service to the mobile host/router are required to prevent
          potential attacks in the access network of the DMM service.
          Various attacks such as impersonation, denial of service, man-
          in-the-middle attacks, and so on, can be mounted against a DMM
          service and need to be protected against.

          Signaling messages can be subject to various attacks since
          they carry critical context information about a mobile node/
          router.  For instance, a malicious node can forge a number of
          signaling messages thus redirecting traffic from its
          legitimate path.  Consequently, the specific node is under a
          denial of service attack, whereas other nodes do not receive
          their traffic.  As signaling messages may travel over the
          Internet, end-to-end security could be required.

H Anthony Chan

---

From: h chan <[email-masked]>
Date: Thu, 6 Sep 2012 23:15:50 +0000

This draft has been updated to solve the issues raised
and has included numerous suggested texts from Kostas. 

The updated requirements are also being sent out one by one in separate emails. 

Please check them, and comments are welcome. 

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 06, 2012 5:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-02.txt

Abstract:

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

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Fri, 21 Sep 2012 13:12:47 +0000

Dear All,

  |The updated requirements are also being sent out one by one in
  |separate emails.
  |
  |Please check them, and comments are welcome.

I guess nobody has publicly voiced major concerns during the last two weeks. Did I miss something?

Best Regards,

Kostas