Network as a Service Architecture
draft-liu-nvo3-naas-arch-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Vic Liu , Liang Xia | ||
| Last updated | 2014-02-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-nvo3-naas-arch-00
Network working group Vic Liu
Internet Draft China Mobile
Category: Standard Track L. Xia
Huawei
Expires: September, 2014 February 14, 2014
Network as a Service Architecture
draft-liu-nvo3-naas-arch-00
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 September 14, 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 February, 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. NaaS Architecture ........................................... 5
3. Data Plane of NaaS System ................................... 6
3.1. Centralized NaaS Network ............................... 6
3.2. Distributed NaaS Network ............................... 7
3.3. Comparison ............................................. 7
4. Control Plane of NaaS Network ............................... 7
5. Management Plane of NaaS Network ............................ 7
6. Security Considerations ..................................... 7
7. Acknowledgements ............................................ 7
8. IANA Considerations ......................................... 7
9. References .................................................. 7
9.1. Normative References ................................... 7
9.2. Informative References ................................. 8
Liu, et al [Page 2]
Internet-Draft NVO3 NaaS Architecture February, 2014
1. Introduction
Network as a Service (NaaS) is a new network business model provided
by more and more operators. 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 VPC:
.............................
. ...... .
. .... .... .
. . +-----+ . .
.. +-+ TS | . .
.. | +---+-+ . .
...... . . +-----+ . .
... ... . ....subnet.... .
.. . . ...... .
. Internet . . | .
.. . . | .
... ... . +---+--+ .
...... . | VPN | .
| . | GW | branch site .
| . +--+---+ or other VPCN.
| .........|...................
| |VPN connection
+---+----+ +---+---+
................|Internet|.........| VPN |...............
. ........ | GW | | GW | .
. .+---+ . +---+----+ +---+---+ ........ .
. .|NAT| . | | .+---+ . .
Liu, et al [Page 3]
Internet-Draft NVO3 NaaS Architecture February, 2014
. .+---+ . +------------------+ .|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 February, 2014
2. 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-----------------+
| +---------------+---------------+
| | | |
| +-----V----+ +-----V----+ +-----V----+
| |Controller| |Controller| |Controller|
+--> | | | | |
| +------A---+ +-----A----+ +-----A----+
| | | |
| | | |
| +---V----+ +---V----+ +----V---+
+----->physical| |vswitch | |vswitch |
|switch | | | | |
+-+----+-+ +-+----+-+ ++-----+-+
| | | | | |
| | | | | |
+-++ +-++ +-++ +-++ ++-+ +-++
|TS| |SN| |TS| |TS| |TS| |SN|
+--+ +--+ +--+ +--+ +--+ +--+
Figure 2: Architecture of NaaS system
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;
Liu, et al [Page 5]
Internet-Draft NVO3 NaaS Architecture February, 2014
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;
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.
3. 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.
3.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
Liu, et al [Page 6]
Internet-Draft NVO3 NaaS Architecture February, 2014
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.
3.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.
3.3. Comparison
To be added.
4. Control Plane of NaaS Network
To be added.
5. Management Plane of NaaS Network
To be added.
6. Security Considerations
TBD.
7. Acknowledgements
8. IANA Considerations
The document does not require any IANA action.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
Liu, et al [Page 7]
Internet-Draft NVO3 NaaS Architecture February, 2014
9.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
[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
Liu, et al [Page 8]