One document matched: draft-pang-nvo3-vxlan-path-detection-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7637 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7637.xml">
<!ENTITY RFC7348 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7348.xml">
<!ENTITY RFC7364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7364.xml">
<!ENTITY RFC7365 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7365.xml">
<!ENTITY I-D.draft-tissa-nvo3-oam-fm SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-tissa-nvo3-oam-fm-02.xml">
<!ENTITY I-D.draft-ashwood-nvo3-oam-requirements SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ashwood-nvo3-oam-requirements-03.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-pang-nvo3-vxlan-path-detection-01" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Path Detection in VXLAN Overlay Network</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Junying Pang" initials="" surname="Junying Pang">
<organization>Alibaba</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>kittypang@alibaba-inc.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jie Cao" initials="" surname="Jie Cao">
<organization>Alibaba</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>jie.caojie@alibaba-inc.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dapeng Liu" initials="" surname="Dapeng Liu">
<organization>Alibaba</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>max.ldp@alibaba-inc.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dacheng Zhang" initials="" surname="Dacheng Zhang">
<organization>Alibaba</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>dacheng.zdc@alibaba-inc.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Yizhou Li" initials="" surname="Yizhou Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>101 Software Avenue,</street>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region></region>
<code>210012</code>
<country>China</country>
</postal>
<phone>+86-25-56624440</phone>
<email>liyizhou@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Hao Chen" initials="" surname="Hao Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>101 Software Avenue,</street>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region></region>
<code>210012</code>
<country>China</country>
</postal>
<phone>+86-25-56624440</phone>
<email>philips.chenhao@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="David Zhou" initials="" surname="David Zhou">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email></email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="BoJian Wang" initials="" surname="BoJian Wang">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email></email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Deepak Kumar" initials="" surname="Deepak Kumar">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>dekumar@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ruichang Gao" initials="" surname="Ruichang Gao">
<organization>H3C</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>gaoruichang@h3c.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Yan Qiao" initials="" surname="Yan Qiao">
<organization>H3C</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>qiaoyan@h3c.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="October 19" year="2015" />
<!-- Meta-data Declarations -->
<area>Routing Area</area>
<workgroup>NVO3</workgroup>
<keyword></keyword>
<keyword></keyword>
<abstract>
<t>
In VXLAN overlay networks, Operation and Management(OAM)functions are
important for fault management and performance monitoring. Path
Detection(PD) is one critical OAM function which is applied to
monitor and/or diagnose the potential paths between two VTEPs or
between two Tenant System. In addition, it can assist to identify the
locations of failures on data transmission paths.
</t>
<t>
This document specifies a method of PD method for VXLAN Overlay
Networks by using a centralized controller. However,the method can be
easily extended to support the overlay networks without a centrilized
controller. It can also be generalized to other overlay technique
such as NVGRE.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
In VXLAN overlay networks, OAM functions such as fault management
should be implemented to prevent the path failure problem [NVO3-OAM-
REQ]. Path Detection is one of OAM function which can be used to
detect all available paths between two Tenant Systems or two VTEPs,
and so it is widely used to assist the identify of the failure
locations along a transmission path.
</t>
<t>
In this memo, a PD mechanism is specified for VXLAN overlay networks.
A centralized Controller is provided as a centralized unit to: 1)
construct Path Detection(PD) packets, 2) inject them into the network
devices to record information such as device's Ingress/Egress
interface number, and 3) collect the PD packets from network devices
for further analysis. Therefore, Path Detection such as monitoring
and diagnose can be realized more efficient.
</t>
<t>Figure 1 shows the architecture of this mechanism:</t>
<figure anchor="fig_architecture"
title="VXLAN Overlay Network with Fabric Controller">
<artwork><![CDATA[
*******************************************
* +------------+ *
* | | *
* +-------+ Fabric +------+ *
* | | Controller | | *
* | | | | *
* | +-----+------+ | *
* | | | *
* | | | *
* | | | *
* | | | *
+-----+ * +---+--+ +----+----+ +--+---+ * +-----+
| +--+| * |+----+| | | |+----+| * |+--+ |
| |VM|+---*--+|VTEP|+-----+ L3 +-----+|VTEP|+--*---+|VM| |
| +--+| * |+----+| | Devices | |+----+| * |+--+ |
| | * | | | | | | * | |
+-----+ * +------+ +---------+ +------+ * +-----+
Server * ToR ToR * Server
* *
* *
* VXLAN Overlay Network *
* *
*******************************************
]]> </artwork>
<postamble>
</postamble>
</figure>
<t>
This method can be extended to support the overlay network without
fabric controller. In this case, it could be regarded as a
traditional OAM fault management solution described in <xref target="I-D.tissa-nvo3-oam-fm"> draft-tissa-nvo3-oam-fm-02 </xref>.It can also be generalized to support other overlay technique such as <xref target="RFC7637"> NVGRE </xref>.
</t>
<t>
The following of this document is organized as follows: Section 3
describes the format of PD packets. Section 4 introduces the
procedure of Path Detection between VTEPs. Section 5 describes the
procedure of Path Detection between Tenant Systems.
</t>
<section title="Acronyms and Terminology">
<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 <xref target="RFC2119">RFC 2119</xref>.</t>
<t>Because this document reuses most of the terms specified in <xref target="RFC7348">RFC 7348</xref> <xref target="RFC7364">RFC 7364</xref> and <xref target="RFC7365">RFC 7365</xref>, this section only defines the key terms used by this document. </t>
<t>NVGRE: Network Virtualization using Generic Routing Encapsulation</t>
<t>OAM: Operations, Administration, and Management </t>
<t>Controller: an entity that generates PD packets and injects them into the overlay network through VTEPs, also collects PD packets from network devices in overlay network.
</t>
</section>
</section>
<section title="Conventions Used in This Document">
<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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Path Detection Under the Assistance of Fabric Controller">
<t>
This section describes the format of PD packet.
</t>
<t>
To provide accurate monitoring and/or diagnostic services, a PD
packet and the corresponding user packets should be transported over
the same data path. In addition, PD packets SHOULD NOT be transferred
to the outside of the overlay network.
</t>
<section title="General Format of PD packet">
<t>
Figure 2 shows the format of a PD packet:
</t>
<figure anchor="fig_format"
title="Format of the PD packet">
<artwork><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
- Outer MAC Header - 14 Octets
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
- Outer IPv4 Header - 20 Octets
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer UDP Header | 8 Octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Header | 8 Octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Pseudo-Header ~ 128 Octets
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM PDU | Variable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<t>
VXLAN Header (8 Octets): A fixed size field, used to carry NVO3
specific information. This work complies with the VXLAN Header
specified in Section 5 of [RFC 7348] but uses a reserve field as the
flag to distinguish the packets for PD from the normal user packets.
</t>
<t>
Pseudo-Header (128 Octets): A fixed size field, consists of the
information of Ethernet MAC header, IPv4 header, and TCP/UDP header,
which is used to identify the packets within the same flow.
</t>
<t>
OAM PDU (Variable): A variable size field,used to carry the path
detection information. An OAM PUB consists of OAM flag, OAM type and
Extendable TLV as shown in Section 3.4. For a OAM PDU, 4 Octets
alignment MUST be guaranteed.
</t>
</section>
<section title="Format of VXLAN Header">
<t>
In this work, the "PD" flag(as with the illustration in Figure 3) MUST be set for all the PD packets.
</t>
<figure anchor="fig_vxlan_header"
title="VXLAN header with the PD Flag">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+
|R|R|R|R|I|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) |R|R|R|R|R|R|R|PD|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<t>
PD (1 bit) - Indicates it is a PD packet and needs to be handled as
specified in this document.
</t>
<t>
All other fields comply with what are specified in Section 5 of <xref target="RFC7348">RFC 7348</xref>.
</t>
</section>
<section title="Pseudo-Header">
<t>
The Pseudo-Header is used to ensure that the PD packets are
transported along the paths that the service flows actually
transported. In order to achieve this, the five-tuples identifying
the service flow should be copied directly into associating fields in
the Pseudo-header.
</t>
</section>
<section title="Format of OAM PDU ">
<t>
OAM PDU consists of an OAM flag field, an OAM type field and an
Extendable TLV field. This structure is used to identify the type of
Path Detection, and records the OAM information along the traverse
path at each hop. The information will be report to fabric controller
at each hop, in order to depict the complete path information.
Following is the format of OAM PDU.
</t>
<figure anchor="fig_oam_pdu"
title="Format of OAM PDU">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extendable TLV (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<t>
OAM Type (1 Octet): used to identify the function of PD packets.
Currently two functions are specified: path traversal and path
tracking.
</t>
<figure>
<artwork><![CDATA[
OAM type Function
-------- ----------------------
0x01 Path Traversal
0x02 Path Tracking
Other Reserved
]]> </artwork>
<postamble>
</postamble>
</figure>
<t>
Reserved (3 Octets): padding bits, used to keep the 4 Octets alignment.
</t>
<t>
Extendable TLV (Variable): used to carry path detection information
such as the Ingress/Egress Interface Identifiers of network devices
along the path in VXLAN overlay network.
</t>
</section>
<section title="Format of Extendable OAM TLV">
<t>
The following figure depicts the general format of an Extendable OAM
TLV:
</t>
<figure anchor="fig_tlv_oam_pdu"
title="Extendable TLV of OAM PDU">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<t>
Type (2 Octets): Specifies the Type of the TLV.(see Section 3.5.1 for
TLV types)
</t>
<t>
Length (2 Octets): Specifies the length of the 'Value' field in
octets. Length of the 'field' can be either zero or more octets.
</t>
<t>
Value (Variable): The length and the content of this field depend on
the type of the TLV. (see Section 3.5.2 for content of TLV)
</t>
<section title="TLV Type">
<t>
This document specifies two type of Extendable OAM TLV: Ingress
Interface Identifier (IIID) TLV and Egress Interface Identifier
(EIID) TLV. The Type field of each TLV is specified as follows:
</t>
<figure>
<artwork><![CDATA[
Type TLV Name
---- ----------------------------
0x0001 Ingress Interface Identifier
0x0002 Egress Interface Identifier
0x0003 Transaction Identifier
0x0004 Ingress Interface Name Identifier
0x0005 Egress Interface Name Identifier
0x0006 Authentication
]]> </artwork>
<postamble>
</postamble>
</figure>
</section>
<section title="Content of Extendable OAM TLV">
<t>
For an IIID TLV, the type field is set as 0x0001, the length field is
set as 4. The value field is 4 Octets long which contains the
device's Ingress Interface Identifier.
</t>
<figure anchor="fig_iid_tlv"
title="IIID TLV">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++--+-+-+-+
| Type = 0x0001 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress Interface Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<t>
For an EIID TLV, the type field is set as 0x0002, the length field is
set as 4. The value field is 4 Octets long which contains the
device's Egress Interface Identifier.
</t>
<figure anchor="fig_eiid_tlv"
title="EIID TLV">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0002 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Interface Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<figure anchor="fig_transactionid_tlv"
title="Transaction Identifier TLV">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0003 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<figure anchor="fig_ingress_ifname_tlv"
title="Ingress Interface Name Identifier TLV">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0004 | Length = ifName length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifName(RFC2863 (DisplayString)) |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<figure anchor="fig_egress_ifname_tlv"
title="Egress Interface Name Identifier TLV">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 | Length = ifName length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifName(RFC2863 (DisplayString)) |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
<postamble>
</postamble>
</figure>
<figure anchor="fig_authentication_tlv"
title="Authentication TLV">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0006 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
| Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key ID: 8 bits. This allows multiple keys to be active
simultaneously.
Auth Key: 16 octets. This field carries the MD5 [RFC1321] checksum
for the entire IP packet. When the Auth Key
is calculated, the shared MD5 key is stored in this field,
and the checksum fields in the IP header, UDP header are set to zero.
The result of the algorithm is placed in the Key field.
]]> </artwork>
<postamble>
</postamble>
</figure>
</section>
</section>
</section>
<section title="Path Detection between VTEPs">
<t>
In VXLAN overlay networks, Equal Cost Multi-path(ECMP) may exist
between two VTEPs, which may be leveraged to achieve load balance.
Link failure and other reasons may lead to the broken of equal cost
paths. In order to avoid delivering packets to the broken paths, it's
necessary to detect all the potential paths between the VTEPs. The
basic idea is to traversal these paths using the PD packets.
</t>
<t>The process of path detection between VTEPs is:</t>
<t>1. The Fabric Controller generates a series of Path Traversal packets
targeting to the same Egress VTEP. The outer Source UDP port numbers
of the Path Traversal packets keep increased by 1. For example,
assume the outer Source UDP port number of a Path Traversal packet is
set to 4000. Then the outer Source UDP port numbers of subsequent
Path Traversal packets are set as 4001, 4002, 4003, etc. The 'PD bit'
in VXLAN header is set to 1 . The content of Pseudo header is left to
empty (default value is full-zero), and the OAM type field is set to
0x01 to indicate that it is a Path Traversal packet. </t>
<t>2. After the Ingress VTEP receives the Path Traversal packets from
Controller, it then computes the corresponding egress port based on
the outer header information and then delivers the packet to that
port. By continuous increasing the Source UDP port number, these
packets can be distributed to different equal cost paths. Therefore,
these Path Traversal packets could go through all the equal cost
paths between the two VTEPs.</t>
<t>3. The Extendable TLV field contains multipls TLVs.
Transaction Identifier TLV is set by controller and carried in packet
without modification in scenario where multiple transactions are initiated
by controller between two endpoints. Network device can add Ingress Interface
Identifier or Ingress Interface Name Identifier, and Egress Interface
Identifier or Egress Interface Name Identifier starting at the end of
Transaction Identifier TLV. Both of these TLVs are set by the network
devices along the transport path. The TLVs are used to
record the identifier of device's Ingress/Egress interface the PD
packet goes through. Each network device receives the Path Traversal
packet from its upstream device, makes a copy of it and passes the
copy to its CPU. After filling the extendable TLVs in this copy, the
network device will deliver this copy to the Fabric Controller for further handling. </t>
<t>4. As new TLVs are added by network device in payload section of UDP/Ipv4
packet, it's good practise to update the IP length, UDP length and IP CRC.</t>
<t>5. By gathering all the Path traversal packets from the network
devices along the paths, the Controller is able to compute the number
of available paths, which could be presented by graphical chart.</t>
</section>
<section title="Path Detection between Tenant Systems">
<t>In VXLAN overlay network, link failures are common and it may affect
normal operations of up-layer applications. For example, it may lead
to service flow interruptions which are unacceptable for most
applications.</t>
<t>Path Detection between two End Systems is essential for accurate
monitoring and/or diagnostics. The basic idea is to transport the
Path Tracking packets right along the path, that the service flow are
transport through.</t>
<t>The process of Path Detection between Tenant Systems is:</t>
<t>1. The Fabric Controller generates one Path Tracking packet to
Ingress VTEP. The 'PD bit' in the VXLAN header of the packet is set
to 1. The content of Pseudo-header is set as the tuple information
which are transported over the path being detected. The OAM type
field is set to 0x02 to indicate it is a Path Tracking packet. </t>
<t>2. After the Ingress VTEP receives the Path Tracking packets from
Fabric Controller, it will firstly compute the outer source UDP port
number based on the information form in Pseudo-header. Then it
deliveries these packets to the corresponding egress port based on
the outer headers information.</t>
<t>3. Each network device receives the Path Tracking packet from its
upstream device, makes a copy of it and passes the copy to its CPU.
After filling the extendable TLVs in this copy, the network device
will deliver this copy to the Controller for further handling. By
doing this, each network device along the path will deliver a copy of
Path Tracking packets back to Fabric Controller in a hop-by-hop
manner.</t>
<t>4. By gathering all the Path traversal packets from network devices
along the paths, Fabric Controller is able to accurately monitor the
status of each link on the data flow path and locate the point of
failure. Fabric Controller may also present the path status using
graphical chart.</t>
</section>
<section title="Security Considerations">
<t>VXLAN security consideration is discussed in Section 7 of RFC 7348.
This document specifies a path failure detection mechanism by
extending the VXLAN header. Thus it has the similar vulnerability as
VXLAN. For example, attackers can inject spoofed path failure
detection packets to the VXLAN overlay network. Administrative
measures, ACL(Access Control List), authentication and encryption etc
could be used to mitigate the attack.</t>
<t>In addition, because the controller needs to collect and process the
PD packets sent from the network devices. An attacker may perform
DDoS attacks to the controller by generating a large amount of PD
packets and sent them to a VXLAN overlay network. This issue will be
well analyzed in our future work.</t>
<t>As communication between controller and network switch is over
internet and it's IP traffic, IPSEC Encryption [RFC 6071] may be
used to encrypt the communication.</t>
</section>
<section title="IANA Considerations">
<t> TBD. </t>
</section>
<section title="Acknowledgements">
<t>
The authors would like to specially thank Daolong zhou for his
generous help in improving the readability of this document.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC7348;
&RFC7364;
</references>
<references title="Informative References">
&I-D.draft-tissa-nvo3-oam-fm;
&RFC7637;
&RFC7365;
&I-D.draft-ashwood-nvo3-oam-requirements;
</references>
<!-- Appendix -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:27:34 |