Namespace Resolution in Future Internet Architecture
draft-wang-fia-namespace-00

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]