| ICNRG | I. Moiseenko |
| Internet-Draft | Cisco Systems |
| Intended status: Informational | D. Oran |
| Expires: January 17, 2019 | Network Systems Research and Design |
| July 16, 2018 |
Flow Classification in Information Centric Networking
draft-moiseenko-icnrg-flowclass-02
For the ubiquitous and highly important Internet protocols (TCP, UDP, IP), flows are conventionally identified by the "5-tuple" of source and destination IP addresses, source and destination port, and protocol type in an IP packet. Information Centric Networking (ICN) is a new paradigm where network communications are accomplished by requesting named content, instead of sending packets to destination addresses. This document describes mechanisms allowing ICN forwarders, consumers, producers and other ICN nodes to encode, decode, and process equivalence class identifiers (flows) at any desired granularity of a routable name prefix and beyond the routable name prefix. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The problem of identifying groups of packets that get consistent treatment in a network and allowing that treatment to be independent and isolated from the treatment of other groups of packets, is ubiquitous and long-standing. The purposes to which this identification can be put is highly varied, including such functions are providing differentiated quality of service, traffic engineering, traffic filtering for security functions like intrusion detection and firewalling, etc.
Providing the capability to apply different functions to groupings (formally equivalence classes) of packets is generally known as the "flow identification problem" where the definition of what constitutes a "flow" is highly dependent on the particular protocol or protocols carrying the packets. Some of the above uses of flows also bring a mechanism requirement that the flow identification technique be useful to have not just equivalence classes, but the ability to apply some useful notion of fairness among the instances of each equivalence class. There are many possible flow identification techniques that are either too granular (spatially or temporally) to establish fairness, or conversely too coarse and cannot separate traffic a fine enough level to have useful fairness.
For the ubiquitous and highly important Internet protocols (TCP, UDP, IP), flows are conventionally identified by the "5-tuple" of source and destination IP addresses, source and destination port, and protocol type in an IP packet. Some systems augment this by further distinguishing equivalence classes by the TOS/DSCP field, but this is secondary to the 5-tuple methods. 2-party flows are present where the source and destination addresses are unicast IP addresses. Multi-party flows can exist when the destination IP address is a multicast address. One key common characteristic is that the identification of flows depends in a very deep way on the presence of source addresses in the packets, and the limited richness of IP addresses is correspondingly constraining as a means to classify traffic in a semantically meaningful way.
The purpose of this document is to devise a mechanism allowing ICN forwarders, consumers, producers and other ICN nodes to encode, decode, and process equivalence class identifiers (flows) at any desired granularity of a routable name prefix and beyond the routable name prefix.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
ICN systems differ from IP-based designs in a number of ways, three of which are quite fundamental.
These differences lead to a need to find a different method to identify flows than used in the IP protocol suite. Ideally, the method would provide semantics that map well with the expected uses of ICN to build applications. It would also use native capabilities in the ICN protocols rather than having to change the protocol architecture in ways that affect the semantics or utility of an ICN approach to networking.
In NDN and CCN protocols, Interest and Data names are the only identifiers in the network; neither source addresses nor destination addresses are employed. Each Interest packet is responded by exactly one Data packet, producing a useful property known as "flow balance". This means that flow identification can be tied directly to the Interest/Data exchanges. The key to having useful flow identification is for the equivalence classes to be associated with the names in the corresponding Interest and Data packets, and to be stable over multiple exchanges using different names that share some common "handle" that can be used to separate the names into equivalence classes. As mentioned above, simply using the routing state that maps name prefixes to routes does not provide a useful set of equivalence classes, because:
Therefore, NDN and CCN protocols need to have something that both relates to the name structure but provides finer granularity for flow classification purposes. This document describes two alternative mechanisms addressing these issues.
Flow encoding schemes described in this document allow ICN systems to perform flow identification at any desired granularity of a routable name prefix and beyond the routable name prefix. Techniques described herein permit both consumer nodes and forwarders to use equivalence classes to perform per-flow functions. The encoding to achieve the flow classification is lightweight and does not require changes to the protocol architecture in ways that affect the semantics or utility of an ICN approach to networking. Furthermore, equivalence classes can be specified by the data producer, in contrast to IP protocols in which the data producer can only control the destination port as an equivalence-class discriminator.
No matter what method is used to identify equivalence classes that can be treated as flows, there is the independent but critically important issue of how to scale any state that is kept on a per-flow basis when the flow count is very high. For consumers and producers, this state scales naturally with the number of applications and application interactions are going on simultaneously. Therefore the scaling limit is not likely to be in the producers or consumers. For ICN forwarders that are operating at high speed and/or handling the traffic of many producers and consumers however, this state can scale quadratically or worse. If the ICN forwarder cannot keep all the state due to memory or processing limitations, it faces the common problem of which flows to remember and which to forget. This document does not solve this problem, which is fundamental. Flow encoding schemes described in this document provide a method for identifying equivalence classes using protocol machinery that already has to scale (e.g. name parsing and lookup) and hence does not introduce a new class of problems not inherently present.
For this encoding scheme a new field called equivalence class component count (EC3) is introduced into the Data packets. It is set by a producer and counts the number of name components in the corresponding name that are to be considered, when grouped together under the same prefix part of the name, to be one equivalence class instance. This allows either finer (or coarser) granularity than provided by routing prefixes. Because the EC3 is a separate field of the packet (Figure 1), producers can "regroup" equivalence classes dynamically by including more or fewer levels of the name hierarchy when they respond to Interests for the corresponding Data packets. Therefore, the behavior of EC3 encoding scheme is somewhat different from ECNCT encoding scheme and has both advantages and disadvantages. The advantage is flexibility in re-grouping equivalence classes, especially in aggregating flows at different granularities. The disadvantage is that the binding of the equivalence class into the namespace is not explicit, and hence it is harder to enforce consistent interpretations.
An additional consideration with the EC3 encoding scheme is whether or not the field is inside or outside the security envelope that provides cryptographic packet integrity to the name and data in the data packet. Either approach is possible; however having the field outside the security envelope would allow ICN forwarders to modify it, allowing the aggregation/disaggregation of flows to be performed by the forwarders as well as the consumers. Conversely, leaving the field outside the security envelope may enhance certain attack scenarios against flow classification for quality of service or firewall filtering.
+-------------------------------------------------------------------+
| /youtube | /<mediaID> | /video OR | <frameID> | <segment#> |
| | | /audio | | |
+-----------+--------------+-------------+-------------+------------+
| Name | Name | Name | Name | Segment |
| component | component | component | component | component |
| type | type | type | type | type |
+-----------+--------------+-------------+-------------+------------+
| |
| Equivalence Class Component Count = 2 (up to MediaID stream) |
| OR |
| Equivalence Class Component Count = 3 (video or audio substream) |
+-------------------------------------------------------------------+
An example of EC3 encoding of flow information.
Figure 1
For this scheme the equivalence class information is encoded directly in the name, by adding a name component to the name of the Interest and Data packets. This new typed named component is called equivalence class name component type (ECNCT). It is set by the producer as part of constructing all Data packets in the desired equivalence class and is therefore immutable for the lifetime of the associated named data. A consequence of this is that the ECNCT is present in Interest packets as well, and hence may affect both PIT matching and FIB matching. The Equivalence Class name component both names the equivalence class explicitly, and implicitly makes all Data packets named below it in the hierarchy part of that equivalence class. In other words, the name can have multiple equivalence class (e.g. flow and subflows) markings using this scheme (Figure 2). As in EC3 encoding scheme, depending where in the name component hierarchy the ECNCT is placed, one can have either finer or coarser granularity than provided by routing prefixes.
The exact details of how to encode the ECNCT name component may differ among ICN architectures. The CCN design has explicitly typed name components, so for that protocol an explicit name component type can be assigned straightforwardly. The NDN design eschews typed name components and instead uses textual naming conventions for name components. In that case an architectural constant string would be chosen to distinguish ECNCT from other name component semantics.
+------------------------------------------------------------+
| /youtube | /<mediaID> | /video OR | <frameID> | <segment#> |
| | | /audio | | |
+----------+------------+-----------+-----------+------------+
| Name | Flow | Flow | Name | Segment |
| component| component | component | component | component |
| type | type | type | type | type |
+----------+------------+-----------+-----------+------------+
An example of ECNCT encoding of flow information.
Figure 2
When an ICN forwarder receives a packet with a name carrying ECNCT(s), it can be processed on a component-by-component basis, and substreams can be identified according to name prefixes indicated by the equivalence class identifiers. The identification of substreams enables special treatment of selected substreams. For example, video substreams can be discriminated from other substreams, such as audio substreams. In the example in Figure 2, two name components include equivalence class identifiers to define a hierarchy of flows (or substreams). Specifically, two flow components are encoded to define the following hierarchy of flows:
First level name prefix: /youtube/<mediaID>
Second level name prefix: /youtube/<mediaID>/video
Second level name prefix: /youtube/<mediaID>/audio
In ECNCT encoding scheme, an ICN producer receives an Interest packet carrying equivalence class identifiers in the name. A producer might use the equivalence class identifiers for demultiplexing, load sharding and other purposes, and reply with a Data packet matching the Interest name.
In EC3 encoding scheme, an ICN producer receives an Interest packet that might not carry an equivalence class identifier. In such case, the producer may refer to the name schemas used in a particular application to dynamically determine the equivalence class identifier for Interest demultiplexing, load sharding and other purposes, and for replying with a Data packet carring the equivalence class identifer in EC3 field.
An ICN consumer may also use the knowledge of equivalence classes of packets to take certain actions. For example, when a Data packet with a name specifying a particular equivalence class arrives at a consumer in response to a previously sent Interest packet, the consumer can associate the data packet with the correct equivalence class. Consequently, the consumer can manage subsequent Interest/Data exchanges with the same name prefix and equivalence class identifier (e.g., EC3 or ECNCT) as one flow. Associated measurements such as round trip time (RTT) or marginal delay can be leveraged to perform flow and congestion management for the equivalence class as a whole.
A flow table may be provisioned in ICN node to enable the node to make decisions about performing actions on Interest and/or Data packets based on one or more equivalence classes. The flow table can include name prefixes mapped to equivalence class identifiers obtained from previous Interest-Data exchanges. In ECNCT encoding scheme, Interest packets carry the equivalence class identifier, therefore flow table may only include name prefixes. Typically, name prefixes in flow table are more granular than prefixes in the FIB, but less granular than names in the PIT. Flow table could be separate from other elements of ICN node or could be integrated with FIB or PIT.
Flow management logic can be configured to treat flows having the same equivalence class similarly. Actions taken that are related to flows or objects having a similar equivalence class can include, but are not limited to, dropping a packet, using a particular interface for a packet, security related actions (e.g., filtering traffic for security functions like intrusion detection and firewalling), quality of service (QoS) related actions (e.g., types of resources to allocate to the packets, moving a packet up in the queue for forwarding purposes, etc.), and/or traffic engineering (e.g., selecting one path over another path). Flow management logic can enable such actions to be taken on a particular flow based on the equivalence class associated with the flow or object and policies related to the equivalence class.
Specific examples of how ICN node can use the knowledge of equivalence classes of packets include, but are not limited to, the following:
This memo includes no request to IANA.
Certain attack scenarios against flow classification for quality of service or firewall filtering may be prevented if the EC3 field located inside the security envelope. ICN forwarders can read, but not change, the EC3 value, because the EC3 field is covered by a security signature and not encrypted.
If the EC3 field is outside of the security envelope, it can be placed in the hop-by-hop headers and, therefore, be modified by the transit ICN forwarders. This allows the transit ICN forwarders to override the flow definitions set by the producer applications, but opens the system to various attack scenarios.
Modification of equivalence class identifiers in ECNCT encoding scheme effectively modifies the packet name, and therefore, ECNCT does not introduce any additional security threats.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |