[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05

Network Work group                                              N. Kumar
Internet-Draft                                              C. Pignataro
Intended status: Standards Track                                P. Quinn
Expires: September 10, 2015                          Cisco Systems, Inc.
                                                           March 9, 2015


              IPFIX Information Element extension for SFC
                   draft-kumar-ipfix-sfc-extension-00

Abstract

   Service Function Chaining (SFC) is an architecture that enables any
   operator to apply selective set of services by steering the traffic
   through an ordered set of service functions without any topology
   dependency.

   This document defines the required Information Elements to represent
   the details about service flows over any Service Function Path.

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 September 10, 2015.

Copyright Notice

   Copyright (c) 2015 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



Kumar, et al.          Expires September 10, 2015               [Page 1]


Internet-Draft                                                March 2015


   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
   2.  Requirements notation . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Network Service Header  . . . . . . . . . . . . . . . . . . .   3
   5.  Flow measurement in SFC environment . . . . . . . . . . . . .   4
     5.1.  Observation Point . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Flow measurement  . . . . . . . . . . . . . . . . . . . .   5
   6.  Service Flow Information Elements . . . . . . . . . . . . . .   6
     6.1.  nshBaseVersion  . . . . . . . . . . . . . . . . . . . . .   6
     6.2.  nshBaseFlags  . . . . . . . . . . . . . . . . . . . . . .   6
     6.3.  nshBaseHeaderLength . . . . . . . . . . . . . . . . . . .   7
     6.4.  nshBaseMDType . . . . . . . . . . . . . . . . . . . . . .   7
     6.5.  nshBaseNextProtocol . . . . . . . . . . . . . . . . . . .   7
     6.6.  nshSphServicePathID . . . . . . . . . . . . . . . . . . .   8
     6.7.  nshSphServiceIndex  . . . . . . . . . . . . . . . . . . .   8
     6.8.  nshMetadataMch  . . . . . . . . . . . . . . . . . . . . .   9
     6.9.  nshMetadataVch  . . . . . . . . . . . . . . . . . . . . .   9
     6.10. nshIPv4NextSFF  . . . . . . . . . . . . . . . . . . . . .   9
     6.11. nshIPv6NextSFF  . . . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Contributing Authors  . . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   [I-D.ietf-sfc-architecture] introduces and explains SFC architecture
   that enables any operator to apply selective set of services by
   steering the traffic through an ordered set of service functions
   without any topology dependency.  Such ordered set of service
   functions to be applied to a packet is defined as service function
   chaining.  As defined in [I-D.quinn-sfc-nsh], a classifier will add
   Network Service Header (NSH) to a packet that defines the
   corresponding service path to follow.

   This document defines the required Information Elements to represent
   the details about traffic flows over any Service Function Path and
   export to Collector.



Kumar, et al.          Expires September 10, 2015               [Page 2]


Internet-Draft                                                March 2015


2.  Requirements notation

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

3.  Terminology

   This document uses the terminologies defined in
   [I-D.ietf-sfc-architecture] and [RFC7011].  In addition, this
   document defines the below terminologies:

   Service Flow

      A Service Flow is defined as a set of packets over a specific
      Service Function Path.

4.  Network Service Header

   Section 3.1 of [I-D.quinn-sfc-nsh] defines the Network Service Header
   format used by the classifier to encapsulate the traffic, carrying
   instruction about the service functions to be applied to the packet.
   This header comprises a 4 byte base header followed by a 4 byte
   service path header and a variable size context header.

   In order to accomodate different needs from different use cases,
   there are 2 types of Network Service Header defined in
   [I-D.quinn-sfc-nsh] that preserves same Base header and Service Path
   header while differs in Context header.  NSH MD-type 1 have a fixed
   size Mandatory Context header while NSH MD-type 2 have a variable
   size TLV based context header.  The details are below:




















Kumar, et al.          Expires September 10, 2015               [Page 3]


Internet-Draft                                                March 2015


        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver|O|C|R|R|R|R|R|R|   Length  |  MD-type=0x1  | Next Protocol |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Service Path ID                      | Service Index |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Mandatory Context Header                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Mandatory Context Header                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Mandatory Context Header                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Mandatory Context Header                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Figure 1: NSH MD-type 1



        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Ver|O|C|R|R|R|R|R|R|   Length  |  MD-type=0x2  | Next Protocol |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Service Path ID                      | Service Index |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~           Optional Variable Length Context Headers            ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Figure 2: NSH MD-type 2


   The details about different header fields are detailed in Section 3.4
   and 3.5 of [I-D.quinn-sfc-nsh].

5.  Flow measurement in SFC environment

   SFC introduces the concept of steering user traffic over an ordered
   set of service function by utilizing service overlay between service
   functions over the existing network topology.  The measurement of
   Service flow over Service Function Chain are required for various
   application such as but not limited to below:

   o  Capacity Planning - To ensure distributing load between Service
      Functions.





Kumar, et al.          Expires September 10, 2015               [Page 4]


Internet-Draft                                                March 2015


   o  OAM and troubleshooting - To measure the performance and
      troubleshooting failures.

   o  Traffic Profiling - Determine the characteristics of traffic flow
      over SFP.

   o  Security - To identify DoS attack or malicious intrusion.

   In SFC environment, Classifier and Service Function Forwarder (SFF)
   are the different nodes that handles SFC encapsulation and it is
   appropriate to collect the Service Flow records in these nodes.

5.1.  Observation Point

   An Observation point in SFC environment is where Flow record for
   Service Flow will be collected and exported to the Collector.  In a
   Classifier or SFF, an Observation point can be any physical or
   logical port that:

   o  Forwards NSH encapsulated packets or frame from Classifier to SFF.

   o  Receives NSH encapsulated packets or frame from Classifier or
      previous SFF.

   o  Receives NSH encapsulated packets or frame from Service Function
      after packet treatment applied.

   o  Forwards NSH encapsulated packets or frame to next Service
      Function Forwarder.

   o  Forwards NSH encapsulated packets or frame to Service Function for
      packet treatment.

5.2.  Flow measurement

   The ability to collect Flow record for different flows observed at
   the above range of Observation point allows an Operator to measure
   flow properties before and after the application of any service
   function within a service function path.  An implementation SHOULD
   support the use of Information Elements defined in section 6 to
   measure and export the flow information.  In addition, it also MAY
   support the use of other Flow keys relevant to the underlay network
   to collect any additional information from transport header
   encapsulating NSH header.







Kumar, et al.          Expires September 10, 2015               [Page 5]


Internet-Draft                                                March 2015


6.  Service Flow Information Elements

   This document defines the below set of Information Elements that are
   necessary for enabling IPFIX traffic measurement for Service Flow:


                  +---------+------------------------------------------+
                  |   ID    |                Name                      |
                  +---------+------------------------------------------+
                  |  TBD1   |  nshBaseVersion                          |
                  |  TBD2   |  nshBaseFlags                            |
                  |  TBD3   |  nshBaseHeaderLength                     |
                  |  TBD4   |  nshBaseMDType                           |
                  |  TBD5   |  nshBaseNextProtocol                     |
                  |  TBD6   |  nshSphServicePathID                     |
                  |  TBD7   |  nshSphServiceIndex                      |
                  |  TBD8   |  nshMetadataMch                          |
                  |  TBD9   |  nshMetadataVch                          |
                  |  TBD10  |  nshIPv4NextSFF                          |
                  |  TBD11  |  nshIPv6NextSFF                          |
                  +---------+------------------------------------------+


6.1.  nshBaseVersion

   Description:

      The Version field in NSH header.

   Abstract Data Type: unsigned8

   Element ID: TBD1

   Data Type Semantic: identifier

   Range: The valid range is 0-3.

   Reference:

      See Section 3.2 of [I-D.quinn-sfc-nsh]

6.2.  nshBaseFlags

   Description:

      The flag bits from bit position 2 to 9 in NSH Base header.  This
      information is encoded as a bit field.




Kumar, et al.          Expires September 10, 2015               [Page 6]


Internet-Draft                                                March 2015


   Abstract Data Type: unsigned8

   Element ID: TBD2

   Data Type Semantic: flags

   Reference:

      See Section 3.2 of [I-D.quinn-sfc-nsh]

6.3.  nshBaseHeaderLength

   Description:

      The length of the NSH header including any optional variable TLVs.

   Abstract Data Type: unsigned8

   Element ID: TBD3

   Range: The valid range is 0-255.

   Reference:

      See Section 3.2 of [I-D.quinn-sfc-nsh]

6.4.  nshBaseMDType

   Description:

      Defines the Metadata format beyond the NSH Base header.

   Abstract Data Type: unsigned8

   Element ID: TBD4

   Data Type Semantic: identifier

   Reference:

      See Section 3.2 of [I-D.quinn-sfc-nsh]

6.5.  nshBaseNextProtocol

   Description:

      This indicates the type of the payload packet encapsulated within
      the NSH header.



Kumar, et al.          Expires September 10, 2015               [Page 7]


Internet-Draft                                                March 2015


   Abstract Data Type: unsigned8

   Element ID: TBD5

   Data Type Semantic: identifier

   Reference:

      See Section 3.2 of [I-D.quinn-sfc-nsh]

6.6.  nshSphServicePathID

   Description:

      Service Path ID uniquely identifies the Service Chain which is a
      sequence of service function to be applied on the payload packet.

   Abstract Data Type: unsigned32

   Element ID: TBD6

   Data Type Semantic: identifier

   Reference:

      See Section 3.3 of [I-D.quinn-sfc-nsh]

6.7.  nshSphServiceIndex

   Description:

      Service Index identifies the next service function to be applied
      in the service chain.

   Abstract Data Type: unsigned8

   Element ID: TBD7

   Range : The valid range is between 0-255.

   Reference:

      See Section 3.3 of [I-D.quinn-sfc-nsh]








Kumar, et al.          Expires September 10, 2015               [Page 8]


Internet-Draft                                                March 2015


6.8.  nshMetadataMch

   Description:

      When MD Type is 1 on NSH header, Service Base header is followed
      by fixed size Mandatory Context Header.  The format of this header
      varies depending on the implementation.  This information element
      is of 16 bytes size.

   Abstract Data Type: OctetArray

   Element ID: TBD8

   Reference:

      See Section 3.4.1 of [I-D.quinn-sfc-nsh]

6.9.  nshMetadataVch

   Description:

      When MD Type is 2 on NSH header, Service Base header is followed
      by Variable size Context Header.  The format of this header varies
      depending on the implementation.  This Informational element
      carries n octets from the NSH Service Path header.

      A value of 64 reduced from nshBaseHeaderLength expresses how much
      Metadata was observed, while the remainder is padding.

   Abstract Data Type: OctetArray

   Element ID: TBD9

   Reference:

      See Section 3.5.1 of [I-D.quinn-sfc-nsh]

6.10.  nshIPv4NextSFF

   Description:

      This defines the IPv4 address of the next SFF in the Service
      Function Path.  This Information element is of size 4 bytes.

   Abstract Data Type: ipv4Address

   Element ID: TBD10




Kumar, et al.          Expires September 10, 2015               [Page 9]


Internet-Draft                                                March 2015


   Data Type Semantic: identifier

6.11.  nshIPv6NextSFF

   Description:

      This defines the IPv6 address of the next SFF in the Service
      Function Path.  This Information element is of size 16 bytes.

   Abstract Data Type: ipv6Address

   Element ID: TBD11

   Data Type Semantic: identifier

7.  IANA Considerations

   To be Updated.

8.  Security Considerations

   TBD

9.  Acknowledgement

   The authors would like to thank Jim Guichard, Stewart Bryant, Benoit
   Claise and Richard Furr for their contribution.

10.  Contributing Authors

   TBD

11.  References

11.1.  Normative References

   [I-D.quinn-sfc-nsh]
              Quinn, P., Guichard, J., Surendra, S., Smith, M.,
              Henderickx, W., Nadeau, T., Agarwal, P., Manur, R.,
              Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman,
              D., Garg, P., McConnell, B., Wright, C., and K. Kevin,
              "Network Service Header", draft-quinn-sfc-nsh-07 (work in
              progress), February 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.





Kumar, et al.          Expires September 10, 2015              [Page 10]


Internet-Draft                                                March 2015


   [RFC7011]  Claise, B., Trammell, B., and P. Aitken, "Specification of
              the IP Flow Information Export (IPFIX) Protocol for the
              Exchange of Flow Information", STD 77, RFC 7011, September
              2013.

11.2.  Informative References

   [I-D.ietf-sfc-architecture]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-ietf-sfc-architecture-07 (work
              in progress), March 2015.

   [RFC7012]  Claise, B. and B. Trammell, "Information Model for IP Flow
              Information Export (IPFIX)", RFC 7012, September 2013.

   [RFC7013]  Trammell, B. and B. Claise, "Guidelines for Authors and
              Reviewers of IP Flow Information Export (IPFIX)
              Information Elements", BCP 184, RFC 7013, September 2013.

Authors' Addresses

   Nagendra Kumar
   Cisco Systems, Inc.
   7200 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: naikumar@cisco.com


   Carlos Pignataro
   Cisco Systems, Inc.
   7200 Kit Creek Road
   Research Triangle Park, NC  27709-4987
   US

   Email: cpignata@cisco.com


   Paul Quinn
   Cisco Systems, Inc.
   170 West Tasman Dr
   San Jose, CA
   US

   Email: paulq@cisco.com





Kumar, et al.          Expires September 10, 2015              [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/