Internet DRAFT - draft-browne-ietf-sfc-nsh-timestamp
draft-browne-ietf-sfc-nsh-timestamp
Network Working Group R. Browne
Internet-Draft A. Chilikin
Intended status: Standards Track B. Ryan
Expires: April 20, 2016 Intel
October 19 2015
Network Service Header Time Stamping
draft-browne-ietf-sfc-nsh-timestamp-00
Abstract
This draft describes a method of time-stamping Network Service Header
(NSH) encapsulated packets or frames on service chains in order to
measure accurately hop by hop performance delays of application flows
carried within the chain. This method may be used to monitor
performance and highlight problems with virtual links (vlinks) VNFs
or PNFs on the rendered service path (RSP).
Requirements Language
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].
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 April 20, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Browne Expires April 20, 2016 [Page 1]
Internet-Draft Network Service Header Time Stamping August 2015
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Definition of Terms . . . . . . . . . . . . . . . . . . 3
3. NSH Time stamping . . . . . . . . . . . . . . . . . . . . . 5
3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Operation . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Implementation . . . . . . . . . . . . . . . . . . . . . . 8
4. NSH Time stamping Encapsulation . . . . . . . . . . . . . . . 9
5. Hybrid Models . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Targeted VNF Time Stamp . . . . . . . . . . . . . . . . . 12
6. Fragmentation Considerations . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Open Items for WG Discussion . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Network Service Header (NSH) as defined by draft-ietf-sfc-nsh-00
defines a method to insert a service-aware header in between payload
and transport headers. This allows a great deal of flexibility and
programmability in the forwarding plane allowing user flows to be
programmed on the fly for the appropriate service functions (SFs).
Whilst NSH promises a compelling vista of operational agility for
Service Providers, many service providers are concerned about losing
service visibility in the transition from physical appliance SFs to
virtualized SFs running in the NFV domain. This concern increases
when we consider that many service providers wish to run their
networks seamlessly in 'hybrid' mode: - that is, whereby they wish to
mix physical and virtual SFs and run services seamlessly between the
two domains.
Browne Expires April 20, 2016 [Page 2]
Internet-Draft Network Service Header Time Stamping August 2015
This draft describes a generic method to monitor and debug service
chains and application performance of the flows within a service
chain. This method is compliant with hybrid architectures in which
VNFs and PNFs are freely mixed in the service chain. This method also
is flexible to monitor an entire chain performance or part thereof as
desired. Please refer to draft-ietf-sfc-nsh-00.txt as background
architecture for the method described in this document.
The method described in this draft is not an OAM protocol like Y.1731
or Y.1564 for example. As such it does not define new OAM packet
types or operation. Rather it monitors the service chain performance
for subscriber payloads and indicates subscriber QoE rather than
out-of-band infrastructure metrics.
2.1. Definition of Terms
Classification: Locally instantiated policy and
customer/network/service profile matching of traffic flows for
identification of appropriate outbound forwarding actions.
First TS Node (FTSN) - Must mark packet correctly. Must understand 5
tuple information in order to match TS Controller flow table.
Last TS Node (LTSN) - must read all MD & export to system performance
statistics agent or repository. Should also send NSH header - the SI
will indicate if a PNF(s) was at the end of the chain. The LTSN
changes the SPI in order that the underlay routes the metadata back
directly to the TSDB.
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.
PNF: Physical Network Function
Browne Expires April 20, 2016 [Page 3]
Internet-Draft Network Service Header Time Stamping August 2015
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.
Service Function (SF): A function that is responsible for specific
treatment of received packets. A service function can act at the
network layer or other OSI layers. A service function can be virtual
instance or be embedded in a physical network element. One of
multiple service functions can be embedded in the same network
element. Multiple instances of the service function can be enabled in
the same administrative domain.
Service Function Chain (SFC): A service function chain defines an
ordered set of service functions that must be applied to packets
and/or frames selected as a result of classification. The implied
order may not be a linear progression as the architecture allows for
nodes that copy to more than one branch. The term service chain is
often used as shorthand for service function chain.
Service Function Path (SFP): The instantiation of a SFC in the
network. Packets follow a service function path from a classifier
through the requisite service functions.
TS Controller: The TS Controller may be part of the service chaining
application, SDN controller, NFVO or any MANO entity. For clarity we
define the TS Controller separately here as the central logic that
decides what packets to timestamp and how. The TS Controller
instructs the classifier on how to mark the NSH header.
Time Stamp Control Plane (TSCP) - the control plane between the FTSN
and the TS Controller.
Time Stamp Database (TSDB) - external storage of Metadata for
reporting, trend analysis etc.
UTC: Real Time Clock
VNF: Virtual Network Function
Browne Expires April 20, 2016 [Page 4]
Internet-Draft Network Service Header Time Stamping August 2015
3. NSH Time stamping
As a generic architecture, please refer to figure 1 below:-
TS
Controller
| TSDB
| TSCP Interface |
,---. ,---. ,---. ,---.
/ \ / \ / \ / \
( SCL )-------->( SF1 )--------->( SF2 )--------->( SFN )
\ FTSN/ \ / \ / \ LTSN/
`---' `---' `---' `---'
Figure 1: Logical roles in NSH Time Stamping
The TS Controller will most probably be part of the SFC controller
but is explained separately in this document for clarity. The TS
Controller is responsible for initiating start/stop timestamp
requests to the SCL or FTSN, and also for distributing timestamp NSH
policy into the service chain via the Time Stamping Control Plane
(TSCP) interface.
The First Time Stamp Node (FTSN) will typically be part of the
service classifier but again is called out as separate logical entity
for clarity. The FTSN is responsible for marking NSH MD Type 0x2
fields for the correct flow with the appropriate NSH fields. This
tells all upstream nodes how to behave in terms of time stamping at
VNF ingress,egress or both, or ignoring the timestamp NSH metadata
completely. The FTSN also writes the UTC value into the header so the
chain:flow performance can be compared to previous samples for
offline analysis. The FTSN should return an error to the TS
Controller if not synchronized to time-of-day and forward the packet
along the service-chain unchanged.
SF1, SF2 timestamp the packets as dictated by the FTSN and process
the payload as per normal.
Note 1: The exact location of the timestamp creation may not be in
the VNF itself as referenced in section 3.3.
Note 2: Special cases exist where some of the SFs (PNFs or VNFs) are
NSH-unaware. This is covered in section 6.
The Last Time Stamp Node (LTSN) should export all NSH time stamp
metadata to the Time stamp Database (TSDB) for offline analysis,
strip the entire header and forward the packet to the IP next hop. In
fully virtualized environments the LTSN will be co-located with the
VNF that decrements NSH SI to zero. Corner cases exist whereby this
is not the case and is covered in section 6.
Browne Expires April 20, 2016 [Page 5]
Internet-Draft Network Service Header Time Stamping August 2015
3.1 Prerequisites
In order to guarantee metadata accuracy, all servers hosting VNFs
should be synchronized from a centralized stable clock. As PNFs do
not time stamp there is no need for synchronize. There are two types
of synchronization required.
A) Low accuracy time-of-day as described in 1 below and
B) High accuracy (sub-microsecond) as described by 2 or 3 below.
1. Each platform (including the TS Controller) should synch their
system real-time-clock from an NTP server. This is used to mark
the metadata in the chain. The UTC format is written by the first
SF in the chain to apply a timestamp. NTP accuracy can vary by
several milliseconds between locations. This is not an issue as
the UTC stamp is merely being used as a reference inserted into
the TSDB for performance monitoring. It is not a reference for the
timestamp itself.
2. Synchronous Ethernet. Each platform should be synchronized to a
primary reference clock (PRC) and use G.8261, G.8262 and G.8264
ITU specifications.
3. IEEE 1588: Each platform should be frequency-synchronized to a
primary reference clock (PRC) and use IEEE 1588-2008 for frequency
distribution.
If a SF is not synchronized at the moment of time stamping, it should
indicate synch status in the NSH header. This is described in more
detail in section 5.
By synchronizing the network in this way, the time stamping operation
is independent of the current RSP, whether the entire chain is served
by one NFVI-PoP or by multiple. Indeed the time stamp MD can indicate
where a chain has been moved due to a resource starvation event as
indicated in the figure 2 below, between VNF 3 and VNF 4 at time B.
Delay
| v
| v
| x
| x x = UTC time A
| xv v = UTC time B
| xv
| xv
|______|______|______|______|______|_____
VNF1 VNF2 VNF3 VNF4 VNF5
Figure 2: Flow performance in a service chain
Browne Expires April 20, 2016 [Page 6]
Internet-Draft Network Service Header Time Stamping August 2015
Regarding draft-ietf-sfc-nsh-00, section 3.2. We would request that
the text is changed to reflect that MD-Type 0x2 MUST be supported to
aid methods like the one outlined in this draft.
3.2 Operation
Section 3.5 of draft-ietf-sfc-nsh-00.txt defines NSH metadata type 2
encapsulation as per the figure below. Please refer to the draft for
detailed explanation. Time stamed flows will use this format.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Class | Type |R|R|R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NSH MD type 2 Encapsulation
Flow Selection
The TS Controller should maintain a list of flows within each
service chain to be monitored. This flow table should be in the
format SPI:5 tuple ID. The TS Controller should map these pairs to
unique Flow IDs per service chain within the extended NSH header
specified in this draft. The TS Controller should instruct the FTSN
node initiate timestamping on flow table match. The TS Controller
should also tell the classifier the duration of the time stamping
operation, either by number of packets in the flow or a duration in
UTC format.
In this way the system can monitor the performance of an individual
subscriber in a chain or just a specific application the subscriber
is running.
The TS Controller should write the list of monitored flows into the
TSDB for correlation of performance data. Thus when the TSDB
receives data from the LTSN it understands to which flow the data
pertains.
The association of source IP to subscriber identity is outside the
scope of this draft and will vary by network application. For
example the method of association of a source IP to IMSI in mobile
cores will be different to how a CPE with NAT function may be
chained in an enterprise NFV application.
Browne Expires April 20, 2016 [Page 7]
Internet-Draft Network Service Header Time Stamping August 2015
TSCP Interface
A new timestamp control plane (TSCP) interface is required between
the TS Controller and the FTSN or classifier. This interface:-
- Communicates which chains:flows to timestamp. This can be a
specific chain:flow combination or include wildcards for
monitoring subscribers across multiple chains or multiple flows
within one chain.
- How the timestamp should be applied (ingress, egress, both or
specific)
- When to stop time stamping
Exact specification of TSCP is for further study.
3.3 Implementation
Whilst applying and operating on the timestamps themselves incur an
additional small delay in the service chain it can be assumed that
these additional delays are all relative for the flow in question.
Thus whist the absolute timestamps may not be fully accurate for
normal non-time stamped traffic they can be assumed to be relative.
It is assumed that the method described in this document would only
operate on a small percentage of user flows. The service provider
may choose a flexible policy in the TS Controller to time stamp a
selection of user-plane every minute for example to highlight any
performance issues. Of course the TS Controller can stress test an
individual flow or chain should a deeper analysis be required. We
can expect that this type of deep analysis has an impact on the
performance of the chain itself whilst under investigation. The
impact will be dependent on vendor implementation and outside the
scope of this document.
The timestamp may be applied at various parts of the NFV
architecture. The VNF, hypervisor (assuming no SRIOV pass-through),
vSwitch or NIC are all potential locations that's can append the
packet with the requested timestamp. Whilst it is desirable to
timestamp as close as possible to the VNF for performance accuracy,
the exact location of the timestamp application is outside the scope
of this document, but should be consistent across the individual
TS Controller domain.
Browne Expires April 20, 2016 [Page 8]
Internet-Draft Network Service Header Time Stamping August 2015
4. NSH Time stamping Encapsulation
NSH time stamping encapsulation is shown below in figure 4:-
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 | NextProto=0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Class=0x10 | Type=0x01 |R|R|R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UTC Reference |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Syn |R|E|I|TSI|TS Service Indx| Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Ingress Timestamp (I bit is set)(FTSN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Timestamp (E bit is set)(FTSN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Syn |R|E|I|TSI|TS Service Indx| Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Ingress Timestamp (I bit is set) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Timestamp (E bit is set) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Syn |R|E|I|TSI|TS Service Indx| Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Ingress Timestamp (I bit is set) (LTSN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Timestamp (E bit is set) (LTSN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: NSH Time Stamp Encapsulation
Relevant fields in header that the FTSN must implement:
The O bit should not be set as we are operating on subscriber packets
The C bit should be set indicating critical metadata exists
Browne Expires April 20, 2016 [Page 9]
Internet-Draft Network Service Header Time Stamping August 2015
The MD type must be set to 0x2
TLV Class must be set to 0x10 (General KPI Monitoring) as requested
in section 11, and in addition that we define the timestamp type to
be 0x01.
Type = 0x00 Reserved.
Type = 0x01 Timestamp.
The MSB of the Type field must be set to zero. Thus if a receiver
along the path does not understand the time stamping protocol it will
pass the packet transparently and not drop. This scheme allows for
extensibility to the mechanism described in this document to other
KPI collections and operations.
FTSN timestamp metadata contains Timestamp Service Index (TSI) field
which must be set as follows:
0x0 Timestamp mode, no Service index specified in the TS Service
Index field.
0x1 Timestamp Hybrid mode is selected, Time Stamp Service Index
contains LTSN Service index. This is used when PNFs or NSH-unaware
SFs are used at the tail of the chain. If TSI=0x1, then the value in
the type field informs the chain which SF should act as the LTSN.
0x2 Timestamp Specific mode is selected, Time Stamp Service Index
contains the targeted Service Index. In this case the Time Stamp
Service Index field indicates which SF is to be time stamped. Both
ingress and egress timestamps are performed when the SI=TSSI on the
chain. In this mode the FTSN will also apply UTC and ingress time
stamp. This will indicate the delay along the entire service chain to
the targeted SF. This method may also be used as a light
implementation to monitor end-to-end service chain performance
whereby the targeted SF is the LTSN.
The Flow ID is a unique 16 bit identifier written into the header by
the classifier. This allow 65536 flows to be concurrently timestamped
on any given NSH service chain (SPI). Flow IDs are not written by
subsequent SFs in the chain. The FTSN exports monitored flow IDs to
the TSDB for correlation.
The E bit should be set if Egress timestamp is requested.
The I bit should be set if Ingress timestamp is requested.
UTC reference is the wall clock of the FTSN, and may be used for
historical comparison of SC performance. If the FTSN is not
time-of-day synched it should inform the TS controller over the TSCP
interface.
Browne Expires April 20, 2016 [Page 10]
The Syn bits are an indication of the synchronization status of the
node performing the time stamp and must be set as follows:
In Synch: 0x00
In holdover: 0x01
In free run: 0x02
Out of Synch: 0x03
If the network node is out of synch or in free run no timestamp is
applied by the node (but other timestamp MD is applied) and the
packet is processed normally.
If FTSN is out of synch or in free run timestamp request rejected and
not propagated though the chain. The FTSN should inform the TS
controller in such an event over the TSCP interface.
The Outer service index value is copied into the timestamp metadata
to help cater for hybrid chains that's are a mix of VNFs and PNFs or
through SFs that do not understand NSH. Thus if a flow transits
through a PNF or a NSH-unaware node the delta in the inner service
index between time stamps will indicate this.
Timestamps are applied in PTP format (64 bit) and corresponding bits
(I and E) reported in the timestamp metadata header.
5. Hybrid Models
A hybrid chain may be defined as a chain whereby there is a mix of
NSH-aware and NSH-unaware SFs. This may be the case is some PNFs are
used in the chain or if VNFs are used that do not support NSH.
Example 1: PNF in the middle
TS
Controller
| TSDB
| TSCP Interface |
,---. ,---. ,---. ,---.
/ \ / \ / \ / \
( SCL )-------->( SF1 )--------->( SF2 )--------->( SFN )
\ FTSN/ \ / \ PNF1/ \ LTSN/
`---' `---' `---' `---'
Figure 5: Hybrid chain with PNF in middle
In this example the FTSN begins operation and sets the SI to 3, SF1
decrements this to 2 and passes the flow to a SFC proxy (not shown).
The proxy strips the NSH header and passes to the PNF. On receipt
back from the PNF the Proxy decrements the SI and passes the packet
onto the LTSN with a SI=1.
Browne Expires April 20, 2016 [Page 11]
After the LTSN processes the traffic it knows it is the last node on
the chain from the SI value and exports the entire NSH header and all
metadata to the TSDB. The payload is forwarded to the next hop on the
underlay minus the NSH header. The TS information packet is given a
new SPI which acts as a homing tag to transport the timestamp data
back to the TSDB.
Example 2: PNF at the end
TS
Controller
| TSDB
| TSCP Interface |
,---. ,---. ,---. ,---.
/ \ / \ / \ / \
( SCL )-------->( SF1 )--------->( SF2 )--------->( PNFN )
\ FTSN/ \ / \ LTSN/ \ /
`---' `---' `---' `---'
Figure 6: Hybrid Chain with PNF at end
In this example the FTSN begins operation and sets the SI to 3, the
TSI field set to 0x1, and the type to 1. Thus when SF2 receives the
packet with SI=1, it understands that it is expected to take on the
role of the LTSN as it is the last NSH-aware node in the chain.
5.1 Targeted VNF Time Stamp
For the majority of flows within the service chain, time stamps
(ingress,egress or both) will be carried out at each hop until the SI
decrements to zero and the NSH header and TS MD is exported to the
TSDB. There may exist however the need to just test a particular VNF
(perhaps after a scale out operation or software upgrade for
example). In this case the FTSN should mark the NSH header
as follows:-
TSI field is set to 0x2. Type is set to the expected SI at the SF in
question. When outer SI = type. Timestamps are applied at SF ingress,
egress and the NSH header and MD exported to the TSDB.
Browne Expires April 20, 2016 [Page 12]
6. Fragmentation Considerations
The method described in this draft does not support fragmentation.
The TS Controller should return an error should a time stamping
request from an external system exceed MTU limits and require
fragmentation.
Depending on the length of the payload and the type of timestamp and
chain length, this will vary for each packet.
In most service provider architectures we would expect a SI << 10,
and that may include some PNFs in the chain which do not add
overhead. Thus for typical IMIX packet sizes we expect to able to
perform time stamping on the vast majority of flows without
fragmenting.
7. Security Considerations
TBD
8. Open Items for WG Discussion
1. Specification and operation of TSCP
2. AOB
9. Acknowledgments
The authors would like to thank Ron Parker of Affirmed Networks and
Seungik Lee of ETRI for their reviews of this draft.
10. IANA Considerations
TLV Class Registry
IANA is requested to set up a registry of "TLV Types". These are
16-bit values. Registry entries are assigned by using the
"IETF Review" policy defined in RFC 5226 [RFC5226]. One new type is
required for KPI General Monitoring and time stamping type as
discussed above.
Browne Expires April 20, 2016 [Page 13]
11. References
11.1. Normative References
[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>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
February 2011.
[SFC-PS] Quinn, P., Ed. and T. Nadeau, Ed., "Service Function
Chaining Problem Statement", 2014,
<http://datatracker.ietf.org/doc/
draft-ietf-sfc-problem-statement/>.
[SFC-arch] Quinn, P., Ed. and J. Halpern, Ed., "Service Function
Chaining (SFC) Architecture", 2014,
<http://datatracker.ietf.org/doc/draft-quinn-sfc-arch>.
[dcalloc] Guichard, J., Smith, M., and S. Kumar, "Network Service
Header (NSH) Context Header Allocation (Data Center)",
2014,
<https://datatracker.ietf.org/doc/
draft-guichard-sfc-nsh-dc-allocation/>.
[moballoc] Napper, J. and S. Kumar, "NSH Context Header Allocation --
Mobility", 2014,
<https://datatracker.ietf.org/doc/
draft-napper-sfc-nsh-mobility-allocation/>.
Browne Expires April 20, 2016 [Page 14]
Author's Address
Rory Browne
Email: rory.browne@intel.com
Andrey Chilikin
Email: andrey.chilikin@intel.com
Brendan Ryan
Email: brendan.ryan@intel.com
Intel
Dromore House
Shannon
Co.Clare
Ireland
Browne Expires April 20, 2016 [Page 15]
