Internet DRAFT - draft-cao-sfc-control-orchestration
draft-cao-sfc-control-orchestration
Internet Engineering Task Force Z. Cao
Internet-Draft H. Deng
Intended status: Experimental China Mobile
Expires: August 18, 2014 February 14, 2014
Service Function Controller/Orchestration Requirements and Templates
draft-cao-sfc-control-orchestration-00
Abstract
Service Function Chain architecture further enables the modularity of
network functions; network service functions can be split and chained
together to compose complicated services. Network automation relies
on a specific orchestrator to automatically deploy an end2end service
or application. If this end2end service or application has a
specific requirement to chaining several service functions, there is
a need of an interface from the application to inform the
orchestrator. This document investigates the problem.
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 August 18, 2014.
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
Cao & Deng Expires August 18, 2014 [Page 1]
Internet-Draft SFC-Orchestration February 2014
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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SFC Orchestration Framework . . . . . . . . . . . . . . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Orchestration Templates including SFC Information . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Motivation
Service function chaining is a broad term used to describe a common
model for delivering multiple service functions in a specific order.
Service function chaining de-couples service delivery from the
underlying network topology and creates a dynamic services plane that
addresses the requirements of cloud and virtual application delivery.
Packets and/or flows that require services to be applied are
classified and redirected to the appropriate service functions.
Additionally, context can be shared between the network and the
services. Service function chaining has also been discussed in other
forums e.g. ETSI and 3GPP, and the ETSI NFV group is discussing
service function chaining as part of network function virtualization.
Service Function Chain architecture further enables the modularity of
network functions; network service functions can be split and chained
together to compose complicated services. Network automation relies
on a specific orchestrator to automatically deploy an end2end service
or application. If this end2end service or application has a
specific requirement to chaining several service functions, there is
a need of an interface from the application to inform the
orchestrator.
Orchestrator is an important function within the cloud management
system and Network Function Virtualization (NFV) system [Heat][Cfn].
End-to-end service utilizes the NFV orchestrator to map the VNFs to
the virtualization infrastructure, instantiating VNFs at appropriate
locations to realize the intended service, allocating and scaling
hardware resources to VNFs.
Cao & Deng Expires August 18, 2014 [Page 2]
Internet-Draft SFC-Orchestration February 2014
Establishing the VNF forwarding paths (forwarding path is service
function chain) is also the task of the orchestrator. This document
discusses the orchestration requirement and template examples.
2. Terminology
NF (Network Function): A functional building block within an
operator's network infrastructure, which has well-defined external
interfaces and a well-defined functional behaviour. Note that the
totality of all network functions constitutes the entire network and
services infrastructure of an operator/service provider. In
practical terms, a Network Function is today often a network node or
physical appliance. [Quoted from ETSI NFV]
Virtualised Network Function (VNF): An implementation of an
executable software program that constitutes the whole or a part of
an NF that can be deployed on a virtualisation infrastructure.
Service Classifier: A component that performs traffic classification.
Classification is the precursor to the start of a service chaining
path. Meta-data could assist traffic classification. Service
classification is different from DPI component where only service
related information in packets is retrieved and classified.
3. SFC Orchestration Framework
The following figure is the architecture of NFV.
Cao & Deng Expires August 18, 2014 [Page 3]
Internet-Draft SFC-Orchestration February 2014
+---------------------+
| NFV-MANO |
+-----------+ | +------------+ |
| OSS/BSS +-----------+----|Orchestrator| |
+-----+-----+ | +------+-----+ |
| | | |
| | +------+-----+ |
+-----------+ | | | |
| E/NMS |-----------+----+ | |
+-----------+ | | | |
| | | VNFM | |
| | | | |
+-----+-----+ | | | |
| VNF |-----------+----+ | |
+-----------+ | | | |
| | +------+-----+ |
| | | |
+-----+-----+ | +------+-----+ |
| NFVI |-----------+----| VIM | |
+-----------+ | +------------+ |
+---------------------+
NFV Architecture
The NFV-MANO consists of Orchestrator, VNFM(VNF Manager) and VIM
(Virtual Infrastructure Manager). VNFM is the component to interact
with the VNFs, and VIM is the to manage the NFV Infrastructure
(NFVI), including computing, storage and NETWORKING.
Figure 1 is the service function chain orchestration architecture.
In this architecture, Application Deployer is the entity or
administrator to deploy a specific end-to-end network system. For
example, it can be a Mobile Operator to deploy a virtualized packet
core system with Gi-LAN services [I-D.liu-sfc-use-cases]. In the
network auto deployment, the Application Deployer specifies the
requirements of the Service Functions (certain vNF) and their
forwarding paths (chaining relations). Thereafter, the Orchestrator
informs the VNFM and VIM to instantiate SFs and Infrastructure Nodes
respectively.
Note: the VNFM and VIM will interact with the SFC Controller Node in
SFC Architecture [I-D.quinn-sfc-arch], or the VIM or VNFM will take
the job of SFC Controller Node themselves.
Cao & Deng Expires August 18, 2014 [Page 4]
Internet-Draft SFC-Orchestration February 2014
+------------------+
| Application |
| Deployer |
+------------------+
||| +--------------------------------+
+---------------------+ | +-----+ |
| NFV-MANO | | +-----+ / | SF2 |\ +-----+ |
| +------------+ | | | SF1 | +-----+ \_| SF3 | |
+ |Orchestrator| | | +-----+ +--+--+ |
| +------+-----+ | | | \__+-----+ / | |
| | | | | | SF4 |--/ | |
| +------+-----+ | | | +--+--+ | |
| | VNFM | |====>| | | | |
+ + | | | (~~~~~~~~~~~~~~~~~~~~~~~~) |
| +------+-----+ | | / \ |
| | | | + Infrastructure +|
| +------+-----+ | | \ / |
| | VIM | | | (_________________________) |
| +------------+ | | |
+---------------------+ +--------------------------------+
Figure 1: SFC Orchestration
4. Requirements
The requirements of SFC Orchestration Templates are listed as below.
1. RESTful Style API. This is the common practice in both AWS
Cloudformation and Openstack Heat.
2. Components of the SFC Orchestration.
A. Template Version: version number and time
B. Template Description: text description of the template.
C. Parameters: necessary parameters of SF, e.g., username and
password of Database node, or SSH access account information.
D. Mapping Information: Mapping of the vNF/SF to the
infrastructure nodes, and it will contain the memory,
storage, network information.
E. Resources: containing the Elasticity, Properties, Security
Group information.
3. Chaining information.
Cao & Deng Expires August 18, 2014 [Page 5]
Internet-Draft SFC-Orchestration February 2014
A. Chaining Identity.
B. Chain name.
C. Forwarding Context: the matching criteria of of this chain.
D. Next Hop Context: the information information of the next SF
on the chain.
5. Orchestration Templates including SFC Information
According to the discussion in the previous section, an example of
the SFC orchestration template can be depicted as below:
{
"SFCTemplateFormatVersion" : "2014-02-12",
"Description" : "This template installs a singe instance deployment for video
traffic optimization. It also specifies the chaining information for this instance",
"Parameters" : {
"KeyName": {
"Description" : "Name of an existing KeyPair to enable SSH access to the instances",
"Type": "String",
"MinLength": "1",
"MaxLength": "255",
"AllowedPattern" : "[\\x20-\\x7E]*",
"ConstraintDescription" : "can contain only ASCII characters."
},
"SSHLocation" : {
"Description" : "The IP address range that can be used to SSH to the VM instances",
"Type": "String",
"MinLength": "9",
"MaxLength": "18",
"Default": "0.0.0.0/0",
"AllowedPattern": "(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})\\.(\\d{1,3})/(\\d{1,2})",
"ConstraintDescription": "must be a valid IP CIDR range of the form x.x.x.x/x."
}
}
"Mappings" : {
"CloudOSInstanceType2Arch" : {
"t1.micro" : { "Arch" : "64" },
"m1.small" : { "Arch" : "64" },
"m2.xlarge" : { "Arch" : "64" },
"m3.xlarge" : { "Arch" : "64" },
Cao & Deng Expires August 18, 2014 [Page 6]
Internet-Draft SFC-Orchestration February 2014
"c1.medium" : { "Arch" : "64" },
},
% The following information informs that this SF engages in a video acceleration chain
% indexed with ID "0X7516AB", and was instructed to forward packets with
% Destination IP ==20.20.20.1, Port=XXXX to the next SF on the chain
% with node ID == "0x abcdabcdabcdabcd" AND IP addr == "12.34.56.78"
"ChainInstance" :{
"ChainID": "0X7516AB",
"Description": "Video Acceleration",
"ProtocolType": "8080",
"ForwardingContext":"DIP==20.20.20.1, Port=XXXX",
"NextHopNodeUUID": "0X abcdabcdabcdabcd",
"NextHopIP": "12.34.56.78",
}
}
"Resources": {}
"Outputs": {}
}
6. IANA Considerations
To be analyzed.
7. Security Considerations
To be analyzed.
8. References
8.1. Normative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
8.2. Informative References
[Cfn] "AWS CloudFormation,
http://aws.amazon.com/cloudformation/", .
[Heat] "OpenStack Orchestration, https://wiki.openstack.org/wiki/
Heat.", .
Cao & Deng Expires August 18, 2014 [Page 7]
Internet-Draft SFC-Orchestration February 2014
[I-D.liu-sfc-use-cases]
Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N.,
Cao, Z., Hu, J., and C. Pham, "Service Function Chaining
(SFC) Use Cases", draft-liu-sfc-use-cases-02 (work in
progress), February 2014.
[I-D.quinn-sfc-arch]
Quinn, P. and A. Beliveau, "Service Function Chaining
(SFC) Architecture", draft-quinn-sfc-arch-04 (work in
progress), January 2014.
[I-D.quinn-sfc-nsh]
Quinn, P., Guichard, J., Fernando, R., Surendra, S.,
Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A.,
McConnell, B., and C. Wright, "Network Service Header",
draft-quinn-sfc-nsh-01 (work in progress), February 2014.
[NFVE2E] "Network Functions Virtualisation: End to End
Architecture, http://docbox.etsi.org/ISG/NFV/70-DRAFT/0010
/NFV-0010v016.zip", .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
Authors' Addresses
Zhen Cao
China Mobile
Xuanwumenxi Ave. No. 32
Beijing 100053
China
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Cao & Deng Expires August 18, 2014 [Page 8]
Internet-Draft SFC-Orchestration February 2014
Hui Deng
China Mobile
Xuanwumenxi Ave. No. 32
Beijing 100053
China
Email: denghui@chinamobile.com
Cao & Deng Expires August 18, 2014 [Page 9]
