Internet DRAFT - draft-agv-sfc-performance-measurement-architecture
draft-agv-sfc-performance-measurement-architecture
SFC Working Group
INTERNET-DRAFT Anil Kumar S N
Intended Status: Informational Gaurav Agrawal
Vinod Kumar S
Huawei Technologies India
Expires: June 13, 2016 December 11, 2015
Performance Measurement Architecture for SFC
draft-agv-sfc-performance-measurement-architecture-00
Abstract
This document describes passive performance measurement(PM)
architecture for Service Function Chains (SFCs) in a network. It
includes architectural concepts and principles for composite services
performance measurement when deployed as SFCs, This document does not
propose solutions, protocols, or extensions to existing protocols.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
AGV Expires June 13, 2016 [Page 1]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
Copyright and License 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
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
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Terms & Definition . . . . . . . . . . . . . . . . . . . . . 5
2 Architecture overview . . . . . . . . . . . . . . . . . . . . . 9
3 Measurement Controller, Measurement Collector & MA. . . . . . . 10
4 Performance Measurement Attributes . . . . . . . . . . . . . . . 11
4.1 NSH Context Header Attributes . . . . . . . . . . . . . . . 11
4.2 PM Reporting Attributes . . . . . . . . . . . . . . . . . . 11
4.3 Attributes Description . . . . . . . . . . . . . . . . . . . 11
4.3.1 PMF Identifier . . . . . . . . . . . . . . . . . . . . . 11
4.3.2 Window Identifier . . . . . . . . . . . . . . . . . . . 12
4.3.3 Measurement Agents with PM Type . . . . . . . . . . . . 12
4.3.4 Performance Statistics . . . . . . . . . . . . . . . . . 13
4.3.5 PM Instance . . . . . . . . . . . . . . . . . . . . . . 13
5 Measurement Controller Operation . . . . . . . . . . . . . . . . 13
6 Classifier Operation . . . . . . . . . . . . . . . . . . . . . . 14
7 MA Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8 Collector Operation . . . . . . . . . . . . . . . . . . . . . . 15
9 Measurement steps . . . . . . . . . . . . . . . . . . . . . . . 15
10 Hop by Hop Performance Measurement . . . . . . . . . . . . . . 16
11 End to End Performance Measurement . . . . . . . . . . . . . . 16
12 Security Considerations . . . . . . . . . . . . . . . . . . . . 16
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1 Normative References . . . . . . . . . . . . . . . . . . . 17
14.2 Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
AGV Expires June 13, 2016 [Page 2]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
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).
The purpose of this memo is to define a general framework for
systematic passive performance measurement for the Network Service
Header (NSH) encapsulated packets or frames on service chains.
Service provider's service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics mostly for
following parameters:
a) Packet Loss
b) Packet delay
Performance measurement capability enables operators with greater
visibility into the performance characteristics of their networks,
thereby operators can carry out facilitating & planning,
troubleshooting, and network performance evaluation.
Performance measurement methods could be broadly into two categories:
Active Measurement method :
Active method measures performance or reliability parameters by
the examining injected special traffic into the network,
especially for the purpose of measurement by intended
measurement point.
Passive measurement method :
Passive method measures performance or reliability parameter
based of observing existing live traffic (packets) on the
network.
AGV Expires June 13, 2016 [Page 3]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
Both passive and active measurement methods have their strengths and
should be regarded as complementary. There are scenarios where active
measurements alone is not enough or applicable and passive
measurements are desirable along with active measurement method, one
such reasons could be the rate, numbers and interval between the
injected active measurement packets may affect the accuracy of the
results and also the injected test packets may not be guaranteed to
always be in-band with the data traffic in the network due to Equal
Cost Multi-Path (ECMP).
Below are some of the basic requirements for PM architecture for SFC
o Measurement of Packet Loss, Delay & Jitter.
o Hop by Hop, E2E, & SFC segment(s) Measurement.
o Measurement for Granular Flows in SFP as well as SFP as a whole
o Continuous/proactive & selective/on-demand measurement.
o Packet Out of Ordering shouldn't impact the PM calculation
o Compliance with NSH Standards
o PM applicability between different component in SPF path to
exactly locate the problem area (this includes Measurement
between SF-SF, SF-SFF, SFF-SFF etc.)
This document describes efficient and accurate passive performance
measurement architecture for Service Function Chains (SFCs) in a
service function domain with conformance to above listed basic
requirements.
AGV Expires June 13, 2016 [Page 4]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
1.1 Terminology
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 RFC 2119 [RFC2119].
1.2 Terms & Definition
Network Service: An offering provided by an operator that is
delivered using one or more service functions. This may
also be referred to as a "composite service". The term
"service" is used to denote a "network service" in the
context of this document.
Note: Beyond this document, the term "service" is overloaded
with varying definitions. For example, to some a service is
an offering composed of several elements within the
operator's network, whereas for others a service, or more
specifically a network service, is a discrete element such
as a "firewall". Traditionally, such services (in the latter
sense) host a set of service functions and have a network
locator where the service is hosted.
Classification: Locally instantiated matching of traffic flows
against policy for subsequent application of the required
set of network service functions. The policy may be
customer/network/service specific.
Classifier: An element that performs Classification.
Service Function Chain (SFC): A service function chain defines an
ordered set of abstract service functions and ordering
constraints that must be applied to packets and/or frames
and/or flows selected as a result of classification.
An example of an abstract service function is "a firewall".
The implied order may not be a linear progression as the
architecture allows for SFCs that copy to more than one
branch, and also allows for cases where there is flexibility
in the order in which service functions need to be applied.
The term "service chain" is often used as shorthand for
service function chain.
Service Function (SF): A function that is responsible for specific
treatment of received packets. A Service Function can act
at various layers of a protocol stack (e.g., at the network
layer or other OSI layers). As a logical component, a
service function can be realized as a virtual element or be
AGV Expires June 13, 2016 [Page 5]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
embedded in a physical network element. One or more Service
Functions can be embedded in the same network element.
Multiple occurrences of the service function can exist in
the same administrative domain.
One or more service functions can be involved in the
delivery of added-value services. A non-exhaustive list of
abstract service functions includes: firewalls, WAN and
application acceleration, Deep Packet Inspection (DPI),
Lawful Intercept (LI), server load balancing, NAT44
[RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID
injection, HTTP Header Enrichment functions, and TCP
optimizer.
An SF may be SFC encapsulation aware (that is, it receives
and acts on information in the SFC encapsulation) or unaware
(in which case, data forwarded to the SF does not contain
the SFC encapsulation). This is often referred to as "SFC
aware" and "SFC unaware", respectively.
Service Function Forwarder (SFF): A service function forwarder
is responsible for forwarding traffic to one or more
connected service functions according to information carried
in the SFC encapsulation, as well as handling traffic coming
back from the SF. Additionally, an SFF is responsible for
delivering traffic to a classifier when needed and supported
, transporting traffic to another SFF (in the same or
different type of overlay), and terminating the Service
Function Path (SFP).
Metadata: Provides the ability to exchange context information
between classifiers and SFs, and among SFs.
Service Function Path (SFP): The service function path is a
constrained specification of where packets assigned to a
certain service function path must go. While it may be so
constrained as to identify the exact locations, it can also
be less specific. The SFP provides a level of indirection
between the fully abstract notion of service chain as a
sequence of abstract service functions to be delivered, and
he fully specified notion of exactly which SFF/SFs the
packet will visit when it actually traverses the network.
By allowing the control components to specify this level of
indirection, the operator may control the degree of SFF/SF
selection authority that is delegated to the network.
SFC Encapsulation: The SFC encapsulation provides, at a minimum,
SFP identification, and is used by the SFC-aware functions,
AGV Expires June 13, 2016 [Page 6]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
such as the SFF and SFC-aware SFs. The SFC encapsulation is
not used for network packet forwarding. In addition to SFP
identification, the SFC encapsulation carries metadata
including data-plane context information.
Rendered Service Path (RSP): Within an SFP, packets themselves
are of course transmitted from and to specific places in the
network, visiting a specific sequence of SFFs and SFs. This
sequence of actual visits by a packet to specific SFFs and
SFs in the network is known as the Rendered Service Path
(RSP). This definition is included here for use by later
documents, such as when solutions may need to discuss the
actual sequence of locations the packets visit.
SFC-Enabled Domain: A network or region of a network that
implements SFC. An SFC-enabled domain is limited to a
single network administrative domain.
SFC Proxy: Removes and inserts SFC encapsulation on behalf of an
SFC-unaware service function. SFC proxies are logical
elements.
Network Node/Element: Device that forwards packets or frames
based on outer header information. In most cases is not
aware of the presence of NSH.
Network Overlay: Logical network built on top of existing
network (the underlay). Packets are encapsulated or
tunneled to create the overlay network topology.
Network Service Header: Data plane header added to frames/
packets. The header contains information required for
service chaining, as well as metadata added and consumed by
network nodes and service elements.
NSH Proxy: Acts as a gateway: removes and inserts SH on behalf
of a service function that is not NSH aware.
Service Classifier: Function that performs classification and
imposes an NSH. Creates a service path. Non-initial (i.e.
subsequent) classification can occur as needed and can alter,
or create a new service path.
Measurement Collector : An operational function that collects
measurement data from a Measurement Agent. Measurement
collector is responsible for collecting the Performance
measurement Data from Measurement Agent. Measurement
collector functionality could be integrated with one of
AGV Expires June 13, 2016 [Page 7]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
the MA or with the Controller itself.
Measurement Agent: An operational function that contains one or
more Measurement functions. Measurement Agents is
responsible for understand and analyze Performance
measurement control information encoded in NSH metadata
and perform the performance data collecting and report the
same to Measurement collector with key information to
identify performance measurement instance along with data
collected.
Measurement Controller: An operational function that controls
running, scheduling, and general coordination of Measurement
functions by instructing a Measurement Agent using NSH
metadata. Measurement Controller is responsible for
Configuring the Performance measurement Instance.
Optionally Performance measurement instance can be
configured manually at the Ingress in which case
Controller is not required
AGV Expires June 13, 2016 [Page 8]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
2 Architecture overview
+--------------------+ +------------------+
| | | |
| Measurement | | Measurement |
| Controller +----------+ Collector |
| | | |
| | | |
+--------------+-----+ +--------+---------+
| |
+----------------+-------------------------+--------------+
| Candidate Measurement Agents |
| |
| +----- |
| +------------+ | SF | |
| | | +--+-- |
| | SFC | | |
| | CLassifier | +---+----+ +--------+ |
| | Node <-------> SFF <--------> SFF | |
| | | +--------+ +---+----+ |
| | | | |
| +------------+ +-----+------+ |
| +----+ +----+ |
| | SF | | SF | |
| +----+ +----+ |
+---------------------------------------------------------+
SFC performance measurement architecture will have the following
major components:
Measurement Controller:
Responsible for Programming the PM instance at the SFC
classifier. Optionally PM instance can be configured
manually at the Ingress in which case controller is not
required.
Measurement Collector:
Responsible for collecting the PM Data from MA(s).
SFC Classifier:
Responsible for programming/encoding measurement control
information for MA(s) to collect the appropriate PM
statistics information as NSH metadata based on traffic
classification & Measurement controller instructions.
Measurement Agent:
Measurement Agents responsible for collecting the PM Data.
From now on will be referred as MA.
AGV Expires June 13, 2016 [Page 9]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
The following elements in a SFP can act as a MA
o SF
o SFF
o Classifier
o NSH Proxy Agent.
Note: Controller and Collector function can be hosted on a single
device which depending on deployment.
3 Measurement Controller, Measurement Collector & MA.
As described the major components of a service function enabled
network performance measurement platform are the Measurement Agents,
the Measurement Controller(s) and the Measurement Collector(s).
The MAs are the elements actually performing the measurements. The
MAs are controlled by exactly one Controller at a time and the
Measurement Collectors gather the results generated by the MAs.
In a nutshell, the normal operation of a SFC performance measurement
platform starts with the Controller instructing a set of one or more
MAs to perform a set of one or more performance measurement tasks at
a certain point in time. The MAs execute the instructions from a
Controller, and once they have done so, they report the results of
the measurements to one or more Measurement Collectors.
The overall detailed framework for a SFC performance measurement
platform along with information model will be described in subsequent
draft versions.
AGV Expires June 13, 2016 [Page 10]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
4 Performance Measurement Attributes
To perform an effective and accurate measurement; Encoding metadata
and accurate communication between measurement controller and
measurement agent is very important.
To achieve desired goal of efficiency and accuracy many performance
control information need to be encoded as NSH Context Header
Attributes in NSH metadata. Once measurement is done then these key
NSH Context Header Attributes along with measurement data need to be
reported to measurement controller.
4.1 NSH Context Header Attributes
Following attributes should encoded in NSH metadata in a Context
Header
- PMF Identifier
- Window Identifier
- List of MA(s) with PM Type
4.2 PM Reporting Attributes
Following Information should be sent from each MA to COLLECTOR
- PMF Identifier
- Window Identifier
- MA with PM Type
- Performance Statistics
4.3 Attributes Description
Multiple new performance attributes are introduced in this memo to
carry performance control information. Each attribute has unique
purpose; are understood based on context and corresponding
performance is performed by respective MA in the SFP.
4.3.1 PMF Identifier
Purpose : For unique identification of a measured Flow
in SFC Domain
Value : Unique value within current SFC domain
Processing :
- At Classifier : The PMF Identifier in encoded in NSH
Context Header.
- At MA : Used as a key while collecting, maintaining
& reporting PM Statistics to Collector.
AGV Expires June 13, 2016 [Page 11]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
- At Collector : Collector co-relates the performance data
received from MA using this PMF Identifier.
4.3.2 Window Identifier
Purpose : Divides the flows into multiple Windows. Packets
with PM information in a Window will have same
Window identifier and consecutive Windows will
have 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 co-relates the performance data
received from MA using this Window
Identifier.
4.3.3 Measurement Agents with PM Type
Purpose : To identify participating measurement agents
and type of performance measurement.
Value : Service Index to identify SF in SFP.
Processing :
- At Classifier : Encode the Participating MA(s) with PM Type.
- At MA : Presence of self index triggers the PM
collection & reporting.
- At Collector : Identifies the reporting MA
AGV Expires June 13, 2016 [Page 12]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
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 report it to Collector
For Delay: Record the time for sent and
received packet for a given Flow + window
and report it to Collector.
- At Collector : Co-relate and maintain received data
4.3.5 PM Instance
PM Instance is a set of parameters consisting PMF ID, MA List along
wit its PM Type, Window size & PM Schedule (Specifies the time when
the PM has to be performed). PM Instance uniquely identifies a PM
flow in SFC domain. PM Instance needs to be programmed for a
classified flow at the classifier either by Controller or by manually
configuration. Values of these parameters will depend on the
measurement scenario.
5 Measurement Controller Operation
Measurement Controller has the following responsibility:
1) Program the PM Instance at the Classifier
2) Provides the PM Instance details to the Collector (if required)
3) Ensures the uniqueness of PMF Id across the SF Domain
4) Program the reporting interval at the MAs (optional).
AGV Expires June 13, 2016 [Page 13]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
6 Classifier Operation
Classifier classifies packets for the PM Instance based on the
instruction provided by the controller. In the classified packets
it encodes the following information in Context header of NSH
metadata
PMF Identifier: As provided by the Controller
Window Identifier: Locally generated Number which changes based
on the Window size.
MA(s): List of MA(s) with PM Type
Note: Selecting the packets in a flow to participate in a PM is
decided by Controller/Classifier and it is outside the scope of this
document.
7 MA Operation
MA carries out following operation when packet with NSH header
encountered:
- 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 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 MA.
Note:
1) MA does not maintain the context of the window, the statistics
information of a single window can be sent in more than one
report, its Collector's responsibility to map and accumulates
the statistics of a window from different reports.
2) If Classifier itself is a MA it also needs to do performance
measurement and reporting.
AGV Expires June 13, 2016 [Page 14]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
8 Collector Operation
Collector collects the data from the MA and performs the following
for Data co-relation:
- Collector uses PMF Identifier to group statistics related to
single PM flow. Collector maintains the statistics related to
a single PM flow from multiple MA to compute the performance
for the flow.
- Collector uses the Window identifier to group the statistics
received from multiple MA for a single window for a given PM
Flow.
- Since MA does not maintain the context of the block interval,
statistics 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 computations 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 PM Instance at Classifier.
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 check presence of its service index in PM Context
Header (If its own index is not present than 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 packet.
Step 8: MA reports the accumulated PM statistics to Collector
at reporting interval.
Step 9: Regular Packet processing continues.
Step 5 to Step 9 is repeated at every MA.
AGV Expires June 13, 2016 [Page 15]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
10 Hop by Hop Performance Measurement
In case PM needs to be performed on all the SFs in the SFP, as per
the described NSH programming in classifier, all the SF's, SI needs
to be added in the context header. This will ensure all the SFs
participate in the PM. This mechanism will require all the SF to
traverse the context header until the self SI is found.
Alternatively, we can optimize this process by defining a new context
type which means the all the SF's needs to perform the specified PM.
By this way at classifier we can skip the SI encoding in the context
header, and at MA we can skip the SI traversing.
Extension for SFF participation in Hop by Hop PM. As mentioned in the
above section, we can define a special context types which means SFF
and/or needs participate in the PM.
11 End to End Performance Measurement
In case PM needs to be performed on the end point SFs in the SFP,
these 2 SI needs to be encoded in the context header, and it will
follow the normal procedure to perform E2E SF's PM.
If in case PM needs to be performed between the classifier and SFC
domain boundary SFF, a special context type will be encode on the
NSH, which needs to be processed by the boundary SFF to report the PM
data to collector and then strip the NSH.
12 Security Considerations
No specific security considerations for this document
13 IANA Considerations
No specific IANA considerations for this document
AGV Expires June 13, 2016 [Page 16]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
14 References
14.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.
AGV Expires June 13, 2016 [Page 17]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
14.2 Informative References
[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/
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 June 13, 2016 [Page 18]
INTERNET DRAFT PM Architecture for SFC December 11, 2015
Authors' Addresses
Anil Kumar S N
Huawei Technologies India Pvt. Ltd,
Near EPIP Industrial Area,
Kundalahalli Village,
Whitefield,
Bangalore - 560037
EMail: anil.sn@huawei.com
Gaurav Agrawal
Huawei Technologies India Pvt. Ltd,
Near EPIP Industrial Area,
Kundalahalli Village,
Whitefield,
Bangalore - 560037
EMail: gaurav.agrawal@huawei.com
Vinod Kumar S
Huawei Technologies India Pvt. Ltd,
Near EPIP Industrial Area,
Kundalahalli Village,
Whitefield,
Bangalore - 560037
EMail: vinods.kumar@huawei.com
AGV Expires June 13, 2016 [Page 19]
