idnits 2.17.1 draft-zhang-icn-uscamulsertag-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 'Intended status' indicated for this document; assuming Proposed Standard 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 (March 2019) is 1859 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 N Working Group 2 Internet Draft Zhang Wei 3 Document: draft-zhang-icn-uscamulsertag-00.txt He Jing 4 Expires: September 11, 2019 China SAPPRFT 5 March 2019 7 the Use Cases for the Application of Multi-Service Tag 8 draft-zhang-icn-uscamulsertag-00 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF). Note that other groups may also distribute 17 working documents as Internet-Drafts. The list of current Internet- 18 Drafts is at https://datatracker.ietf.org/drafts/current/. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 This Internet-Draft will expire on Nov 11, 2019. 27 Abstract 29 Based on the important concepts and research challenges described in 30 RFC 7927, we consider multi-service tagging technology to be an 31 effective name mechanism for audio and video content in ICN. Since 32 audio and video traffic is the primary traffic transmitted over the 33 Internet, it will greatly advance the current Internet architecture 34 to the ICN architecture, the name mechanism for creating audio and 35 video content. This article discusses typical cases of improvements 36 using name mechanisms, including content resource exchange between 37 different ISPs, resource caching of content naming information, and 38 data distribution for different transmission quality requirements in 39 low latency environments. 41 Conventions used in this document 43 In examples, "C:" and "S:" indicate lines sent by the client and 44 server respectively. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119 [i]. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. 62 Table of Contents 64 1. Introduction...................................................2 65 2. Terminology and Acronyms.......................................3 66 3. Use cases......................................................3 67 3.1 content resource sharing across ISP network................3 68 3.2 cache according to the content naming information..........4 69 3.3 Media transmission for different latency levels............4 70 Security Considerations...........................................5 71 IANA Considerations...............................................5 72 References........................................................5 73 Author's Addresses................................................5 75 1. Introduction 76 Now the network traffic presents a rapid increase trend, the 77 popularization of network audio and video and the diversified viewing 78 model modes support watch audio and video in anytime and 79 anywhere,which also results in the increase of network traffic. The 80 network audio and video Apps must provide terrific Quality of 81 experience(QoE). These trends represent a developing direction of 82 future networks. Recognition and handling of the application traffic 83 is a key factor for network operation. Each network application uses 84 different protocol and is deployed by different ISP, which 85 incompletely depends on the network operaters. The method of the 86 recognition of traffic and applications uses the fuzzy heuristic 87 modes which are based on the port scope and key information of the 88 traffic and are similar with the DPI technology, but this series of 89 technologies have some limitations. The heuristic methods can't 90 effectively solve the problem of traffic recognition 91 because they can't keep up with the synchronization update of 92 application characteristics. The traffic recognition schemes based on 93 the port scope detection face the great challenge because of enormous 94 amount of ports which are discontinuous, especially for http traffic, 95 the http traffic usually use 80 or 8080 port, so the content in http 96 traffic is difficult to be identified accurately. Due to the 97 encryption transmission of more and more traffic, these lead to the 98 great increase of DFI/DPI calculated amount and make these two 99 technologies be faced with invalidation. IP tunneling technology 100 makes the operator's network more complex. So we need a new 101 technology which can rapidly and uniquely recognize the traffic based 102 on its characteristics without resolve the whole package. 104 2. Terminology and Acronyms 106 This document makes use of the same terminology and definitions as 107 RFC 7927 [RFC7927]. In addition it uses the terms defined 108 below: 110 Multi-Service Tag: uses the tag field in each packet header to 111 mark packets according to their service class so that the network can 112 easily recognize packets that need to be treated preferentially. 114 3. Use cases 115 3.1 content resource sharing across ISP network 117 The Internet audio and video transmission usually uses the CDN 118 technology and cache technology to provide service for users and the 119 CP will deploy the CDN or cache nodes according to the user 120 distribution in the operator network. In order to guarantee QoE, the 121 CP will deploy CDN nodes with full resource in the network center and 122 CDN nodes with hot resource at the network edge which usually locate 123 in the operator's premises network. Each premises network operator 124 has its own IP address field and the user's IP address is allocated 125 by the premises network operator. In the current IP network, the CP 126 can find the nearest resource only according to the IP address in the 127 inquiry and then schedule the corresponding CDN node to serve the 128 user, if the edge CDN node has no the resource asked by the user, the 129 CP will haul the user inquiry back to the center CDN nodes with full 130 resource and schedule the corresponding resource to serve the user, 131 and this can easily form the network congestion of ISP haul-back 132 route and increase the network delay. Though the different ISP 133 premises networks have routing reachability, the content resource 134 can't be sharing among different IPS. 136 Under the audio and video scheduling mechanism based on the IP 137 address, IP address will fragment the network resource and the same 138 content will have many IP address or URL, thus CP or ISP have to use 139 large storage resource to deploy the same hot content. IP address and 140 URL are all the network address information independent of the 141 content and the operator can't share the content through the address 142 information. 144 In ICN, we can use the multi-service tag naming scheme to realize the 145 content resource sharing among ISPs and form larger content resource 146 sharing pool, thus all user can acquire the content in the pool and 147 it breaks the IP-ISP resource closed mechanism. The multi-service tag 148 assembly modular can acquire all ISP network resource information and 149 the user can use this information to find the relevant content. 151 3.2 cache according to the content naming information 153 The cache technology is always one of the main technological means 154 for decreasing inter-network settlement charge and enhancing QoE. The 155 maximal challenge which the traditional cache technology faces is 156 that the repetitive contents waste the cache resource. The core 157 technology of the traditional cache is to obtain URL contents and 158 store them locally by monitoring the hot program's URLs through DPI. 159 But the URL is not stable and the same contents may have different 160 URLs. Though we can use DPI to decode the content and acquire partial 161 content characteristics to compare, it has major limitations at 162 decreasing the repetitive contents and greatly increases the 163 computation complexity, what is more, the begin of the content is 164 often advertisement or station caption and this makes content 165 comparison different to work well. The multi-service tag contains the 166 attribute information of carried content which is one-to-one 167 correspondence to the content, then the cache system can use the tag 168 as the base of comparison so as to quickly discover the repetitive 169 contents and raise cache efficiency. 171 3.3 Media transmission for different latency levels 172 In some organizations, such as audio station or television station, 173 there are both unscheduled non-real-time traffic and different levels 174 of time-sensitive media traffic, which have different transmission 175 priorities. With the DiffServ method [RFC3260], the device uses the 176 appropriate DSCP value to flag the outgoing traffic, but note that 177 DiffServ is a coarse-grained QoS architecture that handles traffic 178 traffic by category rather than individual traffic. As in an audio 179 and video stream, the priority of audio and video streams should be 180 consistent, different media streams, audio and video media streams 181 (such as multicast) with low transmission delay requirements, and 182 media streams required for normal transmission delays (such as media 183 streams migration in different unit). The QoS level of the migration 184 needs to be distinguished by the name service to avoid the low 185 transmission delay audio and video media stream cannot meet the 186 transmission delay requirement due to the same service priority media 187 profile. 189 Multi-service tag identify traffic levels through content tag. The 190 tag value is assigned by the server that generates the traffic 191 according to certain rules. The transmission interaction device can 192 adopt multiple content transmission selection algorithms according to 193 the label value, and a more general one is a strict priority 194 algorithm. According to this algorithm, the oldest data packet is 195 selected for transmission from a non-empty queue with a higher 196 priority. Therefore, high-priority audio and video traffic will have 197 the lowest latency, while lower-priority audio and video traffic may 198 result in longer transmission delays and even timeouts. This hunger 199 state can be achieved through more complex selection algorithms, but 200 with high priority traffic latency will become higher. 202 4. Security Considerations 204 This document has no security considerations. 206 5. IANA Considerations 208 There is no IANA action in this document. 210 6. References 211 6.1 Normative References 212 TBD 214 6.2 Informative References 215 [RFC7927] D. Kutscher, S., "Information-Centric Networking (ICN) 216 Research Challenges", RFC 7927, July 2016, 217 219 [RFC3260] D. Grossman, "New Terminology and Clarifications for 220 Diffserv", RFC 3260, April 2002, 223 Author's Addresses 225 Zhang Wei 226 China SAPPRFT 227 Email: zhangwei@abs.ac.cn 229 He Jing 230 China SAPPRFT 231 Email: hejing@abs.ac.cn