Internet Engineering Task Force A. Gray, Ed.
Internet-Draft Charter Communications
Intended status: Informational 25 September 2019
Expires: 28 March 2020
Sampled Traffic Streaming
draft-gray-sampled-streaming-01
Abstract
This document standardizes the means of requesting a sampled capture
stream from a router, receiving details about the resulting data
flow, and the structure of the data flow itself. This is
specifically tailored to having various hardware ASICs be able to
perform this operation as quickly as possible, by allowing
communication of the specific bit formats of headers applied to the
packet flow, in a way that enhances interoperability between sources
and sinks. Historically, NetFlow and its ilk have been used for
these use cases, however the growth in hardware forward speeds is far
outpacing the growth in CPU speeds, and the CPU-heavy parts of
NetFlow is resulting in a reduction of sampling rates that include
all of the fields provided by NetFlow that require CPU lookups.
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 https://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 28 March 2020.
Copyright Notice
Copyright (c) 2019 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 (https://trustee.ietf.org/
Gray Expires 28 March 2020 [Page 1]
Internet-Draft Sampled Traffic Streaming September 2019
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement / Operator Use Cases . . . . . . . . . . . 3
2.1. Use Case 1 : Traffic Analytics . . . . . . . . . . . . . 3
2.2. Use Case 2 : Network Behavior Verification . . . . . . . 3
2.3. Use Case 3 : Standardization . . . . . . . . . . . . . . 4
3. Stream Setup . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Data Stream Format . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Yang Model . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
1.1. 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].
1.2. Terminology
The following terms are used within this document:
Client: The device configuring the Replicator.
Receiver: The device that will be receiving the packet stream.
Replicator: The device doing the actual packet replication, as
requested by a Client, and sending it to a Receiver.
Point: The location inside the Replicator (generally a forwarding
ASIC) that performs the actual packet replication. There may be
multiple physical interfaces serviced by one Point, or one
Gray Expires 28 March 2020 [Page 2]
Internet-Draft Sampled Traffic Streaming September 2019
interface may be serviced by multiple Points, that may have
different capabilities.
2. Problem Statement / Operator Use Cases
This document is designed around the following use cases that
operators have today, or can foresee coming on the near horizon.
2.1. Use Case 1 : Traffic Analytics
At present, operators may use a mix of NetFlow, IPFIX, and inline
traffic samplers spread throughout the network to gather data for
analytics. With the next generation of hardware on the horizon, we
have 400Gb/s interfaces starting to become available, with faster
speeds already being talked about. This will require at least an
augmentation of any inline traffic samplers, which are quite
expensive. Additionally, the pace of growth in the data plane is
outgrowing the pace of growth in the control plane. This is
especially seen with relatively control plane or CPU heavy protocols
like NetFlow, where present sampling rates are simply not going to be
sustainable long-term, due to on-box control plane hardware
limitations. Being able to capture a filtered, sampled collection of
actual packets throughout the network is very valuable for
understanding how the network is being used, to provide hard data to
justify network topology augments or changes.
This proposal addresses this use case by making the data replication
as simple as possible for hardware forwarding ASICs to implement and
send off the device. This allows offloading the heavy calculations
to distributed infrastructure than can be scaled as needed using
commodity hardware.
2.2. Use Case 2 : Network Behavior Verification
This use case focuses on the potential ability to have the ASICs also
include packets that would normally be dropped, along with a reason
why. With bits denoting dropped due to QoS policies, buffer
contention, ACLs, etc., this traffic could be captured (potentially
at a sampling rate of 1:1, i.e. every packet) and sent off for off-
box analysis to determine if this was expected, or to provide alerts
that QoS policies may be having adverse effects on the network.
Here, including the packet payload provides a lot of additional data
for these platforms to effectively "second guess" these policies.
This proposal addresses this use case by explicitly including a field
for marking what an ASIC is going to do with a packet, and including
the payload of the resulting sample.
Gray Expires 28 March 2020 [Page 3]
Internet-Draft Sampled Traffic Streaming September 2019
2.3. Use Case 3 : Standardization
These problems are foreseen by various vendors, who are talking about
different variants of these sorts of traffic flows. Standardizing
the way these streams are formed and communicated between the
Replicators, Clients, and Receivers in a fashion that allows vendors
flexibility in what the ASIC has to do (by allowing communicating of
an extremely dynamic header in a manner than control planes can
manage) allows systems to be used between all compliant platforms.
The alternative is having to build independent systems for each form
of this sort of packet replication that may end up being developed,
resulting in much higher costs.
This proposal addresses this use case by allowing the packet header
to contain any combination of information, in any position and of any
length, to be dynamically determined and information about how to
handle this data to be exchanged between the Replicator, Client, and
Receiver. This allows ASICs to put on what information they can, in
the most efficient format for them.
3. Stream Setup
To begin, a Client utilizes a supported configuration method
(NETCONF, RESTCONF, gRPC, etc.) and the YANG model listed in
Appendix A. A Client must first request from the Replicator the
available configurations via the 'points' branch, which provides the
following information:
* A name of the Point.
* What interfaces this Point is servicing.
* If filtering is available, and if so, what filters can be applied
(against certain IP fields, against parts of the frame, etc.)
* Minimum and maximum sampling rates.
* Any current samplers already active off this Point.
* Optionally, the maximum frame length the Point can replicate into
the sample.
* Optionally, the maximum offset into a frame the Point can inspect.
* Optionally, the maximum number of samplers that this Point can
accommodate. A Client MUST still check for success, as highly
complex filters may reduce the amount of replication the Point can
do from this maximum.
Gray Expires 28 March 2020 [Page 4]
Internet-Draft Sampled Traffic Streaming September 2019
The Client then can request one or more streams to be set up on the
Replicator, using that information.
These individual streams may be configured with filters and a
sampling rate, with the replicated packets sent to the Receiver,
wrapped in an outer UDP header. The available filters are provided
by the Replicator in the response above - a common option will be for
what interface specifically to filter traffic against. The source
port of this UDP stream MUST be set to TBD1 by default - Replicators
MAY offer an ability to change this default. This is to allow
security filters to have a fixed value to key off of as an additional
defense to prevent these streams from being inadvertently sent to
undesirable locations.
The Client and Receiver MAY be separate devices. The mechanism of
exchanging information between Client and Receiver about the setup
process is outside the scope of this document.
4. Data Stream Format
After the stream setup, the Client MUST re-query the stream
configuration to get the stream-format data that the remote device
has calculated. The Client MUST NOT assume that the stream-format
data is consistent between one instance and any other performed
(there may be different versions of ASICs, different capabilities,
different versions of operating systems, or different filters may
yield a different format), or that the Payload is always at the end
(as it is the only variable-width field, it could appear at the
beginning or in the middle, and sufficient data is provided by the
other fields to extract the data correctly). This provides the
Client with what information is provided at what location in the
resulting packet. The Replicator MUST follow the expectation that is
provided in these fields.
One example of what the resulting packet may look like (but not a
nominative listing of what it is - the actual format can be any
combination of fields, of any size, in any order), the data inside
the resulting data stream after the UDP tunnel header may look like
the following:
Example layout:
Gray Expires 28 March 2020 [Page 5]
Internet-Draft Sampled Traffic Streaming September 2019
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Port | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Act| Frame Length | Internal Data 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
This non-normative example would be listed in the modeled data for
packet-format as per the following table:
+-----------+------+----------------+-----------------------------+
| Name | Size | Type | Type-Data |
+===========+======+================+=============================+
| Incoming | 8 | ingress-port | A listing of values that |
| port | | | may be seen in this field, |
| | | | mapped to interface-refs |
| | | | from [RFC8343]. |
+-----------+------+----------------+-----------------------------+
| Timestamp | 24 | timestamp-nsec | Two 32 bit numbers giving |
| | | | when the "0" of this field |
| | | | is based off of. |
+-----------+------+----------------+-----------------------------+
| Act | 2 | action | A listing of values that |
| | | | may be seen in this field, |
| | | | mapped to action types |
| | | | (accepted, dropped, etc.) |
+-----------+------+----------------+-----------------------------+
| Frame | 17 | frame-length | Note that this denotes the |
| Length | | | original frame length - the |
| | | | payload field MAY NOT |
| | | | include the entire payload. |
+-----------+------+----------------+-----------------------------+
| Internal | 13 | padding | |
| Data 1 | | | |
+-----------+------+----------------+-----------------------------+
| Payload | 0 | frame-payload | |
+-----------+------+----------------+-----------------------------+
Table 1: Example packet-format response
To restate the prior note, the above is purely an example of what the
format could be - the actual format used is negotiated between the
Gray Expires 28 March 2020 [Page 6]
Internet-Draft Sampled Traffic Streaming September 2019
Client and Replicator, and can have practically any layout, with any
additional fields.
To adequately addresses the use cases stated above, a Replicator
SHOULD support as a minimum set of capabilities:
* An action field that denotes a pass or drop (ideally with drop
reason)
* The payload of at least 128 octets
* The original frame length
* Sampling rates down to 1:1 (i.e. every packet is replicated)
* Having different sampling sessions having different sampling rates
(to allow a "general" session to be watching a broad selection of
traffic, and more specific sessions targeting exact flows or
situations)
* At least two sessions per physical interface
* Filtering on ingress port
* Filtering on action
* Filtering on direction of traffic
A Client SHOULD take efforts to be notified when a change has
occurred on the Replicator, and re-verify its replication
configurations when such a change is detected.
5. IANA Considerations
This document defines a new UDP port number, entitled "Sampled
Streaming", and assigns a value of TBD1 from the Service Name and
Transport Protocol Port Number Registry
https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.xhtml:
+------+-------------------+
| Tag | Description |
+======+===================+
| TBD1 | Sampled Streaming |
+------+-------------------+
Table 2
Gray Expires 28 March 2020 [Page 7]
Internet-Draft Sampled Traffic Streaming September 2019
This document requests registration of a URI in the "IETF XML
Registry" RFC 3688 [RFC3688]. Following the format in RFC 3688, the
following registration is suggested:
URI: urn:ietf:params:xml:ns:yang:ietf-sampled-streaming
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the "YANG Module Names"
registry RFC 6020 [RFC6020]:
name: ietf-sampled-streaming
namespace: urn:ietf:params:xml:ns:yang:ietf-sampled-streaming
prefix: ss
reference: This document
6. Security Considerations
Vendors and deployments must take into consideration that this
functionality allows a mirroring of traffic, with configurable
destinations and filters. Similar functionality already exists in
various remote packet mirroring systems, and similar considerations
should be taken. Filters utilizing the source port of TBD1 SHOULD be
applied at the edges of a provider's network to provide an additional
layer of security.
7. References
7.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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
Gray Expires 28 March 2020 [Page 8]
Internet-Draft Sampled Traffic Streaming September 2019
7.2. Informative References
Appendix A. Yang Model
module ietf-sampled-streaming {
namespace "urn:ietf:params:xml:ns:yang:ietf-sampled-streaming";
prefix "ss";
import ietf-yang-types {
prefix yang;
}
import ietf-interfaces {
prefix if;
}
import ietf-inet-types {
prefix inet;
}
organization
"IETF Working Group";
contact
"Editor: Andrew Gray
<mailto:Andrew.Gray@charter.com>";
description
"This module contains a collection of YANG definitions for
managing sampled streaming subscriptions.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
Gray Expires 28 March 2020 [Page 9]
Internet-Draft Sampled Traffic Streaming September 2019
revision 2019-08-06 {
description
"Updates based on feedback for -01 draft.";
reference
"draft-gray-sampled-streaming-01";
}
revision 2019-06-25 {
description
"Initial version.";
reference
"draft-gray-sampled-streaming-00";
}
typedef filter-type {
type enumeration {
enum interfaces {
description "List of interfaces to filter against.";
}
enum action {
description "Filter against a list of actions that the Point took (i.e., only consider packets that were actually forwarded).";
}
enum direction {
description "Direction to sample traffic in.";
}
enum ip-version {
description "The version number in the IP header.";
}
enum ip-v4-srcip {
description "The IPv4 header's source IPv4 address.";
}
enum ip-v4-dstip {
description "The IPv4 header's destination IPv4 address.";
}
enum ip-v4-ttl {
description "The IPv4 header's Time to Live.";
}
enum ip-v4-prot {
description "The IPv4 header's protocol number.";
}
enum ip-v6-srcip {
description "The IPv6 header's source IPv4 address.";
}
enum ip-v6-dstip {
description "The IPv6 header's destination IPv4 address.";
}
enum frame-size {
description "The total size of the frame.";
Gray Expires 28 March 2020 [Page 10]
Internet-Draft Sampled Traffic Streaming September 2019
}
enum frame-payload {
description "Specific payload octets.";
}
}
description "The filtering abilities available.";
}
typedef field-type {
type enumeration {
enum padding {
description "Padding bits that MUST be ignored.";
}
enum port {
description "An indication of the port the traffic was sampled from.";
}
enum direction {
description "Which direction the traffic went.";
}
enum ingress-port {
description "What port the traffic was received from (may be different than 'port')";
}
enum egress-port {
description "What port the traffic is leaving on (may be different than 'port')";
}
enum timestamp-msec {
description "The timestamp the packet was received at, in integer milliseconds.";
}
enum timestamp-usec {
description "The timestamp the packet was received at, in integer microseconds.";
}
enum timestamp-nsec {
description "The timestamp the packet was received at, in integer nanoseconds.";
}
enum frame-length {
description "The received frame length. Note that due to chipset capabilities, this MAY NOT be the same as the captured packet length.";
}
enum frame-payload {
description "The payload of the frame.";
}
enum action {
description "The action that was taken on this frame. Values are mapped as according to action-type.";
}
}
description "Types of data included in the data stream provided back to the receiver. Note that all fields will not be provided.";
}
typedef action-type {
Gray Expires 28 March 2020 [Page 11]
Internet-Draft Sampled Traffic Streaming September 2019
type enumeration {
enum forwarded {
description "Forwarded normally through the system.";
}
enum dropped {
description "Generically dropped. A more specific action type code should be used, if possible.";
}
enum dropped-rate-limit {
description "Dropped due to a rate limiter applied.";
}
enum dropped-buffer {
description "Dropped due to no buffer space.";
}
enum dropped-security {
description "Dropped due to a security policy.";
}
enum dropped-error {
description "Dropped due to the frame being in error.";
}
enum remarked {
description "Frame was remarked and forwarded.";
}
}
description "Possible actions taken on a packet.";
}
typedef destination-type {
type enumeration {
enum udp {
description "Sent with a UDP header.";
}
}
description "Different possible destination types.";
}
typedef direction-type {
type enumeration {
enum ingress {
description "Traffic flowing into the Replicator.";
}
enum egress {
description "Traffic flowing out of the Replicator.";
}
enum both {
description "Capture both ingress and egress traffic.";
}
}
description "Different possible direction types.";
Gray Expires 28 March 2020 [Page 12]
Internet-Draft Sampled Traffic Streaming September 2019
}
list points {
description "A listing of the capture points available on this device, what ports they provide for, and what filtering is available at those points.";
key name;
leaf name {
type string;
description "The name of this capture point.";
}
list interface {
description "List of interfaces that are available at this point.";
config false;
leaf if {
mandatory true;
type if:interface-ref;
description "An interface tied to this capture point.";
}
}
list filters {
description "List of filtering options available at this point.";
config false;
leaf filter {
description "One specific filter available at this point.";
mandatory true;
type filter-type;
}
}
leaf min-ratio {
type uint32 {
range "1..max";
}
description "The minimum sampling ratio (1:N, with N being this value) this point can provide.";
}
leaf max-ratio {
type uint32 {
range "1..max";
}
description "The maximum sampling ratio (1:N, with N being this value) this point can provide.";
}
leaf max-samplers {
type uint32;
description "The maximum number of samplers that can be installed at this point.";
}
leaf max-filters {
type uint32;
description "The maximum number of filtering rules permitted at this location. Note this is an absolute maximum, and fewer rules that are complex may still be rejected by the device.";
}
leaf max-frame-length-copy {
Gray Expires 28 March 2020 [Page 13]
Internet-Draft Sampled Traffic Streaming September 2019
type uint16;
description "The maximum size that the point can replicate and copy into the header.";
}
leaf max-frame-depth-inspect {
type uint16;
description "The offset of the last octet in a frame the ASIC can perform filtering against.";
}
list samplers {
description "A list of all the samplers attached to this point.";
config true;
key "name";
leaf name {
mandatory true;
type string;
description "A unique name given to this sampler.";
}
container destination {
description "The destination of where to send the UDP stream to.";
leaf type {
mandatory true;
type destination-type;
description "The type of encoding for the destination.";
}
container udp-parameters {
description "Parameters for destination-type=udp. Source port is always the port number assigned by IANA.";
when "../type='udp'";
leaf destination-ip {
mandatory true;
type inet:ip-address-no-zone;
description "The destination IP to send the stream to.";
}
leaf destination-port {
mandatory true;
type inet:port-number;
description "The destination UDP port number to send the stream to.";
}
}
}
leaf ratio {
mandatory true;
type uint32 {
range "1..max";
}
Gray Expires 28 March 2020 [Page 14]
Internet-Draft Sampled Traffic Streaming September 2019
description "The requested sampling ratio (1:N, with N being this value).";
}
list filters {
description "A list of filters applied to this sampling. Multiple filters are logically ANDed together.";
key "name";
leaf name {
description "A name for this filter.";
type string;
}
list interfaces {
when "../type = 'interfaces'";
description "Filter down to only this list of interfaces.";
key "int";
leaf int {
description "A specific interface to filter against.";
type if:interface-ref;
}
}
list actions {
when "../type = 'action'";
description "Filter down to only this list of actions.";
key "action";
leaf action {
description "One specific action code.";
type action-type;
}
}
list directions {
when "../type = 'direction'";
description "Which direction(s) to sample traffic in.";
key "direction";
leaf direction {
description "Specific direction code.";
type direction-type;
}
}
leaf type {
description "The type of filter associated.";
type filter-type;
mandatory true;
}
Gray Expires 28 March 2020 [Page 15]
Internet-Draft Sampled Traffic Streaming September 2019
leaf ipv4-address {
when "../type = 'ip-v4-srcip' | ../type = 'ip-v4-dstip'";
type inet:ipv4-address-no-zone;
description "The IPv4 address to filter on.";
}
leaf ipv6-address {
when "../type = 'ip-v6-srcip' | ../type = 'ip-v6-dstip'";
type inet:ipv6-address-no-zone;
description "The IPv6 address to filter on.";
}
leaf version {
when "../type = 'ip-version'";
type inet:ip-version;
description "The value of the IP version number to match on.";
}
container frame-payload {
when "../type = 'frame-payload'";
description "Frame payload fragment to match on.";
leaf offset {
description "Offset in octets from the start of the frame to begin the match on.";
type uint16;
}
leaf match {
description "The bytes to match on.";
type binary;
}
}
leaf frame-length {
when "../type = 'frame-length'";
type uint16;
description "Frame length to match on.";
}
}
container stream-format {
config false;
description "This contains the packet format data that this sampling stream is sending. This is only valid after configuration. The length fields are given in bits, and are consecutive. Needed gaps should use a 'padding' element.";
list fields {
description "The listing of the fields that will be encapsulated and sent to the receiver.";
key "name";
leaf name {
Gray Expires 28 March 2020 [Page 16]
Internet-Draft Sampled Traffic Streaming September 2019
type string;
description "Human readable name of what this field contains.";
}
leaf size {
type uint32 {
range "0..524280";
}
description "The size of this field, in bits. The value of '0' denotes a variable-sized field, which is only permitted as the last field in this definition.";
}
leaf type {
type field-type;
description "The type of this data.";
}
list action-mappings {
description "The mapping of values to action-type codes, valid for type=action.";
key "value";
when "../type='action'";
leaf value {
type binary;
description "The value that will appear in the header.";
}
leaf meaning {
type action-type;
description "What this value indicates.";
}
}
list port-mappings {
description "The mapping of values to interfaces, valid for type=ingress-port or type=egress-port";
key "value";
when "../type='ingress-port' | ../type='egress-port'";
leaf value {
type binary;
description "The value that will appear in the header.";
}
leaf port {
type if:interface-ref;
description "The port the value maps to.";
}
}
list direction-mappings {
description "The mapping of values to direction codes, valid for type=direction.";
key "value";
when "../type='direction'";
leaf value {
type binary;
Gray Expires 28 March 2020 [Page 17]
Internet-Draft Sampled Traffic Streaming September 2019
description "The value that will appear in the header.";
}
leaf direction {
type direction-type;
description "The direction the traffic in respect to the port.";
}
}
container timestamp {
description "Supplemental data for type=timestamp*, in PTP Truncated Timestamp Format. Provides the time used as the epoch for the number in the data stream.";
when "../type='timestamp-nsec' | ../type='timestamp-usec' | ../type='timestamp-msec'";
leaf seconds {
type uint32;
description "Specifies the integer portion of the number of seconds since the epoch.";
}
leaf nanoseconds {
type uint32;
description "Specifies the fractional portion of the number of seconds since the epoch, in integer number of nanoseconds.";
}
}
}
}
}
}
}
Author's Address
Andrew Gray (editor)
Charter Communications
8560 Upland Drive, Suite B
Englewood, CO 80112
United States
Phone: +1 720 699 5125
Email: Andrew.Gray@charter.com
Gray Expires 28 March 2020 [Page 18]