One document matched: draft-singh-nvo3-vxlan-router-alert-02.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-singh-nvo3-vxlan-router-alert-02"
     ipr="trust200902">
  <front>
    <title abbrev="VxLAN Router Alert Option">VxLAN Router Alert Option</title>

    <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="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="Diego" initials="D." surname="Garcia del Rio">
      <organization>Nuage Networks.</organization>
      <address>
        <postal>
          <street>755 Ravendale Drive</street>
          <city>Mountain View, CA</city>
          <code>94043</code>
          <country>USA</country>
        </postal>

        <email>diego@nuagenetworks.net</email>
      </address>

    </author>

    <author fullname="Wim Henderickx" initials="W."
            surname="Henderickx">
      <organization>Alcatel-Lucent, Inc.</organization>

      <address>
        <postal>
          <street>Copernicuslaan 50, 2018 </street>

          <city>ANTWERP</city>

          <code>2018</code>

          <country>BELGIUM</country>
        </postal>

        <email>Wim.Henderickx@alcatel-lucent.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="Reshad Rahman" initials="R." surname="Rahman">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>2000 Innovation Drive</street>
          <city>Kanata, ON</city>
          <code>K2K 3E8</code>
          <country>USA</country>
        </postal>
        <email>rrahman@cisco.com</email>
      </address>
    </author>
	
    <date day="21" month="September" year="2015" />

    <area>Internet Area</area>

    <workgroup>NVO3</workgroup>

    <abstract>
      <t>This proposal describes a new option to achieve a mechanism 
	  which alerts VxLAN terminating VTEP to more closely 
	  examine the contents of the packet encapsulated under VxLAN header. 
	  This option is useful for case(s) where a given frame encapsulated
	  within a given VXLAN segment responsible for carrying data between two 
	  different End Systems contains some control information (e.g OAM information,
	  any control plane protocol packet etc.)
	  that may require special handling/processing by terminating VTEP.</t>
    </abstract>
  </front>

  <middle>
    <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 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>

    <section title="Introduction">
      <t>VXLAN <xref target="RFC7348" />is a 
	  tunneling mechanism to overlay Layer 2 networks on top of Layer 3 networks.
	  In most cases the end point of the tunnel (VTEP) 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>VXLAN segment encapsulates End System data at Originating VTEP and 
	  carries it over L3 network to the Terminating VTEP, where VXLAN header is
	  interpreted, removed and data is passed on to the End System.</t>
	  
	  <t>There could be some scenarios, where the network element 
	  at originating VTEP needs to encapsulate some control information in a given 
	  VXLAN segment, and this control information needs to be analysed and processed 
	  at the terminating VTEP for that VXLAN segment. There could be various examples
	  of such control information e.g OAM, and protocol control packets encapsulated 
	  in VxLAN segment.</t>

	  <t>This document defines a mechanism whereby Originating VTEP can add additional 
	  information to the VXLAN header, based upon which the Terminating VTEP can decide
	  to analyse the payload under VXLAN packet and handle it to slow-path, 
	  rather then forwarding it to the destination End System.</t>
	  
    </section>

    <section title="Terminology">
      <t>Terminology used in this document:</t>

      <t>VXLAN: Virtual eXtensible Local Area Network.</t>

	  <t>VTEP: VXLAN Tunnel End Point.</t>
	  
	  <t>VM: Virtual Machine.</t>
	  
      <t>End System: Could be VM etc. - System whose data is expected to go over
                     VXLAN Segment.</t>

	  <t>OAM: Operations, Administration, and Maintenance</t>
	  
      <t>Other terminologies are as defined in 
	  <xref target="RFC7348" />.
	  </t>
    </section>

    <section title="Approach">
      <t>If the Originating VTEP decides to generate control information, 
	  which needs to go over a given VXLAN segment and if the Terminating
	  VTEP needs to analyse and process it, then following procedures
	  have to be followed at Originating and Terminating VTEP(s):-</t>
      
	  <section title="Originating VTEP Procedure">
	  <t>When creating the VXLAN header for a given VXLAN 
	  segment, the Originating VTEP MUST set Router Alert Bit in the 
	  Flag bits in VXLAN header. The VNI for this frame MUST be the 
	  same as for the given VXLAN segment which carries the data 
	  traffic of the End System.</t>

    <figure>
     <artwork>

    VXLAN Header:
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |R|R|R|R|I|R|R|RA|           Reserved                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                VXLAN Network Identifier (VNI) |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           
		
    RA: Router Alert Bit (Proposed)
	 </artwork>
    </figure>
	  
	  </section>
	  
	  <section title="Terminating VTEP Procedure">
      <t>On receiving VXLAN frame, the Terminating VTEP would do the usual 
	  VXLAN processing as defined in <xref target="RFC7348"/>, 
	  but if the RA Bit in Flags is Set it MUST send the rest of the inner frame 
	  for further processing to the above application. The details of the applications 
	  and how it would process the inner frame is outside the scope of this document. 
	  This frame MUST not be sent to the target End System.</t>
      </section>
    </section>
	
    <section title="Management Considerations">
      <t>None</t>
    </section>

    <section anchor="Security" title="Security Considerations">
     <t>For wide range, security requirements for VxLAN Packets with Route Alert (RA) bit
	 set is no different from how IP Router Alert Option is handled in Network End Points.</t>
	 
	 <t>The most common potential attack could be Denial-of-Service attacks by sending 
     VxLAN Packets with Router Alert Bit Set at aggressive rate, causing potential high 
 	 resource utilization. For such scenarios its recommended that implementations 
	 regulate sending of such packets to control plane via rate limiting.</t>
	</section>
	
    <section anchor="Ack" title="Acknowledgements">
      <t>The authors want to thank Krishna Ram Kuttuva Jeyaram, 
	  and Suresh Boddapati of Nuage Networks for significant 
	  contribution and feedback.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Router Alert Bit (RA): IANA is request to asigh 1 Bit in Flags field 
	  of VXLAN Header to communicate VXLAN Router Alert information.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">

    <?rfc include='reference.RFC.7348'?> 	

      <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="i 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-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'?>
    </references>
  </back>
</rfc>