Encapsulations for In-situ OAM Data
draft-brockners-inband-oam-transport-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Frank Brockners , Shwetha Bhandari , Vengada Prasad Govindan , Carlos Pignataro , Hannes Gredler , John Leddy , Stephen Youell , Tal Mizrahi , David Mozes , Petr Lapukhov , Remy Chang <> | ||
| Last updated | 2017-03-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-brockners-inband-oam-transport-03
ippm F. Brockners
Internet-Draft S. Bhandari
Intended status: Informational V. Govindan
Expires: September 13, 2017 C. Pignataro
Cisco
H. Gredler
RtBrick Inc.
J. Leddy
Comcast
S. Youell
JMPC
T. Mizrahi
Marvell
D. Mozes
Mellanox Technologies Ltd.
P. Lapukhov
Facebook
R. Chang
Barefoot Networks
March 12, 2017
Encapsulations for In-situ OAM Data
draft-brockners-inband-oam-transport-03
Abstract
In-situ Operations, Administration, and Maintenance (OAM) records
operational and telemetry information in the packet while the packet
traverses a path between two points in the network. In-situ OAM is
to complement current out-of-band OAM mechanisms based on ICMP or
other types of probe packets. This document outlines how in-situ OAM
data fields can be transported in protocols such as NSH, Segment
Routing, VXLAN-GPE, native IPv6 (via extension headers), and IPv4.
Transport options are currently investigated as part of an
implementation study. This document is intended to only serve
informational purposes.
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/.
Brockners, et al. Expires September 13, 2017 [Page 1]
Internet-Draft In-situ OAM Data Transport March 2017
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2017.
Copyright Notice
Copyright (c) 2017 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
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. In-Situ OAM Metadata Transport in IPv6 . . . . . . . . . . . 4
3.1. In-situ OAM in IPv6 Hop by Hop Extension Header . . . . . 5
3.1.1. In-situ OAM Hop by Hop Options . . . . . . . . . . . 5
4. In-situ OAM Metadata Transport in IPv4 . . . . . . . . . . . 6
4.1. In-situ OAM Metadata Transport in GRE . . . . . . . . . . 6
5. In-situ OAM Metadata Transport in VXLAN-GPE . . . . . . . . . 9
6. In-situ OAM Metadata Transport in NSH . . . . . . . . . . . . 11
6.1. In-situ OAM Tracing in NSH . . . . . . . . . . . . . . . 11
6.2. In-situ OAM POT in NSH . . . . . . . . . . . . . . . . . 13
6.3. In-situ OAM Edge-to-Edge in NSH . . . . . . . . . . . . . 14
7. In-situ OAM Metadata Transport in Segment Routing . . . . . . 15
7.1. In-situ OAM in SR with IPv6 Transport . . . . . . . . . . 15
7.2. In-situ OAM in SR with MPLS Transport . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Manageability Considerations . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Brockners, et al. Expires September 13, 2017 [Page 2]
Internet-Draft In-situ OAM Data Transport March 2017
1. Introduction
This document discusses transport mechanisms for "in-situ"
Operations, Administration, and Maintenance (OAM) data fields. In-
situ OAM records OAM information within the packet while the packet
traverses a particular network domain. The term "in-situ" refers to
the fact that the OAM data is added to the data packets rather than
is being sent within packets specifically dedicated to OAM. A
discussion of the motivation and requirements for in-situ OAM can be
found in [I-D.brockners-inband-oam-requirements]. Data types and
data formats for in-situ OAM are defined in
[I-D.brockners-inband-oam-data].
This document outlines transport encapsulations for the in-situ OAM
data defined in [I-D.brockners-inband-oam-data]. This document is to
serve informational purposes only. As part of an in-situ OAM
implementation study different protocol encapsulations for in-situ
OAM data are being explored. Once data formats and encapsulation
approaches are settled, protocol specific specifications for in-situ
OAM data transport will address the standardization aspect.
The data for in-situ OAM defined in [I-D.brockners-inband-oam-data]
can be carried in a variety of protocols based on the deployment
needs. This document discusses transport of in-situ OAM data for the
following protocols:
o IPv6
o IPv4
o VXLAN-GPE
o NSH
o Segment Routing (IPv6 and MPLS)
This list is non-exhaustive, as it is possible to carry the in-situ
OAM data in several other protocols and transports.
A feasibility study of in-situ OAM is currently underway as part of
the FD.io project [FD.io]. The in-situ OAM implementation study
should be considered as a "tool box" to showcase how "in-situ" OAM
can complement probe-packet based OAM mechanisms for different
deployments and packet transport formats. For details, see the open
source code in the FD.io [FD.io].
Brockners, et al. Expires September 13, 2017 [Page 3]
Internet-Draft In-situ OAM Data Transport March 2017
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Abbreviations used in this document:
IOAM: In-situ Operations, Administration, and Maintenance
MTU: Maximum Transmit Unit
NSH: Network Service Header
OAM: Operations, Administration, and Maintenance
POT: Proof of Transit
SFC: Service Function Chain
SID: Segment Identifier
SR: Segment Routing
VXLAN-GPE: Virtual eXtensible Local Area Network, Generic Protocol
Extension
3. In-Situ OAM Metadata Transport in IPv6
This mechanisms of in-situ OAM in IPv6 complement others proposed to
enhance diagnostics of IPv6 networks, such as the IPv6 Performance
and Diagnostic Metrics Destination Option described in
[I-D.ietf-ippm-6man-pdm-option]. The IP Performance and Diagnostic
Metrics Destination Option is destination focused and specific to
IPv6, whereas in-situ OAM is performed between end-points of the
network or a network domain where it is enabled and used.
A historical note: The idea of IPv6 route recording was originally
introduced by [I-D.kitamura-ipv6-record-route] back in year 2000.
With IPv6 now being generally deployed and new concepts such as
Segment Routing [I-D.ietf-spring-segment-routing] being introduced,
it is imperative to further mature the Operations, Administration,
and Maintenance mechanisms available to IPv6 networks.
The in-situ OAM options translate into options for an IPv6 hop by hop
extension header. The extension header would be inserted by either a
host source of the packet, or by a transit/domain-edge node. If the
addition of the in-situ OAM Hop-by-Hop Option header would lead to
Brockners, et al. Expires September 13, 2017 [Page 4]
Internet-Draft In-situ OAM Data Transport March 2017
the packet exceeding the MTU of the domain an error should be
reported. The methods and procedures of how the error is reported
are outside the scope of this document. Likewise if an ICMPv6
forwarding error occurs between encapsulating and decapsulating
nodes, the node generating the ICMPv6 error should strip the in-situ
OAM Hop-by-Hop Option header before sending the ICMPv6 message to the
source.
3.1. In-situ OAM in IPv6 Hop by Hop Extension Header
This section defines in-situ OAM for IPv6 transport. In-situ OAM
Options are transported in IPv6 hop-by-hop extension header.
3.1.1. In-situ OAM Hop by Hop Options
IPv6 hop-by-hop option format for carrying in-situ OAM data fields:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | |
. . I
. Option Data . O
. . A
. . M
. . .
. . O
. . P
. . T
. . I
. . O
. . N
. . |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
Option Type 8-bit identifier of the type of option.
Opt Data Len 8-bit unsigned integer. Length of the
Reserved and Option Data field of this option,
in octets.
Reserved (MBZ) 16-bit field MUST be filled with zeroes.
Option Data Variable-length field. Option-Type-specific
data.
Brockners, et al. Expires September 13, 2017 [Page 5]
Internet-Draft In-situ OAM Data Transport March 2017
In-situ OAM Options are inserted as Option data as follows:
1. Pre-allocated Tracing Option: The in-situ OAM Preallocated
Tracing option defined in [I-D.brockners-inband-oam-data] is
represented as a IPv6 option in hop by hop extension header by
allocating following type:
Option Type: 001xxxxxx 8-bit identifier of the type of option.
xxxxxx=TBD_IANA_PRE_TRACE_OPTION_IPV6.
2. Incremental Tracing Option: The in-situ OAM Incremental Tracing
option defined in [I-D.brockners-inband-oam-data] is represented
as a IPv6 option in hop by hop extension header by allocating
following type:
Option Type: 001xxxxxx 8-bit identifier of the type of option.
xxxxxx=TBD_IANA_INCR_TRACE_OPTION_IPV6.
3. Proof of Transit Option: The in-situ OAM POT option defined in
[I-D.brockners-inband-oam-data] is represented as a IPv6 option
in hop by hop extension header by allocating following type:
Option Type: 001xxxxxx 8-bit identifier of the type of option.
xxxxxx=TBD_IANA_POT_OPTION_IPV6.
4. Edge to Edge Option: The in-situ OAM E2E option defined in
[I-D.brockners-inband-oam-data] is represented as a IPv6 option
in hop by hop extension header by allocating following type:
Option Type: 000xxxxxx 8-bit identifier of the type of option.
xxxxxx=TBD_IANA_E2E_OPTION_IPV6.
4. In-situ OAM Metadata Transport in IPv4
Transport of in-situ OAM data in IPv4 will use GRE encapsulation.
4.1. In-situ OAM Metadata Transport in GRE
GRE encapsulation is defined in [RFC2784]. IOAM is defined as a
"Protocol Type" TBD_IANA_ETHERNET_NUMBER_IOAM and follows GRE header.
The different IOAM data fields defined in
[I-D.brockners-inband-oam-data] are added as options within a new
IOAM protocol header following GRE header. In an administrative
domain where IOAM is used, insertion of the IOAM protocol header in
GRE is enabled at the GRE tunnel endpoints which also serve as IOAM
encapsulating/decapsulating nodes by means of configuration.
Brockners, et al. Expires September 13, 2017 [Page 6]
Internet-Draft In-situ OAM Data Transport March 2017
In-situ OAM header following GRE header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|C| Reserved0 | Ver | Protocol Type | G
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R
| Checksum (optional) | Reserved1 (Optional) | E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| Version | IOAM HDR len | Next Protocol Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM
| IOAM options | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| |
| |
| Payload + Padding (L2/L3/ESP/...) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GRE header and fields are defined in [RFC2784] with Protocol Type
set to TBD_IANA_ETHERNET_NUMBER_IOAM. IOAM specific fields and
header are defined here:
Version: 8-bit unsigned integer defining IOAM protocol version.
IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR
in 8-octet units.
Next Protocol Type: 16 bits Next Protocol Type field contains the
protocol type of the packet following IOAM protocol header. These
Protocol Types are defined in [RFC3232] as "ETHER TYPES" and in
[ETYPES]. An implementation receiving a packet containing a
Protocol Type which is not listed in [RFC3232] or [ETYPES] SHOULD
discard the packet.
IOAM options: Variable-length field, of length such that the
complete in-situ OAM header is an integer multiple of 8 octets
long. Contains one or more TLV-encoded options of the format:
Brockners, et al. Expires September 13, 2017 [Page 7]
Internet-Draft In-situ OAM Data Transport March 2017
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| .
. .
. Option Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit identifier of the type of option.
Opt Data Len 8-bit unsigned integer. Length of the
Option Data field of this option, in octets.
Option Data Variable-length field. Option-Type-specific
data.
The IOAM data fields defined in [I-D.brockners-inband-oam-data] are
encoded with an option type allocated in the new IOAM IANA registry -
IOAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In addition the following
padding options are defined to be used when necessary to align
subsequent options and to pad out the containing header to a multiple
of 8 octets in length.
Pad1 option (alignment requirement: none)
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE: The format of the Pad1 option is a special case -- it does
not have length and value fields.
The Pad1 option is used to insert one octet of padding into the
Options area of a header. If more than one octet of padding is
required, the PadN option, described next, should be used, rather
than multiple Pad1 options.
PadN option (alignment requirement: none)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN option is used to insert two or more octets of padding
into the Options area of a header. For N octets of padding, the
Opt Data Len field contains the value N-2, and the Option Data
consists of N-2 zero-valued octets.
Brockners, et al. Expires September 13, 2017 [Page 8]
Internet-Draft In-situ OAM Data Transport March 2017
5. In-situ OAM Metadata Transport in VXLAN-GPE
VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe] encapsulation is somewhat similar
to IPv6 extension headers in that a series of headers can be
contained in the header as a linked list. The different iIOAM types
are added as options within a new IOAM protocol header in VXLAN GPE.
In an administrative domain where IOAM is used, insertion of the IOAM
protocol header in VXLAN GPE is enabled at the VXLAN GPE tunnel
endpoint which also serve as IOAM encapsulating/decapsulating nodes
by means of configuration.
In-situ OAM header in VXLAN GPE header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Ethernet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer IP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer UDP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|R|R|Ver|I|P|R|O| Reserved | NP = IOAM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE
| Virtual Network Identifier (VNI) | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Type =IOAM | IOAM HDR len | Reserved | Next Protocol | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IOAM
| IOAM options | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| |
| Payload + Padding (L2/L3/ESP/...) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The VXLAN-GPE header and fields are defined in
[I-D.ietf-nvo3-vxlan-gpe]. IOAM specific fields and header are
defined here:
Type: 8-bit unsigned integer defining IOAM header type
IOAM HDR len: 8-bit unsigned integer. Length of the in-situ OAM HDR
in 8-octet units
Reserved: 8-bit reserved field MUST be set to zero.
Brockners, et al. Expires September 13, 2017 [Page 9]
Internet-Draft In-situ OAM Data Transport March 2017
Next Protocol: 8-bit unsigned integer that determines the type of
header following IOAM protocol. The value is from the IANA
registry setup for VXLAN GPE Next Protocol defined in
[I-D.ietf-nvo3-vxlan-gpe].
IOAM options: Variable-length field, of length such that the
complete IOAM header is an integer multiple of 8 octets long.
Contains one or more TLV-encoded options of the format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | Reserved (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Option Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit identifier of the type of option.
Opt Data Len 8-bit unsigned integer. Length of the
Option Data field of this option, in octets.
Reserved (MBZ) 16-bit field MUST be filled with zeroes.
Option Data Variable-length field. Option-Type-specific
data.
The in-situ OAM options defined in [I-D.brockners-inband-oam-data]
are encoded with an option type allocated in the new in-situ OAM IANA
registry - in-situ OAM_PROTOCOL_OPTION_REGISTRY_IANA_TBD. In
addition the following padding options are defined to be used when
necessary to align subsequent options and to pad out the containing
header to a multiple of 8 octets in length.
Brockners, et al. Expires September 13, 2017 [Page 10]
Internet-Draft In-situ OAM Data Transport March 2017
Pad1 option (alignment requirement: none)
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE: The format of the Pad1 option is a special case -- it does
not have length and value fields.
The Pad1 option is used to insert one octet of padding into the
Options area of a header. If more than one octet of padding is
required, the PadN option, described next, should be used, rather
than multiple Pad1 options.
PadN option (alignment requirement: none)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
The PadN option is used to insert two or more octets of padding
into the Options area of a header. For N octets of padding, the
Opt Data Len field contains the value N-2, and the Option Data
consists of N-2 zero-valued octets.
6. In-situ OAM Metadata Transport in NSH
6.1. In-situ OAM Tracing in NSH
In Service Function Chaining (SFC) [RFC7665], the Network Service
Header (NSH) [I-D.ietf-sfc-nsh] already includes path tracing
capabilities [I-D.penno-sfc-trace]. Tracing information can be
carried in-situ as IOAM data fields over NSH Type 2 metadata TLVs.
Brockners, et al. Expires September 13, 2017 [Page 11]
Internet-Draft In-situ OAM Data Transport March 2017
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Class= TBD |C| Type=Trace |R| Len=n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Octets-left | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| | |
| node data list [0] | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D
| | a
| node data list [1] | t
| | a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ p
| | a
| node data list [n-1] | c
| | e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| node data list [n] | |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-++
TLV Class: Describes the scope of the "Type" field. In some cases,
the TLV Class will identify a specific vendor, in others, the TLV
Class will identify specific standards body allocated types.
TRACE is currently defined using the TBD TLV class.
C bit: Critical bit, See [I-D.ietf-sfc-nsh] for description.
Type: The specific type of information being carried, within the
scope of a given TLV Class. Value allocation is the
responsibility of the TLV Class owner. A type value of
0xTBD_NSH_IOAM_TRACE is used for IOAM Preallocated trace option.
Reserved bits and R-bits: one reserved bit is present for future
use. The reserved bits MUST be set to 0x0.
Length: Length of the variable metadata octets.
IOAM-trace-type: 16-bit identifier of IOAM Trace Type as defined in
[I-D.brockners-inband-oam-data] IOAM-Trace-Types.
Octets-left: 8-bit unsigned integer as defined in
[I-D.brockners-inband-oam-data].
Brockners, et al. Expires September 13, 2017 [Page 12]
Internet-Draft In-situ OAM Data Transport March 2017
Flags 8-bit field as defined in [I-D.brockners-inband-oam-data].
Node data List [n]: Variable-length field as defined in
[I-D.brockners-inband-oam-data].
6.2. In-situ OAM POT in NSH
The "Proof of Transit" capabilities (see
[I-D.brockners-inband-oam-requirements] and
[I-D.brockners-proof-of-transit]) of in-situ OAM can be leveraged
within NSH. In an administrative domain where in-situ OAM is used,
insertion of the in-situ OAM data into the NSH header is enabled at
the required nodes (i.e. at the in-situ OAM encapsulating/
decapsulating nodes) by means of configuration.
Proof of transit in-situ OAM data is added as NSH Type 2 metadata:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Class=TBD |C| Type=POT |R| Len=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|IOAM POT Type|P| Reserved (MBZ) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Random | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| Random(contd.) | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Cumulative | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Cumulative (contd.) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
TLV Class: Describes the scope of the "Type" field. In some cases,
the TLV Class will identify a specific vendor, in others, the TLV
Class will identify specific standards body allocated types. POT
is currently defined using the Cisco (0x0009) TLV class.
C bit: Critical bit, See [I-D.ietf-sfc-nsh] for description.
Type: The specific type of information being carried, within the
scope of a given TLV Class. Value allocation is the
responsibility of the TLV Class owner. A type value of
0xTBD_NSH_IOAM_POT is used.
Reserved bit: one reserved bit is present for future use. The
reserved bits MUST be set to 0x0.
Brockners, et al. Expires September 13, 2017 [Page 13]
Internet-Draft In-situ OAM Data Transport March 2017
Length: Length of the variable metadata, in octets. Here the length
is 20.
IOAM POT Type: 7-bit identifier of a particular POT variant that
dictates the POT data that is included as defined in
[I-D.brockners-inband-oam-data].
Profile to use (P): 1-bit as defined in
[I-D.brockners-inband-oam-data] IOAM POT Option.
Reserved (MBZ): 24-bit field MUST be filled with zeroes.
Random: 64-bit Per-packet Random number.
Cumulative: 64-bit Cumulative that is updated by the Service
Functions.
6.3. In-situ OAM Edge-to-Edge in NSH
The "Edge-to-Edge" capabilities (see
[I-D.brockners-inband-oam-requirements]) of in-situ OAM can be
leveraged within NSH. In an administrative domain where in-situ OAM
is used, insertion of the in-situ OAM data into the NSH header is
enabled at the required nodes (i.e. at the in-situ OAM encapsulating/
decapsulating nodes) by means of configuration.
Edge-to-Edge in-situ OAM data is added as NSH Type 2 metadata:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Class=TBD |C| Type=E2E |R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|IOAM E2E Type | Reserved (MBZ) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E2E
| E2E Option data field determined by IOAM-E2E-Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
TLV Class: Describes the scope of the "Type" field. In some cases,
the TLV Class will identify a specific vendor, in others, the TLV
Class will identify specific standards body allocated types. POT
is currently defined using the Cisco (0x0009) TLV class.
C bit: Critical bit, See [I-D.ietf-sfc-nsh] for description.
Type: The specific type of information being carried, within the
scope of a given TLV Class. Value allocation is the
Brockners, et al. Expires September 13, 2017 [Page 14]
Internet-Draft In-situ OAM Data Transport March 2017
responsibility of the TLV Class owner. Currently a type value of
0xTBD_NSH_IOAM_E2E is used.
Reserved bits and R-bits: one reserved bit is present for future
use. The reserved bits MUST be set to 0x0.
Length: Length of the variable metadata, in octets.
IOAM E2E Type: 8-bit identifier of a particular E2E variant that
dictates the POT data that is included as defined in
[I-D.brockners-inband-oam-data].
Reserved (MBZ): 24-bit field MUST be filled with zeroes.
E2E Option data field: Variable length field as defined in
[I-D.brockners-inband-oam-data] IOAM E2E Option.
7. In-situ OAM Metadata Transport in Segment Routing
7.1. In-situ OAM in SR with IPv6 Transport
Similar to NSH, a policy defined using Segment Routing for IPv6 can
be verified using the in-situ OAM "Proof of Transit" approach. The
Segment Routing Header (SRH) for IPv6 offers the ability to transport
TLV structured data, similar to what NSH does (see
[I-D.ietf-6man-segment-routing-header]). In an domain where in-situ
OAM is used, insertion of the in-situ OAM data is enabled at the
required edge nodes (i.e. at the in-situ OAM encapsulating/
decapsulating nodes) by means of configuration.
A new "POT TLV" is defined for the SRH which is to carry proof of
transit in situ OAM data.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED |F| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|IOAM POT Type|P| Reserved (MBZ) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Random | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P
| Random(contd.) | O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Cumulative | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Cumulative (contd.) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
Brockners, et al. Expires September 13, 2017 [Page 15]
Internet-Draft In-situ OAM Data Transport March 2017
Type: To be assigned by IANA.
Length: 20.
RESERVED: 8 bits. SHOULD be unset on transmission and MUST be
ignored on receipt.
F: 1 bit. Indicates which POT-profile is active. 0 means the even
POT-profile is active, 1 means the odd POT-profile is active.
Flags: 8 bits. No flags are defined in this document.
IOAM POT Type: 7-bit identifier of a particular POT variant that
dictates the POT data that is included as defined in
[I-D.brockners-inband-oam-data].
Profile to use (P): 1-bit as defined in
[I-D.brockners-inband-oam-data] IOAM POT Option.
Reserved (MBZ): 24-bit field MUST be filled with zeroes.
Random: 64-bit per-packet random number.
Cumulative: 64-bit cumulative value that is updated at specific
nodes that form the service path to be verified.
7.2. In-situ OAM in SR with MPLS Transport
In-situ OAM "Proof of Transit" data can also be carried as part of
the MPLS label stack. Details will be addressed in a future version
of this document.
8. IANA Considerations
IANA considerations will be added in a future version of this
document.
9. Manageability Considerations
Manageability considerations will be addressed in a later version of
this document..
10. Security Considerations
Security considerations will be addressed in a later version of this
document. For a discussion of security requirements of in-situ OAM,
please refer to [I-D.brockners-inband-oam-requirements].
Brockners, et al. Expires September 13, 2017 [Page 16]
Internet-Draft In-situ OAM Data Transport March 2017
11. Acknowledgements
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, Stefano Previdi, Hemant Singh, Erik Nordmark, LJ Wobker,
and Andrew Yourtchenko for the comments and advice. The authors
would like to acknowledge Craig Hill for contributing GRE IOAM
encapsulation. For the IPv6 encapsulation, this document leverages
and builds on top of several concepts described in
[I-D.kitamura-ipv6-record-route]. The authors would like to
acknowledge the work done by the author Hiroshi Kitamura and people
involved in writing it.
12. References
12.1. Normative References
[ETYPES] "IANA Ethernet Numbers",
<https://www.iana.org/assignments/ethernet-numbers/
ethernet-numbers.xhtml>.
[I-D.brockners-inband-oam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., and R. <>, "Data Formats for In-situ OAM", draft-
brockners-inband-oam-data-02 (work in progress), October
2016.
[I-D.brockners-inband-oam-requirements]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi,
T., <>, P., and r. remy@barefootnetworks.com,
"Requirements for In-situ OAM", draft-brockners-inband-
oam-requirements-02 (work in progress), October 2016.
[I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-05 (work in progress), February
2017.
[I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-03 (work
in progress), October 2016.
Brockners, et al. Expires September 13, 2017 [Page 17]
Internet-Draft In-situ OAM Data Transport March 2017
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), February 2017.
[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>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<http://www.rfc-editor.org/info/rfc2784>.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
January 2002, <http://www.rfc-editor.org/info/rfc3232>.
12.2. Informative References
[FD.io] "Fast Data Project: FD.io", <https://fd.io/>.
[I-D.brockners-proof-of-transit]
Brockners, F., Bhandari, S., Dara, S., Pignataro, C.,
Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof
of Transit", draft-brockners-proof-of-transit-02 (work in
progress), October 2016.
[I-D.ietf-ippm-6man-pdm-option]
Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com,
"IPv6 Performance and Diagnostic Metrics (PDM) Destination
Option", draft-ietf-ippm-6man-pdm-option-08 (work in
progress), February 2017.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-10 (work in progress), November
2016.
[I-D.kitamura-ipv6-record-route]
Kitamura, H., "Record Route for IPv6 (PR6) Hop-by-Hop
Option Extension", draft-kitamura-ipv6-record-route-00
(work in progress), November 2000.
Brockners, et al. Expires September 13, 2017 [Page 18]
Internet-Draft In-situ OAM Data Transport March 2017
[I-D.penno-sfc-trace]
Penno, R., Quinn, P., Pignataro, C., and D. Zhou,
"Services Function Chaining Traceroute", draft-penno-sfc-
trace-03 (work in progress), September 2015.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses
Frank Brockners
Cisco Systems, Inc.
Hansaallee 249, 3rd Floor
DUESSELDORF, NORDRHEIN-WESTFALEN 40549
Germany
Email: fbrockne@cisco.com
Shwetha Bhandari
Cisco Systems, Inc.
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Email: shwethab@cisco.com
Vengada Prasad Govindan
Cisco Systems, Inc.
Email: venggovi@cisco.com
Carlos Pignataro
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: cpignata@cisco.com
Brockners, et al. Expires September 13, 2017 [Page 19]
Internet-Draft In-situ OAM Data Transport March 2017
Hannes Gredler
RtBrick Inc.
Email: hannes@rtbrick.com
John Leddy
Comcast
Email: John_Leddy@cable.comcast.com
Stephen Youell
JP Morgan Chase
25 Bank Street
London E14 5JP
United Kingdom
Email: stephen.youell@jpmorgan.com
Tal Mizrahi
Marvell
6 Hamada St.
Yokneam 20692
Israel
Email: talmi@marvell.com
David Mozes
Mellanox Technologies Ltd.
Email: davidm@mellanox.com
Petr Lapukhov
Facebook
1 Hacker Way
Menlo Park, CA 94025
US
Email: petr@fb.com
Brockners, et al. Expires September 13, 2017 [Page 20]
Internet-Draft In-situ OAM Data Transport March 2017
Remy Chang
Barefoot Networks
2185 Park Boulevard
Palo Alto, CA 94306
US
Brockners, et al. Expires September 13, 2017 [Page 21]