idnits 2.17.1
draft-anilj-icnrg-icn-qos-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (July 15, 2018) is 2105 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 ICNRG Anil Jangam
3 Internet-Draft Prakash Suthar
4 Intended status: Informational Milan Stolic
5 Expires: January 16, 2019 Cisco Systems
6 July 15, 2018
8 Supporting QoS aware Data Delivery in Information Centric Networks
9 draft-anilj-icnrg-icn-qos-00
11 Abstract
13 Information Centric Networking (ICN) is shaping up as an alternative
14 networking mechanism for the TCP/IP based host-centric networking
15 paradigm. Content delivery or streaming is one of important use
16 cases where the real value and potential of ICN architecture is being
17 investigated. While a number of studies on an optimal and efficient
18 routing of Interest requests have been published, more discussion is
19 needed on the mechanisms for implementation and enforcement of the
20 quality of service (QoS) in the ICN based data delivery path. In
21 this document, we focus on two most popular ICN architectures, CCN
22 (Content Centric Networking) and NDN (Named Data Networking) and
23 describe how we can achieve the QoS aware data delivery in the ICN
24 network. We propose to use the differentiated services (DiffServ)
25 QoS model based on DSCP codes, which is also used in the IP based
26 Internet design. We further present how QoS parameter syntax can be
27 added to the current CCNx messages.
29 Status of This Memo
31 This Internet-Draft is submitted in full conformance with the
32 provisions of BCP 78 and BCP 79.
34 Internet-Drafts are working documents of the Internet Engineering
35 Task Force (IETF). Note that other groups may also distribute
36 working documents as Internet-Drafts. The list of current Internet-
37 Drafts is at https://datatracker.ietf.org/drafts/current/.
39 Internet-Drafts are draft documents valid for a maximum of six months
40 and may be updated, replaced, or obsoleted by other documents at any
41 time. It is inappropriate to use Internet-Drafts as reference
42 material or to cite them other than as "work in progress."
44 This Internet-Draft will expire on January 16, 2019.
46 Copyright Notice
48 Copyright (c) 2018 IETF Trust and the persons identified as the
49 document authors. All rights reserved.
51 This document is subject to BCP 78 and the IETF Trust's Legal
52 Provisions Relating to IETF Documents
53 (https://trustee.ietf.org/license-info) in effect on the date of
54 publication of this document. Please review these documents
55 carefully, as they describe your rights and restrictions with respect
56 to this document. Code Components extracted from this document must
57 include Simplified BSD License text as described in Section 4.e of
58 the Trust Legal Provisions and are provided without warranty as
59 described in the Simplified BSD License.
61 Table of Contents
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
65 3. Prior Work and Motivation . . . . . . . . . . . . . . . . . . 3
66 3.1. Prior Work . . . . . . . . . . . . . . . . . . . . . . . 3
67 3.1.1. Prioritization of Interest Packets . . . . . . . . . 3
68 3.1.2. Flow classification in ICN . . . . . . . . . . . . . 4
69 3.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
70 3.2.1. QoS Perspective in ICN . . . . . . . . . . . . . . . 5
71 3.2.2. ICN Deployments in Mobile Networks . . . . . . . . . 6
72 4. Current QoS Implementations . . . . . . . . . . . . . . . . . 6
73 4.1. QoS in IP Networks . . . . . . . . . . . . . . . . . . . 6
74 4.1.1. Traffic Classification and Marking . . . . . . . . . 7
75 4.2. QoS in Mobile Networks . . . . . . . . . . . . . . . . . 8
76 4.2.1. QoS in 4G Networks . . . . . . . . . . . . . . . . . 8
77 4.2.2. QoS in 5G Networks . . . . . . . . . . . . . . . . . 10
78 4.3. QoS in hICN . . . . . . . . . . . . . . . . . . . . . . . 10
79 5. Supporting QoS in ICN . . . . . . . . . . . . . . . . . . . . 11
80 5.1. DiffServ in ICN . . . . . . . . . . . . . . . . . . . . . 11
81 5.2. Supporting DiffServ Fields in CCNx Message . . . . . . . 11
82 5.2.1. Overall CCNx Packet Format . . . . . . . . . . . . . 11
83 5.2.2. Generic CCNx Message Format . . . . . . . . . . . . . 12
84 5.2.3. DiffServ Fields Message TLV . . . . . . . . . . . . . 13
85 5.2.4. Modified Interest Message TLV . . . . . . . . . . . . 14
86 5.2.5. Modified Content Object TLV . . . . . . . . . . . . . 14
87 6. Empirical Study . . . . . . . . . . . . . . . . . . . . . . . 15
88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
89 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
93 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
94 11.2. Informative References . . . . . . . . . . . . . . . . . 18
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
97 1. Introduction
99 Information Centric Networking (ICN) is a promising network design,
100 where the content is the first class citizen. The content is
101 uniquely identified and addressed by its name. The network follows
102 the Pub-Sub design paradigm using the Interest and Data messages for
103 the communication. The network architecture paves the ways for
104 network traffic optimization by virtue of (1) aggregation of Interest
105 requests initiated for the same content and (2) by caching of the
106 content within the network itself [JACOBSON]. A number of
107 applications and empirical studies have been performed, which
108 establishes the benefits and feasibility of this new network
109 architecture.
111 With the ubiquitous and phenomenal growth of smart mobile devices in
112 recent years, the demand for the Internet and its use has outgrown
113 beyond its traditional use for the transfer of data/file. The
114 availability and support for higher bandwidth due to technological
115 advancements in the networks, the demands and usage patterns of the
116 Internet is changing faster than ever [CISCO_VNI]. According to this
117 report, it is imperative for the service providers to meet the
118 quality of service (QoS) demands of consumers as well as certain
119 types of applications (e.g. VR, AR), and provide a better quality of
120 experience to their users.
122 2. Conventions and Terminology
124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
126 document are to be interpreted as described in [RFC2119].
128 This document uses the terminology of [CCNXSEMANTICS] and
129 [CCNXMESSAGES] for CCNx entities.
131 3. Prior Work and Motivation
133 3.1. Prior Work
135 3.1.1. Prioritization of Interest Packets
137 Among the published research related to meeting the quality of
138 service (QoS) requirements in ICN network, we found that a larger
139 focus and emphasis is given to an optimized and efficient routing of
140 the Interest requests towards the content.
142 M.F. Al-Naday et.al. in [NADAY] attribute the scalability limitation
143 of IP based QoS model to its lack of information awareness in the IP
144 based network; however, they argue that these limitations can be
145 resolved in an ICN like network. In the context of CCN/NDN network
146 design, while authors points to the possibility of using the QoS
147 aware name prefixes, they also comment about the limitations of such
148 approach for the third parties (e.g. network operators) in defining
149 an alternative QoS enforcement mechanisms. Moreover, the QoS
150 solution is developed around the PURSUIT architecture, which may not
151 be applicable to CCN/NDN.
153 Weibo Chu et.al. in [WEIBO] present a QoS model for ICN network based
154 on the popularity ranking of the content and its placement/location
155 in the network. They present a classification of the content into
156 three categories - locally cached, remotely cached, and uncached
157 contents, hence the network delay is modeled as a function of the
158 distance of the content from the requester. Essentially, the QoS
159 problem is tackled in terms of faster routing of Interest request
160 towards its content.
162 In [XINGWEI] authors present a QoS mechanism, which is applicable to
163 the routing of Interest requests in ICN network. The basis of their
164 proposal is to decide the suitability of the forwarding link to make
165 the process more energy efficient. They maintain or use the same
166 Data forwarding algorithm specified in the original NDN design
167 [JACOBSON].
169 Finally, in [CHRISTOS] Christos et.al. argue about a need for a
170 differentiated routing and forwarding mechanisms based on not only
171 the name of the content but also specifying the nature of the
172 traffic. They further emphasize that this differentiation is better
173 handled at the network level rather than leaving it for the upper
174 layer.
176 In all above use cases, we noticed that all QoS related discussions
177 are mainly focused on the forwarding of the Interest requests. The
178 examples we cited above assumes that the Data packets are forwarded,
179 downstream direction, using the interface information recorded in the
180 pending Interest table (PIT). There is little or no discussions
181 provided as to how QoS can be implemented and enforced on the Data
182 packet path.
184 3.1.2. Flow classification in ICN
186 There are at least two prior arts, which describe methods to
187 implement flow classification in ICN.
189 In [MIOSEENKO] author have described two methods for identifying the
190 flow classes using the content name. In the first method, called as
191 equivalence class component count (EC3), they use the predefined
192 number of components from the content name forming an equivalence
193 class. While the approach has the flexibility in re-grouping of
194 components in aggregating the flows, it suffers from the consistent
195 interpretations due to implicit binding of the equivalence class into
196 the content namespace. In second method, called as equivalence class
197 name component type (ECNCT), the flow classification information is
198 directly embedded into the hierarchical content name. This paves the
199 way to achieve implicit or aggregate flow classification similar to
200 prefix based content aggregation. At the forwarder level, a flow
201 table is implemented to store the equivalence classes and used to
202 perform the flow classification decisions.
204 While authors present an idea, in absence of an empirical analysis,
205 it leaves many questions open (e.g. scalability of flow table, name
206 lookup, and publishing of equivalence classes). Also, without a
207 standardized or accepted naming convention, this name based scheme
208 may not be suitable as a basis for flow classification.
210 Xia et.al. in [XIA] state the need of traffic recognition for better
211 network operations; however, due to lake of an efficient flow
212 identification and unified standard for traffic recognition, author
213 propose a multi-service tag based naming scheme similar to
214 hierarchical URI design. They provide a set of guidelines for the
215 design of multi-service tag and a preliminary design of the same;
216 however, the proposed approach does not provide any aspects of
217 practical feasibility.
219 3.2. Motivation
221 3.2.1. QoS Perspective in ICN
223 Using its multipath forwarding capability, CCN/NDN routers forward
224 the Interest message to one or more next-hop interfaces. This
225 provides an opportunity for the router to implement an adaptive
226 forwarding policy and achieve faster and efficient content fetching.
227 In this process, router records the ingress Interface information (on
228 which the Interest request arrived) and maintains the mapping, in the
229 PIT table, between the content name and the Interface. Once the Data
230 packet is received from the upstream router node, this router
231 forwards the Data on the Interface by finding the matching Interface,
232 from the PIT table, using the content name of the Data packet.
234 While there is a flexibility in forwarding the Interest traffic on to
235 multiple next hops (e.g. using multipath forwarding strategy), Data
236 packets are always (or rather must be) forwarded on the Interface
237 recorded in the PIT. This CCN/NDN behavior creates an interesting
238 problem from the QoS perspective - the same (ingress) Interface can
239 now potentially be used for transferring traffic serving multiple
240 content names. There is a contention for sending multiple Data
241 packets on the same interface. At this point, the forwarding of Data
242 packet traffic also becomes the problem of scheduling of traffic. In
243 [CHRISTOS] we saw that by the very nature of type of traffic, a
244 differentiated traffic handling is necessary to ensure appropriate
245 QoS is achieved.
247 3.2.2. ICN Deployments in Mobile Networks
249 A number of proposals have been submitted describing the use and
250 deployment of ICN in 4G and 5G mobile networks. In [PSUTHAR]
251 P.Suthar et.al. described the native deployment of ICN and dual stack
252 deployment (IP and ICN) in distinct parts of 4G/LTE network, such as
253 user plane, UE, eNodeB, and core network (SGW and PGW). In
254 [RAVINDRAN] Ravi Ravindran et.al. have described the ICN based
255 extensions to 5G control and user plane to support packet data unit
256 (PDU) sessions. Lastly, [KALYANI] described the use of hICN (Hybrid
257 ICN) in management of mobility in 5G networks.
259 An important takeaway from these ICN deployment examples is that it
260 opens up scope for extending ICN specific QoS features proposed in
261 this draft and also provides an opportunity for interoperability
262 between the QoS mechanisms used in 4G, 5G mobile networks and the
263 proposed ICN QoS mechanisms. These topics need further
264 investigations.
266 4. Current QoS Implementations
268 4.1. QoS in IP Networks
270 Differentiated services or DiffServ [RFC2475] is one of the highly
271 deployed and preferred L3 QoS mechanisms over other mechanisms, such
272 as Integrated Services or IntServ. DiffServ works on the premise
273 that the traffic classification marking is performed at the edge of
274 the network whereas the core network router only acts on the QoS
275 marked packets and performs packet forwarding and scheduling. Each
276 DiffServ-aware network router (or a set of routers in a DiffServ
277 domain) implements a common per-hop behaviors (PHBs) that defines the
278 packet-forwarding properties associated with a class of traffic.
280 DiffServ specify a simple and scalable quality of service (QoS)
281 architecture based on the principle of traffic classification. This
282 traffic classification is achieved by using a 6-bit differentiated
283 services code point (DSCP) in the 8-bit differentiated services field
284 (DS field) in the IP header [RFC2474].
286 In the scope of this draft proposal, we mainly focus on the DiffServ
287 based QoS model and do not explore into the applicability of IntServ
288 QoS model to this work. In future revisions, we shall investigate
289 the use of IntServ as needed.
291 4.1.1. Traffic Classification and Marking
293 The traffic classification and PHB is determined by a 6-bit
294 differentiated services code point (DSCP) in the differentiated
295 services field (DS field) of the IP header [RFC2474]. On the ingress
296 router at the DiffServ domain, a specific traffic class is assigned
297 based on various parameters, such as source address, destination
298 address or traffic type (e.g. audio, video). By virtue of the 6-bit
299 field a total of 64 (2^6) classifications are possible at the network
300 router; however, for more practical purposes, following 4 classes are
301 typically used by the network routers.
303 o Default forwarding (DF): this is the default forwarding
304 classification provides the best-effort forwarding
305 characteristics.
307 o Expedited forwarding (EF): as its name suggests, this forwarding
308 classification provides the low delay, low loss and low jitter
309 forwarding characteristics. These are typically suitable for
310 real-time traffic. To avoid any adverse effect of overuse of this
311 class, the EF traffic classification is performed through a
312 stricter admission policy control mechanism.
314 o Assured forwarding (AF): this forwarding classification provides
315 the assurance of the packet delivery under a configured threshold
316 levels of traffic. Beyond this threshold level, network routers
317 may choose to drop the packet traffic when congestion is detected.
318 Within the three levels of drop probabilities (low, medium, and
319 high), a further sub-classification is achieved by 4 different
320 sub-classes. Thus, total 12 classes are possible using AF
321 classification. Within the given drop probability, the traffic
322 with the higher sub-class assignment is given priority over the
323 others. Similarly, within the same sub-class, the packets with
324 higher drop probability are dropped first over the others.
326 o Class selectors (CS): provides the backward compatibility with the
327 IP Precedence field in the TOS byte of the IP header. It has been
328 widely accepted to use the TOS octet as the DS field for DiffServ
329 networks; however, CS classification is used to process the
330 packets received from a non-DiffServ aware router.
332 In DiffServ model, the end-to-end QoS behavior is still unpredictable
333 as the PHB behavior of each router in the DiffServ domain depends on
334 configuration at each router. This end-to-end QoS behavior is
335 further complicated if the packet has to traverse multiple DiffServ
336 domains. Thus any QoS marking or classification does not guarantee
337 the QoS as such. Sender can only expect that network provides the
338 QoS indicated by it.
340 4.2. QoS in Mobile Networks
342 Applicability and use of ICN in mobile networks is briefly discussed
343 in Section 3.2.2. Therefore, in the context of this draft, it
344 becomes important to understand how QoS is implemented in mobile
345 networks today, and this section provides an overview of that
346 implementation. In subsequent section, we shall see how ICN based
347 QoS mechanisms can provide an end-to-end QoS service to the mobile
348 network users.
350 3rd Generation Partnership Project (3GPP) specification [TS23.107]
351 describes the framework for QoS within the 3GPP system applicable to
352 4G/LTE networks. It specifies the list of attributes applicable to
353 the end-to-end bearer service, as well as describes the QoS
354 architecture to be used in the 3GPP system. In a typical case, a
355 user session is established in two parts and each of these provides
356 an optimized way to realize end-to-end bearer over the respective
357 cellular network topology.
359 o Radio access bearer service: provides confidential transport of
360 signaling and user data between mobile terminal (MT) and core
361 network (CN) edge node with the QoS adequate to the negotiated
362 Bearer Service.
364 o Core network bearer service: connects the CN edge node with the CN
365 gateway to the external network, as well as efficiently controls
366 and utilizes the backbone network in order to provide the
367 contracted bearer service QoS.
369 Aspects to enable the QoS at each of these bearer services include
370 the aspects of control plane, user plane transport and QoS management
371 functionality.
373 4.2.1. QoS in 4G Networks
375 4G mobile network traffic is broadly classified as Control plane
376 (i.e. signaling) and User plane (i.e. subscriber) traffic. QoS
377 treatment applies to both control and user plane traffic, regardless
378 if they are separated or not. Among the various bearer level QoS
379 management functions in the control plane, translation function
380 provides conversion between the internal service primitives (i.e.
381 bearer service attributes) for radio and core network bearer service
382 control and the QoS attributes of the external networks service
383 control protocol. Other QoS management functions which play an
384 important role are: service management, admission/capability control,
385 and subscription control.
387 Among the QoS management functions at the user plane level, mapping,
388 classification, resource management and traffic conditioner functions
389 are of importance. This is all considered at a bearer level, since
390 all packets within the same bearer receive the same treatment.
391 Mapping function provides each data unit with the marking required to
392 receive the intended QoS by a bearer service. Classification service
393 assigns the data units with an appropriate priority, according to the
394 QoS related attributes. Traffic conditioner performs the traffic
395 policing or the traffic shaping according to the related QoS
396 attributes. The traffic conditioner function discussed here is
397 analogically similar to what is discussed in Section 4.1.1
399 The policy and charging control functionality of 3GPP [TS23.203]
400 among the various other functions, provides the detailed procedures
401 for QoS control and QoS signaling functions. Please note that it
402 specifies functionality for unicast bearers only.
404 The policy control architecture defines more QoS classes used in the
405 4G mobile networks. They are referred to as QoS Class Identifiers
406 (QCI) and are scalars that are used as a reference to node specific
407 parameters that control packet forwarding treatment (e.g. scheduling
408 weights, admission thresholds, queue management thresholds, link
409 layer protocol configuration, etc.), and that have been pre-
410 configured by the operator owning the node (e.g. eNodeB). QCI values
411 are associated with a set of standard characteristics or attributes.
412 They are shown in Table 1.
414 The goal of standardizing a QCI with corresponding characteristics is
415 to ensure that applications / services mapped to that QCI receive the
416 same minimum level of QoS in multi-vendor network deployments and in
417 case of roaming.
419 +-----+----------+----------+-------------+-------------------------+
420 | QCI | Priority | Pkt | Pkt Error | Service |
421 | | | Delay | Loss | |
422 +-----+----------+----------+-------------+-------------------------+
423 | 1 | 2 | 100ms | 10^-2 | Conversational voice |
424 | 2 | 4 | 150ms | 10^-3 | Conversational video |
425 | 3 | 3 | 50ms | 10^-3 | Real-time gaming |
426 | 4 | 5 | 300ms | 10^-6 | Non-Conversational |
427 | | | | | Video |
428 | 5 | 1 | 100ms | 10^-6 | IMS Signaling |
429 | 6 | 6 | 300ms | 10^-6 | Video (Buffered |
430 | | | | | Streaming) |
431 | 7 | 7 | 100ms | 10^-3 | Voice, Video, Live |
432 | | | | | streaming |
433 | 8 | 8 | 300ms | 10^-6 | Video (Buffered |
434 | | | | | Streaming) |
435 | 9 | 9 | 300ms | 10^-6 | Video (Buffered |
436 | | | | | Streaming) |
437 +-----+----------+----------+-------------+-------------------------+
439 Table 1: QoS Class Identifier for a 4G Network
441 So far, we discussed how QoS is defined and implemented in 4G mobile
442 network. In the context of native ICN deployment scenarios in 4G
443 network as described in [PSUTHAR], it is important that proposed ICN
444 QoS model supports and interworks with the QCI values listed in
445 Table 1. We will work out and update, in Section 5.2.3, the exact
446 protocol specifications to support these additional QoS classes.
448 4.2.2. QoS in 5G Networks
450 The 5G mobile network system architecture specified in [TS23.501]
451 (see section 5.7) describes the QoS identifiers with corresponding
452 characteristics. We request the reader to refer to [HOMMA] (section
453 5.5), which briefly describes the QoS model in 5G mobile networks.
454 The model is based on QoS flows identified by QFI (QoS Flow
455 Identifier) identifiers. The QFI is similar to the QCI described in
456 Section 4.2.1. [HOMMA] specifies total of 6-bits space for defining
457 the QFI in the protocol message. We will require to support at least
458 this number of bits to support the 5G QoS primitives in ICN based QoS
459 implementation.
461 4.3. QoS in hICN
463 Hybrid-ICN (a.k.a. hICN) is described in [HICN] and a mobile video
464 delivery application over hybrid-ICN is described in [HICN_VIDEO].
465 Although these references do not make any explicit comments on the
466 QoS implementation, we believe they shall support and use the IP
467 based QoS model, described in Section 4.1, since hICN fundamentally
468 works inside the IP protocol [HICN]. We plan to study in depth about
469 how QoS would work in case of hICN based network architecture.
471 5. Supporting QoS in ICN
473 5.1. DiffServ in ICN
475 In Section 3.2.1, we discussed the motivation behind implementation
476 of QoS in ICN as well as discussed how it is relevant and can be
477 applied in the Data packet traffic path. We know that hop-by-hop
478 forwarding in CCN/NDN network allows for a name based aggregation of
479 Interest requests and caching of data at each router node. The per-
480 hop behavior (PHB) design of DiffServ QoS model, makes it a natural
481 choice for implementing QoS in CCN/NDN network. DiffServ
482 architecture [RFC2475] does not describe the use of the DS field as
483 an input to route selection; however, within the core of the network,
484 packets are forwarded according to the PHB associated with the DS
485 codepoint. This behavior of DiffServ provides a value proposition of
486 using the DS fields in the implementation of forwarding strategies in
487 CCN/NDN network.
489 ICN follows a receiver driven, pull based communication model where
490 an Interest packet is sent by the consumer results with a Data packet
491 response being sent by the network. From the QoS implementation
492 perspective, the copy over of the DS field shall happen from the
493 Interest packet into the corresponding Data packet. This copy over
494 shall be performed by CCN/NDN router, which finds the requested
495 content in its local cache or by the origin server (producer) where
496 the content is originally hosted. As the Data packet with the DS
497 field information is routed back to the consumer (via name mapped
498 interface entries in the PIT table), each router in the path shall
499 use these DS fields to enforce the PHB QoS behavior and meet the
500 consumer's QoS SLA.
502 In Section 5.2, we discuss the proposed amendments in the Interest
503 and Data packets to support the DiffServ DS fields.
505 5.2. Supporting DiffServ Fields in CCNx Message
507 5.2.1. Overall CCNx Packet Format
509 CCNx messages [CCNXMESSAGES] follow a TLV based packet format,
510 including the TLV types used by each message element and the encoding
511 of each value. The TLVs use the scheme of fixed 2-byte (16-bit) Type
512 and a fixed 2-byte (16-bit) Length field. An overall CCNx packet
513 format is provided below.
515 For detailed description of various header TLVs (fixed and hop-by-
516 hop), we request to kindly refer to section 3.2 of [CCNXMESSAGES].
518 1 2 3
519 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
520 +---------------+---------------+---------------+---------------+
521 | Version | PacketType | PacketLength |
522 +---------------+---------------+---------------+---------------+
523 | PacketType specific fields | HeaderLength |
524 +---------------+---------------+---------------+---------------+
525 / Optional Hop-by-hop header TLVs /
526 +---------------+---------------+---------------+---------------+
527 / PacketPayload TLVs /
528 +---------------+---------------+---------------+---------------+
530 The packet payload is a TLV encoding of the CCNx message, followed by
531 optional Validation TLVs.
533 1 2 3
534 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
535 +---------------+---------------+---------------+---------------+
536 | CCNx Message TLV /
537 +---------------+---------------+---------------+---------------+
538 / Optional CCNx ValidationAlgorithm TLV /
539 +---------------+---------------+---------------+---------------+
540 / Optional CCNx ValidationPayload TLV (ValidationAlg required) /
541 +---------------+---------------+---------------+---------------+
543 Figure 1: Overall CCNx Packet Format
545 5.2.2. Generic CCNx Message Format
547 The CCNx message begins with MessageType followed by the optional
548 Message and Payload TLVs. The same general format is used for both
549 Interest and Content Object messages, which are differentiated by the
550 MessageType field.
552 1 2 3
553 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
554 +---------------+---------------+---------------+---------------+
555 | MessageType | MessageLength |
556 +---------------+---------------+---------------+---------------+
557 | Name TLV (Type = T_NAME) |
558 +---------------+---------------+---------------+---------------+
559 / Optional Message TLVs (Various Types) /
560 +---------------+---------------+---------------+---------------+
561 / Optional Payload TLV (Type = T_PAYLOAD) /
562 +---------------+---------------+---------------+---------------+
564 Figure 2: Generic CCNx Message Format
566 5.2.3. DiffServ Fields Message TLV
568 Interest packet may travel multiple hops until the content requested
569 by it is found. As described in Section 5.1, it is necessary that DS
570 field message TLV is carried further into the network until the Data
571 packet is created. For this reason, we propose to add a new optional
572 DsField TLV in the CCNx Interest message. The DsField TLV shall be
573 coped over from the Interest message into the Content Object TLV.
575 1 2 3
576 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
577 +---------------+---------------+---------------+---------------+
578 | MessageType | MessageLength |
579 +---------------+---------------+---------------+---------------+
580 | Name TLV |
581 +---------------+---------------+---------------+---------------+
582 / Optional DsField TLV /
583 +---------------------------------------------------------------+
585 Figure 3: DS Field Message TLV
587 +------------+---------+-----------------------------------+
588 | Abbrev | Name | Description |
589 +------------+---------+-----------------------------------+
590 | T_DS_FIELD | DsField | representation of the DsField TLV |
591 +------------+---------+-----------------------------------+
593 Table 2: DS Field Message TLV
595 The bit-wise structure of the DsField TLV is shown in Figure 4. We
596 propose to use this TLV to encode the 4G QCI identifiers described in
597 Section 4.2.1 as well as 5G QFI identifiers described in
598 Section 4.2.2.
600 1 2 3
601 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
602 +---------------+---------------+---------------+---------------+
603 | T_DS_FIELD | 1 byte |
604 +---------------+---------------+---------------+---------------+
605 / |8 bit DS field /
606 +---------------+---------------+---------------+---------------+
608 Figure 4: Binary Encoding of DS field TLV
610 5.2.4. Modified Interest Message TLV
612 Figure 5 shows the Interest message TLV structure after addition of
613 the optional DS Field TLV.
615 1 2 3
616 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
617 +---------------+---------------+---------------+---------------+
618 | MessageType | MessageLength |
619 +---------------+---------------+---------------+---------------+
620 | Name TLV |
621 +---------------+---------------+---------------+---------------+
622 / Optional KeyIdRestriction TLV /
623 +---------------------------------------------------------------+
624 / Optional ContentObjectHashRestriction TLV /
625 +---------------------------------------------------------------+
626 / Optional DsField TLV /
627 +---------------------------------------------------------------+
629 Figure 5: Modified Interest Message TLV with DS Field TLV
631 5.2.5. Modified Content Object TLV
633 Figure 5 shows the modified Content Object TLV structure after
634 addition of the optional DS Field TLV.
636 1 2 3
637 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
638 +---------------+---------------+---------------+---------------+
639 | MessageType | MessageLength |
640 +---------------+---------------+---------------+---------------+
641 | Name TLV |
642 +---------------+---------------+---------------+---------------+
643 / Optional PayloadType TLV /
644 +---------------------------------------------------------------+
645 / Optional ExpiryTime TLV /
646 +---------------------------------------------------------------+
647 / Optional DsField TLV /
648 +---------------------------------------------------------------+
650 Figure 6: Modified Content Object TLV with DS Field TLV
652 As shown in Figure 5 and Figure 6, the DsField TLV is added to both
653 Interest and Content object message TLVs.
655 In Section 5.2 we only present our proposal to support new DiffServ
656 fields message TLV and discuss about encoding of the TLV in
657 Section 5.2.3. A detailed investigation and evaluation is required
658 to understand the applicability of other DiffServ service features
659 [RFC2475] and how they can be supported in the ICN network in
660 general. Some of these service features are:
662 o DiffServ Services Domain
664 o DiffServ Services Region
666 o Traffic Classification and Conditioning
668 o Per-Hop Behaviors
670 o Network Resource Allocation
672 6. Empirical Study
674 This is a work-in-progress activity. To test the proposed CCNx
675 message modifications in Section 5, we plan to build a prototype
676 system and evaluate its functional aspects. A tentative progression
677 of the verification step is given below:
679 o Implement and test the protocol changes through simulation using
680 ndnSIM NDN simulator [ndnSIM].
682 o Based on the learning and insight from the simulation study, we
683 plan to implement a real application setup using [VICN] platform.
685 7. Security Considerations
687 This draft proposes extensions to [CCNXMESSAGES] to support DiffServ
688 based QoS in ICN architecture. ICN being name based networking opens
689 up new security and privacy considerations which have to be studied
690 in the context of DiffServ QoS framework. The security
691 considerations of DiffServ based QoS services are provided in section
692 6 of [RFC2475].
694 8. Summary
696 In this draft, we identified some of the gaps in meeting the end-to-
697 end QoS requirements in the ICN (CCN/NDN) network architecture. We
698 presented, through review of some of the peer work, how the
699 investigations and proposals made so far have not addressed the QoS
700 in the Data packet delivery path. We provided a reasoning for
701 similarities between the Data delivery in IP network and in ICN (CCN/
702 NDN) the need for a differentiated service treatment at each of the
703 ICN (CCN/NDN) routers. In the end, we briefly summarized the
704 DiffServ based QoS model and its details.
706 We presented how DiffServ based QoS mechanism can be used in ICN
707 (CCN/NDN) network and discussed the amendments in the CCNx protocol
708 to support the differentiated services code point (DSCP) parameters.
709 In the end, our conclusion and recommendations are that implementing
710 DiffServ architecture into ICN (CCN/NDN) architecture is feasible and
711 can fit the bill. The compatibility of these two architectures
712 mainly stem from the fact that both these network architectures work
713 on hop-by-hop basis.
715 While we have addressed and presented the basic mechanism to achieve
716 DiffServ based QoS implementation in ICN (CCN/NDN) network in
717 general, a detailed study is required to understand the applicability
718 of this design to the other ICN based network adoptions, such as 4G
719 and 5G mobile networks. While the fundamental principles used in
720 implementing QoS mechanisms in the mobile networks are the same as IP
721 based QoS mechanisms, there are certain protocol differences between
722 the two. We plan to provide a detailed analysis about it in
723 subsequent revisions.
725 Security related aspects need further elaboration and study not only
726 in the context of DiffServ framework, but also from the point of view
727 of 4G and 5G mobile networks.
729 We intend to implement, through prototype and/or simulation work, the
730 proposals made in this draft and further prove their practical
731 feasibility. We would also look forward to do some QoS testing
732 trials using video streaming applications and measure its
733 effectiveness in improving the quality of experience.
735 9. Acknowledgements
737 We thank all contributors, reviewers and the chairs for their
738 valuable time in providing the comments and feedback, which has
739 helped to improve this draft.
741 10. IANA Considerations
743 This draft includes no request to IANA.
745 11. References
747 11.1. Normative References
749 [CCNXMESSAGES]
750 "Marc Mosko et.al., CCNx Messages in TLV Format, ICNRG
751 Internet-Draft 2018", .
754 [CCNXSEMANTICS]
755 "Marc Mosko et.al., CCNx Semantics, ICNRG Internet-Draft
756 2018", .
759 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
760 Requirement Levels", BCP 14, RFC 2119,
761 DOI 10.17487/RFC2119, March 1997,
762 .
764 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
765 "Definition of the Differentiated Services Field (DS
766 Field) in the IPv4 and IPv6 Headers", RFC 2474,
767 DOI 10.17487/RFC2474, December 1998,
768 .
770 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
771 and W. Weiss, "An Architecture for Differentiated
772 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
773 .
775 11.2. Informative References
777 [CHRISTOS]
778 "Christos Tsilopoulos et.al., Supporting Diverse Traffic
779 Types in Information Centric Networks, Proceedings of the
780 ACM SIGCOMM Workshop on Information-centric Networking,
781 Pages 13-19, ICN 2011".
783 [CISCO_VNI]
784 Cisco Systems, "Cisco Visual Networking Index: Global
785 Mobile Data Traffic Forecast Update, 2016-2021".
787 [HICN] Luca Muscariello et.al., "Hybrid Information-Centric
788 Networking, Internet Area WG, Internet-Draft,
789 https://datatracker.ietf.org/doc/
790 draft-muscariello-intarea-hicn", June 2018.
792 [HICN_VIDEO]
793 Giovanna Carofiglio et.al., "Mobile Video Delivery with
794 Hybrid ICN, IP-integrated ICN solution for 5G", February
795 2017.
797 [HOMMA] S. Homma et.al., "User Plane Protocol and Architectural
798 Analysis on 3GPP 5G System, DMM Internet-Draft, 2018,
799 https://datatracker.ietf.org/doc/
800 draft-hmm-dmm-5g-uplane-analysis/".
802 [JACOBSON]
803 Jacobson, Van et.al, "Networking Named Content, 5th
804 International Conference on Emerging Networking
805 Experiments and Technologies, CoNEXT '09, pp. 1-12, 2009".
807 [KALYANI] "Kalyani Bogineni et.al., Optimized Mobile User Plane
808 Solutions for 5G, DMM Internet-Draft,
809 https://datatracker.ietf.org/doc/
810 draft-bogineni-dmm-optimized-mobile-user-plane/, June
811 2018".
813 [MIOSEENKO]
814 "Moiseenko et.al., Flow Classification in Information
815 Centric Networking, ICNRG Internet-Draft, February 2017,
816 https://datatracker.ietf.org/doc/
817 draft-moiseenko-icnrg-flowclass/".
819 [NADAY] "M. F. Al-Naday et.al., Quality of service in an
820 information-centric network, 2014 IEEE Global
821 Communications Conference GLOCOM.2014, pp. 1861-1866, Dec
822 2014".
824 [ndnSIM] "ndnSIM: NS-3 based Named Data Networking (NDN)
825 simulator", .
827 [PSUTHAR] "Prakash Suthar et.al., Native Deployment of ICN in LTE,
828 4G Mobile Networks, ICNRG Internet-Draft, 2018,
829 https://datatracker.ietf.org/doc/
830 draft-irtf-icnrg-icn-lte-4g/".
832 [RAVINDRAN]
833 "Ravi Ravindran et.al., Enabling ICN in 3GPP's 5G NextGen
834 Core Architecture, ICNRG Internet-Draft, 2018,
835 https://datatracker.ietf.org/doc/
836 draft-ravi-icnrg-5gc-icn/".
838 [TS23.107]
839 3GPP, "Quality of Service (QoS) concept and architecture",
840 3GPP TS 23.107 14.0.0, March 2015.
842 [TS23.203]
843 3GPP, "Policy and charging control architecture", 3GPP
844 TS 23.203 14.9.0, June 2016.
846 [TS23.501]
847 3GPP, "System Architecture for the 5G System", 3GPP
848 TS 23.501 15.2.0, June 2018.
850 [VICN] "Mauro Sardara et.al., Virtualized ICN (vICN): towards a
851 unified network virtualization framework for ICN
852 experimentation, ICN'17 Proceedings of the 4th ACM
853 Conference on Information-Centric Networking Pages
854 109-115", .
856 [WEIBO] "Weibo Chu et.al., Network delay guarantee for
857 differentiated services in content-centric networking,
858 Journal of Computer Communications Volume 76, Pages 54-66,
859 February 2016".
861 [XIA] "Xia Yong et.al., Consideration for the Application of
862 Multi-Service Tag, ICNRG Internet-Draft, October 2017,
863 https://datatracker.ietf.org/doc/
864 draft-xia-icn-multiservtag/".
866 [XINGWEI] "Xingwei Wang et.al., Energy-efficient ICN routing
867 mechanism with QoS support, Journal of Computer
868 Communications Volume 131, Pages 38-51, 2018".
870 Authors' Addresses
872 Anil Jangam
873 Cisco Systems
874 3600 Cisco Way
875 San Jose, California 95134
876 USA
878 Email: anjangam@cisco.com
880 Prakash Suthar
881 Cisco Systems
882 9501 Technology Blvd
883 Rosemont, Illinois 56018
884 USA
886 Email: psuthar@cisco.com
888 Milan Stolic
889 Cisco Systems
890 9501 Technology Blvd
891 Rosemont, Illinois 56018
892 USA
894 Email: mistolic@cisco.com