One document matched: draft-ooamdt-rtgwg-ooam-header-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC5905 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY RFC4656 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml">
<!ENTITY RFC5357 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY I-D.ietf-nvo3-geneve SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nvo3-geneve-01.xml">
<!ENTITY I-D.ietf-nvo3-gue SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nvo3-gue-04.xml">
<!ENTITY I-D.ietf-nvo3-vxlan-gpe SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nvo3-vxlan-gpe-02.xml">
<!ENTITY I-D.ietf-bier-mpls-encapsulation SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-bier-mpls-encapsulation-04.xml">
<!ENTITY I-D.ietf-sfc-nsh SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-nsh-05.xml">
<!ENTITY I-D.ietf-ippm-twamp-time-format SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ippm-twamp-time-format-00.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-ooamdt-rtgwg-ooam-header-01">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev='OAM Header for use in Overlay Networks'>OAM Header for use in Overlay Networks</title>
<author initials='G.' surname="Mirsky" fullname='Greg Mirsky'>
<organization>Ericsson</organization>
<address>
<email>gregimirsky@gmail.com</email>
</address>
</author>
<author initials='E.' surname="Nordmark" fullname='Erik Nordmark'>
<organization>Arista Networks</organization>
<address>
<email>nordmark@acm.org</email>
</address>
</author>
<!--
<author initials='C.' surname="Pignataro" fullname='Carlos Pignataro'>
<organization>Cisco Systems, Inc.</organization>
<address>
<email>cpignata@cisco.com</email>
</address>
</author>
-->
<author initials='N.' surname="Kumar" fullname='Nagendra Kumar'>
<organization>Cisco Systems, Inc.</organization>
<address>
<email>naikumar@cisco.com</email>
</address>
</author>
<author initials='D.' surname="Kumar" fullname='Deepak Kumar'>
<organization>Cisco Systems, Inc.</organization>
<address>
<email>dekumar@cisco.com</email>
</address>
</author>
<author initials='M.' surname="Chen" fullname='Mach Chen'>
<organization>Huawei Technologies</organization>
<address>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author initials='Y.' surname="Li" fullname='Yizhou Li'>
<organization>Huawei Technologies</organization>
<address>
<email>liyizhou@huawei.com</email>
</address>
</author>
<author initials='D.' surname="Mozes" fullname='David Mozes'>
<organization>Mellanox Technologies Ltd.</organization>
<address>
<email>davidm@mellanox.com</email>
</address>
</author>
<author initials='D' surname="Dolson" fullname='David Dolson'>
<organization>Sandvine</organization>
<address>
<email>ddolson@sandvine.com</email>
</address>
</author>
<author initials='I' surname="Bagdonas" fullname='Ignas Bagdonas'>
<organization></organization>
<address>
<email>ibagdona@gmail.com</email>
</address>
</author>
<date day="13" month="October" year="2016" />
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>OAM</keyword>
<abstract>
<t>
This document introduces Overlay OAM Header to be used in overlay networks to de-multiplex Overlay OAM
protocols.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
New protocols that support overlay networks like VxLAN-GPE <xref target=" I-D.ietf-nvo3-vxlan-gpe"/>,
GUE <xref target="I-D.ietf-nvo3-gue"/>, Geneve <xref target="I-D.ietf-nvo3-geneve"/>,
BIER <xref target="I-D.ietf-bier-mpls-encapsulation"/>, and NSH <xref target="I-D.ietf-sfc-nsh"/> support multi-protocol
payload, e.g. Ethernet, IPv4/IPv6, and recognize Operations, Administration, and Maintenance (OAM) as one of distinct
types. That ensures that Overlay OAM packets are sharing fate with Overlay data packet traversing the underlay.
</t>
<t>
This document introduces Overlay OAM Header to be used in overlay networks to de-multiplex Overlay OAM
protocols.
</t>
<section title="Conventions used in this document">
<section title="Terminology">
<t>
Term "Overlay OAM" used in this document interchangeably with longer version
"set of OAM protocols, methods and tools for Overlay networks".
</t>
<!--
<t>CC Continuity Check </t>
<t>CV Connectivity Verification </t>
<t>FM Fault Management </t>
<t>G-ACh Generic Associated Channel </t>
<t>Geneve Generic Network Virtualization Encapsulation </t>
<t>GUE Generic UDP Encapsulation </t>
<t>MPLS Multiprotocol Label Switching </t>
<t>NVO3 Network Virtualization Overlays </t>
<t>
OAM Operations, Administration, and Maintenance</t>
<t>SFC Service Function Chaining</t>
<t>SFP Service Function Path</t>
<t>VxLAN Virtual eXtensible Local Area Network</t>
<t>VxLAN-GPE Generic Protocol Extension for VxLAN</t>
-->
<t>NTP Network Time Protocol</t>
<t>PTP Precision Time Protocol</t>
</section>
<section title="Requirements Language">
<t>
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
<xref target="RFC2119"></xref>.
</t>
</section>
</section>
</section>
<section anchor="ooam-header" title="Overlay OAM Header">
<t>
The format of the Overlay OA Header is:
<figure align="left" anchor="ooam-header-pic"
title="Overlay OAM Header format">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Msg Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Next Prot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ OOAM Control Packet ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
The OAM Header consists of the following fields:
<list style="symbols">
<t>V - two bits long field indicates the current version of the Overlay OAM Header. The current value is 0;</t>
<t>Msg Type - 14 bits long field identifies OAM protocol, e.g. Echo Request/Reply, BFD, Performance Measurement;</t>
<t>Length - two octets long field that is length of the OOAM control packet in octets;</t>
<t>
Flags -two octets long field carries bit flags that define optional capability and thus processing of the
OOAM control packet;</t>
<t>Reserved - one octet field that MUST be zeroed on transmit and ignored on receipt
;</t>
<t>Next Prot - one octet long field that defines optional payload that is present after the OOAM Control Packet.</t>
</list>
</t>
<t>
The format of the Flags field is:
<figure align="left" anchor="ooam-flags-pic"
title="Flags field format">
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
where:
<list style="symbols">
<t>T - Timestap block flag.
</t>
<t>Reserved - must be set to all zeroes on transmission and ignored on receipt.
</t>
</list>
</t>
<t>
The OOAM header may be followed by the Timestamp control block <xref target="ooam-timestamp-pic"/> and then by
OOAM Control Packet identified by the Msg Type field.
<figure align="left" anchor="ooam-timestamp-pic"
title="Timestamp block format">
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>where:
<list>
<t>QTF - Querier timestamp format </t>
<t>RTF - Responder timestamp format </t>
<t>Timestamp 1-4 - 64-bit timestamp values </t>
</list>
Network Time Protocol (NTP), described in <xref target="RFC5905"/>,
is widely used and has long history of deployment. But it is the IEEE 1588 Precision
Time Protocol (PTP) <xref target="IEEE.1588.2008"/> that is being broadly used to achieve high-quality
clock synchronization. Converging between NTP and PTP time formats is possible but is not trivial and
does come with cost, particularly when it is required to be performed in real time without loss of accuracy.
And recently protocols that supported only NTP time format, like One-Way Active Measurement Protocol <xref target="RFC4656"/>
and Two-Way Active Measurement Protocol <xref target="RFC5357"/>,
have been enchanced to support the PTP time format as well <xref target="I-D.ietf-ippm-twamp-time-format"/>.
This document proposes to select PTP time format as default time format for Overlay OAM performance
measurement. Hence QTF, RTF fields MUST be set to 0 if querer or responder use PTP time format respectively.
If the querer or responder use the NTP time format, then QTF and/or RTF MUST be set to 1. Use of other values MUST be
considered as error and MAY be reported.
</t>
</section>
<section anchor="iana-considerations" title="IANA Considerations">
<t>IANA is requested to create new registry called "Overlay OAM".
</t>
<section anchor="iana-ooam-types" title="OOAM Message Types">
<t>
IANA is requested to create new sub-registry called "Overlay OAM Protocol Types" in the
"Overlay OAM" registry.
All code points in the range 1 through 15615 in this registry shall be allocated
according to the "IETF Review" procedure as specified in <xref target="RFC5226"/>
.
Remaining code points are allocated according to the <xref target="iana-ooam-header-type-tbl"/>:
</t>
<texttable anchor="iana-ooam-header-type-tbl" title="Overlay OAM Protocol type">
<ttcol align='left'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c></c>
<c>1 - 15615</c>
<c>Unassigned</c>
<c>IETF Review</c>
<c>15616 - 16127</c>
<c>Unassigned</c>
<c>First Come First Served</c>
<c>16128 - 16143</c>
<c>Experimental</c>
<c>This document</c>
<c>16144 - 16382</c>
<c>Private Use</c>
<c>This document</c>
<c>16383</c>
<c>Reserved</c>
<c>This document</c>
</texttable>
</section>
<section anchor="iana-header-flags" title="OOAM Header Flags">
<t>
IANA is requested to create sub-registry "Overlay OAM Header Flags" in
"Overlay OAM" registry. Two flags are defined in this document.
New values are assigned via Standards Action <xref target="RFC5226"/>.
</t>
<texttable anchor="iana-ooam-header-lags-tbl" title="Overlay OAM Flags">
<ttcol align='left'>Flags bit</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>Bit 0</c>
<c>Timestamp field</c>
<c>This document</c>
<c>Bit 1-15</c>
<c>Unassigned</c>
<c></c>
</texttable>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>
TBD
</t>
</section>
<section anchor="ack" title="Acknowledgement">
<t>
TBD
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC5905;
<reference anchor="IEEE.1588.2008">
<front>
<title>Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems</title>
<author>
<organization/>
</author>
<date month="July" year="2008"/>
</front>
<seriesInfo name="IEEE" value="Standard 1588"/>
</reference>
</references>
<references title="Informative References">
&RFC5226;
&RFC4656;
&RFC5357;
&I-D.ietf-nvo3-geneve;
&I-D.ietf-nvo3-gue;
&I-D.ietf-nvo3-vxlan-gpe;
&I-D.ietf-bier-mpls-encapsulation;
&I-D.ietf-sfc-nsh;
&I-D.ietf-ippm-twamp-time-format;
<!--
&RFC4379;
&RFC6374;
&RFC5880;
&RFC5884;
&RFC5882;
&RFC5883;
&RFC5885;
&RFC6428;
&RFC7726;
&RFC5357;
&RFC6038;
&RFC7750;
&RFC7276;
&RFC7746;
&RFC7594;
&I-D.ietf-bfd-multipoint;
&I-D.ietf-bfd-multipoint-active-tail;
&I-D.ietf-bfd-seamless-base;
&I-D.ietf-bfd-seamless-ip;
&I-D.kumarzheng-bier-ping;
&I-D.ietf-mpls-rfc6374-udp-return-path;
&I-D.mirsky-bier-pmmm-oam;
&I-D.tempia-ippm-p3m;
&I-D.lapukhov-dataplane-probe;
&I-D.ashwood-nvo3-oam-requirements;
&I-D.nordmark-nvo3-transcending-traceroute;
&I-D.saum-nvo3-pmtud-over-vxlan;
&I-D.singh-nvo3-vxlan-router-alert;
&I-D.spallagatti-bfd-vxlan;
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:14:52 |