Internet Engineering Task Force Q. Fu, Ed. Internet-DraftChina MobileH. Deng Intended status: InformationalS. Gundavelli Expires: January 2, 2016 Cisco H. DengChina MobileJulyExpires: April 21, 2016 October 19, 2015 Motivations, usecases and Models of VCPEdraft-fu-dmm-vcpe-models-00draft-fu-dmm-vcpe-models-01 Abstract This document introduces the concept of Virtual Customer Premises Equipment (VCPE). Such concept was first proposed in Broadband Forum (BBF) as Network Enhanced Residential Gateway (NERG). TheVCPEconcept isthe Home Agent (HA)further expanded as not only referring to virtual CPE of residential network, but all theMobile Nodes (MN) attachedvirtual network and service functions shifted from the customer side to thephysical CPE (pCPE).operator side. Deployment of VCPE in some typical DMM (Distributed Mobility Management) scenarios brings specific requirements and even protocol extension in DMM. In this document, we will first explain the motivation and advantages of VCPE.ThreeA usecases of VCPE in the community Wi-Fi deployment is further discussedin the enterprise network, the residential network, andso as to explain theInternetdeployment ofThings (IoT) Network. TwoVCPE in a DMM scenario. Three models of field deployment of VCPE are discussedafterwards. The models of VCPE decomposeafterwards to indicate theControl Plane (CP)possible CP/DP decomposition requirement andthe Data Plane (DP), which makes it easier for the deployment of the distributed mobility model.protocol extension. 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 onJanuary 2,April 21, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation and Advantage of VCPE . . . . . . . . . . . . . . 3 4. Use case of VCPE . . . . . . . . . . . . . . . . . . . . . . 4 5. Models of VCPE Deployment . . . . . . . . . . . . . . . . . . 5 6. VCPE Deployment for Community Wi-Fi . . . . . . . . . . . . . 8 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . .8 7.9 8. Informative References . . . . . . . . . . . . . . . . . . .89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .910 1. Introduction This document introduces the concept of VCPE. The concept of VCPE is to shift most of the networking and service functionalities from the customer side to the network side. In this way, the customer side's equipment, that is the pCPE (Physical Customer Premises Equiptment), can be simplified. The VCPE refers to one or a set of equipments at the network side to execute the networking and service functionalities used to be executed at the CPE. In such architecture, the CPE can be a simple L2 switch, which is only responsible for forwarding packets to a certain next hop. The concept of VCPE was first introduced in BBF as NERG (WT-317), which mainly focuses on shifting some of the functionalities of a residential gateway to the operator's network, for enabling network based features. The aim is to facilitate the deployment, maintenance and evolution of both existing and new capabilities without adding complexity to the RG and/or the home network. Figure 1 shows the architecture of the pCPE and the VCPE.In this architecture, the VCPE is the HA for the mobile nodes adhear to the pCPE at the network side. +---+ +-----+ +-----+ |MN1|====|pCPE1|================|VCPE1| +---+ +-----+ +-----+ +-----+ |pCPE2| +-----+ +---+............... .............. :Customer side: :Network side: : +-----+ : : +-----+|MN2|====|pCPE3|================|vCPE2| +---+: : |pCPE |================|VCPE | : : +-----+ : : +-----+ : ..............: .............: Figure 1: VCPE Architecture In this document, we would like to further propose such concept in the following aspects: (1) Motivation and advantages of VCPE. (2) Usecases of VCPE.We propose three usecases, including the enterprise network, the residential network, and the IoT (InternetA usecase ofthings) network.VCPE in the community Wi-Fi is explained in detail. (3) Models of VCPE deployment. We proposetwothree models for the field deployment of VCPE.Such models can be used for deployments in multiple scenarios, including both residential network and enterprise network.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. Motivation and Advantage of VCPE The motivation and advantage of introduting VCPE can be concluded as follows: (1) It willreducegreatly speed up thecostservice launching period. Since most ofmanufacturingthe complicated functions are located at the VCPE in the network side, operators have more power over services. Benefitting from the recent NFV (Network Function Virtualization) andmaintainingcloud technologies, VCPE can be accomplished using SFC in the virtual network, where different services can act as different VNFs (Virtual Network Functions). Operators only need to add new VNFs on the VCPE side to launch new services to the customers. In this way, Operators can provide a variety of services through the network. (2) It will reduce the cost of the pCPE. By shifting most of the complicated functions from the customer's side to the operator's side, the cost of the pCPE can be reduced significantly. Such redunction can be remarkable in the enterprise network, since network functions, such as Firewall and NAT(Network Address Translator) at the customer side can be expensive. In the meantime,deployment of VCPE can also reducingtheOPEX of operators. Orderscost ofon-site repair can be reduced becauseupgrading tens ofthe simplicitythousands ofthe customer equiptments. (2) It will avoid complicating thepCPEdeviceswhenproviding value- added L3-L7 services to the customers. Take the transport network as example. Traditionally, pCPEs at the enterprise customer side are simple L2 devices in the transport network. In order to meet the requirements for value-added L3-L7launching new servicesfrom the customers, the pCPEs shouldcan beredesigned to become L3 or even more complicated devices. Such devices will notsaved, since onlyresult in an increase of manufacture and maintenance cost, and will also request addtional efforts for frequent update to meet the constantly increased requirements of the customers. Nevertheless, by utilizingsoftware upgrade at the VCPEachitecture, pCPE can remain to be a simple L2 device, which is only responsible for L2 forwarding. In this way, frequent update of these pCPEsside isnot necessary, which will greatly decrease both CAPEX and OPEX of the network operators.required. (3) It willgreatly speed upsimplify theservice launching period.maintainance of the pCPE. Since most of the complicatedfunctionsfunctionalities arelocated at the VCPE inshifted to the network side,operators have more power over services. Benefitting fromtherecent NFV (Network Function Virtualization) and cloud technologies, VCPEmaintainance of the pCPE can beaccomplished using SFCgreatly simplified. On-line maintainance is possible in lots of cases since thevirtual network, where different services can act as different VNFs (Virtual Network Functions). OperatorspCPE is onlyneed to add new VNFs on the VCPE side to launch new services to the customers. In this way, Operators can provideavariety of services throughL2 devices and can be considered transparent to thenetwork.operators. (4) It will provide user-define-network experience. By introducing SFC concept into the VCPE, users can define his own service order and sequence. Therefore,enterprisecustomers can enjoy the self-defined services over the public network. 4. Use case of VCPE The concept of VCPE can be used in multiple scenarios. In this section, we will proposetwo use cases of VCPE, one in residential network, and the other in the enterprise network. (1) Use Casea usecase of VCPEin the Enterprise network. Traditional enterprise network uses the tranport network access. Multiplewhen deploying community Wi-Fi. The community Wi-Fi is a new service that operators provide to leverage unused capacity on existing residential Wi-Fi infrastructure to offer Wi-Fi networkfunctions, including Firewall (FW)access to visitors andNAT, are deployed at the enterprise customer's side. Such deployment not only increasespassers by near thecost ofneighbourhood. An operator can also use this excess capacity to offer services to retail and roaming-parter operators' subscribers. The residential subscribers accessing theequiptment atnetwork from inside their homes have prioritized access to thecustomer side, but also makes it difficultWi-Fi resources. The residential Wi-Fi infrastructure is configured in a manner that allows forboth the enterprise customersa secure andtheindependent access channel to retain serviceproviders operatingquality, safety, andmaintaining the functions. By introducing VCPE into the transport network, functions such as FWprivacy for both residential andNAT can be shiftedvisitor customers. Roaming users are only allowed to use theaggregateWi-Fi networkor core network, acting as VCPE at the service provider's side. Moreover, value-added services can be provided. For example,capacity that is not currently used bydeploying a virtual Deep Packet Inspection (vDPI), service providers can provide fine grained data control totheenterprise customers. (2) Use case of VCPE in the residential network. In the residential network, traditionally, pCPE locatessubscriber at home. Basically, thecustomer premises terminateswireless Access Point (AP) in the homenetworkwill provide two networks: a private one for the home owner/subscriber, andconnecta community network for on-the-go subscribers passing through theLANneighborhood. Home users can have all of their Wi-Fi devices (smartphone, tablet, etc.) automatically connect to theInternet or to some service platforms through the broadband accessprivate network.WithIn theexpansion ofmeantime users travel outside can connect to thebroadband accesscommunity network, andthe development of the OTT (Overcan roaming through different APs supporting community Wi-Fi as he/she is moving. TheTop) industry, the quantity and requirements of addtional functionscommunity Wi-Fi service is a typical usecase of DMM. Deploying community Wi-Fi on the pCPEincreases rapidly. By shifting mostmeans upgrading tens ofthe complicated functions to VCPE, the costthousands of existing pCPE devices at thelargely deployed CPE can be saved.customer side, which is not cost-effective and may bring extra complexity for maintainance. Therefore VCPE becomes an optimized solution for such deployment. In such deployment, themeantime, deployment of new features by service providers can be accelerated. Taking PPPoEprivate users accessas example. By shifting PPPoE clienttoVCPE,the pCPEcan be a simple L2 device. In this case, VCPE takes(which is theresponsibility to initiate PPPoE request to BRAS once receivingAP at home) as usual. The public users are roaming through different pCPEs. The trafficflow from the customers. When receivingall goes though thecertificationtunnel fromBRAS, VCPE will act as DHCP server by assigning IP address tothetraffic generating port. Such approach can also be used for IPv6 upgrade,in which case VCPE can act as IPv6 DHCP relay. (3) Use case of VCPE inpCPE to theIoT (InternetVCPE. The deployment ofThings) network.VCPEcan also be usedin theIoT network. So far, multiple wireless communication standards, including Wi-Fi, Zigbee, Blue Tooth,community Wi-Fi sencario brings specific requirement andetc., exist for the connection of the IoT devicesprotocol extensions tothe GW.DMM. TheIoT GW is responsible for decomposing the L2 packets from the devices, composing them into L3 packets and transferring to the Internet Server. Due to these various wireless communication standards, multiple IoT GWs have to be deployed at users' home to support different IoT devices. By shifting the packet transforming function to VCPE, IoT GW can be a simple and unified L2 forwarding GW, whiledeployment model of VCPEwill support different standard stacksand its possible influence to DMM isresponsible for transforming packetsfurther discussed in the followingdifferent communication standards to IP packets.section. 5. Models of VCPE Deployment There are multiple models when deploying VCPE in use cases as are discussed in the previous section. In this document, we conclude the deployment of VCPE intotwothree models. In the first model, a logical instance of VCPE is deployed in the cloud for each pCPE instance.All traffic from pCPE goes through the vCPE. In the second model, the VCPE is based on service chains attached to BNG. The classifier on BNG putsThat is, the pCPEtraffic through the correct set of service functions. Both of these two models can easily introduce CP/DP decompositon at the VCPE side,andthe DMM protocol can be used. Figure 1 and Figure 2 show the two models of VCPE deployment. For the first model, logical instance ofVCPE isdeployed. Such logical instance can be a seperate instancedeployedbefore or after the BNG, as is showninFigure 1(a) and Figure 1(b). It can also be deployed by upgrading the traditional BNG to includean 1:1 manner. All traffic from pCPE goes through thefunctions of VCPE, as is shown in Figure 1(c).vCPE. +------+ +------+ | pCPE+--------++-----| VCPE |-----+ +------+ +------+ | | +------+ ________ +------++--+---+ +-----++------+ +-+---+ |SFC in| / \ | pCPE +-----+ VCPE +---+ BNG +-----+WAN DC+---+ Internet | +------++--+---+ +-----++------+ +-+---+ +------+ \________/ | +------+ +------+ | | pCPE+--------++-----| VCPE |-----+ +------+ +------+ Figure1(a)2: VCPEinstance deployed beforedeployment model NO.1: Logical Instance of VCPE In the second model, vCPE is modeled service function chains in Gi- LAN. BNG+------+ |knows how to classify the traffic from a given CPE with the help of the control plane, and run it through the service chain. In such model, the CP/DP interface should be used between the control plane (which might be the controller) and the pCPE. +----------+ +Controller| +--+-------+ +CP/DP interface ....................... + :VCPE : + +---+--+ : +-----------------\ : ++++ pCPE +--------+ :|SFP1:DPI->FW->NAT + : + +------+ | : +-----------------/ : + | : : + +------+________ +------+ +--+---+ +-----+ |SFC in| / \ |+--+--+ : +------------\ : ++++ pCPE +-----+ BNG+---+VCPE +-----+WAN DC+---+ Internet | +------+ +--+---+ +-----++---+SFP2:FW->NAT + : + +------+\________/+--+--+ : +------------/ : + | : : + +------+ ||: +--------\ : ++++ pCPE +--------+ : |SFP3:NAT + : +------+ : +--------/ : ....................... Figure1(b)3: VCPEinstance deployed afterdeployment model NO.2: VCPE as SFC The third model is almost the same with the second one, except that the BNG+------+ |is also CP/DP decomposed. In this model, The control plane is composed of the controller of the pCPE+--------+ +------+ | +--+---------+ +------+ ________and the control plane of the BNG. The CP/DP interface is used between the controller and the pCPE, and between the control plane and the data plane of the BNG. Both of model No.2 and No.3 may have specific requirement and protoco extensions for the CP/DP interface due to the usecase of VCPE. ................................. : Control Plane : : +----------+ +------+ : : +++++++Controller| |BNG+-----+CP| : : + +----------+ +--+---+ : ..+......................+......: + CP/DP interface + ....................... + + :VCPE : + +---+--+ + : +-----------------\ : ++++ pCPE +-------+ + :|SFP1:DPI->FW->NAT + : + +------+ ||SFC in| / \+ : +-----------------/ : + | + : : + +------+ +-+----+-+ : +------------\ : ++++ pCPE +-----+|VCPE | +---+WAN DC+---+ Internet |BNG DP +----+SFP2:FW->NAT + : + +------+ +-+------+ : +------------/ : ++-----+|+------+ \________/ +--+---------+: : + +------+ ||: +--------\ : ++++ pCPE+--------++-------+ : |SFP3:NAT + : +------+ : +--------/ : ....................... Figure1(c) VCPE instance deployed through upgrading BNG Figure 2:4: VCPE deployment modelNO.1: Logical Instance of VCPE For the second models, no logical instance exists as VCPE.NO.3: VCPEis realizedasa sequenceSFC, with CP/DP decomposition ofservice function chaining (SFC) in the WAN DC. In this model,BNGis acting as the classifier of SFC. Such classfication should be based on user profile, in which case, users can define his own VCPE service.SDN (Software Define Network) controllers can also be introduced in thesecondthird model. In which case, all of the pCPEs and the BNG data plane(BNG-dp)(BNG DP) can be controlled by theSDN-controller (also acting as the BNG control plane(BNG-cp)), as is shown in Figure 3.SDN-controller. When the customer selects a set of services, the SDN-controller will inform the pCPE and theBNG-dpBNG DP to direct the traffic flow to a certain SFC.the Service Classification Function (SCF) is located in the BNG, responsible for classifing traffic from different customer/network/ service. The SCF is controlled by the SDN-controller. When a packet arrives, the SCF will ask the controller which Service Founction Path (SFP) this flow should follow, and put corresponding SFC encapsulation into the packet. The packet then goes into the service founction region, and will be directed to different Service Founctions (SF) based on the encapsulation. +------+ ............... | pCPE +--------+................................. : Control Plane : : +--------------+ :VCPE: +++++++SDN Controller|++ : : + +--------------+ + : ..+......................+......: + CP/DP interface + ....................... + + :VCPE : + +---+--+ + : +-----------------\ : ++++ pCPE +-------+ + :|SFP1:DPI->FW->NAT + : + +------+ | + :+----++-----------------/ : + | + : :+--+sfp1+-----------++ +------++--+---++-+----+-+ :| +----++------------\ :___|____ |++++ pCPE +-----+ BNG+----| +----+DP +----+SFP2:FW->NAT + :/ \+ +------++--+---++-+------+ :+--+sfp2+------+ Internet | |+------------/ : + |+----+:\________/: + +------+ | :| +----++--------\ :| |++++ pCPE+--------++-------+ : |SFP3:NAT + :+--+sfp3+-----------++------+ :+----++--------/ ::.............:....................... Figure3:5: VCPE deployment modelNO.2:NO.3: SFC realization ofVCPEVCPE, with SDN controller as control plane 6. VCPE Deployment for Community Wi-Fi In this section, we will discuss about the VCPE deployment for Community Wi-Fi in detail. In the following deployment, we assume the VCPE is deployed following the third model we discussed in section 5. That is, the VCPE is a bounch of SFCs at the operator side behind the BNG. The pCPEs and BNG-DP are all controlled by a mutual control plane. The FPC protocol is used between the control plane and the pCPEs, and that and the BNG-DP. As we discussed in section 4, Community Wi-Fi can be deployed with the help of deploying VCPE. In order to provide the Community Wi-Fi service, the pCPE should provide two SSIDs, one for the pubic Wi-Fi users, and the other for the private Wi-Fi users. Packets from different SSID are marked with different VLAN ID. The VCPE should know of the corresponding relation between the SSID and the VLAN ID, so as to provide distinguished services to the publice users and the private users. For instance, the private users should experience a better QoS than the publice ones. In the meantime, the private users and the public users may choose different SFC in the VCPE. All of these different services are classified based on the VLAN ID. Such deployment requirs the FPC client to support the following task: 1) The FPC client should be able to set specific VLAN to each SSID. 2) The FPC client should be able to set the QoS for specific VLAN ID. 3) The FPC client should be able to inform the agent the specific SFC for each VLAN ID. 4) The FPC client should be capable of instruct the agent to handle the MN hand-over of the public Wi-Fi users. In the meantime, such deployment requirs the FPC agent to support the following task: 1) The FPC agent should be able to set specific VLAN to each SSID following the command from the client. 2) The FPC agent should be able to set the QoS for specific VLAN ID following the command from the client. 3) The FPC agent should be able to direct the traffic for specific VLAN ID to a certain SFC following the command of the client. 4) The FPC agent should be able to handle the MN hand-over of the public Wi-Fi users. 7. 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, andproviding quick launched customer defined services insimlify themeantime. Threemaintainance of both pCPE and VCPE. A use casesareof community Wi-Fi is proposed for VCPE,including scenarios in the enterprise network, the residential network and the IoT network. Twowhich is a typical scenario for DMM. Three models are then discussed for the field deployment of VCPE.7.And CP/DP interface is suggested to be utilized in the deployment models. 8. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March1997.1997, <http://www.rfc-editor.org/info/rfc2119>. Authors' Addresses Qiao Fu (editor) China Mobile Xuanwumenxi Ave. No.32 Beijing China Email: fuqiao1@outlook.comSri Gundavelli Cisco Email: sgundave@cisco.comHui Deng China Mobile Xuanwumenxi Ave. No.32 Beijing China Email: denghui@chinamobile.com