Internet DRAFT - draft-giust-dmm-cpdp-deployment

draft-giust-dmm-cpdp-deployment







DMM Working Group                                               F. Giust
Internet-Draft                                                M. Liebsch
Intended status: Informational                                       NEC
Expires: January 7, 2016                                    July 6, 2015


          Deployment of Control-/Data-Plane separation in DMM
                   draft-giust-dmm-cpdp-deployment-00

Abstract

   The DMM working group is currently looking at solutions for mobility
   management based on control and data plane separation.  In this
   context, the network entities in charge for the mobility control
   function are separated from the data plane nodes, responsible mainly
   for, but not limited to, data packet forwarding.  This vision allows
   for the design of different interaction methods between the mobility
   control function and the data plane nodes.  One of such mechanisms
   being currently discussed devises an SDN-based abstraction layer
   between control and data planes, embodied by an SDN Network
   Controller.  This latter interfaces to the mobility control function
   through a north-bound interface (NBI), and programs the underneath
   infrastructure through a south-bound interface (SBI), e.g., OpenFlow.

   This draft describes multiple deployment scenarios for NBI and SBI
   interworking, given that multiple network controllers could be
   deployed in order to meet performance requirements e.g., related to
   latency.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any




Giust & Liebsch          Expires January 7, 2016                [Page 1]

Internet-Draft             Deployment of CPDP                  July 2015


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 7, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Control plane and data plane separation: deployment scenarios   6
     3.1.  Scenario 1  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Scenario 2  . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Scenario 3  . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     4.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The Distributed Mobility Management (DMM) working group is currently
   investigating solutions, which are based on the separation of
   mobility management functions' Control- and Data-Plane.  The network
   functions in charge of the mobility control are separated from the
   data plane nodes, responsible mainly for, but not limited to, data
   packet forwarding.  In this scenario, it is possible to design
   different mechanisms for the interaction between the mobility control
   function and the data plane nodes.

   One of these mechanisms devises a Software Defined Networking (SDN)
   abstraction layer between control and data planes, embodied by an SDN
   Network Controller (NC).  The NC enforces instructions from different
   mobility control functions, which operate on top of a Network



Giust & Liebsch          Expires January 7, 2016                [Page 2]

Internet-Draft             Deployment of CPDP                  July 2015


   Controller and hold the mobility states, to Data-Plane nodes (DPNs),
   such as switches or routers, within a defined network scope.  DPNs in
   different networks may be controlled by physically separated NCs.
   The NC configures Data-Plane nodes with forwarding and policy
   enforcement related rules, either with the accuracy of a single data
   flow or as aggregated rule, such as for an IP address prefix.

   An example of a Control-Plane function is the Control-Plane of a
   Local Mobility Anchor (LMA-C) as per the Proxy Mobile IPv6 (PMIPv6)
   architecture [RFC5213] or a Packet Data Network (PDN) Gateway's
   Control-Plane functions as per the 3rd Generation Partnership
   Project's architecture for cellular mobile communications.  These
   functions perform protocol operation with remote Control-Plane
   functions for mobility management, e.g. the Control-Plane of a Mobile
   Access Gateway (MAG) as per the PMIPv6 protocol.

   Control-Plane functions associated with mobility management need to
   interact with the NC to enforce forwarding and policy rules in the
   Data-Plane.  By taking again the PMIPv6 architecture as an example,
   the Data-Plane nodes have the role of the Data-Plane functions within
   an LMA or MAG.

   This document discusses various deployment options for mobility
   management in a Control-/Data-Plane separated setup utilizing SDN and
   how results of the chartered work about Forwarding Policy Control
   (FPC) [I-D.ietf-dmm-fpc-cpdp] can be used in such setup.

   The diagrams and descriptions as per this document are meant for
   discussion and consideration in the DMM working group's chartered
   item about DMM deployment options.

   The WG document [I-D.ietf-dmm-fpc-cpdp] specifies an abstraction and
   information model for DMM control and data plane separation.  The
   specified functional architecture comprises a Client function, which
   is associated with the mobility management Control-Plane, and an
   Agent function, which is associated with Data-Plane configuration.
   Client and Agent interact with each other as per the specification in
   [I-D.ietf-dmm-fpc-cpdp] to enforce forwarding and policy rules from
   the mobility management Control-Plane in the Data-Plane.  Such rules
   comprise, for example, forwarding of defined traffic through a GRE
   tunnel to a remote Data-Plane node while the traffic should
   experience prioritization as per a defined Quality-of-Service class.
   Such interaction is illustrated in Figure 1








Giust & Liebsch          Expires January 7, 2016                [Page 3]

Internet-Draft             Deployment of CPDP                  July 2015


                                 +-------------------------+
                                 | Mobility Control-Plane  |
                                 |                         |
                                 |+--------[API]----------+|
                                 ||  FPC Client Function  ||
                                 |+----------^------------+|
                                 +-----------|-------------+
                                             |
                                             | DMM FPC protocol
                                             |
                                 +-----------|-------------+
                                 |+----------v------------+|
                                 ||  FPC Agent Function   ||
                                 |+-----------------------+|
                                 |                         |
                                 |  DPN Configuration API  |
                                 +-------------------------+

    Figure 1: Illustration of the functional reference architecture for
                 DMM Forwarding Policy Configuration (FPC)

   In the present document we describe a base reference model from
   [I-D.ietf-dmm-fpc-cpdp], to then propose some sub-scenarios of
   interest for practical deployment.  In the base reference model, as
   depicted in Figure 2, the Control-/Data-Plane interaction is
   performed through an NC that exhibits a southbound interface (SBI),
   e.g. the OpenFlow protocol, to configure DPNs, and exposes a
   northbound interface (NBI) towards mobility management Control-Plane
   functions utilizing the Client and Agent functions as well as the
   abstraction and configuration model as per [I-D.ietf-dmm-fpc-cpdp].
   This enables the mobility management Control-Plane using the NC's NBI
   to enforce rules and policies in the Data-Plane, which are relevant
   for the Control-Plane's operation, without the need to be aware of a
   Data-Plane node's configuration details and whether the Data-Plane
   node is a switch or a router.

   An SDN-based Control- and Data-plane separation for DMM has been
   proposed also in [I-D.yang-dmm-sdn-dmm].  In such draft the mobility
   function is co-located with the SDN Network Controller.  By doing so,
   the mobility protocol is highly coupled with the NC and the SBI
   interface.  The present draft extends [I-D.yang-dmm-sdn-dmm] by
   introducing the use of an NBI as an additional abstraction layer.  In
   this way the architecture gains in flexibility as the mobility
   function is independent from the specific SBI and NC used.  The NBI
   hides Data-Plane configuration details from Control-Plane functions
   and is represented by a protocol implementation as per
   [I-D.ietf-dmm-fpc-cpdp].




Giust & Liebsch          Expires January 7, 2016                [Page 4]

Internet-Draft             Deployment of CPDP                  July 2015


                           ___.......___
                        ,-'  mobility   `-.
                       |     control       |
                       `._   function    _,
                          `--[Client]---'
                                |
                                |
                                |        NBI
                          +--[Agent]---+
                          |  network   |
                          | controller |
                          `,----+---+--'
                      ____/     |    \   SBI
                     |    |     |     \____
                     +----+     |     |    | data
                             +----+   +----+ plane
                             |    |          nodes
                             +----+

                  Figure 2: Reference communication model

   The flexibility introduced by splitting the Control-/Data-Plane
   reference point into two different interfaces, namely the NBI and the
   SBI, may lead to practical limitations for a single network
   controller to handle the whole set of data plane nodes.  As a
   consequence, when multiple NCs are to be deployed, different
   scenarios arise with different characteristics.  This documents
   explores three possible deployment scenarios.

2.  Terminology

   The following terms are defined and used in this document:

   FPCP (Forwarding Policy Configuration Protocol)

   MCF (Mobility Control Function)

   NC (Network Controller)

   NBI (North-bound Interface)

   SBI (South-bound Interface)

   DPN (Data Plane Node)

   MN (Mobile Node)





Giust & Liebsch          Expires January 7, 2016                [Page 5]

Internet-Draft             Deployment of CPDP                  July 2015


3.  Control plane and data plane separation: deployment scenarios

   A single network controller may lead to practical limitations when it
   comes to handle the operations in large network, like scalability
   issues and protocol promptness.

   The mobility management protocol should execute quickly in order to
   guarantee optimal service to users.  For this reason the network
   controller should not be too distant from the DPNs.  Therefore, a
   network administrator might deploy multiple NCs, each responsible for
   a network sub-domain or site.

   By deploying multiple NCs, the Control-/Data-Plane reference model as
   depicted in Figure 2 suffers some variations as described in the
   following subsections.

3.1.  Scenario 1

   In this scenario the NCs from different sites are directly
   interacting with the mobility control function by means of the NBI
   interface.  The mobility control function possesses a holistic view
   of the network domain and propagates the instruction to the NCs
   accordingly.  The mobility control function, which is associated with
   the Client function as per [I-D.ietf-dmm-fpc-cpdp], connects to two
   Agent functions, each associated with one NC.  This scenario is
   illustrated in Figure 3.

                   _______________________________
                ,-'           mobility            `-.
               |           control function         |
               `.        _____________________     _,
                 `------[______ Client _______]---'
                         |                   |
                         |           NBI     |
               +----[Agent]-+             +-[Agent]----+
               |     NC     |             |     NC     |
               |   site 1   |             |   site 2   |
               `,----+---+--'             `,----+---+--'
           ____/     |    \           ____/     |    \
          |DPN |     | SBI \____     |DPN |     | SBI \____
          +----+     |     |    |    +----+     |     |    |
                  +----+   +----+            +----+   +----+
                  |    |                     |    |
                  +----+                     +----+

                           Figure 3: Scenario 1





Giust & Liebsch          Expires January 7, 2016                [Page 6]

Internet-Draft             Deployment of CPDP                  July 2015


3.2.  Scenario 2

   In this scenario, the mobility control Client function interacts with
   a single Agent co-located with one NC, which in turns propagates the
   configuration through an east-west interface (EWI) to other NCs.
   This scenario is illustrated in Figure 4.

                    __________
                 ,-' mobility `-.
                |    control     |
                `._  function   _,
                   `-[Client]--'
                      |
                      | NBI
               +---[Agent]--+             +-----+------+
               |     NC     |_____________|     NC     |
               |   site 1   |    EWI      |   site 2   |
               `,----+---+--'             `,----+---+--'
           ____/     |    \           ____/     |    \
          |DPN |     | SBI \____     |DPN |     | SBI \____
          +----+     |     |    |    +----+     |     |    |
                  +----+   +----+            +----+   +----+
                  |    |                     |    |
                  +----+                     +----+

                           Figure 4: Scenario 2

3.3.  Scenario 3

   In this scenario, each NC interacts through an Agent with a dedicated
   instance of the mobility function Client.  It is then up to the
   different mobility control entities to coordinate the operations
   among different sites.  This scenario is illustrated in Figure 5.


















Giust & Liebsch          Expires January 7, 2016                [Page 7]

Internet-Draft             Deployment of CPDP                  July 2015


                    _________                  _________
                 ,-' mobility`-.             / mobility \
                |    support    |___________|  control   |
                `._  entity    _,           \_ entity   /
                   `-[Client]-'               `[Client]'
                      |                          |
                      | NBI                  NBI |
               +---[Agent]--+             +---[Agent]--+
               |     NC     |             |     NC     |
               |   site 1   |             |   site 2   |
               `,----+---+--'             `,----+---+--'
           ____/     |    \           ____/     |    \
          |DPN |     | SBI \____     |DPN |     | SBI \____
          +----+     |     |    |    +----+     |     |    |
                  +----+   +----+            +----+   +----+
                  |    |                     |    |
                  +----+                     +----+

                           Figure 5: Scenario 3

4.  References

4.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

4.2.  Informative References

   [I-D.ietf-dmm-fpc-cpdp]
              Liebsch, M., Matsushima, S., Gundavelli, S., and D. Moses,
              "Protocol for Forwarding Policy Configuration (FPC) in
              DMM", draft-ietf-dmm-fpc-cpdp-00 (work in progress), May
              2015.

   [I-D.yang-dmm-sdn-dmm]
              yangun@dcn.ssu.ac.kr, y. and Y. Kim, "Routing Optimization
              with SDN", draft-yang-dmm-sdn-dmm-03 (work in progress),
              March 2015.

Authors' Addresses







Giust & Liebsch          Expires January 7, 2016                [Page 8]

Internet-Draft             Deployment of CPDP                  July 2015


   Fabio Giust
   NEC Laboratories Europe
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  D-69115
   Germany

   Phone: +49 6221 4342216
   Email: fabio.giust@neclab.eu


   Marco Liebsch
   NEC Laboratories Europe
   NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  D-69115
   Germany

   Phone: +49 6221 4342146
   Email: liebsch@neclab.eu































Giust & Liebsch          Expires January 7, 2016                [Page 9]