TRILL WG Radia. Perlman Internet-Draft Intel Labs Intended status: Standards Track Fangwei. Hu Expires: January 31, 2013 ZTE Corporation Donald. Eastlake 3rd Huawei technology July 30, 2012 TRILL Cloudlet draft-perlman-trill-cloudlet-00 Abstract This draft addresses the problems of nickname exhaustion, size of endnode learning table in access RBs, and the size of the core TRILL network. It does this by creating an invisible level of hierarchy at the edge that we refer to as a "cloudlet". Status of this Memo 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 January 31, 2013. Copyright Notice Copyright (c) 2012 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 Perlman, et al. Expires January 31, 2013 [Page 1] Internet-Draft TRILL Cloudlet July 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Smart Endnode . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Building a Cloudlet . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Perlman, et al. Expires January 31, 2013 [Page 2] Internet-Draft TRILL Cloudlet July 2012 1. Overview The IETF TRILL (Transparent Interconnection of Lots of Links) protocol implemented by devices called RBridges (Routing Bridges, [RFC6325]), provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS([RFC1195]) ([RFC6165]) ([RFC6326bis])link state routing and encapsulating traffic using a header that includes a hop count.Devices that implement TRILL are called "RBridges" (Routing Bridges) or TRILL Switches. This draft addresses the problems of nickname exhaustion, size of endnode learning table in access RBs, and the size of the core TRILL network. It does this by creating an invisible level of hierarchy at the edge that we refer to as a "cloudlet". A cloudlet looks to the core like a collection of endnodes attached to a core access RB. The cloudlet can be a mixture of endnodes, hypervisors, switches, and simple RBs. A cloudlet will not consume nicknames, nor introduce LSPs into the core. In this draft we will build the concept from the simplest case; a cloudlet consisting of a single endnode, and expand the idea in subsequent sections. 2. Terminology This document uses the acronyms defined in([RFC6325]) and the following phrase: Smart end node: An end node that can do TRILL encapsulation/ decapsulation. Simple RBridge: An edge RBridge that assign its nickname to the smart end node attached. It should response the querying from its attached smart end node. 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]). 3. Smart Endnode Suppose endnode E is attached to RBridge R. E signals to R that E wishes to be a "smart endnode". Let's take the figure 1 as the example. Perlman, et al. Expires January 31, 2013 [Page 3] Internet-Draft TRILL Cloudlet July 2012 E------R figure1 E, will do TRILL encapsulation/decapsulation and endnode learning of endnodes it is in communication with, freeing its attached RB, R, from learning the addresses of nodes corresponding with E. When E encapsulates, E uses R's nickname as "ingress" in the TRILL header. Although this draft is explaining the concept rather than exact details of packet formats, a logical way for E to signal R that E wishes to act as a smart endnode is by having E issue a TRILL-Hello, with a flag indicating that E wants to be a "smart endnode", and perhaps a flag indicating that E wishes to receive ESADI. A logical way for R to respond is by including E in its neighbor list in R's TRILL-Hello, with a flag indicating that R hears E's Hello, but acknowledges that E is a smart endnode rather than a true RB neighbor. R also includes R's nickname in its TRILL-Hello. The endnode E does not issue LSPs, nor does it receive LSPs. It does the following: o It keeps an endnode table of (MAC, nickname) of end nodes with which the smart end node is communicating. Entries in this table are populated the same way that an edge RBridge populates the entries in its table: * learning from (source, ingress) on packets it decapsulates * from ESADI([TRILL-ESADI]), TRILL ESADI is an end station system distribution protocol, which can be used to distribute the (MAC,nickname) entry. * by querying a directory,Smart end node E can get the (MAC, nickname) entry by querying a directory. The RBridges which the smart end nodes are attached act as directory server. Both the push and pull model are supported in this document([Directory]). In push model, the RBridge pushes down the MAC and egress nickname mapping for the hosts which might communicate with hosts attached to the RBridge. In pull model,smart end node sends a pull request to the RBridge if it has no the entry of (MAC, nickname) of the destination end node. * by having some entries configured The Simple RBridge R does the following: Perlman, et al. Expires January 31, 2013 [Page 4] Internet-Draft TRILL Cloudlet July 2012 o It marks the port to smart end node E as being "leave encapsulated" o For attached access ports, simple RBridge R keeps, for each such port, a set of MAC addresses of end nodes on those ports. For each of those MAC addresses, R keeps a new flag indicating whether that MAC address is a "smart endnode". o When receiving a packet with R's nickname as egress, if the destination MAC address in the enclosed packet is listed as "smart endnode", R leaves the packet encapsulated when forwarding to E. 4. Multi-homing Now suppose E is attached to the TRILL campus in two places; to RBridges R1 and R2. There are two ways for this to work: (1) E can choose either R1 or R2's nickname, when encapsulating a frame, whether the encapsulated frame is sent via R1 or R2. Most likely, E would always choose the same one, unless that one was unreachable, and then E would switch to the other. (2) R1 and R2 might indicate, in their Hello, another nickname that attached end nodes may use if they are multihomed to R1 and R2, separate from R1 and R2's nicknames (which they would also list in their Hello). This would be useful if there were many end nodes multihomed to the same set of RBridges. This would be analogous to a pseudonode nickname; return traffic would go via the shortest path from the source to the endnode, whether it is R1 or R2. If E loses connectivity to R2, then E would revert to using R1's nickname. This does use a nickname, but hopefully would be shared by many end nodes multihomed to the same set of RBridges. (When end ndoe E loses connectivity to one of the RBridges, how to detect the connectionless and how to switch to another RBridge will be defined later in this document.) 5. Building a Cloudlet Another level of functionality might be to build reasonably large cloudlets, with multiple hops of ordinary spanning tree bridges, and/or "simple RBridges". A "simple RBridge" is one that only is aware of the topology of the cloudlet. In other words, the cloudlet Perlman, et al. Expires January 31, 2013 [Page 5] Internet-Draft TRILL Cloudlet July 2012 operates like a lower level of routing. Inside the TRILL core, forwarding is based on nicknames. Inside the cloudlet, forwarding is based on MAC addresses of the end nodes in the cloudlet, although the packet being forwarded may be encapsulated with a TRILL header. If all end nodes in the cloudlet are smart end nodes, then packets inside the cloudlet would always be encapsulated. If there in a "normal" endnode N, in the cloudlet, then N would issue unencapsulated packets, and the first simple RBridge R1, would encapsulate it, and R1 would maintain the endnode cache entries for end nodes communicating with N. Likewise, when R1 is forwarding to N, R1 would decapsulate the packet. RBridges within the cloudlet have to know whether the packet belongs in the cloudlet or the TRILL campus. This is done based on the "egress nickname" in the encapsulated packet. If the egress nickname is the nickname to be used by the cloudlet, then the packet is forwarded only within the cloudlet. If the egress nickname is not one used by the cloudlet, the packet is forwarded to the "true RBridge" that attaches the cloudlet to the TRILL campus. If the cloudlet is multihomed to R1 and R2, say, and the "ingress nickname" indicates R1's nickname, then the cloudlet forwards the encapsulated packet towards R1. If the cloudlet is multihomed and is using a pseudonode nickname, then the cloudlet forwards to whichever of R1 or R2 is closer. 6. Security Considerations For general TRILL Security Considerations, see([RFC6325]). 7. Acknowledgements TBD 8. IANA Considerations 9. Normative References [Directory] Linda, D., Eastlake, D., Perlman, R., and I. Gashinsky, "TRILL Edge Directory Assistance Framework", raft-ietf- trill-directory-framework-00 (work in process), July 2012. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. Perlman, et al. Expires January 31, 2013 [Page 6] Internet-Draft TRILL Cloudlet July 2012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011. [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6326bis] Eastlake, D., Banerjee, A., Dutt, D., Ghanwani, A., and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", draft-eastlake-isis-rfc6326bis-07.txt, work in process, March 2012. [TRILL-ESADI] Zhai, H., Hu, F., Perlman, R., and D. Eastlake, "TRILL (Transparent Interconnection of Lots of Links): The ESADI (End Station Address Distribution Information) Protocol", draft-ietf-trill-esadi-00.txt (work in process), June 2012. Authors' Addresses Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA Phone: +1-408-765-8080 Email: Radia@alum.mit.edu Fangwei Hu ZTE Corporation No.889 Bibo Rd Shanghai, 201203 China Phone: +86 21 68896273 Email: hu.fangwei@zte.com.cn Perlman, et al. Expires January 31, 2013 [Page 7] Internet-Draft TRILL Cloudlet July 2012 Donald Eastlake,3rd Huawei technology 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-634-2066 Email: d3e3e3@gmail.com Perlman, et al. Expires January 31, 2013 [Page 8]