app-class

Traffic Class app-class:<class>

SRND is a 12-Class QoS classification model based on RFC 4594, which is very commonly used among enterprises and is well supported in NBAR and in other network elements and services from Cisco. Therefore, the most important and useful attributes are the ones used by the SRND QOS feature by default – traffic-class and business-relevance. Using these values should be as simple as possible, therefore short notations for these values are proposed.

This also aligns with the classification done by APIC-EM Easy QoS app or other SRND 4.0 based QoS provisioning solutions.

Below are the supported values for Traffic Class and Business Relevance, along with the shortcuts and the Business Relevance defaults per class.

 

APPLICATION CLASS APPLICATION CLASS long APPLICATION CLASS short BUSINESS-RELEVANCE DSCP COS WMM QUEUING & DROPPING APPLICATION EXAMPLES
(RFC 4594) DNS-AS-RR (LONG) DNS-AS-RR(SHORT) DNS-AS-RR(SHORT)     802.11e    
VoIP Telephony app-class:VOIP-TELEPHONY app-class:VO business:yes EF Priority Queue (PQ) Cisco IP Phones (G.711, G.729)
Broadcast Video app-class:BROADCAST-VIDEO app-class:BV business:yes CS5 (Optional) PQ Cisco IP Video Surveillance / Cisco Enterprise TV
Real-Time Interactive app-class:REALTIME-INTERACTIVE app-class:RTI business:yes CS4 (Optional) PQ Cisco TelePresence
Multimedia Conferencing app-class:MULTIMEDIA-CONFERENCING app-class:MMC business:yes AF4 BW Queue + DSCP WRED Cisco Jabber, Cisco WebEx
Multimedia Streaming app-class:MULTIMEDIA-STREAMING app-class:MMS business:yes AF3 BW Queue + DSCP WRED Cisco Digital Media System (VoDs)
Network Control app-class:NETWORK-CONTROL app-class:NC business:yes CS6 BW Queue EIGRP, OSPF, BGP, ISIS, HSRP, IKE
Signaling app-class:SIGNALING app-class:CS business:yes CS3 BW Queue SCCP, SIP, H.323
Ops / Admin / Mgmt app-class:OPS-ADMIN-MGMT app-class:OAM business:yes CS2 BW Queue SNMP, SSH, Syslog
Transactional Data app-class:TRANSACTIONAL-DATA app-class:TD business:yes AF2 BW Queue + DSCP WRED ERP Apps, CRM Apps, Database Apps
Bulk Data app-class:BULK-DATA app-class:BD business:yes AF1 BW Queue + DSCP WRED E-mail, FTP, Backup Apps, Content Distribution
Best Effort app-class:BEST-EFFORD app-class:BE business:default DF 0 Default Queue + RED Default Class
Scavenger app-class:SCAVENGER app-class:SCV business:no CS1 0 Min BW Queue (Deferential) YouTube, Netflix, iTunes, BitTorrent, Xbox Live

 

The idea here is to use the same traffic-class name like being used inside the C3PL policy map to move applications seamlessly into the right traffic-class.

app-id

Application ID app-id:<engine-id>/<selector-id>

Application ID is an ID exported by AVC which explains to what  application a particular flow belongs to.

The numeric application ID is specified using http://www.rfc-editor.org/rfc/rfc6759.txt format. This RFC specifies the application ID model used in Cisco AVC. In this model the application ID is divided into an Engine ID and a Selector ID.

  • Application-ID is divided into a Selector ID and Engine ID separated by a slash
  • Selector-ID is encoded as a simple numeric value between <1-65535>
  • Engine-ID is encoded as either a textual representation or a number

The Application ID is divided into two parts:

  • Engine ID— A unique identifier for the engine that determined the Selector ID. The Classification Engine ID defines the context for the Selector ID. The Engine ID is the first eight bits that provide information about the engine that classifies the flow. IANA-L4, CANA-L3, and so on, are some of the engines that can be classified using an engine ID. Note that the Engine ID does not represent the NBAR2 mechanism used to classify the application. For more information about the engine IDs, see the information available here: http://tools.ietf.org/html/rfc6759
  • Selector ID—The remaining 24 bits that provide information about the application. 495(MS office) is one of the applications that can be classified using the classification ID.

In the case of DNS-AS the  TXT/AVC record the term selector ID is replaced by app-id. Usually the textual representation of app-id is using a colon but since we use colons to separate the option from the value, we’re using a slash.

Any other engine ID should be encoded numerically. e.g. CANA-L4 is engine ID of 4 so a selector ID of 4739 on CANA-L4 should be encoded as: app-id:4/4739
For the full list of Engine IDs see: EDCS-816617

In the case of DNS-AS there are two ways to classify applications:

  1. Generate a classifier for  NBAR build in applications
  2. Generate a classifier for  NBAR custom applications

In case the combination of (app-id|app-name) does not match the NBAR taxonomy, apps are treated as custom apps, therefore we use the Engine ID CU (custom) with the prefix cu/

Application ID for Flexible Netflow Export

  • For a single network device the significance of the app-id is low as MQC is confined by nature to a single device.
  • On the other hand, FNF is used to export records from multiple devices to a centralized netflow collector. The collector use both app-name and app-id
  • If we have 2 applications with the same app-name but with a different app-id it will be treated by the collector as 2 different applications thus leading to a inconsistent report.

Consistent FNF reporting

We achieve consistent reporting between NBAR build in, NBAR custom and non NBAR enabled devices in the following way:

if dns-as(app-id|app-name) eq nbar-pp(app-id|app-name)

  • NBAR-enabled (routers): we’re fine, as there is no NBAR and we just export (app-id|app-name)
  • NBAR-disabled (switches): also fine, as we match NBAR so no custom app gets created and the export of (app-id|app-name) is inline

if dns-as(app-id|app-name) !eq nbar-pp(app-id|app-name)

  • NBAR-enabled (routers):we’re fine, as there is no NBAR and we just export (app-id|app-name)
  • NBAR-disabled (switches):we don’t match NBAR so a custom app gets created but the (app-id|app-name) form DNS-AS is being exported

Point is that all the times we report (app-id|app-name) in a consistent way!

app-name

Application Name app-name:<name>

Application Name indicates a name of an application to be used to classify the entity being described. By default, it describes the HOST for which the record belongs.
Please be aware that an Application Name does not equals the protocol! While NBAR classifies applications based on the protocol they’re communication over the Application Name outlines the “spoken name” of that application.

Application names comprise of:

  • Application name with a length of min 3 and max 24 characters
  • No whitespace
  • ASCII Alphanumeric characters
  • The following characters are allowed in addition: ‘-‘ (hyphen)
  • On switches without NBAR the app-name can match the NBAR local taxonomy
  • Custom names for applications are possible

There are two classes of Application Names:

  1. Predefined: if you want to use for matching predefined applications you need to match the NAME being used inside the NBAR taxonomy
  2. Custom: if you want to create a NBAR2 custom application or if the Network Device itself has no NBAR capabilities.

business

business-relevance

DNS

Domain Name System

DNS-AS

Domain Name System – Authoritative Source

DNS-AS-RR

DNS-AS Metadata Resource Record are expressed within a TXT DATA format

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                   TXT-DATA                   /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

TXT-DATA       One or more <character-string>s.

  • TXT RRs are used to hold descriptive text.
    The semantics of the text depends on the domain where it is found.
  • Originally for arbitrary human-readable text in a DNS record.
  • Since the early 1990s, however, this record more often carries machine-readable data, such as specified by RFC 1464, opportunistic encryption, Sender Policy Framework, DKIM, DMARC, DNS-SD, etc.
  • The base DNS specification limits DNS messages over UDP to 512 octets
  • You can use multiple RRs, but this will make it complicated to sort the records

engine-id

Engine ID— A unique identifier for the engine that determined the Selector ID.

The Classification Engine ID defines the context for the Selector ID. The Engine ID is the first eight bits that provide information about the engine that classifies the flow. IANA-L4, CANA-L3, and so on, are some of the engines that can be classified using an engine ID. Note that the Engine ID does not represent the NBAR2 mechanism used to classify the application.

For more information about the engine IDs, see the information available
here: http://tools.ietf.org/html/rfc6759 as also
here: https://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-03

0 Invalid or reserved.
IANA-L3 1 The IANA protocol (layer 3) number is exported in the Selector ID.
See http://www.iana.org/assignments/protocol-numbers/
CANA-L3 2 Cisco proprietary layer 3 definition. Cisco can still export our own layer 3 protocol numbers, while waiting for IANA to assign it. The Selector ID has got a global significance for all Cisco devices under CANA governance. Hopefully the same IDs will be maintained after the IANA standardization.
IANA-L4 3 IANA layer 4 well-known port number is exported in the application ID. See http://www.iana.org/assignments/port-numbers. Note: as a flow is unidirectional, it contains the destination port in a flow from the client to the server.
CANA-L4 4 Cisco proprietary layer 4 definition. Cisco can still export our own layer 4 port number, while waiting for IANA to assign it. The Selector ID has got a global significance for all Cisco devices under CANA governance. Hopefully the same ID will be maintained after the IANA standardization. Example: IPFIX had the port 4739 pre-assigned in the IETF draft for years. While waiting for the IANA registration, we could use this Selector ID.
NBAR-STANDARD 5 The Selector ID represents the NBAR unique application Id. The Selector ID has got a global significance for all Cisco devices that uses NBAR. This unique Selector ID is equivalent to the NBAR protocol discovery MIB index. THIS ONE WILL TRANSITION TO AN INTERNAL APP ID, SPECIFIC TO THE NBAR IMPLEMENTATION
NBAR-CUSTOM 6 The selector ID represents the NBAR unique custom application Id. The Selector ID has a local significance per Cisco device. The Selector ID is equivalent to the NBAR protocol discovery MIB index.
MIME 7 The MIME type string is exported in the Selector ID.
Note: the MIME type allows the definition of non standardized types, called vendor specific, with a format such as vnd.xxx.
See http://tools.ietf.org/html/rfc2048#section-2.1.2 for reference.
Therefore, there is no point of assigning a classification engine value for Cisco proprietary MIME types.
The selector ID represents a class ID specified by the PSAMP Selection Sequence ID.
PSAMP 8 From the PSAMP protocol specification, the Selection Sequence is specified as:
From all the packets observed at an Observation Point, only a few packets are selected by one or more Selectors.  The Selection Sequence is a unique value per Observation Domain describing the Observation Point and the Selector IDs through which the packets are selected.
The Selector ID has a local significance per router.
MQC-CLASS-ID 9 The selector ID represents the MQC class ID. The Selector ID has a local significance per router. In this case, Selector ID has a local significance per router and the Selector Id value has got the corresponding cbQoSConfigIndex value from the CB-QoS-MIB
SML-STANDARD 10 The selector ID represents the SML unique application Id. The Selector ID has got a global significance for all Cisco devices that uses the SML DPI engine.
SML-CUSTOM 11 The Selector ID represents the SML unique custom application Id.  The Selector ID has a local significance per Cisco device.
CANA-L2 12 The Selector ID represents the layer 2 applications. The Selector ID has a global significance. This regsitry is mainly for the layer2 CISCO-SNAP but we can’t exclude something else!
CANA-L7 13 The Selector ID represents the Cisco unique global application Id. The Selector ID has got a global significance for all Cisco devices
WAAS 14 The Selector ID represents the NAM unique custom application Id. In this case, Selector ID has a local significance per Cisco device IMPORTANT NOTE: application police must try to standardize using this classification engine id
WAAS-CLASS-ID 15 The Selector ID represents the WAAS unique class Id, which is called the WAAS Classifier. In this case, Selector ID has a local significance per Cisco device.
Contact: Mohamed Hassan, Rajiv Raghunarayan
NAM-CLASS-ID 16 The Selector ID represents the NAM unique custom application Id
In this case, Selector ID has a local significance per Cisco device.
Contact: Patrick Wildi
PFR-CLASS-ID 17 The Selector ID represents the PfR unique Traffic Class.
In this case, Selector ID has a local significance per Cisco device (per Border Router).  Note that the Selector ID has got some more structure: see EDCS-909561 for the details.
Contact: Pritam Shah & Yoshiyuki Tsuda
ETHERTYPE 18 The Selector ID represents the well-knonw L2 Ethertype. See http://standards.ieee.org/develop/regauth/ethertype/eth.txt and http://www.iana.org/assignments/ethernet-numbers . Note that the Ethertype is usually expressed in hexa, however the corresponding integer value is used in Selector id. Note2: Ethertype starts at 0x0600, i.e. 1536 integer
Contact: Patrick Wildi & Benoit Claise
LLC 19 The Selector ID represents the well-knonw LLC based applications. See http://standards.ieee.org/develop/regauth/llc/public.html. Note that the Ethertype is usually expressed in hexa, however the corresponding integer value is used in Selector id
Contact: Patrick Wildi & Benoit Claise
PANA-L7-PEN 20 Proprietary layer 7 definition; See RFC 6759
CISCO-PPDK-LOCAL 21 For use by the Protocol Pack development Kit for user defined Ids
255 The classification engine ID 255 is the maximum engine ID.

 

HTTP

Hypertext Transfer Protocol

HTTP/2

Next generation of “Hypertext Transfer Protocol” which is based on “SPDY” which had been based on “QUIC”

At a high level, HTTP/2:

  • is binary, instead of textual
  • is fully multiplexed, instead of ordered and blocking
  • can therefore use one connection for parallelism
  • uses header compression to reduce overhead
  • allows servers to “push” responses proactively into client caches

IOE

Internet of Everything, another term for IOT Internet of Things

IOT

The Internet of Things (IoT) is the network of physical objects—devices, vehicles, buildings and other items which are embedded with electronics, software, sensors, and network connectivity, which enables these objects to collect and exchange data.[1] The Internet of Things allows objects to be sensed and controlled remotely across existing network infrastructure,[2] creating opportunities for more direct integration of the physical world into computer-based systems, and resulting in improved efficiency, accuracy and economic benefit;[3][4][5][6][7][8] when IoT is augmented with sensors and actuators, the technology becomes an instance of the more general class of cyber-physical systems, which also encompasses technologies such as smart grids, smart homes, intelligent transportation and smart cities. Each thing is uniquely identifiable through its embedded computing system but is able to interoperate within the existing Internet infrastructure. Experts estimate that the IoT will consist of almost 50 billion objects by 2020.[9]

Metadata

data about the data

DNS-AS Metadata Resource Record are expressed witin a TXT DATA format

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                   TXT-DATA                   /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

TXT-DATA       One or more <character-string>s.

  • TXT RRs are used to hold descriptive text.
    The semantics of the text depends on the domain where it is found.
  • Originally for arbitrary human-readable text in a DNS record.
  • Since the early 1990s, however, this record more often carries machine-readable data, such as specified by RFC 1464, opportunistic encryption, Sender Policy Framework, DKIM, DMARC, DNS-SD, etc.
  • The base DNS specification limits DNS messages over UDP to 512 octets
  • You can use multiple RRs, but this will make it complicated to sort the records

one

https://www.opennetworking.org

onrc

http://onrc.net

OpenDaylight

OpenDaylight is leading the transformation to Open SDN. By uniting the industry around a common SDN platform, the ODL community is helping to make interoperable, programmable networks a reality.
https://www.opendaylight.org

OpenFlow

Open Flow

QUIC

QUIC, a multiplexed stream transport over UDP

QUIC is an experimental protocol aimed at reducing web latency over that of TCP. On the surface, QUIC is very similar to TCP+TLS+SPDY implemented on UDP. Because TCP is implement in operating system kernels, and middlebox firmware, making significant changes to TCP is next to impossible. However, since QUIC is built on top of UDP, it suffers from no such limitations.

Key features of QUIC over existing TCP+TLS+SPDY include 
  • Dramatically reduced connection establishment time
  • Improved congestion control
  • Multiplexing without head of line blocking
  • Forward error correction
  • Connection migration

What is QUIC?  QUIC is the name for a new experimental protocol, and it stands for Quick UDP Internet Connection.  The protocol supports a set multiplexed connections over UDP, and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency. An experimental implementation is being put in place in Chrome by a team of engineers at Google.

What are some of the distinctive techniques being tested in QUIC?  QUIC will employ bandwidth estimation in each direction into congestion avoidance, and then pace packet transmissions evenly to reduce packet loss.  It will also use packet-level error correction codes to reduce the need to retransmit lost packet data.  QUIC aligns cryptographic block boundaries with packet boundaries, so that packet loss impact is further contained.

Doesn’t SPDY already provide multiplexed connections over SSL?  Yes, but SPDY currently runs across TCP, and that induces some undesirable latency costs (even though SPDY is already producing lower latency results than traditional HTTP over TCP).

Why isn’t SPDY over TCP good enough?  A single lost packet in an underlying TCP connection stalls all of the multiplexed SPDY streams over that connection. By comparison, a single lost packet for X parallel HTTP connections will only stall 1 out of X connections. With UDP, QUIC can support out-of-order delivery, so that a lost packet will typically impact (stall) at most one stream. TCP’s congestion avoidance via a single congestion window also puts SPDY at a disadvantage over TCP when compared to several HTTP connections, each with a separate congestion window. Separate congestion windows are not impacted as much by a packet loss, and we hope that QUIC will be able to more equitably handle congestion for a set of multiplexed connections.

Are there any other reasons why TCP isn’t good enough?  TCP, and TLS/SSL, routinely require one or more round trip times (RTTs) during connection establishment.  We’re hopeful that QUIC can commonly reduce connection costs towards zero RTTs. (i.e., send hello, and then send data request without waiting).

Why can’t you just evolve and improve TCP under SPDY?  That is our goal. TCP support is built into the kernel of operating systems. Considering how slowly users around the world upgrade their OS, it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas, and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.

Why didn’t you build a whole new protocol, rather than using UDP? Middle boxes on the Internet today will generally block traffic unless it is TCP or UDP traffic.  Since we couldn’t significantly modify TCP, we had to use UDP.  UDP is used today by many game systems, as well as VOIP and streaming video, so its use seems plausible.

Why does QUIC always require encryption of the entire channel?  As we learned with SPDY and other protocols, if we don’t encrypt the traffic, then middle boxes are guaranteed to (wittingly, or unwittingly) corrupt the transmissions when they try to “helpfully” filter or “improve” the traffic.

UDP doesn’t have congestion control, so won’t QUIC cause Internet collapse if widely adopted?  QUIC employs congestion controls, just as it employs automatic retransmission to support reliable transport.  QUIC will attempt to be fair with competing TCP traffic.  For instance, when conveying Q multiplexed flows, and sharing bandwidth with T concurrent TCP flows, we will try to use resources in the range of Q / (Q+T) bandwidth (i.e., “a fair share” for Q additional flows).

Why didn’t you use existing standards such as SCTP over DTLS?  QUIC incorporates many techniques in an effort to reduce latency. SCTP and DTLS were not designed to minimize latency, and this is significantly apparent even during the connection establishment phases. Several of the techniques that QUIC is experimenting with would be difficult technically to incorporate into existing standards. As an example, each of these other protocols require several round trips to establish a connection, which is at odds with our target of 0-RTT connectivity overhead.

RFC6759

 

RFC6759 Metadata Components

  • http://www.rfc-editor.org/rfc/rfc6759.txt
  • https://datatracker.ietf.org/doc/rfc6759/
  • General DNS-AS TXT record syntax: “CISCO-CLS=<option>:<val>{|<option>:<val>}*”
  • Option-value pairs may appear in the same record, separated by a pipe character ‘|’.
  • Example for such a TXT record with app metadata would be: CISCO-CLS=app-name:EXCHANGE

Supported Attributes:

  • Application Name
  • Application ID (as in RFC 6759)
  • Application Category
  • Application Sub-Category
  • Attributes (tunneled, encrypted, p2p)
  • Traffic Class (QoS)
  • Business Relevance
  • Server Port Range (to identify an application with ports)
  • IP Protocol Specifier
  • IP Version Specifier
  • Min/Avg/Max Bandwidth consumption
  • Max. Possible Packet Loss (in %)
  • Max. Possible Jitter (in ms.)
  • Max. Possible Latency (in ms.)
  • Source of Metadata (NBAR2, DNS-AS server etc.)

SDN

Software Defined Networking

The Promise of OF/SDN had been “Decoupling Policy from Configuration”

SDN

selector-id

Application ID app-id:<engine-id>/<selector-id>

Application ID is an ID exported by AVC which explains to what  application a particular flow belongs to.

The numeric application ID is specified using http://www.rfc-editor.org/rfc/rfc6759.txt format. This RFC specifies the application ID model used in Cisco AVC. In this model the application ID is divided into an Engine ID and a Selector ID.

  • Application-ID is divided into a Selector ID and Engine ID separated by a slash
  • Selector-ID is encoded as a simple numeric value between <1-65535>
  • Engine-ID is encoded as either a textual representation or a number

Selector ID—The remaining 24 bits that provide information about the application.

SPDY

SPDY

SPDY is an experiment with protocols for the web.  Its goal is to reduce the latency of web pages.

tenet

any opinion, principle, doctrine, dogma, etc., especially one held as true by members of a profession, group, or movement.