idnits 2.17.1 draft-hong-icnrg-ccnx-nrs-02.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 seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 345, but not defined == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-06 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-06 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group J. Hong 3 Internet-Draft T. You 4 Intended status: Informational Y-G. Hong 5 Expires: January 3, 2019 ETRI 6 July 2, 2018 8 CCNx Extension for Name Resolution Service 9 draft-hong-icnrg-ccnx-nrs-02 11 Abstract 13 This document presents the CCNx extension for Name Resolution Service 14 (NRS). It describes TLV-based CCNx messages for NRS and modification 15 of CCNx forwarder where the messages for NRS are working. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 3, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 53 3. Mappig System for Name Resolution Service in CCN . . . . . . 3 54 4. CCNx Extension for Name Resolution . . . . . . . . . . . . . 4 55 4.1. Interest . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Content Object . . . . . . . . . . . . . . . . . . . . . 5 57 4.3. Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. CCNx Extension for Name Management . . . . . . . . . . . . . 6 59 5.1. Interest . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.2. Content Object . . . . . . . . . . . . . . . . . . . . . 7 61 5.3. Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 In Information Centric Networking (ICN)[RFC7927], the name resolution 73 is defined as the first step of ICN routing along with content 74 discovery and delivery, which translates a content name to locator(s) 75 of providers/sources that can provide the content. However, the name 76 resolution step can be omitted in the hierarchical name based 77 routing. 79 NDN [NDN] and CCN [CCN] are representative projects of ICN which use 80 the hierarchical name based routing. Nevertheless, in [Afanasyev], 81 in order to address the routing scalability problem in NDN's DFZ, a 82 distributed mapping system called NDNS was designed, which maintains 83 and lookups the mapping information from a name to its globally 84 routed prefixes. Here, NDNS is a kind of Name Resolution Service 85 (NRS) in NDN. 87 Similarly, CCN also has a challlenge to address the routing 88 scalability problem in CCN's DFZ even though CCN uses the 89 hierarchical name based routing. Thus, NRS can be utilized in CCN 90 for the scalable name based routing as well as the efficient mobility 91 support. 93 This document presents the design of NRS-Mapping System (NRS-MS) 94 which is a system that provides the name resolution service in CCN 95 and its implementation by extending CCNx. It also describes TLV- 96 based CCNx messages for NRS and modification of CCNx forwarder where 97 the messages for NRS are working. 99 2. Conventions and Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 This document uses the terminology of [CCNxSemantics] and 106 [CCNxMessages] for CCNx entities. 108 The following terms are used in this document and defined as follows: 110 o Mapping Server (MS) : stores and maintains the actual mapping 111 table which keeps the bindings of name to some information that is 112 used for forwarding Interest. MS is a role of NRS resolver and 113 all NRS messages are processed though the MS. In other words, CCN 114 nodes such as consumer, provider communicate with only MS to get 115 the name resolution service. Thus we design the MS using C CN 116 protocol assuming that the NRS is served at the content router 117 (CR) and each CR knows its default MS. 119 o Name List Server (NLS) : is constructed by the DNS-like tree 120 according to the name hierarchy. NLS is only used to find the 121 corresponding MS which stores the binding information of the 122 requested name since CR sends the NRS lookup request to its 123 default MS whether it has the binding information of the requested 124 name or not. MS is located at the second level NLS and we have 125 utilized the IP for the communications between MSs and NLSs. 127 3. Mappig System for Name Resolution Service in CCN 129 This document presents the new implementation of NRS-MS functions 130 based on extension of CCNx to show usefulness of NRS in CCN. We 131 design a simple scenario to maximize NRS usefulness and to understand 132 NRS functionalities easily. 134 o Scenario : Similar with CDN approach, multiple media servers 135 containing popular contents can be deployed in different areas, 136 but all of media data in replica servers (RSs) must have 137 equivalent name to keep data integrity as a single publisher's 138 authority. In order to take an advantage from the replica 139 servers, NRS can be utilized to lookup the physical locations of 140 the rplica servers. The nearest replica server can be chosen from 141 the information resolved by NRS. 143 o Design choices : We design and implement a new entity named a 144 Mapping Server (MS) by extension of content router (CR). The MS 145 can be deployed by a single network provider. Moreover, we assume 146 that an ICN edge domain is required to have at least one MS. MS 147 maintains mapping information between name and another name and 148 processes a lookup request and its response. Consumer is not 149 changed. The first hop content router (CR1) like a first hop 150 router should have a communication channel toward a mapping 151 server. We design new messages to implement NRS functionalities 152 just by following the CCNx messages in TLV format [CCNxMessages] 153 by extension of optional fields. 155 +-----+ 156 | MS | 157 +-----+ 158 | 159 | 160 +----------+ +-----+ +-----+ +-----+ 161 | Consumer |---| CR1 |---| CR2 |---| RS1 | 162 +----------+ +-----+ +-----+ +-----+ 163 \ 164 \ 165 +-----+ +-----+ 166 | CR3 |---| RS2 | 167 +-----+ +-----+ 169 Figure 1: Replica server scenario 171 4. CCNx Extension for Name Resolution 173 We have implemented the NRS for CCN based on CCNx. This means that 174 the name is resolved by Interest and Content Object packets defined 175 in CCNx. We define two types of Interest packets for NRS: Interest 176 for registration (I-reg) and Interest for lookup (I-get) which are 177 sent from a proper CR to its default MS for name registration and 178 lookup, respectively. We also define two types of Content Object 179 (CO) packets: CO-reg and CO-get which are corresponding to the I-reg 180 and I-get, respectively. We have utilized the nested header format 181 used in CCNx [CCNxMessages] to enable the newly defined packets. 183 4.1. Interest 185 I-get is an Interest packet requesting the name resolution. It 186 includes two names, MS name and a requested name as shown in 187 Figure 2. MS name is used for forwarding I-get to the correspoding 188 MS. On the other hands, the requested name is used for updating PIT. 190 At each CR, I-get is sent to its defalut MS when FIB does not have 191 information for the requested name, where each CR is aware of its 192 default MS's name so it knows where to send I-get. 194 1 2 3 195 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 196 +---------------+---------------+---------------+---------------+ 197 | Version | PT_INTEREST | PacketLength | 198 +---------------+---------------+---------------+---------------+ 199 | HopLimit | Reserved | Flags | HeaderLength | 200 +---------------+---------------+---------------+---------------+ 201 | MessageType, T_NAME | MessageLength | 202 +---------------+---------------+---------------+---------------+ 203 | Name TLV (MS Name) | 204 +---------------+---------------+---------------+---------------+ 205 | MessageType, T_GET | MessageLength | 206 +---------------+---------------+---------------+---------------+ 207 | Name TLV (requested Name) | 208 +---------------+---------------+---------------+---------------+ 210 Figure 2: Interest packet format for name resolution request 212 4.2. Content Object 214 1 2 3 215 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 216 +---------------+---------------+---------------+---------------+ 217 | Version | PT_CONTENT | PacketLength | 218 +---------------+---------------+---------------+---------------+ 219 | Reserved | Flags | HeaderLength | 220 +---------------+---------------+---------------+---------------+ 221 | MessageType, T_NAME | MessageLength | 222 +---------------+---------------+---------------+---------------+ 223 | Name TLV (requested Name) | 224 +---------------+---------------+---------------+---------------+ 225 | MessageType, T_PAYLDTYPE_GET | MessageLength | 226 +---------------+---------------+---------------+---------------+ 227 | Name TLV (acquired Name) | 228 +---------------+---------------+---------------+---------------+ 230 Figure 3: Content Object packet format for name resolution request 232 CO-get is a Content Object which is a respoding packet to I-get. So, 233 it is used to forward the resolved name. As Figure 3 shows, CO-get 234 includes two names, requested name and acquired name. CO-get is 235 forwarded by the requested name according to its PIT record toward CR 236 which initiated the corresponding I-get. replying to the name 237 resolution request, I-get. 239 4.3. Forwarder 241 Forwarder has been modified to make the I-get and CO-get working 242 properly. Forwarder initicates I-get when there is no information 243 for the requested name in FIB. In general, Forwarder drops Interest 244 when no information in FIB. However, we made a chance to lookup for 245 another name instead of dropping it right away. 247 It is assuemd that each forwarder knows the name of its defalut MS. 248 So, forwarder can use the MS name when it initiates I-get. MS name 249 is only used for forwading toward MS but PIT is updated by the 250 requested name which is the second name included in I-get. 251 Therefore, forwarder uses only the requested name in CO-get to 252 forward back to where I-get is initiated. 254 5. CCNx Extension for Name Management 256 In order to serve the NRS lookup, the name of data object has to be 257 registered in a mapping server (MS)and its binding information also 258 has to be stored in a MS. Thus, we define 4 different types of the 259 registering name: reg, add, del, and dereg. 261 o I-reg/CO-reg : registration of new name 263 o I-add/CO-add : addition of the binding name (A registered name can 264 have more than one binding name.) 266 o I-del/CO-del : deletion of the binding name 268 o I-dereg/CO-dereg : deregisteration of name 270 5.1. Interest 272 I-reg is an Interest packet to register a name and store the binding 273 information in a corresponding MS. As figure 4 shows, I-reg includes 274 three names: MS name, registering name and binding name. MS name is 275 used for forwarding I-reg toward MS and registering name is used for 276 updating PIT. Similarly to I-get, I-reg is sent to its defalut MS. 278 1 2 3 279 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 280 +---------------+---------------+---------------+---------------+ 281 | Version | PT_INTEREST | PacketLength | 282 +---------------+---------------+---------------+---------------+ 283 | HopLimit | Reserved | Flags | HeaderLength | 284 +---------------+---------------+---------------+---------------+ 285 | MessageType, T_NAME | MessageLength | 286 +---------------+---------------+---------------+---------------+ 287 | Name TLV (MS Name) | 288 +---------------+---------------+---------------+---------------+ 289 | MessageType, T_REG | MessageLength | 290 +---------------+---------------+---------------+---------------+ 291 | Name TLV (registering Name) | 292 +---------------+---------------+---------------+---------------+ 293 | MessageType, T_VALUE | MessageLength | 294 +---------------+---------------+---------------+---------------+ 295 | Name TLV (binging Name) | 296 +---------------+---------------+---------------+---------------+ 298 Figure 4: Interest packet format for name registration 300 5.2. Content Object 302 1 2 3 303 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 304 +---------------+---------------+---------------+---------------+ 305 | Version | PT_CONTENT | PacketLength | 306 +---------------+---------------+---------------+---------------+ 307 | Reserved | Flags | HeaderLength | 308 +---------------+---------------+---------------+---------------+ 309 | MessageType, T_NAME | MessageLength | 310 +---------------+---------------+---------------+---------------+ 311 | Name TLV (registering Name) | 312 +---------------+---------------+---------------+---------------+ 313 | MessageType, T_PAYLDTYPE_REG | MessageLength | 314 +---------------+---------------+---------------+---------------+ 315 | Name TLV (binding Name) | 316 +---------------+---------------+---------------+---------------+ 318 Figure 5: Content Object packet format for name registration 320 CO-reg is a Content Object which is a respoding packet to I-reg. As 321 Figure 5 shows, CO-reg includes two names, registering name and 322 binding name. CO-reg is forwarded by the registering name according 323 to its PIT record toward CR which initiated the corresponding I-reg. 325 5.3. Forwarder 327 Forwarder has been modified to make the I-reg and CO-reg working 328 properly. When new name is registered to MS, forwarder initiates and 329 sends I-reg toward its default MS. MS name is only used for 330 forwading I-reg but PIT is updated by the registering name which is 331 the second name included in I-reg. Therefore, forwarder uses only 332 the registering name in CO-reg to forward back to where I-reg is 333 initiated. 335 6. IANA Considerations 337 There are no IANA considerations related to this document. 339 7. Security Considerations 341 [TBD] 343 8. Acknowledgements 345 [TBD] 347 9. References 349 9.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 357 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 358 "Information-Centric Networking (ICN) Research 359 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 360 . 362 9.2. Informative References 364 [NDN] "NSF Named Data Networking project.", 365 http://www.named-data.net . 367 [CCN] "Content Centric Networking project.", 368 https://wiki.fd.io/view/Cicn . 370 [Afanasyev] 371 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 372 Scale NDN Forwarding", IEEE Global Internet Symposium , 373 April 2015. 375 [CCNxSemantics] 376 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 377 draft-irtf-icnrg-ccnxsemantics-06 , October 2017. 379 [CCNxMessages] 380 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 381 Format", draft-irtf-icnrg-ccnxmessages-06 , October 2017. 383 Authors' Addresses 385 Jungha Hong 386 ETRI 387 218 Gajeong-ro, Yuseung-Gu 388 Daejeon 34129 389 Korea 391 Phone: +82 42 860 0926 392 Email: jhong@etri.re.kr 394 Tae-Wan You 395 ETRI 396 218 Gajeong-ro, Yuseung-Gu 397 Daejeon 34129 398 Korea 400 Phone: +82 42 860 0642 401 Email: twyou@etri.re.kr 403 Yong-Geun Hong 404 ETRI 405 218 Gajeong-ro, Yuseung-Gu 406 Daejeon 34129 407 Korea 409 Phone: +82 42 860 6557 410 Email: yghong@etri.re.kr