idnits 2.17.1 draft-wang-fia-namespace-01.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 (October 5, 2015) is 3124 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Information Centric Working Group J. Wang 3 Internet-Draft City University of Hong Kong 4 Intended status: Experimental S. Liu 5 Expires: April 7, 2016 C. Wetphal 6 Huawei 7 October 5, 2015 9 Namespace Resolution in Future Internet Architectures 10 draft-wang-fia-namespace-01 12 Abstract 14 This document presents the architecture and implementation of an open 15 and flexible namespace resolution mechanism to be used with Future 16 Internet Architectures. This resolution mechanism allows the 17 resolution of different network entities and can be adapted to the 18 needs of network, application and service providers alike. 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 April 7, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 50 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3 60 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Generic Namespace Management System . . . . . . . . . . . 5 65 5.2. Definable Routing . . . . . . . . . . . . . . . . . . . . 6 66 5.3. Decoupling Name Resolution from the Application Service 67 Provider . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.4. Compatibility Issues . . . . . . . . . . . . . . . . . . 6 69 5.5. Security Requirements . . . . . . . . . . . . . . . . . . 7 70 6. Components of a Multi-namespace Management System . . . . . . 7 71 7. System Architecture . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 8 73 7.2. Switch . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7.2.1. Namespace Management Module . . . . . . . . . . . . . 8 75 7.2.2. Namespace Access Control Module . . . . . . . . . . . 8 76 7.2.3. Session Control Module at the edge switch . . . . . . 8 77 7.2.4. Forwarding Plane . . . . . . . . . . . . . . . . . . 9 78 8. Implementation . . . . . . . . . . . . . . . . . . . . . . . 9 79 9. Example of Multiple Namespaces . . . . . . . . . . . . . . . 10 80 9.1. Deploy ICN instances on Multiple-namespace Network . . . 10 81 9.2. Supporting Manifests . . . . . . . . . . . . . . . . . . 11 82 10. The procedure of communication over Heterogeneous Wireless 83 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 89 14.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 A number of future network architectures have been proposed to 95 address existing problems of the current Internet, denoted as future 96 Internet Architectures (FIAs). The naming and addressing of network 97 entities including content, users, devices, services etc. are an 98 common to all FIAs. Thus, no matter toward which FIA the Internet 99 will evolve, there will be a need an open namespace management and 101 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 103 resolution system to provide flexible definition of network entities, 104 optimal name resolution and management, extra mobility consideration 105 and improvement of security issues. 107 Such a system will: 109 Allow multiple namespaces to co-exist; 111 Enable dynamic name resolution among multiple namespaces through 112 policies; 114 And facilitate interpolation between networked systems with 115 different namespaces. 117 This draft presents the architecture and implementation of such an 118 open namespace resolution system. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Definitions and Abbreviations 128 3.1. Definitions 130 This document uses the following definitions, that are mostly 131 inspired from from [RFC5052], [RFC6363]. 133 Namespace: 135 Resolution: 137 To Be Completed 139 3.2. Abbreviations 141 This document uses the following abbreviations: 143 ASP: Application Service Provider 145 CCN: Content-Centric Network 147 CS: Content Store 149 DPI: Deep Packet Inspection 151 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 153 FIA: Future Internet Architecture 155 FIB: Forwarding Information Base 157 GUID: Globally Unique Identifier 159 ICN: Information Centric Network 161 IFNS: Interface based Naming System 163 MNSS: Multi-Name Service System 165 NDN: Named Data Network 167 NA: Network Address 169 NSC: Name Service Component 171 PIT: Pending Interest Table 173 PSIRP: Publish Subscribe Internet Routing Paradigm 175 QoS: Quality of Service 177 RID: Routing Identifier 179 SID: Static Identifier 181 SDN: Software Defined Network 183 URL: Universal Resource Locator 185 VID: Virtual Identifier 187 Other to be provided 189 4. Background 191 In the current Internet, DNS servers take charge of mapping URL 192 (name) to the actual network address of a target resource before 193 initialting the communication. This name resolution policy (i.e., 194 from domain name to IP address) is usually static. 196 In a Named Data Network (NDN) [ndn], data is requested and located by 197 its name. A NDN uses a recursive machanisms to resolve and forward 198 from one namespace (named objectives) to another namespace. 200 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 202 The Mobility First architecture [mobility] uses a Globally Unique 203 Identifier (GUID) and a network address (NA) as the namespace to 204 identify network entities. The length of the GUID is fixed to 205 160bits and the name resolution is also fixed and consists of mapping 206 the GUID to the actual network address (NA). A switch will forward 207 the packet based on the NA. 209 The Independent Virtual Id Routing [virtualID] or VIRO decouples 210 naming from routing via Virtual ID (VID) and allows different 211 identifiers such as IPv4/IPv6, DNS names or some other names, to co- 212 exist within the namespace. However, all of these namespaces will be 213 mapped to the VID of the particular network entity. It only allows 214 one level name resolution, e.g., from one name to VID, and flexible 215 name resolution driven by policies among multiple namespaces is not 216 accommodated. 218 The Interface based Naming System [minami] or IFNS also allows 219 multiple namespaces to co-exist in the architecture. A Multi-Name 220 Service System (MNSS) will have different Name Service Components 221 (NSC). IFNS is just one of NSC in this Multi-Name Service System. 222 Each NSC has its own name resolution strategy and cannot map from one 223 NSC to another one. 225 What can be seen from the above it that each FIA has defined it's own 226 mechanims. We propose that namespace resolution not only should have 227 universality to adapt to general usage scenarios, but also should be 228 flexible enough to meet some new requirements as the Internet 229 evolves. A namespace management system should only be defined by the 230 properties of network entities. Furthermore, a name resolution 231 strategy should also provide name resolution from any source 232 namespace to any destination namespace. 234 5. Requirements 236 5.1. Generic Namespace Management System 238 As was seen above, for curretly existing network architectures, the 239 namespace and resolution policy is fixed. As such a fixed name 240 resolution policy cannot facilitate the deployment of new services. 241 For example, a network service provider may do Deep Packet Inspection 242 (DPI) for some flows. To enable this, a name resolution policy could 243 specify which certain flows satisfied the pre-set conditions to be 244 resolved to a middlebox for DPI while other flows will be resolved to 245 next hop router for forwarding. 247 In the more and more diverse Internet, a namespace management system 248 should provide unified APIs to define namespaces and resolution 249 policies flexibly and be applicable to network, services and 251 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 253 application providers alike. Thus many types of network 254 architectures can be supported on the same physical network. In 255 addition, security features are necessary to ensure that a provider 256 can only access its own namespace and the namespace can only be 257 accessed by itself. Only when a source namespace allows resolution 258 to a target namespace and, at the same time, the target namespace 259 allows resolution from the source namespace, then the resolution 260 between the source and the target namespaces can occur. It implies 261 that resolving from namespace A to namespace B, then from namespace B 262 to namespace C may not be equivalent to resolving from namespace A to 263 namespace C. The mechanism decribed in the rest of this document 264 allows this. 266 5.2. Definable Routing 268 Controlling the routing and forwarding procedure based on some QoS 269 and security consideration is a requirement of both service providers 270 (to keep the traffic within their management domain) and of 271 application providers (to control the quality of service). Hence, in 272 a namespace management system, flexible name resolution policy should 273 facilitate the implementation of any particular routing scheme. 275 5.3. Decoupling Name Resolution from the Application Service Provider 277 In existing solutions, ASPs usually handle their own name resolution. 278 For example, in Skype, name resolution is conducted by globally 279 synchronized super nodes. But to maintain a namespace management 280 system by application results in infrastructure costs when deploying 281 application services. In consequence, and becuase the resolution 282 cold be done on a remote network, the resolution delay may be higher 283 than when done more locall by the network service provider. 285 With our generic name resolution system, the resolution process can 286 be moved from the application layer to the network layer with the 287 authentication of ASPs. To achieve this as as mentioned above, there 288 needs to be appropriate security for the namespace management system 289 to ensure that an ASP can only define and access its own namespace, 290 that there exisit a trust agreement betwoeen the ASP and the network 291 service provider and that the resolution policy is mutually agreed by 292 both source namespace owner and target namespace owner. 294 5.4. Compatibility Issues 296 In order to support long-term evolution, different networks/protocols 297 must be deployed in a unified framework. Thus, a generic namespace 298 management system will provide a reasonable way to realize both 299 backward and forward compatibility. On the application layer, 300 because of the decoupling of resolution service from ASPs, the 302 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 304 relationship among applications can be defined more flexibly with 305 more interoperability. 307 5.5. Security Requirements 309 The following two main features are added to the namespace solution 310 to address the security concerns related to address resolution. 312 1) The dynamic security strategy is self-contained in the 313 namespace definition. The service provider will be able to deploy 314 different security strategies for specific services or 315 applications in configuring its namespace. The security strategy 316 can be flexibly changed by modifying the namespace. 318 2) The physical address is hidden. The namespace and name 319 resolution rule are both defined by the service provider, and this 320 whole process is hidden to other traffic. Furthermore, the 321 control plane will do the authentication verification to guarantee 322 the namespace cannot be left without proper authority. 324 6. Components of a Multi-namespace Management System 326 To provide a namespace management system with the aforementioned 327 features, we define three main components: 329 1) A Namespace Management Component that keeps namespace records. 330 Different service providers can flexibly define their own 331 namespaces based on different objectives and requirements. For 332 instance, a network service provider can define a particular 333 network by deploying the network entity namespace. In terms of 334 application service providers, they can use the namespaces to 335 describe the specific forwarding and security strategy of their 336 application. 338 2) A Resolution Engine (forwarding plane) which processes filter 339 and action setting for namespaces and entities respectively. In 340 order to get the optimal name resolution and routing scheme, a 341 service provider should define a series of appropriate forwarding 342 policies among particular namespaces. Another other type of 343 policy is provided by filters to define the access control for 344 particular namespace. It is allowed that an instruction set 345 contains multiple actions. 347 A Control Plane which contains the access control module to 348 guarantee that the configuration process is secure and reliable. 349 It provides configuration APIs including: namespace management 350 (register, update, delete), policy setting (filter and action) and 351 system control. The control plane is provided by middleware, 353 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 355 which makes it possible that all entities in the Internet (e.g., 356 network devices, user, service, data object) can manage their 357 namespaces when give appropriate authority. 359 7. System Architecture 361 7.1. Control Plane 363 The Control Plane is a middleware between applications/services and 364 the physical infrastructure. The configuration messages will be 365 verified by the access control module in the control plane. This 366 ensures there is valid authority for deploying the configuration for 367 each namespace. Verified messages will be transmitted to the 368 particular switches maintaining the target namespaces. 370 7.2. Switch 372 7.2.1. Namespace Management Module 374 The Namespace Management Module provides two main functionalities: 375 (i) it maintains the records of all namespaces and (ii) it interprets 376 and executes policies (filters and actions) for namespace and 377 entities (Resolution Engine). 379 7.2.2. Namespace Access Control Module 381 Any entity (e.g., network devices, user, service, data object) can 382 create, update, or delete namespaces and resolution policies by 383 configuration messages. These messages contain the namespace 384 settings (or changes), the policy setting (or changes) and the 385 process flag (create, update or delete). A configuration message is 386 firstly sent to the control plane. Then the control plane processes 387 the message to find the target switches. Finally, the control plane 388 pushes the configuration message with its signature to switches. In 389 the switch, the Access Control Module will verify whether the 390 configuration message is from the controller with authority to manage 391 this particular namespace. 393 7.2.3. Session Control Module at the edge switch 395 The Session Control Module is designed for managing the sessions and 396 providing QoS in the edge switch. A session describes a temporary 397 resolution, which avoids searching and interpreting among namespaces 398 repeatedly. It highly improves the efficiency of data routing. 399 Generally, every sessionxxx activity will be managed by its own life- 400 cycle or providerxxx instruction. Sessions can be managed 401 individually to achieve some QoS goals. The xxxirst packetxxx 402 inference of OpenFlow and SDN can be used to trigger a new session. 404 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 406 For OpenFlow, the first packet of a stream (after the DNS resolution) 407 may trigger a control action. The first packet exchange therefore 408 takes on a dual role: data exchange and control trigger. Having an 409 explicit initial exchange that informs the network of the data 410 transfer provodes a clean mechanism for separating the data delivery 411 from the control plane. 413 7.2.4. Forwarding Plane 415 The Forwarding Plane handles packet forwarding based on the 416 resolution engine integrated in the namespace management module. It 417 forwards packets to particular interfaces according to records in the 418 interface mapping table. 420 8. Implementation 422 The recommended namespace format is presented in the figure below. 423 It can use the unity paradigm or a self-defined namespace format. 425 +-----------------------------------------------------+ 426 | Namespace: | 427 |-----------------------------------------------------| 428 | Policy: | | 429 |----------------+------------------------------------| 430 | Tag: | | 431 |----------------+------------------------------------| 432 | Entity Name | Value | Action | State | ... | 433 |----------------+---------+----------+---------+-----| 434 | | | | | | 435 |----------------+---------+----------+---------+-----| 436 | | | | | | 437 |----------------+---------+----------+---------+-----| 438 | | | | | | 439 +-----------------------------------------------------+ 441 Figure 1: Namespace format 443 The different elements of the format are defined as follows: 445 Policy: the access control filters of the namespace compose the 446 policy. Generally, regular expressions are supported. But policy 447 could also be programmed by script language to describe 448 complicated filters and actions like moving to another namespace. 450 Tag: the tag of a namespace indicates its characteristics. For 451 example, if this is a service namespace, the tag could be the 452 servicexxx name. 454 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 456 Entity Name: the name of the specific entity. 458 Value: the value is the type of address or of any other network 459 identity. For example, the IP address, the MAC address or some 460 new identity that is defined by the provider. 462 Action: The action field indicates how the entities will be 463 matched and what will be done after the matching. A particular 464 namespace could have multiple actions to execute. For instance, 465 SENDTO VALUE means forward to the network address recorded in the 466 value field. GOTO means the packet will be send to another 467 namespace. Furthermore, some filter can be added to limit the 468 action. 470 State: The state of this entity. For example state could show 471 that whether a device is online or offline. 473 9. Example of Multiple Namespaces 475 9.1. Deploy ICN instances on Multiple-namespace Network 477 Existing ICNs all have their own namespaces and mechanisms for 478 resolution. Hence, we have deployed an ICN instance on our system. 480 For instance, in NDN [jacobson], Forwarding Information Base (FIB), 481 Content Store (CS), and Pending Interest Table (PIT) can be 482 implemented as three namespaces in the proposed system where FIB is a 483 namespace of destinations for Interests, CS is a namespace of cached 484 content, and PIT is a namespace of sources for unsatisfied Interests. 486 The Forwarding Engine described in CCN [snamp] can also be 487 implemented in our system. The logic of original CCN Forwarding 488 Engine can be defined by policies of namespaces. For instance, when 489 an Interest packet comes in, the our forwarding engine will check if 490 there is match in the namespace of the CS. If not, the forwarding 491 engine will check the namespace of PIT (according to the action 492 defined by the policy of namespace of CS). If no matching entity can 493 be found in PIT again, the forwarding engine will check the namespace 494 of FIB (according to the action defined by policy of namespace of 495 PIT). We note that "prefix longest matching" can be defined by the 496 filter of the policy of the entity in the namespace. Finally, 497 according to the policy (action of forwarding and ID of target 498 interface), the switch forwards this Interest packet to the 499 corresponding interface specified by the matched entity. 501 Besides NDN, other ICNs can be implemented by the proposed system. 502 For example, PSIRP [psirp], is also supported by multiple namespaces. 503 In PSIRP, users (subscribers/publishers) subscribe/publish content to 505 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 507 rendezvous nodes. Rendezvous nodes actually can be implemented on 508 switches with the namespaces of scope and content. In PSIRP, 509 forwarding solely depends on information identifiers, i.e. RIds and 510 SIds, thus MPLS-like label switching protocols are used. These 511 identifiers can be processed by the filters defined by policies of 512 corresponding namespaces and forwarding engine forwards packet by 513 these identifiers with policies of namespaces. 515 As a generic solution, our system supports implementation different 516 ICNs, which makes it possible to deploy all these different ICN 517 instances on the same infrastructure. An extra benefit is the 518 possibility of fusioning ICNs. For instance, we can deploy two ICN 519 instances, CCN and PSIRP, on the same infrastructure. In the switch, 520 we can set some policies to define the translation between the 521 namespaces of CCN and PSIRP. A CCN client requests content by 522 sending an Interest packet. When it fails to find a matched entry in 523 namespace of CS (defined by CCN), we may let it search in namespace 524 of published content (defined by PSIRP), by the policies (action of 525 xxxotoxxx and packet modifying to adapt PSIRP) of namespaces in CS. 526 Thus, a publisher of PSIRP may provide the content to a CCN client. 528 9.2. Supporting Manifests 530 The manifest is a data object containing meta-data about another 531 object. Therefore, it can be given a name in CCN and the CCN 532 transaction could start in a corresponding manner by requesting this 533 object. There are proposals and discussion to add manifests to CCN. 534 These manifests usually point to hashes of a series of data objects 535 in order to speed up the forwarding and security checks. Manifests 536 could also point to other names for the same object (like the name of 537 an object pinned at a specific location). They could be extended to 538 support other useful network meta-data. 540 In a generalized multiple namespace management system, a user can 541 issue a request for a manifest data object which consists of a set of 542 data objects from different ASPs or different ICN instances. The 543 name resolution for the data objects contained in the manifest can be 544 done individually in different namespaces according to the name 545 resolution policy specified in the meta data of the manifest. This 546 will allow users to compose and fetch data/service from different 547 ASPs and/or ICN instances in an easy way. 549 10. The procedure of communication over Heterogeneous Wireless Network 551 In the current heterogeneous wireless network, communication between 552 two entities which employ different network protocols needs to be 553 bridged by IP. That means the protocol translation is performed 554 twice, which leads to extra transmission overhead (due to redundant 556 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 558 TCP/IP packet header) and operations overhead (brought by format 559 conversion between Ethernet frame in the link layer and data packet 560 in the network layer). To solve the problem mentioned above, we 561 designed a new namespace management system to make the communication 562 more flexible and efficient. 564 +-----------+ +-----------+ 565 |User Device| |User Device| 566 +-----------+ +-----------+ 567 \ / 568 \ Wi-Fi ZigBee / 569 \\ / \ // 570 \| |/ 571 |------------IP------------| 572 |\ /| 573 AP\ / AP 574 \ / 575 \ / 576 IP IP 577 \ / 578 \ / 579 \ / 580 \ / 581 \ \ / / 582 \ | / 583 BlueTooth | 584 AP --- +-----------+ 585 |User Device| 586 +-----------+ 588 Figure 2: Demo Scenario 590 In the sensor network scenario shown in the Figure 1, three different 591 protocols, i.e., Wi-Fi, ZigBee, and Bluetooth, are adopted by 592 different devices. Instead of encapsulating the original packet with 593 different protocols into a TCP or UDP packet and routing packets 594 based on IP, Our proposed namespace management system can be used to 595 support protocol and packet translation by extending the Ethernet 596 frame. The format of the designed new frame is shown in the figure 597 2. 599 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 601 +----------------------------------------------------------------------+ 602 |Destination |Source | | | | | 603 |Mac address |MAC address |Protocol Type | SrcName | DstName | Payload | 604 |-------------------------+----------------------------------+---------| 605 | MAC Header | Self-defined Namespace | Data | 606 +----------------------------------------------------------------------+ 608 Figure 3: Frame Format 610 In this frame, MAC Header field records the source and destination 611 MAC addresses for link layer transmission. SrcName, DstName and 612 Protocol Type in the Data field are used for routing purposes where 613 the name resolution will be used by our proposed multiple namespace 614 management system. 616 Upon receiving the frame, the router will do name resolution based on 617 the SrcName and DstName to find out where this frame should be 618 forwarded to and will change the DstMACAdd to the Mac address of a 619 physical device's specific port for next hop. When the target device 620 receives the frame, it will translate the frame to the target format 621 according to the protocol stored in the Protocol Type property. 622 Figure 3 presents an example of the translation between Bluetooth and 623 WiFi. 625 +---------------------------------------------------------------------+ 626 | | | 627 | +-----------------------------------------------------------+ | 628 | | Access Code | Bluetooth Header | Data | | 629 | +-----------------------------------------------------------+ | 630 | | | 631 | +-----------------------------------------------------------+ | 632 | | Ethernet MAC Header | Protocol |Self-defined| | | 633 | ==> |(SrcMAC,DstMAC address)| Type | Namespace | Data | | 634 | +-----------------------------------------------------------+ | 635 | | | 636 | +-----------------------------------------------------------+ | 637 | | Wi-Fi MAC Header | | | 638 | ==> |(Frame Control, SrcMAC, DstMAC, RouterMAC address)| Data | | 639 | +-----------------------------------------------------------+ | 640 | | | 641 | Header | Payload | 642 +---------------------------------------------------------------------+ 644 Figure 4: an example of the translation between Bluetooth and Wi-Fi 646 With the application of the new namespace management system, the 647 whole procedure is expected to be accomplished at the link layer 649 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 651 without switching to the network layer. Figure 4 indicates the 652 results of the comparison of the throughput rates between the 653 solution using multiple namespace management system and UDP under 654 different situations (Throughput: Packets/sec, Packet Size: Bytes). 656 +--------------------------------------------------------------------+ 657 | | One Threads | Two Threads | Three Threads | 658 |--------------------------------------------------------------------| 659 | Packet | | | | | | | | | | 660 | Size | 10 | 100 |1000 | 10 | 100 |1000 | 10 | 100 |1000 | 661 |--------------------------------------------------------------------| 662 | Our System | | | | | | | | | | 663 | Throughput |50120|47875|38533|94231|90652|72153|136246|126053|98152| 664 |--------------------------------------------------------------------| 665 | UDP | | | | | | | | | | 666 | Throughput |36983|36720|33023|63034|60992|60238|53221 |52965 |53393| 667 |--------------------------------------------------------------------| 668 | Optimizing | | | | | | | | | | 669 | Percentage | 35% | 30% | 16% | 49% | 48% | 19% | 156% | 137% | 83% | 670 +--------------------------------------------------------------------+ 672 Figure 5: Comparison of the throughput capacity between our system 673 and UDP 675 This demo shows that multiple namespace management system can enable 676 flexible protocol translation by self-defined name resolution. 678 11. Acknowledgements 680 The authors would like to acknowledge Dr. Marie-Jose Montpetit for 681 supporting editing of this draft. 683 12. IANA Considerations 685 This document includes no request to IANA at this point. 687 13. Security Considerations 689 To be defined when appropriate, see RFC 3552 [RFC3552]. 691 14. References 693 14.1. Normative References 694 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", BCP 14, RFC 2119, 698 DOI 10.17487/RFC2119, March 1997, 699 . 701 14.2. Informative References 703 [jacobson] 704 Jacobson, V., Smetters, D., Thornton, J., and et. al, 705 "Networking named content.", Proceedings of the 5th 706 international ACM conference on Emerging Networking 707 Experiments and Technologies. , 2009. 709 [minami] Minami, M., Morikawa, H., and T. Ayoma, "The design of 710 naming-based service composition system for ubiquitous 711 computing applications", SAINT Workshop at the 2004 IEEE 712 International Symposium on Applications and the Internet , 713 2004. 715 [mobility] 716 Seskar, I., Nagajara, K., Nelson, S., and et. al, 717 "Mobilityfirst future internet architecture project.", 718 Proceedings of the ACM 7th Asian Internet Engineering 719 Conference. , 2011. 721 [ndn] Zhang, L., Estrin, D., Burke, J., and et. al, "Named data 722 networking (NDN) project.", Relatxxxrio Txxxcnico NDN- 723 0001, Xerox Palo Alto Research Center-PARC , 2010. 725 [psirp] Trossen, D., "PURSUIT reference.", Some conference - TBD , 726 XXX. 728 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 729 Text on Security Considerations", BCP 72, RFC 3552, 730 DOI 10.17487/RFC3552, July 2003, 731 . 733 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 734 Correction (FEC) Building Block", RFC 5052, 735 DOI 10.17487/RFC5052, August 2007, 736 . 738 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 739 Correction (FEC) Framework", RFC 6363, 740 DOI 10.17487/RFC6363, October 2011, 741 . 743 Internet-DrafNamespace Resolution in Future Internet Archit October 2015 745 [snamp] Afanasyev, A., "SNAMP: Secure Namespace Mapping to Scale 746 NDN Forwarding.", Proceedings of IEEE Global Internet 747 Symposium. , 2015. 749 [virtualID] 750 Lu, G., Jain, S., Chen, S., and et. al, "Virtual id 751 routing: a scalable routing framework with support for 752 mobility and routing efficiency.", Proceedings of the 3rd 753 International ACM Workshop on Mobility in the Evolving 754 Internet Architecture. , 2008. 756 Authors' Addresses 758 Jianping Wang 759 City University of Hong Kong 761 Email: "jianwang@cityu.edu.hk 763 Shusheng Liu 764 Huawei 766 Email: liushucheng@huawei.com 768 Cedric Westphal 769 Huawei 771 Email: Cedric.Westphal@huawei.com