Internet DRAFT - draft-anilj-icnrg-icn-qos
draft-anilj-icnrg-icn-qos
ICNRG Anil Jangam
Internet-Draft Prakash Suthar
Intended status: Informational Milan Stolic
Expires: January 16, 2019 Cisco Systems
July 15, 2018
Supporting QoS aware Data Delivery in Information Centric Networks
draft-anilj-icnrg-icn-qos-00
Abstract
Information Centric Networking (ICN) is shaping up as an alternative
networking mechanism for the TCP/IP based host-centric networking
paradigm. Content delivery or streaming is one of important use
cases where the real value and potential of ICN architecture is being
investigated. While a number of studies on an optimal and efficient
routing of Interest requests have been published, more discussion is
needed on the mechanisms for implementation and enforcement of the
quality of service (QoS) in the ICN based data delivery path. In
this document, we focus on two most popular ICN architectures, CCN
(Content Centric Networking) and NDN (Named Data Networking) and
describe how we can achieve the QoS aware data delivery in the ICN
network. We propose to use the differentiated services (DiffServ)
QoS model based on DSCP codes, which is also used in the IP based
Internet design. We further present how QoS parameter syntax can be
added to the current CCNx messages.
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 https://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 16, 2019.
Anil Jangam, et al. Expires January 16, 2019 [Page 1]
Internet-Draft July 2018
Copyright Notice
Copyright (c) 2018 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
(https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Prior Work and Motivation . . . . . . . . . . . . . . . . . . 3
3.1. Prior Work . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Prioritization of Interest Packets . . . . . . . . . 3
3.1.2. Flow classification in ICN . . . . . . . . . . . . . 4
3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. QoS Perspective in ICN . . . . . . . . . . . . . . . 5
3.2.2. ICN Deployments in Mobile Networks . . . . . . . . . 6
4. Current QoS Implementations . . . . . . . . . . . . . . . . . 6
4.1. QoS in IP Networks . . . . . . . . . . . . . . . . . . . 6
4.1.1. Traffic Classification and Marking . . . . . . . . . 7
4.2. QoS in Mobile Networks . . . . . . . . . . . . . . . . . 8
4.2.1. QoS in 4G Networks . . . . . . . . . . . . . . . . . 8
4.2.2. QoS in 5G Networks . . . . . . . . . . . . . . . . . 10
4.3. QoS in hICN . . . . . . . . . . . . . . . . . . . . . . . 10
5. Supporting QoS in ICN . . . . . . . . . . . . . . . . . . . . 11
5.1. DiffServ in ICN . . . . . . . . . . . . . . . . . . . . . 11
5.2. Supporting DiffServ Fields in CCNx Message . . . . . . . 11
5.2.1. Overall CCNx Packet Format . . . . . . . . . . . . . 11
5.2.2. Generic CCNx Message Format . . . . . . . . . . . . . 12
5.2.3. DiffServ Fields Message TLV . . . . . . . . . . . . . 13
5.2.4. Modified Interest Message TLV . . . . . . . . . . . . 14
5.2.5. Modified Content Object TLV . . . . . . . . . . . . . 14
6. Empirical Study . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
Anil Jangam, et al. Expires January 16, 2019 [Page 2]
Internet-Draft July 2018
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
Information Centric Networking (ICN) is a promising network design,
where the content is the first class citizen. The content is
uniquely identified and addressed by its name. The network follows
the Pub-Sub design paradigm using the Interest and Data messages for
the communication. The network architecture paves the ways for
network traffic optimization by virtue of (1) aggregation of Interest
requests initiated for the same content and (2) by caching of the
content within the network itself [JACOBSON]. A number of
applications and empirical studies have been performed, which
establishes the benefits and feasibility of this new network
architecture.
With the ubiquitous and phenomenal growth of smart mobile devices in
recent years, the demand for the Internet and its use has outgrown
beyond its traditional use for the transfer of data/file. The
availability and support for higher bandwidth due to technological
advancements in the networks, the demands and usage patterns of the
Internet is changing faster than ever [CISCO_VNI]. According to this
report, it is imperative for the service providers to meet the
quality of service (QoS) demands of consumers as well as certain
types of applications (e.g. VR, AR), and provide a better quality of
experience to their users.
2. Conventions and Terminology
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 [RFC2119].
This document uses the terminology of [CCNXSEMANTICS] and
[CCNXMESSAGES] for CCNx entities.
3. Prior Work and Motivation
3.1. Prior Work
3.1.1. Prioritization of Interest Packets
Among the published research related to meeting the quality of
service (QoS) requirements in ICN network, we found that a larger
focus and emphasis is given to an optimized and efficient routing of
the Interest requests towards the content.
Anil Jangam, et al. Expires January 16, 2019 [Page 3]
Internet-Draft July 2018
M.F. Al-Naday et.al. in [NADAY] attribute the scalability limitation
of IP based QoS model to its lack of information awareness in the IP
based network; however, they argue that these limitations can be
resolved in an ICN like network. In the context of CCN/NDN network
design, while authors points to the possibility of using the QoS
aware name prefixes, they also comment about the limitations of such
approach for the third parties (e.g. network operators) in defining
an alternative QoS enforcement mechanisms. Moreover, the QoS
solution is developed around the PURSUIT architecture, which may not
be applicable to CCN/NDN.
Weibo Chu et.al. in [WEIBO] present a QoS model for ICN network based
on the popularity ranking of the content and its placement/location
in the network. They present a classification of the content into
three categories - locally cached, remotely cached, and uncached
contents, hence the network delay is modeled as a function of the
distance of the content from the requester. Essentially, the QoS
problem is tackled in terms of faster routing of Interest request
towards its content.
In [XINGWEI] authors present a QoS mechanism, which is applicable to
the routing of Interest requests in ICN network. The basis of their
proposal is to decide the suitability of the forwarding link to make
the process more energy efficient. They maintain or use the same
Data forwarding algorithm specified in the original NDN design
[JACOBSON].
Finally, in [CHRISTOS] Christos et.al. argue about a need for a
differentiated routing and forwarding mechanisms based on not only
the name of the content but also specifying the nature of the
traffic. They further emphasize that this differentiation is better
handled at the network level rather than leaving it for the upper
layer.
In all above use cases, we noticed that all QoS related discussions
are mainly focused on the forwarding of the Interest requests. The
examples we cited above assumes that the Data packets are forwarded,
downstream direction, using the interface information recorded in the
pending Interest table (PIT). There is little or no discussions
provided as to how QoS can be implemented and enforced on the Data
packet path.
3.1.2. Flow classification in ICN
There are at least two prior arts, which describe methods to
implement flow classification in ICN.
Anil Jangam, et al. Expires January 16, 2019 [Page 4]
Internet-Draft July 2018
In [MIOSEENKO] author have described two methods for identifying the
flow classes using the content name. In the first method, called as
equivalence class component count (EC3), they use the predefined
number of components from the content name forming an equivalence
class. While the approach has the flexibility in re-grouping of
components in aggregating the flows, it suffers from the consistent
interpretations due to implicit binding of the equivalence class into
the content namespace. In second method, called as equivalence class
name component type (ECNCT), the flow classification information is
directly embedded into the hierarchical content name. This paves the
way to achieve implicit or aggregate flow classification similar to
prefix based content aggregation. At the forwarder level, a flow
table is implemented to store the equivalence classes and used to
perform the flow classification decisions.
While authors present an idea, in absence of an empirical analysis,
it leaves many questions open (e.g. scalability of flow table, name
lookup, and publishing of equivalence classes). Also, without a
standardized or accepted naming convention, this name based scheme
may not be suitable as a basis for flow classification.
Xia et.al. in [XIA] state the need of traffic recognition for better
network operations; however, due to lake of an efficient flow
identification and unified standard for traffic recognition, author
propose a multi-service tag based naming scheme similar to
hierarchical URI design. They provide a set of guidelines for the
design of multi-service tag and a preliminary design of the same;
however, the proposed approach does not provide any aspects of
practical feasibility.
3.2. Motivation
3.2.1. QoS Perspective in ICN
Using its multipath forwarding capability, CCN/NDN routers forward
the Interest message to one or more next-hop interfaces. This
provides an opportunity for the router to implement an adaptive
forwarding policy and achieve faster and efficient content fetching.
In this process, router records the ingress Interface information (on
which the Interest request arrived) and maintains the mapping, in the
PIT table, between the content name and the Interface. Once the Data
packet is received from the upstream router node, this router
forwards the Data on the Interface by finding the matching Interface,
from the PIT table, using the content name of the Data packet.
While there is a flexibility in forwarding the Interest traffic on to
multiple next hops (e.g. using multipath forwarding strategy), Data
packets are always (or rather must be) forwarded on the Interface
Anil Jangam, et al. Expires January 16, 2019 [Page 5]
Internet-Draft July 2018
recorded in the PIT. This CCN/NDN behavior creates an interesting
problem from the QoS perspective - the same (ingress) Interface can
now potentially be used for transferring traffic serving multiple
content names. There is a contention for sending multiple Data
packets on the same interface. At this point, the forwarding of Data
packet traffic also becomes the problem of scheduling of traffic. In
[CHRISTOS] we saw that by the very nature of type of traffic, a
differentiated traffic handling is necessary to ensure appropriate
QoS is achieved.
3.2.2. ICN Deployments in Mobile Networks
A number of proposals have been submitted describing the use and
deployment of ICN in 4G and 5G mobile networks. In [PSUTHAR]
P.Suthar et.al. described the native deployment of ICN and dual stack
deployment (IP and ICN) in distinct parts of 4G/LTE network, such as
user plane, UE, eNodeB, and core network (SGW and PGW). In
[RAVINDRAN] Ravi Ravindran et.al. have described the ICN based
extensions to 5G control and user plane to support packet data unit
(PDU) sessions. Lastly, [KALYANI] described the use of hICN (Hybrid
ICN) in management of mobility in 5G networks.
An important takeaway from these ICN deployment examples is that it
opens up scope for extending ICN specific QoS features proposed in
this draft and also provides an opportunity for interoperability
between the QoS mechanisms used in 4G, 5G mobile networks and the
proposed ICN QoS mechanisms. These topics need further
investigations.
4. Current QoS Implementations
4.1. QoS in IP Networks
Differentiated services or DiffServ [RFC2475] is one of the highly
deployed and preferred L3 QoS mechanisms over other mechanisms, such
as Integrated Services or IntServ. DiffServ works on the premise
that the traffic classification marking is performed at the edge of
the network whereas the core network router only acts on the QoS
marked packets and performs packet forwarding and scheduling. Each
DiffServ-aware network router (or a set of routers in a DiffServ
domain) implements a common per-hop behaviors (PHBs) that defines the
packet-forwarding properties associated with a class of traffic.
DiffServ specify a simple and scalable quality of service (QoS)
architecture based on the principle of traffic classification. This
traffic classification is achieved by using a 6-bit differentiated
services code point (DSCP) in the 8-bit differentiated services field
(DS field) in the IP header [RFC2474].
Anil Jangam, et al. Expires January 16, 2019 [Page 6]
Internet-Draft July 2018
In the scope of this draft proposal, we mainly focus on the DiffServ
based QoS model and do not explore into the applicability of IntServ
QoS model to this work. In future revisions, we shall investigate
the use of IntServ as needed.
4.1.1. Traffic Classification and Marking
The traffic classification and PHB is determined by a 6-bit
differentiated services code point (DSCP) in the differentiated
services field (DS field) of the IP header [RFC2474]. On the ingress
router at the DiffServ domain, a specific traffic class is assigned
based on various parameters, such as source address, destination
address or traffic type (e.g. audio, video). By virtue of the 6-bit
field a total of 64 (2^6) classifications are possible at the network
router; however, for more practical purposes, following 4 classes are
typically used by the network routers.
o Default forwarding (DF): this is the default forwarding
classification provides the best-effort forwarding
characteristics.
o Expedited forwarding (EF): as its name suggests, this forwarding
classification provides the low delay, low loss and low jitter
forwarding characteristics. These are typically suitable for
real-time traffic. To avoid any adverse effect of overuse of this
class, the EF traffic classification is performed through a
stricter admission policy control mechanism.
o Assured forwarding (AF): this forwarding classification provides
the assurance of the packet delivery under a configured threshold
levels of traffic. Beyond this threshold level, network routers
may choose to drop the packet traffic when congestion is detected.
Within the three levels of drop probabilities (low, medium, and
high), a further sub-classification is achieved by 4 different
sub-classes. Thus, total 12 classes are possible using AF
classification. Within the given drop probability, the traffic
with the higher sub-class assignment is given priority over the
others. Similarly, within the same sub-class, the packets with
higher drop probability are dropped first over the others.
o Class selectors (CS): provides the backward compatibility with the
IP Precedence field in the TOS byte of the IP header. It has been
widely accepted to use the TOS octet as the DS field for DiffServ
networks; however, CS classification is used to process the
packets received from a non-DiffServ aware router.
In DiffServ model, the end-to-end QoS behavior is still unpredictable
as the PHB behavior of each router in the DiffServ domain depends on
Anil Jangam, et al. Expires January 16, 2019 [Page 7]
Internet-Draft July 2018
configuration at each router. This end-to-end QoS behavior is
further complicated if the packet has to traverse multiple DiffServ
domains. Thus any QoS marking or classification does not guarantee
the QoS as such. Sender can only expect that network provides the
QoS indicated by it.
4.2. QoS in Mobile Networks
Applicability and use of ICN in mobile networks is briefly discussed
in Section 3.2.2. Therefore, in the context of this draft, it
becomes important to understand how QoS is implemented in mobile
networks today, and this section provides an overview of that
implementation. In subsequent section, we shall see how ICN based
QoS mechanisms can provide an end-to-end QoS service to the mobile
network users.
3rd Generation Partnership Project (3GPP) specification [TS23.107]
describes the framework for QoS within the 3GPP system applicable to
4G/LTE networks. It specifies the list of attributes applicable to
the end-to-end bearer service, as well as describes the QoS
architecture to be used in the 3GPP system. In a typical case, a
user session is established in two parts and each of these provides
an optimized way to realize end-to-end bearer over the respective
cellular network topology.
o Radio access bearer service: provides confidential transport of
signaling and user data between mobile terminal (MT) and core
network (CN) edge node with the QoS adequate to the negotiated
Bearer Service.
o Core network bearer service: connects the CN edge node with the CN
gateway to the external network, as well as efficiently controls
and utilizes the backbone network in order to provide the
contracted bearer service QoS.
Aspects to enable the QoS at each of these bearer services include
the aspects of control plane, user plane transport and QoS management
functionality.
4.2.1. QoS in 4G Networks
4G mobile network traffic is broadly classified as Control plane
(i.e. signaling) and User plane (i.e. subscriber) traffic. QoS
treatment applies to both control and user plane traffic, regardless
if they are separated or not. Among the various bearer level QoS
management functions in the control plane, translation function
provides conversion between the internal service primitives (i.e.
bearer service attributes) for radio and core network bearer service
Anil Jangam, et al. Expires January 16, 2019 [Page 8]
Internet-Draft July 2018
control and the QoS attributes of the external networks service
control protocol. Other QoS management functions which play an
important role are: service management, admission/capability control,
and subscription control.
Among the QoS management functions at the user plane level, mapping,
classification, resource management and traffic conditioner functions
are of importance. This is all considered at a bearer level, since
all packets within the same bearer receive the same treatment.
Mapping function provides each data unit with the marking required to
receive the intended QoS by a bearer service. Classification service
assigns the data units with an appropriate priority, according to the
QoS related attributes. Traffic conditioner performs the traffic
policing or the traffic shaping according to the related QoS
attributes. The traffic conditioner function discussed here is
analogically similar to what is discussed in Section 4.1.1
The policy and charging control functionality of 3GPP [TS23.203]
among the various other functions, provides the detailed procedures
for QoS control and QoS signaling functions. Please note that it
specifies functionality for unicast bearers only.
The policy control architecture defines more QoS classes used in the
4G mobile networks. They are referred to as QoS Class Identifiers
(QCI) and are scalars that are used as a reference to node specific
parameters that control packet forwarding treatment (e.g. scheduling
weights, admission thresholds, queue management thresholds, link
layer protocol configuration, etc.), and that have been pre-
configured by the operator owning the node (e.g. eNodeB). QCI values
are associated with a set of standard characteristics or attributes.
They are shown in Table 1.
The goal of standardizing a QCI with corresponding characteristics is
to ensure that applications / services mapped to that QCI receive the
same minimum level of QoS in multi-vendor network deployments and in
case of roaming.
Anil Jangam, et al. Expires January 16, 2019 [Page 9]
Internet-Draft July 2018
+-----+----------+----------+-------------+-------------------------+
| QCI | Priority | Pkt | Pkt Error | Service |
| | | Delay | Loss | |
+-----+----------+----------+-------------+-------------------------+
| 1 | 2 | 100ms | 10^-2 | Conversational voice |
| 2 | 4 | 150ms | 10^-3 | Conversational video |
| 3 | 3 | 50ms | 10^-3 | Real-time gaming |
| 4 | 5 | 300ms | 10^-6 | Non-Conversational |
| | | | | Video |
| 5 | 1 | 100ms | 10^-6 | IMS Signaling |
| 6 | 6 | 300ms | 10^-6 | Video (Buffered |
| | | | | Streaming) |
| 7 | 7 | 100ms | 10^-3 | Voice, Video, Live |
| | | | | streaming |
| 8 | 8 | 300ms | 10^-6 | Video (Buffered |
| | | | | Streaming) |
| 9 | 9 | 300ms | 10^-6 | Video (Buffered |
| | | | | Streaming) |
+-----+----------+----------+-------------+-------------------------+
Table 1: QoS Class Identifier for a 4G Network
So far, we discussed how QoS is defined and implemented in 4G mobile
network. In the context of native ICN deployment scenarios in 4G
network as described in [PSUTHAR], it is important that proposed ICN
QoS model supports and interworks with the QCI values listed in
Table 1. We will work out and update, in Section 5.2.3, the exact
protocol specifications to support these additional QoS classes.
4.2.2. QoS in 5G Networks
The 5G mobile network system architecture specified in [TS23.501]
(see section 5.7) describes the QoS identifiers with corresponding
characteristics. We request the reader to refer to [HOMMA] (section
5.5), which briefly describes the QoS model in 5G mobile networks.
The model is based on QoS flows identified by QFI (QoS Flow
Identifier) identifiers. The QFI is similar to the QCI described in
Section 4.2.1. [HOMMA] specifies total of 6-bits space for defining
the QFI in the protocol message. We will require to support at least
this number of bits to support the 5G QoS primitives in ICN based QoS
implementation.
4.3. QoS in hICN
Hybrid-ICN (a.k.a. hICN) is described in [HICN] and a mobile video
delivery application over hybrid-ICN is described in [HICN_VIDEO].
Although these references do not make any explicit comments on the
QoS implementation, we believe they shall support and use the IP
Anil Jangam, et al. Expires January 16, 2019 [Page 10]
Internet-Draft July 2018
based QoS model, described in Section 4.1, since hICN fundamentally
works inside the IP protocol [HICN]. We plan to study in depth about
how QoS would work in case of hICN based network architecture.
5. Supporting QoS in ICN
5.1. DiffServ in ICN
In Section 3.2.1, we discussed the motivation behind implementation
of QoS in ICN as well as discussed how it is relevant and can be
applied in the Data packet traffic path. We know that hop-by-hop
forwarding in CCN/NDN network allows for a name based aggregation of
Interest requests and caching of data at each router node. The per-
hop behavior (PHB) design of DiffServ QoS model, makes it a natural
choice for implementing QoS in CCN/NDN network. DiffServ
architecture [RFC2475] does not describe the use of the DS field as
an input to route selection; however, within the core of the network,
packets are forwarded according to the PHB associated with the DS
codepoint. This behavior of DiffServ provides a value proposition of
using the DS fields in the implementation of forwarding strategies in
CCN/NDN network.
ICN follows a receiver driven, pull based communication model where
an Interest packet is sent by the consumer results with a Data packet
response being sent by the network. From the QoS implementation
perspective, the copy over of the DS field shall happen from the
Interest packet into the corresponding Data packet. This copy over
shall be performed by CCN/NDN router, which finds the requested
content in its local cache or by the origin server (producer) where
the content is originally hosted. As the Data packet with the DS
field information is routed back to the consumer (via name mapped
interface entries in the PIT table), each router in the path shall
use these DS fields to enforce the PHB QoS behavior and meet the
consumer's QoS SLA.
In Section 5.2, we discuss the proposed amendments in the Interest
and Data packets to support the DiffServ DS fields.
5.2. Supporting DiffServ Fields in CCNx Message
5.2.1. Overall CCNx Packet Format
CCNx messages [CCNXMESSAGES] follow a TLV based packet format,
including the TLV types used by each message element and the encoding
of each value. The TLVs use the scheme of fixed 2-byte (16-bit) Type
and a fixed 2-byte (16-bit) Length field. An overall CCNx packet
format is provided below.
Anil Jangam, et al. Expires January 16, 2019 [Page 11]
Internet-Draft July 2018
For detailed description of various header TLVs (fixed and hop-by-
hop), we request to kindly refer to section 3.2 of [CCNXMESSAGES].
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+
| PacketType specific fields | HeaderLength |
+---------------+---------------+---------------+---------------+
/ Optional Hop-by-hop header TLVs /
+---------------+---------------+---------------+---------------+
/ PacketPayload TLVs /
+---------------+---------------+---------------+---------------+
The packet payload is a TLV encoding of the CCNx message, followed by
optional Validation TLVs.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| CCNx Message TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+
Figure 1: Overall CCNx Packet Format
5.2.2. Generic CCNx Message Format
The CCNx message begins with MessageType followed by the optional
Message and Payload TLVs. The same general format is used for both
Interest and Content Object messages, which are differentiated by the
MessageType field.
Anil Jangam, et al. Expires January 16, 2019 [Page 12]
Internet-Draft July 2018
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| Name TLV (Type = T_NAME) |
+---------------+---------------+---------------+---------------+
/ Optional Message TLVs (Various Types) /
+---------------+---------------+---------------+---------------+
/ Optional Payload TLV (Type = T_PAYLOAD) /
+---------------+---------------+---------------+---------------+
Figure 2: Generic CCNx Message Format
5.2.3. DiffServ Fields Message TLV
Interest packet may travel multiple hops until the content requested
by it is found. As described in Section 5.1, it is necessary that DS
field message TLV is carried further into the network until the Data
packet is created. For this reason, we propose to add a new optional
DsField TLV in the CCNx Interest message. The DsField TLV shall be
coped over from the Interest message into the Content Object TLV.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional DsField TLV /
+---------------------------------------------------------------+
Figure 3: DS Field Message TLV
+------------+---------+-----------------------------------+
| Abbrev | Name | Description |
+------------+---------+-----------------------------------+
| T_DS_FIELD | DsField | representation of the DsField TLV |
+------------+---------+-----------------------------------+
Table 2: DS Field Message TLV
The bit-wise structure of the DsField TLV is shown in Figure 4. We
propose to use this TLV to encode the 4G QCI identifiers described in
Anil Jangam, et al. Expires January 16, 2019 [Page 13]
Internet-Draft July 2018
Section 4.2.1 as well as 5G QFI identifiers described in
Section 4.2.2.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_DS_FIELD | 1 byte |
+---------------+---------------+---------------+---------------+
/ |8 bit DS field /
+---------------+---------------+---------------+---------------+
Figure 4: Binary Encoding of DS field TLV
5.2.4. Modified Interest Message TLV
Figure 5 shows the Interest message TLV structure after addition of
the optional DS Field TLV.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional KeyIdRestriction TLV /
+---------------------------------------------------------------+
/ Optional ContentObjectHashRestriction TLV /
+---------------------------------------------------------------+
/ Optional DsField TLV /
+---------------------------------------------------------------+
Figure 5: Modified Interest Message TLV with DS Field TLV
5.2.5. Modified Content Object TLV
Figure 5 shows the modified Content Object TLV structure after
addition of the optional DS Field TLV.
Anil Jangam, et al. Expires January 16, 2019 [Page 14]
Internet-Draft July 2018
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional PayloadType TLV /
+---------------------------------------------------------------+
/ Optional ExpiryTime TLV /
+---------------------------------------------------------------+
/ Optional DsField TLV /
+---------------------------------------------------------------+
Figure 6: Modified Content Object TLV with DS Field TLV
As shown in Figure 5 and Figure 6, the DsField TLV is added to both
Interest and Content object message TLVs.
In Section 5.2 we only present our proposal to support new DiffServ
fields message TLV and discuss about encoding of the TLV in
Section 5.2.3. A detailed investigation and evaluation is required
to understand the applicability of other DiffServ service features
[RFC2475] and how they can be supported in the ICN network in
general. Some of these service features are:
o DiffServ Services Domain
o DiffServ Services Region
o Traffic Classification and Conditioning
o Per-Hop Behaviors
o Network Resource Allocation
6. Empirical Study
This is a work-in-progress activity. To test the proposed CCNx
message modifications in Section 5, we plan to build a prototype
system and evaluate its functional aspects. A tentative progression
of the verification step is given below:
o Implement and test the protocol changes through simulation using
ndnSIM NDN simulator [ndnSIM].
Anil Jangam, et al. Expires January 16, 2019 [Page 15]
Internet-Draft July 2018
o Based on the learning and insight from the simulation study, we
plan to implement a real application setup using [VICN] platform.
7. Security Considerations
This draft proposes extensions to [CCNXMESSAGES] to support DiffServ
based QoS in ICN architecture. ICN being name based networking opens
up new security and privacy considerations which have to be studied
in the context of DiffServ QoS framework. The security
considerations of DiffServ based QoS services are provided in section
6 of [RFC2475].
8. Summary
In this draft, we identified some of the gaps in meeting the end-to-
end QoS requirements in the ICN (CCN/NDN) network architecture. We
presented, through review of some of the peer work, how the
investigations and proposals made so far have not addressed the QoS
in the Data packet delivery path. We provided a reasoning for
similarities between the Data delivery in IP network and in ICN (CCN/
NDN) the need for a differentiated service treatment at each of the
ICN (CCN/NDN) routers. In the end, we briefly summarized the
DiffServ based QoS model and its details.
We presented how DiffServ based QoS mechanism can be used in ICN
(CCN/NDN) network and discussed the amendments in the CCNx protocol
to support the differentiated services code point (DSCP) parameters.
In the end, our conclusion and recommendations are that implementing
DiffServ architecture into ICN (CCN/NDN) architecture is feasible and
can fit the bill. The compatibility of these two architectures
mainly stem from the fact that both these network architectures work
on hop-by-hop basis.
While we have addressed and presented the basic mechanism to achieve
DiffServ based QoS implementation in ICN (CCN/NDN) network in
general, a detailed study is required to understand the applicability
of this design to the other ICN based network adoptions, such as 4G
and 5G mobile networks. While the fundamental principles used in
implementing QoS mechanisms in the mobile networks are the same as IP
based QoS mechanisms, there are certain protocol differences between
the two. We plan to provide a detailed analysis about it in
subsequent revisions.
Security related aspects need further elaboration and study not only
in the context of DiffServ framework, but also from the point of view
of 4G and 5G mobile networks.
Anil Jangam, et al. Expires January 16, 2019 [Page 16]
Internet-Draft July 2018
We intend to implement, through prototype and/or simulation work, the
proposals made in this draft and further prove their practical
feasibility. We would also look forward to do some QoS testing
trials using video streaming applications and measure its
effectiveness in improving the quality of experience.
9. Acknowledgements
We thank all contributors, reviewers and the chairs for their
valuable time in providing the comments and feedback, which has
helped to improve this draft.
10. IANA Considerations
This draft includes no request to IANA.
11. References
11.1. Normative References
[CCNXMESSAGES]
"Marc Mosko et.al., CCNx Messages in TLV Format, ICNRG
Internet-Draft 2018", <https://datatracker.ietf.org/doc/
draft-irtf-icnrg-ccnxmessages/>.
[CCNXSEMANTICS]
"Marc Mosko et.al., CCNx Semantics, ICNRG Internet-Draft
2018", <https://datatracker.ietf.org/doc/
draft-irtf-icnrg-ccnxsemantics/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
Anil Jangam, et al. Expires January 16, 2019 [Page 17]
Internet-Draft July 2018
11.2. Informative References
[CHRISTOS]
"Christos Tsilopoulos et.al., Supporting Diverse Traffic
Types in Information Centric Networks, Proceedings of the
ACM SIGCOMM Workshop on Information-centric Networking,
Pages 13-19, ICN 2011".
[CISCO_VNI]
Cisco Systems, "Cisco Visual Networking Index: Global
Mobile Data Traffic Forecast Update, 2016-2021".
[HICN] Luca Muscariello et.al., "Hybrid Information-Centric
Networking, Internet Area WG, Internet-Draft,
https://datatracker.ietf.org/doc/
draft-muscariello-intarea-hicn", June 2018.
[HICN_VIDEO]
Giovanna Carofiglio et.al., "Mobile Video Delivery with
Hybrid ICN, IP-integrated ICN solution for 5G", February
2017.
[HOMMA] S. Homma et.al., "User Plane Protocol and Architectural
Analysis on 3GPP 5G System, DMM Internet-Draft, 2018,
https://datatracker.ietf.org/doc/
draft-hmm-dmm-5g-uplane-analysis/".
[JACOBSON]
Jacobson, Van et.al, "Networking Named Content, 5th
International Conference on Emerging Networking
Experiments and Technologies, CoNEXT '09, pp. 1-12, 2009".
[KALYANI] "Kalyani Bogineni et.al., Optimized Mobile User Plane
Solutions for 5G, DMM Internet-Draft,
https://datatracker.ietf.org/doc/
draft-bogineni-dmm-optimized-mobile-user-plane/, June
2018".
[MIOSEENKO]
"Moiseenko et.al., Flow Classification in Information
Centric Networking, ICNRG Internet-Draft, February 2017,
https://datatracker.ietf.org/doc/
draft-moiseenko-icnrg-flowclass/".
[NADAY] "M. F. Al-Naday et.al., Quality of service in an
information-centric network, 2014 IEEE Global
Communications Conference GLOCOM.2014, pp. 1861-1866, Dec
2014".
Anil Jangam, et al. Expires January 16, 2019 [Page 18]
Internet-Draft July 2018
[ndnSIM] "ndnSIM: NS-3 based Named Data Networking (NDN)
simulator", <http://ndnsim.net/2.2/>.
[PSUTHAR] "Prakash Suthar et.al., Native Deployment of ICN in LTE,
4G Mobile Networks, ICNRG Internet-Draft, 2018,
https://datatracker.ietf.org/doc/
draft-irtf-icnrg-icn-lte-4g/".
[RAVINDRAN]
"Ravi Ravindran et.al., Enabling ICN in 3GPP's 5G NextGen
Core Architecture, ICNRG Internet-Draft, 2018,
https://datatracker.ietf.org/doc/
draft-ravi-icnrg-5gc-icn/".
[TS23.107]
3GPP, "Quality of Service (QoS) concept and architecture",
3GPP TS 23.107 14.0.0, March 2015.
[TS23.203]
3GPP, "Policy and charging control architecture", 3GPP
TS 23.203 14.9.0, June 2016.
[TS23.501]
3GPP, "System Architecture for the 5G System", 3GPP
TS 23.501 15.2.0, June 2018.
[VICN] "Mauro Sardara et.al., Virtualized ICN (vICN): towards a
unified network virtualization framework for ICN
experimentation, ICN'17 Proceedings of the 4th ACM
Conference on Information-Centric Networking Pages
109-115", <https://wiki.fd.io/view/Vicn>.
[WEIBO] "Weibo Chu et.al., Network delay guarantee for
differentiated services in content-centric networking,
Journal of Computer Communications Volume 76, Pages 54-66,
February 2016".
[XIA] "Xia Yong et.al., Consideration for the Application of
Multi-Service Tag, ICNRG Internet-Draft, October 2017,
https://datatracker.ietf.org/doc/
draft-xia-icn-multiservtag/".
[XINGWEI] "Xingwei Wang et.al., Energy-efficient ICN routing
mechanism with QoS support, Journal of Computer
Communications Volume 131, Pages 38-51, 2018".
Anil Jangam, et al. Expires January 16, 2019 [Page 19]
Internet-Draft July 2018
Authors' Addresses
Anil Jangam
Cisco Systems
3600 Cisco Way
San Jose, California 95134
USA
Email: anjangam@cisco.com
Prakash Suthar
Cisco Systems
9501 Technology Blvd
Rosemont, Illinois 56018
USA
Email: psuthar@cisco.com
Milan Stolic
Cisco Systems
9501 Technology Blvd
Rosemont, Illinois 56018
USA
Email: mistolic@cisco.com
Anil Jangam, et al. Expires January 16, 2019 [Page 20]
