Internet DRAFT - draft-lee-vhs-ps
draft-lee-vhs-ps
TBD Y. Lee
Internet-Draft Comcast
Intended status: Informational R. Ghai
Expires: May 14, 2015 Benu Networks
November 10, 2014
Problem Statements of Virtual Home Network
draft-lee-vhs-ps-02
Abstract
Network Virtualization is proven a success to more effectively manage
services in data center. This draft states the motivations and
problem statements of decoupling services from Customer Premises
Equipment (CPE) and virtualizing them in the Network Service Provider
(NSP).
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 May 14, 2015.
Copyright Notice
Copyright (c) 2014 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
Lee & Ghai Expires May 14, 2015 [Page 1]
Internet-Draft Virtualizing Home Services November 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Home CPE . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. CPE Deployment Model . . . . . . . . . . . . . . . . . . . . 3
3. Customizable Service . . . . . . . . . . . . . . . . . . . . 3
4. Network Virtualization . . . . . . . . . . . . . . . . . . . 4
5. High-level Architecture . . . . . . . . . . . . . . . . . . . 4
6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Home CPE
In the early days of Internet era, most users used dial-up directly
connecting to Internet from desktop Personal Computer (PC). Network
Service Provider (NSP) offered a single public IPv4 address to the
dial-up (i.e., PPP) connection to the PC. This model was revised
when Internet and PC became more popular. Multiple PCs would share a
single NSP connection. NSP wanted to preserve the model to offer
only a single public IPv4 address per connection, NAT [RFC2663]
enabled Customer Premises Equipment (CPE) was introduced in home
network. When days advance, NSP are offering more and more IP
services (e.g., video, voice, home automation), NSPs must provide
seamless support and excellent services to their users. Today CPEs
are doing more than just NAT-ing. They may include but not limited
to the following services:
o IPv4 NAT Services
o DHCPv4 Server Service
o Personal Firewall Services
o Parental Control Service
o Voice over IP (VoIP) Service
o Home Monitor Service
Lee & Ghai Expires May 14, 2015 [Page 2]
Internet-Draft Virtualizing Home Services November 2014
o Video Streaming Service
o DNS Proxy Service
2. CPE Deployment Model
Although the current CPE deployment model is a by-product of limited
public IPv4 addresses, it is proven a successful model to serve
users. More importantly, in the past NSP network had limited service
capacity in the network and the capacity wasn't growing as fast as
the user demand. NSP could offload and distribute their services to
the CPE so that NSP can focus on growing bandwidth capacity. With
all the CPE's successes, there are also some drawbacks:
o No Uniform set of Services: There is no uniform set of services.
CPE vendors can't build an one-for-all-NSP CPE. Each NSP may
offer slightly different set of services; hence, each NSP may
develop its CPE specifications for CPE vendors to build.
o Service Variation: Even for a well defined service, each NSP may
still have different requirements. For example: NSP-A may use SIP
for its VoIP and NSP-B may use WebRTC.
o CPE Manageability: When an NSP plan to offer a new service that is
not compatible to the current CPE. The NSP must update or upgrade
the CPE. Depending on the NSP subscription base, it could mean to
update or upgrade thousands to millions of CPEs.
Among all three, CPE manageability is particularly critical to NSP.
3. Customizable Service
The revolution of portable smart device and Internet-of-Thing has
radically changed the service definition for NSP. In the past, only
personal computers were connected to the Internet. NSP service model
was to provide the best connectivity to a household. Household
members didn't usually carry multiple devices and didn't streaming HD
videos to different type of devices, so the service model was
providing best Internet connectivity for the entire household. Fast
forward to today, portable smart devices are personalized. A typical
user may carry 2 to 3 devices that are constantly connected to
Internet. Besides, many electronic devices such as sensors,
monitoring systems, appliances and entertainment systems are all
connected to the Internet. These devices may have different service
requirements. Some may have strict latency requirement (e.g. webcam
and online gaming) and others may have strict bandwidth requirement
(e.g. high-definition video streaming). These new requirements
cause the NSP to rethink a pure connectivity service model to a
Lee & Ghai Expires May 14, 2015 [Page 3]
Internet-Draft Virtualizing Home Services November 2014
customizable service model. This requires the NSP to build a network
that could identify packet flows and associated them to user profiles
and apply proper policies to them.
Since the IPv4 addresses are depleted, IPv6 emigration has finally
started. One major advantage of IPv6 is network transparency. In
IPv4, NSP and Content Service Provider (CSP) can't identify a device
simply by examining just an IPv4 address because a public IPv4 may
represent multiple devices behind NAT. In IPv6, every device will
have one or more Global Unicast IPv6 addresses (GUA). This enables
NSP and CSP to offer device and user specific services. This
inspires innovation in new end-to-end services. For NSP, they may
refine and evolve the current "heavy" CPE deployment model to speed
up offering new services.
4. Network Virtualization
Software Defined Network (SDN) is originally designed to decouple
network software functions from hardware. Service designers can
focus on service development without coupling to the underneath
hardware architecture. SDN provides a set of Application Programming
Interface (API) for service designers to interact with the hardware
for packet processing. There are two critical criterion to make this
concept possible: Fast network and Exponential growth of computation
power in general purposed hardware. Recently many NSPs have agreed
that these two criterion are met with current technology.
Network Function Virtualization (NFV) aims to define a framework to
allow typical network functions such as NAT, firewall and QoS policy
management running on Virtual Machine (VM). NFV can combine with SDN
and convert the traditional hardware centric networking architecture
to more software centric networking architecture. Many NSPs are
seriously considering to apply the SDN and NFV concept to re-
architect the core and edge network design.
5. High-level Architecture
Similar to classic SDN architecture, Virtual Home Network (VHN)
includes a Controller (VHNC) that contains user configurations and
policies and a Packet Processor (VHNF) that process packet
forwarding. Similar to class NFV architecture, VHN includes a set of
Virtual Network Functions (VNF) and a VNF Manager (VNFM) managing the
VNF. Figure 1 shows the high-level VHN architecture.
Lee & Ghai Expires May 14, 2015 [Page 4]
Internet-Draft Virtualizing Home Services November 2014
----------------------
/ User Configuration /
/ and Policy /
/ Controller /
-----||--------||-----
|| || **************
|| Ib || / VNF Manager /
|| || **************
|| +--||-----------------------+ ||
|| | +----+ +----+ +----+ | || Ic
Ia || | |VNF1| |VNF2| .... |VNFx| |=======||
|| | +----+ +----+ +----+ |
|| | Virtual Network Functions |
|| +-------||------------------+
|| ||
|| ||
|| || Service Function Chain (SFC)
---- || || Ie
/CPE/==========\ || ||
---- \ || ||
\+||--||-------+ ///////////////
---- | | / /
/CPE/ =============| Packet |====================/ Internet /
---- Id | Forwarder | / /
/+-------------+ \\\\\\\\\\\\\\\
---- /
/CPE/=========/
---- Ia - SFC Provisioning API
Ib - Service Provisioning API
Ic - VNF Management API
Id - Encapsulation Specification
Ie - SFC Specification
Virtualizing Home Services High-Level Architecture Diagram
Figure 1
In Figure 1, it shows five interfaces. Ia, Ib and Ic are interfaces
for control protocols. Id and Ie are data path specifications.
o Ia between the VHNC and the VHNF is used to exchange configuration
and policy. For example: User A's living room TV has Committed
Information Rate (CIR) set at 10Mb/s and must be protected by
firewall function implemented in VNF.
Lee & Ghai Expires May 14, 2015 [Page 5]
Internet-Draft Virtualizing Home Services November 2014
o Ib between the VHNC and VNFs is used to exchange configuration and
policy For example: VHNC could configure the firewall VHF to block
any incoming ICMP messages to the User A's living room TV.
o Ic between VNFM and VNFs is used to exchange VHN management
messages. For example: VNFM could instantiate a new firewall VNF
when the current firewall VNF reached certain capacity.
o Id is the protocol agreed between CPE and VHNF. It could be
Ethernet or any encapsulation technology such as PMIP or MPLS.
o Ie is the Service Chaining Function protocol between VHNF and VNF.
SFC WG is currently defining the specifications.
VNF contains the service definitions and service logic. For example:
Virtual Network Function 1 (VNF1) could be a parental control service
and manage web filter rules configured by subscriber. Virtual
Network Function 2 (VNF2) could be personal firewall that protects a
home from botnet and intrusion. NSP can scale VNFs horizontally to
meet user demand. NSP can also dynamically create VNF per subscriber
only when the subscriber wants that service. For example: NSP
initiates VNF1 for User X and VNF2 for User Y. In this model, NSP no
longer updates CPE for service addition or modification.
VHNC stores the user's service subscription. Each user may have
different set of home services. For example: User A may have video
service. User B may have VoIP service. VHNC contains the user's
service subscription and interact with the VNF modules to provide
proper services to users.
VHNF is usually a networking device that is optimized for processing
packet. It is also implemented the Service Function Chain function
to forward user packets to proper VNFs.
CPE is a simple access device that connects to the subscriber's
devices at home to the NSP network.
6. Problem Statement
Virtual Home Network enables NSP to offer service in a more rapid
pace. It also enables NSP to offer new possible services such as:
1. Connect a user mobile device to his home network at outdoor
access point.
2. Provide more flexibility IPv4 and IPv6 address management.
3. Provide more granular QoS management.
Lee & Ghai Expires May 14, 2015 [Page 6]
Internet-Draft Virtualizing Home Services November 2014
Section 5 describes the high-level architecture. One possible
deployment is to put the VHNC in a central location and put the VHNF
closer to users. This deployment requires to standardize the
following:
o Service Definition: Define the service semantics and user
interaction. This allows the vendor community to standardize the
service definition and build the Virtual Service model to support
it.
o Ia: Define and specify the API to provision the user configuration
parameters to the VHNF and Service Function Chain.
o Ib: Define and specify the API to provision service parameters to
VNFs.
o Id: Define new header format to carry user id and device id in the
packet.
Standardizing the Service Definitions, Ia and Ib will simplify
service integration and equipment interoperability. This will help
vendors to speed up development and NSP to speed up new service
offering.
7. Security Considerations
8. Conclusion
9. Acknowledgements
10. IANA Considerations
This memo includes no request to IANA.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
Lee & Ghai Expires May 14, 2015 [Page 7]
Internet-Draft Virtualizing Home Services November 2014
Authors' Addresses
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
U.S.A.
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Rajat Ghai
Benu Networks
300 Concord Road, Suite 110
Billerica, MA 01821
U.S.A.
Email: rghai@benunets.com
URI: http://www.benunets.com
Lee & Ghai Expires May 14, 2015 [Page 8]
