| Network Working Group | M. Portoles |
| Internet-Draft | V. Ashtaputre |
| Intended status: Experimental | V. Moreno |
| Expires: October 9, 2016 | F. Maino |
| Cisco Systems | |
| D. Farinacci | |
| lispers.net | |
| April 7, 2016 |
LISP L2/L3 EID Mobility Using a Unified Control Plane
draft-portoles-lisp-eid-mobility
The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution, as well as analyzing possible deployment options and models.
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].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 9, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document describes the architecture and design options required to offer a unified L2 and L3 overlay solution with the LISP control-plane.
The architecture takes advantage of the flexibility that LISP provides to simultaneously support different overlay flavors. In this sense, while the LISP specification defines both data-plane and control-plane solutions, this document focuses on the use of the control-plane piece, which can be combined with the data-plane of choice (e.g., [VXLAN-GPE], [VXLAN], or [LISP].
The recommended selection of whether a flow is sent over the L2 or the L3 overlay is mapped to bridged (intra-subnet or non-IP) or routed (inter-subnet) traffic, respectively. This allows treating both overlays as separate segments, and enables L2-only and L3-only deployments (and combinations of them) without modifying the architecture.
The unified solution for L2 and L3 overlays offers the possibility to extend subnets and routing domains (as required in state-of-art Datacenter and Enterprise architectures) with traffic optimization.
An important use-case of the unified architecture is that, while most data centers are complete layer-3 routing domains, legacy applications either have not converted to IP or still use auto-discovery at layer-2 and assume all nodes in an application cluster belong to the same subnet. For these applications, the L2-overlay limits the functionality to where the legacy app lives versus having to extend layer-2 into the network.
Broadcast, Unknown and Multicast traffic on the overlay are supported by either replicated unicast, or underlay (RLOC) multicast as specified in [RFC6831], [I-D.ietf-lisp-signal-free-multicast].
LISP related terms are defined as part of the LISP specification [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server (MS) and Map-Resolver (MR).
This section introduces a reference system to support the description of the solution and it walks the supported packet flows.
The following figure illustrates the reference system used to support the packet flow description. The system presents 4 sites. Site A and Site D provide access to different subnets (non-extended), while Site B and Site C extend a common subnet. The xTR in each one of the sites registers EIDs from the sites with the LISP Mapping System and provides support to encapsulate overlay (EID) traffic through the underlay (RLOC space).
,-------------.
(Mapping System )
-+------------+
+--+--+ +-+---+
|MS/MR| |MS/MR|
+-+---+ +-----+
.-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-.
.-.' '.-.
( L3 Underlay )
( (RLOC Space) )
'.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.'
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------'
IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4
MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3
Figure 1: Reference System Architecture with unified L2 and L3 overlays
The recommended selection between the use of L2 and L3 overlays is to map them to bridged (intra-subnet or non-IP) and routed (inter-subnet) traffic. This section follows this recommendation to describe the packet flows.
However, note that in a different selection approach, intra-subnet traffic MAY also be sent over the L3 overlay. Section 6.1 specifies the changes needed to send all IP traffic using the L3 overlay and restricting the use of the L2 overlay to non-IP traffic.
When required, the control plane makes use of two basic types of EID-to-RLOC mappings associated to end-hosts and in order to support the unified architecture:
Bridged traffic is encapsulated using the L2 overlay. This section provides an example of the unicast packet flow and the control plane operations when in the topology shown in Figure 1, the End-Device 2 in site B communicates with the End-Device 3 in site C. In this case we assume that End Device 2, knows the MAC address of End-Device 3 (e.g., learned through ARP).
Inter-subnet traffic is encapsulated using the L3 overlay. The process to encapsulate this traffic is the same as described in the original specification [RFC6830]. We describe the packet flow here for completeness
The following is a sequence example of the unicast packet flow and the control plane operations when in the topology shown in Figure 1 End-Device 1, in LISP site A, wants to communicate with End-Device 4 in LISP site D. Note that both end systems reside in different subnets. We'll assume that End-Device 1 knows the EID IP address of End-Device 4 (e.g. it is learned using a DNS service).
A large majority of applications are IP based and, as a consequence, end systems are typically provisioned with IP addresses as well as MAC addresses.
In this case, to limit the flooding of ARP traffic and reduce the use of multicast in the RLOC network, the LISP mapping system is used to support ARP resolution at the ITR.
In order to provide this support, ETRs handle and register an additional EID-to-RLOC mapping as follows,
The following packet flow sequence describes the use of the LISP Mapping System to support ARP resolution for hosts residing in a subnet that is extended to multiple sites. Using Figure 1, End-Device 2 tries to find the MAC address of End-Device 3. Note that both have IP addresses within the same subnet:
This example shows how LISP, by replacing dynamic data plane learning (such as Flood-and-Learn) can reduce the use of multicast in the underlay network.
Note that ARP resolution using the Mapping System is a stateful operation on the ITR. The source IP,MAC tuple coming from the ARP request have to be stored to generate the ARP-reply when the Map-Reply is received.
Note that the ITR SHOULD cache the ARP entry. In that case future ARP-requests can be handled without sending additional Map-Requests.
This section describes the specific elements required to support a unified L2 and L3 overlay solution and the packet flows described in the previous section.
LISP support of segmentation and multi-tenancy is structured around the propagation and use of Instance-IDs, and handled as part of the EID in control plane operations. The encoding is described in [I-D.ietf-lisp-lcaf] and its use in [I-D.ietf-lisp-ddt].
Depending on the particular deployment, both the L2 and L3 overlays can be segmented. An Instance-ID can be used for L2 overlay segmentation (e.g., VLAN extension) and for L3 overlay segments (e.g., VRF extension or multi-VPN overlays). In all cases, the Instance-ID is a 24-bit value. Instance-IDs are unique to a Mapping System and MAY be used to identify the overlay type.
An important aspect of L2 overlay segmentation is the mapping of VLANs to IIDs. In this case a Bridge Domain (which is the L2 equivalent to a VRF as a forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a bridge domain or different VLAN-IDs on different ports may map to a common Bridge Domain, which in turn maps to an IID in the L2 overlay. When ethernet traffic is double tagged, usually the external 802.1Q tag will be mapped to a bridge domain on a per port basis, and the inner 802.1Q tag will remain part of the payload to be handled by the overlay. The IID should therefore be able to carry ethernet traffic with or without an 802.1Q header. A port may also be configured as a trunk and we may chose to take the encapsulated traffic and map it to a single IID in order to multiplex traffic from multiple VLANs on a single IID. These are all examples of local operations that could be effected on VLANs in order to map them to IIDs, they are provided as examples and are not exhaustive.
When an end-host is attached or detected in an ETR that provides L2-overlay and L3-overlay services, two Database Mapping entries are registered to the mapping system:
These two database mappings are the ones required to support L3 and L2 forwarding.
The registration of these EIDs MUST follow the LCAF format as defined in [I-D.ietf-lisp-lcaf].
When an end-host is attached or detected in an ETR that provides L2-overlay services and supports ARP resolution using the LISP control-plane, an additional mapping entry is registered to the mapping system:
In this case both the xTRs and the Mapping System MUST support an EID-to-RLOC mapping where the MAC address is set as a locator record.
This mapping is registered with the Mapping System using the following EID record structure,
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | AFI = 16387 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | Rsvd1 | Flags | Type = 2 | IID mask-len |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | 4 + n | Instance-ID... |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | ...Instance-ID | EID-AFI = 1 or 2 |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EID-Prefix (IPv4 or IPv6) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | Unused Flags |L|p|R| AFI = 16387 |
| A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C | Rsvd1 | Flags | Type = 1 | Rsvd2 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | 2 + 6 | AFI = 6 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Layer-2 MAC Address ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| ... Layer-2 MAC Address |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.
An EID record with a locator record that carries a MAC address follows the same structure as described in [RFC6830]. However, some fields of the EID record and the locator record require special consideration:
Note that an IP EID record that carries a MAC address in the locator record, SHOULD be registered with the Proxy Map-Reply bit set.
The interface between the xTRs and the Mapping System is described in [RFC6833] and this document follows the specification as described there. When available, the registrations MAY be implemented over a reliable transport as described in [I-D.kouvelas-lisp-map-server-reliable-transport].
The LISP specification ([RFC6830]) describes how to handle Time-to-Live values of the inner and outer headers during encapsulation and decapsulation of packets when using the L3 overlay. The same approach SHOULD be followed for the unified overlay.
When using the L2 overlay and the encapsulated traffic is IP traffic, the Time-to-Live value of the inner IP header MUST remain unmodified at encapsulation and decapsulation. Network hops traversed as part of the L2 overlay SHOULD be hidden to tools like traceroute and applications that require direct L2 connectivity.
One of the key elements to support end-host mobility using the LISP architecture is the Solicit-Map-Request (SMR). This is an special message by means of which an ETR can request an ITR to send a new Map-Request for a particular EID record. In essence the SMR message is used as a signal to indicate a change in mapping information and it is described with detail in [RFC6830]. Section 5 provides a packet flow description of the mobility support in a unified overlay.
In order to support mobility, an ETR SHALL maintain a list of EID records for which it has to generate a SMR message whenever it receives traffic with that EID as destination. This is called an Away Table.
The particular strategy to maintain an Away Table is implementation specific and it will be typically based on the strategy to detect the presence of hosts and the use of the Map-Notifies received from the Map-Server. In essence the table SHOULD provide support to the following:
The registration and access to non-extended subnets using the L3 overlay follows [RFC6830].
Note also that non-extended subnets can also be treated as non-LISP networks. In that case, providing access to the subnet to participants of LISP overlays requires the use of a PxTR, following the specification in [RFC6830].
xTRs that offer L2 overlay services and are part of the same Instance-ID join a common Multicast Group. When required, this group allows ITRs to send traffic that needs to be replicated (flooded) to all ETRs participating in the L2-overlay (e.g., broadcast traffic within a subnet). When the core network (RLOC space) supports native multicast ETRs participating in the L2-overlay join a (*,G) group associated to the Instance-ID.
When multicast is not available in the core network, each xTR that is part of the same instance-ID SHOULD join a (S,G) entry to the mapping system using the procedures described in [I-D.ietf-lisp-signal-free-multicast], where S is 0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows and ITR to know which ETRs are part of the L2 overlay and it can head-end replicate traffic to.
Broadcast, Unknown Unicast and Multicast (BUM) traffic on the L2-overlay is supported by either replicated unicast, or underlay (RLOC) multicast.
Support to end-host mobility is a basic requirement of state-of-art overlay solutions. The unified overlay architecture described here supports mobility both over L2-overlays and L3-overlays. This section provides a packet flow sequence description of the mobility support, detailing the use of the elements defined in the previous section.
In order to support the packet flow description we use again the same example as in Figure 1. In this particular case hosts may roam and we distinguish the case when we have L2-mobility (e.g., IP hosts move within their own subnet) or L3-mobility.
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
' ) ' )
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------'
(IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4)
(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
Figure 2: Reference Mobility Architecture
The support to L2 mobility covers the requirements to allow an end-host to move from a given site to another and maintain correspondence with the rest of end-hosts that are connected to the same L2 domain (e.g. extended VLAN). This support MUST ensure convergence of L2 forwarding (MAC based) from the old location to the new one, when the host completes its move.
The following is a sequence description of the packet flow when End-Device 2 in the figure moves to Site C, which is extending its own subnet network.
The support to L3 mobility covers the requirements to allow an end-host to move from a given site to another and maintain correspondence with the rest of end-hosts that are connected to the same L3 routing domain. This support MUST ensure convergence of L3 forwarding (IPv4/IPv6 based) from the old location to the new one when the host completes its move.
The following is a sequence description of the packet flow when End-Device 1 in the reference figure roams to site D:
The support of an integrated L2 and L3 overlay solution takes multiple architectural design options, that depend on the specific requirements of the deployment environment. While some of the previous describe specific packet flows and solutions based on the recommended solution, this section documents OPTIONAL design considerations that differ from the recommended one but that MAY be required on alternative deployment environments.
As pointed out at the beginning the recommended selection of the L2 and L3 overlays is not the only one possible. In fact, providing L2 extension to some cloud platforms is not always possible and subnets need to be extended using the L3 overlay.
In order to send all IP traffic (intra- and inter-subnet) through the L3 overlay the solution MUST change the ARP resolution process described in Section 3.2.3 to the following one (we follow again Figure 1 to drive the example. End-Device 2 queries about End-Device 3):
It is also important to note that using this strategy to extend subnets through the L3 overlay but still keeping the L2 overlay for the rest of traffic MAY lead to flow asymmetries. This MAY be the case in deployments that filter Gratuitous ARPs, or when moved hosts continue using actual L2 information collected before a migration.
The LISP control-plane offers independence from the data-plane encapsulation. Any encapsulation format that can carry a 24-bit instance-ID can be used to provide the unified overlay.
Common encapsulation formats that can be used are [VXLAN-GPE], [LISP] and [VXLAN]:
The Unified architecture that this document specifies allows the deployment of L3-only or L2-only overlays. By having a single control plane where the mapping database can hold both MAC EIDs and IP EIDs, the deployment of L2-only or L3-only architectures consists in using only the relevant database mappings.
The requirements and use of LISP to support a L3-only overlay are extensively documented in the original LISP specification and related documents.
The provision of a L2-only overlay MUST provide support for intra-subnet connectivity of end-hosts belonging to the same tenant, including them in a unique L2 broadcast domain extended across the network.
Provision such L2-only overlay SHALL take the following aspects into account, as described before in Section 4:
This memo includes no request to IANA.
This draft builds on top of two expired drafts that introduced the concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and draft-hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the combined authors of those drafts, that SHOULD be considered main contributors of this draft as well: Vina Ermagan, Dino Farinacci, Yves Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael Smith.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC6830] | Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013. |
| [RFC6831] | Farinacci, D., Meyer, D., Zwiebel, J. and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013. |
| [RFC6833] | Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013. |
| [RFC7348] | Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M. and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014. |
| [I-D.ietf-lisp-ddt] | Fuller, V., Lewis, D., Ermagan, V. and A. Jain, "LISP Delegated Database Tree", Internet-Draft draft-ietf-lisp-ddt-04, March 2016. |
| [I-D.ietf-lisp-lcaf] | Farinacci, D., Meyer, D. and J. Snijders, "LISP Canonical Address Format (LCAF)", Internet-Draft draft-ietf-lisp-lcaf-11, September 2015. |
| [I-D.ietf-lisp-signal-free-multicast] | Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Internet-Draft draft-ietf-lisp-signal-free-multicast-00, December 2015. |
| [I-D.ietf-nvo3-vxlan-gpe] | Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, P. and D. Melman, "Generic Protocol Extension for VXLAN", Internet-Draft draft-ietf-nvo3-vxlan-gpe-01, November 2015. |
| [I-D.kouvelas-lisp-map-server-reliable-transport] | Cassar, C., Kouvelas, I., Lewis, D., Arango, J. and J. Leong, "LISP Map Server Reliable Transport", Internet-Draft draft-kouvelas-lisp-map-server-reliable-transport-01, February 2016. |