ICNRG C. Hur Internet Draft J. Kim Intended status: Informational H. Jung Expires: March 2015 J. Eun ETRI W. Chun HUFS October 28, 2014 Abstracted Network API for ICN draft-hur-icnrg-abstracted-network-api-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Hur Expires January 21, 2015 [Page 1] Internet-Draft Abstracted Network API for ICN October 2014 This Internet-Draft will expire on March 10, 2015. Copyright Notice Copyright (c) 2014 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract In information-centric networking (ICN), well designed API will play a pivotal role in adopting ICN to applications. Traditional network API - i.e., current Socket implementation - is coupled between applications and underlying protocols, so it is hard to change one without changing the other, thus it could be solved by redesigning the network API in a way that decouples application-specific functions from network specific functions. In this draft, we addressed the network API modeling issues which can be also applied to the design of ICN APIs and proposed iPlug and dSocket API which help injection of applications' intent and hide underlying network specific mechanisms, respectively. Table of Contents 1. Introduction ................................................ 3 2. Abstracted Network API ...................................... 4 2.1. Intent modeling......................................... 4 2.2. Loosely coupled modeling................................ 5 3. IPlug and DSocket API........................................ 6 3.1. Key operations ......................................... 8 4. Analysis .................................................... 8 5. Security Considerations...................................... 8 6. IANA Considerations ......................................... 8 7. References .................................................. 9 7.1. Normative References.................................... 9 7.2. Informative References.................................. 9 A.1. Authors' Addresses..................................... 10 Hur Expires April 27 2015 [Page 2] Internet-Draft Abstracted Network API for ICN October 2014 1. Introduction In the information-centric networking, the key idea is to let named data to be identified by name and to be retrieved wherever they are. To enable these communications, the named data need network API to use the functionalities of the underlying network. We bring up an issue for such an interface that is used by any source. Since many studies in interface patch up traditional socket-based API which is already tightly coupled to location, it is inevitable to redesign new network interface not only to be in accordance with location independent name, but also to meet the needs such as multihoming, and mobility[ICN Challenges]. Recent ICN-based contributions have been presented network API, such as NetInf[ref], CCN/NDN[ref] and Publish/Subscribe Networking. There is common ground on naming and network primitives for accessing any object, regardless of location. NetInf defines set of APIs to handle Named Data Object (NDO), such as PUBLISH, INDICATION, REQUEST, RESPONSE, etc. NetInf API is used to retrieve NDO which is identified by NI naming [RFC 6920], instead of IP and Port in traditional socket API. It employs receiver-driven transport for carrying chunks of an object, and provides convergence layer to bridge with other protocols, such as HTTP and DTN. CCN/NDN defines CCNx API [Mosko] which adopted URL in content name representation. All communication between the core protocol implementation, network, and applications is accomplished through a Face abstraction (e.g., link layer face, network-layer face, and transport-layer face). They also note that abstracted API is important for flexibility and extensibility. In this regard, we need a common ICN API that enables applications to be independent, interworked and evaluated throughout heterogeneous network architecture. In addition, network architectures can evolve and converged with others. For this, it is necessary to define common primitive API which abstracts the essential behavior. This draft introduces modeling consideration for API of ICN as well as other network architectures. We abstract the network API by applying Model Driven Engineering (MDE) and Separation of Concerns (SoC) principle [Morin, Moreira] which are principles in Object- Oriented design. The network API, in common with many other architectures, needs to be simple but powerful enough to help applications to focus on their own concerns regardless wherever the objects are located in and how to get the objects in the underlying network, but also assist separating ID/Locator in the Internet Hur Expires April 27 2015 [Page 3] Internet-Draft Abstracted Network API for ICN October 2014 architecture. The Internet applications using the network API can focus on only what to communicate with, not where or how. 2. Abstracted Network API This draft describes abstracted network API to inject communication intents from application to network. For this abstraction requires API modeling concepts at different point of view. The abstracted network API can overcome the problems in the application point of view in the following. First of all, network application uses API that depends on some parts of network mechanism. Therefore, it has to concern with unnecessary aspects of network, such as name resolution, and congestion control. Second, when new network mechanism such as ICN is introduced, existing applications are no longer available, but modification takes a lot of efforts. In addition, new architectural changes are hardly deployed because of difficulty of application migration. It often led to overwrap the existing network API. Therefore, in network API, abstractions for both vertical and horizontal separation of concerns should be provided for reducing complexity. Vertical separation of concerns itemizes application's intent to be composable, and horizontal separation of concern reduces complexity by decoupling network-specific aspects from application, as shown in Figure 1. 2.1. Intent modeling In the ID/Locator splitted network such as ICN, application is only required to handle whom to communicate, but not how to communicate. Given this network, this draft adopts the MDE for API to be modeled at two different levels of abstraction. Network Independent Model (NIM) and Network Specific Model (NSM). When we define a network independent model and a network mechanism dependent model, one can find intent of network application. An intent is concern of application and an application can have multiple intent. For instance, an application can have intent to communicate with endpoints and demand reliable transmission. To enable the network application over the network, intent injection from NIM to NSM are needed. For example, if voice call application requires secure communication channel and certain quality of service, its intent can be carried in various ways such as IPSec and jitter control. Hur Expires April 27 2015 [Page 4] Internet-Draft Abstracted Network API for ICN October 2014 2.2. Loosely coupled modeling Loosely coupled modeling has several advantages in the network API. First of all, it helps to separate concerns between application and network layer. Because separation of concerns in horizontal manner is to present integrated way to use underlying network, despite the network might include certain networking mechanisms (e.g., protocol, delivery types). It helps to realize applications' various communication intents over the heterogeneous network mechanisms. Second, loosely coupled relation reduces the dependency. Also, it makes possible to communicate between applications regardless the lower-level component and its implementation. For example, when applications retrieve Named Data Object, loosely coupled API is required in different kinds of architectures (e.g., ICN, CCN). Similarly, by performing the dynamic association between communication intent and network mechanism, both sides can be independent. Hur Expires April 27 2015 [Page 5] Internet-Draft Abstracted Network API for ICN October 2014 +=======================================================+ | Network Independent Model | | +----------+ +----------+ +----------+ | | | Intent 1 | | Intent 2 | ... | Intent N | | | +----------+ +----------+ +----------+ | +=========================|=============================+ Intent Injection | +=========================@=============================+ | Network Specific Model | | +-------------+ +-------------+ +-------------+ | | | Mechanism 1 | | Mechanism 2 | ... | Mechanism N | | | +-------------+ +-------------+ +-------------+ | | | | / | | +----------------------+ | | | Network Architecture | | | +----------------------+ | +=======================================================+ Network API modeling Figure 1. 3. IPlug and DSocket API This draft proposes iPlug and dSocket as an abstracted API model. The iPlug API takes charge of application-specific capabilities. Application needs functionalities such as flow control, authentication, which is supported by iPlug. The dSocket is a cut- off point of separation and hold responsibilities that network should handle, such as congestion control, multipath, multihoming. Hur Expires April 27 2015 [Page 6] Internet-Draft Abstracted Network API for ICN October 2014 In Figure 2, relation of API components is described. At first, application binds unique ID to iPlug. The plug-in and plug-out behavior help dynamic association between iPlug and dSocket. When detailed metadata of dSockets are delivered to applications, and then dSocket notifies the status to dSocket Manager to inform their relation change. Then, the iPlug can plug into the dSocket to inject application's intent, and plug out of the dSocket. Detailed procedures of each API are described in the following. +-------------------+ | Application |---+ +-------------------+ | | Extension | |BIND +----------------+ FIND +-------------------+ | | dSocket |<--------| iPlug |<--+ | Manager | +===================+ +----------------+ | PLUGIN ^ | PLUGOUT | REGISTER +===================+ ----------------| dSocket | +-------------------+ | Domain | +-------------------+ Components of API Figure 2. Hur Expires April 27 2015 [Page 7] Internet-Draft Abstracted Network API for ICN October 2014 3.1. Key operations The abstracted network API has main operations for dynamic convergence. The sequences and states of each operations are described in the folloing. iPlug dSocket |---+ | | | BIND NAME | IDENTIFIED |<--+ | | | |-------------- PLUG IN ------------->| PLUGIN-RECEIVED PLUGGED IN | | PRESENTED | | |------------- PLUG OUT ------------->| PLUGOUT-RECEIVED PLUGGED OUT | | DEPRESENTED | | 4. Analysis TBD 5. Security Considerations TBD 6. IANA Considerations TBD Hur Expires April 27 2015 [Page 8] Internet-Draft Abstracted Network API for ICN October 2014 7. References 7.1. Normative References 7.2. Informative References [ICNRG charter] http://irtf.org/icnrg [ICN Challenges] D.Kutscher, S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, and M. Waehlisch, "ICN Research Challenges ", draft-kutscher-icnrg-challenges-02, February 2014. [RFC 6920]S. Farrell, C. Dannewitz, P. Hallam-Baker, D. Kutscher, and B. Ohlman, "Naming Things with Hashes." [Online]. Available: https://tools.ietf.org/html/rfc6920. [Accessed: 24-Oct-2014]. [Mosko] M. Mosko, "CCNx 1.0 Protocol Introduction," Apr. 2014. [NETINF] Scalable and Adaptable Internet Solutions (SAIL), "D.B.1: The Network of Information: Architecture and applications", available at: http://www.sail-project.eu/deliverables/, 2011 [CLICK] "The Click Modular Router Project." [Online]. Available: http://read.cs.ucla.edu/click/. [Accessed: 12-Jun-2014]. [Morin] B. Morin, F. Fleurey, N. Bencomo, J.-M. Jezequel, A. Solberg, V. Dehlen, and G. Blair, "An Aspect-Oriented and Model-Driven Approach for Managing Dynamic Variability," in Model Driven Engineering Languages and Systems, K. Czarnecki, I. Ober, J.-M. Bruel, A. Uhl, and M. Volter, Eds. Springer Berlin Heidelberg, 2008, pp. 782-796. [Moreira] A. Moreira, A. Rashid, and J. Araujo, "Multi-dimensional separation of concerns in requirements engineering," in 13th IEEE International Conference on Requirements Engineering, 2005. Proceedings, 2005, pp. 285-296. [Fielding]R. T. Fielding, "Architectural Styles and the Design of Network-based Software Architectures," University of California, Irvine, 2000. Hur Expires April 27 2015 [Page 9] Internet-Draft Abstracted Network API for ICN October 2014 A.1. Authors' Addresses Cinyoung Hur ETRI 218 Gajeong-ro, Yuseong-gu, Daejeon, Korea Email: cyhur@etri.re.kr JongHwan Kim ETRI 218 Gajeong-ro, Yuseong-gu, Daejeon, Korea Email: ditto@etri.re.kr Heeyoung Jung ETRI 218 Gajeong-ro, Yuseong-gu, Daejeon, Korea Email: hyjung@etri.re.kr Jeesook Eun ETRI 218 Gajeong-ro, Yuseong-gu, Daejeon, Korea Email: jseun@etri.re.kr Woojik Chun Hankuk University of Foreign Strudies 81, Oedae-ro, Mohyeon-myeon, Cheoin-gu, Yongin-si, Gyeonggi-do, Korea Email: woojikchun@gmail.com Hur Expires April 27 2015 [Page 10]