INTERNATIONAL TELECOMMUNICATION UNION
STUDY GROUP 13
TELECOMMUNICATION
STANDARDIZATION SECTOR
TD 76 Rev.1 (WP 4/13)
English only
STUDY PERIOD 2009-2012
Original: English
Question(s):
17/13
Mar Del Plata, Argentina, 2-12 September 2009
TEMPORARY DOCUMENT
Source:
Rapporteur for Question 17/13
Title:
Updated draft ITU-T Recommendation Y.dpireq “Requirements of DPI in packetbased networks and NGN environment”
[Note: present word file is using many “styles and formats” beyond ITU-T template. May we please
ask the editor to map the input document for the next meeting again to the ITU-T styles
according http://www.itu.int/oth/T0A0F00000C/en ]
Contact:
Shaohua Yu
Wuhan Research Ins. of Posts and Telecoms
China
Tel: +86 27 8769 3441
Email: shuyu@wri.com.cn
Attention: This is not a publication made available to the public, but an internal ITU-T Document intended only for use by the
Member States of ITU, by ITU-T Sector Members and Associates, and their respective staff and collaborators in their ITU related
work. It shall not be made available to, and used by, any other persons or entities without the prior written consent of ITU-T.
-2TD 76 Rev.1 (WP 4/13)
Draft new ITU-T Recommendation Y.dpireq
Requirements of deep packet inspection
in packet-based networks and NGN environment
AAP Summary
[To be added before Consent]
Summary
This Recommendation specifies service requirements, capability requirements, functional
requirements and performance requirements of Deep Packet Inspection (DPI) services. The
requirements could be applied in any packet-based networks and NGN environment.
[Editor’s note: the title should be considered to include “functions” after “inspection”. Further
study will be done in next meeting]
-3TD 76 Rev.1 (WP 4/13)
Contents
1
Scope ............................................................................................................................ 4
2
References .................................................................................................................... 4
3
Terms and Definitions ................................................................................................ 4
3.1
Terms defined elsewhere .............................................................................. 4
3.2
Terms defined in this Recommendation ..................................................... 5
4
Abbreviations and acronyms .................................................................................... 7
5
Conventions ................................................................................................................. 7
6
Service requirements .................................................................................................. 7
6.1
Application management ............................................................................. 7
6.2
Analysis and Reporting ................................................................................ 7
6.3
User Bandwidth Optimization..................................................................... 8
7
Capability requirements ............................................................................................ 8
7.1
Scanning Packet at all layers ...................................................................... 8
7.2
Application Classification, Measurement, and Reporting ........................ 8
7.3
Set Policies for Controlling Traffic ............................................................. 8
7.4
Session Identification.................................................................................... 8
7.5
Modification of the Packet Header ............................................................. 8
7.6
Modification of Packet Payload .................................................................. 9
7.7
Message Reports ........................................................................................... 9
8
Functional requirements ............................................................................................ 9
8.1
The basic unidirectional DPI functional requirements ............................. 9
8.2
The basic bidirectional DPI functional requirements ............................... 11
8.3
Data plane, control plane and management plane in DPI node ............... 13
8.4
Interface to RACF ........................................................................................ 13
9
Performance requirements ............................................................................................ 13
9.1
Real-time DPI ................................................................................................. 13
9.2
Non-real-time DPI .......................................................................................... 14
Bibliography............................................................................................................................. 15
Appendix I Application Scenarios for DPI in packet-based networks and NGN
environment....................................................................................................... 16
-4TD 76 Rev.1 (WP 4/13)
1
Scope
The scope of this Recommendation includes all elements of Deep Packet Inspection (DPI), the
service requirements, capability requirements, functional requirements and performance
requirements identifying and defining (if necessary) , standard interfaces to interconnect with other
components, taking into account policy-based networks in both packet-based networks (e.g.
IPv4/v6) and NGN environment. These requirements will provide service awareness, ,control and
security by partial or entire packet scanning based on static/dynamic rules in packet-based networks
and NGN environment

NOTE: Static rules are related to provisioned policy rules by policy management and remain unchanged until
next policy configuration action. Dynamic rules are related to signalled policy rules by policy control.
2
References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published. The reference to a document within
this Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T X.200 ]
ITU-T Recommendation X.200 (1994) | ISO/IEC 7498-1:1994, Information
technology. Open Systems Interconnection. Basic reference model: The basic model.
[ITU-T Y.2111]
ITU-T Recommendation Y.2111 (2008), Resource and admission control
functions in Next Generation Networks.
[ITU-T Y.2121]
ITU-T Recommendation Y.2121 (2008), Requirements for the support of flow
state aware transport technology in an NGN.
[ITU-T Y.2901]
ITU-T Recommendation Y.2901 (2006), The carrier grade open environment
reference model.
[IETF RFC 3198] IETF RFC 3198 (2001), Terminology for Policy-Based Management.
3
Terms and Definitions
This Recommendation defines the following terms:
3.1
Terms defined elsewhere
3.1.1 Filter: In general [IETF RFC 3198]: A set of terms and/or criteria used for the purpose of
separating or categorizing. This is accomplished via single- or multi-field matching of traffic header
and/or payload data. "Filters" are often manipulated and used in network operation and policy. A
filter rule is a specific policy rule.
3.1.2 Filter/policy rules: In general [IETF RFC 3198]: A basic building block of a policy-based
system. It is the binding of a set of actions to a set of conditions, where the conditions are evaluated
to determine whether the actions are performed.
-5TD 76 Rev.1 (WP 4/13)
3.1.3 Flow ([ITU-T Y.2121]): A uni-directional sequence of packets with the property that, along
any given network link, a Flow Identifier has the same value for every packet.
3.1.4 Flow Identifier ([ITU-T Y.2121]): A vector (or n-tuple) comprising the values of a number
of elements taken from the layer 3, layer 4 header fields, encapsulation header, and label fields
attached to a packet. The Flow Identifier for a flow within a single network is unique.
[Editor’s note: in DPI applications, flow identifier may need to include the Layer 2 fields.]
3.1.5 Policy [IETF RFC 3198]: a set of rules administer, manage, and control access to network
resources.
3.2
Terms defined in this Recommendation
3.2.1 Deep Packet Inspection (DPI): a method of packet filtering that applies the filter rules
using filter conditions (see Figure. 1) based on protocol elements across multiple protocol layers
(see e.g. reference model [ITU-T X.200]) in order to find, identify, classify, or control packets with
specific data or code payloads that header packet filtering cannot detect.
NOTE – Nonstandard terms, often used in literature:
Shallow Packet Inspection“ (SPI) = L3,4HI
Medium Depth Packet Inspection“ (MPI) = L3,4HI  L4+HI
Deep Packet Inspection“ (DPI)
= L3,4HI  L4+HI  L7PI = L3,4HI  L4PI
[Editor’s note:If you really use the terms SPI and MDI, why don’t you just define them here since,
by your own text, they are generally used. But I don’t see where you use either of those two terms
in the Rec, so why go into unnecessary detail here?]
L7 SDU
(= L7 Payload)
L4 to L7 (‚L4+’)
Headers
Transport (L4)
Header
Network (L3)
Header
Link (L2)
Header
L7 Payload („IP Application Data“)
L5-7
L4
L3
L2
<L7 SDU
data>
Enforcement of Packetindividual („Flow“) Policy
Rule(s):
here – check of protocol
layer specific Policy
Condition(s)
<L4+ PCI
elements>
<L3/4 PCI
elements>
L4+ Header Inspection
(L4+HI)
L3,4 Header Inspection
(L3,4HI)
Packet Analyzer
L7 Payload Inspection (L7PI)
L4 Payload Inspection (L4PI = L4+HI  L7PI)
„Shallow Packet Inspection“ (SPI)
„Medium Depth Packet Inspection“ (MPI)
„Deep Packet Inspection“ (DPI)
Legend:
Lx
SDU
PCI
PDU
Protocol Layer x
Service Data Unit („Packet Payload“)
Protocol Control Information („Packet Heder“)
Protocol Data Unit („Packet“)
Figure 1 – Packet Inspection – Illustration of Terminology
Editor’s note: diagram may be updated dependent on clarification of L2 relation with DPI
(“there’ll be probably a split of DPI in a) L2-independent DPI with respect to end-to-end
(L3) consideration, and b) L2-dependent DPI with scope on L2 network domain specific
DPI).
3.2.2
DPI node: a network node device with DPI function.
-6TD 76 Rev.1 (WP 4/13)
Note: This network node device could be a router, switch, bridge, border gateway, or any other kind
of access devices, telecom transmission device or system, etc.
[Editor’s note: DPI function should be defined in the previous text.]
3.2.3 DPI engine: a DPI processing element including a scan function, analyzer, rule action,
rules table.
3.2.4 Rule entry: one of a set of rules which are statically predefined or dynamically generated
and used to identify and control traffic. The rule entry may include the field of policy for controlling
functions.
3.2.5 DPI analyzer: a functional implementation to perform comparison functions between the
particular packet headers and payloads of the target packet flows and a set of the rules to determine
what actions to take. DPI analyzer may provide the functionality of an Intrusion Detection
System(IDS) analyzer.
3.2.6 Rule action: an action applied to packets identified as subject to the rule by the DPI
analyzer,, which includes, for instance, the following:

Discard the packet (Silently or otherwise)

Classify the flow for reporting to other network functions (e.g. measurement and
management)

Take action to support control plane and management plane or security: prioritize, block,
shape, schedule, etc

Perform dynamic rule building and modification
[Editor’s note: the text need to be refined]
3.2.7 Rules table: a database including multiple rule entries. These rules are defined and
classified at different levels (protocol layer 2 to layer 7), and the different functions at the same
layer to meet the carrier gradeinterworking requirements [ITU-T Y.2901].
[Editor’s note: it was questioned whether the 2nd sentence should be part of the “rules table”
definition itself because it is more related to the definition of a (policy) “rule” (which is now
addressed by clause 3.1.2). Should be clarified …]
3.2.8 Mediation Unit: a mediation functional unit performing the bi-directional DPI. This unit is
connected to each Rules table, rule action and analyzer to deal with the end-to-end association
between outgoing stream and the relevant incoming stream.
[Editor’s note: detailed description should be provided on the bi-directional DPI definition]
3.2.9 L3,4 Header Inspection (L3,4HI): policy rule(s) with policy conditions using protocol
control information (PCI) elements of the network layer or/and transport layer only.
3.2.10 L4+ Header Inspection (L4+HI): policy rule(s) with policy conditions using only PCI
elements above the transport layer.
3.2.11 L4 Payload Inspection (L4PI): policy rule(s) with policy conditions based on application
data.
NOTE – L4PI relates to the union of L4+HI and L7PI policy conditions.
3.2.12 L7 Payload Inspection (L7PI): rule(s) with policy conditions based on application data.
[Editor’s note: the above term definitions should be modified if other SDOs already have DPI
related definitions.]
-7TD 76 Rev.1 (WP 4/13)
[Editor’s note: I don’t think you use these four terms (3.2.9 – 3.2.12) in the document. Consider
deleting them]
4
Abbreviations and acronyms
This Recommendation uses the following abbreviations and acronyms:
DA
Destination Address
IP
Internet Protocol
P2P
Peer to Peer
DPI
Deep Packet Inspection
NGN
Next Generation Network
QoS
Quality of Service
IDS
Intrusion Detection System
RACF
Resource and Admission Control Functions
PEP
Policy Enforcement Point
DSLAM
Digital Subscriber Line Access Multiplexer
BRAS
Broadband Remote Access Server
SBC
Session Border Controller
ER
Edge Router
GGSN
Gateway GPRS Support Node
5
Conventions
TBD
6
Service requirements
6.1
Application management
DPI node shall perform traffic signature analysis by inspecting all packets for new application
signatures, score up the signatures, and append them to the relevant database. Data collected by the
DPI node shall be relevant to analysis of subscriber usage, service utilization and QoS on a per
application basis.
[Editor’s note: “score up” should be clarified in further contributions]
6.2
Analysis and Reporting
DPI node is required to analyze current usage patterns and provide report, including classification
of applications, performance measurement, how subscribers are using the network and how long per
application, traffic peak loads on network etc. DPI should have the capability of data collection,
statistical analysis, which should provide statistic reports based on use, application, link or network
address (Source IP address, Destination IP address, etc.).
-8TD 76 Rev.1 (WP 4/13)
6.3
Bandwidth Optimization
DPI node can manage bandwidth demand and optimize it according to how and when and by
whom. As a result, DPI node can optimize network performance during off-peak and peak periods;
manage network applications to improve the user experience.
[Editor’s note: make sure if these sub-clauses have the overlapping, texts need to be refined]
7
Capability requirements
7.1
Scanning Packet at all layers
DPI shall scan all packets at all layers, recognizing applications and transactions that traverse
multiple packets as well as those in a single packet. The results of DPI scanning shall support rule
actions identified in the relevant rules table, such as:

Identification of user, including user account, ID of equipment, MAC address, IP address, etc;

Identification and classification of applications and corresponding protocol, for example: P2P,
VoIP and multimedia.

Identification of special content based on recognition of a keyword as well as recognition of
abnormal content (i.e. content that is outside the rules table’s parameters of normal traffic);
[Editor’s note: Guess that the general result of a “scanning packet” activity is the identification of
“policy actions” (as part of the rules table). Above listed functions may be then subsequent
activities due to that policy actions … ]
7.2
Application Classification, Measurement, and Reporting
DPI is required to to classify applications, measure performance, and generate reports. This
provides network managers with the visibility essential for strategic traffic planning and policy
based charging, etc.
[Editor’s note: different requirements may be for DPI itself or DPI system. May need to add
general note]
7.3
Controlling Traffic
Based on packet payload scans, application classification, and a set of policies for managing traffic,
DPI shall be capable of supporting mechanisms to trigger the actions of prioritizing and/or
controlling traffic. This function provides one of the fundamental controls that used for offering
tiered services and for controlling application data flow, which could be traffic shaping and ratelimiting, redirect the traffic, and discard the traffic according to QoS strategy to ensure high-priority
services, such as modifying priority information element.
[Editor’s note: further investigation should be done on the DPI actions]
7.4
Session Identification
DPI shall provide the information to analyze session behaviour, track session state changes if
necessary, monitor individual subscriber’s quality of experience or end-to-end QoS and
performance parameters in real-time on a complete session-by-session basis from Layer 2 to Layer
7.
[Editor’s note: the concept of a “session” is not yet outlined, thus generic here. It might be worth to
provide concrete session examples like e.g. an “IPTV session”, “RTP session”, “multimedia
session with multiple, media-type individual RTP sessions”, “RTSP session”, etc. … ]
-9TD 76 Rev.1 (WP 4/13)
7.5
Modification of the Packet Header
It is optional that DPI be capable of modifying packet headers in order to enable new
services[note:examples needed here] or prevent attacks. It is optional that this capability be
configurable, programmable, and sufficiently granular to allow maximum flexibility in packet
processing.
7.6
Modification of Packet Payload
DPI is required to be able to modify payload. Based on dynamic packet and session monitoring,
DPI packet content modification can carry out functions such as removing viruses
7.7
Reporting capability
DPI is required to support the mechanisms to report results of DPI with all the appropriate content
and envelope information to be sent to the network manager.
[Editor’s note: DPI is thus required to “generate messages with e.g. alert information” as a
reporting capability towards e.g. management plane entities. Further text may be helpful … ]
8
Functional requirements
8.1
The basic uni-directional DPI functional requirements
Figure 2 illustrates the relationship between DPI and other components within the packet-based
networks and NGN environment.
RACF
Security
Charging
SeChargi
ng
DPI engine
Scan
Rules Table
Analyzer
Rule Action
Other functions
Figure 2a – Uni-directional DPI within the packet-based networks and NGN environment
- 10 TD 76 Rev.1 (WP 4/13)
Users of DPI
scanning data
Security Functions
DPI Node
Function
Management Functions
Others
Rules Table
DPI Engine
Scan
Analyze
Apply Rule
Figure 2b – Uni-directional DPI within the packet-based networks and NGN
environment
[Editor’s note: during this meeting, Figure 2b has been proposed which does not include the rule
table in the rule engine. To be discussed in the next meeting.]
8.1.1 DPI engine function: a uni-directional DPI processing functional element including a scan
function, analyzer, rule action, rules table in a DPI node as shown in Figure 2a (or Figure 2b).
8.1.2 Rule entry: one of a set of rules which are statically predefined or dynamically generated
and used to compare the particular overhead or contents of the packet flows with a set of the rules to
determine if the string matching is successful or not.
8.1.3 DPI analyser function: a functional element in a DPI node to perform comparison
functions between the particular overhead or contents of the packet flows and a set of the rules to
determine what the results are.
8.1.4 Rule action: an action after analyzing according to the related rule actions, which include
for instance the following:

Discard the packet (Silently or otherwise)

Traffic classification, measurement, and reporting and management

Resource management, admission control and filtering

Prioritization, blocking, shaping and scheduling

Dynamic rule building and modification
[Editor’s note: wording may be improved, e.g. the execution of a rule action is the consequence of
valid rule conditions … the entry in a row of a rules table consists of policy condition(s) and
policy action(s) … ]
- 11 TD 76 Rev.1 (WP 4/13)
[Editor’s note: silently discard should be clarified]
8.1.5 Rules table function: a database functional element including the multiple rule entries.
These rules are defined and classified at the different levels (layer2-layer7), and the different
functions at the same layer to meet the carrier grade interworking requirements [ITU-T Y.2901].
8.2
The basic bi-directional DPI functional requirements
8.2.1 DPI engine function: a bi-directional DPI processing function including a scan function,
analyzer, rule action, rules table in a DPI node as shown in Figure 3.
8.2.2 Rule entry: one of a set of rules which are statically predefined or dynamically generated
and used to compare the particular overhead or contents of the packet flows with a set of the rules to
determine if the string matching is successful or not.
- 12 TD 76 Rev.1 (WP 4/13)
8.2.3 DPI analyser function: a functional element in a DPI node to perform comparison
functions between the particular overhead or contents of the packet flows and a set of the rules to
determine what the results are.
DPI Engine
Rules
Table
Scan
Analyzer
Rule Action
Packets Input
Packets Output
Input Queue
Output Queue
Mediation
Packets Output
Packets Input
Output Queue
Rule
Action
Input Queue
Analyzer
Scan
Rules Table
DPI Engine
Figure 3 – The bi-directional DPI function and architecture
8.2.4 Rule action: an action after analyzing according to the related rule actions, which include at
least the following:

Discard packet (Silently or otherwise)

Traffic classification, measurement, and reporting and management

Resource management, admission control and filtering

Policy-based prioritization, blocking, shaping and scheduling

Dynamic rule building and modification
- 13 TD 76 Rev.1 (WP 4/13)
8.2.5 Rules table function: a database functional element including the multiple rule entries.
These rules are defined and classified at different levels (layer2-layer7), and the different functions
at the same layer to meet the carrier grade interworking requirements [ITU-T Y.2901].
8.2.6 Mediation function Unit: a functional unit performing the bi-directional DPI. This unit is
connected to each Rules table, rule action and analyzer to deal with the end-to-end association
between outgoing stream and the relevant incoming stream.
[Editor’s note: use reference to the terms and definitions and specific requirements should be given
in this clause]
8.3
Data plane, control plane and management plane in DPI node
DPI node has data, control and management plane, and data plane can work either uni-directional or
bi-directional mode. A DPI node shall recognize two kinds of packets: data packets, which belong
to customers and carry customer traffic, and control and management packets, which belong to the
network and are used to create and operate the network. The two kinds of packets traverse a
“common pipe” (or are called “in-band”) or logically separate data channels from “out-of-band”
control channels.
The requirements of management plane should be:

User-based management: manage user’s ID information; maintain corresponding relationship
between user and user’s applications.

Management of Application and service: generate, modify and publish application template;
maintain the relationship between application and strategy; provide and manage reservation of
user’s service

Management of strategy: manage the strategies predefined or generated dynamically. These
strategies may include: strategy of application identification, strategy of application control,
strategy of user management, etc;

Management of administration authority: to support hierarchical management, different
administrator has different management authority.
8.4
Interface to RACF
The RACF [ITU-T Y.2111] provides an abstract view of transport network infrastructure to
Resource Control Functions and makes Service Providers to the details of transport facilities such as
network topology, connectivity, resource utilization and QoS mechanisms/technology etc.
[Editor’s note: the general description of requirements on the interface with RACF should be
given]
9
Performance requirements
9.1
Real-time DPI
9.1.1
Node-internal transfer delay
DPI related policy rules are applied to each individual packet of a particular packet flow. Such kind
of policy enforcement introduces basically additional service and waiting time in the packet
forwarding path of a packet node (e.g. an IP hop) with “DPI engine” support (i.e., a policy
enforcement point (PEP) providing DPI). The performance metric node-internal transfer delay
represents the packet transfer delay by the network element itself.
- 14 TD 76 Rev.1 (WP 4/13)
NOTE 1 – Example of IP node: the transfer delay of a DPI node may be fundamentally greater than the
transfer delay of a legacy IP node (i.e. an IP hop or router according IETF RFC 1812) due to the
additional service function on top of native IP forwarding functionality.
Qualitative performance requirement:

the transfer delay (inclusive the additional service time due to DPI processing) shall not exceed
any end-to-end real-time requirements.
NOTE 2 – Such a packet forwarding requirement is also colloquially known as “wirespeed processing”.
NOTE 3 – Such a performance objective may limit the number of enforced policy rules per packet (just due
to the limited budget of service time).
Editor’s note 1: any quantitative performance requirement(s) may complement above qualitative
statements. Contributions are solicited.
Editor’s note: how to achieve the end-to-end real-time requirements by single node behaviour, need
more clarification
Editor’s note 2: existing ITU-T performance metrics should be cross-checked whether they may be
re-used for DPI-specific performance requirements. Below a list (not exhaustive) of
potential relevant documents:
o Y.1540 Internet protocol data communication service - IP packet transfer and
availability performance parameters
o Y.1541 Network performance objectives for IP-based services
o Y.1542 Framework for achieving end-to-end IP performance objectives
o Y.1543 Measurements in IP networks for inter-domain performance assessment
o Y.1544 Multicast IP performance parameters
o Y.1560 Parameters for TCP connection performance in the presence of middleboxes
o Y.1561 Performance and availability parameters for MPLS networks
o Y.1562 Framework for higher layer protocol performance parameters and their
measurement
Contributions are solicited.
9.1.2
xxx
Editor’s note: other performance metrics (e.g. packet loss) were mentioned in the Mar del Plata
meeting discussions. Contributions are solicited.
9.2
TBD
Non-real-time DPI
- 15 TD 76 Rev.1 (WP 4/13)
Bibliography
[b-ITU-T Y.2011]
ITU-T Recommendation Y.2011 (2004), General principles and general
reference model for Next Generation Networks.
[b-ITU-T Y.2001]
ITU-T Recommendation Y.2001 (2004), General overview of NGN.
[b-ITU-T Y.2021]
ITU-T Recommendation Y.2021 (2006), IMS for Next Generation
Networks.
[b-ITU-T Y.2091]
ITU-T Recommendation Y.2091 (2007), Terms and definitions for Next
Generation Networks.
[b-ITU-T X.200]
ITU-T X.200 (1994) | ISO/IEC 7498-1:1994, Information technology . Open
Systems.Interconnection. Basic reference model: The basic model.
[b-ITU-T X.211]
ITU-T X.211 (1995) | ISO/IEC 10022:1996, Information technology . Open
Systems Interconnection. Physical service definition.
[b-ITU-T Y.2121]
ITU-T Recommendation Y.2121 (2008), Requirements for the support of
flow state aware transport technology in an NGN.
[b-ITU-T Y.2901]
ITU-T Recommendation Y.2901 (2006), The carrier grade open
environment reference model.
[b-IETF RFC 3198] IETF RFC 3198 (2001), Terminology for Policy-Based Management.
[b-IETF RFC 791]
IETF RFC 791 (1981), Internet Protocol . DARPA Internet Program .
Protocol specification.
[b-IETF RFC 2460]
IETF RFC 2460 (1998), Internet Protocol, Version 6 (IPv6). Specification.
______________
______________
- 16 TD 76 Rev.1 (WP 4/13)
Appendix I Application Scenarios for DPI in packet-based networks and NGN environment
(This appendix does not form an integral part of this Recommendation)
I.1 Application scenarios of DPI in packet-based network
In packet-based networks, it is imperative to identify different kinds of services and apply different
control mechanisms to provide differentiated services for its subscribers. As a control point in
packet forwarding, DPI is often deployed in the following application scenarios, as illustrated in the
subsections.
I.1.1 Differentiated services based on service identification
One of DPI’s fundamental functions is to provide differentiated services for subscribers in an
operator’s network and enterprise network. Service identification is the prerequisite for operators to
provide differentiated services for its customers. In Figure I.1, DPI is deployed at different layers in
the operator’s networks and is transparent to the subscribers.
Editor’s note: Does the term “differentiated services” imply just the IETF DiffServ model, or is it
used here in a more general meaning? Should be made more clear in the text.
In such scenario, DPI is often deployed as a real-time operation (for real-time and non-real-time
end-to-end applications) which makes all services visible and easy to manage. Traditionally, packet
forwarding can unveil some information about the carried traffic by extracting and parsing the basic
protocol information such as connection address information like e.g. IP addresses (source,
destination) and other low-level connection states. This information typically resides in the packet
header itself and consequently reveals the principal communication intent, such as HTTP, FTP, and
email services, as the port number often indicates the carried services.
Figure I.1- Scenario of differentiated services at the example of an IP-based packet network
with DPI support
- 17 TD 76 Rev.1 (WP 4/13)
As depicted in Figure I.1, user A, whose available bandwidth is e.g. 2 Mbit/s, has different network
needs including VoIP, mail/web, pplive, p2p and so on. When the user’s application traffic flows
pass through the DPI device in the network, the DPI will implement differentiated services in
accordance with the predefined control list (i.e., the policy rules table for DPI in the packet
forwarding path) and the identification results.
However, from the perspective of service awareness, it is insufficient to reach any applicationrelated service identifications, especially for the current P2P popular services, like Skype, a VoIPbased service which prevails almost everywhere on the internet; and some of the download services,
such as eDonkey and eMule, which often consume a lot of bandwidth, lead to congestion and
packet loss for authorized services.
To achieve the purpose of service awareness, DPI is applied to probe deeper into the packets in a
multi-services stream for e.g. content analysis. Ways of service identification are listed below, as it
is often used in most service control scenarios, though sometimes they are not sufficient to make the
most successful decisions as what kinds of services being carried:
(1) Analysis based on layer 4 port number (in case of IP);
this is the simplest way in classifying the carried services;
(2) Analysis by strings match;
sometimes a typical string which indicates the application type is embedded in the traffic,
thus deep inspection into the packet content should be involved to find the exact match
which indicates the kinds of services being carried;
(3) Analysis by numerical nroperties.
Analysis by numerical properties involves the investigation of arithmetic and numerical
characteristics within a packet, and of a packet or several packets. Some examples of
properties analyzed include payload length, the number of packets sent in response to a
specific transaction, and the numerical offset of some fixed string (or byte) value within a
packet.
(4) Analysis by behaviour and heuristics.
In such kinds of application scenarios, DPI is deployed as an intelligent component in
service identification. In a generic application of this kind, behavioural analysis refers to the
way a protocol acts and operates, while heuristic analysis typically boils down to the
extraction of statistical parameters of examined packet transactions. In some scenarios,
behavioural and heuristic analyses are combined to provide improved services identification
capabilities.
In most application scenarios, services after identification can be categorized and marked as one of
the following attributes:
(1) Critical and time-sensitive, such as VoIP services;
(2) Critical but not time-sensitive, such as management and routing information;
(3) Best effort services, such as traditional services like HTTP, FTP, and Email, etc.;
(4) Services unidentified.
Under current multi-services network application scenarios, P2P is the prevalent services that often
results in network outrage, such as congestion, collapse, and deprives most subscribers of fair
network access, and so on.
- 18 TD 76 Rev.1 (WP 4/13)
Based on identification of peer-to-peer (P2P) services, DPI can apply some policy to ban or limit
P2P traffic, such as:
(1) P2P download application (a retrieval service);
(2) P2P stream application (a streaming service);
(3) Instant message;
(4) VoIP, including: Skype, ET, UUPhone, etc; or
(5) Traffic anomalies, which consumes a lot of the bandwidth not permitted by service
providers.
From the perspective of service control, DPI is often used as an auxiliary tool for providers to
personalize services to its users, including: new services creation, content filtering to avoid
offending the subscribers, resource allocation varying from application to application, etc.,
including:

Limited service packages based on subscriber awareness in accordance with SLA;

Expanded service packages based on subscriber awareness in accordance with SLA;

Tiered service packages based on time of day and allocatted bandwidth amounts for various
applications;

Additional provisioned bandwidth dedicated for a specific user application;

QoS assurance for all traffic from a specific user; or e.g.
QoS assurance for traffic of a certain type or from a certain source for a specific user.As depicted in
I.1.2 Traffic monitoring
Another important scenario where DPI is widely deployed is that DPI is often used as the key
control points enabling traffic management: scanning, filtering or forwarding packets based on
services identified protocol layer 2 to layer 7 (for e.g. the case OSI X.200 basic reference model).
From the perspective of packet forwarding, each service will be delivered as one or more flows in
the network. To better control the traffic, a pre-configured or intelligently deduced policy is often
applied which makes all the identified services under the operator’s supervision as desired. When
the services are identified, different traffic of different services will be forwarded based on their
attributes, for example, they can be forwarded along different path to their destinations based upon
their SLA requirements.
Another aspect of traffic management is resource allocation as resources can be proportionally
allocated based on the subscribers’ profile and services control policy, as it is showed in Figure
I.2.
- 19 TD 76 Rev.1 (WP 4/13)
Figure I.2  DPI used for the purpose of traffic monitoring
I.1.3 Security
As a basic requirement, DPI is deployed to provide the capabilities to identify prohibited services,
which often results in malicious traffic over the network, as the traffic would often degrade user
performance, drain network resources, impair infrastructure, and finally make the network
unavailable to its subscribers. Most of the malicious traffic disguises itself as normal traffic and is
extremely bandwidth consuming, such as: Outgoing spam, IP scanning and port scanning, etc.
Figure I.3 shows a typical application scenario that when malicious traffic is identified, it will be
removed by the DPI component from the traffic thus preventing it from spreading into the network.
Figure I.3  DPI deployed to filter out malicious traffic
Therefore, DPI in such kinds of application scenarios provides the packet forwarding process with
the following capabilities:
(1) On-line monitoring, tracking and analyzing possible connections, since sudden, rapid increases
in active connections are indicative of many forms of prohibited services.
(2) Real-time identification of malicious attacks. Through peering deep into the traffic, DPI alerts
the network administrators of possible attacks and providing a range of monitoring and
detection tools to track attack launchers, applications, flows, connections, ports, protocols,
- 20 TD 76 Rev.1 (WP 4/13)
trends and other parameters. Meanwhile, some of the attack features if possible, should also be
feed backed to the forwarding engine to make resources unavailable to the attackers.
(3) Real-time reporting of possible attacks. Through an automated and flexible early-warning
mechanism DPI is applied to inform network administrators of potential threats in advance,
enabling them to take appropriate actions against possible attacks. Thus, DPI may be
fundamentally a basic function of an intrusion detection system (IDS).
Mitigation of threats through enforcement. In such scenario DPI is deployed to yield productive
measures against possible attacks. Under such circumstances, mitigation of threats must be
implemented to avoid the infiltration of the malicious traffic into the network, as it might make the
network more vulnerable and even collapse from resource exhaustion.
I.1.4 Traffic statistics & services-based billing
Through the perceptions to subscribers and applications, DPI can provide comprehensive statistics
of application flows, which can help the network operator master all the information about network
load, user’s behavioural characteristics, and the bandwidth occupation of every application. Service
providers often charge their customers based on the services they subscribed as different services
may have different billing policies. For example, time-critical and delay-sensitive services often
comparatively consuming more resources and will be charged higher while legacy internet services
such as E-mail, Http may exert fewer demands on resources and will be charged much lower. From
the perspective of operators, as depicted in figure I.4, this kind of billing issues are often termed as
services-based billing
Figure I.4 – Traffic statistics& Services-based billing
II. Application scenarios of DPI in NGN
Currently there are few NGN deployments around the world. We can only deduce some of its
possible application scenarios based on its already defined 2-stratum architecture ([ITU-T
Y.2012])..
Figure II.1 illustrates an example how DPI can be deployed in an NGN environment. The functional
blocks included in the dashed box are components that are closely related to the process of both DPI
and packet forwarding: the blocks of policy control consists of subscriber policy control and its
corresponding policy repository; the block of resource admission control subsystem is responsible
for subscriber authentication/admission and resource allocation while the block of DPI will carry
out all the functions of packet header analysis and content scanning.
- 21 TD 76 Rev.1 (WP 4/13)
Figure II.1  Example of DPI’s application scenario within the context of NGN [ITU-T
Y.2012]
As NGN is a seamlessly architected into 2 stratum, as described in II.2, DPI resides in packet
forwarding plane, while resource and admission control is a basic function of control plane, with
policies being stored in the policy repository. Whenever a new application is detected, DPI will
generate a request for resource demand and deliver it to the control plane for resource allocation,
even in some cases, DPI can be used to reroute the packets to satisfy SLA requirement.
Service control functions
Service stratum
Transport stratum
Resource and admission
control functions
s
N
G
N
re
ht
O
NACF
CPE
DPI
DPI Transport functions
Figure II.2  Example of DPI’s operation within the environment of NGN
Figure 6 illustrates example locations of DPI policy rule enforcement, e.g. CPE- or host-based on
customer premises or network based DPI.
In the scenario above, when DPI is used in the scenario for resource allocation, there are some
standardized interfaces within the network architecture. Resource reservation request originated
from DPI will be generated whenever a new service is identified. DPI then will issue this request to
the SCF (service control function) which later on will trigger a request message and delivered to the
RACF for resource demand[3]. For example, bandwidth allocation and QoS guarantee for a realtime VoIP application. Under such circumstances, DPI is deployed to fulfil the following goals:
(1) Monitor network and bandwidth usage. DPI is applied to automatically discover the
application and determine the protocol that might affect the network performance and
bandwidth usage.
- 22 TD 76 Rev.1 (WP 4/13)
(2) Define the policies in accordance with the identified application. Policies can be seen as the
tie between application and resource requirements, which in turn determines the QoS
attributes of applications, among them are: minimum and maximum bandwidth, traffic
prioritization, etc.
(3) Enforce the policy and make the policy repository up-to-date at any time.
From the perspective of NGN, DPI is applied to identify the application and generate the raw
resource demand; all the remaining processing, including message triggering, delivery and
processing will follow the procedures as defined in section 9, ITU-T recommendation of [Y.2111].
III The deployment of DPI in packet-based network
As part of application scenario, how DPI components are installed in the network is a big concern,
and what functions DPI can fulfil are something that also should be mentioned.
[Editor’s note: Which should illustrate in more detail “big concern”, if not, readers may
questioning what exactly concerns …]
III.1 DPI’s deployment in packet-based network
As shown in figure II.3, a DPI component can be deployed in a network either as an in-line device
or a by-pass device; it depends on the operator’s purpose in using them.
Figure II.3 Scenario of DPI’s Deployment in packet-based network
III.2 DPI used as a bi-directional tool for service control
With its bi-directional rule tables, DPI can act on both incoming and outing traffic bi-directionally.
See [ITU-T Y.dpireq] concerning the clarification of uni- versus bi-directional DPI.
- 23 TD 76 Rev.1 (WP 4/13)
III.3 DPI used as a nexus among ICP, ISP and subscribers
DPI is not a separate node but instead a nexus among Internet service providers (ISP), Internet
content providers (ICP) and subscribers. However, the interaction among those three players are
totally different, their priorities of generating and operating DPI rules are arranged in order with
ISPs having the highest priority while subscribers with the lowest. Subscribers can only determine
what kinds of services they want to receive; and ICPs provide the kinds of services for its
customers, while ISPs have the highest priority in traffic control，as depicted in Figure III.1.
Figure III.1－ DPI works as a nexus among ICP, ISP and subscribers