<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-fan-l2tp-vp-02" ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="L2TP-VP">L2TP-VP: Layer Two Tunneling Protocol -
    Virtualization Profile</title>

    <author fullname="Duoliang Fan" initials="D." surname="Fan">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>fanduoliang@huawei.com</email>
      </address>
    </author>

    <author fullname="Liang Xia" initials="L." surname="Xia">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>frank.xialiang@huawei.com</email>
      </address>
    </author>

    <author fullname="Zhen Cao" initials="Z." surname="Cao">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>Xuanwumenxi Ave. No.32 , Xicheng District</street>

          <city>Beijing</city>

          <region/>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>zehn.cao@gmail.com, caozhen@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Namgon Kim" initials="N." surname="Kim">
      <organization>KT</organization>

      <address>
        <postal>
          <street>463-1 Jeonmin-Dong, Yuseoung-Gu Daejeon, 305-811</street>

          <city/>

          <region/>

          <code/>

          <country>Korea</country>
        </postal>

        <email>ng.kim@kt.com</email>
      </address>
    </author>

    <date year="2014"/>

    <area>Routing Area</area>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>L2TP Virtualization Profile</keyword>

    <abstract>
      <t>This document describes Layer Two Tunneling Protocol (L2TP)'s
      virtualization profile (L2TP-VP), which reuses session header of L2TP
      data message to securely support overlay networks for multiple tenants,
      and simplifies tunnel setup by disabling all kinds of L2TP control
      messages.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Traditional data centre network uses global VLAN ID to distinguish
      different tenants. Usually, a tenant consumes several VLAN IDs, for
      example, one for web server, one for application server and one for
      database server. When the number of tenants increases, the number of
      available VLAN IDs becomes insufficient.</t>

      <t>When services provided by cloud via Internet becomes popular, a
      tenant's local area network needs to securely and smoothly reach
      anywhere via Internet if it wants. For example, a tenant can access its
      office IT services hosted in cloud data centers consisting of many
      geographically dispersed physical data centers. So, VPN access to cloud
      data centers becomes very important.</t>

      <t>Layer Two Tunneling Protocol - Version 3 (L2TPv3) [RFC3931] is a
      mature and practical protocol that provides secure remote access service
      and layer 2 over IP service, but L2TPv3 aslo uses complicated control
      messages to setup tunnel. At the same time, L2TPv3 uses dynamical
      session id that is controlled by signaling mechanism and only has local
      significance. Currently, L2TPv3 is complex and does not support multiple
      tenants though it provides basic overlay functions.</t>

      <t>This document will describe Layer Two Tunneling Protocol (L2TP)'s
      virtualization profile (L2TP-VP), which reuses session header of L2TP
      data message to securely support overlay networks for multiple tenants,
      and simplifies tunnel setup by disabling all kinds of L2TP control
      messages. Essentially, L2TP-VP defines a subset of L2TPv3 via fine and
      back-compatible reuse, and then extends L2TP's usage to network
      virtualization. L2TP is widely deployed and used whatever for operators'
      network or enterprises' network, L2TP-VP brings L2TP to the entire cloud
      network by further covering data center network.</t>

      <t>The motivation of this draft is to propose an altenative L3-based
      overlay technology, besides the existed VxLAN [RFC7348] , NVGRE [NVGRE],
      based on the following consideration:<list style="symbols">
          <t>L2TPv3 is a mature IP-based tunnelling technology that is widely
          supported and implemented on current operators' deployed networks.
          Directly reusing it can help operators to save their costs;</t>

          <t>L2TPv3 inherent Cookie mechanism provides security protection
          against network attacks for tenant service;</t>

          <t>L2TP-VP solution mainly focuses on the changing on network side,
          i.e. router or switch, to be transparent to client/server for
          alleviating their complexity and burden.</t>
        </list></t>
    </section>

    <section title="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 RFC-2119 [RFC2119].</t>

      <t>In this document, these words will appear with that interpretation
      only when in ALL CAPS. Lower case uses of these words are not to be
      interpreted as carrying RFC-2119 significance.</t>
    </section>

    <section title="L2TP-VP Frame Format">
      <t>L2TPv3 message format is specified in [RFC3931]. In order to support
      virtualization and reduce complexity from the control messages, two key
      fields are added into L2TP header to carry the original payload type and
      TNI (Tenant Network Identifier).The example of packet format for
      Ethernet encapsulation in L2TP-VP is shown in Figure 1.</t>

      <figure title="Figure 1 L2TP-VP Encapsulation Frame Format">
        <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
 Outer Ethernet Header:             
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Outer Destination MAC Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Outer Destination MAC Address |  Outer Source MAC Address     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Outer Source MAC Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Ethertype 0x0800        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Outer IPv4 Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live | Protocol 115  |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Outer Source Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Outer Destination Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 L2TP-VP Header:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|        Reserved#0           |        Type                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Tenant Network Identifier (TNI)          |   Reserved#1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Cookie (optional)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Inner Ethernet Header
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Inner  Destination MAC Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Inner Destination MAC Address |   Inner Source MAC Address    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Inner  Source MAC Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Optional Ethertype=C-Tag 802.1Q| Inner VLAN Tag Information    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ethertype of Original Payload |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Original Ethernet Payload:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                Original Ethernet Payload                      |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
      </figure>

      <t>The original Ethernet frame is encapsulated with L2TP-VP Header,
      Outer IP Header and Outer Ethernet Header.</t>

      <t>L2TP-VP Header:<list style="symbols">
          <t>M bit: Modified Identifier. The M bit MUST be set to 1 to
          indicate the header is modified to L2TP-VP header format. If M=0 ,it
          indicates the header format following the L2TPv3 Session Header Over
          IP format and should to refer to [RFC3931] (Session ID is changed to
          a 31-bit field);</t>

          <t>Type field : A 16-bit field is used to carry original payload
          type (e.g., frame type). Payload type can be Layer2 type such as
          ATM, FR, Ethernet, etc. It also can be Layer3 type such as IPv4 ,
          IPv6 ,etc. In Figure 1 the type of original packet is Ethernet;</t>

          <t>TNI field : A 24-bit field allows up to 16 million tenants in the
          same management domain. The packets with different TNI will be
          isolated logically;</t>

          <t>Cookie field : The optional Cookie field inherits all the
          functions from cookie field in [RFC3931] . It is used to check the
          association of a received data message with TNI. Only need to change
          its length to be 32-bit.</t>
        </list></t>

      <t>Outer IP Header: Both IPv4 and IPv6 can be used as encapsulation IP
      header. Figure 1 shows an example of IPv4. The source IP address is
      filled with IP address of L2TP-VP endpoint which encapsulates the
      original packet with L2TP-VP frame format. The destination IP address is
      unicast address obtained by lookup of address table. Also it may be a
      multicast address representing this packet may be used for address
      learning.</t>

      <t>Outer Ethernet Header: The destination MAC address in Figure 1 may be
      the address of next hop device. The Optional Vlan Tag may be used to
      limit the area of the broadcast.</t>
    </section>

    <section title="Control Plane Consideration">
      <t>In order to reduce complexity coming from control messages, there is
      no separate control plane in L2TP-VP. All kinds of control messages
      defined in [RFC3931] are disabled. All tunnel endpoints are expected to
      be configured by management plane(e.g., OSS).</t>
    </section>

    <section title="Data Plane Consideration">
      <section title="Address Learning">
        <t>For the E2E link and tunnel setup of L2TP-VP overlay network, the
        forwarding information including tenant systems’ address, and its
        associated L2TP-VP endpoint address and TNI should be populated in the
        network. There are several options to support address learning:<list
            style="symbols">
            <t>Through the management plane, L2TP-VP endpoints will be
            configured part or all of the address table;</t>

            <t>L2TP-VP endpoints directly acquire the forwarding information
            through data plane by flooding mechanism;</t>

            <t>L2TP-VP endpoints join the multicast group and populate the
            forwarding information to the other endpoints in the same virtual
            network by the multicast tree.</t>
          </list></t>
      </section>

      <section title="Forwarding">
        <section title="Unicast Traffic">
          <t>Ingress L2TP-VP endpoint firstly gets the destination address
          from the unicast traffic, then obtains IP address of the egress
          endpoint and the TNI by lookup of address table, at last
          encapsulates the original packet in L2TP-VP frame format. The source
          IP address in outer IP header is filled with its own IP address and
          the destination IP address is filled with egress endpoint's IP
          address.</t>
        </section>

        <section title="Broadcast/Unknown/Multicast(BUM) Traffic ">
          <t>There are several proven methods to process BUM traffic.</t>

          <t>One method needs the multicast support of underlay network. All
          BUM traffic originating from within a TNI is terminated by the
          L2TP-VP endpoint, then encapsulated and sent to the assigned
          multicast address. The binding relation of the TNI and the multicast
          address of underlay network can be configured by the management
          plane.</t>

          <t>Another method is ingress replication. One BUM frame in a TNI can
          be replicated to multiple unicast frames which will be sent to all
          the egress L2TP-VP endpoints in the same TNI.</t>
        </section>
      </section>

      <section title="MTU Configuration ">
        <t>L2TP-VP overlay header can cause the MTU of the path to the egress
        tunnel endpoint to be exceeded. Here lists some solutions: <list
            style="symbols">
            <t>Modifying the MTU support configuration in the network devices,
            including L2TP-VP endpoints and other network devices which will
            transmit the encapsulation packets;</t>

            <t>Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or
            Extended MTU Path Discovery techniques such as defined in
            [RFC4821].</t>
          </list></t>
      </section>

      <section title="Qos Consideration">
        <t>QoS of underlay network can be provided without problem due to the
        fact that it’s an IP network.</t>

        <t>QoS of the overlay network may need to support the mapping of CoS
        marking between different network layers (e.g., Tenant Systems,
        Overlays, and/or Underlay) in L2TP-VP endpoints, for enabling each
        networking layer to independently enforce its own CoS policies.</t>

        <t>TS’s QoS fields (e.g. IP DSCP and/or Ethernet 802.1p) and policies
        can be defined to indicate application level CoS requirements. L2TP-VP
        endpoint can use the new service CoS fields in the overlay header to
        indicate the proper service CoS to be applied across the overlay
        network. This field can be mapped from the TS’s QoS fields or other
        mechanism (e.g. DPI).</t>
      </section>

      <section title="ECMP">
        <t>Because the outer header is standard IP header, the L2TP-VP
        endpoint SHOULD provide ECMP. Basically the L2TP-VP endpoint uses a
        hash of various fields of the outer Ethernet header and outer IP
        header, furthermore it can uses the fields of L2TP-VP header or even
        inner original packet. And the endpoint can select different fields
        for hash according to the requirement.</t>
      </section>
    </section>

    <section title="Management Plane Consideration">
      <t>Management plane is needed to configure access type, TNI, QoS,
      Cookie, etc. In some scenarios, management plane should support to
      configure the forwarding information or policies for data plane and
      control plane , such as routing table, address table, etc. Management
      plane can be OSS or SDN controller.</t>
    </section>

    <section title="Deployment Consideration">
      <t>TBD.</t>
    </section>

    <section title="Security Considerations">
      <t>Like L2TPv3, L2TP-VP continues to adopt Cookie Field as an additional
      check to the received packet. A 32-bit random field is difficult to be
      cracked so that it can afford protection against brute-force, blind and
      insertion attacks.</t>

      <t>When the network is open network and someone can sniff the whole
      traffic through the network , it will need other security measures.
      Traditional security mechanisms based on IP technique will provide
      authentication/encryption function ,such as IPSec.</t>
    </section>

    <section title="IANA Considerations">
      <t>TBD.</t>
    </section>
  </middle>

  <back>
    <references title="Normaative References">
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement
          Levels</title>

          <author fullname="Bradner, S" initials="S." surname="Bradner"/>

          <date month="March" year="1997"/>
        </front>
      </reference>

      <reference anchor="RFC3931">
        <front>
          <title>Layer Two Tunneling Protocol - Version 3 (L2TPv3)</title>

          <author fullname="J. Lau" initials="J." surname="Lau"/>

          <date month="March" year="2005"/>
        </front>
      </reference>

      <reference anchor="RFC7348">
        <front>
          <title>Virtual eXtensible Local Area Network (VXLAN): A Framework
          for Overlaying Virtualized Layer 2 Networks over Layer 3
          Networks</title>

          <author fullname="Mallik Mahalingam  " initials="M."
                  surname="Mahalingam  ">
            <organization/>
          </author>

          <date month="August" year="2014"/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="NVGRE">
        <front>
          <title>NVGRE: Network Virtualization using Generic Routing
          Encapsulation</title>

          <author fullname="Murari Sridharan " initials="M."
                  surname="Sridharan ">
            <organization/>
          </author>

          <date month="October" year="2014"/>
        </front>

        <seriesInfo name="ID" value="draft-sridharan-virtualization-nvgre-06"/>
      </reference>
    </references>
  </back>
</rfc>
