idnits 2.17.1 draft-cheng-lisp-shdht-03.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 : ---------------------------------------------------------------------------- == There are 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2013) is 4081 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) ** Downref: Normative reference to an Experimental draft: draft-meyer-lisp-mn (ref. 'I-D.meyer-lisp-mn') -- Possible downref: Non-RFC (?) normative reference: ref. 'I-ietf-lisp-ddt' -- Possible downref: Non-RFC (?) normative reference: ref. 'LISP-DHT' ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Downref: Normative reference to an Experimental RFC: RFC 6836 -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group L. Cheng 3 Internet-Draft M. Sun 4 Intended status: Standards Track ZTE Corporation 5 Expires: August 25, 2013 February 21, 2013 7 draft-cheng-lisp-shdht-03 8 LISP Single-Hop DHT Mapping Overlay 10 Abstract 12 This draft specifies the LISP Single-Hop Distributed Hash Table 13 Mapping Overlay (LISP-SHDHT), a distributed mapping database which 14 embodies SHDHT Nodes to maintain (Key, value) pairs for LISP 15 (Locator/ID Separation Protocol)-like architecture, wherein every 16 (key value) pair corresponds to an EID(Endpoint ID)-to-RLOC(Routing 17 Locator) mapping information entry. According to this strategy, EID 18 is hashed to be a unique Resource ID which is used for locating 19 destination DHT Node who maintains mapping entry for the particular 20 EID. Furthermore, adaptive hash space partition method is adopted to 21 solve the load balance problem on SHDHT Nodes which is common on 22 traditional DHT planes. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 25, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 60 3. SHDHT Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Node ID and Partition ID . . . . . . . . . . . . . . . . . 7 62 3.2. Data Storage and Hash Assignment . . . . . . . . . . . . . 8 63 3.3. Node Routing Table . . . . . . . . . . . . . . . . . . . . 9 64 4. LISP SHDHT . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1. ITR Operation . . . . . . . . . . . . . . . . . . . . . . 10 66 4.2. ETR Operation . . . . . . . . . . . . . . . . . . . . . . 10 67 4.3. SHDHT Map Resolver Operation . . . . . . . . . . . . . . . 11 68 4.4. SHDHT Map Server Operation . . . . . . . . . . . . . . . . 11 69 4.5. Encapsulated Message Format . . . . . . . . . . . . . . . 12 70 4.5.1. Encapsulated Map Request . . . . . . . . . . . . . . . 13 71 5. Domain LISP SHDHT Deployment . . . . . . . . . . . . . . . . . 14 72 5.1. SHDHT Border Node . . . . . . . . . . . . . . . . . . . . 14 73 5.2. Mapping Register . . . . . . . . . . . . . . . . . . . . . 15 74 5.2.1. Intra Domain Mapping Register . . . . . . . . . . . . 15 75 5.2.2. Inter Domain Mapping Register . . . . . . . . . . . . 15 76 5.3. Mapping Request . . . . . . . . . . . . . . . . . . . . . 16 77 5.3.1. Intra Domain Mapping Request . . . . . . . . . . . . . 16 78 5.3.2. Inter Domain Mapping Request . . . . . . . . . . . . . 17 79 6. Mobility Considerations . . . . . . . . . . . . . . . . . . . 18 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 84 9.2. Informational References . . . . . . . . . . . . . . . . . 21 85 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 Locator/ID Separation Protocol (LISP) [RFC6830] specifies an 91 architecture and mechanism for replacing the address currently used 92 by IP with two separate name spaces: Endpoint IDs (EIDs), used within 93 LISP sites, and Routing Locators (RLOCs), used on transit networks 94 that make up the Internet infrastructure. To achieve this 95 separation, LISP defines protocol mechanisms for mapping from EIDs to 96 RLOCs. As a result, an efficient database is needed to store and 97 propagate those mappings globally. Several such mapping databases 98 have been proposed, among them: LISP-NERD [I-D.lear-lisp-nerd], LISP- 99 ALT[RFC6836], LISP-DDT[I-ietf-lisp-ddt], and LISP-DHT [LISP-DHT]. 101 According to hybrid model databases such like LISP-ALT [RFC6836] and 102 LISP-DDT [I-ietf-lisp-ddt], architectures of these mapping databases 103 are based on announcement/delegation of hierarchically-delegated 104 segments of EID namespace (i.e., prefixes). Therefore, based on 105 these architectures, when a roaming event occurs and a LISP site or a 106 LISP MN receives new RLOCs, the site or MN has to anchor pre- 107 configured map-server to register its new mapping information no 108 matter where the site or MN currently locates, just in order to 109 protect EID prefixes announced aggregately in the database 110 [I-D.meyer-lisp-mn]. 112 As a DHT strategy based mapping database, LISP-DHT [LISP-DHT] 113 exhibits several interesting properties, such as self-configuration, 114 self-maintenance, scalability and robustness that are clearly 115 desirable for a EID-to-RLOC resolution service. However, this 116 database is based on multi-hop Chord DHT. On one hand, inquiries of 117 mapping information in this case need to pass through iterative 118 multi-hop lookup steps which will cause relatively large delay time. 119 On the other hand, load balance between Chord nodes is another 120 essential problem need to be solved. 122 This draft specifies a LISP Single-Hop Distributed Hash Table Mapping 123 Overlay (LISP-SHDHT) which provides mapping information lookup 124 service for sites running LISP. Main characters of this strategy is 125 that, 127 1. Each SHDHT Node maintains routing information for all other SHDHT 128 Nodes. Thus, messages interaction between SHDHT Nodes in the 129 same SHDHT overlay just need one or two hops. 131 2. Traditionally, Node IDs are used to identify DHT nodes and 132 represent hash space arrangement on DHT nodes. In SHDHT 133 strategy, the two roles are separated. Partition IDs are adopted 134 for hash space arrangement and a build-in load balancing solution 135 is designed. 137 This draft specifies the outline of SHDHT and the basic application 138 of LISP SHDHT. In actual deployment of LISP SHDHT, mapping database 139 could be maintained by multiple mapping service providers and could 140 be deployed as collaborative combination of multiple Domain LISP 141 SHDHTs. Details about Domain LISP SHDHT Deployment are introduced in 142 Section 5. Security strategies on/between Domain LISP SHDHTs is for 143 future study. 145 2. Definition of Terms 147 This draft uses terms defined in [RFC6830]. This section defines 148 some new terms used in this document. 150 SHDHT: Single-Hop Distributed Hash Table Mapping Overlay. 152 SHDHT Node: Physical nodes which compose SHDHT overlay's topology. 153 Each SHDHT Node has a unique Node ID and maintains multiple hash 154 space segments which labeled by Partition IDs. Each SHDHT Node 155 maintains a Node Routing Table of local SHDHT Mapping Overlay. 156 SHDHT Nodes locates in the same Mapping Overlay implement hash 157 operation based on the same hash algorithm. SHDHT Nodes hash data 158 object to be a unique Resource ID, and perform put/get/move 159 operations based on the Resource IDs. 161 Node ID: Node identifier, which is used for maintenance. Each SHDHT 162 Node has a unique Node ID. The ring containing Node IDs indicates 163 overlay's topology. 165 Partition ID: Partition identifier, which is used for hash space 166 assignment. Partition IDs and Resource IDs share the same hash 167 space. All Partition IDs in overlay are unique. Each SHDHT Node 168 could have multiple Partition IDs. The ring containing Partition 169 IDs determines how the hash space is partitioned into segments and 170 how these segments are assigned to nodes. 172 Resource ID: Each data object stored in DHT overlay could be hashed 173 to be a unique Resource ID. In LISP-SHDHT strategy, data objects 174 correspond to the EIDs. Resource IDs share the same hash space 175 with Partition IDs. As a result, SHDHT Nodes perform data objects 176 put/get/remove operations based on these IDs. 178 Node Routing Table: Routing table of a SHDHT Mapping Overlay which 179 contains all SHDHT Nodes information of this overly, including 180 Node IDs, Partition IDs and Node IP addresses, etc. Each SHDHT 181 Node of this overly will maintain the Routing Table. 183 SHDHT Map Server: A SHDHT Node that also implements Map Server 184 functionality (forwarding Map-Requests and/or return Map Replies 185 if offering proxy Map-Reply service) for mapping entries it 186 maintains. 188 SHDHT Map Resolver: A SHDHT Node that also implements Map Resolver 189 functionality (accepting Map-Requests, hash the requested EID to 190 be Resource ID, and then forward Map-Requests to corresponding 191 SHDHT Map Server based on Resource ID). Furthermore, in this 192 document SHDHT Map Resolver could perform as proxy for Map- 193 Register. SHDHT Map Resolver could accept register messages and 194 forward them to SHDHT Map Servers. 196 SHDHT Border Node: SHDHT Border Node locates on the border of a 197 Domain SHDHT Overlay. Each SHDHT Border Node maintains an Inter- 198 Domain Routing Table. SHDHT Border Nodes are used to flood cross 199 domain routing and forward cross domain packets. 201 Inter-Domain Routing Ttable: A routing table maintained on a SHDHT 202 Border Node. This routing table contains information of other 203 Domain SHDHT Overlays, such like EID prefixes other domain 204 overlays maintain, IP addresses and ports information of other 205 overlay's Border Nodes. 207 3. SHDHT Overview 209 3.1. Node ID and Partition ID 211 Most of existing DHTs use node IDs for both maintenance and hash 212 space arrangement. For example, in LISP-DHT[LISP-DHT], each chord 213 node of the DHT ring has a unique k-bits identifier (ChordID). Nodes 214 perform operations such like put/get/remove based on ChordIDs. 215 Furthermore, ChordIDs are also used to associate nodes with hash 216 space segments that the nodes responsible for. 218 In SHDHT, two roles of maintenance and hash space arrangement are 219 separated and a new kind identifier called Partition ID is adopted. 220 Each SHDHT node has a unique Node ID which identifies the physical 221 node and multiple Partition IDs which represent hash space segments. 222 All Partition IDs in the overlay are also unique. Node IDs and 223 Partition IDs are mapped into two ring-shaped spaces respectively. 224 The ring containing Node IDs indicates the overlay's topology. The 225 ring containing Partition IDs determines how the hash space is 226 partitioned into segments and how these segments are assigned to 227 nodes. It is noteworthy that SHDHT Nodes could determine number of 228 Partition IDs on them separately and could generate Partition IDs 229 randomly just need to make sure that the generated Partition IDs will 230 not conflict with existing Partition IDs on the SHDHT plane. 232 +--------------------+ +--------------------+ 233 |Node ID: 0x0123| |Node ID: 0x4444| 234 |Partition ID: 0x1234| +-----+ +-----+ |Partition ID: 0x9000| 235 | 0x7000| |Node1+----------+Node2| | 0x3234| 236 +--------------------+ +--+--+ +--+--+ +--------------------+ 237 | | 238 | | 239 | | 240 | | 241 +--------------------+ +--+--+ +--+--+ +--------------------+ 242 |Node ID: 0xe000| |Node3+----------+Node4| |Node ID: 0xc000| 243 |Partition ID: 0x5000| +-----+ +-----+ |Partition ID: 0xaaaa| 244 | 0xeeee| | 0xcccc| 245 +--------------------+ +--------------------+ 247 Fig.1 SHDHT Deployment Example 249 As shown in Fig.1 is an example of SHDHT. This SHDHT overlay is 250 consist of four SHDHT NODEs each has a unique Node ID and maintains 251 two Partition IDs. According to this deployment, hash space is 252 partitioned to be eight segments each is indexed by a Partition ID. 253 From Fig. 1, it could be observed that hash space segments are not 254 required to be partitioned equally. As SHDHT Nodes could general 255 Partition IDs separately, when a SHDHT Node gets all hash segments 256 assignment information of other SHDHT Nodes, it will be able to 257 implement the load balance of SHDHT overlay by general proper 258 Partition IDs. 260 In SHDHT, each SHDHT Node stores and maintains data objects. Data 261 objects are indexed by Resource IDs which share the same hash space 262 with Partition IDs and will locate in the hash space segments whose 263 Partition IDs are closest to their Resource IDs. 265 For example, for a data object whose Resource ID is 0x8213, the 266 Resource ID locates between Partition ID 0x7000 and Partition ID 267 0x9000. As Partition ID 0x9000 is closer to Resource ID 0x8213, the 268 data object will be stored and maintained on Node2 who is assigned 269 with the hash space segment indexed by Partition ID 0x9000. 271 3.2. Data Storage and Hash Assignment 273 In traditional DHTs, hash space is partitioned into segments based on 274 node IDs. As a result, data objects are always stored in their root 275 nodes, whose node IDs are "closest" to data objects' Resource IDs. 277 What does "closest" means? Suppose we have three consecutive 278 Partition IDs a, b and c which are the only Partition IDs in SHDHT 279 for our example, then the range of each hash space segment is defined 280 as follow: 282 Partition ID a: [id(a)-0.5*d(c,a); id(a)+0.5*d(a,b)) 284 Partition ID b: [id(b)-0.5*d(a,b); id(b)+0.5*d(b,c)) 286 Partition ID c: [id(c)-0.5*d(b,c); id(c)+0.5*d(c,a)) 288 with functions 290 id(x): value of Partition ID x in hash space 292 d(x,y): distance between Partition ID x and y in hash space 294 Replications of data objects in a particular node are always stored 295 in the preceding node or successor node of the root node. The backup 296 preceding node or successor node will automatically become the new 297 closest node if the root node leaves the overlay. 299 In SHDHT, the whole hash space is partitioned into segments based on 300 partition IDs. The root node of a data object is the node, which has 301 the closest partition ID to the data object's Resource ID. In SHDHT, 302 each node can maintain multiple hash space segments with respective 303 Partition IDs. As the preceding Partition ID or successor Partition 304 ID may be owned by the same root node. Replication of data objects 305 could still be stored in preceding node or successor node of root 306 node. 308 3.3. Node Routing Table 310 In SHDHT, each node maintains a Node Routing Table containing routing 311 information of all other SHDHT Nodes locate in the same SHDHT 312 overlay. Table I shows the Node Routing Table on SHDHT Nodes of 313 Fig.1. A Node Routing Table contains all Partition IDs and their 314 associated Node IDs and node addresses. For simplification, Node IDs 315 and Partition IDs shown in the draft are only 16-bit numbers. 317 When SHDHT Node receives a message points to a particular Resource 318 ID, it could look up Node Routing Table and find out the Partition ID 319 which is closest to the Resource ID. Furthermore, message could be 320 transferred to the corresponding SHDHT Node. 322 +--------------+---------+---------------+ 323 | Partition ID | Node ID | Address | 324 +--------------+---------+---------------+ 325 | 0x1234 | 0x0123 | 10.0.0.2:2000 | 326 | 0x3234 | 0x4444 | 10.0.0.3:2000 | 327 | 0x5000 | 0xe000 | 10.0.0.4:2000 | 328 | 0x7000 | 0x0123 | 10.0.0.2:2000 | 329 | 0x9000 | 0x4444 | 10.0.0.3:2000 | 330 | 0xaaaa | 0xc000 | 10.0.0.5:2000 | 331 | 0xcccc | 0xc000 | 10.0.0.5:2000 | 332 | 0xeeee | 0xe000 | 10.0.0.4:2000 | 333 +--------------+---------+---------------+ 335 TABLE I SHDHT Node Routing Table 337 For example, if Node 1 (ID: 0x1234) in Fig.1 needs to implement put/ 338 get/remove operations for a data object with Resource ID 0x8213. 339 Node 1 first looks up its Node Routing Table and finds out that the 340 closest Partition ID corresponding to this Resource ID is 0x9000. 341 Then Node 1 will send put/get/remove request to the node owns the 342 Partition ID, in Fig.1 is Node2, whose Node ID is 0x4444 and address 343 is 10.0.0.3:2000. 345 4. LISP SHDHT 347 LISP SHDHT is proposed to provide "EID-to-RLOC(s)" mapping 348 information lookup service for sites running the Locator/ID 349 Separation Protocol (LISP). 351 In LISP SHDHT, mapping overlay consists of SHDHT Nodes which play 352 roles of SHDHT Map Server and/or SHDHT Map Resolver. In this draft 353 SHDHT-MS and SHDHT-MR just represent function entities, and these 354 entities could be collocated on the same SHDHT Node. 356 All EID-to-RLOC mapping entries are stored in SHDHT Nodes as data 357 objects. Each SHDHT Node has a RLOC address. EIDs in mapping 358 entries can be hashed as Resource IDs of data objects. All SHDHT 359 Nodes in the same SHDHT overly perform hash operation based on the 360 same hash algorithm. 362 Data objects stored in LISP SHDHT Nodes may be in the following 363 format: 365 Object (lisp) = [EID prefix, (RLOC1, priority, weight), 366 ...,RLOCn, priority, weight), TTL ] 368 4.1. ITR Operation 370 According to LISP-MS [RFC6833], LISP ITRs use Map Resolvers as proxy 371 to send control messages, such like encapsulated Map-Requests and 372 Map-Replies. 374 In Scenario of LISP SHDHT, an ITR send Map-Requests directly to the 375 SHDHT Node which is selected to play roles of SHDHT Map Resolver for 376 the ITR. 378 4.2. ETR Operation 380 According to LISP-MS [RFC6833], LISP ETRs register mapping 381 information onto the Map Server by sending Map-Register messages. 383 In scenario of LISP SHDHT, ETR could send Map-Register messages 384 directly to the SHDHT Node which is selected to play roles of SHDHT 385 Map Server for the registered EIDs. 387 Alternatively, ETRs could send Map-Register messages to a nearest 388 SHDHT Node who will hash registered mapping entries to be Resource 389 IDs. Then, the SHDHT Node forwards Map-Register messages to the 390 corresponding SHDHT Map Servers based on Resource IDs. This 391 alternative strategy will be more efficient for roaming scenario. 392 Furthermore, ETRs are no longer anchoring to fixed SHDHT Map Server 393 Nodes, and ISPs who operate mapping overlays could arrange hash space 394 onto SHDHT Nodes more autonomously and could perform better load 395 balance among SHDHT Nodes. 397 4.3. SHDHT Map Resolver Operation 399 In LISP SHDHT, when a SHDHT Map Resolver receives a Map-Request 400 message from an ITR, it will perform the following operations, 402 1. SHDHT Map Resolver extracts destination EID address from the Map- 403 Request message. 405 2. SHDHT Map Resolver hashes the EID address to be Resource ID based 406 on the shared hash algorithm. 408 3. SHDHT Map Resolver looks up Node Routing Table and finds out the 409 Partition ID which matches the Resource ID. 411 4. SHDHT Map Resolver forwards Map-Request message to the 412 corresponding SHDHT Node. This SHDHT Node maintains the hash 413 space labeled by matched Partition ID and plays the role of SHDHT 414 Map Server for the requested mapping entry. 416 In LISP SHDHT, when a SHDHT Map Resolver receives a Map-Register 417 message from an ETR, it will perform the following operations, 419 1. SHDHT Map Resolver extracts registered EID information of the 420 Map-Register message. 422 2. SHDHT Map Resolver hashes the registered EID address to be 423 Resource ID based on shared hash algorithm. 425 3. SHDHT Map Resolver looks up Node Routing Table and finds out the 426 Partition ID which matches the Resource ID. 428 4. SHDHT Map Resolver forwards Map-Register message to the 429 corresponding SHDHT Map Server. 431 4.4. SHDHT Map Server Operation 433 In LISP SHDHT, when a SHDHT Map Server receives a Map-Request 434 message, it will perform the following operations, 436 1. SHDHT Map Server first check if it is responsible for the 437 requested mapping entry, i.e. if it has a hash space whose 438 Partition ID matches Resource ID of the requested EID. 440 2. SHDHT Map Server then looks for data objects in its hash space 441 according to the matched Partition ID. 443 3. If there's no data object corresponds to the requested EID, SHDHT 444 Map Server responses a negative Map-Reply message. 446 4. If there's a data object corresponds to the requested EID, SHDHT 447 Map Server will forward the Map-Request to registered ETR or 448 return Map-Reply message if it offers proxy Map-Reply service. 450 In LISP SHDHT, when a SHDHT Map Server receives a Map-Register 451 message, it will perform the following operations, 453 1. SHDHT Map Server first checks if it is responsible for the 454 registered mapping entry, i.e. if it has a hash space whose 455 Partition ID matches Resource ID of the requested EID. 457 2. SHDHT Map Server then stores and maintains the registered mapping 458 information in its hash space according to the matched Partition 459 ID. 461 4.5. Encapsulated Message Format 463 An Encapsulated Control Message (ECM) defined in[RFC6830] is used to 464 encapsulate control packets sent between xTRs and mapping database 465 system. At this time, only Map-Request messages are allowed to be 466 encapsulated in ECM format. When ITRs choose a SHDHT Node as proxy 467 to send control messages, they could use encapsulated message format 468 defined in [RFC6830], as shown in Fig.2. 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 / | IPv4 or IPv6 Header | 474 OH | (uses RLOC addresses) | 475 \ | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 / | Source Port = xxxx | Dest Port = 4342 | 478 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 \ | UDP Length | UDP Checksum | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 LH |Type=8 |S| Reserved | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 / | IPv4 or IPv6 Header | 484 IH | (uses RLOC or EID addresses) | 485 \ | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 / | Source Port = xxxx | Dest Port = yyyy | 488 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 \ | UDP Length | UDP Checksum | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 LCM | LISP Control Message | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Fig.2 Encapsulated Control Message Format 496 4.5.1. Encapsulated Map Request 498 Suppose that the selected SHDHT Node of an ITR is Node1. 500 When the ITR sends Encapsulated Map-Requests to Node1, source address 501 and destination address in message OH (Outside Header) should be RLOC 502 addresses of ITR and Node1 respectively. 504 In the IH (Inside Header), source address is still RLOC address of 505 Node1, while destination address is the inquired EID address. 507 Consider Node1 is a configured Map Resolver, and then the 508 configuration of Encapsulated Map-Request message has not been 509 changed. 511 5. Domain LISP SHDHT Deployment 513 LISP is a global architecture. In order to make LISP SHDHT meets 514 requirements of LISP mapping database better, LISP SHDHT should 515 perform better scalability and distribution attributes. Especially 516 in practical application, LISP mapping database may be operated by 517 different ISPs, when a new mapping service provider join or leave the 518 mapping database, all other providers should not be influenced to be 519 re-assigned. 521 In practice deployment, LISP SHDHT mapping overlay could be consist 522 of multiple Domain SHDHT overlays which are operated by different 523 mapping service providers. These Domain SHDHT overlays communicate 524 through SHDHT Border Nodes of each other. 526 As shown in Fig.3, there are two Domain LISP SHDHT Overlays which 527 communicate through BN1 (Border Node1) and BN2. 529 In domain LISP SHDHT deployment, different domain overlays maintain 530 EID-to-RLOC mapping information covered by different EID prefixes. 531 As in example of Fig.3, Domain 1 maintains mapping information 532 according to EID prefix 12.0.0.0/8, and Domain 2 maintains mapping 533 information covered by EID prefix 16.0.0.0/8. 535 +----+ +-----+ +-----+ +-----+ +-----+ +----+ 536 |ITR1+-----+Node1+------+Node2| |Node4+------+Node5+------+ITR2| 537 +----+ +--+--+ +--+--+ +--+--+ +--+--+ +----+ 538 | Domain | | Domain | 539 | Overlay 1 | | Overlay 2 | 540 | 12.0.0.0\8 | | 16.0.0.0\8 | 541 +----+ +--+--+ +--+--+ +--+--+ +--+--+ +----+ 542 |ETR1+-----+Node3+------+ BN1 |<->| BN2 +------+Node6+------+ETR2| 543 +----+ +-----+ +-----+ +-----+ +-----+ +----+ 545 * BN: SHDHT Border Node 547 Fig.3 Domain SHDHT Deployment Example 549 5.1. SHDHT Border Node 551 Each Domain SHDHT Overlay has one or more Border Nodes which are not 552 only to store EID-to-RLOC mapping just like normal SHDHT Nodes, but 553 also be used to flood cross domain routing and forward the cross 554 domain packets. 556 Each SHDHT Border Node maintains an Inter-Domain Routing Table, which 557 contains information of all other domain overlays, such like EID 558 prefixes other domain overlays maintain, IP addresses and ports 559 information of other overlays' Border Nodes. 561 At the beginning, Inter-Domain Routing Table could be configured on 562 SHDHT Border Nodes. Then, a SHDHT Border Node will flood cross 563 domain routing periodically to trigger other Border Nodes update 564 their Inter-Domain Routing Tables. 566 5.2. Mapping Register 568 5.2.1. Intra Domain Mapping Register 570 All SHDHT Nodes of a Domain SHDHT Overlay must be noticed the EID 571 prefixes that local domain overlay responsible for. When a SHDHT 572 Node of a domain overlay receives a Map-Register message, it checks 573 if the registered EIDs are covered by local domain overlay's EID 574 prefixes. If local domain overlay is responsible for registered 575 EIDs, SHDHT Node who receives Map-Register message will process the 576 message as procedures listed in Section 4.3. 578 Suppose in Fig.3, ETR1 registers mapping entry of EID 12.0.0.1 to 579 Node3 of Domain1. Node 3 will perform the following operations, 581 1. Node3 extracts the mapping information and finds that the 582 registered EID is 12.0.0.1. 584 2. Node3 determines that EID 12.0.0.1 is covered by Domain 1's 585 prefix 12.0.0.0/8. 587 3. Node3 hashes registered EID 12.0.0.1 to be Resource ID. 589 4. Node3 forwards Map-Register message to the Node whose Partition 590 ID matches the Resource ID. 592 5.2.2. Inter Domain Mapping Register 594 All SHDHT Nodes of a Domain SHDHT Overlay must be configured with 595 routing information pointing to local domain overlay's Border Nodes. 596 When a SHDHT Node of a domain overlay receives a Map-Register 597 message, it checks if the registered EIDs are covered by local domain 598 overlay's EID prefixes. If local domain overlay is not responsible 599 for registered EIDs, SHDHT Node who receives Map-Register message 600 will forward it directly to local domain overlay's Border Nodes. 601 Then, Border Nodes will forward the message to corresponding domain 602 overlay based on the Inter-Domain Routing Table. 604 Suppose in Fig.3, ETR2 registers mapping entry of EID 12.2.0.1 to 605 Node 6 of Domain 2. It will perform the following operations, 606 1. Node6 extracts the mapping information and finds that the 607 registered EID is 12.2.0.1. 609 2. Node6 determines that EID 12.2.0.1 is not covered by Domain 2's 610 prefix 16.0.0.0/8. 612 3. Node6 forwards the Map-Register message to BN2. 614 4. BN2 extracts mapping information and looks for Inter-Domain 615 Routing Table to find corresponding domain overlay of EID 616 12.2.0.1. 618 5. BN2 finds out Domain 1 is responsible for EID 12.2.0.1. BN2 619 forwards Map-Register message to Domain 1's Border Node ( BN1). 621 6. BN1 processes the Map-Register message based on procedures 622 introduced in Section 5.2.1. 624 5.3. Mapping Request 626 5.3.1. Intra Domain Mapping Request 628 When SHDHT Node of a Domain SHDHT Overlay receives a Map-Request 629 message, it checks if the requested EID is covered by local domain 630 overlay's EID prefixes, i.e. if the requested mapping entry is stored 631 on local domain overlay. If local domain overlay is responsible for 632 requested EID, SHDHT Node hashes the requested EID to be Resource ID 633 and forward message to the SHDHT Node who maintains the hash space 634 labeled by matched Partition ID. The Target SHDHT Node plays roles 635 of SHDHT Map Server for the required mapping entry, and will process 636 the message based on procedures introduced in Section 4.4. 638 Suppose in Fig.3, ITR1 send a Map-Request message to Node1 of Domain 639 1 to get mapping information of EID 12.2.0.1. 641 1. Node1 extract requested EID from the Map-Request message. 643 2. Node1 determines that EID 12.2.0.1 is covered by Domain 1's EID 644 prefix 12.0.0.0/8. The mapping entry is now stored on a SHDHT 645 Node of Domain 1. 647 3. Node1 hashes requested EID 12.0.0.1 to be Resource ID. 649 4. Node1 forwards Map-Register message to the Node whose Partition 650 ID matches the Resource ID. 652 5.3.2. Inter Domain Mapping Request 654 When SHDHT Node of a Domain SHDHT Overlay receives a Map-Request 655 message, it checks if the requested EID is covered by local domain 656 overlay's EID prefixes. If the requested EID entry is not stored on 657 local domain overlay, SHDHT Node directly forwards the Map-Request to 658 Border Nodes. Border Nodes of local domain overlay then forwards it 659 to corresponding domain overlay based on Inter-Domain Routing Table. 661 Suppose in Fig.3, ITR2 send a Map-Request message to Node 5 of Domain 662 2 to get mapping information of EID 12.0.0.1. 664 1. Node5 extracts requested EID from the Map-Request message. 666 2. Node5 determines that EID 12.0.0.1 is not covered by Domain 2's 667 prefix 16.0.0.0/8. 669 3. Node5 forwards the Map-Request message to BN2. 671 4. BN2 extracts requested EID and looks for Inter-Domain Routing 672 Table to find corresponding domain overlay of EID 12.0.0.1. 674 5. BN2 finds out Domain 1 is responsible for EID 12.0.0.1. BN2 675 forwards Map-Request message to Domain 1's Border Node ( BN1). 677 6. BN1 processes the Map-Request message based on procedures 678 introduced in Section 5.3.1. 680 6. Mobility Considerations 682 As specified in section 4.2 and 4.3, ITR/ETR could choose a nearest 683 LISP SHDHT Node as proxy to send control messages. 685 Based on LISP SHDHT, when roaming events occurs, the roamed LISP 686 sites or LISP MNs are no longer need to anchor pre-configured map- 687 servers. 689 7. Security Considerations 691 TBD 693 8. IANA Considerations 695 This document makes no requests to IANA. 697 9. References 699 9.1. Normative References 701 [I-D.meyer-lisp-mn] 702 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 703 Mobile Node", October 2012. 705 [I-ietf-lisp-ddt] 706 Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated 707 Database Tree", October 2012. 709 [LISP-DHT] 710 Mathy, L. and L. Iannone, "LISP-DHT: Towards a DHT to map 711 identifiers onto locators, 712 http://dl.acm.org/citation.cfm?id=1544073", December 2008. 714 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 715 "Locator/ID Separation Protocol (LISP)", January 2013. 717 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 718 Alternative Topology (LISP+ALT)", January 2013. 720 9.2. Informational References 722 [I-D.lear-lisp-nerd] 723 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 724 April 2012. 726 [RFC6833] Fuller, V. and D. Farinacci, "LISP Map Server Interface", 727 January 2013. 729 Appendix A. Acknowledgments 731 The authors with to express their thanks to Michael Hoefling for work 732 on Hash space segment of SHDHT overlay. Thanks also go to Dino 733 Farinacci and Darrel Lewis for their suggestions about database 734 structure deployment. 736 Authors' Addresses 738 Li Cheng 739 ZTE Corporation 740 R&D Building 1, Zijinghua Road No.68 741 Nanjing, Yuhuatai District 210012 742 P.R.China 744 Email: cheng.li2@zte.com.cn 746 Mo Sun 747 ZTE Corporation 748 R&D Building 1, Zijinghua Road No.68 749 Nanjing, Yuhuatai District 210012 750 P.R.China 752 Email: sun.mo@zte.com.cn