idnits 2.17.1 draft-perlman-trill-cloudlet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 30, 2012) is 4259 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Directory' == Outdated reference: A later version (-09) exists of draft-eastlake-isis-rfc6326bis-07 == Outdated reference: A later version (-09) exists of draft-ietf-trill-esadi-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL WG Radia. Perlman 3 Internet-Draft Intel Labs 4 Intended status: Standards Track Fangwei. Hu 5 Expires: January 31, 2013 ZTE Corporation 6 Donald. Eastlake 3rd 7 Huawei technology 8 July 30, 2012 10 TRILL Cloudlet 11 draft-perlman-trill-cloudlet-00 13 Abstract 15 This draft addresses the problems of nickname exhaustion, size of 16 endnode learning table in access RBs, and the size of the core TRILL 17 network. It does this by creating an invisible level of hierarchy at 18 the edge that we refer to as a "cloudlet". 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 31, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Smart Endnode . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Building a Cloudlet . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Overview 67 The IETF TRILL (Transparent Interconnection of Lots of Links) 68 protocol implemented by devices called RBridges (Routing Bridges, 69 [RFC6325]), provides optimal pair-wise data frame forwarding without 70 configuration, safe forwarding even during periods of temporary 71 loops, and support for multipathing of both unicast and multicast 72 traffic. TRILL accomplishes this by using IS-IS([RFC1195]) 73 ([RFC6165]) ([RFC6326bis])link state routing and encapsulating 74 traffic using a header that includes a hop count.Devices that 75 implement TRILL are called "RBridges" (Routing Bridges) or TRILL 76 Switches. 78 This draft addresses the problems of nickname exhaustion, size of 79 endnode learning table in access RBs, and the size of the core TRILL 80 network. It does this by creating an invisible level of hierarchy at 81 the edge that we refer to as a "cloudlet". 83 A cloudlet looks to the core like a collection of endnodes attached 84 to a core access RB. The cloudlet can be a mixture of endnodes, 85 hypervisors, switches, and simple RBs. A cloudlet will not consume 86 nicknames, nor introduce LSPs into the core. In this draft we will 87 build the concept from the simplest case; a cloudlet consisting of a 88 single endnode, and expand the idea in subsequent sections. 90 2. Terminology 92 This document uses the acronyms defined in([RFC6325]) and the 93 following phrase: 95 Smart end node: An end node that can do TRILL encapsulation/ 96 decapsulation. 98 Simple RBridge: An edge RBridge that assign its nickname to the smart 99 end node attached. It should response the querying from its attached 100 smart end node. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in ([RFC2119]). 106 3. Smart Endnode 108 Suppose endnode E is attached to RBridge R. E signals to R that E 109 wishes to be a "smart endnode". Let's take the figure 1 as the 110 example. 112 E------R 114 figure1 116 E, will do TRILL encapsulation/decapsulation and endnode learning of 117 endnodes it is in communication with, freeing its attached RB, R, 118 from learning the addresses of nodes corresponding with E. When E 119 encapsulates, E uses R's nickname as "ingress" in the TRILL header. 121 Although this draft is explaining the concept rather than exact 122 details of packet formats, a logical way for E to signal R that E 123 wishes to act as a smart endnode is by having E issue a TRILL-Hello, 124 with a flag indicating that E wants to be a "smart endnode", and 125 perhaps a flag indicating that E wishes to receive ESADI. A logical 126 way for R to respond is by including E in its neighbor list in R's 127 TRILL-Hello, with a flag indicating that R hears E's Hello, but 128 acknowledges that E is a smart endnode rather than a true RB 129 neighbor. R also includes R's nickname in its TRILL-Hello. 131 The endnode E does not issue LSPs, nor does it receive LSPs. It does 132 the following: 134 o It keeps an endnode table of (MAC, nickname) of end nodes with 135 which the smart end node is communicating. Entries in this table 136 are populated the same way that an edge RBridge populates the 137 entries in its table: 139 * learning from (source, ingress) on packets it decapsulates 141 * from ESADI([TRILL-ESADI]), TRILL ESADI is an end station system 142 distribution protocol, which can be used to distribute the 143 (MAC,nickname) entry. 145 * by querying a directory,Smart end node E can get the (MAC, 146 nickname) entry by querying a directory. The RBridges which 147 the smart end nodes are attached act as directory server. Both 148 the push and pull model are supported in this 149 document([Directory]). In push model, the RBridge pushes down 150 the MAC and egress nickname mapping for the hosts which might 151 communicate with hosts attached to the RBridge. In pull 152 model,smart end node sends a pull request to the RBridge if it 153 has no the entry of (MAC, nickname) of the destination end 154 node. 156 * by having some entries configured 158 The Simple RBridge R does the following: 160 o It marks the port to smart end node E as being "leave 161 encapsulated" 163 o For attached access ports, simple RBridge R keeps, for each such 164 port, a set of MAC addresses of end nodes on those ports. For 165 each of those MAC addresses, R keeps a new flag indicating whether 166 that MAC address is a "smart endnode". 168 o When receiving a packet with R's nickname as egress, if the 169 destination MAC address in the enclosed packet is listed as "smart 170 endnode", R leaves the packet encapsulated when forwarding to E. 172 4. Multi-homing 174 Now suppose E is attached to the TRILL campus in two places; to 175 RBridges R1 and R2. 177 There are two ways for this to work: 179 (1) E can choose either R1 or R2's nickname, when encapsulating a 180 frame, whether the encapsulated frame is sent via R1 or R2. 181 Most likely, E would always choose the same one, unless that one 182 was unreachable, and then E would switch to the other. 184 (2) R1 and R2 might indicate, in their Hello, another nickname that 185 attached end nodes may use if they are multihomed to R1 and R2, 186 separate from R1 and R2's nicknames (which they would also list 187 in their Hello). This would be useful if there were many end 188 nodes multihomed to the same set of RBridges. This would be 189 analogous to a pseudonode nickname; return traffic would go via 190 the shortest path from the source to the endnode, whether it is 191 R1 or R2. If E loses connectivity to R2, then E would revert to 192 using R1's nickname. This does use a nickname, but hopefully 193 would be shared by many end nodes multihomed to the same set of 194 RBridges. 196 (When end ndoe E loses connectivity to one of the RBridges, how to 197 detect the connectionless and how to switch to another RBridge will 198 be defined later in this document.) 200 5. Building a Cloudlet 202 Another level of functionality might be to build reasonably large 203 cloudlets, with multiple hops of ordinary spanning tree bridges, 204 and/or "simple RBridges". A "simple RBridge" is one that only is 205 aware of the topology of the cloudlet. In other words, the cloudlet 206 operates like a lower level of routing. Inside the TRILL core, 207 forwarding is based on nicknames. Inside the cloudlet, forwarding is 208 based on MAC addresses of the end nodes in the cloudlet, although the 209 packet being forwarded may be encapsulated with a TRILL header. If 210 all end nodes in the cloudlet are smart end nodes, then packets 211 inside the cloudlet would always be encapsulated. If there in a 212 "normal" endnode N, in the cloudlet, then N would issue 213 unencapsulated packets, and the first simple RBridge R1, would 214 encapsulate it, and R1 would maintain the endnode cache entries for 215 end nodes communicating with N. Likewise, when R1 is forwarding to N, 216 R1 would decapsulate the packet. 218 RBridges within the cloudlet have to know whether the packet belongs 219 in the cloudlet or the TRILL campus. This is done based on the 220 "egress nickname" in the encapsulated packet. If the egress nickname 221 is the nickname to be used by the cloudlet, then the packet is 222 forwarded only within the cloudlet. If the egress nickname is not 223 one used by the cloudlet, the packet is forwarded to the "true 224 RBridge" that attaches the cloudlet to the TRILL campus. If the 225 cloudlet is multihomed to R1 and R2, say, and the "ingress nickname" 226 indicates R1's nickname, then the cloudlet forwards the encapsulated 227 packet towards R1. If the cloudlet is multihomed and is using a 228 pseudonode nickname, then the cloudlet forwards to whichever of R1 or 229 R2 is closer. 231 6. Security Considerations 233 For general TRILL Security Considerations, see([RFC6325]). 235 7. Acknowledgements 237 TBD 239 8. IANA Considerations 241 9. Normative References 243 [Directory] 244 Linda, D., Eastlake, D., Perlman, R., and I. Gashinsky, 245 "TRILL Edge Directory Assistance Framework", raft-ietf- 246 trill-directory-framework-00 (work in process), July 2012. 248 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 249 dual environments", RFC 1195, December 1990. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 255 Systems", RFC 6165, April 2011. 257 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 258 Ghanwani, "Routing Bridges (RBridges): Base Protocol 259 Specification", RFC 6325, July 2011. 261 [RFC6326bis] 262 Eastlake, D., Banerjee, A., Dutt, D., Ghanwani, A., and R. 263 Perlman, "Transparent Interconnection of Lots of Links 264 (TRILL) Use of IS-IS", 265 draft-eastlake-isis-rfc6326bis-07.txt, work in process, 266 March 2012. 268 [TRILL-ESADI] 269 Zhai, H., Hu, F., Perlman, R., and D. Eastlake, "TRILL 270 (Transparent Interconnection of Lots of Links): The ESADI 271 (End Station Address Distribution Information) Protocol", 272 draft-ietf-trill-esadi-00.txt (work in process), 273 June 2012. 275 Authors' Addresses 277 Radia Perlman 278 Intel Labs 279 2200 Mission College Blvd. 280 Santa Clara, CA 95054-1549 281 USA 283 Phone: +1-408-765-8080 284 Email: Radia@alum.mit.edu 286 Fangwei Hu 287 ZTE Corporation 288 No.889 Bibo Rd 289 Shanghai, 201203 290 China 292 Phone: +86 21 68896273 293 Email: hu.fangwei@zte.com.cn 294 Donald Eastlake,3rd 295 Huawei technology 296 155 Beaver Street 297 Milford, MA 01757 298 USA 300 Phone: +1-508-634-2066 301 Email: d3e3e3@gmail.com