Service Function Chain Control Plane Overview
draft-wang-msv-using-virtual-line-card-01
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Wang Danhua , Qin Wu , XianGuo Zhang , Mohamed Boucadair | ||
| Last updated | 2014-02-13 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| 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-wang-msv-using-virtual-line-card-01
Network Working Group D. Wang
Internet-Draft Q. Wu
Intended status: Standards Track X. Zhang
Expires: August 17, 2014 Huawei
M. Boucadair
C. Boucadair
France Telecom
February 13, 2014
Service Function Chain Control Plane Overview
draft-wang-msv-using-virtual-line-card-01
Abstract
As described in [I.D-boucadair-sfc-framework], the dynamic
enforcement of a Service-derived, adequate forwarding policy for
packets entering a network that supports such advanced Service
Functions has become a key challenge for operators and service
providers.
This document is based on [I.D-boucadair-sfc-framework] and focusing
on discussing how the Service Functions are discovered and
provisioned and how Service Function Chaining path is setup.
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 17, 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
Wang, et al. Expires August 17, 2014 [Page 1]
Internet-Draft SFC CP February 2014
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. SFC Control Plane Overview . . . . . . . . . . . . . . . . . . 5
4. Signaling procedure . . . . . . . . . . . . . . . . . . . . . 7
4.1. Building Service Topology . . . . . . . . . . . . . . . . 7
4.2. Service Function Discovery . . . . . . . . . . . . . . . . 7
4.3. Service Function Map Selection . . . . . . . . . . . . . . 8
4.4. Building Service Function Chaining (SFC) Policy Tables . . 8
4.5. Service Function Chaining Path Setup and Policy
configuration . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Service Availability . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Wang, et al. Expires August 17, 2014 [Page 2]
Internet-Draft SFC CP February 2014
1. Introduction
Service Function Chaining(SFC) refers to the delivery of added value
services by invoking, in a given order, a set of Service Functions
along the forwarding path towards a specific destination [I.D-quinn-
sfc-problem-statement]. Service functions involved in a given SFC
may include advanced Service Functions such as load-balancing,
firewalling, intrusion prevention. A given SFC domain may involve
several instances of the same Service Functions. Service Function
instances can be automatically added or removed to an SFC. Service
functions can be co-located on the same physical node or be embedded
in distinct physical nodes.
As described in [I.D-boucadair-sfc-framework], the dynamic
enforcement of a SF-derived, adequate forwarding policy for packets
entering a network that supports such advanced Service Functions has
become a key challenge for operators and service providers.
This document is based on [I.D-boucadair-sfc-framework]and is
focusing on discussing how the set of available Service Functions
(including several instances of the same Service Function) are
discovered and provisioned and how Service Function Chaining path is
setup.
Wang, et al. Expires August 17, 2014 [Page 3]
Internet-Draft SFC CP February 2014
2. 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 RFC2119 [RFC2119].
MSV: Multi-service Virtualization
pSlot: Physical Slot
vSlot: Virtual Slot
Slot ID: Identity number of Slot
Wang, et al. Expires August 17, 2014 [Page 4]
Internet-Draft SFC CP February 2014
3. SFC Control Plane Overview
The Service Function Chain Control plane Overview proposed in this
document includes a topology server, policy decision point(PDP), and
service Function(SF) Nodes, SFC Ingress Node, SFC Egress Node.
Service functions can be co-located on one SF Node or physically
separated across several SF Nodes with each having one or more
Service Functions. The Topology server(Topo Server for short) is
used to locate SF Nodes in the network as needed. The PDP is a
central control/management plane entity and used to maintain SFC
Policy Tables defined in figure 1 of [I.D- boucadair-sfc-framework],
and generating and communicating appropriate policies in SF Nodes and
SFC Ingress/Egress Nodes. To create SF map in the SFC Policy tables,
PDP may interact with the Topo Server using SF node discovery
protocol to build SF maps. To communicate policies in SF nodes,
either fully centralized approach, or half centralized approach or
distributed approach can be used.
o In the fully centralized approach, I2RS signaling can be used
between PDP and SF Node or between PDP and SF Ingress/Egress Node.
o In the distributed approach, SFC Ingress Node makes a path
computation request to the Topo server. The Topo server returns
computed path in the Explicit Route Object in the response. SFC
Ingress Node then can use RSVP-TE to initiate signaling and
communicate policy with each SF Node and establish the service
Function Chaining path.
o In the half centralized approach, SFC Ingress Node interacts with
the Topo server and retrieves the path computation results and
then use RSVP-TE to populate the Path profile Identifier in each
SF node. Then each SF node can use Path Profile Identifier to
request PDP for SF path profile.
Wang, et al. Expires August 17, 2014 [Page 5]
Internet-Draft SFC CP February 2014
+-------------+
+---------------------| |
| (e.g.,PCEP, ALTO..) | Topo Server |
| +------------------| |
| | +----A--------+
| | | |
| | | |(e.g.,PCEP, ALTO..)
| | Netconf.. +----|-----V--+
| | +--------------> PDP <------------------+
| | | | <---+ |
| | | +-A-----------+ | |
| | | | | |
| | | | | |
| | | RSVP-TE.. | | |
+-V--V---V--+ +-------V-+ +------V--+ +-----V------+
|SFC Ingress| | SF | | SF | | SFC Egress |
| Node |---->| Node1 |----->| Node2 |---->| Node |
| |<----| |<---- | |<----| |
+-----------+ | SF1 SF2 | | SF3 SF4 | +------------+
+---------+ +---------+
Wang, et al. Expires August 17, 2014 [Page 6]
Internet-Draft SFC CP February 2014
4. Signaling procedure
4.1. Building Service Topology
Network topology information can be collected from network by using
IGP or BGP-LS [I.D-draft-idr-ls-distribution].
Not all SF Nodes can be directly connected. The Service overlay
creates a forwarding path between SF Nodes or connected graph for
these SF Nodes. SF nodes can be co-located on the same physical node
or be embedded in distinct physical nodes. A service specific
overlay utilized by SFC creates the service topology. Service
topology information includes SF Identifier, SF Locator, Service
Function administration information (Packet rate
utilization,Bandwidth utilization per CoS,Packet rate utilization per
Cos,Memory utilization, RIB utilization per address family, FIB
utilization per address family,,available memory,CPU
utilization,Available storage)or Service Function capability
information(e.g.,supported ACLnumbers, virtual context
number,supported-packet-rate) Service topology information can be
collected by the Topo server using either I2RS interface or routing
protocol. The Topo Server can be collocated with PDP or physically
separated from the entity that supports the PDP.
Within the service topology, an ordered set of SF nodes will be
invoked for each packet that belongs to a given flow for which a SFC
will be applied. Adding new Service Functions to SF Node in the
Service topology is easily accomplished, and no underlying network
changes are required. Furthermore, additional service Functions or
Service Function instances, for redundancy or load distribution
purpose, can be added or removed to the service topology as required.
4.2. Service Function Discovery
When service topology is created by a service-specific overlay
utilized by Service Function Chaining, each Service Function type is
assigned with a unique SF identifier and can be located using SF
locator. There are two approaches for Service Function Discovery
o PDP initiated Service Function Discovery
* Upon receiving service request, PDP send path computation
request to Topo server.
o SFC Ingress Node Initiated Service Function Discovery
Wang, et al. Expires August 17, 2014 [Page 7]
Internet-Draft SFC CP February 2014
* Upon receiving service request, Headend router or SFC Ingress
Node send path computation request to Topo server.
The Service request carries various constraint information or
resource requirements(e.g., SF location constraint, SF order
constraint, SF capability information) The topo Server looks up
service topology information based on service request and returns
either computed path or path profile Identifier to the requestor. In
the centralized approach, the Topo server will return computed path
to the PDP. In the distributed approach, the Topo server Will return
computed path to the SF Ingress Node. In the half centralized
approach, the Topo server will only return path profile Identifier to
the SF Ingress Node.
4.3. Service Function Map Selection
In either PDP initiates Service Function Discovery or SF Ingress Node
Initiated Service Function Discovery, PDP will compose the Service
Function Map based on the returned computed path. If there are
multiple Service Functions or Service Function Instances can satisfy
service requirements, the PDP will select appropriate Service
Function based on Service Functions capability info or local policy
to build Service Function Map.
4.4. Building Service Function Chaining (SFC) Policy Tables
In case of SFC ingress node initiated Service Function Discovery, the
SFC ingress node retrieves path profile Identifier in the half
centralized approach and retrieves service Function Map and
associated Service Function Map index from the Topo server in the
distributed approach. The SFC ingress Node can create entries in the
Policy Table based on Service Function Map obtained from the Topo
server.
In case of PDP initiated Service Function Discovery, the PDP retrieve
computed path information from topo server and compose service
Function Map based on computed path information and create entries in
the Policy Table .
4.5. Service Function Chaining Path Setup and Policy configuration
In case of SFC ingress node initiated Service Function Discovery, SFC
ingress node initiate signaling to establish the service chaining
path. Path Profile ID can be carried in the RSVP-TE message and
populated to each SF Node in the Service Function Chain. When each
SF node receives Path Profile ID, it will pull policy table based on
Path Profile ID from PDP.
Wang, et al. Expires August 17, 2014 [Page 8]
Internet-Draft SFC CP February 2014
In case of PDP initiated Service Function Discovery, PDP will use
I2RS interface and communicate policy with each SF node in the
Service Function Chain. A set of policy templates can be pre-
defined, as shown in Figure 3. By applying policy template,
different service chains are pre- provisioned and provided to users.
For example, the "DATA_SEC" template defined in Figure 3 implies you
can choose random combinations of these services provided in the
"Service-chain" list.
Policy Template Service-chain list
DLP
DATA_SEC AV
IPS
DPI
SIP
Figure 3 Policy Template
4.6. Service Availability
In order to check service Function availability for each SF node, the
control channel should be setup between service function and
monitoring system to keep track of state change or performance issue.
The monitoring system can be either collocated with
o PDP
o or NFVPool Manager
o or vswitch as SF node or overlay node in the service overlay.
When one service Function is not a mandatory service function(e.g.,
HTTP optimization service function) in the Service Function Chain and
break down, this service function can be bypassed from service
Function chain, the service will not be interrupted since other
service functions still work well, but service provided by service
function chain is in the degraded mode. When the service function is
a mandatory service function (e.g., firewall) in the Service Function
Chain and break down, the service will be interrupted before this
service function recovers from failing.
Wang, et al. Expires August 17, 2014 [Page 9]
Internet-Draft SFC CP February 2014
^ ^
| |
+--|----------|--+
___________________|__| | |
| | | |
+--------+ Heartbeat | | |
| vFW |----------------->| vSwitch | |
+--------+ | (SF Node) | |
| __________________|__ | |
Fail | | | |
+--|----------|--+
| |
| |
| |
Security Failure
Detection ---->
Process Bypass
Figure 4 Heartbeat Monitoring Process
Wang, et al. Expires August 17, 2014 [Page 10]
Internet-Draft SFC CP February 2014
5. Security Considerations
TBD
Wang, et al. Expires August 17, 2014 [Page 11]
Internet-Draft SFC CP February 2014
6. Acknowledgements
The author would like to thank LAC Chidung for his review and
comments that help improvement to this document.
Wang, et al. Expires August 17, 2014 [Page 12]
Internet-Draft SFC CP February 2014
7. References
7.1. Normative References
[I.D-boucadair-sfc-framework]
Boucadair, M., "Service Function Chaining: Framework &
Architecture", ID draft-boucadair-sfc-framework-00,
October 2013.
[I.D-quinn-sfc-problem-statement]
Quinn, P., "Network Service Chaining Problem Statement",
ID draft-quinn-nsc-problem-statement-03, August 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
7.2. Informative References
[ALTO] Yang, Y., "ALTO Protocol",
ID http://tools.ietf.org/html/draft-ietf-alto-protocol-16,
May 2013.
[RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based
Architecture", RFC 4655, August 2006.
Wang, et al. Expires August 17, 2014 [Page 13]
Internet-Draft SFC CP February 2014
Authors' Addresses
Danhua Wang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangdanhua@huawei.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
XianGuo Zhang
Huawei
Beijing, 100085
China
Email: zhangxianguo09@huawei.com
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
France Telecom
Rennes 35000
France
Email: christian.jacquenet@orange.com
Wang, et al. Expires August 17, 2014 [Page 14]