Internet DRAFT - draft-hur-icnrg-abstracted-network-api
draft-hur-icnrg-abstracted-network-api
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]
