One document matched: draft-smith-lisp-layer2-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-smith-lisp-layer2-02" ipr="trust200902">
<front>
<title abbrev="">Layer 2 (L2) LISP Encapsulation Format</title>
<author fullname="Michael Smith" initials="M.S" surname="Smith">
<organization>Insieme Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>michsmit@insiemenetworks.com</email>
</address>
</author>
<author fullname="Dinesh Dutt" initials="D.D" surname="Dutt">
<organization>Cumulus Networks</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>ddutt@cumulusnetworks.com</email>
</address>
</author>
<author fullname="Dino Farinacci" initials="D.F" surname="Farinacci">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author>
<author fullname="Fabio Maino" initials="F.M" surname="Maino">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<region>California</region>
<country>USA</country>
</postal>
<email>fmaino@cisco.com</email>
</address>
</author>
<date day="24" month="January" year="2013" />
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<keyword>LISP; deployment</keyword>
<abstract>
<t>This memo describes an encapsulation method for carrying Ethernet and
IEEE 802 media access control (MAC) frames within the Locator/ID
Separation Protocol (LISP).</t>
</abstract>
<note title="Requirements Language">
<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"></xref>.</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>LISP <xref target="RFC6830"></xref> specifies an architecture and
method for separating the location of an endpoint from its network
identifier. It does this by using two separate name spaces: EIDs
representing the network identifier of the endpoint and RLOCs
representing the network location of the endpoint. This document extends
the LISP specifications to allow Ethernet/IEEE 802 MAC frames to be
carried within the LISP frame. The MAC addresses of the encapsulated
Ethernet/IEEE 802 MAC frames will be used as EIDs.</t>
</section>
<section anchor="overview" title="Basic Overview">
<t>L2 LISP specifies the mechanism on which to carry L2 traffic over a
LISP network. Within an L2 LISP environment, the source and destination
MAC addresses of the Ethernet/IEEE 802.3 packet are used as the source
and destination EIDs. The RLOCs can use IPv4 or IPv6 addressing. The
entire MAC frame is encapsulated with the exception of the preamble and
trailing FCS. It should be noted that L2 LISP introduces the possibility
of packet reordering during route topology changes due to the usage of
IP as the network substrate.</t>
<t>This memo addresses the data plane and frame format details of L2
LISP. The control plane details are outside the scope of this memo.</t>
</section>
<section anchor="encap" title="Layer 2 LISP Encapsulation">
<t>The layer 2 LISP encapsulation is based on the LISP header defined in
the LISP specification <xref target="RFC6830"></xref>. The UDP and LISP
headers are shown below for reference. For header fields description see
section 5.3 of <xref target="RFC6830"></xref>.<figure align="center"
title="">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 or IPv6 Header (with RLOC addresses) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator Status Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>When the headers are used for encapsulating L2 frames, the UDP
Destination Port is set to 8472.</t>
<section title="VXLAN ">
<t>The VXLAN <xref target="I-D.mahalingam-dutt-dcops-vxlan"></xref>
header is achieved by setting the L2 LISP header bits as shown in the
figure below. According to <xref
target="I-D.mahalingam-dutt-dcops-vxlan"></xref> the I flag MUST be
set to 1 for a valid VXLAN Network ID (VNI). The figure shows the
whole VXLAN frame, including the original inner L2 frame.</t>
<t><figure align="center" title=" ">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 or IPv6 Header (with RLOC addresses) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 8472 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |0 0 0 0|I|0 0 0| Not Used |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID | Not Used |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Inner Destination MAC Address |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Inner Destination MAC Address | Inner Source MAC Address |
n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
e | Inner Source MAC Address |
r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Eth.type = C-Tag [802.1Q]| Inner.VLAN Tag Information |
L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
F | |
r | |
a | Original Ethernet Payload |
m | |
e | |
\ | (Note that the original Ethernet Frame's FCS is not included) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
</section>
<section title="L2 LISP">
<t>An L2 LISP frame may optionally use the entire set of fields in the
LISP header to support all of the features of the LISP protocol.</t>
<t>The figure below shows the whole L2 LISP frame, including the
original inner L2 frame.</t>
<t><figure align="center" title="">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 or IPv6 Header (with RLOC addresses) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 8472 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator Status Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Inner Destination MAC Address |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
n | Inner Destination MAC Address | Inner Source MAC Address |
n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
e | Inner Source MAC Address |
r +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Eth.type = C-Tag [802.1Q]| Inner.VLAN Tag Information |
L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
F | |
r | |
a | Original Ethernet Payload |
m | |
e | |
\ | (Note that the original Ethernet Frame's FCS is not included) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
</section>
</section>
<section anchor="mtu" title="MTU Considerations">
<t>Since additional tunnel headers are prepended, the packet becomes
larger and can exceed the MTU of any link traversed from the ITR to the
ETR. <xref target="RFC6830"></xref> recommends in IPv4 that packets do
not get fragmented as they are encapsulated by the ITR. Instead, the
packet is dropped and an ICMP Too Big message is returned to the source.
Section 5.4 of <xref target="RFC6830"></xref> recommends procedure to
mitigate MTU issues for IPv4 or IPv6 packets.</t>
</section>
<section anchor="nvo3" title="Overlays for Network Virtualization">
<t>A notable use case for layer 2 LISP encapsulation is the use as an
overlay-based network virtualization architecture to support
multi-tenancy in large data center networks, as stated in <xref
target="I-D.narten-nvo3-overlay-problem-statement"></xref>. In this use
case, the 24-bit Instance ID serves as virtual network instance ID
(VNID) that is typically used to identify the tenants in large
multi-tenant data centers.</t>
<t>Packet replication in the underlay network to support broadcast,
unknown unicast and multicast overlay services can be done by:</t>
<t><list style="symbols">
<t>Ingress replication</t>
<t>Use of underlay multicast trees</t>
</list><xref target="RFC6831"></xref> and <xref
target="I-D.farinacci-lisp-mr-signaling"></xref> specify how to map a
multicast flow in the EID space during distribution tree setup and
packet delivery in the underlay network.</t>
</section>
<section anchor="ms" title="LISP Mapping System">
<t>When the LISP mapping database system is used with L2 LISP, it must
support the LISP Canonical Address Format (LCAF) specified in <xref
target="I-D.ietf-lisp-lcaf"></xref>. More specifically the mapping
database system must support the use of MAC Addresses as LISP EIDs, and
the use of Instance IDs as part of the lookup key.</t>
<t>According to <xref target="I-D.ietf-lisp-lcaf"></xref> the encoding
format for the 2-tuple <Instance-ID, MAC-address> is:</t>
<t><figure align="center" title="">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | IID mask-len | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 6 | Layer-2 MAC Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Layer-2 MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>In the case of a single instance of mapping database, no Instance ID
is necessary, and the encoding format for the MAC address is shown
below. In this case an Ethernet IEEE 802.1Q VLAN tag may be part of the
lookup key (encoded in an Instance ID field).</t>
<t><figure align="center" title="">
<artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 6 | Layer-2 MAC Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Layer-2 MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>A mapping database system that supports both the LISP Canonical
Address Format, and Instance ID is the LISP Delegated Database Tree
<xref target="I-D.ietf-lisp-ddt"></xref>.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>Security in a network carrying L2 LISP should be similar to security
in a normal IPv4 network. Packet filtering on the L2 LISP inner frames
will require that a firewall look inside the L2 LISP packet or that
filtering is done at the ITR/ETR.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>The IANA registry has allocated UDP port number 8472 for the L2 LISP
data packets.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Sumeet Singh, and Ajit Sanzgiri for
their technical and editorial commentary.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include="reference.RFC.6830"
?>
<?rfc include="reference.RFC.6831"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-narten-nvo3-overlay-problem-statement-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mahalingam-dutt-dcops-vxlan-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-ddt-00.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-lcaf-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-farinacci-lisp-mr-signaling-01"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 12:31:54 |