Internet DRAFT - draft-wang-msv-using-virtual-line-card
draft-wang-msv-using-virtual-line-card
Network Working Group Q. Wu
Internet-Draft D. Wang
Intended status: Standards Track Huawei
Expires: August 18, 2014 M. Boucadair
C. Boucadair
France Telecom
X. Zhang
Y. Shi
Huawei
February 14, 2014
Service Function Chain Control Plane Overview
draft-wang-msv-using-virtual-line-card-02
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 18, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wu, et al. Expires August 18, 2014 [Page 1]
Internet-Draft SFC CP 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. 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
Wu, et al. Expires August 18, 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.
Wu, et al. Expires August 18, 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].
Wu, et al. Expires August 18, 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, Communication between PDP and
Topo Server can be used to return computed path information .
I2RS signaling can be used communicate policy between PDP and SF
Node or between PDP and SF Ingress/Egress Node.
o In the distributed approach, The Topo server communicate with SFC
Ingress Node and returns computed path in the Explicit Route
Object in the response [I.D-wu-pce-traffic-steering-sfc]. 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, The Topo server communicate with
SFC Ingress Node and return the path computation results to SFC
Ingress Node and then SFC Ingress Node uses RSVP-TE to populate
the Path profile Identifier in each SF node [I.D-wu-pce-traffic-
steering-sfc]. Then each SF node can use Path Profile Identifier
to request PDP for SF path profile.
Wu, et al. Expires August 18, 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 | +------------+
+---------+ +---------+
Wu, et al. Expires August 18, 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 one approache for Service Function Discovery
o PDP initiated Service Function Discovery
* Upon receiving service request, PDP 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
Wu, et al. Expires August 18, 2014 [Page 7]
Internet-Draft SFC CP February 2014
service topology information and returns either computed path or path
profile Identifier to the PDP. In the centralized approach, the Topo
server will return computed path to the PDP. In the distributed
approach, the Topo server will send 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.
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
Wu, et al. Expires August 18, 2014 [Page 8]
Internet-Draft SFC CP February 2014
"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.
Wu, et al. Expires August 18, 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
Wu, et al. Expires August 18, 2014 [Page 10]
Internet-Draft SFC CP February 2014
5. Security Considerations
TBD
Wu, et al. Expires August 18, 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.
Wu, et al. Expires August 18, 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.
[I.D-wu-pce-traffic-steering-sfc]
Wu, Q., Dhody, D., Boucadair, M., Boucadair, C., and J.
Tantsura, "PCEP Extensions for traffic steering support in
Service Function Chaining",
ID draft-wu-pce-traffic-steering-sfc-02, Feburary 2014.
[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.
Wu, et al. Expires August 18, 2014 [Page 13]
Internet-Draft SFC CP February 2014
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Danhua Wang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangdanhua@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
XianGuo Zhang
Huawei
Beijing, 100085
China
Email: zhangxianguo09@huawei.com
Wu, et al. Expires August 18, 2014 [Page 14]
Internet-Draft SFC CP February 2014
Yang Shi
Huawei
Beijing, 100085
China
Email: shiyang1@huawei.com
Wu, et al. Expires August 18, 2014 [Page 15]
