Internet DRAFT - draft-liu-nvo3-naas-arch
draft-liu-nvo3-naas-arch
Network working group Vic Liu
Internet Draft China Mobile
Category: Standard Track L. Xia
Huawei
Zu Qiang
Ericsson
Expires: December, 2014 June 30, 2014
Network as a Service Architecture
draft-liu-nvo3-naas-arch-01
Abstract
This draft provides an high-level overview architecture of Network
as a Service (NaaS) system, and describes how every component of it
works together from different aspects (i.e., data plane, control
plane, management plane, etc) of NaaS system.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al [Page 1]
Internet-Draft NVO3 NaaS Architecture June, 2014
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.
Table of Contents
1. Introduction ................................................ 3
1.1. Conventions used in this document ...................... 4
1.2. Terminology ............................................ 4
2. Overview .................................................... 5
2.1. New Features ........................................... 5
2.2. Main Challenges......................................... 6
3. NaaS Architecture ........................................... 6
4. Data Plane of NaaS System ................................... 8
4.1. Centralized NaaS Network ............................... 8
4.2. Distributed NaaS Network ............................... 9
4.3. Comparison ............................................. 9
5. Control Plane of NaaS Network ............................... 9
6. Management Plane of NaaS Network ............................ 9
7. Security Considerations ..................................... 9
8. Acknowledgements ............................................ 9
9. IANA Considerations ......................................... 9
10. References ................................................. 9
10.1. Normative References .................................. 9
10.2. Informative References ................................ 9
Liu, et al [Page 2]
Internet-Draft NVO3 NaaS Architecture June, 2014
1. Introduction
Network as a Service (NaaS) is a new network business model provided
by more and more operators. It is a novel class of services for
cloud computing that provides virtualized E2E connectivity to end
users at different levels of reliability, traffic QoS and
transparency in a flexible and scalable way. From the technical
point of view, the essential part of it is network virtualization.
That means, virtual network (including sub-network, gateway, network
routing, bandwidth, network service, etc) as the resource provided
by operator, can be got on-demand by clients by the way of pay as
you go service. Clients can make the network provision and use their
own virtual network flexibly according to specific requirements. By
this way, operators' network infrastructure can be virtualized and
multiplexed for selling, and clients can improve the flexibility of
their network to reduce cost because of better visibility and
efficient control over their own virtual network.
The common use case for NaaS is to construct the virtual private
cloud network (VPCN) for tenant (i.e., enterprise, organization, etc)
over the public cloud provided by operator. Its main characteristic
is that tenant can custom their own VPCN, i.e., network topology,
VPN connection, network services, etc. Following Figure 1 is an
example for VPCN:
.............................
. ...... .
. .... .... .
. . +-----+ . .
.. +-+ TS | . .
.. | +---+-+ . .
...... . . +-----+ . .
... ... . ....subnet.... .
.. . . ...... .
. Internet . . | .
.. . . | .
... ... . +---+--+ .
...... . | VPN | .
| . | GW | branch site .
| . +--+---+ or other VPCN.
| .........|...................
| |VPN connection
+---+----+ +---+---+
................|Internet|.........| VPN |...............
Liu, et al [Page 3]
Internet-Draft NVO3 NaaS Architecture June, 2014
. ........ | GW | | GW | .
. .+---+ . +---+----+ +---+---+ ........ .
. .|NAT| . | | .+---+ . .
. .+---+ . +------------------+ .|NAT| . .
. .+---+ . | | .+---+ . .
. .|FW | . +---+--+ +---+--+ .+---+ . .
. .+---+ .-----+ GW | | GW +----.|FW | . .
. .+---+ . +--+---+ +--+---+ .+---+ . .
. .|...| . | | .+---+ . .
. .+---+ ...... ...... .|...| . .
. ....... .... .... .... .... .+---+ .
. . +-----+ . . +-----+ . ....... .
. . +-+ TS | . . +-+ TS | . .
. . | +---+-+ . . | +---+-+ . .
. . +-----+ . . +-----+ . .
. ....subnet.... ....subnet.... .
.VPCN ...... ...... .
...........................................................
Figure 1: VPCN example
In a VPCN, tenant has several subnets for different application or
service, gateways work for the inter-subnet traffics. Some network
services (i.e., NAT, FW, etc) may be needed to work together with
gateways. If the VPCN provides services to internet, or needs to
access to internet, the internet gateway is needed to support this.
The VPCN can also have the VPN gateway for interconnecting tenant's
branch sites or other VPCNs through VPN connections.
In addition to the VPCN, a complete NaaS system consists of other
components. They involve different aspects of NaaS system, i.e.,
data plane, control plane, management plane. This draft provides an
high-level overview architecture of NaaS system, and describes how
every component of it works together from different aspects of NaaS
system.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
1.2. Terminology
To be added.
Liu, et al [Page 4]
Internet-Draft NVO3 NaaS Architecture June, 2014
2. Overview
For better understanding what influence NaaS may introduce into
current network technologies, this section gives a brief summary of
new features and main challenges introduced by NaaS.
2.1. New Features
NaaS introduces a lot of new features to current network for
consideration; most of them are listed below:
o Network virtualization: NaaS must support Multi-tenancy
requirement. And it should hide the implementation details of the
network infrastructure;
o Close integration with virtual IT resources (compute, storage):
NaaS must have the capabilities of VM auto-discovery, integrated
operation/provision together with IT resources;
o Elasticity/High Availability: NaaS must have the capabilities of
on-demand bandwidth allocation, dynamic link/network creation,
dynamic and geographically distributed pools of shared ICT
resources, etc;
o Flexible service chain: Flexible interposition of various middle
boxes in the NaaS network becomes an essential and valuable
requirement for it and an IETF WG (SFC: Service Function Chaining)
has been created to study and resolve the series of requirements;
o SDN paradigm: SDN is optional paradigm, but provides great
flexibility and efficiency in network resource management,
optimized path selection for DC interconnection;
o Automation: This feature should be achieved in many aspects for
saving manual labor, which includes automatic collection of the
network topology information, policy auto distribution, OAM, auto
recovery, etc;
o Open interface to user: Making virtual network resource can be
managed by user themselves. For simplifying the operation, this
interface should provide network resource
abstraction/presentation, comprehensive service template, etc.
Liu, et al [Page 5]
Internet-Draft NVO3 NaaS Architecture June, 2014
2.2. Main Challenges
Despite the above features introduced by NaaS, a series of
challenges also appear in front of the implementation, as listed
below:
o Constraints of physical DC: Traditional network technologies such
as vlan, broadcast domain, acl, firewall setting, etc, have put
so much constraints because of their location dependent feature;
o Distributed subnet: One L3 subnet can span across the whole DC by
virtualization technology. Hosts in a L3 subnet are no longer
limited in one location. This kind of distributed subnet scenario
brings new challenges of hosts' unified identification and access
control;
o Programmable network: SDN paradigm needs to define information
model and data model used by the related interfaces, and the
information mapping between overlay and underlay network;
o On-demand and flexible service chain: It means dynamic service
awareness and automatic service provision;
o End to end connection provision: How to provide the End to end
VPN service to users when the wan/man network and DC network are
separated? How to integrate enterprise's current infrastructure
and NaaS in cloud seamlessly and securely? How to guarantee the
End to end SLA, including bandwidth, latency, etc?
o Backwards compatibility and smooth migration;
o Security related issue;
3. NaaS Architecture
A complete and high-level architecture of NaaS system is shown in
Figure 2 followed:
+-----+ +-----+ +-----+ +-----+
| NMS | | APP | | APP | | APP |
+--A--+ +--A--+ +--A--+ +--A--+
| | | |
| +-------V---------V---------V-------+
| | Orchestrator |
+------> |
| +-----------------A-----------------+
Liu, et al [Page 6]
Internet-Draft NVO3 NaaS Architecture June, 2014
| +---------------+---------------+
| | | |
| +-----V----+ +-----V----+ +-----V----+
| |Controller| |Controller| |Controller|
+--> | | | | |
| +------A---+ +-----A----+ +-----A----+
| | | |
| | | |
| +---V----+ +---V----+ +----V---+
+----->physical| |vswitch | |vswitch |
|switch | | | | |
+-+----+-+ +-+----+-+ ++-----+-+
| | | | | |
| | | | | |
+-++ +-++ +-++ +-++ ++-+ +-++
|TS| |SN| |TS| |TS| |TS| |SN|
+--+ +--+ +--+ +--+ +--+ +--+
Figure 2: NaaS Architecture
In the above architecture, a NaaS system can divide into 4 layers:
o Application layer This layer consists of application (APP) and/or
network management system (NMS). Applications having the
visibility to network resource is beneficial for them to use
network resource better. Various standard interfaces can be used
among applications and orchestrator, i.e., Restful API, Java,
JSON, netconf, etc. NMS is used for the management or
configuration of the network devices (i.e., physical/virtual
switch), policies in controller, etc. NMS is an independent
system which can communicate and manage objects of every layers;
o Orchestrator layer: This layer is mainly used for integrating all
the resource (i.e., computing, store, network, etc) and
controlling them in centralized way. By providing standard
interface in northbound and southbound, it can support different
types of controller and hide the difference from application
layer;
Liu, et al [Page 7]
Internet-Draft NVO3 NaaS Architecture June, 2014
o Controller layer: The core layer for the NaaS system. It is
responsible for transforming service requests from application
layer into forwarding information (e.g., flow table) in the
network devices. It collects network states, status and warnings
from network devices and synthesizes them for the path
computation. It can distribute various policies (i.e., ACL, QoS,
access control, etc) to network devices. Controller can be the
centralized or distributed system. It uses standard protocols
(i.e., Openflow, Netconf, I2RS [I-D.ietf-i2rs-architecture], BGP-
LS [I-D.ietf-idr-ls-distribution], etc) to communicate with
network devices;
o Network layer: This layer consists of all the network devices for
switching traffic, also all the tenant systems (TS) and service
nodes (SN: i.e., FW, NAT, etc). The network devices and service
nodes receive the forwarding information and policies from
controller layer and process the traffic in data plane
accordingly.
Four layers of component work together through standard interfaces
and protocols among them, form a complete and high-level
architecture of NaaS system.
In the following sections, NaaS system is described in details from
different aspects.
4. Data Plane of NaaS System
In data plane, NaaS system is mainly related to the network layer.
Depending on the network scalability and traffic throughput of it,
the provision of network layer can have two models: centralized NaaS
network and distributed NaaS network.
4.1. Centralized NaaS Network
Main characteristic of centralized NaaS network is the centralized
gateway and related service nodes normally located at the core or
aggregation layer of network. This deployment model is more suitable
for small/middle scale network. Most tenant systems are in the layer
2 network, traffic among them is switched locally. Other types of
traffic (i.e., inter network traffic, internet traffic, VPN traffic,
etc) among a small part of tenant systems need to traverse the
centralized gateway and related services nodes to get the unified
process.
Liu, et al [Page 8]
Internet-Draft NVO3 NaaS Architecture June, 2014
4.2. Distributed NaaS Network
Being opposite to centralized NaaS network, distributed NaaS network
requires multiple gateways and related service nodes can be
distributed in different places of network. This helps to improve
the overall network performance and avoid the single point of
failure. This deployment model is more suitable for large scale
network. Most of the inter network traffic is processed locally in
the distributed gateway and related service nodes.
4.3. Comparison
To be added.
5. Control Plane of NaaS Network
To be added.
6. Management Plane of NaaS Network
To be added.
7. Security Considerations
TBD.
8. Acknowledgements
9. IANA Considerations
The document does not require any IANA action.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
10.2. Informative References
[I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward,
D., and T.Nadeau, "An Architecture for the Interface to the Routing
System", (work in progress), February 2014
Liu, et al [Page 9]
Internet-Draft NVO3 NaaS Architecture June, 2014
[I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S.,
Farrel, A., and S.Ray, "North-Bound Distribution of Link-State and
TE Information using BGP", (work in progress), November 2013.
Authors' Addresses
Vic Liu
China Mobile
32 Xuanwumen West Ave, Beijing, China
Email: liuzhiheng@chinamobile.com
Liang Xia
Huawei Technologies
Email: frank.xialiang@huawei.com
Zu Qiang
Ericsson
8400, boul. Decarie
Ville Mont-Royal, QC,
Canada
Email: Zu.Qiang@Ericsson.com
Liu, et al [Page 10]