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