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]