Information Centric Working Group J. Wang Internet-Draft City University of Hong Kong Intended status: Experimental S. Liu Expires: January 1, 2016 C. Wetphal Huawei June 30, 2015 Namespace Resolution in Future Internet Architecture draft-wang-fia-namespace-00 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 January 1, 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 January 1, 2016 [Page 1] Internet-Draft Namespace Resolution in FIA June 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. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Generic Namespace Management System . . . . . . . . . . . 5 5.2. Definable Routing . . . . . . . . . . . . . . . . . . . . 5 5.3. Decoupling Name Resolution from the Application Service Provider . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. Compatibility Issues . . . . . . . . . . . . . . . . . . 6 5.5. Security Requirements . . . . . . . . . . . . . . . . . . 6 6. Components of a Multi-namespace Management System . . . . . . 7 7. System Architecture . . . . . . . . . . . . . . . . . . . . . 7 7.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7 7.2. Switch . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 8 8. Implementation . . . . . . . . . . . . . . . . . . . . . . . 8 9. Example of Multiple Namespaces . . . . . . . . . . . . . . . 10 9.1. Deploy ICN instances on Multiple-namespace Network . . . 10 9.2. Supporting Manifests . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 common requirements to all FIAs. Thus, no matter toward which FIA the Internet will evolve, there will be a need for open namespace management and resolution system to provide flexible definition of network entities, optimal name resolution and management, extra mobility consideration, and improvement of security issues. Wang, et al. Expires January 1, 2016 [Page 2] Internet-Draft Namespace Resolution in FIA June 2015 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. Abbreviations This document uses the following abbreviations: ASP: Application Service Provider CCN: Content-Centric Network CS: Content Store DPI: Deep Packet Inspection 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 Wang, et al. Expires January 1, 2016 [Page 3] Internet-Draft Namespace Resolution in FIA June 2015 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 as the document evolves 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 fixed. 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. 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 Wang, et al. Expires January 1, 2016 [Page 4] Internet-Draft Namespace Resolution in FIA June 2015 (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 its own resolution mechanim. 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 currently 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 h certain flows satisfying 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 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 Wang, et al. Expires January 1, 2016 [Page 5] Internet-Draft Namespace Resolution in FIA June 2015 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 could be done on a remote network, the resolution delay may be higher than when done locally 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 mentioned above, appropriate security is needed for the namespace management system to ensure that an ASP can only define and access its own namespace, that there exists a trust agreement between 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 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. Wang, et al. Expires January 1, 2016 [Page 6] Internet-Draft Namespace Resolution in FIA June 2015 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, which makes it possible that all entities in the Internet (e.g., network devices, user, service, data object) can manage their namespaces when given 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 Wang, et al. Expires January 1, 2016 [Page 7] Internet-Draft Namespace Resolution in FIA June 2015 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 session's activity will be managed by its own life- cycle or provider's instruction. Sessions can be managed individually to achieve some QoS goals. The "first packet" inference of OpenFlow and SDN can be used to trigger a new session. 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. Wang, et al. Expires January 1, 2016 [Page 8] Internet-Draft Namespace Resolution in FIA June 2015 +-----------------------------------------------------+ | 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 service's name. 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 sent to another namespace. Furthermore, some filter can be added to limit the action. State: The state of the entity. For example state could show that whether a device is online or offline. Wang, et al. Expires January 1, 2016 [Page 9] Internet-Draft Namespace Resolution in FIA June 2015 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. All ICN instance can be deployed 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 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 Wang, et al. Expires January 1, 2016 [Page 10] Internet-Draft Namespace Resolution in FIA June 2015 of published content (defined by PSIRP), by the policies (action of 'GOTO' and packet modifying to adapt to 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. Acknowledgements The authors would like to acknowledge Dr. Marie-Jose Montpetit for supporting editing of this draft. 11. IANA Considerations This document includes no request to IANA at this point. 12. Security Considerations To be defined when appropriate, see RFC 3552 [RFC3552]. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Wang, et al. Expires January 1, 2016 [Page 11] Internet-Draft Namespace Resolution in FIA June 2015 13.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.", Relaterio Tecnico NDN-0001, Xerox Palo Alto Research Center-PARC , 2010. [psirp] Fotiou, N., Nikander, P., Trossen, D., and G. Polyzos, "Developing Information Networking Further: From PSIRP to PURSUIT", BROADNETS: International ICST Conference on Broadband Communications, Networks, and Systems , 2010. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [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. Wang, et al. Expires January 1, 2016 [Page 12] Internet-Draft Namespace Resolution in FIA June 2015 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 January 1, 2016 [Page 13]