Voice Over IP Protocol (VoIP)

Chapter 3
The Higher Institute of Industry
Postgraduate Program
Course Instructor
Dr. Majdi Ali Ashibani
Email: mashibani@yahoo.co.uk
Next Generation Networks (NGN)
course agenda
Introduction
PSTN
Mobile IP
GPRS/UMTS
4G mobile networks
VOIP
VOIP QoS issues
Multimedia Control Protocols
H323
H324
Session Initiation Protocol (SIP)
Soft Switching
Convergent Networks

Service Delivery Platforms (SDP)
IP Multimedia Subsystem (IMS)
OSA/Parlay
Next Generation Billing Systems
Ad Hoc Networks
Ad hoc routing issues
Ad hoc network security
What Is VoIP?
The term VoIP (Voice over Internet Protocol)
describes the use of the Internet Protocol (IP)
to transfer speech between two or more sites.
Internet telephony Is simply a means of
making telephone calls over a data network
instead of over the traditional analogue public
switched telephone network (PSTN).
IP WAN/
INTERNET
VoIP
VoIP
Brief history
The term VoIP was first used by the VoIP Forum (a group of
major companies including Cisco, Vocalec and 3Com) to
promote and develop the use of the International
Telecommunications Unions (ITU) H.323 protocol.
February 1995 when Vocaltec released its Internet Phone
software (PC-to-PC internet telephony).
Internet telephony has made a number of important
advances since 1995. Many software developers now offer
PC telephony software but, more importantly, gateway
servers are emerging to act as an interface between the
internet and the PSTN, these gateway servers enable users
to communicate via standard telephones over great
distances without using the long distance telephone
network.
How does VoIP work?
When a traditional call is made using the PSTN,
the analogue lines are kept open between the
two callers for the entire duration of the call;
this is called a circuit. This small segment of
the network is exclusively used for this call and
will be unavailable to any other users until the
call has finished.
VoIP does not require such dedicated circuits
as it translates voice signals into packets of
digital data. These packets are then transmitted
over Ethernet or wireless networks, with no part
of the network used exclusively by callers.
VoIP Features
Lower Cost
Internet technology makes available to anyone
with a personal computer and modem the ability
to bypass the long distance PSTN.
long distance phone calls become very
inexpensive.
For companies
Single network for data and voice.
Less infrastructure .
Less managing, maintenance.
Integrated voice/computing customer service.
Voice calls to other HQ/partners over the Internet
instead of telecoms
VoIP Features
Greater Efficiency
The conventional circuit-switched technology of the
PSTN requires a circuit between the telephone
companys switch and the customers premise to be
open and occupied for the entire duration of a call,
regardless of the amount of information transmitted.
In contrast, on IP networks, all content -- whether
voice, text, video, computer programs, or numerous
other forms of information -- travels through the
network in packets that are directed to their
destination by diverse routes, sharing the same
facilities most efficiently (good bandwidth
utilization).
VoIP Features
Higher Reliability
In some respects, IP networks also offer the
potential for higher reliability than the circuit-
switched network because IP networks
automatically re-route packets around problems
such as malfunctioning routers or damaged lines.
Also, IP networks do not rely on a separate
signaling network, which is vulnerable to outages.
VoIP Features
Supporting Innovation
IP is a nonproprietary standard agreed on by
hardware and software developers, and is free to be
used by anyone. This open architecture allows
entrepreneurial firms to develop new hardware and
software that can seamlessly fit into the network. In
contrast, the circuit switched network operates as a
closed system, thus making it more difficult for
innovative developers to build and implement new
applications.
VoIP Components
VoIP Components
Gateway converts signals from the traditional telephony
interfaces (POTS,T1/E1, ISDN, E& M trunks) to VoIP.
Terminal that has native VoIP Support and can connect
directly to an IP network.
IP phone.
PC.
Server provides management and administrative functions
to support the routing Of calls across the network.
Gatekeeper ( H.323 ).
SIP server ( SIP/SDP).
IP network provides connectivity Between all the terminals.
private network.
Intranet.
Internet.
VoIP technologies
VoIP technologies fall into two general categories:
Centralized: centralized models follow a client/server
architecture.
Distributed: models are based on peer-to-peer interactions.
All VoIP technologies use common media by transmitting voice
information in RTP packets over IP.
They also agree by supporting a wide variety of compression codecs.
The difference lies in signaling and where call logic and call state are
maintained, whether at the endpoints or at a central intelligent server.
Distributed models tend to scale well and are more resilient
(robust) because they lack a central point that could fail.
Centralized call control models offer easier management and can
support traditional supplementary services (such as
conferencing) more easily, but they can have scaling limits
based on the capacity of the central server.
Distributed VoIP call management schemes include H.323 and SIP.
Centralized call management methods include Media Gateway Control
Protocol.
VoIP Architecture

VoIP over Ethernet VoIP over Wireless Link
Application
Application Presentation Voice Codec Voice Codec
Session
Transport Transport
RTP
UDP
RTP
UDP
Network Network IP IP
Datalink Datalink Ethernet 802.11
Physical Physical
Internet Model OSI Model
Internet Multimedia Protocol stack
Voice Codec Overview
Voice communication is analog, while data
networking is digital. The process of converting
analog waveforms to digital information is done
with a coder-decoder (CODEC, which is also
known as a voice coder-decoder [VOCODER]).
There are several approaches to digitizing the
voice samples. These approaches vary by the
information that is transmitted, the complexity of
the algorithm, and the assumptions of the sound
being transmitted (e.g. voice, fax, music). Different
applications select the best voice coding method
based on what needs to be accomplished, the
amount of bandwidth that the underlying network
can supply, and how much the user wants to
spend for the call.

Pulse Code Modulation
speech bandwidth 300-3800 Hz (approx 4 kHz).
Samples every 125 s is 8000 times per second (Nyquist
rate).
The resulting data stream is 8 bits 8000 = 64,000 bits/sec.
11101001
11010100
00110101
0 125 250 375 500 625 750 s

11111111







00000000
00101001
00001011
00111010
Type of Voice Coders
Waveform codecs
Time domain:
compression techniques that exploit redundant
characteristics of the waveform itself.
Sample and code.
High-quality and not complex.
Large amount of bandwidth.
Examples:
Pulse Code Modulation (PCM).
Differential Pulse Code Modulation (DPCM).
Adaptive Differential Pulse Code Modulation (ADPCM).
Type of Voice Coders
Waveform codecs
Frequency domain:
Instead of sampling the waveform in fixed units of time,
the sound is represented in units of frequency.
This works well for speech since vowels are low
frequency and consonants are high frequencies .
Type of Voice Coders
source codecs
compress speech by sending only simplified
parametric information about the original speech
excitation and vocal tract shaping.
Low bit rates, but sounds synthetic.
Higher bit rates do not improve much.
Examples:
Linear Predictive Coding (LPC) .
Type of Voice Coders
Hybrid codecs
Use a mixture of Both.
Adequate sound quality.
Medium bit rates.
Examples:
Code Exited Linear Prediction (CELP) .


Mean Opinion Score (MOS)
Number indicating how people feel about the
quality of the voice signal for that algorithm
(higher is better).
Compression Method Bit Rate (kbps) Processing (MIPS) Compression Delay(ms) MOS Score
G711 PCM 64 0.34 0.75 4.1
G726 ADPCM 32 14 1 3.85
G728 LD-CELP 16 18 5 3.61
G729 CS-ACELP 8 20 10 3.92
G729a CS-ACELP 8 10.5 10 3.7
G723.1 ACELP 5.3/6.3 16 30 3.65
Real-time Transport Protocol (RTP)
RTP specifies a packet structure for packets
carrying audio and video data
RFC 1889.
RTP packet provides
payload type identification
packet sequence numbering
Timestamping
RTP runs in the end systems.
RTP packets are encapsulated in UDP segments
Interoperability: If two Internet phone
applications run RTP, then they may be able to
work together
RTP Header
RTP - Overheads
RTP Voice Example
Consider sending 64 kbps PCM-encoded voice
over RTP.
Application collects the encoded data in chunks,
e.g., every 20 msec = 160 bytes in a chunk.
The audio chunk along with the RTP header form
the RTP packet, which is encapsulated into a
UDP segment.
RTP header indicates type of audio encoding in
each packet
sender can change encoding during a conference.
RTP header also contains sequence numbers
and timestamps.
RTP Header Fields
Payload Type (7 bits):
Indicates type of encoding currently being used.
If sender changes encoding in middle of
conference, sender informs the receiver through
this payload type field.
Payload type 0: PCM mu-law, 64 kbps
Payload type 3, GSM, 13 kbps
Payload type 7, LPC, 2.4 kbps
Payload type 26, Motion JPEG
Payload type 31. H.261
Payload type 33, MPEG2 video
RTP Header Fields
Sequence Number (16 bits):
Increments by one for each RTP packet sent.
May be used to detect packet loss and to restore
packet sequence.
RTP Header Fields
Timestamp field (32 bytes long):
Reflects the sampling instant of the first byte in the
RTP data packet.
For audio, timestamp clock typically increments by one for
each sampling period (for example, each 125 uses for a 8
KHz sampling clock)
if application generates chunks of 160 encoded samples,
then timestamp increases by 160 for each RTP packet
when source is active. Timestamp clock continues to
increase at constant rate when source is inactive.

RTP Header Fields
SSRC field (32 bits long):
Identifies the source of the RTP stream.
Each stream in a RTP session should have a
distinct SSRC.

Real-time Control Protocol (RTCP)
Works in conjunction with RTP.
Each participant in RTP session periodically
transmits RTCP control packets to all other
participants.
Each RTCP packet contains sender and/or receiver
reports
report statistics useful to application
Statistics include number of packets sent, number
of packets lost, interarrival jitter, etc.
Feedback can be used to control performance
Sender may modify its transmissions based on
feedback

Real-time Control Protocol (RTCP)
For an RTP session there is typically
a single multicast address all RTP
and RTCP packets belonging to the
session use the multicast address.
RTP and RTCP packets are
distinguished from each other
through the use of distinct port
numbers.
To limit traffic, each participant
reduces his RTCP traffic as the
number of conference participants
increases. (Otherwise control
signalling would not scale to large
numbers of receivers.)
RTCP Packet Types
Receiver Report(RR):
Includes the fraction of packets lost, last sequence
number received, average inter-arrival jitter.
Sender Report (SR):
Includes the synchronisation source (SSRC)
identifier of the RTP stream, the current time, the
number of packets sent, and the number of bytes
sent.
Source Description (SDES):
e-mail address of sender, sender's name, SSRC of
associated RTP stream.
Provide mapping between the SSRC and the
user/host name.
Teardown signal (BYE)
Application specific information (APP)
Stream Synchronisation
RTCP can synchronize different media streams
within an RTP session.
Consider video-conferencing application for which
each sender generates one RTP stream for video
and one for audio.
Timestamps in RTP packets tied to the video and
audio sampling clocks (not tied to the wall-clock
time)
Each RTCP sender-report packet contains (for the
most recently generated packet in the associated
RTP stream):
timestamp of the RTP packet
wall-clock time for when the packet was created.
Receivers can use this association to synchronize
the playout of audio and video
RTCP Bandwidth Scaling
RTCP attempts to limit its traffic to 5% of the session
bandwidth.
Suppose one sender, sending video at a rate of 2
Mbps. Then RTCP attempts to limit its traffic to 100
Kbps.
RTCP gives 75% of this rate to the receivers;
remaining 25% to the sender
The 75 kbps is equally shared among receivers:
With R receivers, each receiver gets to send RTCP
traffic at 75/R kbps.
Sender gets to send RTCP traffic at 25 kbps.
Participant determines RTCP packet transmission
period by calculating average RTCP packet size
(across the entire session) and dividing by allocated
rate.
Sender Reports
V=2 P RC PT=200 Length
Synchronization Source (SSRC) Identifier
NTP Timestamp, High Word
NTP Timestamp, Low Word
RTP Timestamp
Packet Count
Octet Count
Reception Report
V=2 P RC PT=201 Length
Synchronization Source (SSRC) Identifier
SSRC 1
Frac. Lost Cumulative No. of Packets Lost
Extended Highest Seq. No. Received
Interarrival Jitter
Last SR (LSR)
Delay Since Last SR (DLSR)
RTCP Cumulative Loss
Total number of packets lost since receiving
information from the sender
First packet from sender establishes base
sequence number.
Last packet heard from sender establish
expected number of packet overall.
Late packets and duplicate packet are
considered lost
RTCP Estimation Of Jitter
S(i) = Timestamp from RTP packet i
R(i) = Time of arrival of packet i in RTP
timestamp units
D(i) = (R(i) - R(i-1) - (S(i) - S(i-1))
J(i) = Estimate of Interarrival jitter up to the
receipt of RTP packet i
J (i) = 15/16 * J(i-1) + 1/16 * |D(i)|
RTCP End-To-End Delay
Take the NPT timestamp (compact form) of the
Sender Report.
Subtract the LSR (last SR timestamp).
Subtract the DLSR (delay since the last SR
arrived)
QoS for VoIP Overview
As the IP network was primarily designed to carry
data, it does not provide real-time guarantees but only
provides best effort service, which is inadequate for
voice communication. Upper layer protocols were
designed to provide such guarantees.
For VoIP to be a realistic replacement for standard
public switched telephone network (PSTN) telephony
services, customers need to receive the same quality
of voice transmission they receive with basic
telephone services-meaning consistently high-quality
voice transmissions.
QoS ensures that VoIP voice packets receive the
preferential treatment they require.
QoS for VoIP Overview
For VoIP to be deployed so that users receive an
acceptable level of voice quality, VoIP traffic must be
guaranteed:
Compensating bandwidth
latency
Jitter requirements
Packets loss.
In general, QoS provides better (and more predictable)
network service by providing the following features:
Supporting dedicated bandwidth.
Improving loss characteristics.
Avoiding and managing network congestion.
Shaping network traffic.
Setting traffic priorities across the network.
QoS for VoIP Overview
For example, the following standards must be met:
The default G.729 codec requires packet loss far
less than 1 percent to avoid audible errors. Ideally,
there should be no packet loss for VoIP.
The ITU G.114 specification recommends less than
150 millisecond (ms) one-way end-to-end delay for
high-quality real-time traffic such as voice. (For
international calls, one-way delay up to 300 ms is
acceptable, especially for satellite transmission.
This one-way delay takes propagation delay into
considerationthe time required for the signal to
travel the distance.)
Jitter buffers (used to compensate for varying delay)
further add to the end-to-end delay, and are usually
only effective on delay variations less than 100 ms.
Jitter must therefore be minimized
Bandwidth
The first issue of major concern when designing a VoIP
network is bandwidth constraints. Depending upon
which codec you use and how many voice samples you
want per packet, the amount of bandwidth per call can
increase drastically. For a list of bandwidth consumed
by codec

Bandwidth
The payload size
G.729 codec with two 10-ms samples per packet.
20 ms/packet = 0.02 sec/packet ( 50 packets/sec).
Bit rate = 8 kb/s =8000 bits/sec.
8000 bits/sec . 0.02 sec/packet = 160 bits/packet = 20 bytes/packet.
The header size = 40 byte
Header of RTP = 12 byte.
Header of UDP = 8 byte.
Header of IP = 20 byte.
The packet size = 20 + 40 = 60 byte = 480 bit.
Bandwidth consumed = 480 bits / 0.02sec = 24000 bits/sec.
The bandwidth does not include layer 2 headers.
It includes headers from layer 3 (network layer) and above only.
The same G.729 call can consume different amounts of
bandwidth based upon which data link layer is used (Ethernet,
Frame Relay, PPP, and so on).
Bandwidth
Various Link Layer Header Sizes
Minimizing Bandwidth
Compressed Real-Time Transport Protocol (CRTP).
A great deal of information in RTP headers is duplicated or
redundant in a stream.
CRTP compress the 40-byte IP/RTP/UDP header to 2 to 4
bytes most of the time.
The amount of traffic per VoIP call is reduced from 24 kbps
to 11.2 kbps.
CRTP is used on a link-by-link basis.
This compression scheme reduces the IP/RTP/UDP header to
2 bytes when UDP checksums are not used, or 4 bytes when
UDP checksums are used.

Minimizing Bandwidth
Voice Activity Detection (VAD)
Stopping transmission if the analog voice level falls below a
threshold.
Reducing the bandwidth requirements by about half because most
human conversations are silent at least half the time as the other
person talks.
Problems
switch on/switch off times must be carefully tuned to avoid
clipping.
The lack of noise at the receiver end Human users of these
systems frequently complained that it sounded like they had
been disconnected during the call because they no longer
heard noise from the other end while they were talking.
This proves that VAD is working but is evidently not user-friendly.

Minimizing Bandwidth
Bandwidth requirements of various codec implementations
Minimizing Bandwidth
Latency (Delay)
Latency (or delay) is the time that it takes a packet to
make its way through a network end to end. In telephony
terms, latency is the measure of time it takes the talker's
voice to reach the listener's ear.
Large latency values do not necessarily degrade the sound
quality of a phone call, but the result can be a lack of
synchronization between the speakers such that there are
hesitations in the speaker' interactions.
Generally, it is accepted that the end-to-end latency should
be less than 150 ms for toll quality phone calls. To ensure
that the latency budget remains below 150 ms, you need to
take into account the following primary causes of latency.
End to- End Delay
Sender Receiver
Network
Transit Delay
t
A A
Network
Last Bit
Received
First Bit
Transmitted
Processing
Delay
Processing
Delay
End-to-End Delay
Sources Of Delay
Algorithm Delay
This is the delay introduced by the CODEC and is inherent
in the coding algorithm.
Sources Of Delay
Packetization Delay
The amount of time it takes to fill a packet with data.
The larger the packet size, the greater the amount of time it
takes to fill it.
This problem also exists on the receiving side because the
media gateway must remove and further process the packet
data.
RFC 1890 specifies that the default packetization period
should be 20 ms for G.711, this means that 160 samples will
be accumulated and then transmitted in a single frame.
G.723.1 generates a voice frame every 30 ms and each voice
frame is usually transmitted as a single RTP packet.
Sources Of Delay
Serialization Delay
The delay it takes to serialize the digital data onto the physical links of
the interconnecting equipment.
This delay is inversely proportional to the link speed.
The faster the media, the lower the latency.
This value is somewhat dependent on the link technology used and its
access method. For example, it takes 125 microseconds to place one
byte on a 64-Kb circuit. The same byte placed on an OC-3/STM-1
circuit takes 0.05 microseconds.
This delay is incurred whenever it passes through another store-and-
forward device such as a router or a switch.
Thus, a frame that traverses 10 routers will incur this delay 10 times.
This delay is unavoidable (regardless of the bandwidth used), keeping
the number of intervening links small and using high bandwidth
interfaces reduces the overall latency.
Sources Of Delay
Propagation Delay
This is the time required for the electrical or optical signal
to travel along a transmission medium.
The speed of these signals is always slower than that of the
speed of light.
It is a function of the geographic distance.
Propagation delay = Circuit km / (299300 km/s x 0.6)
The propagation speed in a cable is approximately 5.57
microseconds per kilometer.
Sources Of Delay
Queuing delay
The amount of time that a packet remains buffered in a network
element while it awaits transmission.
Network traffic loads result in variable queuing delays.
The amount of buffer that a queue uses is usually a configurable
parameter, with a smaller number being better for latency values.
However, this delay is also based on the amount of traffic the element
is trying to pass through a given link, and therefore it increases with
network load.
Hence, you need to set aside adequate bandwidth and resources for
voice traffic.
If the queue used for voice traffic is not serviced fast enough and that
queue is allowed to grow too large, the result is greater latency.
Sources Of Delay
Packet Switching Delay
The time it takes a router or switch to buffer a packet and
make the decision on which interface the packet is to be
directed.
Although this delay is usually small, the architecture of the
router or switch is the deciding factor.
If a packet must be further buffered as a part of its
processing, greater latency is incurred.
Echo Cancellation
The first impairment caused by delay is the effect of echo.
Echo can arise in a voice network due to poor coupling between the
earpiece and the mouthpiece in the handset (acoustic echo).
It can also arise when part of the electrical energy is reflected back to the
speaker by the hybrid circuit3 in the PSTN (hybrid echo).
When the one-way end-to-end delay is short, whatever echo that is
generated by the voice circuit will come back to the speaker very quickly
and will not be noticeable.
Echo cancellation is not necessary if the one-way delay is less than 25ms.
In other words, if the echo comes back within 50 ms, it will not be
noticeable.
However, the one-way delay in a VoIP network will almost always exceed
25 ms. Therefore, echo cancellation is always required
Talker Overlap
This is the problem that occurs when one party cuts off the
other partys speech because of the long delay.
G.114 provides the following guidelines regarding the one-
way delay limit:
0 to 150 ms Acceptable for most user application.
150 to 400 ms Acceptable provided that Administrations are
aware of the transmission time impact on the transmission
quality.
Above 400 ms Unacceptable for general network planning
purposes.
Delay Variation (Jitter)
When frames are transmitted through an IP network, the
amount of delay experienced by each frame may differ. This is
because the amount of queuing delay and processing time can
vary depending on the overall load in the network.
Even though the source gateway generates voice frames at
regular intervals (say, every 20 ms ), the destination gateway
will typically not receive voice frames at regular intervals
because of jitter.
In general, jitter will result in clumping and gaps in the
incoming data stream.
The general strategy in dealing with jitter is to hold the
incoming frames in a play out buffer long enough to allow the
slowest frames to arrive in time to be played in the correct
sequence.
Delay Variation (Jitter)
The larger the amount of jitter, the longer some of the frames
will be held in the buffer, which introduces additional delay.
To minimize the delay due to buffering, most implementations
use an adaptive jitter buffer. In other words, if the amount of
jitter in the network is small, the buffer size will be small. If the
jitter increases due to increased network load, the buffer size
will increase automatically to compensate for it. Therefore,
jitter in the network will impair voice quality to the extent that
it increases the end-to-end delay due to the play out buffer.
Some times when the jitter is too large, the play out buffer may
choose to allow some frame loss to keep the additional delay
from getting too long.
Delay Variation (Jitter)
Delay Budget
Delay Budget
We assume that the voice gateways are connected via a VPN
service offered by an ISP. Assume an end-to-end delay target of
150 ms:
G723.1 (algorithmic delay) 37.5
G723.1 (processing delay) 30.0
Total gateway delay 67.5
Internet delay limit = 150 67.5 = 82.5 ms.
The delay introduced by the ISP must not exceed 82.5 ms.
This represents both the fixed and variable delays.
In other words, the minimum delay along the VPN path might
be 50 ms. The maximum jitter that the system can tolerate will
be 32.5 ms, which will be compensated by the play out buffer.
Packet Loss
Packet loss occurs for many reasons, and in some cases, is
unavoidable:
Network congestion , routers and switches can overflow
their queue buffers and be forced to discard packets.
Packet loss can result from excess latency, where a group of
packets arrives late and must be discarded in favor of newer
ones.
It can also be the result of jitter, that is, when a packet
arrives after its surrounding packets have been flushed from
the buffer, making the received packet useless.
Real-time applications based on the UDP are significantly
less tolerant to packet loss. UDP does not have
retransmission facilities, however, retransmissions would
almost never help.
Packet Loss
Packet loss up to 5% can be tolerated with VOIP traffic
encoded with G.711.
Greater payload compression rates resulted in a higher
sensitivity to packet loss ( 1-3% for voice compression on
an 8kbps stream).
It is important that bearer and signaling packets are not
discarded, otherwise, voice quality or service disruptions
might occur.
Class of Service (CoS) mechanisms become very
important.
Packets of greater importance are giving a higher priority in
the network, thus ensuring packet delivery for critical
applications, even during times of network congestion.
Class of Service
Packet Classification
To guarantee bandwidth for VoIP packets, a network device
must be able to identify VoIP packets in all the IP traffic flowing
through it. Network devices use the source and destination IP
address in the IP header or the source and destination User
Datagram Protocol (UDP) port numbers in the UDP header to
identify VoIP packets. This identification and grouping process
is called classification and it is the basis for providing any QoS.
Packet classification can be processor-intensive, so it should
occur as far out toward the edge of the network as possible.
Because every hop still needs to make a determination on the
treatment a packet should receive, you need to have a simpler,
more efficient classification method in the network core. This
simpler classification is achieved through marking or setting the
type of service (ToS) byte in the IP header.
Packet Classification
IP Precedence bits
The three most significant bits of the ToS byte in the IP header.
Differentiated Services Code Point (DSCP)
The six most significant bits of the ToS byte in the IP header.
Packet Classification
Differentiated Services Code Point (DSCP)
The first three bits of the DSCP are used as class selector
bits, the class selector bits makes DSCP compatible with IP
Precedence.
The next two bits are used to define drop preference.
if the traffic in Class 4 (the first three bits are 100) exceeds a
certain contracted rate, the excess packets could be re-
marked so that the drop preference is raised instead of
being dropped.
If congestion occur , the first packets to be dropped would
be the "high drop preference" packets.
The sixth bit must be set to 0 to indicate to the network
devices that the classes have been set according to the DS
standard.
Packet Classification
Differentiated Services Code Point (DSCP)
Best-effort class - Class selector bits set to 000
Assured Forwarding (AF) - Class selector bits set to 001,
010, 011, or 100.
Expedited Forwarding (EF) - Class selector bits set to 101.
Packet Classification
Differentiated Services Code Point (DSCP)
Expedited Forwarding (EF) is intended for delay-sensitive
applications that require guaranteed bandwidth (VoIP).
An EF marking guarantees priority service by reserving a
certain minimum amount of bandwidth that can be used for
high priority traffic.
In EF, the egress rate (or configured priority bandwidth)
must be greater than or equal to the sum of the ingress
rates, so that there is no congestion for packets marked EF.
If there is congestion, nonconforming packets exceeding the
specified priority rate are dropped to assure that packets in
other queues belonging to different classes are not starved of
bandwidth.
The recommended DSCP value for EF is 101110 (46).
Policy and Shape
Regulate or limit the amount of traffic an application is allowed
to send across various interfaces or networks.
Enable network administrators to define how much bandwidth
an application or even a user can use, identify when traffic
exceeds the thresholds set by the network administrator.
Rate-Limiting Tools
Drop traffic based upon policing.
Used in service provider networks to ensure that a subscriber does
not exceed the amount of bandwidth set by contract with the
service provider.
Traffic Shaping Tools
Buffer the excess traffic while waiting for the next open interval to
transmit the data
used at the edge of the network to make sure the network is
utilizing the bandwidth for business needs.
Policy and Shape
Traffic shaping enables you to control the traffic going out of an
interface to match its flow to the speed of the remote, target
interface and to ensure that the traffic conforms to policies
contracted for it.
Control usage of available bandwidth.
Establish traffic policies.
Regulate traffic flow to avoid congestion.
Configure an interface if you have a network with different
access rates.
Suppose one end of the link in the network runs at 256 kbps and
the other end runs at 128 kbps. Sending packets at 256 kbps could
cause the applications using the link to fail.
Configure an interface to offer a subrate service. In this case,
traffic shaping enables you to use the router to partition your links
into smaller channels.
Queuing and scheduling
After all traffic has been placed into QoS classes based on their
QoS requirements, you need to provide bandwidth guarantees
and priority servicing through an intelligent output queuing
mechanism.
A priority queue is required for VoIP. You can use any queuing
mechanism that effectively gives VoIP high priority
Low Latency queuing (LLQ)
provide priority to certain classes and provide guaranteed
minimum bandwidth for other classes .
During periods of congestion, the priority queue is policed at the
configured rate so that the priority traffic does not monopolize all
the available bandwidth.
LLQ also allows queue depths to be specified to determine when
the router should drop packets if too many packets are waiting in
any particular class queue.
Queuing and scheduling
Low Latency queuing (LLQ)
There is also a class default
that is used to determine
treatment of all traffic not
classified by a configured
class.
The class default can be
configured with the fair-
queue interface configuration
command, which means that
each unclassified flow will be
given an approximately equal
share of the remaining
bandwidth.
Queuing and scheduling
Low Latency queuing (LLQ)
all traffic going out of an interface or subinterface (for Frame
Relay and ATM) is first classified using MQC. There are four
classes: one high priority class, two guaranteed bandwidth classes,
and a default class.
The priority class traffic is placed into a priority queue and the
guaranteed bandwidth class traffic is placed into reserved queues.
The default class traffic can be given a reserved queue or can be
placed in an unreserved default queue where each flow will get an
approximately equal share of the unreserved and available
bandwidth.
The scheduler services the queues so that the priority queue traffic
is output first unless it exceeds a configured priority bandwidth
and this bandwidth is needed by a reserved queue (that is, there is
congestion).
Queuing and scheduling
Low Latency queuing (LLQ)
The reserved queues are serviced according to their reserved
bandwidth, which the scheduler uses to calculate a weight.
The weight is used to determine how often a reserved queue is
serviced and how many bytes are serviced at a time. The scheduler
services are based on the weighted fair queuing (WFQ) algorithm.
If the priority queue fills up because the transmission rate of
priority traffic is higher than the configured priority bandwidth,
the packets at the end of the priority queue will be dropped only if
no more unreserved bandwidth is available.
None of the reserved queues are restricted to the configured
bandwidth if bandwidth is available. Packets violating the
guaranteed bandwidth and priority are dropped only during
periods of congestion.
Provide the priority queue with enough bandwidth to handle all
the VoIP traffic requiring priority servicing.
Security
Security, especially in a converged voice and data network,
is a high priority.
security in VoIP needs to be address carefully.
The tools that we use to protect data like Cryptography,
Firewalls and Encryption provided by VPN can lead to a
bad performance in the quality of the voice because they
introduce a considerable latency (nodal processing delay).
this has a direct effect in the MOS) for Voice Quality.