[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-sfc-agv-performance-measurement-architecture) 00 01 02

Internet Draft                                            Anil Kumar S N
SFC Working Group                                         Gaurav Agrawal
Category: Informational                                    Vinod Kumar S
Expires: December 30, 2016                           Huawei Technologies
                                                            C. Jacquenet
                                                                  Orange
                                                           June 28, 2016


              Performance Measurement Architecture for SFC
         draft-agv-sfc-performance-measurement-architecture-02

Abstract

   This document describes performance measurement(PM) architecture for
   Service Function Chains (SFCs) to assess the operational status and
   behavior of a service function, a subset of service function's, a
   whole service function chain as a function of the actual
   deterministic service function / service function chain. This
   document does not propose solutions, protocols, nor any extension to
   existing protocols.

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 December 30, 2016













AGV                    Expires December 30, 2016                [Page 1]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


Copyright and License Notice

   Copyright (c) 2016 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. Architecture Overview . . . . . . . . . . . . . . . . . . . . .  7
   3 PM Measurements Methods: . . . . . . . . . . . . . . . . . . . .  8
   4 Performance Measurement Attributes . . . . . . . . . . . . . . .  9
     4.1  Metadata Attributes . . . . . . . . . . . . . . . . . . . .  9
     4.2 PM Reporting Attributes  . . . . . . . . . . . . . . . . . .  9
     4.3 Performance Measurement Attributes Description . . . . . . .  9
       4.3.1 PMF Identifier . . . . . . . . . . . . . . . . . . . . . 10
       4.3.2 Window Identifier  . . . . . . . . . . . . . . . . . . . 10
       4.3.3 Measurement Agents Identifier with PM type . . . . . . . 11
       4.3.4 Performance Statistics . . . . . . . . . . . . . . . . . 12
   5 Measurement Controller Operation . . . . . . . . . . . . . . . . 12
   6 Measurement Classifier Operation . . . . . . . . . . . . . . . . 13
   7 MA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8 Collector Operation  . . . . . . . . . . . . . . . . . . . . . . 14
   9 Measurement Steps  . . . . . . . . . . . . . . . . . . . . . . . 14
   10 Hop by Hop Performance Measurement  . . . . . . . . . . . . . . 15
   11 SFC as a whole Performance Measurement  . . . . . . . . . . . . 15
   12 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 15
   13 Security Considerations . . . . . . . . . . . . . . . . . . . . 16
   14 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
   15 References  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     15.1 Normative References  . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19





AGV                    Expires December 30, 2016                [Page 2]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016





















































AGV                    Expires December 30, 2016                [Page 3]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


1. Introduction

   The delivery of end-to-end services often requires various service
   functions.  These include traditional network service functions such
   as firewalls and traditional IP network address translators (NATs),
   as well as application-specific functions.  The definition and
   instantiation of an ordered set of service functions and subsequent
   "steering" of traffic through them is termed service function
   chaining (SFC).

   This document describes an architecture used for assessing and
   monitoring SFC operation. It includes architectural concepts,
   principles, and components, with a focus on assessing the operational
   status and behavior of a SF, a subset of SFs, a whole SFC as a
   function of the actual deterministic SF/SFC.

   Proper operation of a SFC depends on the ability to monitor and
   quickly identify faults and focus attention on the root cause of the
   problem. To achieve this we need to monitor the performance
   parameters of SFC like packet loss, delay, jitter etc.

   For instance a SFC is composed of diffServ (e.g., traffic
   conditioning capabilities) and NAT functions, with OOP as a traffic
   type. To ensure the proper operation of a OOP it's required to ensure
   that traffic is properly re-marked before invoking the NAT function
   which selects a specific pool for such OOP traffic. Incorrect re-
   marking of this traffic will lead to performance deterioration in
   terms of increase in one way delay.

   For another instance a SFC is composed of firewall which is supposed
   to controls the incoming and outgoing network traffic based on
   predetermined security rules. To ensure the proper functioning of
   this SF it's required to ensure that a specific set of traffic must
   be dropped and another specific set of traffic must be allowed to
   pass.

   Continuous measurement and monitoring of packet delay/loss for a SF,
   a subset of SFs, a whole SFC will help to find the problem. Also
   performance measurement results can be used to locate the root cause.
   which inturn can also be used to possibly take required action as far
   as SFC structuring is concerned.

   Service provider's service level agreements (SLAs) usually include
   performance indicators like packet loss or inter-packet delay
   variation that need to be measured over a given period of time. SFC
   Performance measurement enables operators with greater visibility
   into the performance characteristics of their SFCs, thereby ensuring
   service SLAs.



AGV                    Expires December 30, 2016                [Page 4]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


   SFC is at service layer which is independent of transport layer
   technology. For a SFC underlying layer can be a mix of multiple
   transport layer tunneling technology like MPLS, VXLAN etc. SLA
   measurements of independent transport layer will not be capable to
   assess the operational status and behavior of a SF, a subset of SFs,
   a whole SFC as a function of the actual deterministic SF/SFC which
   leads to a requirement for performance measurement architecture
   specific to service function chain.

   Transport layer PM and SFC PM can go hand in hand, SFC PM can be used
   to obtain the exact segment of problem if that segment is one of the
   Transport layer Tunnel, transport layer PM can be used to locate
   exact fault location.

   Requirements of SFC performance measurement architecture includes:

   1) Localization of performance degradation occurred due to a unit in
      a service function chain.

   2) Localization of performance degradation for a specific service
      traffic type

   3) Enable service providers with a tool to offer high value services
      whose performance degradation can be proactively located and
      corrected.

   4) ECMP scenarios can result in out of order packets, performance
      measurement should consider this while measurement.

   5) Validation of service function chain performance at the time of
      deployment/fault correction verification (using probe packets)

   6) Runtime Validation of service function chain performance using
      traffic packets itself to get accurate performance data without
      additional probe packets.

   7) Performance measurement under induced traffic level. The
      motivation for this can be related to the rate and the amount of
      traffic that can influence the accuracy of the measurement results

   8) Optimized measurement by keeping minimal performance measurement
      load.









AGV                    Expires December 30, 2016                [Page 5]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


   Following capabilities are required to be supported by performance
   measurement architecture to address above requirements.

   1) Capability to assess and monitor at
      a) SF
      b) SFF
      c) Set of SF/SFF
      d) Segment(s) between any two SF/SFF in a SFC.
      e) SFC as a whole.

   2) Capability to measure performance for fine-grained and
      coarse-grained flow.

   3) Capability for Continuous/proactive & selective/on-demand
      measurement.

   4) Support for all three measurement methods:

      Active Measurement method:
          Active method measures performance and other parameters by
          injecting test traffic into the network from specific
          locations (e.g., a Point of Presence).

      Passive measurement method:
          Passive method measures performance and other parameters
          based on the observation of live traffic forwarded in the
          network.

      Hybrid measurement method:
          Hybrid measurement method uses both active and passive
          measurement methods.

   5) Capability to measure performance even in case of out of order
      packets.

















AGV                    Expires December 30, 2016                [Page 6]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


2. Architecture Overview

        +--------------------+          +------------------+
        |                    |          |                  |
        |     Measurement    |          |    Measurement   |
        |     Controller     +----------+    Collector     |
        |                    |          |                  |
        |                    |          |                  |
        +--------------+-----+          +--------+---------+
                       |                         |
      +----------------+-------------------------+--------------+
      |   Candidate Measurement Agents                          |
      |                                                         |
      |                        +-----                           |
      |  +------------+        | SF |                           |
      |  |            |        +--+--                           |
      |  | Measurement|           |                             |
      |  | CLassifier |       +---+----+        +--------+      |
      |  |            <------->  SFF   <-------->  SFF   |      |
      |  |            |       +--------+        +---+----+      |
      |  |            |                             |           |
      |  +------------+                       +-----+------+    |
      |                                    +----+        +----+ |
      |                                    | SF |        | SF | |
      |                                    +----+        +----+ |
      +---------------------------------------------------------+


   The SFC performance measurement architecture relies upon the
   following components:

   Measurement Controller: An entity that controls and coordinates a set
   of measurement functions. The measurement controller is responsible
   for programming the performance measurement instance at measurement
   classifier and updating the same to measurement collector,
   additionally it can inject probe packets in SFP for measurement.


   Measurement Collector: An entity that collects measurement data from
   a measurement agents (MAs). A measurement collector functionality
   could be integrated with one of the MAs deployed in the network or
   with the measurement controller itself.

   Measurement Classifier: An entity responsible for encoding
   measurement control information based on PMI programmed by
   measurement controller. SFC Classifier MUST incorporate the
   measurement classifier functionality to support SFC performance
   measurement.



AGV                    Expires December 30, 2016                [Page 7]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


   Measurement Agent: An entity that supports one or more Measurement
   functions. It is responsible for performance data collection and
   reporting the same to Measurement collector.

   The following elements MUST incorporate the MA functionality to
   support SFC performance measurement.

       o SF
       o SFF
       o Classifier
       o NSH Proxy Agent.


3 PM Measurements Methods:

   a) Active measurement : Measurement controller induce probe packets
      with encoded performance measurement data or programs PMI at
      measurement classifier which will in turn induce probe packets
      with encoded performance measurement data. measurement controller
      updates the PMI to measurement collector. Participating
      measurement agents based on received encoded information carry out
      measurements and reports the collected data to measurement
      collector. measurement collector co-relates received data and
      provides measurement results.

      Note: Current draft only covers the Measurement attributes
      programming for probe packets. Construction of base probe packet
      is outside the scope of this RFC.

   b) Passive measurement : Measurement controller programming PMI at
      measurement classifier and updating the same to measurement
      collector. measurement classifier encodes the performance
      measurement data in classified packets. Participating measurement
      agents based on received encoded information carry out measurement
      and reports the collected data to measurement collector.
      measurement collector co- relates received data and provides
      measurement results.

   c) Hybrid measurement : Measurement controller induce probe packets
      to pre-setup load condition for a SFC using active measurement.
      measurement controller than uses passive measurement to carry out
      performance measurement under load condition.









AGV                    Expires December 30, 2016                [Page 8]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


4 Performance Measurement Attributes

   There are two types of PM attributes

   a) Metadata Attributes: These attributes are to instruct the MA to
      carry out the required performance measurement. Measurement
      classifier encodes these attributes in the traffic packets based
      on instructions provided by controller or these attributes are
      encoded directly in test packet by measurement
      controller/measurement classifier.

   b) PM reporting attributes: These attributes are used by MA(s) to
      report the collected performance data to Collector

4.1  Metadata Attributes

      The following attributes  must be encoded as metadata for selected
      traffic or probe packets

           - PMF Identifier
           - Window Identifier
           - List of MA(s) identifier with PM Type

4.2 PM Reporting Attributes

      The following Information should be sent by each MA to the
      collector:

           - PMF identifier
           - Window identifier
           - MA identifier with PM type
           - Performance statistics

4.3 Performance Measurement Attributes Description

   Several performance attributes are introduced in this memo to
   carry performance control information. Each attribute has a unique
   purpose; they are interpreted based upon a specific context and the
   corresponding performance measurement is performed by the
   respective MA.











AGV                    Expires December 30, 2016                [Page 9]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


4.3.1 PMF Identifier

   Purpose : To unambiguously identify a measurement flow in the SFC
   Domain. When a MA reports its performance data to collector,
   collector has to associate the data to a particular instance of
   measurement, as controller would have created multiple instance of
   measurements. By using service path index + service index only
   coarse-grained flows can be identified. To identify a fine-grained
   flows (Ex: SFC classification is based on destination IP, so flow
   classified based on this destination IP is coarse-grained flow. Sub
   flow corresponding to a particular destination IP within this flow is
   an example of fine-grained flows) within a SFC domain SPI + SI is not
   enough.  PMF identifier is used to uniquely identify the performance
   measurement instance corresponding to fine grained flows.

        Value             : Unique value within current SFC domain

        Processing        :
          - At Classifier : The PMF Identifier is encoded in metadata
                            Note: For probe packets this information is
                            encoded by entity (controller/classifier)
                            constructing probe packet.

          - At MA         : Used as a key while collecting, maintaining
                            & reporting PM statistics to collector.

          - At Collector  : Collector correlates the performance data
                           received from a MA using this PMF Identifier.

4.3.2 Window Identifier

        Purpose : Window identifier is to handle out of order packet
                  scenario.

        Example:
        SFC classifier-----------SF1--------------SF2--------------SF3
        Packet 1-->-------------------------------------------->Packet 2
        Packet 2-->-------------------------------------------->Packet 1

        Packet 1 belongs to earlier cycle of measurement but SF3
        receives Packet 2 before packet 1 due to out of order problem.
        Now, when this data is co-related at Collector, if there is no
        window identifier, packet 2 will be treated as packet 1 and
        result will be incorrect. Window identifier is of local scope to
        a MA.

        Sender (Classifier/Controller) divides the flows into multiple
        windows. Packets with PM information in a window will have the



AGV                    Expires December 30, 2016               [Page 10]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


        same window identifier and consecutive windows will have a
        different identifier. This enables MA to collect & accumulate
        statistics corresponding to each window & report it to
        collector. Size of the window is programmable.

        Value             : Integer (Max/Min Value: Programmable to
                            context header at classifier, once Max value
                            reached then value = Min Value). Value
                            increments with each PM interval.


        Processing        :
          - At Classifier : The window identifier is encoded in NSH
                            context header.

          - At MA         : Used as a key while collecting, maintaining
                            & reporting PM statistics to collector.

          - At Collector  : Collector correlates the performance data
                            received from MA by using this window
                            identifier.

4.3.3 Measurement Agents Identifier with PM type

        Purpose           : To identify participating measurement agents
                            with context and type of performance
                            measurement.

        Value             : Measurement agent for a given SFP is
                            identified using MA identifier + service
                            index

   MA identifier has two parts
   1) Node identifier - 24 bit
      a) For SFF: MUST be unique number assigned by controller
      b) For SF: All zero. Context identifier itself identifies SF node.
   2) Order identifier - 8 bit
      a) For SFF: Service index of next SF.
      b) For SF: Service index

   MA identifier SHOULD be in decreasing order of the SI for optimized
   traversal of the SI participation.

   PM Type (IANA assigned values)

        Processing        :
          - At Classifier : Encode the participating MA(s) with PM type.




AGV                    Expires December 30, 2016               [Page 11]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


          - At MA         : Presence of self service index triggers the
                            PM collection & reporting

          - At Collector  : Identifies the reporting MA

4.3.4 Performance Statistics

        Purpose           : Computation of performance.
        Value             : Collected statistics

        Processing        :
          - At Classifier : None.
          - At MA         : Depends on performance measurement type

                            For packet loss: Accumulates received & sent
                            packets counter for a given flow + window
                            and reports it to collector

                            For packet delay: Record the time for
                            sending and receiving a packet of a given
                            flow + window and reports it to collector.

          - At Collector  : Correlates and maintains received data

5 Measurement Controller Operation

      The Measurement Controller has the following responsibilities:

      1) Programs the unique MA identifier for SF/SFF/SFC proxy in
         SFC domain.
      2) Programs the PM instance at the classifier

            PM Instance MUST contain the following information:
            a) PM flow classification rule with PMF identifier
               (unique across the SFC domain). For coarse grained
               flow PM flow classification rule is optional.
            b) List of participating MA with PM type.
            c) Window size and PM schedule.

      3) Provides the PM Instance to the collector (if required)
      4) Ensures the uniqueness of MA identifier & PMF identifier across
         the SFC domain
      5) Programs the reporting interval at the MAs (optional).
      6) For active measurement creates and send test probe packet.







AGV                    Expires December 30, 2016               [Page 12]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


6 Measurement Classifier Operation

   The classifier classifies packets for the PM instance based on the
   instructions provided by the controller. In the classified
   packets it encodes the following information in context header of
   NSH metadata:

   PMF identifier      : As programmed by controller
   Window identifier   : Locally generated number which changes
                         based on the window size.
   MA(s)               : List of MA(s) with PM type


   For active measurement measurement classifier MAY need to generate
   probe packet as instructed by measurement controller.
   Note: Selection of  packets in a flow to participate in a PM is
   decided by controller and it is outside the scope of this document.

7 MA Operation

   MA carries out the following operations upon receipt of a packet with
   NSH header:

      - Detection of PM context header in a packet.
      - Processing of context header information.
      - Check the presence of self index in context header.
      - Identification of the PM type.
      - Performance measurement based on the identified type.
          * For packet loss: Accumulates statistics for received & sent
                             packets for a given PMF + window
          * For packet delay: Record the time when the packet was
                             received and sent for a given PMF + window
      - Reporting of accumulated statistics at configured interval to
        the collector. This interval should be consistent across all
        MAs.

      Note:
      1) A MA does not maintain the context of the window, the
         statistical information of a single window can be sent in more
         than one report, it is the collector's responsibility to map
         and accumulate statistics of a window from different reports.
      2) If the classifier itself embeds a MA, it also needs to do
         performance measurement and reporting.








AGV                    Expires December 30, 2016               [Page 13]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


8 Collector Operation

   Collector collects data from the MA and performs the following
   operations for data correlation purposes:

      - Collector uses PMF identifier to group statistics related to  a
        given PM flow. Collector maintains the statistics related to  a
        given PM flow from multiple MAs to assess the forwarding
        performance.

      - Collector uses the window identifier to group statistics
        received from multiple MAs for a single window for a given PM
        flow.

      - Since the MA does not maintain the context of the block
        interval, statistical information of a single block can be
        received in more than one report; collector maps and accumulates
        the statistics of a block from different reports.

      - Collector performs the PM computation based on the PM type
        & statistics collected from the MA; the identification of PM
        segment is done in the collector, based on the PM types received
        from the segment end point MAs.

9 Measurement Steps

   Step 1: Programming of MA identifier at SF/SFF/SFC proxy by
   controller. Programming of PM instance at classifier by controller

   Step 2: Classifier classifies & select packets for a PM Flow.

   Step 3: Classifier encapsulates the PM attributes in PM context
           header for selected packets.

   Step 4: Packet is sent out of classifier.

   Step 5: MA receives packet and check presence of PM context header
           (If context header is not present move to step 9.)

   Step 6: MA checks presence of its service index in PM context
           header (If its own index is not present, then move to Step 9)

   Step 7: MA obtains PM type to be carried out and according
           accumulates PM statistics for a given PMF + window for
           received and sent packets.

   Step 8: MA reports the accumulated PM statistics to collector at
           reporting intervals.



AGV                    Expires December 30, 2016               [Page 14]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


   Step 9: Regular packet processing continues.

           Step 5 to step 9 is repeated at every MA.

10 Hop by Hop Performance Measurement

   In case PM needs to be performed on all the SFs invoked along the
   SFP, as per the described NSH programming in the classifier, all the
   SFs MA identifier needs to be added in the context header. This will
   ensure all the SFs/SFFs participate in the PM. This mechanism will
   require all the SFs/SFFs to traverse the context header until the
   self SI is found.

   Alternatively, we can optimize this process by defining a new context
   type where all the SFs need to perform the specified PM. Thus, the
   classifier can skip the MA identifier encoding in the context header,
   and the MA can skip the MA identifier processing.

   Extension for SFF participation in hop-by-hop PM. As mentioned in the
   previous  section, we can define a special context types which means
   SFF and/or needs participate in the PM.

11 SFC as a whole Performance Measurement

   In case PM needs to be performed on the endpoint SFs along the SFP,
   these 2 MA identifier needs to be encoded in the context header, and
   will follow the procedure to perform E2E SF's PM.

   In case the PM needs to be performed between the classifier and SFC
   domain boundary SFF, a special context type will be encoded in the
   NSH, which needs to be processed by the boundary SFF to report the PM
   data to the collector and then strip the NSH.

12 Acknowledgements

   Special Thanks to Nobin Mathew for his review and comments.















AGV                    Expires December 30, 2016               [Page 15]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


13 Security Considerations

   There are no security considerations relevant to this document.

14 IANA Considerations

   No actions are required from IANA as result of the publication of
   this document.











































AGV                    Expires December 30, 2016               [Page 16]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


15 References

15.1 Normative References

      [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
                 DOI 10.17487/RFC0791, September 1981,
                 <http://www.rfc-editor.org/info/rfc791>.

      [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
                 RFC2119, March 1997,
                 <http://www.rfc-editor.org/info/rfc2119>.

      [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
                 "Framework for IP Performance Metrics", RFC 2330,
                 May 1998.

      [RFC2678]  Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
                 Connectivity", RFC 2678, September 1999.

      [RFC2679]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
                 Delay Metric for IPPM", RFC 2679, September 1999.

      [RFC2680]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
                 Packet Loss Metric for IPPM", RFC 2680, September 1999.

      [RFC3148]  Mathis, M. and M. Allman, "A Framework for Defining
                 Empirical Bulk Transfer Capacity Metrics", RFC 3148,
                 July 2001.

      [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay
                 Variation Metric for IP Performance Metrics (IPPM)",
                 RFC 3393, November 2002.

      [RFC3432]  Raisanen, V., Grotefeld, G., and A. Morton, "Network
                 performance measurement with periodic streams",
                 RFC 3432, November 2002.

      [RFC4656]  Shalunov, S., Teitelbaum, B., Karp, A., Boote, J.,
                 and M.Zekauskas, "A One-way Active Measurement
                 Protocol (OWAMP)", RFC 4656, September 2006.
      [RFC5226]  Narten, T. and H. Alvestrand,"Guidelines for Writing an
                 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                 DOI 10.17487/RFC5226, May 2008,
                 <http://www.rfc-editor.org/info/rfc5226>.

      [RFC7498]  Quinn, P., Ed. and T. Nadeau,Ed.,"Problem Statement for
                 Service Function Chaining", RFC 7498, DOI 10.17487/



AGV                    Expires December 30, 2016               [Page 17]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


                 RFC7498, April 2015,
                 <http://www.rfc-editor.org/info/rfc7498>.

      [SFC-arch]
                 Quinn, P., Ed. and J. Halpern, Ed., "Service Function
                 Chaining (SFC) Architecture", 2014,
                 <http://datatracker.ietf.org/doc/draft-quinn-sfc-arch>.












































AGV                    Expires December 30, 2016               [Page 18]


INTERNET DRAFT          PM Architecture for SFC            June 28, 2016


Authors' Addresses


      Anil Kumar S N
      Huawei Technologies India Pvt. Ltd,
      Near EPIP Industrial Area,
      Kundalahalli Village,
      Whitefield,
      Bangalore - 560066

      EMail: anil.sn@huawei.com


      Gaurav Agrawal
      Huawei Technologies India Pvt. Ltd,
      Near EPIP Industrial Area,
      Kundalahalli Village,
      Whitefield,
      Bangalore - 560066

      EMail: gaurav.agrawal@huawei.com


      Vinod Kumar S
      Huawei Technologies India Pvt. Ltd,
      Near EPIP Industrial Area,
      Kundalahalli Village,
      Whitefield,
      Bangalore - 560066

      EMail: vinods.kumar@huawei.com

      Christian Jacquenet
      Orange
      Rennes  35000
      France

      Email: christian.jacquenet@orange.com













AGV                    Expires December 30, 2016               [Page 19]


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