One document matched: draft-jain-nvo3-overlay-oam-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-jain-nvo3-overlay-oam-00"
ipr="trust200902">
<front>
<title abbrev="Detecting Overlay Segment Failure">Generic Overlay OAM and Datapath Failure Detection</title>
<author fullname="Pradeep Jain" initials="P." surname="Jain">
<organization>Nuage Networks </organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>pradeep@nuagenetworks.net</email>
</address>
</author>
<author fullname="Kanwar Singh" initials="K." surname="Singh">
<organization>Nuage Networks</organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>kanwar@nuagenetworks.net</email>
</address>
</author>
<author fullname="Florin Balus" initials="F." surname="Balus">
<organization>Nuage Networks</organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>florin@nuagenetworks.net</email>
</address>
</author>
<author fullname="Wim Henderickx" initials="W." surname="Henderickx">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Copernicuslaan 50</street>
<city>Antwerp</city>
<code>2018</code>
<country>Belgium</country>
</postal>
<email>wim.henderickx@alcatel-lucent.be</email>
</address>
</author>
<author fullname="Vinay Bannai" initials="V." surname="Bannai">
<organization>PayPal</organization>
<address>
<postal>
<street>2211 N. First St,</street>
<city>San Jose</city>
<code>95131</code>
<country>USA</country>
</postal>
<email>vbannai@paypal.com</email>
</address>
</author>
<author fullname="Ravi Shekhar" initials="R." surname="Shekhar">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 North Mathilda Ave.</street>
<city>Sunnyvale, CA</city>
<code>94089</code>
<country>USA</country>
</postal>
<email>rshekhar@juniper.net</email>
</address>
</author>
<author fullname="Anil Lohiya" initials="A." surname="Lohiya">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 North Mathilda Ave.</street>
<city>Sunnyvale, CA</city>
<code>94089</code>
<country>USA</country>
</postal>
<email>alohiya@juniper.net</email>
</address>
</author>
<date day="12" month="February" year="2014" />
<area>Internet Area</area>
<workgroup>NVO3</workgroup>
<abstract>
<t>This proposal describes a mechanism that can be used to detect
Data Path Failures of various overlay technologies as
VXLAN, NVGRE, MPLSoGRE and MPLSoUDP and verifying/sanity of their
Control and Data Plane for given Overlay Segment.
This document defines the following for each of the above Overlay Technologies: </t>
<list style="symbols">
<t>Encapsulation of OAM Packet, such that it has same Outer and Overlay Header as any End-System's data going over the same Overlay Segment.</t>
<t>The mechanism to trace the Underlay that is exercised by any Overlay Segment.</t>
<t>Procedure to verify presence of any given Tenant VM or End-System within a given Overlay Segment at Overlay End-Point.</t>
</list>
<t>Even though the present proposal addresses Overlay OAM for VXLAN, NVGRE, MPLSoGRE and MPLSoUDP, but
the procedures described are generic enough to accommodate OAM for any other Overlay Technology.</t>
</abstract>
</front>
<middle>
<t>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 <xref
target="RFC2119" />.</t>
<t>When used in lower case, these words convey their typical use in common
language, and are not to be interpreted as described in RFC2119 <xref
target="RFC2119" />.</t>
<section title="Introduction">
<t>VXLAN <xref target="I-D.draft-mahalingam-dutt-dcops-vxlan" />,
NVGRE <xref target="I-D.draft-sridharan-virtualization-nvgre" />, MPLSoGRE <xref
target="RFC4023" /> and
MPLSoUDP <xref target="I-D.draft-ietf-mpls-in-udp" /> are well known technologies
and are used as tunneling mechanism to Overlay either Layer 2 networks or Layer 3 networks
on top of Layer 3 Underlay networks. For all above Overlay Models there are two Tunnel
End Points for a given Overlay Segment. One End Point is where the Overlay Originates, and other where Overlay Terminates.
In most cases the Tunnel End Point is intended to be at the
edge of the network, typically connecting an access switch to an IP transport
network. The access switch could be a physical or a virtual switch located
within the hypervisor on the server which is connected to End System which
is a VM. </t>
<t>This document describes a mechanism that can be used to detect Data Plane
failures and sanity of Overlay Control and Data Plane for a given Overlay Segment, and
the method to trace the Underlay path that is exercised by any given Overlay Segment.</t>
<t>The document also defines procedures for validating the presence of any given
Tenant VM/End-System/End-System or Flow representing the End-System System within a
given Overlay Segment.</t>
<t>The proposal describes: </t>
<list style="symbols">
<t>The mechanism to verify Overlay Control Plane and Data Plane consistency at the Overlay End Point(s), by encapsulating the OAM Packet
in exact the same way as that of any End System Traffic that is transported over the Overlay Segment.</t>
<t>The mechanism to trace the Underlay that is exercised by any Overlay Segment.</t>
<t>The mechanism to verify presence of any "End-System" in a given Overlay Segment.</t>
</list>
<t>The proposal defines the information to check correct operation of the Data Plane,
as well as a mechanism to verify the Data Plane against the Control Plane for a given
Overlay Segment.</t>
<t>It is important consideration in this proposal to carry Echo Request along
same Data Path that any End System's data using the given Overlay Segment takes.</t>
<t>The tenants VM(s) or End System(s) are not aware of the Overlays and as such the
need for the verification of the Data Path MUST solely rest with the Cloud Provider.
The use cases where the Tenant VM(s) need to be aware of the Data Plane failures is beyond
the scope of this document. </t>
</section>
<section title="Terminology">
<t>Terminology used in this document:</t>
<t>OAM: Operations, Administration, and Management </t>
<t>VXLAN: Virtual eXtensible Local Area Network.</t>
<t>NVGRE: Network Virtualization using GRE.</t>
<t>MPLSoGRE: Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)</t>
<t>MPLSoUDP: Encapsulating MPLS in UDP.</t>
<t>Originating End Point: Overlay Segment's Head End or Starting Point of Overlay Tunnel.</t>
<t>Terminating End Point: Overlay Segment's Tail End or Terminating Point of Overlay Tunnel.</t>
<t>VM: Virtual Machine.</t>
<t>VNI: VXLAN Network Identifier (or VXLAN Segment ID)</t>
<t>VSID: Virtual Subnet ID. (for NVGRE)</t>
<t>NVE: Network Virtualized Edge </t>
<t>End System: Could be Tenant VM, Host, Bridge etc. - System whose data is expected to go over
Overlay Segment.</t>
<t> Echo Request: Throughout this document, Echo Request packet is expected to be
transmitted by Originator Overlay End Point and destined to Overlay Terminating End Point.</t>
<t> Echo Reply: Throughout this document, Echo Reply packet is expected to be
transmitted by Terminating Overlay End Point and destined to Overlay Originating End Point.</t>
<t>Other terminologies are as defined in <xref target="I-D.draft-mahalingam-dutt-dcops-vxlan" />,
<xref target="I-D.draft-sridharan-virtualization-nvgre" />, <xref
target="RFC4023" /> and <xref target="I-D.draft-ietf-mpls-in-udp" />
</t>
</section>
<section title="Motivation for Overlay OAM">
<t>When any Overlay Segment fails to deliver user traffic, there is a need to provide a
tool that would enable users, as Cloud Providers to detect such failures, and a mechanism to
isolate faults. It may also be desirable to test the data path before mapping End System
traffic to the Overlay Segment.</t>
<t> The basic idea is to facilitate following verifications:-</t>
<list style="symbols">
<t>End-System's data that are expected to go over a particular Overlay Segment actually ends up using
the Data-Path represented by given Overlay Segment between the two End-Points.</t>
<t>To verify the correct value of Overlay Segment Identifier is programmed at Originating and
Terminating End Point(s) for a given Overlay Segment. Segment Identifier will be VNI for VXLAN, VSID for NVGRE,
MPLS Label for MPLSoGRE and MPLSoUDP.</t>
<t>The facilitate mechanism to trace the Underlay that is exercised by any Overlay Segment.</t>
<t>The mechanism to verify presence of any "End-System" in a given Overlay Segment.</t>
</list>
<t>
To facilitate verification of Overlay Segment or any End-System using the Overlay, this document proposes sending of a Packet
(called an "Echo Request") along the same data path as other Packets belonging to this Segment. Echo Request also carries
information about the Overlay Segment whose Data Path is to be verified. This Echo Request is forwarded just like any other End System Data Packet belonging to that Overlay Segment, as it contains the same Overlay Encapsulation as regular
End System's data.</t>
<t> On receiving Echo Request at the end of the Overlay Segment, it is sent to the
Control Plane of the Terminating Overlay End Point, which in-turn would respond with Echo Reply.</t>
<t>To facilitate tracing of the Underlay used by any given Overlay Segment, the document proposes Echo
Request/Reply encapsulation in "trace mode", which would allow the user or Cloud Provider to gather information
of the Underlay network.</t>
</section>
<!--Motivation for Overlay OAM END-->
<section title="Approach">
<t>The proposal aims at validating Data Plane and its view of Control Plane
for a particular Overlay Segment. To achieve this aim, the draft proposes
creating an Overlay OAM Packet which MUST be encapsulated with the Overlay Header
as that of any End-Point data going over the same Overlay Segment. This
would guarantee the data-path for OAM Packet follows the same path as
that for any End User data going over the same Overlay Segment.</t>
<t>The draft outlines procedures to encode Overlay Header and Inner
Ethernet or IP Header based on the type of payload that Overlay is
expected to carry.</t>
</section>
<section title="Packet Format">
<t>Generic Overlay Echo Request/Reply is a UDP Packet identified by well known UDP Port XXXX.
The payload carried by Overlay typically could be either be Layer 2 / Ethernet Frame, or it
could be Layer 3 / IP Packet.</t>
<section title="Overlay OAM Encapsulation in Layer 2 Context">
<t>If the encapsulated payload carried by Overlay is of type Ethernet, then the OAM Echo Request
packet would have inner Ethernet Header, followed by IP and UDP Header. The payload of inner UDP would be
as described in below section "Generic Overlay OAM Packet Format". </t>
= </section>
<section title="Overlay OAM Encapsulation in Layer 3 Context">
<t>If the encapsulated payload carried by Overlay is of type IP, then the OAM Echo Request
packet would have inner IP Header, followed by UDP Header. The payload of inner UDP would be
as described in below section "Generic Overlay OAM Packet Format". </t>
</section>
<section title="Generic Overlay OAM Packet Format">
<t>Following is the format of UDP payload of Generic Overlay OAM Packet:</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Generic Overlay OAM Packet
</artwork>
</figure>
<texttable style="headers">
<preamble>The Message Type is one of the following:-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>1</c>
<c>Echo Request</c>
<c>2</c>
<c>Echo Reply</c>
</texttable>
<texttable style="headers">
<preamble>Reply Mode Values:-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>1</c>
<c>Do not reply</c>
<c>2</c>
<c>Reply via an IPv4/IPv6 UDP Packet</c>
<c>3</c>
<c>Reply via Overlay Segment</c>
</texttable>
<t> Echo Request with 1 (Do not reply) in the Reply Mode field
may be used for one-way connectivity tests. The receiving node may
log gaps in the Sequence Numbers and/or maintain delay/jitter
statistics. For normal operation Echo Request would have 2 (Reply via an
IPv4 UDP Packet) in the Reply Mode field.
</t>
<t>
If it is desired that the reply also comes back via Overlay Segment i.e. encapsulated
with the Overlay Header, then the Reply Mode filed needs to be set to 3 (Reply via Overlay Segment).
</t>
<t> The Originator's Handle is filled in by the Originator, and returned
unchanged by the receiver in the Echo Reply (if any). The value used for
this field can be implementation dependent, this MAY be used by the Originator for
matching up requests with replies.</t>
<t>
The Sequence Number is assigned by the Originator of Echo Request
and can be (for example) used to detect missed replies.</t>
<t>
The TimeStamp Sent is the time-of-day (in seconds and microseconds,
according to the sender's clock) in NTP format [NTP] when the VXLAN
Echo Request is sent. The TimeStamp Received in an Echo Reply is the
time-of-day (according to the receiver's clock) in NTP format that
the corresponding Echo Request was received.</t>
<t>
TLVs (Type-Length-Value tuples) have the following format:</t>
<figure>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Type | Length | Variable Length Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
Types are defined below; Length is the length of the Value field in
octets. The Value field depends on the Type; it is zero padded to
align to a 4-octet boundary. There could be one or many optional
Sub-TLV that could be encoded under the TLV.
</t>
<section title="TLV Types for various Overlay Ping Models">
<texttable style="headers">
<preamble>TLV Types:-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>1</c>
<c>VXLAN Segment Ping for IPv4</c>
<c>2</c>
<c>VXLAN Segment Ping for IPv6</c>
<c>3</c>
<c>NVGRE Segment Ping for IPv4</c>
<c>4</c>
<c>NVGRE Segment Ping for IPv6</c>
<c>5</c>
<c>MPLSoGRE Segment Ping for IPv4</c>
<c>6</c>
<c>MPLSoGRE Segment Ping for IPv6</c>
<c>7</c>
<c>MPLSoUDP Segment Ping for IPv4</c>
<c>8</c>
<c>MPLSoUDP Segment Ping for IPv6</c>
</texttable>
<section title="TLV for VXLAN Ping">
<figure>
<artwork>
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 = 1(VXLAN ping IPv4)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN VNI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv4
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 = 2 (VXLAN ping IPv6)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN VNI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Sender Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv6
</artwork>
</figure>
</section>
<section title="TLV for NVGRE Ping">
<figure>
<artwork>
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 = 3 (NVGRE ping IPv4)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVGRE VSID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv4
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 = 4 (NVGRE ping IPv6)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVGRE VSID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Sender Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv6
</artwork>
</figure>
</section>
<section title="TLV for MPLSoGRE Ping">
<figure>
<artwork>
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 = 5 (MPLSoGRE ping IPv4)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv4
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 = 6 (MPLSoGRE ping IPv6)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Sender Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv6
</artwork>
</figure>
<t>Route Distinguisher is defined as part of <xref target="RFC4365" /></t>
</section>
<section title="TLV for MPLSoUDP Ping">
<figure>
<artwork>
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 = 7 (MPLSoUDP ping IPv4)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv4
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 = 8 (MPLSoUDP ping IPv6)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender IPv6 Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv6
</artwork>
</figure>
<t>Route Distinguisher is defined as part of <xref target="RFC4365" /></t>
</section>
</section>
</section>
</section>
<section title="Return Codes">
<t>
Sender MUST always set the Return Code set to zero. The receiver can set
it to one of the values listed below when replying back to Echo-Request.</t>
<texttable style="headers">
<preamble>Following are the Return Codes (Suggested):-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>0</c>
<c>No return code</c>
<c>1</c>
<c>Malformed Echo Request Received</c>
<c>2</c>
<c>Overlay Segment Not Present</c>
<c>3</c>
<c>Overlay Segment Not Operational</c>
<c>4</c>
<c>Return-Code-OK</c>
</texttable>
</section>
<section title="Procedure for Overlay Segment Ping">
<t>
Echo Request is used to test Data Plane and its view of Control Plane for
particular Overlay Segment. The Overlay Segment to be verified is identified differently
for various Overlay Technologies. For VXLAN, VNI is used to identify given Overlay Segment.
For NVGRE, VSID is used. For MPLSoGRE and MPLSoUDP the MPLS Stack is used to identify a given
Overlay Segment. </t>
<t>For the Data Plane verification, the Overlay Echo Request Packet
MUST be encapsulated within the Overlay Header, which is same as that of any End-Point data going over
the same Overlay Segment. This would guarantee the data-path for OAM Packet follows the same
path as that for any End User data going over the same Overlay Segment.</t>
<t>The payload carried by Overlay typically could be either be Layer 2 or Ethernet Frame, or it
could be Layer 3 or IP Packet. Based on the type of payload following is the way inner Header(s) of
Echo Request would be encoded.</t>
<section title="Encoding of Inner Header for Echo Request in Layer 2 Context">
<t>If the encapsulated payload carried by Overlay is of type Ethernet, then the OAM Echo Request
packet would have inner Ethernet Header, followed by IP and UDP Header. The payload of inner UDP would be
as described in below section "Generic Overlay OAM Packet Format". </t>
<t>
Inner Ethernet Header for the Echo Request Packet MUST have the Destination
Mac set to 00-00-5E-90-XX-XX (to be assigned IANA). The Source Mac should be set to Mac Address
of the Originating VTEP. However, it is desired that the Inner Source Mac SHOULD not be
learnt in the MAC-Table as this represent Control Packet in context of Overlay OAM. </t>
<t>
Inner IP header is set with the Source IP Address which is a routable Address of the sender;
the Destination IP Address is a (randomly chosen) IPv4 Address from
the range 127/8, IPv6 addresses are chosen from the range 0:0:0:0:0:FFFF:127/104.
The IP TTL is set to 255. </t>
<t>The inner Destination UDP port is set to xxxx (assigned by IANA for Overlay OAM).</t>
<t>
The "Generic Overlay OAM Packet" will now be encoded, with following information.</t>
<t> The sender chooses a Originator's Handle and a Sequence Number. When
sending subsequent Overlay Echo Requests, the sender SHOULD increment
the Sequence Number by 1.</t>
<t>The TimeStamp Sent is set to the time-of-day (in seconds and
microseconds) that the Echo Request is sent. The TimeStamp Received
is set to zero. Also, the Reply Mode must be set to the desired reply mode.
The Return Code and Subcode are set to zero.</t>
<t>Next, the TLV is Encoded for desired Overlay Type, as per Section
"Types of TLVs defined for various Overlay Ping Models"</t>
= </section>
<section title="Encoding of Inner Header for Echo Request in Layer 3 Context">
<t>If the encapsulated payload carried by Overlay is of type IP, then the Encoding of the
Echo Request would be same as above Section "Encoding of Inner Header for Echo Request in Layer 2 Context",
but without the presence of Inner Ethernet Header. </t>
</section>
<section title="VXLAN Procedures">
<section title="Sending VXLAN Echo Request">
<t>
The Outer VxLAN header for the Echo Request packet follows the encapsulation as defined in
<xref target="I-D.draft-mahalingam-dutt-dcops-vxlan" />. The VNI is same as that of the VXLAN
Segment that is being verified. This would make sure that OAM Packet takes the same datapath
as any other End System data going over this VXLAN Segment.</t>
<t>
The VXLAN Router Alert option
<xref target="I-D.draft-singh-nvo3-vxlan-router-alert" /> MUST be set in the VXLAN
header as shown below.
<figure>
<artwork>
VXLAN Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|RA| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RA: Router Alter Bit (Proposed)
</artwork>
</figure>
</t>
<t>Originating VTEP MAY set the I Bit to 1 in VXLAN Header when sending OAM Frame. This would cause dropping
of such VXLAN frames on any Terminating VTEP that does not understand Overlay OAM framework, and prevent sending
those frames to End-Systems or VMs.</t>
<t>
It is desired to choose the Source UDP port (in the outer header), so as to exercise the same
Data-Path as that of the traffic carried over the VXLAN Segment and is left to the implementation.
</t>
<t>The Encoding of Inner Header(s) and UDP payload of Generic Overlay OAM Packet is as described in above Sub-Section i.e.
"Encoding of Inner Header for Echo Request in Layer 2/Layer 3 Context".</t>
</section>
<section title="Receiving VXLAN Echo Request">
<t>At the Terminating Overlay End Point or VTEP, since the Overlay OAM Packet is exactly same as that of End-System Packet(s).
It is important to send OAM packet to Control Plane and prevent it from sending to the End System. The trapping and sending
VXLAN Echo Request to the Control Plane is triggered by one of the following Packet processing exceptions: VXLAN Router Alert option,
<xref target="I-D.draft-singh-nvo3-vxlan-router-alert" /> the Inner Destination MAC Address of
00-00-5E-90-XX-XX as defined in above section, and the Destination IP Address in the 127/8 Address range
for IPv4 Address, or 0:0:0:0:0:FFFF:127/104 for IPv6 Address.</t>
<t> The Control Plane further identifies the Overlay OAM Application by UDP well know destination port xxxx.</t>
<t>Since the VxLAN Router Alert bit is set in VxLAN Header, which signifies the presence of Control Packet. The terminating VTEP
SHOULD not learn the Mac address set in the Inner Mac Header of VxLAN Echo Request Packet.</t>
<t>Once the VXLAN Echo Request Packet is identified at Control Plane, it is processed as follows:-</t>
<list style="symbols">
<t> General Packet sanity is verified. If the Packet is not well-
formed, VTEP SHOULD send VXLAN Echo Reply with the Return Code
set to "Malformed Echo Request received" and the Subcode to zero.
The header fields Originator's Handle, Sequence Number, and Timestamp
Sent are not examined, but are included in the VXLAN Echo Reply message</t>
<t> VNI Validation:
If there is no entry for VNI, it indicates that there could be a transient or permanent disconnect
between Control Plane and data Plane and VTEP needs to report an error with Return Code of "Overlay Segment Not Present"
and a Return Subcode of Zero.
If the mapping for VNI Exists, but the state is not Operational, VTEP needs to report an error with Return Code of
"Overlay Segment Not Operational"
If the mapping exists then send VXLAN Echo Reply with a Return Code of "Return-Code-OK",
and a Return Subcode of Zero. The procedures for sending the Echo Reply are
found in subsection below section.</t>
</list>
</section>
<section title="Sending VXLAN Echo Reply">
<t>If the Reply Mode is set to "Reply via an IPv4/IPv6 UDP Packet", the Echo Reply is a UDP Packet.
It MUST ONLY be sent in response to Echo Request. The Source IP Address in the Header should be
Routable Address of the replier; The Destination IP Address should be
IP Address of the Echo Request's Originating End Point or the requester.
The destination UDP Port is set to XXXX (assigned by IANA for identifying
VXLAN OAM application). The IP TTL is set to 255.</t>
<t>The format of the Echo Reply is the same as the Echo Request. The
Originator Handle, the Sequence Number, and TimeStamp Sent are copied
from the Echo Request; the TimeStamp Received is set to the time-of-
day that the Echo Request is received (note that this information is
most useful if the time-of-day clocks on the requester and the
replier are synchronized). The replier MUST fill in the Return Code and Subcode,
as determined in the previous subsection.</t>
<t>If the Reply Mode is set to "Reply via Overlay Segment", then the Replying Overlay
End Point is expected to place Echo Reply packet in-band in the Overlay Segment destined to
the Originating Overlay End Point. The detailed encapsulation for this would be covered in
next revision of the draft.</t>
</section>
<section title="Receiving VXLAN Echo Reply">
<t> An Originating Overlay End Point should only receive Echo Reply in response to an
Echo Request that it sent. When the Reply Mode is "Reply via an IPv4/IPv6 UDP Packet",
the Echo Reply would be and IP Packet/UDP Packet, and is identified by the destination UDP Port XXXX.
The Originating Overlay End Point should parse the Packet to ensure that it is well-formed,
then attempt to match up the Echo Reply with an Echo Request that it had previously sent, and the Originator
Handle. If no match is found, then it should drop the Echo Reply Packet;
otherwise, it checks the Sequence Number to see if it matches.
</t>
</section>
</section>
<!-- VXLAN Procedures END -->
<section title="NVGRE Procedures">
<section title="Sending NVGRE Echo Request">
<t>
The Outer NVGRE header for the Echo Request packet follows the encapsulation as defined in
<xref target="I-D.draft-sridharan-virtualization-nvgre" />. The VSID is same as that of the NVGRE
Segment that is being verified. This would make sure that OAM Packet takes the same datapath
as any other End System data going over this NVGRE Segment.</t>
<t>
The NVGRE Router Alert option
<xref target="I-D.draft-singh-nvo3-nvgre-router-alert" /> MUST be set in the NVGRE
header as shown below.
<figure>
<artwork>
GRE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| |1|0| Reserved0 RA| Ver | Protocol Type 0x6558 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Subnet ID (VSID) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RA: Router Alter Bit (Proposed)
</artwork>
</figure>
</t>
<t>The Encoding of Inner Header(s) and UDP payload of Generic Overlay OAM Packet is as described in above Sub-Section i.e.
"Encoding of Inner Header for Echo Request in Layer 2/Layer 3 Context".</t>
</section>
<section title="Receiving NVGRE Echo Request">
<t>At the Terminating Overlay End Point, since the Overlay OAM Packet is exactly same as that of End-System Packet(s).
It is important to send OAM packet to Control Plane and prevent it from sending to the End System. The trapping and sending
NVGRE Echo Request to the Control Plane is triggered by one of the following Packet processing exceptions: NVGRE Router Alert option,
<xref target="I-D.draft-singh-nvo3-nvgre-router-alert" /> the Inner Destination MAC Address of
00-00-5E-90-XX-XX as defined in above section, and the Destination IP Address in the 127/8 Address range
for IPv4 Address, or 0:0:0:0:0:FFFF:127/104 for IPv6 Address.</t>
<t> The Control Plane further identifies the Overlay OAM Application by UDP well know destination port xxxx.</t>
<t>Since the NVGRE Router Alert bit is set in NVGRE Header, which signifies the presence of Control Packet. The Terminating Overlay End Point
SHOULD not learn the Mac address set in the Inner Mac Header of NVGRE Echo Request Packet.</t>
<t>Once the NVGRE Echo Request Packet is identified at Control Plane, it is processed as follows:-</t>
<list style="symbols">
<t> General Packet sanity is verified. If the Packet is not well-
formed, NVGRE End Point SHOULD send NVGRE Echo Reply with the Return Code
set to "Malformed Echo Request received" and the Subcode to zero.
The header fields Originator's Handle, Sequence Number, and Timestamp
Sent are not examined, but are included in the NVGRE Echo Reply message</t>
<t> VSID Validation:
If there is no entry for VSID, it indicates that there could be a transient or permanent disconnect
between Control Plane and data Plane and NVGRE End Point needs to report an error with Return Code of "Overlay Segment Not Present"
and a Return Subcode of Zero.
If the mapping for VSID Exists, but the state is not Operational, NVGRE End Point needs to report an error with Return Code of
"Overlay Segment Not Operational"
If the mapping exists then send NVGRE Echo Reply with a Return Code of "Return-Code-OK",
and a Return Subcode of Zero. The procedures for sending the Echo Reply are
found in subsection below section.</t>
</list>
</section>
<section title="Sending NVGRE Echo Reply">
<t>The procedure for sending NVGRE Echo Reply are exactly same as defined in
above section "Sending VXLAN Echo Reply".</t>
</section>
<section title="Receiving NVGRE Echo Reply">
<t> The procedure for Receiving NVGRE Echo Reply are exactly same as defined in
above section "Receiving VXLAN Echo Reply".</t>
</section>
</section>
<!-- NVGRE Procedures END -->
<section title="MPLSoGRE Procedures">
<section title="Sending MPLSoGRE Echo Request">
<t>
The Outer header of MPLSoGRE for the Echo Request packet follows the encapsulation as defined in
<xref target="RFC4023" />. The MPLS Stack is same as that of the MPLSoGRE
Segment that is being verified. This would make sure that OAM Packet takes the same datapath
as any other End System data going over this MPLSoGRE Segment.</t>
<t> However, the bottommost Label in MPLS Stack MUST be MPLS Router Alert Label <xref target="RFC3032" />. This would indicate
the Overlay Terminating End Point that the payload is a Control Packet and needs to be delivered to Control Plane.
</t>
<t>The Encoding of Inner Header(s) and UDP payload of Generic Overlay OAM Packet is as described in above Sub-Section i.e.
"Encoding of Inner Header for Echo Request in Layer 2/Layer 3 Context".</t>
</section>
<section title="Receiving MPLSoGRE Echo Request">
<t>At the Terminating Overlay End Point, since the Overlay OAM Packet is exactly same as that of End-System Packet(s).
It is important to send OAM packet to Control Plane and prevent it from sending to the End System. The trapping and sending
MPLSoGRE Echo Request to the Control Plane is triggered by one of the following Packet processing exceptions: MPLS Router Alert Label,
and the Destination IP Address in the 127/8 Address range for IPv4 Address, or 0:0:0:0:0:FFFF:127/104 for IPv6 Address.</t>
<t> The Control Plane further identifies the Overlay OAM Application by UDP well know destination port xxxx.</t>
<t>Once the MPLSoGRE Echo Request Packet is identified at Control Plane, it is processed as follows:-</t>
<list style="symbols">
<t> General Packet sanity is verified. If the Packet is not well-
formed, MPLSoGRE End Point SHOULD send MPLSoGRE Echo Reply with the Return Code
set to "Malformed Echo Request received" and the Subcode to zero.
The header fields Originator's Handle, Sequence Number, and Timestamp
Sent are not examined, but are included in the MPLSoGRE Echo Reply message</t>
<t> Segment Validation:
If there is no entry for service represented by given Route Distinguisher for the MPLSoGRE Segment, it indicates that there could be a transient or permanent disconnect
between Control Plane and Data Plane and MPLSoGRE End Point needs to report an error with Return Code of "Overlay Segment Not Present"
and a Return Subcode of Zero.
If the entry for service represented by given Route Distinguisher for the MPLSoGRE Segment is present, but is Operationally Down. The End Point needs to report an error with Return Code of
"Overlay Segment Not Operational"
If the mapping of service represented by given Route Distinguisher for the MPLSoGRE Segment is present and Active, then send MPLSoGRE Echo Reply with a Return Code of "Return-Code-OK".
</t>
</list>
</section>
<section title="Sending MPLSoGRE Echo Reply">
<t>The procedure for sending MPLSoGRE Echo Reply are exactly same as defined in
above section "Sending VXLAN Echo Reply".</t>
</section>
<section title="Receiving MPLSoGRE Echo Reply">
<t> The procedure for Receiving MPLSoGRE Echo Reply are exactly same as defined in
above section "Receiving VXLAN Echo Reply".</t>
</section>
</section>
<!-- MPLSoGRE Procedures END -->
<section title="MPLSoUDP Procedures">
<section title="Sending MPLSoUDP Echo Request">
<t>
The Outer header of MPLSoUDP for the Echo Request packet follows the encapsulation as defined in
<xref target="I-D.draft-ietf-mpls-in-udp" />. The MPLS Stack is same as that of the MPLSoUDP
Segment that is being verified. This would make sure that OAM Packet takes the same datapath
as any other End System data going over this MPLSoUDP Segment.</t>
<t> However, the bottommost Label in MPLS Stack MUST be MPLS Router Alert Label <xref target="RFC3032" />. This would indicate
the Overlay Terminating End Point that the payload is a Control Packet and needs to be delivered to Control Plane.
</t>
<t>
It is desired to choose the Source UDP port (in the outer header), so as to exercise the same
Data-Path as that of the traffic carried over the MPLSoUDP Segment and is left to the implementation.
</t>
<t>The Encoding of Inner Header(s) and UDP payload of Generic Overlay OAM Packet is as described in above Sub-Section i.e.
"Encoding of Inner Header for Echo Request in Layer 2/Layer 3 Context".</t>
</section>
<section title="Receiving MPLSoUDP Echo Request">
<t>At the Terminating Overlay End Point, since the Overlay OAM Packet is exactly same as that of End-System Packet(s).
It is important to send OAM packet to Control Plane and prevent it from sending to the End System. The trapping and sending
MPLSoGRE Echo Request to the Control Plane is triggered by one of the following Packet processing exceptions: MPLS Router Alert Label,
and the Destination IP Address in the 127/8 Address range for IPv4 Address, or 0:0:0:0:0:FFFF:127/104 for IPv6 Address.</t>
<t> The Control Plane further identifies the Overlay OAM Application by UDP well know destination port xxxx.</t>
<t>Once the MPLSoUDP Echo Request Packet is identified at Control Plane, it is processed as follows:-</t>
<list style="symbols">
<t> General Packet sanity is verified. If the Packet is not well-
formed, MPLSoUDP End Point SHOULD send MPLSoUDP Echo Reply with the Return Code
set to "Malformed Echo Request received" and the Subcode to zero.
The header fields Originator's Handle, Sequence Number, and Timestamp
Sent are not examined, but are included in the MPLSoUDP Echo Reply message</t>
<t> Segment Validation:
If there is no entry for service represented by given Route Distinguisher for the MPLSoUDP Segment, it indicates that there could be a transient or permanent disconnect
between Control Plane and data Plane and MPLSoUDP End Point needs to report an error with Return Code of "Overlay Segment Not Present"
and a Return Subcode of Zero.
If the entry for service represented by given Route Distinguisher for the MPLSoUDP Segment is present, but is Operationally Down. The End Point needs to report an error with Return Code of
"Overlay Segment Not Operational"
If the mapping of service represented by given Route Distinguisher for the MPLSoUDP Segment is present and Active, then send MPLSoUDP Echo Reply with a Return Code of "Return-Code-OK".
</t>
</list>
</section>
<section title="Sending MPLSoUDP Echo Reply">
<t>The procedure for sending MPLSoGRE Echo Reply are exactly same as defined in
above section "Sending VXLAN Echo Reply".</t>
</section>
<section title="Receiving MPLSoUDP Echo Reply">
<t> The procedure for Receiving MPLSoGRE Echo Reply are exactly same as defined in
above section "Receiving VXLAN Echo Reply".</t>
</section>
</section>
<!-- MPLSoUDP Procedures END -->
</section>
<section title="Procedure for Trace">
<t>
In order to be able to trace the Path that a particular flow in the Overlay takes through the Underlay Network, following mechanism can be used - An overlay Echo Request packet is built and sent using the mechanisms described in the Section "Procedure for Overlay Segment Ping" so that the overlay traceroute follows the same path as the data packet for the overlay segment being traced.
</t>
<t>
The Echo Request packet in the traceroute mode is sent with the initial TTL set to 1 in the Outer IP header and thereafter incremented by 1 in each successive request. At each transit hop where the TTL expires, an exception is created. Because of this exception, the packet gets delivered to the Control Plane. Control plane can further deliver the packet to the OAM application based on the TTL exception and the specific UDP port XXXX in the incoming overlay echo request packet. If the transit node has the IP reachability to the destination IP address in the outer IP header, it sends back an overlay echo reply response otherwise the Overlay Echo Request is discarded by the Overlay OAM module on the transit nodes. If the transit node does not support overlay OAM functionality, it will simply generate a regular ICMP TTL exceeded response. This could result into "false negatives". The originating Overlay node that generated the OAM echo request SHOULD try sending the echo request with TTL=n+1, n+2, ... to probe the nodes further down the path to the terminating overlay End-point.
</t>
<t>
At the originating node, when the Echo Reply from the transit node corresponding to the traceroute query is received, it can correlate the incoming Echo Reply with the traceroute query by matching on the sequence numbers in the Overlay Echo Request/Reply packets.
</t>
<t>
Current revision of this draft limits overlay traceroute capability to fault isolation only. A subsequent version of the draft will include mechanisms to trace all possible paths in the underlay that can be used to carry overlay tunnel traffic.
</t>
</section>
<section title="Procedure for End-System Ping">
<t>
In typical Overlay deployment scenarios there is a desired to check the presence of any given
Tenant VM/End-System or Flow representing the End-System System within a given Overlay Segment.
This draft proposes the way to achieve it via End-System Ping.
</t>
<t>
The End-System can be identified at Overlay End Point by either its IP Address, Ethernet MAC Address
or combination of IP/MAC Address.
</t>
<t>
In that case, it would be important to verify the End-System connectivity by procedure
which goes over the Overlay Segment from Originating Overlay End-Point and verifies
the presence of the End-System at the Terminating Overlay End-Point.
</t>
<t>
The scope of End-System Ping is solely with the Cloud Provider which owns control of the
Overlay End Point(s). It is expected that the Overlay End Point traps this request and
checks the Presence of the End-System via its MAC Address, Route or Flow information and replies back.
There SHOULD not be a case where the End-System Ping is delivered to the actual End-Point.
</t>
<section title="Sub-TLV for End-System Ping">
This section defines new set of Sub-TLVs, that needs to be added to be carried in Echo Request/Reply
packets to verify presence of one of more End-System(s) which are present in Overlay Segment.
<texttable style="headers">
<preamble>Sub-TLV Types:-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>1</c>
<c>End-System MAC Sub-TLV</c>
<c>2</c>
<c>End-System IPv4 Sub-TLV</c>
<c>3</c>
<c>End-System IPv6 Sub-TLV</c>
<c>4</c>
<c>End-System MAC/IPv4 Sub-TLV</c>
<c>6</c>
<c>End-System MAC/IPv6 Sub-TLV</c>
</texttable>
<t></t>
<texttable style="headers">
<preamble>End-System Return Code:-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>1</c>
<c>End-System Present</c>
<c>2</c>
<c>End-System Not Present</c>
</texttable>
<section title="Sub-TLV for Validating End-System MAC Address">
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-System MAC Sub-TLV (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | Return Code#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #2 | Return Code#2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n | Return Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Address: MAC Address of the End-System, that user is interested
to validate.
Return Code: Return Code specifying status of End-System at Overlay End Point
</artwork>
</figure>
</section>
<section title="Sub-TLV for Validating End-System IP Address">
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-System IPv4 Sub-TLV (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code #1 | IP address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #2 | Return Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-System IPv6 Sub-TLV (3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address #1 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code #1 | IPv6 Address #2... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address #n |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address : IP Address of the End-System, that user is interested to
validate.
Return Code: Return Code specifying status of End-System at Overlay End Point
</artwork>
</figure>
</section>
<section title="Sub-TLV for Validating End-System MAC and IP Address">
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-System IPv4/MAC Sub-TLV (4)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | IP address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #1 | Return Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #2 | IP address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #2 | Return Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n | IP address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address #n | Return Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-System IPv6/MAC Sub-TLV(5) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| IPv6 address #1 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Return Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+
| IPv6 address #1 |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Return Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address : IP Address of the End-System, that user is interested to
validate.
MAC Address: MAC Address of the End-System, that user is interested to
validate.
Return Code: Return Code specifying status of End-System at Overlay End Point
</artwork>
</figure>
</section>
</section>
<!-- END Sending End-System Ping Request-->
<section title="Sending End-System Ping Request">
<t>When it is desired to check presence of a given End-System, the Echo Request Message is prepared
as described in above Section "Procedure for Overlay Segment Ping". This packet should compose
of Outer Header, Overlay Header, Inner Header, Generic Overlay Header with TLV representing
desired Overlay Type (VXLAN, NVGRE, MPLSoGRE or MPLSoUDP). Apart form this the packet should
also have one of the Sub-TLV's as defined in above section "Sub-TLV for End-System Ping" to
identify the type of End-System Ping that user is interested in.
</t>
<t>
Because of the above mentioned encapsulation, it would be guaranteed that the packet follows the same
Data Path as that of any End-User data going over the given Overlay Segment.
</t>
<t>
User need to fill in MAC, IP or MAC/IP combination for the End-System(s) that needs to be validated
at the Overlay End Point in the respective Sub-TLV for End-System Ping.
</t>
</section>
<!-- END Sending End-System Ping Request-->
<section title="Receiving End-System Ping Request">
<t>On receiving the End-System Ping Request the processing to trap this Packet, and sent it to
Control Plane is done by Overlay Terminating End-System as define in above Section
"Procedure for Overlay Segment Ping".
Once the OAM Packet reaches OAM Application, it is identified as End-System Ping Request by virtue
of presence any of the Sub-TLV's as defined in Section "Sub-TLV for End-System Ping".
</t>
<t>
If the Sub-TLV is of Type "End-System MAC Sub-TLV", the Overlay End Point should iterate through the list
of MAC Addresses and verify the presence of individual MAC Address in its Flow Table or MAC Table for the
given Overlay Segment. </t>
<t>
If the MAC Address is present, it should set the respective End-System's Return Code field in the Sub-TLV to 1 "End-System-Present".
</t>
<t>
If the MAC Address is not present, it should set respective the End-System's Return Code filed in the Sub-TLV to 2 "End-System-Not-Present".
</t>
<t>
If the Sub-TLV is of Type "End-System IP Sub-TLV", the Overlay End Point should iterate through the list
of IP Addresses and verify the presence of individual IP Address in its Flow Table or Route Table for the
given Overlay Segment. </t>
<t>
If the IP Address is present, it should set the respective End-System's Return Code field in the Sub-TLV to 1 "End-System-Present".
</t>
<t>
If the IPC Address is not present, it should set respective the End-System's Return Code filed in the Sub-TLV to 2 "End-System-Not-Present".
</t>
<t>
If the Sub-TLV is of Type "End-System MAC and IP Sub-TLV", the Overlay End Point should iterate through the list
of MAC/IP Addresses and verify the presence of individual MAC/IP Combination in its Flow Table or MAC and IP Table for the
given Overlay Segment. </t>
<t>
If the IP and MAC Address is present, it should set the respective End-System's Return Code field in the Sub-TLV to 1 "End-System-Present".
</t>
<t>
If the IP and MAC Address is not present, it should set respective the End-System's Return Code filed in the Sub-TLV to 2 "End-System-Not-Present".
</t>
<t>
</t>
</section>
<!-- END Sending End-System Ping Request-->
<section title="Sending End-System Ping Reply">
<t>
The procedure for sending End-System Echo Reply is same as defined in above section "Sending VXLAN Echo Reply".
The replier MUST fill Sub-TLV with proper Return Code for each element in the End-System Sub-TLV.
</t>
</section>
<!-- END Sending End-System Ping Reply-->
<section title="Receiving End-System Ping Reply">
<t>
An Originating Overlay End Point should only receive Echo Reply for End-System Ping, in response to an Echo Request that it sent.
By virtue of presence of End-System Sub-TLV it would identify the status of respective End-System, and report it to the user. The other part of the handling
is similar to section "Receiving VXLAN Echo Reply"
</t>
</section>
<!-- END Rx End-System Ping Reply-->
<!-- END Sending End-System Ping Request-->
</section>
<!-- Procedures for End-System Ping END -->
<section title="Security Considerations">
<t> TBD </t>
</section>
<section title="Management Considerations">
<t>None</t>
</section>
<section anchor="Ack" title="Acknowledgements">
<t>
This document is the outcome of many discussions among many people,
including Saurabh Shrivastava, Krishna Ram Kuttuva Jeyaram and Suresh Boddapati
of Nuage Networks, Jorge Rabadan of Alcatel-Lucent, Inc and Rahul Kasralikar
of Juniper Networks, Inc.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>Action-1: This specification reserves a IANA UDP Port Number
to be used when sending the Overlay OAM Packet</t>
<t> Action-2: This specification reserves a IANA Ethernet unicast
Address for VXLAN/NVGRE Exception handling. This Address needs to be reserved
from the block. "IANA Ethernet Address block - Unicast Use"</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="I-D.draft-mahalingam-dutt-dcops-vxlan">
<front>
<title>VXLAN: A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks</title>
<author fullname="Mallik Mahalingam" initials="M" surname="Mahalingam">
<organization></organization>
</author>
<author fullname="Dinesh G. Dutt" initials="D" surname="Dutt">
<organization></organization>
</author>
<author fullname="Puneet Agarwal" initials="P" surname="Agarwal">
<organization></organization>
</author>
<author fullname="Lawrence Kreeger" initials="L" surname="Kreeger">
<organization></organization>
</author>
<author fullname="T. Sridhar" initials="T" surname="Sridhar">
<organization></organization>
</author>
<author fullname="Mike Bursell" initials="M" surname="Bursell">
<organization></organization>
</author>
<author fullname="Chris Wright" initials="C" surname="Wright">
<organization></organization>
</author>
<date day="08" month="May" year="2013" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.draft-lasserre-nvo3-framework">
<front>
<title>Framework for DC Network Virtualization</title>
<author fullname="Marc Lasserre" initials="M" surname="Lasserre">
<organization></organization>
</author>
<author fullname="Florin Balus" initials="F" surname="Balus">
<organization></organization>
</author>
<author fullname="Thomas Morin" initials="T" surname="Morin">
<organization></organization>
</author>
<author fullname="Nabil Bitar" initials="N" surname="Bitar">
<organization></organization>
</author>
<author fullname="Yakov Rekhter" initials="Y" surname="Rekhter">
<organization></organization>
</author>
<date day="15" month="September" year="2011" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.draft-singh-nvo3-vxlan-router-alert">
<front>
<title>VxLAN Router Alert Option</title>
<author fullname="Kanwar Singh" initials="K" surname="Singh">
<organization></organization>
</author>
<author fullname="Pradeep Jain" initials="P" surname="Jain">
<organization></organization>
</author>
<author fullname="Florin Balus" initials="F" surname="Balus">
<organization></organization>
</author>
<author fullname="Wim Henderickx" initials="W" surname="Henderickx">
<organization></organization>
</author>
<date day="24" month="May" year="2013" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.draft-sridharan-virtualization-nvgre">
<front>
<title>NVGRE: Network Virtualization using Generic Routing Encapsulation</title>
<author fullname="Murari Sridharan" initials="M" surname="Sridharan">
<organization></organization>
</author>
<author fullname="Kenneth Duda" initials="K" surname="Duda">
<organization></organization>
</author>
<author fullname="Ilango Ganga initials="I" surname="Ganga">
<organization></organization>
</author>
<author fullname="Albert Greenberg" initials="A" surname="Greenberg">
<organization></organization>
</author>
<author fullname="Geng Lin" initials="G" surname="Lin">
<organization></organization>
</author>
<author fullname="Mark Pearson" initials="M" surname="Pearson">
<organization></organization>
</author>
<author fullname="Patricia Thaler" initials="P" surname="Thaler">
<organization></organization>
</author>
<author fullname="Chait Tumuluri" initials="C" surname="Tumuluri">
<organization></organization>
</author>
<author fullname="Narasimhan Venkataramiah" initials="N" surname="Venkataramiah">
<organization></organization>
</author>
<author fullname="Yu-Shun Wang" initials="Y" surname="Wang">
<organization></organization>
</author>
<date day="25" month="February" year="2013" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.draft-singh-nvo3-nvgre-router-alert">
<front>
<title>NVGRE Router Alert Option</title>
<author fullname="Kanwar Singh" initials="K" surname="Singh">
<organization></organization>
</author>
<author fullname="Pradeep Jain" initials="P" surname="Jain">
<organization></organization>
</author>
<author fullname="Florin Balus" initials="F" surname="Balus">
<organization></organization>
</author>
<author fullname="Wim Henderickx" initials="W" surname="Henderickx">
<organization></organization>
</author>
<date day="24" month="May" year="2013" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.draft-ietf-mpls-in-udp">
<front>
<title>Encapsulating MPLS in UDP</title>
<author fullname="Xiaohu " initials="" surname="Xu">
<organization></organization>
</author>
<author fullname="Nischal " initials="" surname="Sheth">
<organization></organization>
</author>
<author fullname="Lucy" initials="" surname="Yong">
<organization></organization>
</author>
<author fullname="Carlos " initials="" surname="Pignataro">
<organization></organization>
</author>
<author fullname="Yongbing " initials="" surname="Yongbing ">
<organization></organization>
</author>
<author fullname="Zhenbin" initials="" surname="Li">
<organization></organization>
</author>
<date day="10" month="May" year="2013" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<?rfc include='reference.RFC.4379'?>
<?rfc include='reference.RFC.3032'?>
<?rfc include='reference.RFC.4023'?>
<?rfc include='reference.RFC.4365'?>
<!--
<reference anchor="I-D.draft-lasserre-nvo3-framework">
<seriesInfo name="Internet-Draft"
value="draft-lasserre-nvo3-framework-03" />
<format target="http://tools.ietf.org/id/draft-lasserre-nvo3-framework-03"
type="TXT" />
<author fullname="Marc Lasserre" initials="M" surname="Lasserre">
<organization></organization>
</author>
<author fullname="Florin Balus" initials="F" surname="Balus">
<organization></organization>
</author>
<author fullname="Thomas Morin" initials="T" surname="Morin">
<organization></organization>
</author>
<author fullname="Nabil Bitar" initials="N" surname="Bitar">
<organization></organization>
</author>
<author fullname="Yakov Rekhter" initials="Y" surname="Rekhter">
<organization></organization>
</author>
</reference>
-->
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4330'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:42:08 |