Internet Engineering Task Force                            B. Pularikkal
Internet-Draft                                             Cisco Systems
Intended status: Informational                                     Q. Fu
Expires: August 28, 2017                                         H. Deng
                                                            China Mobile
                                                             G. Sundaram
                                                           S. Gundavelli
                                                           Cisco Systems
                                                       February 24, 2017


                 Virtual CPE Deployment Considerations
                    draft-pularikkal-virtual-cpe-02

Abstract

   Broadband Service Provider Industry has been gearing towards the
   adoption of Virtual CPE (vCPE) solutions.  The concept of vCPE is
   build around the idea that the physical CPE device at the customer
   premises can be simplified by moving some of the key feature
   functionalities from the physical CPE device to the Service Provider
   Network.  This document starts discussing the drivers behind vCPE
   adoption followed by Solution level requirements.  Two key
   Architecture models for vCPE, which can address the service provider
   and subscriber requirements, are covered in this reference document.
   Document also touches up on some of the key deployment
   considerations, which can influence the adoption of the vCPE
   architecture models.

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
   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 August 28, 2017.






Pularikkal, et al.       Expires August 28, 2017                [Page 1]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


Copyright Notice

   Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Solution Requirements for vCPE  . . . . . . . . . . . . . . .   3
   4.  Architecture Models for vCPE  . . . . . . . . . . . . . . . .   4
     4.1.  Virtual CPE Definition  . . . . . . . . . . . . . . . . .   4
     4.2.  Virtual CPE Architecture Model-01 . . . . . . . . . . . .   5
     4.3.  Virtual CPE Architecture Model-02 . . . . . . . . . . . .   7
     4.4.  Virtual CPE Architecture Model-03 . . . . . . . . . . . .   9
       4.4.1.  Forwarding Policy Configuration (FPC)  Interface  . .  11
   5.  Deployment Considerations for vCPE  . . . . . . . . . . . . .  12
     5.1.  Multi-tenancy . . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Tunneling . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.3.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  14
     5.4.  Dynamic Service Chaining  . . . . . . . . . . . . . . . .  14
     5.5.  NAT Traversal . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Broadband Service Providers are constantly looking for opportunities
   to generate additional revenue streams from their existing broadband
   infrastructure.  In order to achieve this, new value added services
   need to be created for the end customers.  Customer retention is
   another key focus area for broadband subscribers, where they have
   been facing competition from Internet content providers on home
   multi-media services such as broadcast video, video on demand and
   voice.  There is a need to improve the overall end user experience on
   an ongoing basis to reduce the subscriber churn.  In order to achieve
   these business goals, Broadband Service Providers are starting to



Pularikkal, et al.       Expires August 28, 2017                [Page 2]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


   consider the deployment of Virtual CPE based Architectures.  There
   are several factors, which are driving the adoption of vCPE-based
   solutions.  Also the recent technological advancements in cloud
   computing and software defined networking are expected to further
   accelerate the adoption vCPE based architectures.

   The key aspect of the vCPE solutions is the simplification of the
   physical CPE device.  Such a simplification allows minimizing the
   feature dependency on CPE vendors for the roll out of new service
   offerings.  Also it reduces the complexities around service
   provisioning, Service Upgrade Troubleshooting etc.  There are
   multiple architecture options being considered by the industry for
   vCPE solutions.

   Objective of this draft is to serve as a reference material for
   Broadband Service Operators who are interested in migrating to vCPE
   based architectures.  The document starts with going over some of the
   key drivers for vCPE solution adoption.  Also it covers typical
   solution level requirements, which needs to be considered while
   selecting the right architecture models.  Document also touches up on
   some of the key deployment considerations, which can influence the
   adoption of the vCPE architecture models.

2.  Terminology

   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 [RFC2119].

3.  Solution Requirements for vCPE

   This section provides a high level summary of solution requirements,
   which needs to be addressed by Virtual Connected Home Architecture
   Models.  The solution requirements can be broadly classified under
   the following categories:

   (1) Subscriber side requirements: Subscriber in the context of this
   documentation refers to a homeowner with Broadband connection.  These
   requirements primarily map to the end user experience for a home
   subscriber in terms of connectivity, quality of experience and value
   added services.

   (2) Broadband Operator side requirements: Operator is the broadband
   service provider such as Cable MSOs, DSL providers etc.  These
   requirements primarily maps to the business aspects which needs to be
   covered in the solution in terms of CAPEX, OPEX reduction, service
   velocity, new revenue generation opportunities etc.




Pularikkal, et al.       Expires August 28, 2017                [Page 3]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


   High level requirements under the above two categories are summarised
   in the table below:

             +---------------------------------------------------------+
             | Subscriber Side Requirements |Operator Side requirements|
             +---------------------------------------------------------+
             |1) Private Home Network       | 1) Service Velocity      |
             |2) Zero Touch Provisioning    | 2) Simplified CPE        |
             |3) Local Bridging             | 3) Per UE Visibility     |
             |4) Local Routing              | 4) Community Wi-Fi       |
             |5) NAT, FW, IDS, Parental     | 5) IP Address Persistence|
             |Control                       | 6) UE Attachment/        |
             |6) Home Network Analytics     | Detachment detction      |
             |7) Self Service Portal        | 7)Usage based billing    |
             |8) Dynamic IP address         | 8)Quality of Service     |
             |Assignment                    | 9) NAT Traversal         |
             |9) Home Network Remote Access |                          |
             |                              |                          |
             +------------------------------+--------------------------+



                        Figure 1: VCPE Requirements

4.  Architecture Models for vCPE

   In this document three different architecture models are covered for
   the Virtual CPE based solutions.  This section starts with a
   definition of what represents a virtual CPE and then gets into the
   details of the Architecture options, which are available for the
   implementation of the same.

4.1.  Virtual CPE Definition

   A virtual CPE (vCPE) is a logical representation of classical CPE
   functions performed by a physical CPE device.  In other words,
   business logic and feature functionalities which are traditionally
   embedded in a CPE device is separated from the hardware device and
   runs in the Service Providers cloud.  Concepts of vCPE has basis on
   the Network Function Virtualization.  The business logic and feature
   functionalities of a CPE device are virtualized and runs as NFV in
   the cloud.  Each simplified physical CPE would have a corresponding
   virtual CPE function running in the cloud.  There are several ways to
   realize this vCPE instance in the cloud.  One approach is to have
   separate vCPE instance running as a Linux container or micro-VM
   corresponding to each physical CPE instance.  The vCPE may also be
   implemented as a representational state on aggregation platforms such
   as broadband network gateways (BNGs).  A third approach may rely on a



Pularikkal, et al.       Expires August 28, 2017                [Page 4]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


   combination of the BNG representational state and Service function
   chaining to represent the vCPE instance in the cloud.  These
   Architecture models are covered in the subsequent sub-sections.

4.2.  Virtual CPE Architecture Model-01

   This model is build around the concept of separate virtualized
   instance per physical CPE device.  In this model Virtual CPE instance
   handles the control plane as well as the data plane.  Each micro VM
   represents an NFV element of CPE with integrated control and data
   plane.  All feature functionalities get implemented on the NFV
   element itself.  This model does not leverage the dynamic service
   function chaining capabilities.

   A high level Architecture view of this model is provided in figure-
   below:



































Pularikkal, et al.       Expires August 28, 2017                [Page 5]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


                      +
                      |
                      |                       COMPUTE PLATFORM
                      |               +--------------------------------+
          +--------+  |               |         VXLAN 01     +-------+ |
          |PCPE 01 +-------+          |     +----------------+VCPE 01| |
          +--------+  |    | EoGRE /  |     |                +-------+ |
                      |    | PMIPV6   | +--------+                     |
                      |    +------------+VSWITCH |              +      |
                      |    +------------+        |              |      |
                      |    | EoGRE /  | +--------+              +      |
                      |    | PMIPV6   |   | |                          |
          +--------+  |    |          |   | |    VXLAN 0N    +-------+ |
          |PCPE 0N +-------+          |   | +----------------+VCPE 0N| |
          +--------+  |               |   |                  +-------+ |
                      |               +--------------------------------+
                      |                   |
                      |                   |
                      |                   |
                      |                  XXXX
                      +                XXX   XXX
                                      XX       XX
              Broadband Access       XX         XX
                  Network            X           X
                                     X Internet  X
                                     X           X
                                     XX         XX
                                      XXX     XXX
                                        XXXXXXX
                                          X





                    Figure 2: VCPE deployment model-01

   P-CPE device performs just the bridging function where the layer-2
   traffic between directly connected devices will be simply bridged by
   the P-CPE.  Any layer-3 traffic will be transparently forwarded to
   the cloud over the tunnel.

   In this model all the key cloud based components run on virtualized
   platforms.  These virtual components are deployed on standalone
   virtual platforms rather than on large scale virtual DC of Service
   providers.  Therefore, the tunnel will be terminated on the vSwitch
   rather than a tunnel termination GW located at the boarder of the DC.




Pularikkal, et al.       Expires August 28, 2017                [Page 6]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


   An implementation could leverage either a vendor specific vSwitch or
   an Open vSwitch.

   Tunnel end points are uniquely identified with the IP address of the
   P-CPE.  The vSwitch maps the de-encapsulated traffic from the tunnels
   to unique VXLANs and will forward to the corresponding Micro VM
   instances.  Micro VM instances will be responsible for supporting the
   key functions traditionally performed on physical CPE devices.  After
   the feature processing, V-CPE instance will send the traffic back to
   the v-Switch over VXLAN tunnels and vSwitch will forward it to
   external network.

4.3.  Virtual CPE Architecture Model-02

   In this model vCPE in the cloud is corresponding to each physical CPE
   is realized by a representational state on a tunnel aggregation
   platform such as BNG.  A provisioned physical CPE in run state is
   expected to have at least one tunnel established between the physical
   CPE and the BNG.  As long as the PCPE is in run state there will be a
   CPE session on the BNG which represents the CPE itself.  Some of the
   key CPE features will be running on the BNG while supplementary
   features and services can be deployed using dynamic service function
   chaining functions.

   A high level Architecture view of this mode2 is provided in figure-
   below:

























Pularikkal, et al.       Expires August 28, 2017                [Page 7]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


             +-----------------------+
     +-------+                       +---------------------+
     |       |Policy Infrastructure  |                     |
     |       +----------------+------+                     |
     |                        |                            |
     |                        |                            |
     |                        |                    SFC Framework
     |                 +---------------+        +----------v-----------+
     |                 | +----------+  |        |                      |
     |        +        | | VCPE 01  |  |        | +-----+      +-----+ |
     |        |        | | Session  |  |        | |SF011| +--+ |SF01N| |
 +---v----+   |        | |  State   |  | +---+  | +-----+      +-----+ |
 |PCPE 01 +------------+ +----------+  |        |                      |
 +--------+   |        |               |        |    +            +    |
              |        |      +        |        |    |            |    |
              |        |      |        |        |    |            |    |
              |        |      +        |        |    |            |    |
              |        |               |        |    |            |    |
 +--------+   |        |  +---------+  |        |    +            +    |
 |PCPE 0N +------------+  |VCPE 0N  |  |        |                      |
 +--------+   |        |  |Session  |  | +---+  | +-----+      +-----+ |
              |        |  |State    |  |        | |SF0N1|      |SF0NN| |
              |        |  +---------+  |        | +-----+      +-----+ |
              +        +---------------+        +-----------+----------+
                                                            |
     Broadband Access                                      XXXX
         Network                                         XXX   XXX
                                                       XXX        XX
                                                      XX            X
                                                      X             XX
                                                     X   Internet    X
                                                     X              XX
                                                     XX             X
                                                      XX          XX
                                                       XX       XXX
                                                        XX     XX
                                                         XXXXXXX


                    Figure 3: VCPE deployment model-02

   In this model as well, P-CPE device performs just the bridging
   function where the layer-2 traffic between directly connected devices
   will be simply bridged by the P-CPE.  Any layer-3 traffic will be
   transparently forwarded to the BNG over the tunnel.

   There is no need for pre-configuration of the tunnels on BNG.  When a
   P-CPE device become active and gets provisioned it will try to



Pularikkal, et al.       Expires August 28, 2017                [Page 8]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


   establish an EoGRE tunnel session with V-CPE.  Up on detecting a new
   P-CPE end point, the BNG would invoke an authorization process for
   the tunnel end point.  It is up to the implementation to decide
   whether an out of band authentication mechanism is required before
   establishing v-CPE state on the BNG.  If the access network is
   untrusted, the service provider may decide to overlay the EoGRE
   tunnel with IPSec encapsulation.

   BNG will need to uniquely tag the subscriber flows before forwarding
   to the SFC framework.  This can be accomplished by using some
   scalable tagging mechanisms such as VXLAN.

4.4.  Virtual CPE Architecture Model-03

   This is similar to model-02 but leverages split architecture for
   control plane and data plane for the BNG.  This model introduces the
   concept of a BNG controller, which essentially carries out the
   control plane functions.  Data plane component of the BNG can be a
   purpose built hardware optimized for scaleable tunnel termination,
   data encryption and data forwarding.  Control plane intelligence of
   each vCPE resides as a session state on the BNG controller and the
   data plane intelligence including tunnel termination of each vCPE
   resides on the BNG-DP system.  BNG-CP will leverage the FPC
   (Forwarding Policy Configuration) interface which is being defined in
   the DMM working group to instruct the BNG-DP system to establish
   V-CPE DP states with relevant configuration.Role of FPC interface in
   this solution is described in the sub-section below.  In this model,
   all basic and supplementary subscriber features will be implemented
   using a dynamic service function-chaining framework.

   A high level Architecture view of this mode3 is provided in figure-
   below:



















Pularikkal, et al.       Expires August 28, 2017                [Page 9]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


            +----------------------+
            |Policy Infrastructure +--+---------------+
            +----------------------+  |               |
                            BNG CP    |               |
                           +-------------+            |
                           | +---------+ |            |         XXX
                           | | VCPE 01 | |            |        XX  XX
                           | |CP State | |            |       XX    XX
                           | +---------+ |            |      XX      X
                           |             |            |      X       XX
                           |      +      |            |      X        X
                           |      +      |            |      XInternetX
                           |             |            |      X        X
                           | +---------+ |            |      X       X
                           | | VCPE 0N | |            |      XX      X
                           | |CP State | |            |       XX    XX
                           | +---------+ |            |        XX  X
                  +        +-------------+            |         X+X
                  |               |  FPC              |          |
                  |               |  Interface        |          |
                  |               ^                   |          |
                  |        +-------------+        +--------------+-------+
                  |EOGRE/  | +---------+ |        | +----+        +----+ |
      +---------+ |PMIPV6  | |  VCPE 01| |   +-+  | |SF  |  +--+  |SF  | |
      | PCPE 01 +----------+ | DP State| |        | +----+        +----+ |
      +---------+ |        | +---------+ |        |                      |
                  |        |             |        |    +            +    |
           +      |        |      +      |        |    |            |    |
           +      |        |      +      |        |    |            |    |
                  |        |             |        |    +            +    |
      +---------+ |        | +---------+ |        |                      |
      | PCPE 0N +----------+ |VCPE 0N  | |        | +----+        +----+ |
      +---------+ |        | |DP State | |   +-+  | |SF  |  +--+  |SF  | |
                  |        | +---------+ |        | +----+        +----+ |
                  |        +-------------+        +----------------------+
                  |            BNG-DP                    SFC Framework
                  |
                  |
                  |
                  +
          Broadband Access
             Network




                    Figure 4: VCPE deployment model-03




Pularikkal, et al.       Expires August 28, 2017               [Page 10]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


4.4.1.  Forwarding Policy Configuration (FPC) Interface

   FPC Protocol interface defined in the DMM working group enables DMM
   use cases with Control Plane and data plane separation.  In vCPE
   solution model-03, FPC protocol is applied to the interface between
   BNG-CP and BNG-DP.  FPC interface consists of a client function which
   resides on the Control Plane System (BNG-CP in this case) and an
   agent function which resides on the Data Plane System (BNG-DP in this
   case).  FPC defines a standard set of protocol semantics to exchange
   configuration information from the client to the agent.  Agent
   processes the protocol semantics and translates them into
   configuration commands as per BNG-DP system technology.  FPC client
   function residing on BNG-CP device will leverage FPC Protocol
   semantics to provision activate or deactivate the V-CPE DP states on
   BNG-DP with desired features.

   Some of the FPC attributes needed for vCPE implementation are listed
   in the tables below:

































Pularikkal, et al.       Expires August 28, 2017               [Page 11]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


       +----------------------------------------------------------------+
       |  Attribute  |        Description            |   Availability   |
       +----------------------------------------------------------------+
       | PROP_TUN    | Tunnel Encapsulation Type     | Defined in FPC   |
       +----------------------------------------------------------------+
       | PROP_GW     | Default Gateway IP Address    | Defined in FPC   |
       |             | for client traffic            |                  |
       +----------------------------------------------------------------+
       | PROP_NSH    | Add NSH Header                | Defined in FPC   |
       +----------------------------------------------------------------+
       | PROP_PUNT   | Default next hop for unknown  | Not in FPC Draft |
       |             | traffic class                 |                  |
       +----------------------------------------------------------------+
       | PROP_L2PASS | Layer 2 passthrough for the   | Not in FPC Draft |
       |             | matching traffic              |                  |
       +----------------------------------------------------------------+
       | PROP_QOS_GBR| Guaranteed bit rate for a port| Defined in FPC   |
       |             | or port group                 |                  |
       +----------------------------------------------------------------+
       | PROP_QOS_MBR| Maximum bit rate for a port   | Defined in FPC   |
       |             | or port group                 |                  |
       +----------------------------------------------------------------+
       | PROP_DROP   | Drop the IP packet            | Defined in FPC   |
       +----------------------------------------------------------------+
       | PROP_DROP_L2| Drop the layer 2 packet       | Not in FPC Draft |
       +----------------------------------------------------------------+




             Figure 5: FPC Attributes needed for vCPE Model-03

   Attributed listed in the table above just represents a sample list.
   The complete list of attributes will be defined in a companion draft.

5.  Deployment Considerations for vCPE

   This section at a high level touches up on some of the key deployment
   charecteristics which needs to be considered while selecting the
   right vCPE architecure

5.1.  Multi-tenancy

   vCPE represents the abstraction of key functions and features
   typically performed by classical device into service provider cloud.
   In order for such a solution to be operationally feasible and
   profitable, it is important for vCPE architecture to support multi-
   tenancy.  This multi tenancy support needs to scale of the order of



Pularikkal, et al.       Expires August 28, 2017               [Page 12]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


   hundreds of thousands.  From the context of vCPE deployments, the
   multi-tenancy refers to the logical separation of vCPE instances,
   which are housed in a common backend infrastructure.  This backend
   infrastructure could consist of virtual elements on a compute
   platform or physical networking components.  It could very well be a
   combination of virtual and physical components in the service
   provider cloud.  Few of the key areas where multi-tenancy model will
   have an implication on the operational efficiency of the solution are
   listed below:

   Overlapping IP addressing: Typically home networks are configured
   with RFC 1918 private address space 192.168.0.0/24.  A vCPE solution,
   which deals with IP address management of the private home network,
   must support address overlap for these private home subnets.

   Tunnel scale: Tunnel termination points in the service provider must
   support tunnel scale of the order of hundreds of thousands.  A vCPE
   implementation must implement some form of unique tunnel id per
   physical CPE to support saleable multi-tenancy for tunnel
   termination.

   Overlapping SSID naming: vCPE framework must be flexible enough to
   allow home subscribers to configure private SSID names of their
   choice.  Possibility of overlapping SSID names cannot be ruled out as
   subscribers randomly decide up on their private SSID names.  Multi-
   tenancy solution for a vCPE framework must take into consideration
   this.

5.2.  Tunneling

   In a vCPE solution, the end subscriber data must be tunneled from the
   physical CPE towards the vCPE instance in the cloud.  Typical home
   broadband deployments may have community Wi-Fi SSID enabled in
   addition to subscribers private home SSID.  For such cases, the
   tunnel must be capable of carrying both private and community Wi-Fi
   SSID traffic in a secured manner.  Today there are various tunneling
   methods being used for community Wi-Fi deployments.  Two of the most
   common tunneling methods in use are EoGRE and PMIPv6.  EoGRE is a
   layer-2 tunneling technology and it does not have a control plane of
   its own.  PMIPv6 is a layer-3 tunneling technology with a well-
   defined control plane for tunnel management and session management.
   Either of these tunneling options can be leveraged to carry the
   private SSID traffic from the home towards the cloud-based vCPE.  And
   both are capable of carrying community Wi-Fi and private home SSID
   traffic.  The choice of the tunneling technology may be influenced by
   various factors such as simplicity, need for IP address persistence
   with client roaming, layer-2 forwarding in the data plane to the
   cloud as opposed to layer-3 forwarding etc.



Pularikkal, et al.       Expires August 28, 2017               [Page 13]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


5.3.  Security

   The classical home broadband deployments based up on intelligent
   physical CPE devices typically provide data privacy and security for
   the end subscriber content as it gets carried over the access
   network.  A security framework for a vCPE network has to account for
   the following key aspects:

   Subscriber Authentication

   Protection against spoofing attacks

   Data privacy

   Prevention of eaves dropping between subscribers

   Security considerations go hand in hand with multi-tenancy
   requirements as data and meta data from multiple subscribers will be
   handled by the backend systems.

5.4.  Dynamic Service Chaining

   One of the key motivation behind a cloud based connected home
   solution is to find additional revenue generation opportunities
   through rapid deployment of new services.  The implementation of
   these new services requires a combination of system and network level
   functions to be applied to the end user traffic flows.  Some of these
   functions may be enabled, by leveraging system level features on the
   CPE Device Anchor.  But in many cases, it makes more sense to offload
   the feature processing to network function elements, which are
   external to the CPE Device Anchor (CDA).

   Service function chaining (SFC) refers to a collection of network
   elements connected in a serialized fashion through which a traffic
   flow will be diverted prior to forwarding to the intended
   destination.  Traditionally these service chains are hard connected
   there by causing challenges around flexibility and scale.

   With dynamic service function chaining approach, the network
   elements, which perform various service functions, are arranged in
   grid model.  Logical connectivity is established on a per traffic
   flow basis between the network elements to establish SFC pipeline for
   a qualified traffic flow.  Dynamic SFC addresses the scale and
   flexibility limitations of the traditional chaining model.  A vCPE
   solution must support the deployment of dynamic service function
   chaining.





Pularikkal, et al.       Expires August 28, 2017               [Page 14]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


5.5.  NAT Traversal

   Some vCPE deployments may leverage third party access networks and
   offer the solution as an overlay.  In such cases, there may be
   requirement to bring up P-CPE behind a NAT router.  The vCPE service
   provider may not have direct control over the NAT router, which is
   managed by the access network provider.  In such cases, a tunnel
   transport mode, which can traverse NAT, needs to be selected.

   EoGRE tunnels do not support NAT traversal, since there is no UDP
   layer in the encapsulation header.  PMIPv6 can support NAT traversal
   if the right data encapsulation option is selected.  If a layer
   tunneling technology is desired for the implementation where NAT
   traversal is a requirement, then tunnel transport mechanisms such as
   L2TPV3 may be explored.

6.  Conclusion

   In this document, the concept of VCPE is illustrated in detail.  The
   basic concept of VCPE is to shift the complicated functions from the
   pCPE at the customer side to the VCPE at the service provider side.
   The motivation of such shifting can be concluded as providing quick
   launched customer defined services, reducing the Capex and Opex of
   the pCPE, and simlify the maintainance of both pCPE and VCPE.  A use
   cases of community Wi-Fi is proposed for VCPE, which is a typical
   scenario for DMM.  Three models are then discussed for the field
   deployment of VCPE.  And CP/DP interface is suggested to be utilized
   in the deployment models.

7.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Byju Pularikkal
   Cisco Systems
   170 West Tasman Drive
   San Jose
   United States

   Email: byjupg@cisco.com






Pularikkal, et al.       Expires August 28, 2017               [Page 15]


Internet-Draft    Virtual CPE Deployment Considerations    February 2017


   Qiao Fu
   China Mobile
   Xuanwumenxi Ave. No.32
   Beijing
   China

   Email: fuqiao1@outlook.com


   Hui Deng
   China Mobile
   Xuanwumenxi Ave. No.32
   Beijing
   China

   Email: denghui@chinamobile.com


   Ganesh Sundaram
   Cisco Systems
   170 West Tasman Drive
   San Jose
   United States

   Email: gsundara@cisco.com


   Sri Gundavelli
   Cisco Systems
   170 West Tasman Drive
   San Jose
   United States

   Email: sgundave@cisco.com

















Pularikkal, et al.       Expires August 28, 2017               [Page 16]