Information Centric Working Group J. Wang Internet-Draft City University of Hong Kong Intended status: Experimental S. Liu Expires: April 7, 2016 C. Wetphal Huawei October 5, 2015 Namespace Resolution in Future Internet Architectures draft-wang-fia-namespace-01 Abstract This document presents the architecture and implementation of an open and flexible namespace resolution mechanism to be used with Future Internet Architectures. This resolution mechanism allows the resolution of different network entities and can be adapted to the needs of network, application and service providers alike. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Wang, et al. Expires April 7, 2016 [Page 1] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Definitions and Abbreviations . . . . . . . . . . . . . . . . 3 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Generic Namespace Management System . . . . . . . . . . . 5 5.2. Definable Routing . . . . . . . . . . . . . . . . . . . . 6 5.3. Decoupling Name Resolution from the Application Service Provider . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. Compatibility Issues . . . . . . . . . . . . . . . . . . 6 5.5. Security Requirements . . . . . . . . . . . . . . . . . . 7 6. Components of a Multi-namespace Management System . . . . . . 7 7. System Architecture . . . . . . . . . . . . . . . . . . . . . 8 7.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Switch . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2.1. Namespace Management Module . . . . . . . . . . . . . 8 7.2.2. Namespace Access Control Module . . . . . . . . . . . 8 7.2.3. Session Control Module at the edge switch . . . . . . 8 7.2.4. Forwarding Plane . . . . . . . . . . . . . . . . . . 9 8. Implementation . . . . . . . . . . . . . . . . . . . . . . . 9 9. Example of Multiple Namespaces . . . . . . . . . . . . . . . 10 9.1. Deploy ICN instances on Multiple-namespace Network . . . 10 9.2. Supporting Manifests . . . . . . . . . . . . . . . . . . 11 10. The procedure of communication over Heterogeneous Wireless Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction A number of future network architectures have been proposed to address existing problems of the current Internet, denoted as future Internet Architectures (FIAs). The naming and addressing of network entities including content, users, devices, services etc. are an common to all FIAs. Thus, no matter toward which FIA the Internet will evolve, there will be a need an open namespace management and Wang, et al. Expires April 7, 2016 [Page 2] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 resolution system to provide flexible definition of network entities, optimal name resolution and management, extra mobility consideration and improvement of security issues. Such a system will: Allow multiple namespaces to co-exist; Enable dynamic name resolution among multiple namespaces through policies; And facilitate interpolation between networked systems with different namespaces. This draft presents the architecture and implementation of such an open namespace resolution system. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Definitions and Abbreviations 3.1. Definitions This document uses the following definitions, that are mostly inspired from from [RFC5052], [RFC6363]. Namespace: Resolution: To Be Completed 3.2. Abbreviations This document uses the following abbreviations: ASP: Application Service Provider CCN: Content-Centric Network CS: Content Store DPI: Deep Packet Inspection Wang, et al. Expires April 7, 2016 [Page 3] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 FIA: Future Internet Architecture FIB: Forwarding Information Base GUID: Globally Unique Identifier ICN: Information Centric Network IFNS: Interface based Naming System MNSS: Multi-Name Service System NDN: Named Data Network NA: Network Address NSC: Name Service Component PIT: Pending Interest Table PSIRP: Publish Subscribe Internet Routing Paradigm QoS: Quality of Service RID: Routing Identifier SID: Static Identifier SDN: Software Defined Network URL: Universal Resource Locator VID: Virtual Identifier Other to be provided 4. Background In the current Internet, DNS servers take charge of mapping URL (name) to the actual network address of a target resource before initialting the communication. This name resolution policy (i.e., from domain name to IP address) is usually static. In a Named Data Network (NDN) [ndn], data is requested and located by its name. A NDN uses a recursive machanisms to resolve and forward from one namespace (named objectives) to another namespace. Wang, et al. Expires April 7, 2016 [Page 4] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 The Mobility First architecture [mobility] uses a Globally Unique Identifier (GUID) and a network address (NA) as the namespace to identify network entities. The length of the GUID is fixed to 160bits and the name resolution is also fixed and consists of mapping the GUID to the actual network address (NA). A switch will forward the packet based on the NA. The Independent Virtual Id Routing [virtualID] or VIRO decouples naming from routing via Virtual ID (VID) and allows different identifiers such as IPv4/IPv6, DNS names or some other names, to co- exist within the namespace. However, all of these namespaces will be mapped to the VID of the particular network entity. It only allows one level name resolution, e.g., from one name to VID, and flexible name resolution driven by policies among multiple namespaces is not accommodated. The Interface based Naming System [minami] or IFNS also allows multiple namespaces to co-exist in the architecture. A Multi-Name Service System (MNSS) will have different Name Service Components (NSC). IFNS is just one of NSC in this Multi-Name Service System. Each NSC has its own name resolution strategy and cannot map from one NSC to another one. What can be seen from the above it that each FIA has defined it's own mechanims. We propose that namespace resolution not only should have universality to adapt to general usage scenarios, but also should be flexible enough to meet some new requirements as the Internet evolves. A namespace management system should only be defined by the properties of network entities. Furthermore, a name resolution strategy should also provide name resolution from any source namespace to any destination namespace. 5. Requirements 5.1. Generic Namespace Management System As was seen above, for curretly existing network architectures, the namespace and resolution policy is fixed. As such a fixed name resolution policy cannot facilitate the deployment of new services. For example, a network service provider may do Deep Packet Inspection (DPI) for some flows. To enable this, a name resolution policy could specify which certain flows satisfied the pre-set conditions to be resolved to a middlebox for DPI while other flows will be resolved to next hop router for forwarding. In the more and more diverse Internet, a namespace management system should provide unified APIs to define namespaces and resolution policies flexibly and be applicable to network, services and Wang, et al. Expires April 7, 2016 [Page 5] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 application providers alike. Thus many types of network architectures can be supported on the same physical network. In addition, security features are necessary to ensure that a provider can only access its own namespace and the namespace can only be accessed by itself. Only when a source namespace allows resolution to a target namespace and, at the same time, the target namespace allows resolution from the source namespace, then the resolution between the source and the target namespaces can occur. It implies that resolving from namespace A to namespace B, then from namespace B to namespace C may not be equivalent to resolving from namespace A to namespace C. The mechanism decribed in the rest of this document allows this. 5.2. Definable Routing Controlling the routing and forwarding procedure based on some QoS and security consideration is a requirement of both service providers (to keep the traffic within their management domain) and of application providers (to control the quality of service). Hence, in a namespace management system, flexible name resolution policy should facilitate the implementation of any particular routing scheme. 5.3. Decoupling Name Resolution from the Application Service Provider In existing solutions, ASPs usually handle their own name resolution. For example, in Skype, name resolution is conducted by globally synchronized super nodes. But to maintain a namespace management system by application results in infrastructure costs when deploying application services. In consequence, and becuase the resolution cold be done on a remote network, the resolution delay may be higher than when done more locall by the network service provider. With our generic name resolution system, the resolution process can be moved from the application layer to the network layer with the authentication of ASPs. To achieve this as as mentioned above, there needs to be appropriate security for the namespace management system to ensure that an ASP can only define and access its own namespace, that there exisit a trust agreement betwoeen the ASP and the network service provider and that the resolution policy is mutually agreed by both source namespace owner and target namespace owner. 5.4. Compatibility Issues In order to support long-term evolution, different networks/protocols must be deployed in a unified framework. Thus, a generic namespace management system will provide a reasonable way to realize both backward and forward compatibility. On the application layer, because of the decoupling of resolution service from ASPs, the Wang, et al. Expires April 7, 2016 [Page 6] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 relationship among applications can be defined more flexibly with more interoperability. 5.5. Security Requirements The following two main features are added to the namespace solution to address the security concerns related to address resolution. 1) The dynamic security strategy is self-contained in the namespace definition. The service provider will be able to deploy different security strategies for specific services or applications in configuring its namespace. The security strategy can be flexibly changed by modifying the namespace. 2) The physical address is hidden. The namespace and name resolution rule are both defined by the service provider, and this whole process is hidden to other traffic. Furthermore, the control plane will do the authentication verification to guarantee the namespace cannot be left without proper authority. 6. Components of a Multi-namespace Management System To provide a namespace management system with the aforementioned features, we define three main components: 1) A Namespace Management Component that keeps namespace records. Different service providers can flexibly define their own namespaces based on different objectives and requirements. For instance, a network service provider can define a particular network by deploying the network entity namespace. In terms of application service providers, they can use the namespaces to describe the specific forwarding and security strategy of their application. 2) A Resolution Engine (forwarding plane) which processes filter and action setting for namespaces and entities respectively. In order to get the optimal name resolution and routing scheme, a service provider should define a series of appropriate forwarding policies among particular namespaces. Another other type of policy is provided by filters to define the access control for particular namespace. It is allowed that an instruction set contains multiple actions. A Control Plane which contains the access control module to guarantee that the configuration process is secure and reliable. It provides configuration APIs including: namespace management (register, update, delete), policy setting (filter and action) and system control. The control plane is provided by middleware, Wang, et al. Expires April 7, 2016 [Page 7] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 which makes it possible that all entities in the Internet (e.g., network devices, user, service, data object) can manage their namespaces when give appropriate authority. 7. System Architecture 7.1. Control Plane The Control Plane is a middleware between applications/services and the physical infrastructure. The configuration messages will be verified by the access control module in the control plane. This ensures there is valid authority for deploying the configuration for each namespace. Verified messages will be transmitted to the particular switches maintaining the target namespaces. 7.2. Switch 7.2.1. Namespace Management Module The Namespace Management Module provides two main functionalities: (i) it maintains the records of all namespaces and (ii) it interprets and executes policies (filters and actions) for namespace and entities (Resolution Engine). 7.2.2. Namespace Access Control Module Any entity (e.g., network devices, user, service, data object) can create, update, or delete namespaces and resolution policies by configuration messages. These messages contain the namespace settings (or changes), the policy setting (or changes) and the process flag (create, update or delete). A configuration message is firstly sent to the control plane. Then the control plane processes the message to find the target switches. Finally, the control plane pushes the configuration message with its signature to switches. In the switch, the Access Control Module will verify whether the configuration message is from the controller with authority to manage this particular namespace. 7.2.3. Session Control Module at the edge switch The Session Control Module is designed for managing the sessions and providing QoS in the edge switch. A session describes a temporary resolution, which avoids searching and interpreting among namespaces repeatedly. It highly improves the efficiency of data routing. Generally, every sessionxxx activity will be managed by its own life- cycle or providerxxx instruction. Sessions can be managed individually to achieve some QoS goals. The xxxirst packetxxx inference of OpenFlow and SDN can be used to trigger a new session. Wang, et al. Expires April 7, 2016 [Page 8] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 For OpenFlow, the first packet of a stream (after the DNS resolution) may trigger a control action. The first packet exchange therefore takes on a dual role: data exchange and control trigger. Having an explicit initial exchange that informs the network of the data transfer provodes a clean mechanism for separating the data delivery from the control plane. 7.2.4. Forwarding Plane The Forwarding Plane handles packet forwarding based on the resolution engine integrated in the namespace management module. It forwards packets to particular interfaces according to records in the interface mapping table. 8. Implementation The recommended namespace format is presented in the figure below. It can use the unity paradigm or a self-defined namespace format. +-----------------------------------------------------+ | Namespace: | |-----------------------------------------------------| | Policy: | | |----------------+------------------------------------| | Tag: | | |----------------+------------------------------------| | Entity Name | Value | Action | State | ... | |----------------+---------+----------+---------+-----| | | | | | | |----------------+---------+----------+---------+-----| | | | | | | |----------------+---------+----------+---------+-----| | | | | | | +-----------------------------------------------------+ Figure 1: Namespace format The different elements of the format are defined as follows: Policy: the access control filters of the namespace compose the policy. Generally, regular expressions are supported. But policy could also be programmed by script language to describe complicated filters and actions like moving to another namespace. Tag: the tag of a namespace indicates its characteristics. For example, if this is a service namespace, the tag could be the servicexxx name. Wang, et al. Expires April 7, 2016 [Page 9] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 Entity Name: the name of the specific entity. Value: the value is the type of address or of any other network identity. For example, the IP address, the MAC address or some new identity that is defined by the provider. Action: The action field indicates how the entities will be matched and what will be done after the matching. A particular namespace could have multiple actions to execute. For instance, SENDTO VALUE means forward to the network address recorded in the value field. GOTO means the packet will be send to another namespace. Furthermore, some filter can be added to limit the action. State: The state of this entity. For example state could show that whether a device is online or offline. 9. Example of Multiple Namespaces 9.1. Deploy ICN instances on Multiple-namespace Network Existing ICNs all have their own namespaces and mechanisms for resolution. Hence, we have deployed an ICN instance on our system. For instance, in NDN [jacobson], Forwarding Information Base (FIB), Content Store (CS), and Pending Interest Table (PIT) can be implemented as three namespaces in the proposed system where FIB is a namespace of destinations for Interests, CS is a namespace of cached content, and PIT is a namespace of sources for unsatisfied Interests. The Forwarding Engine described in CCN [snamp] can also be implemented in our system. The logic of original CCN Forwarding Engine can be defined by policies of namespaces. For instance, when an Interest packet comes in, the our forwarding engine will check if there is match in the namespace of the CS. If not, the forwarding engine will check the namespace of PIT (according to the action defined by the policy of namespace of CS). If no matching entity can be found in PIT again, the forwarding engine will check the namespace of FIB (according to the action defined by policy of namespace of PIT). We note that "prefix longest matching" can be defined by the filter of the policy of the entity in the namespace. Finally, according to the policy (action of forwarding and ID of target interface), the switch forwards this Interest packet to the corresponding interface specified by the matched entity. Besides NDN, other ICNs can be implemented by the proposed system. For example, PSIRP [psirp], is also supported by multiple namespaces. In PSIRP, users (subscribers/publishers) subscribe/publish content to Wang, et al. Expires April 7, 2016 [Page 10] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 rendezvous nodes. Rendezvous nodes actually can be implemented on switches with the namespaces of scope and content. In PSIRP, forwarding solely depends on information identifiers, i.e. RIds and SIds, thus MPLS-like label switching protocols are used. These identifiers can be processed by the filters defined by policies of corresponding namespaces and forwarding engine forwards packet by these identifiers with policies of namespaces. As a generic solution, our system supports implementation different ICNs, which makes it possible to deploy all these different ICN instances on the same infrastructure. An extra benefit is the possibility of fusioning ICNs. For instance, we can deploy two ICN instances, CCN and PSIRP, on the same infrastructure. In the switch, we can set some policies to define the translation between the namespaces of CCN and PSIRP. A CCN client requests content by sending an Interest packet. When it fails to find a matched entry in namespace of CS (defined by CCN), we may let it search in namespace of published content (defined by PSIRP), by the policies (action of xxxotoxxx and packet modifying to adapt PSIRP) of namespaces in CS. Thus, a publisher of PSIRP may provide the content to a CCN client. 9.2. Supporting Manifests The manifest is a data object containing meta-data about another object. Therefore, it can be given a name in CCN and the CCN transaction could start in a corresponding manner by requesting this object. There are proposals and discussion to add manifests to CCN. These manifests usually point to hashes of a series of data objects in order to speed up the forwarding and security checks. Manifests could also point to other names for the same object (like the name of an object pinned at a specific location). They could be extended to support other useful network meta-data. In a generalized multiple namespace management system, a user can issue a request for a manifest data object which consists of a set of data objects from different ASPs or different ICN instances. The name resolution for the data objects contained in the manifest can be done individually in different namespaces according to the name resolution policy specified in the meta data of the manifest. This will allow users to compose and fetch data/service from different ASPs and/or ICN instances in an easy way. 10. The procedure of communication over Heterogeneous Wireless Network In the current heterogeneous wireless network, communication between two entities which employ different network protocols needs to be bridged by IP. That means the protocol translation is performed twice, which leads to extra transmission overhead (due to redundant Wang, et al. Expires April 7, 2016 [Page 11] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 TCP/IP packet header) and operations overhead (brought by format conversion between Ethernet frame in the link layer and data packet in the network layer). To solve the problem mentioned above, we designed a new namespace management system to make the communication more flexible and efficient. +-----------+ +-----------+ |User Device| |User Device| +-----------+ +-----------+ \ / \ Wi-Fi ZigBee / \\ / \ // \| |/ |------------IP------------| |\ /| AP\ / AP \ / \ / IP IP \ / \ / \ / \ / \ \ / / \ | / BlueTooth | AP --- +-----------+ |User Device| +-----------+ Figure 2: Demo Scenario In the sensor network scenario shown in the Figure 1, three different protocols, i.e., Wi-Fi, ZigBee, and Bluetooth, are adopted by different devices. Instead of encapsulating the original packet with different protocols into a TCP or UDP packet and routing packets based on IP, Our proposed namespace management system can be used to support protocol and packet translation by extending the Ethernet frame. The format of the designed new frame is shown in the figure 2. Wang, et al. Expires April 7, 2016 [Page 12] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 +----------------------------------------------------------------------+ |Destination |Source | | | | | |Mac address |MAC address |Protocol Type | SrcName | DstName | Payload | |-------------------------+----------------------------------+---------| | MAC Header | Self-defined Namespace | Data | +----------------------------------------------------------------------+ Figure 3: Frame Format In this frame, MAC Header field records the source and destination MAC addresses for link layer transmission. SrcName, DstName and Protocol Type in the Data field are used for routing purposes where the name resolution will be used by our proposed multiple namespace management system. Upon receiving the frame, the router will do name resolution based on the SrcName and DstName to find out where this frame should be forwarded to and will change the DstMACAdd to the Mac address of a physical device's specific port for next hop. When the target device receives the frame, it will translate the frame to the target format according to the protocol stored in the Protocol Type property. Figure 3 presents an example of the translation between Bluetooth and WiFi. +---------------------------------------------------------------------+ | | | | +-----------------------------------------------------------+ | | | Access Code | Bluetooth Header | Data | | | +-----------------------------------------------------------+ | | | | | +-----------------------------------------------------------+ | | | Ethernet MAC Header | Protocol |Self-defined| | | | ==> |(SrcMAC,DstMAC address)| Type | Namespace | Data | | | +-----------------------------------------------------------+ | | | | | +-----------------------------------------------------------+ | | | Wi-Fi MAC Header | | | | ==> |(Frame Control, SrcMAC, DstMAC, RouterMAC address)| Data | | | +-----------------------------------------------------------+ | | | | | Header | Payload | +---------------------------------------------------------------------+ Figure 4: an example of the translation between Bluetooth and Wi-Fi With the application of the new namespace management system, the whole procedure is expected to be accomplished at the link layer Wang, et al. Expires April 7, 2016 [Page 13] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 without switching to the network layer. Figure 4 indicates the results of the comparison of the throughput rates between the solution using multiple namespace management system and UDP under different situations (Throughput: Packets/sec, Packet Size: Bytes). +--------------------------------------------------------------------+ | | One Threads | Two Threads | Three Threads | |--------------------------------------------------------------------| | Packet | | | | | | | | | | | Size | 10 | 100 |1000 | 10 | 100 |1000 | 10 | 100 |1000 | |--------------------------------------------------------------------| | Our System | | | | | | | | | | | Throughput |50120|47875|38533|94231|90652|72153|136246|126053|98152| |--------------------------------------------------------------------| | UDP | | | | | | | | | | | Throughput |36983|36720|33023|63034|60992|60238|53221 |52965 |53393| |--------------------------------------------------------------------| | Optimizing | | | | | | | | | | | Percentage | 35% | 30% | 16% | 49% | 48% | 19% | 156% | 137% | 83% | +--------------------------------------------------------------------+ Figure 5: Comparison of the throughput capacity between our system and UDP This demo shows that multiple namespace management system can enable flexible protocol translation by self-defined name resolution. 11. Acknowledgements The authors would like to acknowledge Dr. Marie-Jose Montpetit for supporting editing of this draft. 12. IANA Considerations This document includes no request to IANA at this point. 13. Security Considerations To be defined when appropriate, see RFC 3552 [RFC3552]. 14. References 14.1. Normative References Wang, et al. Expires April 7, 2016 [Page 14] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 14.2. Informative References [jacobson] Jacobson, V., Smetters, D., Thornton, J., and et. al, "Networking named content.", Proceedings of the 5th international ACM conference on Emerging Networking Experiments and Technologies. , 2009. [minami] Minami, M., Morikawa, H., and T. Ayoma, "The design of naming-based service composition system for ubiquitous computing applications", SAINT Workshop at the 2004 IEEE International Symposium on Applications and the Internet , 2004. [mobility] Seskar, I., Nagajara, K., Nelson, S., and et. al, "Mobilityfirst future internet architecture project.", Proceedings of the ACM 7th Asian Internet Engineering Conference. , 2011. [ndn] Zhang, L., Estrin, D., Burke, J., and et. al, "Named data networking (NDN) project.", Relatxxxrio Txxxcnico NDN- 0001, Xerox Palo Alto Research Center-PARC , 2010. [psirp] Trossen, D., "PURSUIT reference.", Some conference - TBD , XXX. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007, . [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, . Wang, et al. Expires April 7, 2016 [Page 15] Internet-DrafNamespace Resolution in Future Internet Archit October 2015 [snamp] Afanasyev, A., "SNAMP: Secure Namespace Mapping to Scale NDN Forwarding.", Proceedings of IEEE Global Internet Symposium. , 2015. [virtualID] Lu, G., Jain, S., Chen, S., and et. al, "Virtual id routing: a scalable routing framework with support for mobility and routing efficiency.", Proceedings of the 3rd International ACM Workshop on Mobility in the Evolving Internet Architecture. , 2008. Authors' Addresses Jianping Wang City University of Hong Kong Email: "jianwang@cityu.edu.hk Shusheng Liu Huawei Email: liushucheng@huawei.com Cedric Westphal Huawei Email: Cedric.Westphal@huawei.com Wang, et al. Expires April 7, 2016 [Page 16]