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", . [CCNXSEMANTICS] "Marc Mosko et.al., CCNx Semantics, ICNRG Internet-Draft 2018", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . 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", . [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", . [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]