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 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 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
• 2. Conventions used in this document
• 3. SFC Control Plane Overview
• 4. Signaling procedure
• 4.1. Building Service Topology
• 4.2. Service Function Discovery
• 4.3. Service Function Map Selection
• 4.4. Building Service Function Chaining (SFC) Policy Tables
• 4.5. Service Function Chaining Path Setup and Policy configuration
• 4.6. Service Availability
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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.

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].

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.

• 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.
• 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.
• 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.

                           +-------------+
     +---------------------|             |
     | (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 |     +------------+
                     +---------+      +---------+

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

• 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 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 "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

• PDP
• or NFVPool Manager
• 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.

                                                  
                                                  
                                       ^          ^
                                       |          |
                                    +--|----------|--+             
                 ___________________|__|          |  | 
                |                   |             |  |
        +--------+   Heartbeat      |             |  |
        | vFW    |----------------->|    vSwitch  |  |
        +--------+                  |   (SF Node) |  |
                | __________________|__           |  |        
                      Fail          |  |          |  |
                                    +--|----------|--+
                                       |          |
                                       |          |
                                       |          | 
                                 Security       Failure
                                 Detection ---->
                                 Process        Bypass

                  Figure 4 Heartbeat Monitoring Process

5. Security Considerations

TBD

6. Acknowledgements

The author would like to thank LAC Chidung for his review and comments that help improvement to this document.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses