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]