idnits 2.17.1 draft-pularikkal-virtual-cpe-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 40 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 24, 2017) is 2616 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Pularikkal 3 Internet-Draft Cisco Systems 4 Intended status: Informational Q. Fu 5 Expires: August 28, 2017 H. Deng 6 China Mobile 7 G. Sundaram 8 S. Gundavelli 9 Cisco Systems 10 February 24, 2017 12 Virtual CPE Deployment Considerations 13 draft-pularikkal-virtual-cpe-02 15 Abstract 17 Broadband Service Provider Industry has been gearing towards the 18 adoption of Virtual CPE (vCPE) solutions. The concept of vCPE is 19 build around the idea that the physical CPE device at the customer 20 premises can be simplified by moving some of the key feature 21 functionalities from the physical CPE device to the Service Provider 22 Network. This document starts discussing the drivers behind vCPE 23 adoption followed by Solution level requirements. Two key 24 Architecture models for vCPE, which can address the service provider 25 and subscriber requirements, are covered in this reference document. 26 Document also touches up on some of the key deployment 27 considerations, which can influence the adoption of the vCPE 28 architecture models. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 28, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Solution Requirements for vCPE . . . . . . . . . . . . . . . 3 67 4. Architecture Models for vCPE . . . . . . . . . . . . . . . . 4 68 4.1. Virtual CPE Definition . . . . . . . . . . . . . . . . . 4 69 4.2. Virtual CPE Architecture Model-01 . . . . . . . . . . . . 5 70 4.3. Virtual CPE Architecture Model-02 . . . . . . . . . . . . 7 71 4.4. Virtual CPE Architecture Model-03 . . . . . . . . . . . . 9 72 4.4.1. Forwarding Policy Configuration (FPC) Interface . . 11 73 5. Deployment Considerations for vCPE . . . . . . . . . . . . . 12 74 5.1. Multi-tenancy . . . . . . . . . . . . . . . . . . . . . . 12 75 5.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 14 77 5.4. Dynamic Service Chaining . . . . . . . . . . . . . . . . 14 78 5.5. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15 79 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 7. Informative References . . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 Broadband Service Providers are constantly looking for opportunities 86 to generate additional revenue streams from their existing broadband 87 infrastructure. In order to achieve this, new value added services 88 need to be created for the end customers. Customer retention is 89 another key focus area for broadband subscribers, where they have 90 been facing competition from Internet content providers on home 91 multi-media services such as broadcast video, video on demand and 92 voice. There is a need to improve the overall end user experience on 93 an ongoing basis to reduce the subscriber churn. In order to achieve 94 these business goals, Broadband Service Providers are starting to 95 consider the deployment of Virtual CPE based Architectures. There 96 are several factors, which are driving the adoption of vCPE-based 97 solutions. Also the recent technological advancements in cloud 98 computing and software defined networking are expected to further 99 accelerate the adoption vCPE based architectures. 101 The key aspect of the vCPE solutions is the simplification of the 102 physical CPE device. Such a simplification allows minimizing the 103 feature dependency on CPE vendors for the roll out of new service 104 offerings. Also it reduces the complexities around service 105 provisioning, Service Upgrade Troubleshooting etc. There are 106 multiple architecture options being considered by the industry for 107 vCPE solutions. 109 Objective of this draft is to serve as a reference material for 110 Broadband Service Operators who are interested in migrating to vCPE 111 based architectures. The document starts with going over some of the 112 key drivers for vCPE solution adoption. Also it covers typical 113 solution level requirements, which needs to be considered while 114 selecting the right architecture models. Document also touches up on 115 some of the key deployment considerations, which can influence the 116 adoption of the vCPE architecture models. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. Solution Requirements for vCPE 126 This section provides a high level summary of solution requirements, 127 which needs to be addressed by Virtual Connected Home Architecture 128 Models. The solution requirements can be broadly classified under 129 the following categories: 131 (1) Subscriber side requirements: Subscriber in the context of this 132 documentation refers to a homeowner with Broadband connection. These 133 requirements primarily map to the end user experience for a home 134 subscriber in terms of connectivity, quality of experience and value 135 added services. 137 (2) Broadband Operator side requirements: Operator is the broadband 138 service provider such as Cable MSOs, DSL providers etc. These 139 requirements primarily maps to the business aspects which needs to be 140 covered in the solution in terms of CAPEX, OPEX reduction, service 141 velocity, new revenue generation opportunities etc. 143 High level requirements under the above two categories are summarised 144 in the table below: 146 +---------------------------------------------------------+ 147 | Subscriber Side Requirements |Operator Side requirements| 148 +---------------------------------------------------------+ 149 |1) Private Home Network | 1) Service Velocity | 150 |2) Zero Touch Provisioning | 2) Simplified CPE | 151 |3) Local Bridging | 3) Per UE Visibility | 152 |4) Local Routing | 4) Community Wi-Fi | 153 |5) NAT, FW, IDS, Parental | 5) IP Address Persistence| 154 |Control | 6) UE Attachment/ | 155 |6) Home Network Analytics | Detachment detction | 156 |7) Self Service Portal | 7)Usage based billing | 157 |8) Dynamic IP address | 8)Quality of Service | 158 |Assignment | 9) NAT Traversal | 159 |9) Home Network Remote Access | | 160 | | | 161 +------------------------------+--------------------------+ 163 Figure 1: VCPE Requirements 165 4. Architecture Models for vCPE 167 In this document three different architecture models are covered for 168 the Virtual CPE based solutions. This section starts with a 169 definition of what represents a virtual CPE and then gets into the 170 details of the Architecture options, which are available for the 171 implementation of the same. 173 4.1. Virtual CPE Definition 175 A virtual CPE (vCPE) is a logical representation of classical CPE 176 functions performed by a physical CPE device. In other words, 177 business logic and feature functionalities which are traditionally 178 embedded in a CPE device is separated from the hardware device and 179 runs in the Service Providers cloud. Concepts of vCPE has basis on 180 the Network Function Virtualization. The business logic and feature 181 functionalities of a CPE device are virtualized and runs as NFV in 182 the cloud. Each simplified physical CPE would have a corresponding 183 virtual CPE function running in the cloud. There are several ways to 184 realize this vCPE instance in the cloud. One approach is to have 185 separate vCPE instance running as a Linux container or micro-VM 186 corresponding to each physical CPE instance. The vCPE may also be 187 implemented as a representational state on aggregation platforms such 188 as broadband network gateways (BNGs). A third approach may rely on a 189 combination of the BNG representational state and Service function 190 chaining to represent the vCPE instance in the cloud. These 191 Architecture models are covered in the subsequent sub-sections. 193 4.2. Virtual CPE Architecture Model-01 195 This model is build around the concept of separate virtualized 196 instance per physical CPE device. In this model Virtual CPE instance 197 handles the control plane as well as the data plane. Each micro VM 198 represents an NFV element of CPE with integrated control and data 199 plane. All feature functionalities get implemented on the NFV 200 element itself. This model does not leverage the dynamic service 201 function chaining capabilities. 203 A high level Architecture view of this model is provided in figure- 204 below: 206 + 207 | 208 | COMPUTE PLATFORM 209 | +--------------------------------+ 210 +--------+ | | VXLAN 01 +-------+ | 211 |PCPE 01 +-------+ | +----------------+VCPE 01| | 212 +--------+ | | EoGRE / | | +-------+ | 213 | | PMIPV6 | +--------+ | 214 | +------------+VSWITCH | + | 215 | +------------+ | | | 216 | | EoGRE / | +--------+ + | 217 | | PMIPV6 | | | | 218 +--------+ | | | | | VXLAN 0N +-------+ | 219 |PCPE 0N +-------+ | | +----------------+VCPE 0N| | 220 +--------+ | | | +-------+ | 221 | +--------------------------------+ 222 | | 223 | | 224 | | 225 | XXXX 226 + XXX XXX 227 XX XX 228 Broadband Access XX XX 229 Network X X 230 X Internet X 231 X X 232 XX XX 233 XXX XXX 234 XXXXXXX 235 X 237 Figure 2: VCPE deployment model-01 239 P-CPE device performs just the bridging function where the layer-2 240 traffic between directly connected devices will be simply bridged by 241 the P-CPE. Any layer-3 traffic will be transparently forwarded to 242 the cloud over the tunnel. 244 In this model all the key cloud based components run on virtualized 245 platforms. These virtual components are deployed on standalone 246 virtual platforms rather than on large scale virtual DC of Service 247 providers. Therefore, the tunnel will be terminated on the vSwitch 248 rather than a tunnel termination GW located at the boarder of the DC. 250 An implementation could leverage either a vendor specific vSwitch or 251 an Open vSwitch. 253 Tunnel end points are uniquely identified with the IP address of the 254 P-CPE. The vSwitch maps the de-encapsulated traffic from the tunnels 255 to unique VXLANs and will forward to the corresponding Micro VM 256 instances. Micro VM instances will be responsible for supporting the 257 key functions traditionally performed on physical CPE devices. After 258 the feature processing, V-CPE instance will send the traffic back to 259 the v-Switch over VXLAN tunnels and vSwitch will forward it to 260 external network. 262 4.3. Virtual CPE Architecture Model-02 264 In this model vCPE in the cloud is corresponding to each physical CPE 265 is realized by a representational state on a tunnel aggregation 266 platform such as BNG. A provisioned physical CPE in run state is 267 expected to have at least one tunnel established between the physical 268 CPE and the BNG. As long as the PCPE is in run state there will be a 269 CPE session on the BNG which represents the CPE itself. Some of the 270 key CPE features will be running on the BNG while supplementary 271 features and services can be deployed using dynamic service function 272 chaining functions. 274 A high level Architecture view of this mode2 is provided in figure- 275 below: 277 +-----------------------+ 278 +-------+ +---------------------+ 279 | |Policy Infrastructure | | 280 | +----------------+------+ | 281 | | | 282 | | | 283 | | SFC Framework 284 | +---------------+ +----------v-----------+ 285 | | +----------+ | | | 286 | + | | VCPE 01 | | | +-----+ +-----+ | 287 | | | | Session | | | |SF011| +--+ |SF01N| | 288 +---v----+ | | | State | | +---+ | +-----+ +-----+ | 289 |PCPE 01 +------------+ +----------+ | | | 290 +--------+ | | | | + + | 291 | | + | | | | | 292 | | | | | | | | 293 | | + | | | | | 294 | | | | | | | 295 +--------+ | | +---------+ | | + + | 296 |PCPE 0N +------------+ |VCPE 0N | | | | 297 +--------+ | | |Session | | +---+ | +-----+ +-----+ | 298 | | |State | | | |SF0N1| |SF0NN| | 299 | | +---------+ | | +-----+ +-----+ | 300 + +---------------+ +-----------+----------+ 301 | 302 Broadband Access XXXX 303 Network XXX XXX 304 XXX XX 305 XX X 306 X XX 307 X Internet X 308 X XX 309 XX X 310 XX XX 311 XX XXX 312 XX XX 313 XXXXXXX 315 Figure 3: VCPE deployment model-02 317 In this model as well, P-CPE device performs just the bridging 318 function where the layer-2 traffic between directly connected devices 319 will be simply bridged by the P-CPE. Any layer-3 traffic will be 320 transparently forwarded to the BNG over the tunnel. 322 There is no need for pre-configuration of the tunnels on BNG. When a 323 P-CPE device become active and gets provisioned it will try to 324 establish an EoGRE tunnel session with V-CPE. Up on detecting a new 325 P-CPE end point, the BNG would invoke an authorization process for 326 the tunnel end point. It is up to the implementation to decide 327 whether an out of band authentication mechanism is required before 328 establishing v-CPE state on the BNG. If the access network is 329 untrusted, the service provider may decide to overlay the EoGRE 330 tunnel with IPSec encapsulation. 332 BNG will need to uniquely tag the subscriber flows before forwarding 333 to the SFC framework. This can be accomplished by using some 334 scalable tagging mechanisms such as VXLAN. 336 4.4. Virtual CPE Architecture Model-03 338 This is similar to model-02 but leverages split architecture for 339 control plane and data plane for the BNG. This model introduces the 340 concept of a BNG controller, which essentially carries out the 341 control plane functions. Data plane component of the BNG can be a 342 purpose built hardware optimized for scaleable tunnel termination, 343 data encryption and data forwarding. Control plane intelligence of 344 each vCPE resides as a session state on the BNG controller and the 345 data plane intelligence including tunnel termination of each vCPE 346 resides on the BNG-DP system. BNG-CP will leverage the FPC 347 (Forwarding Policy Configuration) interface which is being defined in 348 the DMM working group to instruct the BNG-DP system to establish 349 V-CPE DP states with relevant configuration.Role of FPC interface in 350 this solution is described in the sub-section below. In this model, 351 all basic and supplementary subscriber features will be implemented 352 using a dynamic service function-chaining framework. 354 A high level Architecture view of this mode3 is provided in figure- 355 below: 357 +----------------------+ 358 |Policy Infrastructure +--+---------------+ 359 +----------------------+ | | 360 BNG CP | | 361 +-------------+ | 362 | +---------+ | | XXX 363 | | VCPE 01 | | | XX XX 364 | |CP State | | | XX XX 365 | +---------+ | | XX X 366 | | | X XX 367 | + | | X X 368 | + | | XInternetX 369 | | | X X 370 | +---------+ | | X X 371 | | VCPE 0N | | | XX X 372 | |CP State | | | XX XX 373 | +---------+ | | XX X 374 + +-------------+ | X+X 375 | | FPC | | 376 | | Interface | | 377 | ^ | | 378 | +-------------+ +--------------+-------+ 379 |EOGRE/ | +---------+ | | +----+ +----+ | 380 +---------+ |PMIPV6 | | VCPE 01| | +-+ | |SF | +--+ |SF | | 381 | PCPE 01 +----------+ | DP State| | | +----+ +----+ | 382 +---------+ | | +---------+ | | | 383 | | | | + + | 384 + | | + | | | | | 385 + | | + | | | | | 386 | | | | + + | 387 +---------+ | | +---------+ | | | 388 | PCPE 0N +----------+ |VCPE 0N | | | +----+ +----+ | 389 +---------+ | | |DP State | | +-+ | |SF | +--+ |SF | | 390 | | +---------+ | | +----+ +----+ | 391 | +-------------+ +----------------------+ 392 | BNG-DP SFC Framework 393 | 394 | 395 | 396 + 397 Broadband Access 398 Network 400 Figure 4: VCPE deployment model-03 402 4.4.1. Forwarding Policy Configuration (FPC) Interface 404 FPC Protocol interface defined in the DMM working group enables DMM 405 use cases with Control Plane and data plane separation. In vCPE 406 solution model-03, FPC protocol is applied to the interface between 407 BNG-CP and BNG-DP. FPC interface consists of a client function which 408 resides on the Control Plane System (BNG-CP in this case) and an 409 agent function which resides on the Data Plane System (BNG-DP in this 410 case). FPC defines a standard set of protocol semantics to exchange 411 configuration information from the client to the agent. Agent 412 processes the protocol semantics and translates them into 413 configuration commands as per BNG-DP system technology. FPC client 414 function residing on BNG-CP device will leverage FPC Protocol 415 semantics to provision activate or deactivate the V-CPE DP states on 416 BNG-DP with desired features. 418 Some of the FPC attributes needed for vCPE implementation are listed 419 in the tables below: 421 +----------------------------------------------------------------+ 422 | Attribute | Description | Availability | 423 +----------------------------------------------------------------+ 424 | PROP_TUN | Tunnel Encapsulation Type | Defined in FPC | 425 +----------------------------------------------------------------+ 426 | PROP_GW | Default Gateway IP Address | Defined in FPC | 427 | | for client traffic | | 428 +----------------------------------------------------------------+ 429 | PROP_NSH | Add NSH Header | Defined in FPC | 430 +----------------------------------------------------------------+ 431 | PROP_PUNT | Default next hop for unknown | Not in FPC Draft | 432 | | traffic class | | 433 +----------------------------------------------------------------+ 434 | PROP_L2PASS | Layer 2 passthrough for the | Not in FPC Draft | 435 | | matching traffic | | 436 +----------------------------------------------------------------+ 437 | PROP_QOS_GBR| Guaranteed bit rate for a port| Defined in FPC | 438 | | or port group | | 439 +----------------------------------------------------------------+ 440 | PROP_QOS_MBR| Maximum bit rate for a port | Defined in FPC | 441 | | or port group | | 442 +----------------------------------------------------------------+ 443 | PROP_DROP | Drop the IP packet | Defined in FPC | 444 +----------------------------------------------------------------+ 445 | PROP_DROP_L2| Drop the layer 2 packet | Not in FPC Draft | 446 +----------------------------------------------------------------+ 448 Figure 5: FPC Attributes needed for vCPE Model-03 450 Attributed listed in the table above just represents a sample list. 451 The complete list of attributes will be defined in a companion draft. 453 5. Deployment Considerations for vCPE 455 This section at a high level touches up on some of the key deployment 456 charecteristics which needs to be considered while selecting the 457 right vCPE architecure 459 5.1. Multi-tenancy 461 vCPE represents the abstraction of key functions and features 462 typically performed by classical device into service provider cloud. 463 In order for such a solution to be operationally feasible and 464 profitable, it is important for vCPE architecture to support multi- 465 tenancy. This multi tenancy support needs to scale of the order of 466 hundreds of thousands. From the context of vCPE deployments, the 467 multi-tenancy refers to the logical separation of vCPE instances, 468 which are housed in a common backend infrastructure. This backend 469 infrastructure could consist of virtual elements on a compute 470 platform or physical networking components. It could very well be a 471 combination of virtual and physical components in the service 472 provider cloud. Few of the key areas where multi-tenancy model will 473 have an implication on the operational efficiency of the solution are 474 listed below: 476 Overlapping IP addressing: Typically home networks are configured 477 with RFC 1918 private address space 192.168.0.0/24. A vCPE solution, 478 which deals with IP address management of the private home network, 479 must support address overlap for these private home subnets. 481 Tunnel scale: Tunnel termination points in the service provider must 482 support tunnel scale of the order of hundreds of thousands. A vCPE 483 implementation must implement some form of unique tunnel id per 484 physical CPE to support saleable multi-tenancy for tunnel 485 termination. 487 Overlapping SSID naming: vCPE framework must be flexible enough to 488 allow home subscribers to configure private SSID names of their 489 choice. Possibility of overlapping SSID names cannot be ruled out as 490 subscribers randomly decide up on their private SSID names. Multi- 491 tenancy solution for a vCPE framework must take into consideration 492 this. 494 5.2. Tunneling 496 In a vCPE solution, the end subscriber data must be tunneled from the 497 physical CPE towards the vCPE instance in the cloud. Typical home 498 broadband deployments may have community Wi-Fi SSID enabled in 499 addition to subscribers private home SSID. For such cases, the 500 tunnel must be capable of carrying both private and community Wi-Fi 501 SSID traffic in a secured manner. Today there are various tunneling 502 methods being used for community Wi-Fi deployments. Two of the most 503 common tunneling methods in use are EoGRE and PMIPv6. EoGRE is a 504 layer-2 tunneling technology and it does not have a control plane of 505 its own. PMIPv6 is a layer-3 tunneling technology with a well- 506 defined control plane for tunnel management and session management. 507 Either of these tunneling options can be leveraged to carry the 508 private SSID traffic from the home towards the cloud-based vCPE. And 509 both are capable of carrying community Wi-Fi and private home SSID 510 traffic. The choice of the tunneling technology may be influenced by 511 various factors such as simplicity, need for IP address persistence 512 with client roaming, layer-2 forwarding in the data plane to the 513 cloud as opposed to layer-3 forwarding etc. 515 5.3. Security 517 The classical home broadband deployments based up on intelligent 518 physical CPE devices typically provide data privacy and security for 519 the end subscriber content as it gets carried over the access 520 network. A security framework for a vCPE network has to account for 521 the following key aspects: 523 Subscriber Authentication 525 Protection against spoofing attacks 527 Data privacy 529 Prevention of eaves dropping between subscribers 531 Security considerations go hand in hand with multi-tenancy 532 requirements as data and meta data from multiple subscribers will be 533 handled by the backend systems. 535 5.4. Dynamic Service Chaining 537 One of the key motivation behind a cloud based connected home 538 solution is to find additional revenue generation opportunities 539 through rapid deployment of new services. The implementation of 540 these new services requires a combination of system and network level 541 functions to be applied to the end user traffic flows. Some of these 542 functions may be enabled, by leveraging system level features on the 543 CPE Device Anchor. But in many cases, it makes more sense to offload 544 the feature processing to network function elements, which are 545 external to the CPE Device Anchor (CDA). 547 Service function chaining (SFC) refers to a collection of network 548 elements connected in a serialized fashion through which a traffic 549 flow will be diverted prior to forwarding to the intended 550 destination. Traditionally these service chains are hard connected 551 there by causing challenges around flexibility and scale. 553 With dynamic service function chaining approach, the network 554 elements, which perform various service functions, are arranged in 555 grid model. Logical connectivity is established on a per traffic 556 flow basis between the network elements to establish SFC pipeline for 557 a qualified traffic flow. Dynamic SFC addresses the scale and 558 flexibility limitations of the traditional chaining model. A vCPE 559 solution must support the deployment of dynamic service function 560 chaining. 562 5.5. NAT Traversal 564 Some vCPE deployments may leverage third party access networks and 565 offer the solution as an overlay. In such cases, there may be 566 requirement to bring up P-CPE behind a NAT router. The vCPE service 567 provider may not have direct control over the NAT router, which is 568 managed by the access network provider. In such cases, a tunnel 569 transport mode, which can traverse NAT, needs to be selected. 571 EoGRE tunnels do not support NAT traversal, since there is no UDP 572 layer in the encapsulation header. PMIPv6 can support NAT traversal 573 if the right data encapsulation option is selected. If a layer 574 tunneling technology is desired for the implementation where NAT 575 traversal is a requirement, then tunnel transport mechanisms such as 576 L2TPV3 may be explored. 578 6. Conclusion 580 In this document, the concept of VCPE is illustrated in detail. The 581 basic concept of VCPE is to shift the complicated functions from the 582 pCPE at the customer side to the VCPE at the service provider side. 583 The motivation of such shifting can be concluded as providing quick 584 launched customer defined services, reducing the Capex and Opex of 585 the pCPE, and simlify the maintainance of both pCPE and VCPE. A use 586 cases of community Wi-Fi is proposed for VCPE, which is a typical 587 scenario for DMM. Three models are then discussed for the field 588 deployment of VCPE. And CP/DP interface is suggested to be utilized 589 in the deployment models. 591 7. Informative References 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, 595 DOI 10.17487/RFC2119, March 1997, 596 . 598 Authors' Addresses 600 Byju Pularikkal 601 Cisco Systems 602 170 West Tasman Drive 603 San Jose 604 United States 606 Email: byjupg@cisco.com 607 Qiao Fu 608 China Mobile 609 Xuanwumenxi Ave. No.32 610 Beijing 611 China 613 Email: fuqiao1@outlook.com 615 Hui Deng 616 China Mobile 617 Xuanwumenxi Ave. No.32 618 Beijing 619 China 621 Email: denghui@chinamobile.com 623 Ganesh Sundaram 624 Cisco Systems 625 170 West Tasman Drive 626 San Jose 627 United States 629 Email: gsundara@cisco.com 631 Sri Gundavelli 632 Cisco Systems 633 170 West Tasman Drive 634 San Jose 635 United States 637 Email: sgundave@cisco.com