Table Of Contents
Network Based Application Recognition
RTP Payload Classification
Network Based Application Recognition Overview
Enterprise and Service Provider customers develop, maintain and enhance their networking infrastructure to support applications and protocols. Their networks run a wide range of applications, depending on business objectives and numerous other criteria. These applications have certain requirements and expectations from the network infrastructure, which are often specified in terms of bandwidth, delay, jitter, throughput, and packet loss.
The intention of IP Quality of Service (QoS) is to provide appropriate network resources or Service Level Agreements (SLAs) to applications, and to maximize the ROI on the network infrastructure. Network resources must be distributed in a manner that ensures the non-critical applications do not hamper the performance of critical applications.
Customers typically deploy IP QoS by defining five or six different classes of service using various classification techniques available in the Cisco IOS® QoS framework: Real Time Voice, Real Time Video, Interactive, Transactional, Streaming Video, and Best Effort.
Cisco IOS QoS class-based tools for Marking, Congestion Management, Congestion Avoidance, Link Efficiency mechanisms and Policing and Shaping can then be used to provide the network resources to guarantee the desired performances for these applications.
Classification is therefore a crucial first step in QoS deployment primarily because customers must:
•Identify various applications and protocols running on their networks
•Understand the application behavior with respect to the available network resources
•Identify the mission-critical and non-critical applications
•Categorize the application and protocols in the different classes of service accordingly
Network Based Application Recognition (nBAR) is an intelligent classification engine in Cisco IOS Software that can recognize a wide variety of applications, including Web-based and client/server applications. Once the applications are recognized, the network can invoke required services for that particular application. With the rapid deployment of QoS, newer requirements for packet classification have emerged.
nBAR performs the following two functions:
•Identification of applications and protocols (Layer 4 to Layer 7)
Identification of Applications and Protocols (Layer 4 to Layer 7)
nBAR can classify applications that use:
•Statically assigned TCP and UDP port numbers
•Non-UDP and non-TCP IP protocols
•Dynamically assigned TCP and UCP port numbers negotiated during connection establishment
–Stateful inspection is required for classification of such applications and protocols. This is the ability to discover data connections that will be classified by passing the control connections over which the data connection port assignments are made.
•Sub-port classification: classification of HTTP (URLs, mime or host names) and Citrix applications (ICA traffic based on published application name)
•Classification based on deep packet inspection and multiple application specific attributes. RTP Payload Classification is based on this algorithm, in which the packet is classified as RTP, based on multiple attributes in the RTP header.
Protocol Discovery is a commonly used nBAR feature that collects application and protocol statistics (ie: packet counts, byte counts and bit rates) per interface. QoS Device Manager (QDM) graphically displays this information, and the same functionality will soon be incorporated into QoS Policy Manager (QPM).
nBAR Protocol Discovery MIBs are currently under development (Cisco IOS Software Release 12.[6th]T). The most important function of Protocol Discovery is monitoring. When it is deployed with QDM, it enables customers to generate real-time statistics on the applications in their network. It also gives them an idea of the traffic distribution at key points in the network.
Therefore, nBAR is an application-aware intelligent classification engine that provides real time statistics. It will soon also provide historical statistics, based on the introduction of the Protocol Discovery MIBs. nBAR is an important element in many Cisco initiatives, including Architecture for Voice, Video, and Integrated Data (AVVID), Content Delivery Networks, and Storage Area Networks. It has the application-specific intelligence to classify traffic, and is tightly integrated into the QoS solution.
nBAR plays an important role in the security arena, although it is not intended to be a security tool, it works with other QoS class-based policing features to block certain viruses. Because of its multiple inherent capabilities to identify applications, nBAR, along with other QoS features can deny or limit network resources to rogue or misbehaving applications.
RTP is a widely used packet format for multimedia data streams. It can also be used for media-on-demand, and for interactive services (ie: Internet telephony). The RTP protocol framework provides end-to-end delivery services for data with real time characteristics. The information carried in the RTP header includes payload type identification, time stamping, sequence numbers, source identification, and reception quality feedback. RTP streams consist of two parts: data and control:
•Control: Real-time Transport Control Protocol (RTCP)
•Data: a thin protocol providing support for applications with real-time properties; includes timing reconstruction, loss detection, security and content identification
Per the RTP Protocol definition, even UDP port numbers carry RTP data, while the next higher, odd, port number carry corresponding RTCP packets. The payload type (PT) in the RTP header essentially indicates the CODEC used by the application.
RTP Payload Types
Table 1 shows the set of standard encoding for audio and video traffic as defined by IANA and lists their static payload type value for the Payload Type (PT) field of the RTP data header.
Additionally, end RTP hosts may define payload type values dynamically in the range of 96-127.
•Session directory could specify that for a given session, payload type 96 indicates G721 encoding and an 8KHz sampling rate.
•Other payload type numbers (34 to 95) are currently either unassigned or reserved.
•The payload type can also be negotiated by the session participants, based on either:
–Capabilities of the applications used or
–Previously established agreements between the human participants
Classification of RTP Payload Types using nBAR
nBAR RTP payload classification not only allows the router to statefully identify real time audio and video traffic, but it can also differentiate RTP streams on the basis of specific audio and video CODECs used. nBAR RTP Payload Classification looks deeper into the RTP header to classify RTP traffic for voice and video based on the payload type used (ie: G.711, G.729, and MPEG). The packet is classified as RTP based on multiple attributes in the RTP header, rather than even UDP port numbers alone.
Figure 1. nBAR RTP Payload Type Classification
Why nBAR RTP Payload Classification
While placing voice and video on a network, adequate bandwidth must exist to meet the service needs of these applications. Classification and Marking of the traffic should be performed as close to the edge of the network as possible. The marked DSCP values can then classify, condition, and define the per-hop behavior of each traffic class of traffic within the Diffserv domain.
Cisco IOS Software currently offers many methods for the classification of voice and video traffic. The advantages and disadvantages of each feature are listed below.
1. Match ip rtp
This command matches IP RTP packets that fall within the specified UDP port range. The "match ip rtp" feature matches UDP packets destined to all even port numbers within the specified range. Its limitation is that it will match any UDP packet using an even port number that falls within the range configured. There is a risk that another application could use UDP ports that fall in the same range, as specified by the "match ip rtp" match criteria. This application traffic will now be queued in the Low Latency queue with the delay sensitive voice traffic, and might hamper the quality of voice calls. It is therefore very useful to have a classification engine that can classify applications above the port number criteria.
2. Ip dscp and ip precedence
Various applications and end devices (ie: IP Phones and Polycom Video units) can set their DSCP values. The router can now use this specific DSCP, or Precedence, value as classification criteria for voice and video streams. However, a danger does always exist, because another end user or application could, deliberately or accidentally, mark their packets with the same DSCP or Precedence value.
3. Access lists
Access lists can classify RTP packets, based on source or destination IP addresses, and UDP port number range but do not provide a granular way to classify RTP streams. Again, there is a risk of another application inadvertently matching the access-list criteria for identification of voice and video traffic, resulting in potential theft of service for these service classes. Also, access-lists do not provide classification statistics that are available with nBAR. nBAR thus provides more granular and application-specific matching criteria than access lists.
4. nBAR RTP Payload Classification
This feature expands the RTP traffic-matching capabilities of an nBAR-enabled router by looking deeper into the RTP header to check for RTP specific parameters instead of relying on even UDP port numbers alone
This feature also addresses the challenge of distinguishing RTP packets from different applications based on their payload types or CODECS. The space for payload types is limited, so only very common encodings are assigned static types. These are typically audio and video encodings that have been "blessed" by international standardization bodies, such as the G. series of ITU-T audio encodings (see Table 1). Dynamic payload types map an RTP payload type to an audio and video encoding for the duration of a session. Different members of a session could use different mappings if needed. As shown in the above table, Dynamic payload types use the PT range 96-127.
There are multiple encodings defined by the A/V profile that use dynamic payload types, including GSM-HR, RED, VDVI, L8, MP2P and BMPEG Codecs. nBAR RTP Payload type classification provides a powerful means of classifying the applications based on their static or dynamic payload type.
To configure nBAR to match RTP traffic, use the match protocol rtp command within the class map configuration.match protocol rtp [audio | video | payload-type payload-string]
The syntax description is as follows:
Audio—Specifies matching for payload type values 0-23. Table 1 shows that these values are reserved for audio traffic.
Video—Specifies matching for payload type value 24-33. These values are reserved for video traffic (Table 1).
Payload-Type—This matches traffic belonging to a specific payload type value, thus providing more granularity than the audio and video options mentioned above.
Payload-string—This user-defined string can match against all the specific RTP payload type values from 0-127. Use commas to separate payload type values, and use hyphens to indicate a range of payload type values.Router(config)#class-map nbar_rtpRouter(config-cmap)#match protocol rtp ?audio Match voice packetspayload-type Match an explicit PT - payload typevideo Match video packets<cr>
Entering the "match protocol rtp" command without any other keywords establishes all RTP traffic as a successful match criteria.
Sample Configuration Examples
a. The following example configures nBAR to match all RTP traffic:class-map nbar_rtpmatch protocol rtp
b. The following example configures nBAR to match RTP traffic with the payload-types 0, 1, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 64class-map nbar_rtpmatch protocol rtp payload-type "0, 1, 4 - 0x10, 10001b - 10010b, 64"
To use hexadecimal notation, prepend "0x" to each value. To use binary notation, append a "b" after each value.
RTP Usage Scenarios
Several RTP applications include audio and video tools, and diagnostic tools, such as traffic monitors. RTP is the transport of choice for telephone calls and streaming audio or video. The International Telecommunication Union employs it in the multimedia communications standard H.323, which is used by the real-time streaming protocol (RTSP). There are thousands of users of these applications. The current Internet cannot yet support the full potential demand for real-time services. High-bandwidth services using RTP, including video, have the potential to seriously degrade the quality of service of other network services. When coupled with the ever-present requirement that critical enterprise applications perform optimally, the days of best effort service are rapidly disappearing.
Additionally, voice and video have stringent QoS requirements that the underlying network infrastructure must meet. If these services are not given preferential treatment, it could result in rapid quality degradation to the point of being unusable.
Following are they key requirements for Voice traffic:
•One-way latency should be lesser than 150 ms
•Packet Loss should be less than 0.1%
•Average jitter should be less than 40 ms
•Depending on the CODEC used, bandwidth requirement per call can range from 22 Kbps to 106 Kbps. This will also vary based on the L2 technology used i.e. calls over ATM will have higher L2 overhead than ones made using PPP or FR
•At least 3% of total bandwidth allocation made for voice must be reserved for voice control traffic
There are two main types of video applications:
•Streaming video: non-Real Time (ie: IP/TV; VoD)
•Interactive video: Real Time applications (ie: Video Conferencing)
Following are they key requirements for Streaming Video Applications:
•Latency should be no more than 4-5 seconds
•Packet Loss should be less than 1%
•There are no significant jitter requirements
•Bandwidth requirements depend on the CODEC and the application rate
Streaming video applications have more lenient QoS requirements, as they are delay insensitive (the video can take several seconds to `cue-up'), and are essentially jitter insensitive (due to large application buffers). Some, including E-Learning applications, may contain valuable content, increasing their sensitivity to packet drops and losses.
Following are the key requirements for Interactive Video Applications:
•One-way latency should be lesser than 200 ms.
•Packet Loss should be less than 1%
•Average jitter should be less than 112 ms.
•The minimum bandwidth guarantees made must be at least 20% more than what is actually required as this will ensure faster scheduling of video packets on the wire.
Basically, video conferencing and voice have similar QoS requirements, in terms of latency, loss and jitter; however, the traffic patterns differ radically . For example, video conferencing traffic has varying packet sizes and extremely variable packet rates, while voice traffic travels is at a fixed rate with small packet sizes.
Additional situations can use RTP payload type to classify applications:
1. Audio and Video Conference: Both audio and video media are used in a conference, and are transmitted as separate RTP sessions with no direct coupling at the RTP level. In low bandwidth areas, the PT can be used to allow participants to receive only one medium, if they so choose.
2. Interactive Media Applications: RTP may be the base transport protocol for non-voice and video interactive media applications (ie: shared whiteboards or text editor, a distributed presentation tool, or a networked multiplayer game).
3. A telephone answering machine application needs to be able to receive a media stream from an RTP session and store it in a file.
4. An application that records a conversation or conference must be able to receive a media stream from an RTP session. It must render it on the console and store it in a file.
5. Fax over IP (FoIP): enables the interworking of standard fax machines with packet networks using either a realtime or a store and forward approach. The fax image is extracted from an analog signal and carried as digital data over the packet network. QoS mechanisms must be enforced to mitigate the effect of delay across the network, and to minimize jitter and avoid packet loss. Packet loss can severely hamper the performance of this application, because lost information could result in a failure of transmission by the fax protocol.
nBAR RTP Payload Type Classification can be used to identify these various applications and categorize them. The service guarantees for each of these application classes can now be met in terms of jitter, latency, and packet loss using QoS features: Marking, Congestion Management, Congestion Avoidance, Policing, and Shaping.
Configuration Examples for Voice and Video QoS using nBAR RTP Payload Classification
Consider a scenario in which headquarters and remote branch offices send each other voice, video, and data over WAN links.
Video traffic includes real time video conferencing as well as VODs for the e-learning portal. The e-learning application server uses Bundled MPEG codec that is configured to dynamically negotiate RTP payload Type 97 for the sessions. If there was no QoS data traffic, the streaming BMPEG traffic could starve the real time traffic and interactive data of the needed bandwidth. nBAR can identify and classify these multiple types of traffic, while QoS mechanisms (ie: Marking and Queuing) can mark and prioritize the mission-critical traffic through the network.
Figure 2. nBAR for Voice, Video and Data QoS Deployment
Class-map voiceMatch rtp protocol audioClass-map video-conferencingMatch rtp protocol videoClass-map e-learning-vodMatch rtp payload-type "97"Class-map transactionalMatch protocol notesClass-map interactiveMatch protocol citrixPolicy-map input_markClass voiceSet ip dscp efClass video-conferencingSet ip dscp af41Class e-learning-vodSet ip dscp af11Class transactionalSet ip dscp af21Class interactiveSet ip dscp af31Interface InputService-policy input input_markClass-map voiceMatch ip dscp efClass-map video-conferencingMatch ip dscp af41Class-map e-learning-vodMatch ip dscp af11Class-map transactionalMatch ip dscp af21Class-map interactiveMatch ip dscp af31Policy-map QoS-PolicyClass voicePriority percent 10Class video-conferencingBandwidth remaining percent 20Class e-learning-vodBandwidth remaining percent 35Class transactionalBandwidth remaining percent 15Class interactiveBandwidth remaining percent 30Class class-defaultFair-queueInterface OutputService-policy output QoS-Policy
Support for the nBAR Protocol Discovery MIB is currently scheduled for the Cisco IOS Software Release 12.2(6th)T.
RTP payload is the data transported by RTP in a packet. RTP Payload Classification is a powerful tool that provides customers with a stateful mechanism to identify audio and video traffic in their network. It also includes the ability to differentiate RTP traffic based on audio and video codecs that the various applications use. The PT classification also enables identification of non-voice and video applications using RTP as the packet format.
•No support exists for classifying the RTCP control traffic in a RTP session
•CEF is a prerequisite for nBAR
•nBAR is not supported in the PXF and Multicast switching paths
Cisco IOS Software Support
Cisco added this enhancement to nBAR in Cisco IOS Software Release 12.2(8)T. It is also available in Cisco IOS Software Release 12.1(11b)E.
For a list of all platforms that currently support nBAR, please visit:
RFC 1890: RTP Profile for Audio and Video Conferences with Minimal Control.
RFC 1889: RTP: A Transport Protocol for Real-Time Applications
RTP Parameters as defined by IANA: http://www.iana.org/assignments/rtp-parameters
Cisco IOS QoS Page: http://www.cisco.com/warp/public/732/Tech/qos/
Cisco IOS nBAR Page: http://www.cisco.com/warp/public/732/Tech/qos/nbar/
nBAR Documentation: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/dtnbarad.htm