idnits 2.17.1 draft-moiseenko-icnrg-flowclass-05.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 (January 20, 2020) is 1530 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 I. Moiseenko 3 Internet-Draft Apple Computer 4 Intended status: Informational D. Oran 5 Expires: July 23, 2020 Network Systems Research and Design 6 January 20, 2020 8 Flow Classification in Information Centric Networking 9 draft-moiseenko-icnrg-flowclass-05 11 Abstract 13 For the ubiquitous and highly important Internet protocols (TCP, UDP, 14 IP), flows are conventionally identified by the "5-tuple" of source 15 and destination IP addresses, source and destination port, and 16 protocol type in an IP packet. Information Centric Networking (ICN) 17 is a new paradigm where network communications are accomplished by 18 requesting named content, instead of sending packets to destination 19 addresses. This document describes mechanisms allowing ICN 20 forwarders, consumers, producers and other ICN nodes to encode, 21 decode, and process equivalence class identifiers (flows) at any 22 desired granularity of a routable name prefix and beyond the routable 23 name prefix. This document is a product of the IRTF Information- 24 Centric Networking Research Group (ICNRG). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 23, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Flow Identification Challenges and Opportunities in ICN . . . 3 63 3. Flow Encoding Schemes . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Equivalence class component count (EC3) . . . . . . . . . 5 65 3.2. Equivalence class name component type (ECNCT) . . . . . . 6 66 4. Producer operation . . . . . . . . . . . . . . . . . . . . . 7 67 5. Consumer operation . . . . . . . . . . . . . . . . . . . . . 8 68 6. Forwarder operation . . . . . . . . . . . . . . . . . . . . . 8 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 The problem of identifying groups of packets that get consistent 77 treatment in a network and allowing that treatment to be independent 78 and isolated from the treatment of other groups of packets, is 79 ubiquitous and long-standing. The purposes to which this 80 identification can be put is highly varied, including such functions 81 are providing differentiated quality of service, traffic engineering, 82 traffic filtering for security functions like intrusion detection and 83 firewalling, etc. 85 Providing the capability to apply different functions to groupings 86 (formally equivalence classes) of packets is generally known as the 87 "flow identification problem" where the definition of what 88 constitutes a "flow" is highly dependent on the particular protocol 89 or protocols carrying the packets. Some of the above uses of flows 90 also bring a mechanism requirement that the flow identification 91 technique be useful to have not just equivalence classes, but the 92 ability to apply some useful notion of fairness among the instances 93 of each equivalence class. There are many possible flow 94 identification techniques that are either too granular (spatially or 95 temporally) to establish fairness, or conversely too coarse and 96 cannot separate traffic a fine enough level to have useful fairness. 98 For the ubiquitous and highly important Internet protocols (TCP, UDP, 99 IP), flows are conventionally identified by the "5-tuple" of source 100 and destination IP addresses, source and destination port, and 101 protocol type in an IP packet. Some systems augment this by further 102 distinguishing equivalence classes by the TOS/DSCP field, but this is 103 secondary to the 5-tuple methods. 2-party flows are present where the 104 source and destination addresses are unicast IP addresses. Multi- 105 party flows can exist when the destination IP address is a multicast 106 address. One key common characteristic is that the identification of 107 flows depends in a very deep way on the presence of source addresses 108 in the packets, and the limited richness of IP addresses is 109 correspondingly constraining as a means to classify traffic in a 110 semantically meaningful way. 112 The purpose of this document is to devise a mechanism allowing ICN 113 forwarders, consumers, producers and other ICN nodes to encode, 114 decode, and process equivalence class identifiers (flows) at any 115 desired granularity of a routable name prefix and beyond the routable 116 name prefix. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Flow Identification Challenges and Opportunities in ICN 126 ICN systems differ from IP-based designs in a number of ways, three 127 of which are quite fundamental. 129 1. The packets are addressed to a rich namespace of packets, which 130 is hierarchical and carry semantic information that can be useful 131 for classification of flows. 133 2. Conversely, the packets do not contain source addresses of any 134 kind, which means that identifying flows as groups of packets 135 between a single pair of endpoints (in the unicast case) is not 136 possible for intermediate forwarders (other than possibly the 137 first-hop forwarder if it serves a single consumer per 138 interface). 140 3. Instead of group-based multicast, ICN systems use multi- 141 destination delivery semantics. This allows a different way to 142 map packets to flows, and in fact in the IP world multicast has 143 been difficult to use partly because there is no good way to make 144 use of flow identification for multicast flows (for a variety of 145 reasons). 147 These differences lead to a need to find a different method to 148 identify flows than used in the IP protocol suite. Ideally, the 149 method would provide semantics that map well with the expected uses 150 of ICN to build applications. It would also use native capabilities 151 in the ICN protocols rather than having to change the protocol 152 architecture in ways that affect the semantics or utility of an ICN 153 approach to networking. 155 In NDN and CCN protocols, Interest and Data names are the only 156 identifiers in the network; neither source addresses nor destination 157 addresses are employed. Each Interest packet is responded by exactly 158 one Data packet, producing a useful property known as "flow balance". 159 This means that flow identification can be tied directly to the 160 Interest/Data exchanges. The key to having useful flow 161 identification is for the equivalence classes to be associated with 162 the names in the corresponding Interest and Data packets, and to be 163 stable over multiple exchanges using different names that share some 164 common "handle" that can be used to separate the names into 165 equivalence classes. As mentioned above, simply using the routing 166 state that maps name prefixes to routes does not provide a useful set 167 of equivalence classes, because: 169 o in general, routing prefixes are too coarse; many equivalence 170 classes of packets are generally covered by a single routing 171 prefix because they are present at the same set of destinations 172 from a routing perspective; 174 o practical, scalable routing needs to do route aggregation, which 175 further blurs the discrimination of the equivalence classes. 177 Therefore, NDN and CCN protocols need to have something that both 178 relates to the name structure but provides finer granularity for flow 179 classification purposes. This document describes two alternative 180 mechanisms addressing these issues. 182 3. Flow Encoding Schemes 184 Flow encoding schemes described in this document allow ICN systems to 185 perform flow identification at any desired granularity of a routable 186 name prefix and beyond the routable name prefix. Techniques 187 described herein permit both consumer nodes and forwarders to use 188 equivalence classes to perform per-flow functions. The encoding to 189 achieve the flow classification is lightweight and does not require 190 changes to the protocol architecture in ways that affect the 191 semantics or utility of an ICN approach to networking. Furthermore, 192 equivalence classes can be specified by the data producer, in 193 contrast to IP protocols in which the data producer can only control 194 the destination port as an equivalence-class discriminator. 196 No matter what method is used to identify equivalence classes that 197 can be treated as flows, there is the independent but critically 198 important issue of how to scale any state that is kept on a per-flow 199 basis when the flow count is very high. For consumers and producers, 200 this state scales naturally with the number of applications and 201 application interactions are going on simultaneously. Therefore the 202 scaling limit is not likely to be in the producers or consumers. For 203 ICN forwarders this state could scale quadratically or worse if the 204 forwarders need classic prior resource reservation to 205 deterministically partition resources on a producer/consumer pair 206 basis. This need not be the case however. Practical resource 207 control algorithms exist that keep state only for "active" flows 208 (those with packets either currently or recently moving through the 209 network). Further state reduction is also possible with some loss of 210 accuracy using approximate techniques, like stochastic fair queuing 211 (SFQ). If the ICN forwarder cannot keep all the state due to memory 212 or processing limitations, it faces the common problem of which flows 213 to remember and which to forget. This problem is fundamental, and is 214 mostly independent of the choice of flow identification method in the 215 protocol. Flow encoding schemes described in this document provide a 216 method for identifying equivalence classes using protocol machinery 217 that already has to scale (e.g. name parsing and lookup) and hence 218 does not introduce a new class of problems not inherently present. 220 3.1. Equivalence class component count (EC3) 222 For this encoding scheme a new field called equivalence class 223 component count (EC3) is introduced into the Data packets. It is set 224 by a producer and counts the number of name components in the 225 corresponding name that are to be considered, when grouped together 226 under the same prefix part of the name, to be one equivalence class 227 instance. This allows either finer (or coarser) granularity than 228 provided by routing prefixes. Because the EC3 is a separate field of 229 the packet (Figure 1), producers can "regroup" equivalence classes 230 dynamically by including more or fewer levels of the name hierarchy 231 when they respond to Interests for the corresponding Data packets. 232 This brings a set of clear advantages and disadvantages. The primary 233 advantage is flexibility in re-grouping equivalence classes, 234 especially in aggregating flows at different granularities. The main 235 disadvantage is that the binding of the equivalence class into the 236 namespace is not explicit, and hence it is harder to enforce 237 consistent interpretation among producers, consumers and forwarders. 239 An additional consideration with the EC3 encoding scheme is whether 240 or not the field is inside or outside the security envelope that 241 provides cryptographic packet integrity to the name and data in the 242 data packet. Either approach is possible; however having the field 243 outside the security envelope would allow ICN forwarders to modify 244 it, allowing the aggregation/disaggregation of flows to be performed 245 by the forwarders as well as the consumers. Conversely, leaving the 246 field outside the security envelope may enhance certain attack 247 scenarios against flow classification when employed for quality of 248 service differentiation or firewall filtering. 250 +-------------------------------------------------------------------+ 251 | /youtube | / | /video OR | | | 252 | | | /audio | | | 253 +-----------+--------------+-------------+-------------+------------+ 254 | Name | Name | Name | Name | Segment | 255 | component | component | component | component | component | 256 | type | type | type | type | type | 257 +-----------+--------------+-------------+-------------+------------+ 258 | | 259 | Equivalence Class Component Count = 2 (up to MediaID stream) | 260 | OR | 261 | Equivalence Class Component Count = 3 (video or audio substream) | 262 +-------------------------------------------------------------------+ 264 An example of EC3 encoding of flow information. 266 Figure 1 268 3.2. Equivalence class name component type (ECNCT) 270 For this scheme the equivalence class information is encoded directly 271 in the name, by adding a name component to the name of the Interest 272 and Data packets. This new typed named component is called 273 equivalence class name component type (ECNCT). It is set by the 274 producer as part of constructing all Data packets in the desired 275 equivalence class and is therefore immutable for the lifetime of the 276 associated named data. A consequence of this is that the ECNCT is 277 present in Interest packets as well, and hence may affect both PIT 278 matching and FIB matching. The Equivalence Class name component both 279 names the equivalence class explicitly, and implicitly makes all Data 280 packets named below it in the hierarchy part of that equivalence 281 class. In other words, the name can have multiple equivalence class 282 (e.g. flow and subflows) markings using this scheme (Figure 2). As 283 in EC3 encoding scheme, depending where in the name component 284 hierarchy the ECNCT is placed, one can have either finer or coarser 285 granularity than provided by routing prefixes. 287 The exact details of how to encode the ECNCT name component may 288 differ among ICN architectures. The CCN design has explicitly typed 289 name components, so for that protocol an explicit name component type 290 can be assigned straightforwardly. The NDN design eschews typed name 291 components and instead uses textual naming conventions for name 292 components. In that case an architectural constant string would be 293 chosen to distinguish ECNCT from other name component semantics. 295 +------------------------------------------------------------+ 296 | /youtube | / | /video OR | | | 297 | | | /audio | | | 298 +----------+------------+-----------+-----------+------------+ 299 | Name | Flow | Flow | Name | Segment | 300 | component| component | component | component | component | 301 | type | type | type | type | type | 302 +----------+------------+-----------+-----------+------------+ 304 An example of ECNCT encoding of flow information. 306 Figure 2 308 When an ICN forwarder receives a packet with a name carrying 309 ECNCT(s), it can be processed on a component-by-component basis, and 310 substreams can be identified according to name prefixes indicated by 311 the equivalence class identifiers. The identification of substreams 312 enables special treatment of selected substreams. For example, video 313 substreams can be discriminated from other substreams, such as audio 314 substreams. In the example in Figure 2, two name components include 315 equivalence class identifiers to define a hierarchy of flows (or 316 substreams). Specifically, two flow components are encoded to define 317 the following hierarchy of flows: 319 First level name prefix: /youtube/ 321 Second level name prefix: /youtube//video 323 Second level name prefix: /youtube//audio 325 4. Producer operation 327 In ECNCT encoding scheme, an ICN producer receives an Interest packet 328 carrying equivalence class identifiers in the name. A producer might 329 use the equivalence class identifiers for demultiplexing, load 330 sharding and other purposes, and reply with a Data packet matching 331 the Interest name. 333 In EC3 encoding scheme, an ICN producer receives an Interest packet 334 that might not carry an equivalence class identifier. In such case, 335 the producer may refer to the name schemas used in a particular 336 application to dynamically determine the equivalence class identifier 337 for Interest demultiplexing, load sharding and other purposes, and 338 for replying with a Data packet carring the equivalence class 339 identifer in EC3 field. 341 5. Consumer operation 343 An ICN consumer may also use the knowledge of equivalence classes of 344 packets to take certain actions. For example, when a Data packet 345 with a name specifying a particular equivalence class arrives at a 346 consumer in response to a previously sent Interest packet, the 347 consumer can associate the data packet with the correct equivalence 348 class. Consequently, the consumer can manage subsequent Interest/ 349 Data exchanges with the same name prefix and equivalence class 350 identifier (e.g., EC3 or ECNCT) as one flow. Associated measurements 351 such as round trip time (RTT) or marginal delay can be leveraged to 352 perform flow and congestion management for the equivalence class as a 353 whole. 355 6. Forwarder operation 357 A flow table may be provisioned in ICN node to enable the node to 358 make decisions about performing actions on Interest and/or Data 359 packets based on one or more equivalence classes. The flow table can 360 include name prefixes mapped to equivalence class identifiers 361 obtained from previous Interest-Data exchanges. In ECNCT encoding 362 scheme, Interest packets carry the equivalence class identifier, 363 therefore flow table may only include name prefixes. Typically, name 364 prefixes in flow table are more granular than prefixes in the FIB, 365 but less granular than names in the PIT. Flow table could be 366 separate from other elements of ICN node or could be integrated with 367 FIB or PIT. 369 Flow management logic can be configured to treat flows having the 370 same equivalence class similarly. Actions taken that are related to 371 flows or objects having a similar equivalence class can include, but 372 are not limited to, dropping a packet, using a particular interface 373 for a packet, security related actions (e.g., filtering traffic for 374 security functions like intrusion detection and firewalling), quality 375 of service (QoS) related actions (e.g., types of resources to 376 allocate to the packets, moving a packet up in the queue for 377 forwarding purposes, etc.), and/or traffic engineering (e.g., 378 selecting one path over another path). Flow management logic can 379 enable such actions to be taken on a particular flow based on the 380 equivalence class associated with the flow or object and policies 381 related to the equivalence class. 383 Specific examples of how ICN node can use the knowledge of 384 equivalence classes of packets include, but are not limited to, the 385 following: 387 1. Enforce rate control for the equivalence class as a whole (e.g., 388 dropping packets, queuing packets, etc.); 390 2. Estimate the number of simultaneous flows traversing a bottleneck 391 link, which can improve the performance of many congestion 392 control schemes; and 394 3. Make more intelligent selections of which packets to cache at the 395 ICN forwarder, for example, to prefer to cache many packets of 396 the same equivalence class. 398 7. IANA Considerations 400 This memo includes no request to IANA. 402 8. Security Considerations 404 Certain attack scenarios against flow classification for quality of 405 service or firewall filtering may be prevented if the EC3 field 406 located inside the security envelope. ICN forwarders can read, but 407 not change, the EC3 value, because the EC3 field is covered by a 408 security signature and not encrypted. 410 If the EC3 field is outside of the security envelope, it can be 411 placed in the hop-by-hop headers and, therefore, be modified by the 412 transit ICN forwarders. This allows the transit ICN forwarders to 413 override the flow definitions set by the producer applications, but 414 opens the system to various attack scenarios. 416 Modification of equivalence class identifiers in ECNCT encoding 417 scheme effectively modifies the packet name, and therefore, ECNCT 418 does not introduce any additional security threats. 420 9. Normative References 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, 424 DOI 10.17487/RFC2119, March 1997, 425 . 427 Authors' Addresses 429 Ilya Moiseenko 430 Apple Computer 431 USA 433 Email: imoiseenko@apple.com 435 Dave Oran 436 Network Systems Research and Design 437 4 Shady Hill Square 438 Cambridge, MA 02138 439 USA 441 Email: daveoran@orandom.net