Network Working Group K.Fang Internet Draft Cisco Systems Expires: July 2012 Jan 2012 LISP MAC-EID-To-RLOC mapping (LISP based L2VPN) draft-zhiyfang-lisp-mac-eid-00 Abstract In today's networking environment most enterprise networks span multiple physical sites, Live workload mobility is required . LISP MAC to RLOC mapping provides a scalable solution for L2/L3 Connectivity across different sites using the currently internet access. It is a very cost-effective and simple solution that does not request core network support MPLS. This document provides an overview of this technology. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July, 2012. Copyright Notice Copyright (c) 2009 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. K.Fang Expires July 2012 [Page 1] Internet-Draft LISP based L2VPN Jan 2012 Conventions used in this document 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 1.1. Motivation. . . . . . . . . . . . . . . . . . . . . . . .3 1.2. Implementation overview . . . . . . . . . . . . . . . . .3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . .4 3. MAC EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . .5 3.1. VLAN-ID consideration . . . . . . . . . . . . . . . . . .4 3.2. MAC Address LCAF(Option-A) . . . . . . . . . . . . . . . .6 3.3. MAC Address LCAF(Option-B) . . . . . . . . . . . . . . . .7 3.4. L2xTR auto-discovery . . . . . . . . . . . . . . . . . . .7 3.4.1. L2xTR broadcast MAC registration . . . . . . . . .7 3.4.2. L2xTR auto-discovery . . . . . . . . . . . . . . .8 3.5. MAC learning . . . . . . . . . . . . . . . . . . . . . . .8 3.5.1 Detailed MAC learning flow. . . . . . . . . . . . .9 3.6. MAC Withdraw . . . . . . . . . . . . . . . . . . . . . . .9 3.6.1. Aging Timer. . . . . . . . . . . . . . . . . . . .9 3.6.2. Link down (Un-register to MS). . . . . . . . . . 10 3.6.3. Unclean other L2xTR Local cache. . . . . . . . . 10 3.7. MAC move(Endpoint Mobility). . . . . . . . . . . . . . . 11 3.8. Multicast and STP. . . . . . . . . . . . . . . . . . . . 11 3.8.1. PIM Free Core. . . . . . . . . . . . . . . . . . 11 3.8.2. PIM Core . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 12 K.Fang Expires July 2012 [Page 2] Internet-Draft LISP based L2VPN Jan 2012 1. Introduction This section explains the reasoning for support MAC based EID to provide mobile endpoint roaming and Layer2 VPN services. 1.1. Motivation Currently cloud computing request more and more live workload mobility and endpoint roaming in different network. So it required to support layer 2 connectivity across different sites. Traditional layer 2 VPN technology: VPLS/EoMPLS : need MPLS support L2TPv3: no scalable if add/remove site. OTV: need IGP support LISP packet is encapsulated by UDP, and could be easily transport in internet, also LISP protocol is ip based MAP message can easily deploy over internet and archive inbound traffic engineering. +----+ +----+ RLOC1 +----+ MAC2+----+ | H1 |-------|ITR |------| L3 Core |-------| ETR|-----| H2 | +----+MAC1 +----+ RLOC2 +----+ +----+ +------------+ | DA = RLOC2 | +------------+ | SA = RLOC1 | +------------+ | UDP | +------------+ | LISP Header| +-----------+ +------------+ +-----------+ | DMAC = H2 | | DMAC = H2 | | DMAC = H2 | +-----------+ +------------+ +-----------+ | SMAC = H1 | | SMAC = H1 | | SMAC = H1 | +-----------+ +------------+ +-----------+ | Payload | | Payload | | Payload | +-----------+ +------------+ +-----------+ 1.2. Implementation overview To achieve all this, a control plane is required to exchange the MAC and RLOC mapping information among the different xTR Devices. +----+ +----+ RLOC1 +----+ MAC2+----+ | H1 |-------|ITR |------| L3 Core |-------| ETR|-----| H2 | +----+MAC1 +----+ RLOC2 +----+ +----+ K.Fang Expires July 2012 [Page 3] Internet-Draft LISP based L2VPN Jan 2012 At ITR At ETR +----------------------------+ +----------------------------+ | Destination | Interface/NH | | Destination | Interface/NH | |----------------------------| |----------------------------| | MAC1 | Ethernet X | | MAC1 | LISP:RLOC1 | | MAC2 | LISP:RLOC2 | | MAC2 | Ethernet Y | +----------------------------+ +----------------------------+ 2. Definition of Terms Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of an EID-to- RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically-aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. In this draft it will extension to support a new 64-bit EID for VLAN-ID and MAC address. Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP packet with a single IP header (more precisely, an IP packet that does not contain a LISP header). The router treats this "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC MAY be an intermediate, proxy device that has better knowledge of the EID- to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. Specifically, when a service provider prepends a LISP header for Traffic Engineering purposes, the router that does this is also regarded as an ITR. The outer RLOC the ISP ITR uses can be based on the outer destination address (the originating ITR's supplied RLOC) or the inner destination address (the originating hosts supplied EID). Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and K.Fang Expires July 2012 [Page 4] Internet-Draft LISP based L2VPN Jan 2012 forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. xTR: A xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. xTR refers to the router that is the tunnel endpoint. Used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router", meaning both ITR and ETR functionality is at the CE router. L2xTR: A xTR enable with Layer2 VPN ( MAC-EID to RLOC Mapping function). EID-to-RLOC Cache: The EID-to-RLOC cache is a short-lived, on- demand table in an ITR that stores, tracks, and is responsible for timing-out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-to-RLOC mappings, it is dynamic, local to the ITR(s), and relatively small while the database is distributed, relatively static, and much more global in scope. EID-to-RLOC Database: The EID-to-RLOC database is a global distributed database that contains all known EID-prefix to RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID prefixes "behind" the router. These map to one of the router's own, globally-visible, IP addresses. The same database mapping entries MUST be configured on all ETRs for a given site. In a steady state the EID-prefixes for the site and the locator-set for each EID-prefix MUST be the same on all ETRs. Procedures to enforce and/or verify this are outside the scope of this document. Note that there MAY be transient conditions when the EID-prefix for the site and locator-set for each EID-prefix may not be the same on all ETRs. This has no negative implications. 3. MAC EID-to-RLOC Mapping 3.1. VLAN-ID consideration There are 2 implementation for VLAN support: Option-A use LISP-Instance-id as VLAN-id , but when add new vlans, it request add new instance, or All LISP Router pre-allocate instance-IDs. Option-B use VLAN-ID+MAC as EID and directly encapsulate the 802.11q Packet. K.Fang Expires July 2012 [Page 5] Internet-Draft LISP based L2VPN Jan 2012 3.2. MAC Address LCAF(Option-A) Option-A is same as [LCAF] definition, when MAC addresses are stored in the LISP Mapping Database System,the AFI List Type can be used to carry AFI 6. (Option-A) MAC Address LISP Canonical Address Format: 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 = 1 | Rsvd2 | 2 + 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 6 | Layer-2 MAC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: length in bytes is fixed at 8 when MAC address AFI encoded addresses are used. LISP L2VPN(Option-A) packet encapsulation is shown below: +----+ +----+ RLOC1 +----+ MAC2+----+ | H1 |-------|ITR |------| L3 Core |-------| ETR|-----| H2 | +----+MAC1 +----+ RLOC2 +----+ +----+ +------------+ | DA = RLOC2 | +------------+ | SA = RLOC1 | +------------+ | UDP | +------------+ | LISP Header| <==VLAN-ID as Instance-ID +-----------+ +------------+ +-----------+ | DMAC = H2 | | DMAC = H2 | | DMAC = H2 | +-----------+ +------------+ +-----------+ | SMAC = H1 | | SMAC = H1 | | SMAC = H1 | +-----------+ +------------+ +-----------+ | Payload | | Payload | | Payload | +-----------+ +------------+ +-----------+ K.Fang Expires July 2012 [Page 6] Internet-Draft LISP based L2VPN Jan 2012 3.3. MAC Address LCAF(Option-B) The AFI List Type can be used to carry AFI 7. The length in bytes is fixed at 10. 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 = 1 | Rsvd2 | 2 + 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 7 | VLAN-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Layer-2 MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Layer-2 MAC Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LISP L2VPN(Option-B) packet encapsulation is shown below: +----+ +----+ RLOC1 +----+ MAC2+----+ | H1 |-------|ITR |------| L3 Core |-------| ETR|-----| H2 | +----+MAC1 +----+ RLOC2 +----+ +----+ +------------+ | DA = RLOC2 | +------------+ | SA = RLOC1 | +------------+ | UDP | +------------+ | LISP Header| +-----------+ +------------+ +-----------+ | DMAC = H2 | | DMAC = H2 | | DMAC = H2 | +-----------+ +------------+ +-----------+ | SMAC = H1 | | SMAC = H1 | | SMAC = H1 | +-----------+ +------------+ +-----------+ | VLAN-ID | | VLAN-ID | | VLAN-ID | +-----------+ +------------+ +-----------+ | Payload | | Payload | | Payload | +-----------+ +------------+ +-----------+ 3.4. L2xTR auto-discovery 3.4.1 L2xTR broadcast MAC registration When xTR enable Layer 2 MAC EID mapping, it will send a MAP-Register message to MS. MAP-Register message include the broadcast address FFFF.FFFF.FFFF mapping to the xTR's RLOCs. K.Fang Expires July 2012 [Page 7] Internet-Draft LISP based L2VPN Jan 2012 Map Server add the L2xTR's RLOCs in the database for other xTR auto discovery the L2xTRs. This procedure need to run frequently (RECOMMEND interval than 30s). 3.4.2 L2xTR auto-discovery After finish Broadcast address MAP-register procedure, the L2xTR send MAP-Request for Broadcast address(EID=FFFF.FFFF.FFFF) to MR. Map-Server response MAP-Reply with all available RLOCs. Then L2xTR find all the other L2xTRs. This procedure need to run frequently (RECOMMEND interval less than 30s). 3.5. MAC learning 1. Host-A attached on L2xTR-A, L2xTR-A send MAP-Request to MR find if is there any previously record(Consider Host Roaming) [Detailed Host roaming behavior defined in section 3.6] 2.L2xTR-A send Map-register to MS. 3.Host-A send ARP request. 4.L2xTR-A broadcast to ALL L2xTRs. 5.Other L2xTRs receive the ARP packet and broadcast to local LAN. L2xTR glean the src-MAC/RLOC, and then send MAP-request to MR for post validation. 6.Host-B send ARP-Reply, and L2xTR-B send ARP-response back to L2xTR-A. 7.L2xTR-A glean the MACb and RLOCb , and then MAP-request to MR for post validation. K.Fang Expires July 2012 [Page 8] Internet-Draft LISP based L2VPN Jan 2012 3.5.1 Detailed MAC learning flow L2xTR-A MS MR L2xTR-B | | | | | MAP Register | | | | FFFF.FFFF.FFFF | | | |------------------->| | | | MAP Request | | | | FFFF.FFFF.FFFF | | | |------------------->| | | | MAP Reply with | | | | all the other | | | | L2xTR's RLOC list| | | |<-------------------| | | | | | | HostA online | | HostB online MAC = MACa | | MAC = MACb | | | | | MAP Request | | MAP Request | | MACa | | MACb | |------------------------------------->|<-----------------| | MAP Register | MAP Register | | MACa | MACb | |------------------->|<-----------------------------------| | | | | | Arp Request to broadcast to all the other | | L2xTR(auto-discovery by previously MAP reply) | |-------------------------------------------------------->| | | | | | | | glean MACa | | | | | ARP Reply with MACb | |<--------------------------------------------------------| | | | MAP-Request MACa| glean MACb | | (post validation)| | | |<-----------------| | MAP-Req MACb(post validation) | | |------------------------------------->| | 3.6. MAC Withdraw 3.6.1 Aging Timer L2xTR that learn remote MAC addresses SHOULD have an aging mechanism to remove unused entries associated with the RLOCs. This is important both for conservation of memory and for administrative purposes. For example, if host A is shutdown, eventually the other L2xTRs should Unlearn A's MAC. K.Fang Expires July 2012 [Page 9] Internet-Draft LISP based L2VPN Jan 2012 When the L2xTR receive packet, RLOC information MAY be gleaned from received tunneled packets. And a "glean timer" is started, before " glean timer" expire, the L2xTR need send out MAP Request for post validation. If post validation failure, the L2xTR should remove the gleaned cache. If post validation successful, the "MAC aging" timer start. The aging timer for MAC address M SHOULD be reset when a packet with source MAC address M is received. 3.6.2 Link down (Un-register to MS) When the LAN link down, the L2xTR SHOULD Un-Register the MAC-to-RLOC Mapping, The L2xTR SHOULD send MAP-Register message only carrier the MAC address(Record without RLOC and Priority), and the Record TTL SHOULD be set to ZERO. 3.6.3 Unclean other L2xTR Local cache Other L2xTR may still hold the map-cache, when the other L2ITR send LISP Data with expired Dst-MAC and Dst-RLOC. The L2ETR SHOULD send ARP request in site-local LAN, if there is no response, the L2ETR SHOULD send MAP-Clean cache-Request message to ask the L2ITR remove local cache. MAP-Clean Cache-Request 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=1 |A|M|P|S|p|s|C|c| Reserved | IRC | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-EID-AFI | Source EID Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C bit : introduce new C bit, if C bit = 1, this message is Clean-Cache Request message. c bit : it defined the local/remote clean mechanism if c bit = 0, the router check EID/IP.src in local map-cache, and remove the entry. if c bit = 1, the router check EID/IP.dst in local map-datbase, and remove the entry. K.Fang Expires July 2012 [Page 10] Internet-Draft LISP based L2VPN Jan 2012 3.7. MAC move(Endpoint Mobility) When a host(MACb) move from L2xTR-B to L2xTR-C: 1.If L2xTR-C's MAC table does not have previously MACb-to-RLOCb's record, L2xTR-C SHOULD send MAP-Request to find previously mapping, and store the MAP-Version. 2.L2xTR-C send MAP-Register to MS with new MAP-Version. MS update record. 3.L2xTR-C send MAP-Clean Cache-Request(Cc = "11") to L2xTR-B 4.L2xTR-B remove local entry 5.Host send traffic to other L2xTR, other L2xTR glean the MAC/RLOC mapping and update local cache, then execute post validation. 3.8. Multicast and STP 3.8.1. PIM Free Core Many lisp router need deploy in internet across multiple ISPs, only unicast reachable between L2xTRs. If L2xTR enable STP, it MUST send MAP-Register with EID="0180.C200.0000" to MS. Then it SHOULD send MAP-request to get all the other STP enabled LISP Router to join the multicast group. When L2xTR receive IGMP join message, it MUST send MAP-Register with Multicast EID, Then it SHOULD send MAP-request to get all the other xTR who is join in this group. 3.8.2. PIM Core Follow the previously LISP multicast implementation, assign Multicast MAC Mapping to CORE-MultiCast Address, and use core router replicate packet. 4. Security Considerations Security for the LISP-L2VPN design builds upon the security fundamentals found in LISP [LISP] for data-plane security and the LISP Map Server [LISP-MS] registration security. 5. IANA Considerations Add C bit and c bit in MAP-Request message. Add new LACF type AFI=7 for MAC-To-RLOC mapping option-B K.Fang Expires July 2012 [Page 11] Internet-Draft LISP based L2VPN Jan 2012 6. References [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-farinacci-lisp-lcaf-06.txt (work in progress). [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", April 2011. [LISP-Map-Server] Farinacci, D. and V. Fuller, "LISP Map Server", draft-ietf-lisp-ms-08 work in progress, June 2011. Authors' Addresses Kevin Fang Cisco Systems EMail: zhiyfang&cisco.com K.Fang Expires July 2012 [Page 12]