The European Organisation for Civil Aviation Equipment

L’Organisation Européenne pour l’Equipement de l’Aviation Civile

NETWORK REQUIREMENTS AND PERFORMANCES FOR VOICE

OVER INTERNET PROTOCOL (VOIP) AIR TRAFFIC MANAGEMENT
(ATM) SYSTEMS

PART 2: NETWORK DESIGN GUIDELINE

This document is the exclusive intellectual and commercial property of EUROCAE.

It is presently commercialised by EUROCAE.
This electronic copy is delivered to your company/organisation for internal use exclusively.
In no case it may be re-sold, or hired, lent or exchanged outside your company.

ED-138 Part 2
February 2009

102 rue Etienne Dolet Tel: 33 1 40 92 79 30

92240 MALAKOFF, France Fax: 33 1 46 55 62 65
Web Site: www.eurocae.net Email: eurocae@eurocae.net
 NETWORK REQUIREMENTS AND PERFORMANCES FOR VOICE
OVER INTERNET PROTOCOL (VOIP) AIR TRAFFIC MANAGEMENT
(ATM) SYSTEMS

PART 2: NETWORK DESIGN GUIDELINE

This document is the exclusive intellectual and commercial property of EUROCAE.

It is presently commercialised by EUROCAE.
This electronic copy is delivered to your company/organisation for internal use exclusively.
In no case it may be re-sold, or hired, lent or exchanged outside your company.

ED-138 Part 2
February 2009

© EUROCAE, 2009
 i

FOREWORD
1 The document ED-138 “Network Requirements and Performances for VoIP
ATM Systems” was prepared by EUROCAE Working Group 67 and was
accepted by the Council of EUROCAE on 2 February 2009.
2 EUROCAE is an international non-profit making organisation. Membership is
open to manufacturers and users in Europe of equipment for aeronautics, trade
associations, national civil aviation administrations and non-European
organisations. Its work programme is principally directed to the preparation of
performance specifications and guidance documents for civil aviation
equipment, for adoption and use at European and world-wide levels.
3 The findings of EUROCAE are resolved after discussion among its members
and, where appropriate, in collaboration with RTCA Inc, Washington D.C. USA
and/or the Society of Automotive Engineers (SAE), Warrendale, PA, USA
through their appropriate committee.
4 The document represents “the minimum specification required for
Manufacturers and Users to assure Interoperability between VoIP ATM
Components”.
5 EUROCAE performance specifications are recommendations only. EUROCAE
is not an official body of the European governments; its recommendations are
valid statements of official policy only when adopted by a particular government
or conference of governments.
6 Copies of this document may be obtained from:

EUROCAE
102 rue Etienne Dolet
92240 MALAKOFF
France

Tel: 33 1 40 92 79 30
Fax: 33 1 46 55 62 65
Email: eurocae@eurocae.net
Web Site: www.eurocae.net

© EUROCAE, 2009
 ii

TABLE OF CONTENTS
FOREWORD .......................................................................................................................... I
CHAPTER I INTRODUCTION .............................................................................................. 1
1.1 Background....................................................................................................... 1
1.2 ED-138 PRESENTATION................................................................................. 2
1.2.1 Operational Voice Applications in ATM............................................. 3
1.2.2 Network Concept............................................................................... 4
1.2.3 Authors and Contributors .................................................................. 5
REFERENCES OF INTRODUCTION ............................................................................................. 6
CHAPTER II VOIP OVERVIEW, PROTOCOLS AND STANDARDS .................................... 7
2.1 VoIP Overview .................................................................................................. 7
2.1.1 VoIP Implementation ......................................................................... 7
2.1.2 Quality of Services ............................................................................ 12
2.1.3 Gateway ............................................................................................ 12
2.2 VoIP Architecture Characteristics..................................................................... 13
2.2.1 Assumptions...................................................................................... 13
2.2.2 Voice over IP Components................................................................ 13
2.2.3 Performance Parameters for VoIP Applications................................ 13
2.2.4 Availability.......................................................................................... 13
2.2.5 Delay ................................................................................................. 13
APPENDIX A REAL-TIME MULTIMEDIA PROTOCOLS................................................................ 14
APPENDIX B CODECS FOR VOIP TECHNOLOGY...................................................................... 16
APPENDIX C MULTIMEDIA PROTOCOLS: H.323 AND SIP......................................................... 19
APPENDIX D COMPARISON OF IPV4 AND IPV6......................................................................... 24
APPENDIX E NUMBERING AND ADDRESSING .......................................................................... 26
APPENDIX F VOIP COMPONENTS............................................................................................... 29
CHAPTER II REFERENCES........................................................................................................... 31
CHAPTER III NETWORK AVAILABILITY, RELIABILITY, MAINTAINABILITY ..................... 36
3.1 Introduction ....................................................................................................... 36
3.2 Background and scope ..................................................................................... 36
3.3 High Availability in Networking ......................................................................... 37
3.3.1 Defining Availability ........................................................................... 37
3.3.2 Calculating Availability....................................................................... 38
3.3.3 High-availability platforms ................................................................. 40
3.3.4 High-availability network design........................................................ 40
3.3.5 High availability inside ANSP networks............................................. 41
3.3.6 High Availability in IP Routing ........................................................... 49
3.4 Conclusion and Recommendation.................................................................... 59
CHAPTER III REFERENCES.......................................................................................................... 60
CHAPTER IV QUALITY AND PERFORMANCE..................................................................... 61
4.1 Bandwidth and Performance ............................................................................ 61
4.1.1 Bandwidth.......................................................................................... 61
4.1.2 Packet Loss....................................................................................... 63
4.1.3 Header Compression ........................................................................ 63

© EUROCAE, 2009
 iii

4.1.4 Conclusions & Recommendations .................................................... 68

4.2 Delay and Jitter................................................................................................. 68
4.2.1 Standards for Delay Limits ................................................................ 69
4.2.2 Sources of Delay ............................................................................... 70
4.2.3 Delay Engineering ............................................................................. 78
4.2.4 Conclusion......................................................................................... 80
4.3 Quality of Service QoS ..................................................................................... 80
4.3.1 VoIP QoS requirements .................................................................... 80
4.3.2 QoS Definition ................................................................................... 81
4.3.3 QoS Protocols and Standards........................................................... 83
4.3.4 Conclusion......................................................................................... 106
CHAPTER IV REFERENCES ......................................................................................................... 107
CHAPTER V MULTICAST CONSIDERATIONS.................................................................... 111
5.1 Introduction ....................................................................................................... 111
5.2 Background & Scope ........................................................................................ 111
5.3 INTRA-DOMAIN Multicast solutions for IPv4 ................................................... 111
5.3.1 Multicast protocols overview ............................................................. 111
5.3.2 Multicast flow types ........................................................................... 115
5.3.3 Multicast protocols comparison......................................................... 115
5.3.4 Rendez-vous point election/management......................................... 117
5.3.5 IGMP ................................................................................................. 117
5.4 INTRA-DOMAIN Multicast solutions for IPv6 ................................................... 118
5.4.1 Multicast protocols overview ............................................................. 118
5.5 Design considerations ...................................................................................... 118
5.5.1 Unwanted flooding............................................................................. 118
5.5.2 Domain control .................................................................................. 119
5.5.3 Inter-domain communication ............................................................. 119
5.5.4 Coexistence of different PIM modes on the same network topology 119
5.5.5 Convergence ..................................................................................... 119
5.6 Conclusion ........................................................................................................ 120
APPENDIX A ADDITIONAL QUESTIONS & ANSWERS ............................................................... 122
APPENDIX B ACRONYMS ............................................................................................................. 125
APPENDIX C CONFERENCE CALL RECOMMENDATION (NETWORK POINT OF VIEW)........ 126
CHAPTER V REFERENCES .......................................................................................................... 127
CHAPTER VI IP ADDRESSING.............................................................................................. 129
6.1 Introduction ....................................................................................................... 129
6.2 IPv4 Overview................................................................................................... 129
6.3 IPv6 Overview................................................................................................... 130
6.4 Why IPv6? ........................................................................................................ 133
6.5 Transition Mechanisms..................................................................................... 134
CHAPTER VI REFERENCES ......................................................................................................... 135

© EUROCAE, 2009
 iv

CHAPTER VII SECURITY CONSIDERATIONS ...................................................................... 136

7.1 Introduction ....................................................................................................... 136
7.2 Voice over IP Security OVERVIEW.................................................................. 136
7.2.1 Threats in VoIP networks .................................................................. 137
7.3 Quality of Service Implications ......................................................................... 138
7.4 Security technologies........................................................................................ 138
7.4.1 Encryption for VoIP networks............................................................ 139
7.4.2 VoIP protection - Perimeter security with firewalls ............................ 147
7.4.3 Application Level Gateways .............................................................. 150
7.4.4 Middlebox Solutions .......................................................................... 150
7.4.5 Session Border Controllers ............................................................... 151
7.4.6 IPS (Intrusion Prevention Systems) .................................................. 153
7.5 Best practices solutions for protecting VoIP/IP Telephony Networks .............. 155
7.5.1 Secure the network infrastructure for voice....................................... 156
7.5.2 Attacks against VoIP Endpoints ........................................................ 156
7.5.3 Voice over IP Servers protection....................................................... 157
7.5.4 Voice over IP application protection:................................................. 158
ANNEX 1 IPSEC TERMS GLOSSARY........................................................................................... 160
ANNEX 2 COMPARISON BETWEEN IPSEC AND MPLS-BASED VPN ....................................... 163
CHAPTER VII REFERENCES ........................................................................................................ 164
CHAPTER VIII NETWORK MANAGEMENT............................................................................. 165
8.1 Introduction ....................................................................................................... 165
8.2 Simple Network Management Protocol (SNMP) .............................................. 165
8.2.1 Basic structure................................................................................... 165
8.2.2 SNMP Version 1 (SNMPv1) .............................................................. 166
8.2.3 SNMP Version 2 (SNMPv2) .............................................................. 167
8.2.4 SNMP Version 3 (SNMPv3) .............................................................. 168
8.3 Conclusions & Recommendations.................................................................... 171
CHAPTER VIII REFERENCES ....................................................................................................... 172
VOIP LEXICON .......................................................................................................................... 174
LIST OF FIGURES .......................................................................................................................... 180
LIST OF TABLES .......................................................................................................................... 180

© EUROCAE, 2009
 1

CHAPTER I

INTRODUCTION
1.1 BACKGROUND

Components of Ground- Ground ATM voice systems has used digital (TDM/PCM -
Time Division Multiplexing / Pulsed Code Modulation) or analogue technology during a
long time.
Convergence of voice and data into one multimedia network is observed on the
market. As a consequence the ATM communication network is evolving into a
common infrastructure for voice and data services.
As a result of the above described technological trends, the capability of Voice over IP
Technology may fulfil and improve operational and technical ATM communication
requirements, including voice / data convergence, specific Quality of Services (QoS),
security and safety requirements.
So after analysing the situation regarding:
• Operational and Technical Air-Ground (A/G) and Ground-Ground (G/G) ATM
Voice system requirements
• Existing IP Voice protocols and signaling standards
• IP networks capability for Voice services
• Security, QoS, Convergence (infrastructure, protocol, applications)
• Existing IP Voice ATM systems and their service interfaces,
The following tasks were achieved for ground-ground ATM communications and
ground-ground segment of air-ground ATM communications:
• Define IP Voice ATM Systems and identify their components (Voice
Communication System / VCS, Ground based Radio Station / GRS…)
• Determine possible additional operational and technical ATM requirements for
new IP Voice ATM systems, also taking into consideration A/G communications.
• Accordingly, make recommendations to upgrade current standardisation
documents.
• Develop a Technical Specification for an IP Voice ATM System including:
o Minimum performance and safety / security requirements for the system
and, if appropriate, for components
o Interoperability requirements between IP components of the IP Voice
ATM systems
o Minimum performance requirements of an IP Network aimed to support
Voice in ATM.
o Guidelines for qualification tests of IP Voice ATM systems and IP Voice
ATM components.
So four documents with a common reference to “Vienna Agreement” were provided:
• ED-136 VoIP ATM System Operational and Technical Requirements
• ED-137 Interoperability Standards for VoIP ATM Components
• ED-138 Network Requirements and Performances for VoIP ATM Systems
• ED-139 Qualification tests for VoIP ATM Components and Systems

© EUROCAE, 2009
 2

The “Vienna Agreement” defines the different components of the VoIP ATM system
and may be resumed by the following figure on which are described the different
interfaces between the components.

FIGURE 1 : VIENNA AGREEMENT

1.2 ED-138 PRESENTATION

The purpose of this document is to give solutions and guidelines to fulfil requirements
of network services that is to provide the necessary high levels of availability, integrity,
performances and Quality of Service (QoS) for Voice over Internet Protocol (VoIP) in
Air Traffic Management (ATM) applications.
This document also supports to understand existing standards and protocols of the
above mentioned network services.
To make the documents better readable ED-138 was divided into two parts:
• ED-138 Part 1 [1]
o Network Specification
o Security Policy
o IP Adressing Plan
• ED-138 Part 2:
o Network Design Guideline (this document)

*
ED-138 Part 1 (Network Specification) tells WHAT shall/should/may be done.

ED-138 Part 2 (Network Design Guideline) tells HOW it can be done.

For better reading the document was arranged in different chapters, each chapter has
its own references.

© EUROCAE, 2009
 3

1.2.1 Operational Voice Applications in ATM

Components of Ground-Ground ATM voice systems are currently using digital

(TDM/PCM - Time Division Multiplexing / Pulse Code Modulation) or analogue
technology, otherwise some Voice Air Traffic management (ATM) systems already
use Voice-over-Internet Protocol (VoIP) Technology.
Eurocontrol EATM1 Ground-Ground Communications Strategy is foreseeing to
integrate ATM IP Voice communications by 2010 in the on going ATM IP Data
Network.
WG67 has defined the specification of an VoIP ATM System as illustrated in Figure 2
• for Ground-Ground (G-G) communications (Telephone via Voice
Communication Systems VCS)
• for the Ground segment of Air-Ground (A-G) communications (Radio).

RADIO

WAN

VoIP

VCS 1 VCS 2
VCS = Voice Communication System

FIGURE 2 : CONSIDERED VOICE APPLICATIONS IN WG67

1
European Air Traffic Management

© EUROCAE, 2009
 4

1.2.2 Network Concept

The following are the definitions of the main concepts that are particular to this
Document:
• EDGE is the equipment that serves as the interface to the WAN. This could be
one or a combination of devices (e.g., switches, routers, and firewalls) that
deliver the communication service.
• LAN (Local Area Network) is a network covering a relatively small geographic
area.
• WAN shall be understood as being the interconnecting infrastructure of a
communications enterprise, which may be based upon the IP (though not
necessarily so), supported by underlying technologies (e.g., MPLS, Gigabit
Ethernet, Frame Relay, TDM). The WAN serves users across a broad
geographic area and often uses transmission devices provided by common
carriers. A WAN can be a Provider’s Core network, a private network or the
combination of both of them.
• IP Network means the complete physical and logical mapping and connectivity
(up to Layer 3) between end-system network access points, including the LAN,
EDGE and WAN domains.
Figure 3 shows the different Network domains and their terminology.

IP

IP

IP

IP

IP

IP

IP

IP
LAN EDGE WAN EDGE LAN

FIGURE 3 : IP NETWORK DOMAIN CONCEPT

© EUROCAE, 2009
 5

1.2.3 Authors and Contributors

The following companies and persons mentioned in Table 1 were involved in creating
different chapters of this document:

Permanent
Non-permanent
members
members

FIGURE 4 : SUBGROUP 3 PARTICIPATION (NO PATICULAR ORDER)

Authors Contributors
Catalin Apostol, ROMATSA Annette Maria Balks, Cisco
Armin Biegel, DFS Dragos Baloi, ROMATSA
Valérie Bruté de Rémur, THALES Luca Bertagnolio, Cisco
Juan Francisco Ramos González, Indra Hung Do-Duy, INEO
Leon Sayadian, FAA Olivier Dupont, Cisco
Eric Weill, FAA Graham Fellows, Nortel
Marcelo Zomignani, Indra Christian Geiller, INEO
Wolfgang Kampichler, Frequentis
Pascal Lepers, SITA
Davide Merulli, OTE SELEX
Valery Pialat, SITA
Mickaël Royer, DSNA
TABLE 1 - AUTHORS AND CONTRIBUTORS OF THIS DOCUMENT

© EUROCAE, 2009
 6

REFERENCES OF INTRODUCTION
[1] ED-138 Network Requirements and Performances for VoIP ATM Systems Part
1: Network Specification;
http://www.eurocae.net

© EUROCAE, 2009
 7

CHAPTER II

VOIP OVERVIEW, PROTOCOLS AND STANDARDS

2.1 VOIP OVERVIEW

The legacy G-G voice system infrastructure is based upon costly, low capacity,
congested point-to-point circuitry, which invoke legacy signaling protocols that are
difficult to maintain. Communication service providers are migrating towards newer
technologies [e.g., Transmission Control Protocol (TCP), User Datagram Protocol
(UDP), and IP version 6 (IPv6)], enabling scalable, available, and cost-effective G-G
multimedia communications among ATM facilities.
The porting of voice and signaling via TCP/UDP and IPv6 protocol stacks will leverage
shared media [e.g., Internet, Intranet, Local Area Networks (LAN), and Wide Area
Networks (WAN)] for these payloads. Voice is digitized, compressed, and converted
into packets, where they are merged with data and signaling packet traffic over the
network. Signaling protocols [1 and 65] are used to set up/tear down calls, and convey
information for locating users and negotiating capabilities. This digital approach
provides a transition path from the traditional circuit-switched technology of the public
or Private Switched Telephone Network (PSTN).

2.1.1 VoIP Implementation

Recommended standards and protocols will be described below for implementing

digital voice technology in the application (including session and presentation),
transport, network, link, and physical layers of the OSI model, as shown in Figure 5.
Applicability of these standards is based upon their maturity and complexity, fulfillment
of the ATM mission need, and product availability. Additional standards information
may be found in the attached Appendices.
Provisioning of VoIP entails consideration of the following issues:
• Standards and protocols
• Integrated Networking with PSTN, as shown Figure 6
• Interface to PSTN via ATS Gateway, as shown Figure 7
• Packet technology and products (e.g., Gateway {GW}, Router {Rtr}, Multipoint
Control Unit {MCU}, terminals, ground-based radios, telephone, switches,
multiplexers, and servers), as shown Figure 8
• Network management architecture and policy
• Guaranteed Quality of Service (QoS) for prioritization of traffic classes
• Signal compression
• Security technology
• Multimedia communication
• Interoperability
• Scalability

© EUROCAE, 2009
 8

User

Adapter
OSI Layers

Layer
7, 6, T.120 H.450.x
H.323/ H.235
and 5 (RTP) H.460.x
T.130
(AVC) H.225 H.225 H.24 SIP
Q.93 RAS
1

Layer 4 TCP/UDP

Layer 3 IPv6

Layer 2 FR, ATM, MAC

Layer 1 Physical Interfaces T1/E1

Users LAN/WAN/PSTN Users

FIGURE 5 : VOIP ARCHITECTURE & LAYERS

© EUROCAE, 2009
 9

2.1.1.1 Application Layer

• H.323 series [1] is an umbrella recommendation for multimedia communications

over packet based networks (e.g., Internet and Intranet). It includes the
standards listed below:
o H.225.0 Call setup/Registration Admission Status (RAS) [2] (defined in
Appendix A), Q.931 [25]
o H.245 Call control [4]
o H.246 Interlocking of H-Series multimedia terminal [5]
o H.235 Security [3 and 32]
o H.320, H.321, and H.324 for ISDN [9]
o H.332 Coupled Conferences [10]
o H.450.1-12 Generic functional protocol for the support supplementary
services [e.g., call (transfer, forwarding, hold, park, and waiting)] [11]
o H.460.1-15 Generic Extensibility Framework (GEF) [99]
• Session Initiation Protocol (SIP) [65, 66, 67 and 69] is a simple signaling
protocol for application layer control of VoIP implementations
o SIP-T (Telephony) [71]
o Session Description Protocol (SDP), which describes the session for
Session Access Protocol (SAP), SIP [45, 60, 68 and 70]
o Session Announcement Protocol (SAP) , used for multicast session
managers to distribute a multicast session description to a large group of
recipients [76]
o T.125 – Multipoint communication service protocole [89]
o ECMA – 312, 3rd Edition (ATS QSIG) [31]
• Simple Network Management (SNMP) or SNMPv3 [79]
• RTP (Real Time Protocol) [88] Payload for DTMF Digits, Telephony
Tones/Signaling
• RSVP (Resource reSerVation Protocol) [42] (defined in Appendix A)
• RTSP (Real Time Streaming Protocol) [44] (defined in Appendix A)
o T.120, RTP (Real-Time Transport Protocol) [26 and 98]
o RTCP (Real Time Control Protocol) [73] (defined in Appendix A)
o SRTP (Secure Real Time Protocol) [74] (defined in Appendix A)
o ZRTP (Zimmerman Real Time Protocol) [105] (defined in Appendix A)
• T.130, Audio Visual Control [27]
• Call Processing [59]
• Codecs: G.114, G.711, G.711 Annex B [91], G.723.1, G.726, G.728, G.729A
[13, 15, 16, 17, 18, 19], and iLBC [101 and 102]. For detailed information on
these codecs, see Appendix B.
Appendix C includes a comparison of H.323 and SIP capabilities.

2.1.1.2 Transport Layer

• TCP, UDP [37 and 38]

• Security: Transport Layer Security (TLS) [43].

© EUROCAE, 2009
 10

2.1.1.3 Network Layer

• IPv4, IPv6, Differentiated Services (DiffServ)/Explicit Congestion Notification

(ECN), Internet Control Management Protocol version 6 (ICMPv6) [36, 53, 52
and 54]
• IP Virtual Private Network (VPN) [58]
• IP access to telephony for SIP and SDP [60]
• A Framework for Telephony Routing over IP [61]
• QoS for IP-based services and performance parameters [29, 30 and 63].
• Security: IP Security (IPSec) [47, 48, 49 and 90].
• Border Gateway Protocol version 4 (BGP-4) [41]
• Expedited Forwarding Per-Hop Behavior (PHB) [64]
• Transport IP over Asynchronous Transfer Mode [28]
• Integrated Services Digital Network (ISDN) user-network interface specification
for basic call control [25]
• Open Shortest Path First (OSPF) [46]
• Assured Forwarding PHB Group [57]
• Naming and addressing [Section 2.1.1.7]
A comparison of IPv4 and IPv6 features is included in Appendix D.

SI

VoIP

GW

PSTN

FIGURE 6 : INTEGRATED NETWORK

© EUROCAE, 2009
 11

ATS Gateway

IP
IP IP
PSTN
Network
Network
Network

FIGURE 7 : VOIP INTERFACE TO PSTN VIA ATS GATEWAY

Manager or
H.323 Gatekeeper

Rtr/GW To external networks

Video Video

Telephone IP Telephone
IPWAN
WAN(Router,
(Router,
SW,
SW, GW))
GW
PC PC
Gigabit
Gigabit
Convergence device
and multiplexer Convergence device
LEGEND
and multiplexer
GW – Gateway LAN
LAN – Local Area Network PC Telephone
PC – Personal Computer
Rtr – Router
SW – Switch
WAN – Wide Area Network

FIGURE 8 : EXAMPLE OF A CONVERGED VOIP NETWORK

© EUROCAE, 2009
 12

2.1.1.4 Link Layer

• LAN [33, 34 and 35], Frame Relay (FR) [24], ATM [39 and 40], Multi-Protocol
Label Switching (MPLS) [62 and 106], ISDN [23], ATS-QSIG [31]
• PISN (Private Integrated Services Network) for Air Traffic Services [31]
• Link Control Protocol (LCP) for multi-protocol data-grams over Point to Point
Protocol (PPP) infrastructures [55]

2.1.1.5 Physical Layer

• T1, T3, E1, FDDI, SONET

• ITU V.x series (e.g., V.35, V.34, V.24, V.11)

2.1.1.6 Echo cancellation

• ITU G.165 and ITU G.168 [14]

• ITU G.131 [94]

2.1.1.7 Telephone Naming and Addressing

• Public Numbering ITU-T E.164 [85 and 86]

• Private network addressing ECMA-155 [87]
• Notation for national/international telephone numbers ITU-T E.123 [93]
• Identification plan for land mobile station ITU-T E.212 [83]
• Definition Relating to National/International Numbering Plan T.160 [84]
• Electronic Numbering (ENUM) [78, 80, 81 and 97]
• EUROCONTROL Report on ATS Ground Voice Network Numbering Plan [104]
• ICAO Recommended Voice Addressing Plan [82]
• Assignment procedures for international signaling print code [95 and 96]
Detailed information is contained in Appendix E.

2.1.1.8 Quality Measurement

• ITU-T P.800 [20], ITU-T P.861 [21], ITU-T P.862 [22]

• ITU-T G.107 [12]

2.1.2 Quality of Services

An important consideration is the implementation of mechanisms to ensure that

diverse ATM message types are conveyed as per their appropriate priority, with
sufficient quality. QoS tools may be used to ensure that voice communications are
delivered with precedence over other messaging. Key QoS requirements are
described in Chapter III.

2.1.3 Gateway

Gateway enables external control and management of voice communication

equipment operating at the edge of multi-service packet networks.

© EUROCAE, 2009
 13

2.2 VOIP ARCHITECTURE CHARACTERISTICS

2.2.1 Assumptions

The following assumptions are a pre-requisite for defining the voice switching
infrastructure:
• A robust IP infrastructure exists that supports ATM requirements (e.g.
availability, performance, Quality of Services (QoS), security) at ATM facilities
• Interfaces are available to the Private Switched Telephone Network (PSTN) for
backup and load sharing
• The IP infrastructure is compatible with the legacy end systems (e.g., voice
switches, circuits, signaling protocols)
• Member states manage the portion of the network within their domain
• Provisions are available for fixed wireless links (e.g., satellite)
• ATS-QSIG signaling is integrated within the voice communications network for
international interfaces
• Sufficient implementation of redundancy

2.2.2 Voice over IP Components

VoIP components are defined in Appendix F.

2.2.3 Performance Parameters for VoIP Applications

To achieve the desired level of performance for ATM VoIP communications, the
following criteria must be addressed:
• Jitter
• Impact of packet and frame size
• Packet delay and loss
• Bandwidth allocation based on QoS
• Voice compression
• Echo cancellation
• Interoperability
Chapter IV contains detailed information.

2.2.4 Availability

Availability and reliability are critical parameters of an ATM VoIP network.

More information can be found in Chapter III.

2.2.5 Delay

Packet delay or latency must not exceed the maximum tolerable level for a VoIP
conversation (100 - 150 ms). Jitter, which is the variation of latency over time, must be
below acceptable values, and the jitter buffer must be carefully designed for this
purpose see Chapter III. Packet loss can erode voice quality, so techniques such as
Packet Loss Concealment and Packet Loss Recovery may be implemented to mitigate
this concern.
Chapter IV in this document describes detailed information, parameters, and guidance
materials on these topics.

© EUROCAE, 2009
 14

APPENDIX A

REAL-TIME MULTIMEDIA PROTOCOLS

RSVP is used by a host to request specific qualities of service from the network for
particular application data streams or flows. It is also used by routers to deliver QoS
requests to all nodes along the path(s) of the flows, and to establish and maintain
state to provide the requested service. RSVP requests will generally result in the
allocation of bandwidth for specified traffic flows at each node along the
communications path.
RTP provides end-to-end delivery services for data with real-time characteristics, such
as interactive audio and video. These services include payload type identification,
sequence numbering, time-stamping and delivery monitoring. Applications typically
run RTP on top of UDP to make use of its multiplexing and checksum services; both
protocols contribute parts of the transport protocol functionality.
RTCP is based on the periodic transmission of control packets to all participants in the
session, using the same distribution mechanism as the voice packets. The underlying
transport protocol provides multiplexing of the voice and control packets. RTCP
performs four functions to monitor and control RTP in support of quality of service and
membership management functions:
1. Provides feedback to RTP on the quality of the data distribution
2. Carries persistent transport-level identifiers for RTP sources (called Canonical
Names) to identify session participants
3. Distributes RTCP packets to all session participants to scale the flow rate for
accommodating changing number of participants
4. An OPTIONAL function to convey minimal session control information. This is
may be used to conduct "loosely controlled" sessions, where participants can
drop in and out of a session without undergoing membership control procedures
and parameter negotiations.
RTCP Extended Reports (XR) is a new VoIP management protocol [100], which
defines a set of metrics that contain information for assessing VoIP call quality and
diagnosing problems.
RTSP is an application-level protocol that provides an extensible framework to enable
controlled, on-demand delivery of real-time audio and video.
RAS is used to perform registration, admission control, bandwidth changes, status
reporting, and disengage procedures between endpoints (i.e., terminals and
gateways) and gatekeepers. This protocol exchanges messages over a dedicated
channel prior to the establishment of any other channels. [2]
SRTP, a profile of the RTP, provides confidentiality, message authentication, and
replay protection for RTP and RTCP traffic.

© EUROCAE, 2009
 15

ZRTP [105] complements SRTP2 by providing a robust setup mechanism for key
agreement to establish a secure SIP3-based VoIP call setup. It uses ephemeral Diffie-
Hellman (DH) with hash commitment, and allows the detection of Man-in-The-Middle
(MiTM) attacks by displaying a short authentication string for the users to read and
compare over the phone. If the two strings read out by the callers don't match, it
becomes evident that the call has been intercepted by a third party. Even if the calling
parties choose not to do this, some authentication is still available against MiTM
attacks, due to key continuity properties similar to Secure Shell (SSH)4. This is
manifested by the caching of some key material to be used in the next call’s DH
shared secret.

2
“The Secure Real-time Transport Protocol (SRTP)”, RFC 3711, IETF, March 2004
3
“SIP: Session Initiation Protocol”, RFC 3261, IETF, June 2002; “SIP-specific Event Notification”, RFC 3265,
June 2002; “S/MIME AES Requirement for the SIP”, RFC 3853, July 2004; “Actions Addressing Identified Issues
with the SIP’s Non-INVITE Transaction”, RFC 4320, January 2006; “Connected Identity in the SIP”, RFC 4916,
June 2007
4
“The Secure Shell (SSH) Connection Protocol”, RFC 4254, IETF, January 2006

© EUROCAE, 2009
 16

APPENDIX B

CODECS FOR VOIP TECHNOLOGY

CODECs are the algorithms that enable digital networks (e.g., IP networks) to carry
analog voice. There are several CODECs available, varying in complexity, bandwidth
requirements, and voice quality robustness. Generally, more complex algorithms
provide better voice quality (especially in degraded network conditions), but incur
higher latency due to longer processing time.
This appendix describes common compression standards recommended for G-G ATM
voice applications. Critical parameters that affect their performance include:
• Packet Loss
• Delays (e.g., Algorithmic/Processing, Packetization, Propagation5, and
Queuing), which could result in talker overlap
• Jitter
• Echo cancellation
• Sampling rate and bandwidth
• Synchronization
• Noise
Table 2 introduces various CODEC standards and their significant factors which are
either affected by, contribute to, or mitigate some of the aforementioned parameters:
Name Description Delay (ms) R- Ie Ie MOS
Factor6 (0% (2% loss) 8
7
loss)
G.711 with PCM A-law & µ-law at 0.125 89 0 7 4.3 -
PLC 64Kps 4.4
G.711 PCM A-law & µ-law at 0.125 59- 69 0 35 3.05
without PLC 64Kps
G.726 ADPCM at 16 – 40 Kbps 1 4.0 -
4.2
G.728 LD-CELP at 16Kbps 3-5 7 4.0 -
4.2
G.729A and CSACELP at 8 Kbps 10 (plus 5 ms 75 - 79 11 19 4.2 -
VAD look ahead) 3.99
G.723.1A MPMLQ at 6.3 Kbps 30 (plus 7.5 ms 70 - 75 15 24 3.8 -
and VAD look ahead) 4.0
iLBC9 low-bit rate, narrowband 30 (13.3Kbps) 0 2 3.8 -
13.3/15.2 kbps 20 (15.2Kbps) 3.67
10

GIPS with Enhanced G.711 Variable <0.125 0 2 4.3 -

VAD bit rate, average 80Kbps 4.411
TABLE 2 - CODEC PERFORMANCE FACTORS

5
This delay is dependent on the trunk, router, and switch speed.
6
R is a transmission rating factor, described in ITU-T G.107, which is based upon the E-model for predictive
transmission network planning; these figures assume a typical network
7
ITU-T G.113 Appendix I [92] provides guidelines on the effect of frame loss on voice quality in terms of the Ie
(Equipment Impairment) factor, which is a measure of the voice quality degradation as a result of the equipment
used (e.g., CODEC performance)
8
Mean Opinion Score; MOS above 4 is considered “toll quality” by the ITU-T P.800; these figures assume a
typical network.
9
For description of this protocol, see http://www.ilbcfreeware.org/
10
Refer to: www.globalipsound.com, iLBC white paper – October 2004, Figure1b
11
Refer to: www.GLOBALIPSOUND.com, GIPS Enhanced G.711 Figure 1b

© EUROCAE, 2009
 17

VoIP header and CODEC payload is shown in Table 3.

IP – 20 bytes UDP – 8 bytes RTP – 12 Payload 20 – 240 bytes for
bytes CODEC data
TABLE 3 - EXAMPLE OF VOIP HEADER

CODEC Descriptions
G.711: This standard presents 8 bit compressed Pulse Code Modulation (PCM)
samples from analog signals of voice frequencies. This standard supports two
algorithms:
• A-Law PCM encodes/decodes 13 bit linear PCM samples into 8 bit compressed
logarithmic form
• μ-Law converts 14 bit linear PCM samples into 8 bit compressed PCM samples
This CODEC has been supplemented with ANSI T1.521a-2000, Packet Loss
Concealment (PLC) with ITU-T Recommendation G.711 Proposed Annex B [91]. This
specifies a packet loss concealment algorithm that is applicable to most sample-based
CODECs, particularly G.711.
G.726: This standard is based on the Adaptive Differential Pulse Code Modulation
(ADPCM) algorithm. It takes signals sampled at 8000 samples/second and converts
them to a compressed form. G.726 can operate at 16, 24, 32, and 40 Kbps.
G.728: This standard is based upon the Low Delay Code Excited Linear Prediction
(LD-CELP) algorithm, which provides toll quality speech with low latency, and
compression for low bandwidth, which is often used for VoIP applications.
G.729: This protocol is based upon the Conjugate-Structure Algebraic Code Excited
Linear Prediction (CS-ACELP) algorithm, which provides toll-quality speech at very
low bandwidth with moderate processing overhead. Typical applications of this speech
coder are in telephony over packet networks, such VoIP. This coder works on a frame
of 80 speech samples (10 msec), and look ahead of 40 samples (5 msec). The total
algorithmic delay for the coder is 15 msec.
G.723.1: This protocol is based upon the following algorithms:
• Algebraic Code Excited Linear Prediction (ACELP) @ 5.3 Kbps
• Multi Pulse-Maximum Likelihood Quantization (MP-MLQ) @ 6.3 Kbps
It can perform full duplex compression and decompression for multimedia
applications, and is a part of the overall H.324 family of standards. This coder works
on a frame of 240 speech samples (30 msec), and look ahead of 60 samples (7.5
msec), for a total algorithmic delay of 37.5 msec, which is a significant delay.
iLBC: iLBC frames are encoded completely independently; this provides better quality
when 10% or more of the packets are being dropped, but this CODEC is suboptimal
for clean line conditions. iLBC is a narrowband speech CODEC, utilizing the full 4 KHz
frequency band. The iLBC algorithm enables state-of-the-art fixed bit-rate coding for
packet networks, with an excellent quality-versus-bit-rate tradeoff, and is suitable for
voice communication over IP.
GIPS: Global IP Sound® (GIPS™) Enhanced G.711 is the improved version of the
G.711 CODEC, which provides excellent packet-loss robustness. GIPS Enhanced
G.711 has built-in Voice Activity Detection (VAD) functionality that reduces the bit rate
to approximately half for silence and low audio levels. This is achieved without
distortion of speech or background signals. The benefits are:
• High basic speech quality equal to PSTN and G.711
• Superior packet-loss robustness compared to G.711
• Lower delay

© EUROCAE, 2009
 18

The CODECs described above are recommended for consideration to compress

global VoIP ATM communications. It is further recommended that, at a minimum, the
following critical parameters be tested and measured for the various CODECs:
• Transmission impairment (Ie)
• CODEC robustness when experiencing frame losses
• Delay and jitter
• Quality ratings (e.g., MOS, PSQM, and E-Model)
• End-to-End delay
• Signaling integrity
Since most of the G-series CODECs were developed for narrowband PSTN,
consideration should be given to the benefits incurred by using modern broadband
CODECs in current applications (e.g., radio, terrestrial broadband). Implementation
and transition scenarios should also be developed to deploy this new technology
without ATM service interruption.
Voice Quality Characteristics
QoS parameters are used to set voice service performance, affecting digital voice
quality, jitter, echo cancellation, silence suppression, background noise (may be
significant for wireless and satellite links), and frame losses.
Voice quality is also affected by the implementation of voice compression technologies
(i.e., Compression/Decompression (CODEC)), which reduce the required bandwidth
for voice services. Candidate CODECs should be selected based upon acceptable
quality of voice. A Mean Opinion Score (MOS) that ranges from 1.0 to 5.0 commonly
measures this [20]; a score of 4.0 is considered Toll Quality, which is the minimally
acceptable MOS for ATM applications. Various automated approaches exist that may
be used for objectively predicting MOS for VoIP.
Table 4 lists some prominent CODECs, and their characteristics:

Compression/Decompression Voice Digitizing Complexity Mean

(CODEC) Digitizing Delay (ms) Opinion
Rate (kbps) Score
(MOS)
PCM (G.711) 64 0.75 N/A 4.4
ADPCM (G.726) 32 1 Low 4.2
LD-CELP (G.728) 16 3-5 Very High 4.2
CS-ACELP (G.729/G.729a) 8 10 Moderate 4.2
MPMLG (G.723.1) 6.3 30 N/A 3.98
ACLEP (G.723.1) 5.3 30 N/A 3.5
TABLE 4 - PROMINENT CODEC CHARACTERISTICS

© EUROCAE, 2009
 19

APPENDIX C

MULTIMEDIA PROTOCOLS: H.323 AND SIP

Various standards organizations have considered signaling for voice and video over IP
from different approaches. Two of the primary standards in use are H.323 and SIP.
ITU established H.323 as the first communications protocol for real time multimedia
communication over IP. SIP is the IETF approach to voice, data, and video over IP.
H.323 is an umbrella standard that defines the system architecture (see Figure 9), and
implementation guidelines, for media and capabilities for multimedia communications
(e.g., call set-up, call control and features).

H.323v5 and H.460.x Core

Multimedia Data Transfer Signaling

Audio Video H.450.1 Series

Codecs Codecs T.120 (Supplementary
H.261 (Real Services)
[7] RTCP Time)
G.7xx H.263 (Real Time
Transport H.225.0 H.235
[8] T.130
Control RAS (Security)
(Audio-
Protocol) Visual
Q.931
Control)
(Call H.245
Signaling) (Control
Signaling)
RTP

UDP (User Datagram Protocol) TCP (Transfer Control Protocol)

IP (Internet Protocol) v4 or v6

FIGURE 9 : H.323 ARCHITECTURE

© EUROCAE, 2009
 20

In contrast to H.323, which was developed from the telecommunications perspective,

SIP provides analogous capabilities in the context of the Internet. As such, SIP is not
as rigidly specified as H.323, to accommodate the dynamic growth in IP capabilities.
SIP focuses on session initiation, relying on other protocols (not necessarily real-time)
for other call capabilities (see Figure 10).

SIP Suite

AV I/O
PINT
Data Application and system control equipment
Services
(Interface to
e.g., using
PSTN
RTSP Call Transfer/Conferences/Call Hold/
Signalling
e.g., ATS-
Call Monitoring and other Audio Video
Supplementary Services
QSIG)

Extension
Header SIP Methods

Message Body (e.g., SDP) RTP

TCP UDP

IPv4/6

FIGURE 10 : SIP ARCHITECTURE

© EUROCAE, 2009
 21
Table 5 describes the differences and similarities between H.323 and SIP functions and services.
Functions/Services H.323v5 SIP Comments

Encoding Binary Code Textual Binary code reduces the size of the transmission and
saves bandwidth.
Text is easier to modify and understand these codes,
and ports more readily over Internet-enabling
protocols, but it increases the size of messages that
are sent.
Call Set-up delay =1.5 * RTT = 1.5 * RTT H.323v5 reduced excessive Round Trip Time (RTT)
call delay experienced by previous versions of H.323.
However, work is still required to make SIP
compatible with H.323.
3G (Third Generation) No Yes 3G vendors have settled on a non-standard version of
SIP.
Protocol Complexity High Simple HTTP-style Protocol H.323 uses several different protocols (e.g., H.225.0,
H.245, H.450.x, H.460.x, H.501, H.510, H.530, and
T.120).
Extensibility Extensions added with vendor-specific non-standard Standards-based extensions to perform new functions
elements
Addressing Support Host (without username), E.164 phone numbers; Accommodates many addressing formats (e.g., URL, H.323 ENUM Service Registration
gatekeeper resolved alias (arbitrary case-sensitive E-mail address, H.323, E.164)
string)
Firewall Support Poor Inadequate Security in both protocols remains an issue, due to
poor interoperability of vendor products (e.g.,
gateways)
Instant Messaging No Yes
Loop Detection Imperfect Good SIP: routing loops detected; “spirals” recognized and
permitted.
Transport Protocol UDP and TCP. Mostly TCP. UDP and TCP. Mostly UDP. Usage of TCP results in greater call set-up latency.
Internet Application Not designed for Internet implementation Designed to incorporate Internet style text-based SIP is capable of integration with other services (e.g.,
Integration applications a caller may send an E-mail to an unreachable
callee).
Inter-domain Call Routing H.225 Annex G Domain Name System (DNS) For SIP, DNS is used to find the SIP server, but does
not resolve to the addressee level
Service Standardization Services standardized in detail in the H.450 series Services not standardized SIP only standardizes protocols and general
interfaces
Supplementary Services Rigorously defined Poorly defined Both standards are upgrading
Internet Compatibility Low High H.323 tries to impose ISDN architecture on IP network

Scalability Poor Excellent SIP is less complex and easy to customize

Type of Services Only media streams, including voice No obvious limitations SIP is almost perfectly general
Vender Interoperability Limited Widespread H.323 Interoperability is virtually non-existent
Quality of Services (e.g., Supports redundant gatekeepers. Policy Control has Loop detection algorithm using “VIA” header QoS capabilities are still not mature for H.323 and SIP
Call Setup delay, packet limited DiffServ support over IPv4
loss recovery, resource
reservation capability)
Interoperability Compatible with PSTN Signaling; uses Q.931-like Standards are draft Interfacing between H.323 and SIP, both protocols
messages, which are compatible with ATM-QSIG should translate call set-up and use RTP to
(Private Network) communicate with each other.
Mobile/Wireless Add version 5, reference to H.510 draft Designed for nomadic based services still on going Compatible
Capabilities
3GPP (Third Generation Currently No Yes
Partnership Project)
Security Defines security mechanisms and negotiation via Supports authentication via HTTP; confidentiality with Compatible
H.235; SSL may also be used SSL/TLS, SSH, S-HTTP, PGP, S/MIME; key
exchange with SDP
Architecture H.323 goes beyond basic signaling capabilities to Modular: Does only signaling; other functions (e.g.,
include conference control, registration, capability QoS, directory access, service discovery, and session
negotiation, QoS, and service discovery. content description) reside in separate, orthogonal
protocols
Components Terminal/Gateway UA (User Agents)
Gatekeeper Servers
Multicast Signaling Yes, with Location Requests (LRQ) and Gatekeeper Yes (e.g., group INVITEs) H.323 LRQ and GRQ are Registration, Admissions,
Request (GRQ) and Status (RAS) messages for discovery
Conference Yes Yes
Click for Dial Yes Yes
Large Number of Domains H.225 Annex G defines communication between Inherent support for wide area addressing. Loop
administrative domains, address resolution, access detection, Registrar, and redirect servers support user
authorization, and usage reporting. location with multiple servers.

TABLE 5 : COMPARISON OF H.323 AND SIP CAPABILITIES

© EUROCAE, 2009
 22

Features of the latest versions of H.323 and SIP

Some functions that have been included in H.323v5 are the following:
• Tunneling of DSS1/QSIG signaling within H.323 systems
• Use of URL and DNS services within the context of H.323 systems
• Modem relay within H.323 systems
• Camera control for video conferences
• Fault tolerance
• Number portability
• Call priority designation
• Transport of duplicate Q.931 IEs (Single-byte and Multi-byte),
• Fast connect
• Digit maps
• Querying for alternative routes
• QoS monitoring and reporting
• SIP as a support protocol
• Enhanced security
SIP has been chosen as the standard for call set-up in IP-based networks by the 3rd
Generation Partnership Project (3GPP), with the following enhancements:
• Address resolution and Name mapping
• Reliability of Provisional Responses
• Call redirection
• Determining the location of the target end point
• Enhanced packet size handover, and RTP header compression
• Enhance end-to-end QoS for terminal
• Additional options, such as wireless and mobile applications
• Support Multipurpose Internet Mail Extensions (MIME) and secure MIME
(S/MIME)
• Support unicast and multicast
• Event notification mechanisms
• Capability extension for Instant Messaging

© EUROCAE, 2009
 23

Figure 11 shows VoIP with SIP.

SIP/TCP or UDP
Signaling Signaling
IP
IP
IP
IP
Network
Network
Network
Network

Voice
IP Voice
IP
RTP/UDP
Network
Network

FIGURE 11 : VOIP WITH SIP

© EUROCAE, 2009
 24

APPENDIX D

COMPARISON OF IPV4 AND IPV6

Voice communication services are migrating to a common infrastructure approach that
provides support for multimedia applications (e.g., voice, video, and data). VoIP is
currently using IPv4 technology to support this new approach. However, its limitations
in end-to-end security, scalability, addressing, and Quality of Service (QoS)
capabilities may hamper the deployment of future Air Traffic Management (ATM) voice
services.
The section will focus on IPv6, which provides the networking services found in IPv4,
as well as these additional features:
• Larger address spaces
• More efficient addressing design and handling at the IP network layer
• Better QoS support
• Imbedded security
• Mobility and broadcasting
• Increased support for a variety of communication services
• Ensure future compatibility with industry, government, and international systems
• Airline industry is collaborating on a standard for airborne IPv6.
IPv4 was initially standardized in 1981. As the Internet became more ubiquitous, the
inherent IPv4 QoS, security, addressing, and scalability capabilities were pushed to
their limit. These deficiencies, as well as new network services, exacerbated the strain
placed on IPv4 technology and its quest to accommodate the global needs for Internet
services. To continue using IPv4 under this load required that new features and
capabilities be developed, standardized, and “bolted on”. This approach would have
been costly, risky, and difficult to manage. This resulted in the development of a next
generation networking protocol IPv6. IPv6 was designed to overcome the limitations of
IPv4 by:
• Expanding available IP address space to accommodate future demand
• Improving QoS to minimize packet loss/drops
• Operating over greater bandwidths for video conferencing and Voice over IP
(VoIP) applications
• Enhancing end-to-end security, which is critical for the ATM
• Providing more robust system management on an enterprise scale
• Eliminating the need for network address translation (NAT)
• Incorporating a fixed header structure, this expedites packet routing
The following diagrams show IPv4 and IPv6 header formats and field comparisons.

© EUROCAE, 2009
 25

• IPv4 Header

Version IHL Type of Service Total Length

Identification Flags Fragment Offset
Time-to-live Protocol Header Checksum
Source Address
Destination Address
Options Padding

• IPv6 Header
Version Class Flow Label
Payload Length Next Hop Limit

Source Address

Destination Address

FIGURE 12 : IPV4 AND IPV6 HEADER

A detailed comparison can be found in ED-138 Part 1 (see References in Introduction).

© EUROCAE, 2009
 26

APPENDIX E

NUMBERING AND ADDRESSING

Addressing plans are of particular importance in the establishment of communications
services. There are several currently-deployed voice communications technologies,
each associated with a particular addressing structure (e.g., ISDN, ATS-QSIG/PSS-1,
and PSTN). To establish network services across the various networking
technologies, a common numbering and addressing structure is described below that
is based on nationally and internationally approved standards (e.g., ITU-T, ECMA,
IETF, and ICAO).
A specific addressing scheme has been specified for the ATS voice communications
(see ED-137 Part 2: Telephone, paragraph 3.5).
Database Services
Call control databases manage user endpoint mapping, and provides address
translation services between disparate domains. Additional features include
transaction report generation, and network security.

Eurocontrol R2 addressing
All Air Traffic Control Center switches and switches at international airports are
connected by point-to-point dedicated circuits, using the Multi Frequency Code (MCF-
R2) signaling protocol [111] as shown below:
A A n n n n P A A n n n n

Calling Exchange and Terminal

Area Code of Originator
Priority
Called Exchange and Terminal
Area Code of Destination

Detailed information is contained in the CCITT Yellow Book Volume IV – Fascicle VI-4
[111] and Annex C of this document.

ICAO Recommended Numbering Plan

ICAO Annex 10, Vol. III, Part II, Chapter 4, ‘Recommendations for ATC Speech Circuit
Switching and Signaling’, calls for six-digit addresses for ATC facilities [82], as shown
below:
ICAO Format for ATC Speech Circuit Switching and Signaling
A A c c n n

Working Position
Control Center
Identification/Area

Up to two additional digits may be added to specify unique positions within the control
center.
The field specifications are 2 digits for area identifier (AA), 2 digits for Unit Identifier
(CC), and 2 digits for Controller working position (CWP) identifier.

© EUROCAE, 2009
 27

Integrated Services Digital Network (ISDN) Numbers and Addresses

The level 3 protocol on the ISDN D-Channel is configured for user-network signaling
for the control of calls, as well as for the control of supplementary services. ITU-T
Recommendation Q.931 (I.451) [25] respectively provides these functions. ISDN
numbering plan can be found in ITU-T Recommendation E.164.
ISDN Numbering Plan
National ISDN Number
International ISDN Number
ISDN Address
Country Code National Subscriber Subaddress
(CC) Destination Code Number (SN)
(NDC)

Up to 40 digits
Variable
Variable
Up to 3 digits

International Numbering Plans E.164

Recommendation E.164 [97] provides the number structure and functionality for the
three categories of numbers used for international public telecommunication:
1. National Telephone Services
2. Global Telephone Services
3. International Networks
All telephone numbers can be dialed up-to 15 digits, made up of a one to three digit
country code (CC), and followed by the subscriber number (SN). The first few digits of
the subscriber number generally identify the National Destination Code (NDC), which
identifies the type of telephone number being called. Relevant ITU Documents for
numbering plan are E.123, E.162, E.212, and E.164.

IP Addressing Scheme (Revised iPAX Scheme)

An IPv6 [107] addressing scheme had been developed within the context of the iPAX
Task Force and is illustrated in Figure 13.
The addressing scheme follows on from the RIPE allocation to provide /48
assignments. Indeed, when considering the existing IPv4 addressing schemes, most
Air Navigation Service Providers (ANSPs) already work with a “Class A” address (e.g.,
10.x.y.z), where x and y are 2 octets used to assign sites and subnets. With a /48,
ANSPs still have 2 octets to number their sites and subnets and can still make use of
IPv6 address auto-configuration. Fortunately, this matches the standard /48
assignments described in the RIPE policies.

© EUROCAE, 2009
 28

RIPE Responsibilty
(32 bits)

3 13 13 3 3 13 16 64

FP TLA ID Sub-TLA Res. NLA ID SLA ID Interface ID

Net. v4/ Site

F1 F2 LAN ESI
Prefix v6 Location
3 bits 7 bits 1 bit 5 bits variable bits variable bits 64 bits

Common Responsibilty ANSP Authority

(Coordination Body) (80 bits)
(16 bits)

FIGURE 13 : PROPOSED IPV6 ADDRESS STRUCTURE

To summarise the iPAX addressing scheme:

• The first 32 bits are fixed to 2001:4b50 (RIPE allocation)
• The 3 bits of Field F1 are reserved for future use
• The 7 bits of the fixed “Net. Prefix” field are used to number each ANSP,
organisation or infrastructure that can be considered as a single entity; network
prefix values have been revised since the iPAX-TF and can be found in Annex
A
• The 1 bit of the v4/v6 field is a toggle bit to indicate if IP address translation is
required at the network border.
• The 5 bits of F2 field are assigned as described in Annex B and have been
revised since the iPAX-TF.
ANSPs assign the remaining 80 bits of the address based on their own policies but
should note the advice provided in RFC 3353 (A Flexible Method for Managing the
Assignment of Bits of an IPv6 Address Block).

© EUROCAE, 2009
 29

APPENDIX F

VOIP COMPONENTS
The following describes VoIP technology components, and their interfaces, in support
of an enhanced G-G ATM infrastructure for establishing and managing VoIP services,
as shown in Figure 14.
End system: System that interfaces to users, such as a telephone, audio Personal
Computer (PC), Host, or radio (hardware/software)
Terminal Adapter (Modem): Interface between network and various telephones, Fax
machines, PCs and satellites
Codec: Implement compression techniques on voice signals to reduce bandwidth
requirements from legacy G.711 coding, while preserving voice quality
H.323 Gatekeeper, SIP Proxy: A gatekeeper/proxy provides centralized call
management functions; it may also provide call admission control, bandwidth
management, address translation, authentication, and user location
Gateway and Media Gateway: Interfaces signaling and communication services
among various telephone networks (e.g., between PSTN and VoIP). A Media Gateway
is used among multiple users to transfer packet data, signaling information, and
various stakeholders’ protocols
Media Gateway Controller, Call Agent: External call control elements that interface
and issue commands to Media Gateways
Multipoint-Controller–Unit (MCU): A MCU enables conferencing functions between
three or more terminals. Logically, a MCU contains two parts:
• Multipoint controller (MC) that handles the signaling and control messages
necessary to setup and manage conferences, and,
• Multipoint processor (MP) that accepts streams from endpoints replicates them
and forwards them to the correct participating endpoints.
A MCU can implement both MC and MP functions, in which case it is referred to as a
centralized MCU. Alternatively, a decentralized MCU handles only the MC functions,
leaving the multipoint processor function to the endpoints.
Private Branch Exchange (PBX): A private telephone network that creates
connections for telephones, terminals or other communications equipment either
directly attached to PBX or between connected PBXs and which also provides access
to the public telephone system
Router: A Router is a layer 3 device for forwarding packets (or message), and for
interconnecting two or more nodes across homogeneous or heterogeneous networks.
Routing protocols propagate topological relationships among routers and end systems
of a network (e.g., IP).
Backbone, Trunk: A Backbone is used for LAN/WAN connectivity between subnets
across a high-speed communications network such as Fiber optical cable or fast
Ethernet. A Trunk is a circuit that connects two or more switching or routing devices.
Recorder: Device that records voice and data communications on a network
Network Management: Set of procedures, equipment, tools, and operations for
monitoring and controlling network faults, configuration, usage accounting,
performance, and security
Uninterruptible Power Supply (UPS): Auxiliary power supply back up (e.g., battery,
generator) that supplies continuous power in the event of a power outage
Redundancy: Duplicate standby equipment or interface cards that are activated upon
device failure to ensure continuous service

© EUROCAE, 2009
 30

Node: (1) Physical equipment (e.g., computers, switches, routers) in a network. (2) In
a switched network, the switching points, including PBXs
Network: Collection of switches/routers connected to one another by transmission
facilities
Radiotelephony: Communications medium that provides mobile telephone services to
users
Wireless: Communications media that does not involve physical connectivity to the
network
Hub: A device that interconnects several stations. A hub is basically acting as a
repeater; it repeats an incoming signal on an outgoing link. In satellite networks, it is
used as a central earth station
SIP/User Agents: A user agent is end system acting on behalf of a user. There are two
parts to it: a client and a server. The client portion is called User Agent Client (UAC)
while the server portion is called User Agent Server (UAS). The UAC is used to initiate
a SIP request while the UAS is used to receive request and return responses on
behalf of the user
SIP/Network Servers: There are 3 types of services within a network. A registration
server receives updates concerning the current locations of users. A proxy server on
receiving request forwards them to the next-hop server, which has more information
about the location of the called party. A redirect server on receiving request
determines the next-hop server and returns the address of the next-hop server to the
client instead of forwarding the request.

N M S S ign ali ng
S ign ali ng
GW
GW
Q S IG S IG T R AN S IG T R AN
SS7
Ne tw o rk Ne tw o rk
MGC MGC

S IP -T

MGCP M GCP

MG MG
IP Ne tw o rk P riva te Ne tw o rk s
En te r p r is e

RTP
PBX/ GW PBX/
S wi tch GW
S wi tch
RTP

R AS R AS
GK MCU
H.32 3 T e rm in a ls/
T e le p h o n e s

FIGURE 14 : TYPICAL VOIP COMPONENT ARCHITECTURE

© EUROCAE, 2009

CHAPTER II REFERENCES
1 ITU-T H.323 Version 5, July 2003
2 ITU-T H.225.0, July 2003.
ITU-T H.225 Annex G, Sept.1999
3 ITU-T H.235, August 2003
4 ITU-T H.245, July 2003
5 ITU-T H.246, February 1998
6 ITU-T H.248.1, September 2005
7 ITU-T H.261, March 1993
8 ITU-T H.263, February 1998
9 ITU-T H.320, (March 2004),
H.321 (February 1998), H.324
(March 2002)
10 ITU-T H.332, September 1998
11 ITU-T H.450.1, February 1998
12 ITU-T G107, March 2003
13 ITU-T G.114, May 2003
14 ITU-T G.165, March 1993
ITU-T G 168, August 2004
15 ITU-T G.711, November 1988,
Appendixes I and II
16 ITU-T G.723.1, Annexes A, B, C,
Novembre 1996
17 ITU-T G.726, December 1990
18 ITU-T G.728, September 1992
19 ITU-T G.729 and G.729a, March
1996
20 ITU-T P.800 (August 1996),
P.800.1 (March 2003)
21 ITU-T P.861, February 1998
22 ITU-T P.862 (March 2003), 862.1
(November 2003)
31
Packet-based multimedia communications systems
Call Signaling Protocols and media stream
packetization for packet-based multimedia
communication systems
Security and Encryption for H-Series
Control Protocol for multimedia communication
Interlocking of H-Series multimedia terminal with H-
Series multimedia terminals and voice/voiceband
terminals on GSTN and ISDN
Gateway Control Protocol, version 3
Video Codec for Audiovisual services
Video Coding for Low Bit Rate Communication
Narrow-band visual telephone systems and terminal
equipment; Adaptation of H.320 visual telephone
terminals to B-ISDN environments; Terminal for low
bit-rate multimedia communication
H.323 extended for loosely coupled conferences
Generic function protocol for the support of
supplementary services in H.323
The E-Model, a computational model for use in
transmission planning
Guidance on One Way Delay for Voice over IP
Echo Cancellers
Digital Network Echo Cancellation
Pulse code modulation (PCM) of voice frequencies
Speech Coders: Dual Rate Speech coder for
Multimedia Communications Transmitting at 5.3 and
6.3 Kbps.
Silence compression scheme.
Alternative specification based on floating point
arithmetic.
Scalable channel coding scheme for wireless
applications
40, 32, 24, 16 Kbps Adaptive Differential Pulse Code
Modulation (ADPCM)
Coding of speech at 16 Kbps using low delay code
excited linear prediction
Coding of speech at 8 Kbps using conjugate-
structure algebraic-code-excited linear-prediction
(CS-ACELP)
Methods for Subjective Determination of
Transmission Quality; MOS Terminology
Objective quality measurement of telephone-band
(300-3400 Hz) speech codecs
Revised Annex A: Source code for the reference
implementation and conformance tests.Mapping
function for transforming P.862 raw result scores to
MOS-LQO
© EUROCAE, 2009

23 ITU-T Q.921: June 2000
24 ITU-T Q.922: January 2001, and
IETF RFC 2427, September
1998
25 ITU-T Q.931: May 1998, with
Amendment 1 December 2002,
and H.225
26 ITU-T.120, July 1996 and Annex
C, February 1998
27 ITU-T.130, February 1998
28 ITU-T Y.1310, March 2004
29 ITU-T Y.1540, December 2002,
and Amendment 1, August 2003
30 ITU-T Rec. Y.1541 (May 2002),
Amendment 1 (August 2003),
Amendment 2 (February 2004)
31 ECMA 312, 3rd Edition,
June 2003
32 Internet Telephony Volume 7
Number 4, 2004
33 IEEE 802.1p, 1998
34 IEEE 802.1Q, 2003
35 IEEE 802.3, May 2000
36 IETF RFC 791, 1981; RFC 2474,
1998; RFC 3168, 2001; RFC
3260, 2002
37 IETF RFC 793, 1981
38 IETF RFC 768, 1981
39 IETF RFC 1680, August 1994
IETF RFC 2225, April 1998
40 IETF RFC 1754, January 1995
41 IETF RFC 4271, January 2006
42 IETF RFCs 2205, 2209, and
2750, September 1997.
IETF RFCs 2210, 2211, 2212
(September 1997)
RFC 3936, October 2004;
RFC 4495, May 2006
43 IETF RFC 4346, 2006; RFC
4366, 2006; RFC 4680, 2006;
32
ISDN user-network interface – Data link layer
specification
Implementation Guide for Frame Relay (FR), Multi
protocol over FR
ISDN user-network interface layer 3 specification for
basic call control. Extensions for the support of
digital multiplexing equipment.
Data protocol for multimedia conferencing
Audio Video and Control for Conferences Multimedia
Architecture/General Vision
Transport of IP over ATM in Public Networks
Internet Protocol Data Communication Services – IP
Packet Transfer and Availability Performance
Parameters
Network Performance Objectives for IP-Based
Services (including QoS classes and values)
Private Integrated Services Network (PISN) – Profile
Standard for the Use of PSSI (QSIG) in Air Traffic
Services Networks
VoIP Security: Stakes Get High As Deployments
Grow
Traffic Class Expediting and Dynamic Multicast
Filtering
Virtual Bridge Local Area Networks
Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical
Layer Specifications Aggregation of Multiple Link
Segments
Internet Protocol Specification;
Definition of the DS Field in the IPv4 and IPv6
Headers;
The Addition of ECN to IP;
New Terminology and Clarifications for Diffserv
Transmission Control Protocol
User Data-gram Protocol
IPng Support for ATM Services (Info).
Classical IP & ARP over ATM
IP over ATM Working Group’s Recommendations for
the ATM Forum’s Multiprotocol BOF, Version 1
(Informational)
A Border Gateway Protocol 4 (BGP-4)
Resource Reservation Protocol (RSVP) standards.
The Use of RSVP with IETF Integrated Services;
Specification of the Controlled-Load Network
Element Service; Specification of Guaranteed Quality
of Service; Procedures for Modifying the RSVP; A
RSVP Extension for the Reduction of Bandwidth of a
Reservation Flow
The TLS Protocol Version 1.1; TLS Extensions; TLS
Handshake Message for Supplemental Data; TLS
© EUROCAE, 2009

RFC 4681, 2006
44 IETF RFC 2326, April 1998
45 IETF RFC 4566, July 2006
46 IETF RFC 2328, April 1998
47 IETF RFC 4302, 2005; RFC
4835, 2007
48 IETF RFC 4303, 2005; RFC
4835, 2007
49 IETF RFC 4306, 2005
50 IETF RFC-3142, 2001
51 ITU-T Rec., E.123, 1988
52 IETF RFCs 2474 (December
1998), 3168 (September 2001),
3260 (April 2002)
53 IETF RFC 2460, 1998
54 IETF RFC 4443, 2006; RFC
4884, 2007
55 IETF RFC 2484, January 1999
56 IETF RFC 4364, 2006; RFC
4577, 2006; RFC 4684, 2006
57 IETF RFC 2597, June 1999; RFC
3260, April 2002
58 IETF RFC 2764, February 2000
59 IETF RFC 2824, May 2000
60 IETF RFC 2848, June 2000
61 IETF RFC 2871, June 2000
62 IETF RFC 3031, January 2001
63 IETF RFC 3168, 2001
64 IETF RFC 3246, March 2002
65 IETF RFC 3261, June 2002 RFC
3265, June 2002;
RFC 3853, July 2004;
RFC 4320. January 2006;
RFC 4916, June 2007
66 IETF RFC 3262, June 2002
67 IETF RFC 3263, June 2002
68 IETF RFC 3264, June 2002
33
User Mapping Extension
Real Time Streaming Protocol (RTSP)
SDP: Session Description Protocol
OSPF Version 2
IP Authentication Header;
Cryptographic Algorithm Implementation
Requirements for ESP and AH
IP Encapsulating Security Payload (ESP);
Cryptographic Algorithm Implementation
Requirements for ESP and AH
IKEv2 Protocol
An IPv6-tp-IPv4 Transport Relay Translator
Notation for National and International Telepone
Numbering
Differential Services (DiffServ) and Explicit
Congestion Notification (ECN) standards
Internet Protocol, Version 6 (IPv6) Specification
Internet Control Message Protocol (ICMPv6) for the
Internet Protocol Version 6 (IPv6) Specification;
Extended ICMP to Support Multi-Part Messages
PPP LCP Internationalization Configuration Option
BGP/MPLS IP VPNs;
OSPF as the Provider/Customer Edge Protocol for
BGP/MPLS IP VPNs;
Constrained Route Distribution for BGP/MPLS IP
VPNs
Assured Forwarding PHB Group; New Terminology
and Clarifications for Diffserv
A Framework for IP Based Virtual Private Network
(Informational)
Call Processing Language Framework and
Requirements (Informational)
The PINT Service Protocol: Extensions to SIP and
SDP for IP Access to Telephone Call Services
A Framework for Telephony Routing over IP
Multiprotocol Label Switching Architecture
The Addition of Explicit Congestion Notification
(ECN) to IP
An Expedited Forwarding PHB (Per-Hop Behavior)
SIP: Session Initiation Protocol;
SIP-Specific Event Notification;
S/MIME Advance Encryption Standard (AES)
Requirement for the SIP; Actions Addressing
Identified Issues with the SIP’s Non-INVITE
Transaction; Connected Identity in the SIP
Reliability of Provisional Responses in the Session
Initiation Protocol (SIP)
Session Initiation Protocol (SIP): Locating SIP
Servers
An Offer/Answer Model with the Session Description
Protocol (SDP)
© EUROCAE, 2009
 34

69 IETF RFC 3265, June 2002 Session Initiation Protocol (SIP)-Specific Event
Notification
70 IETF RFC 4566, July 2006 SDP: Session Description Protocol
71 IETF RFC 3372, September Session Initiation Protocol for Telephones (SIP-T):
2002 Context and Architectures
72 IETF RFC 3525, June 2003 Gateway Control Protocol Version 1
73 IETF RFC 3550, July 2003, and RTP: A Transport Protocol for Real-Time
IETF RFC 3551 Applications (RTCP)
74 IETF RFC 3711, 2004 The Secure Real-Time Transport Protocol (SRTP)
75 EUR 145-05/GT 67-15, April Minutes of the 7th Meeting of WG-67 (VoIP for ATM)
2005
76 IETF RFC 2974, October 2000 SAP: Session Announcement Protocol
77 IETF RFC 3435, January 2003, Media Gateway Control Protocol V- 1.0.
IETF RFC 3661, December 2003 MGCP Return Code Usage
78 IETF RFC 3762, 2004 Telephone Numbering Mapping (ENUM) Service
Registration for H.323
79 IETF RFC 1157, May 1990 A Simple Network Management Protocol (SNMP);

IETF RFC 3413, December 2002 SNMP Applications

80 IETF RFC 3764, 2004 Enum Service registration for SIP Address-of-Record
81 IETF RFC 3953, 2005 Telephone Numbering Mapping (ENUM) Service
Registration for Presence Services
82 ICAO Annex 10, Vol. III, Part II., Recommended Voice Addressing Plan.
Chapter 4, 1995, and
Doc 9804, 2002 Manual on ATS Ground Voice Switching
83 ITU-T E.212, 2004 International Identification Plan for Mobile Terminal
and Mobile Users
84 ITU-T E.160 rev.1, 1993 Definition Relating to National and International
Numbering Plan
85 ITU-T E.162, 1995 Capability for 7 digit analysis of International E.164
Numbers
86 ITU-T E.164, 1997 International Telephone Numbering Plan
87 ECMA-155, 1997 Private Integrated Service Network-Addressing
88 IETF RFC 4733, December RTP Payload for DTMF Digits, Telephony Tones and
2006; RFC 4734, December Telephony Signals;
2006 Definition of Events for Modem, Fax, and Text
Telephony Signals
89 ITU-T.125, April 1994 Multipoint communication service protocol
specification
90 NIST Spécial Publication 800-58, Security Considerations for VoIP Systems
January 2005
91 ANSI T1.521a-2000, June 2000 Packet Loss Concealment with ITU-T
Recommendation G.711 Annex B
92 ITU G.113 Appendix I, Provisional Planning Values for the equipment
Septembre, 1999 impairment factor Ie
93 ITU-T E.123, 1988 Notation for National and International Telephone
Numbering
94 ITU-T G.131 October, 1996 Control of Talker Echo
95 ITU-T Q.705, March 1993 Signaling Network Structure
96 ITU-T Q.708, March 1999 Assignment procedures for international signaling
point code
97 IETF RFC 3761, April 2004 The E.164 to Uniform Resource Identifiers (URI)
Dynamic Delegation Discovery System (DDDS)

© EUROCAE, 2009
 35

Application (ENUM)
98 IETF RFC 2198, September RTP Payload Redundant Audio Data
1997
99 ITU-T H.460.x, Novembre 2004 Document series on the Generic Extensibility
Framework for H.323 enhancements
100 IETF RFC 3611, November 2003 RTP Control Protocol Extended Reports (RTCP XR)
101 IETF RFC 3951, December 2004 Internal Low Bit Rate Codec (iLBC), Experimental
102 IETF RFC 3952, December 2004 RTP Payload Format for iLBC speech, Experimental
103 IETF RFC 4301, December 2005 Security Architecture for the Internet Protocol

104 COMT-31 Working Paper 10, Report on ATS Ground Voice Network Numbering
EUROCONTROL, October 2004 Plan
105 draft-zimmermann-avt-zrtp-01.txt, ZRTP: Extensions to RTP for Diffie-Hellman Key
Internet-Draft, March 5, 2006 Agreement for SRTP
draft-zimmermann-avt-zrtp-01
106 IETF RFC 3353, August 2002, Overview of IP Multicasting in a MPLS Environment
Informational
107 E67-IP03-SG1#5-EURO03 EUROCONTROL IPv6
108 IETF RFC-2460, December 1998 IPv6 Specification
109 IETF RFC-3596, 2003 DNS Extensions to Support IPv6
110 IETF RFC-4291, February 2006 IP Version 6 Addressing Architecture
111 ITU-T Rec.,Q.400 and Q.490, Specification of Signalling R2
November 1988
112 IETF RFC-2526, 1999 Reserved IPv6 Subnet Anycast Addressing, using
EUI-64 format
113 IETF RFC-4213, 2005 Basic Transition Mechanisms for IPv6
114 IETF RFC-2766, 2000 Network Address Translation-Protocol (NAT-PT)
115 IETF RFC-2765, 2000 Stateless IP/ICMP translation Algorithms (SIIT)

116 IETF RFC-4214, 2005 Intra-Site Automatic Tunnel Addressing Protocol

(ISATAP)
117 IETF RFC-2464, 1998 Transmission of IPv6 Packets over Ethernet
Networks
118 IETF RFC-1887, December 1995 An Architecture for IPv6 Unicast Address Allocation
119 IETF RFC-3232, January 2002 Assigned Numbering
120 IETF RFC-3142, 2001 An IPv6-tp-IPv4 Transport Relay Translator
121 ITU-T Rec., E.123, 1988 Notation for National and International Telepone
Numbering

© EUROCAE, 2009
 36

CHAPTER III

NETWORK AVAILABILITY, RELIABILITY, MAINTAINABILITY

3.1 INTRODUCTION

The need and benefits of moving in voice communications from the old, analogue
network to converged networks, has been already demonstrated for years. Despite the
clear advantages that a converged network offers to users, careful network design
should be considered when moving to the new approach. The VoIP networks should
offer at least the same availability of resources, quality of service and security as the
classic telephony does.
Voice over IP networks should be stable, scalable and very fast reconfigurable around
failures, so that no interruption of services could be observed by the users. These
features are provided by traditional routing protocols in data networks, which ensure
the automatic, event-driven, reconfiguration of the network paths in the network, in
order to keep forwarding data without the user knowledge that something has
happened.
The traditional requirements for network convergence time around failures, which
were imposed for data applications, are not, however, suitable for voice
communications. In the last years, anyway, a lot of features and technologies were
introduced in hardware and software for networking, making the data networks
suitable for transporting voice communications.
In this chapter, we examine the main features and technologies in the area of
rendundancy, availability and convergence time of IP networks, and the benefits they
add to the traditional data networks.

3.2 BACKGROUND AND SCOPE

For the purpose of supporting Voice over IP applications with performances similar to
the classic telephony, the IP infrastructure must ensure smooth delivery of the voice
and signaling packets to the VoIP elements.
Although network failures are rare, planning for them is essential. Failover strategies
are desirable for cases when network devices malfunction or links are broken. An
important strategy is to deploy redundant links between network devices and/or to
deploy redundant equipment. To ensure continued service, organizations should plan
carefully for how media gateways and media gateway controllers can make use of the
redundant schemes.
The requirements for VoIP communications, pushed the vendors of network
equipments to offer new features in the area of network availability. Combining
different technologies and configurations, it is now possible to obtain convergence
times for the network of 1 second, which makes the network suitable for VoIP
applications that are mission/time critical, which is the case in ATM communications.
This working paper covers the main technologies and features of today’s network
equipments used to improve nework availability without negatively impacting the
scalability of the network, and to speed-up the convergence of IP networks.
The subject of convergence is related to that of network redundancy, which by
definition is the ability to choose between different paths into the network, from one
source to one destination, at any given time, reacting to events in the network.

© EUROCAE, 2009
 37

Availability, Redundancy, Convergence – Definitions

Availability =
The probability that the network (or an item) is operational and functional as required
at any given moment in time.
The expected or measured fraction of time the defined service, device, application,
area is operational. Annual uptime is the amount of time: in days, hours, minutes the
item is operational and functional.
Redundancy =
The quality of systems or elements of a system that are backed up with secondary
resources. For example, “The network has redundancy.”
Network Convergence Time =
The period beginning when a topology change occurs and ending the moment all
routers have a consistent view of the network (have a loop free path to each possible
destination).
The time needed for traffic to be rerouted to the alternative or more optimal path after
a network event.

3.3 HIGH AVAILABILITY IN NETWORKING

In both Enterprise and Service Provider networks, the convergence of business-critical

applications onto a common IP infrastructure is becoming more common. Given the
criticality of the data, these networks are typically constructed with a high degree of
redundancy. While such redundancy is desirable, its effectiveness is dependant upon
the ability of individual network devices to quickly detect failures and reroute traffic to
an alternate path.
Carefull network design should be done when businesses, like ATC Services for
instance, are asking for a network that can converge in minimal times (something
below 1 second), especially for large networks. For many time-critical voice (over IP)
networks, it is considered that the network design should provide one-second network
fault recovery to ensure service continuity and eliminate dropped calls.

3.3.1 Defining Availability

Reliability, resiliency, and availability are sometimes used interchangeably. However,

although all three terms are related to the concept of high availability, it is important to
note the differences in terminology. Reliability is the probability that a system will not
fail during a specified period of time. Resiliency is the ability of a system to recover to
its normal operating form after a failure or an outage. Availability is the ratio of time
that a service is available to total time.
Availability can be expressed as mean time between failure (MTBF) and mean time to
repair (MTTR), and expressed in mathematical terms as:
Availability = MTBF/(MTBF+MTTR)

© EUROCAE, 2009
 38

MTBF is tied to the reliability of the system, while MTTR and resiliency are closely
related. Thus system availability increases as the reliability and/or resiliency of the
system is increased. Availability is typically expressed in percentage of time the
system is available or in downtime per year. The two methods of expressing
availability are equivalent and related as shown in Table 6.

Number of 9s Availability Dowtime per Year Types of System

1 90.0000% 36 days, 12 hours
2 99.0000% 87 hours, 36 minutes
3 99.9000% 8 hours, 46 minutes
4 99.9900% 52 minutes, 33 seconds
5 99.9990% 5 minutes, 15 seconds
6 99.9999% 31.5 seconds
TABLE 6 - AVAILABILITY FIGURES
Fax machines, printers
Dial ISPs, non-critical business
systems
Data Centers
Redundant storage arrays
Aviation and military defense

This definition for availability is good for a simplex system (a system comprising of one
element). However, in a network that consists of multiple trunks and routers, most
failures are partial failures. Service disruptions resulting from such failures typically
affect a subset of customers, while service for others is uninterrupted. Further, even
within a network element only one component may fail, thus only disrupting service for
a subset of users serviced by the network element. Hence availability is defined with
respect to a single customer of the network. Therefore, to compute availability, it is
necessary only to consider the components along the path needed to provide service
to a single customer.
Another important metric is Defects Per Million (DPM), defined as the number of
defects that an end customer would experience per million events. This metric is
adaptable to the application being run on the network and relates directly to the
service availability as seen by the end user. In the telephony space there are two
critical metrics for service availability: DPM for calls dropped and DPM for ineffective
attempts.
DPM for calls dropped refers to the number of calls per million that are dropped while
in progress. DPM for ineffective attempts refers to the number of calls per million that
cannot be set up due to a failure in the signaling path.

3.3.2 Calculating Availability

The common availability definition of MTBF/(MTBF+MTTR) does not fully address

complex systems. Real-world networks are a complex mixture of serial and parallel
network elements. If components are combined in series, the overall network relies on
the availability of all components and the total system availability can be much lower
than the availability of the weakest component. However, if components are combined
in parallel, with redundancy provided by the parallel components, the system
availability can be higher than that of the most available component.
For systems comprised of elements in series (Figure 15), the overall system
availability is the product of the individual element availability values. For systems
comprised of elements in parallel (Figure 16), the availability of the system is one
minus the product of the individual component unavailability values (where
unavailability = 1 - availability). This concept is ilustrated in the figures below.

© EUROCAE, 2009
 39

FIGURE 15 : SYSTEM AVAILABILITY OF ELEMENTS IN SERIES

FIGURE 16 : SYSTEM AVAILABILITY OF ELEMENTS IN PARALLEL

High network availability results from attention to three key points:

• Choice of high-availability network elements, hardware, and software
• Creation and maintenance of a high-availability environment (including security)
• Use of network design and operations practices that emphasize high availability
Efforts in all three of these areas must consider the entire network, including ANSPs
LAN, campus networks and WAN services (intra and inter ANSPs) provided by
carriers or other network service providers (see figure below). This end-to-end
perspective is the only way to minimize the chances and frequency of failure, to
minimize the duration of inevitable outages, and to achieve the quality required by
operational specifications for communications in ATM.

© EUROCAE, 2009
 40

FIGURE 17 : NETWORK ELEMENTS AND DESIGN

3.3.3 High-availability platforms

Redundant designs can have one active and one redundant element (1:1), or one
redundant element for every N elements that are active (1:N).
Redundancy is only as effective as the switchover process, which must detect the
problem and move the load to the redundant element-with no loss of traffic-all within a
very short amount of time. Systems with load-sharing redundancy designs are
generally preferred to those with an active-plus-standby approach, but is worth
mentioning that load sharing in the case of VoIP could only be done at a session/flow
level.
Many modular products allow for harmless insertion and removal of cards while the
system is in service, thus minimizing the chance of an accidental, operations-caused
network failure. Many products offer optional 48-volt DC power supplies, for use in
telephone central offices, data centers, or other locations where 48-volt, battery-based
uninterruptible power supply (UPS) installations are available.

3.3.4 High-availability network design

The best network design practices should take into account the end-to-end
perspective, including the LAN and ANSP backbone, the ANSP premises edge, the
service provider aggregation edge, and the service provider core. In each of these
areas, avoiding any "single point of failure" is a major goal in network design. There
should be few or no instances where there is only one of anything: routers, switches,
servers, media gateways, etc., or paths connecting all of these. Servers should be
dual-homed to multiple Ethernet switches. The impact of redundancy can be dramatic.
Figure 18 illustrates a campus environment and traces an end-to-end connection from
one user to another. The simplest design has many single points of failure and has a
calculated availability of 99.938 percent, or about 325 minutes (more than 5 hours) of
outage each year. Adding redundancy significantly improves this failure rate, down to
about 30 seconds per year, in the last example design.

© EUROCAE, 2009
 41

FIGURE 18 : NETWORK AVAILABILITY OF DIFFERENT DESIGNS

3.3.5 High availability inside ANSP networks

Many features and technologies address the area of availability inside the enterprise
network. These technologies could be implemented, and are usually, by each ANSP,
in order to ensure a high level of reliability for data and voice over data (IP)
communications.
Access Layer – Layer 2 Redundancy:
• Power supply redundancy
• Redundant supervisor cards in access switches
• Access port/link/switch resiliency/redundancy features
• Redundant uplinks to the distribution (uplink) switches, corelated with loop
avoidance technologies like Spanning Tree, Multi-link Trunking
o MAC Bridging (IEEE 802.1D-2004), IEEE 802.1s MST – Multiple
Spanning Tree Protocol
o Multi-link Trunking and Split Multi-link Trunking (Nortel Proprietary)
o IEEE Link Aggregation Control Protocol (IEEE 802.3ad)
• Uni-directional Link Detection Protocol (UDLD)
• Switch Stacking

© EUROCAE, 2009
 42

Distribution Layer – Layer 3 redundancy:

• Redundant uplinks to the core switches
• Power Supply Redundancy
• Route Processor Redundancy technologies
• Non-stop Forwarding (NSF) and Statefull Switchover (SSO)
• Switching Fabric Redundancy
• First Hop Redundancy Protocols: VRRP (IETF Virtual Router Redundancy
Protocol), HSRP (Cisco Hot Standby Router Protocol), GLBP (Cisco Gateway
Load Balancing Protocol) with tracking capabilities (uplink interface tracking or
route tracking)
Core Layer (inside ANSP, and inter-ANSP):
• Layer 3 routing protocol redundancy: BGP convergence optimization, routing
protocol NSF awareness, incremental SPF (Shortest Path First) technologies
for IS-IS and OSPF, IP event dampening
• Network level redundancy: sub-second convergence, MPLS Fast-reroute

3.3.5.1 Access Layer – Layer 2 Redundancy

3.3.5.1.1 MAC Bridging (IEEE 802.1D-2004)

Spanning-Tree Protocol is a link management protocol that provides path redundancy

while preventing undesirable loops in the network. For an Ethernet network to function
properly, only one active path can exist between two stations.
Multiple active paths between stations cause loops in the network. If a loop exists in
the network topology, the potential exists for duplication of messages. When loops
occur, some switches see stations appear on both sides of the switch. This condition
confuses the forwarding algorithm and allows duplicate frames to be forwarded.
To provide path redundancy, Spanning-Tree Protocol defines a tree that spans all
switches in an extended network. Spanning-Tree Protocol forces certain redundant
data paths into a standby (blocked) state. If one network segment in the Spanning-
Tree Protocol becomes unreachable, or if Spanning-Tree Protocol costs change, the
spanning-tree algorithm reconfigures the spanning-tree topology and reestablishes the
link by activating the standby path.
Spanning Tree topology can be thought of as a tree: it includes a root (a Root Bridge),
branches (LANs and Designated Switches), and leaves (End Nodes). On a tree there
are no disconnected parts that are considered part of the tree; that is, the tree
encompasses all of its leaves. In addition, there are no loops in a tree. If you trace a
path from one leaf to any other leaf, you will find there is one, and only one, possible
path. This is true of the Spanning Tree topology as well. It organizes and connects
switches into a loop-free topology while leaving no segments isolated.
Spanning-Tree Protocol operation is transparent to end stations, which are unaware
whether they are connected to a single LAN segment or a switched LAN of multiple
segments. STP is a protocol that detects and eliminates logical loops in a bridged or
switched network.
The STP algorithm does not allow, unfortunately, by its nature, a fast recovery from
link failures, since the convergence of the STP is usually of about 30-50 seconds.
Most current applications require HA systems to switch over in less than a second.
Since STP is so slow, it’s not practical for today’s applications – a faster protocol is
needed. The IEEE-802.1w working group has delivered just that – a newer protocol
called Rapid Reconfiguration or Rapid Spanning Tree Protocol (RSTP).
RSTP is not so much a new protocol, but rather an improved and faster version of
STP. It preserves all the basic concepts of STP and interoperates with it as well.

© EUROCAE, 2009
 43

In many respects STP and RSTP work the same. They reduce the bridged network to
a single spanning tree topology in order to eliminate loops. Either algorithm reactivates
redundant connections in the event of a link or component failure. The main difference
is convergence time. While it may take STP 30 to 50 seconds to re-converge, RSTP
does it in dramatically less time.
RSTP (IEEE 802.1w) can achieve much faster convergence in a properly configured
network, sometimes in the order of a few hundred milliseconds. Classic 802.1d timers
such as forward delay and max_age are nearly only used as a backup and should not
be necessary if point-to-point links and edge ports are properly identified set by the
administrator, and if there is no interaction with legacy bridges.

3.3.5.1.2 Multiple Spanning Tree Protocol (IEEE 802.1s)

The IEEE 802.1s Multiple Spanning Tree Protocol (MSTP) was developed to provide
an efficient means of supporting the multiple instances of ST required for deploying
numerous VLANs in a switched Ethernet LAN. Instead of a separate instance of ST for
each VLAN, MSTP provides for a grouping of VLANs to share a common instance of
ST. Since the number of different logical topologies is generally much smaller than the
number of VLANs, much less CPU capacity is required for calculating spanning trees.
MSTP VLANs allow network designs exploiting 802.1Q VLANs to incorporate active
load sharing across redundant Layer 2 links and switches.
MSTP (IEEE 802.1s) standardizes the concept of multiple spanning trees,
incorporating the rapid convergence offered by RSTP. MSTP allows a group of VLANs
to share a spanning tree instance, defines a protocol for inter-connecting MST
regions, and interoperate with existing 802.1d and 802.1q spanning tree
implementation.
MSTP (IEEE 802.1s) is based on RSTP (IEEE 802.1w) and VLAN (IEEE 802.1Q) and
Cisco Per-VLAN Spanning Tree (PVST+). It implements a set of multiple and
independent spanning tree instances (MSTI) in a network region that is interconnected
via a common spanning tree (CST) to another MST regions.
Inside a region, several VLANs can be mapped to a single tree instance. Multiple tree
instances at each region make it possible to improve the usage of the links. At each
region, there is a tree instance (IST), identified with the number 0, that acts as the
basic spanning tree. The CIST or total spanning tree is comprised of the CST that
connects all the regions, and the IST that provides connectivity inside each region.
This architecture is shown in figure below. It allows separated management of the
regions, appearing to the outside as a unique and separate “superbridge”, i.e. the
whole region connects to the CST via one Regional Root Bridge port and a number of
designated ports, like a single bridge. Therefore, no change in internal topology is
influenced or produced by outside topology changes.

© EUROCAE, 2009
 44

FIGURE 19 : MULTIPLE SPANNING TREE PROTOCOL

As a result of this architecture, MSTP configuration is complex. VLANs must be

mapped to tree instances and this configuration table must be exactly the same for all
bridges of the same region.

3.3.5.1.3 Split Multi-link Trunking (SMLT)

When building redundant networks, Multi-Link Trunking (MLT) offers link redundancy
as a protective measure against link failures. Multi-Link Trunking is a means of
providing physical layer protection against the failure of a single link, while enabling
the use of the bandwidth of all aggregated links (within MLT) in normal conditions.
Split Multi-Link Trunking (SMLT) is a means of providing an additional level of
protection against failures. SMLT enables node redundancy by allowing MLT links of
link-aggregated groups to be dual-homed across a pair of aggregating devices, herein
referred to as a pair of SMLT aggregation devices.
SMLT enables topologies with upstream node redundancy for increased reliability of
Layer 2 link aggregation subnetworks based on [IEEE 802.3ad] and router
redundancy based on VRRP [RFC 3768].
SMLT is MLT with links of a link-aggregation group connected to ports on two different
devices (e.g. SMLT client and aggregation device). Unlike MLT, at least one end of a
link-aggregated group is dual-homed to two different SMLT aggregation devices. In
many cases those devices act as bridges (switches) as well as L3 routers (Routing
Switches). These two redundant SMLT aggregation devices can share one or more
VRRP routing instances; for that SMLT-VRRP extends the VRRP functionality to an
active-active router concept, where both SMLT aggregation device route traffic for a
common VRRP-ID, thus load balancing traffic not only for L2 but also for L3.

© EUROCAE, 2009
 45

SMLT is a Nortel Networks architecture that helps eliminate single points of failure and
creates multiple paths from user access switches to the core of the network. It also
works to reroute failures as quickly as possible. Building on the redundancy offered by
Nortel Networks DMLT (Distributed MLT), SMLT improves network redundancy and
resiliency even further by dual homing edge switches to a pair of aggregation or core
switches.
A working document was submitted to the IETF RFC Repository regarding the SMLT,
as an Internet-Draft.
SMLT improves the reliability of a layer 2 (L2) network operating between a building’s
user access switches and the network center aggregation switch. It does so by
providing load sharing among all the links and fast fail over in case of link failures.
SMLT provides much faster convergence than Spanning Tree (IEEE 802.1d) (typically
one second versus 30-50 seconds). SMLT also eliminates the blocking of ports, thus
increasing network bandwidth, since all trunks between switches can be utilized for
user traffic (with Spanning Tree this requires the use of multiple spanning tree
groups).
SMLT Components:
• SMLT aggregation switch, is a switch that connects to multiple wiring closet
switches, edge switches or CPE devices, typically within a single building. An
SMLT aggregation switch shares an IST link with another SMLT capable switch
to form a redundant core.
• Inter Switch Trunk (IST) - one or more aggregated parallel point-to-point links
that connect two ggregation switches together. The two Aggregation switches
utilize this channel to share information so that they may operate as a single
logical switch for bridging.
• Split Multi-Link Trunk (SMLT) - a Multi-Link Trunk, which is, split between two
aggregation switches.
• SMLT Client - a switch, capable of link aggregation, located at the edge of the
network, such as in a wiring closet or CPE.
• SMLT ID - an ID that is shared between the two SMLT aggregation switches
connecting to one SMLT client. Each SMLT client requires a new SMLT id.
SMLT is to be used in LAN aggregation points (e.g. a building basement where two or
more switches are used to distribute connections to each floor); a campus LAN
backbone (where two or more core switches are used to aggregate the connections
from each building); and/or a server farm where two or more switches are used to
provide redundant server connections.
Regarding interoperability between different vendor solutions, Layer 2 switches that
interoperate with Multi-Link Trunking (MLT) will work with SMLT. For instance, SMLT
has been tested with and works with Fast EtherChannel in most instances. Also,
servers using a Network Interface Card (NIC) that is interoperable with MLT will work
with SMLT.
Spanning Tree Protocol (STP) is disabled on the SMLT ports (e.g. disable STP on all
core switches using SMLT and all edge switches connected to those core switches).
The IST allows the two core switches to share forwarding tables, making them appear
to the edge switches or servers as a single core switch using a normal MLT trunk.
Link failures are detected by the LOS (loss of signal) mechanism on the SMLT links.
The LOS of an SMLT link is exchanged between the SMLT aggregation pair through
the IST protocol. Edge switches also detect failure of a trunk to the core switches
using the standard MLT algorithm. It is recommended to enable Auto-Negotiation on
Gigabit Ethernet links to enable Remote fault indication, which is part of IEEE 802.3z.
This will allow the detection of single-fiber failures.

© EUROCAE, 2009
 46

SMLT typically converges in less than one second, but is dependent on the edge
switch failover mechanism. If a one second ping trace is used for testing, expect to
see either no pings lost or a single ping lost when a link is broken or a core switch is
powered off.
The IST is a critical element of SMLT, allowing exchange of forwarding tables between
the core switches. If the IST fails, the forwarding tables for single-attached devices
e.g. a server which is attached to only one of the core switches) may become
inaccurate and network problems may occur on that device. The IST should be
protected from failures by using multiple ports on different slots in each core switch
(Distributed MLT) and diversely routed fiber cabling. Up to 8 separate fibers and 8
separate ports on each core switch can be grouped together to form the IST. Edge
switches and servers should be dual-homed to both core switches to avoid possible
impact of an IST failure.
SMLT is transparent to Layer 3 protocols such as VRRP. A VRRP extension for SMLT
allows for VRRP active-active configurations where both SMLT aggregation switches
will be forwarding/routing traffic received on SMLT links. This VRRP extension is
called VRRP BackupMaster.
SMLT is not limited to the LAN. It can be used in Metro networks by using either long-
haul GBICs (XD or ZX) or CWDM GBICs and Optical Add/Drop Muxes.
MultiLink Trunking (MLT) is a point-to-point connection that aggregates multiple ports
on the same device so that they logically act like a single port with the aggregated
bandwidth.
Distributed Multi-Link Trunk (DMLT) creates a group of ports (trunk) where trunk
members (ports) can reside on multiple cards (modular solution) or multiple units
stackable solution) for increased redundancy and reliability.

3.3.5.1.4 Link Aggregation Control Protocol (LACP)

LACP is a standards-based link aggregation technology, defined in IEEE 802.3ad

(also known as IEEE 802.3 Clause 43, “Link Aggregation”). LACP packets are
exchanged between switches over EtherChannel capable ports.
The standard applies to 10M, 100M and 1,000M bit/sec Ethernet. Aggregated links
can use a combination of these speeds on a single logical link. This increases the
options available when you have one remaining gigabit port and three or four 100M
bit/sec ports available between switches. You can add link bandwidth incrementally
and affordably. Network traffic is dynamically distributed across ports, so
administration of what data actually flows across a given port is taken care of
automatically within the aggregated link.
The link aggregation standard provides inherent, automatic redundancy on point-to-
point links. In other words, should one of the multiple ports used in a link fail, network
traffic is dynamically redirected to flow across the remaining good ports in the link. The
redirection is fast and triggered when a switch learns that a media access control
address has been automatically reassigned from one link port to another in the same
link. The switch then sends the data to the new port location, and the network
continues to operate with virtually no interruption.
Link Aggregation or trunking is a method of combining physical network links into a
single logical link for increased bandwidth. With Link aggregation we are able to
increase the capacity and availability of the communications channel between devices
(both switches and end stations) using existing Fast Ethernet and Gigabit Ethernet
technology. Two or more Gigabit Ethernet connections are combined in order to
increase the bandwidth capability and to create resilient and redundant links. A set of
multiple parallel physical links between two devices is grouped together to form a
single logical link.
Link Aggregation also provides load balancing where the processing and
communications activity is distributed across several links in a trunk so that no single
link is overwhelmed.

© EUROCAE, 2009
 47

By taking multiple LAN connections and treating them as a unified, aggregated link,
we can achieve practical benefits in many applications.
Link Aggregation provides the following important benefits:
• Higher link availability. Link aggregation prevents the failure of any single
component link from leading to a disruption of the communications between the
interconnected devices. The loss of a link within an aggregation reduces the
available capacity but the connection is maintained and the data flow is not
interrupted.
• Increased link capacity. The performance is improved because the capacity of
an aggregated link is higher than each individual link alone. Standard LAN
technology provides data rates of 10 Mb/s, 100 Mb/s, and 1000 Mb/s. Link
Aggregation can fill the gaps of these available data rates when an intermediate
performance level is more appropriate; a factor of 10 increase may be overkill in
some environments.
• Improvements are obtained using existing hardware.
There are a number of situations where Link Aggregation is commonly deployed:
• Switch-to-switch connections
• Switch-to-station (server or router) connections
• Station-to-station connections

FIGURE 20 : LINK AGGREGATION CONTROL PROTOCOL

3.3.5.1.5 Uni-Directional Link Detection (UDLD)

A working document containing the specification of UDLD protocol was submitted to

the IETF RFC Repository on August 2005 as an Internet-Draft.
Today's Ethernet-based switched networks often rely on the Spanning Tree Protocol
(STP) to create a loop-free topology that is used to forward the traffic from a source to
a destination based on the Layer 2 packet information learned by the switches and on
the knowledge of the status of the physical links along the path.

© EUROCAE, 2009
 48

Issues arise when due to mis-wirings or to hardware faults the communication path
behaves abnormally and generates forwarding anomalies. The simplest example of
such anomalies is the case of a bidirectional link that stops passing traffic in one
direction and therefore breaks one of the most basic assumptions most high-level
protocols depend upon: reliable two-way communication between peers.
The purpose of the UDLD protocol is to detect the presence of anomalous conditions
in the Layer 2 communication channel, while relying on the mechanisms defined by
the IEEE in the 802.3 standard to properly handle conditions inherent to the physical
layer.
The UDLD protocol allows devices connected through fiber-optic or copper Ethernet
cables (for example, Category 5 cabling) to monitor the physical configuration of the
cables and detect when a unidirectional link exists. When a unidirectional link is
detected, UDLD shuts down the affected port and alerts the user. Unidirectional links
can cause a variety of problems, including spanning-tree topology loops.
UDLD is a Layer 2 protocol that works with Layer 1 mechanisms such as
autonegotiation to determine the physical status of a link. At Layer 1, autonegotiation
handles physical signaling and fault detection. UDLD also performs tasks that
autonegotiation cannot perform such as detecting the identities of neighbors and
shutting down misconnected ports. When both autonegotiation and UDLD are
enabled, Layer 1 and Layer 2 detection features can work together to prevent physical
and logical unidirectional connections and malfunctioning of other protocols.

FIGURE 21 : UNI-DIRECTIONAL LINK DETECTION

A unidirectional link occurs whenever traffic transmitted by the local device over a link
is received by the neighbor but traffic transmitted from the neighbor is not received by
the local device. For example, if one of the fiber strands in a pair is disconnected, as
long as autonegotiation is active the link does not stay up. In this situation, the logical
link is undetermined, and UDLD does not take any actions. If both fibers are working
normally at Layer 1, then UDLD at Layer 2 determines whether those fibers are
connected correctly and whether traffic is flowing bidirectionally between the correct
neighbors. This check cannot be performed by autonegotiation, because
autonegotiation is a Layer 1 feature.
The switch periodically transmits UDLD messages (packets) to neighbor devices on
ports with UDLD enabled. If the messages are echoed back to the sender within a
specific time frame and they are lacking a specific acknowledgment (echo), the link is
flagged as unidirectional and the port is shut down. Devices on both ends of the link
must support UDLD in order for the protocol to successfully identify and disable
unidirectional links.

© EUROCAE, 2009
 49

3.3.5.2 Distribution Layer – Layer 3 Redundancy

3.3.5.2.1 Virtual Router Redundancy Protocol (VRRP)

There are a number of methods that an end-host can use to determine its first hop
router towards a particular IP destination. These include running (or snooping) a
dynamic routing protocol such as Routing Information Protocol or OSPF version 2,
running an ICMP router discovery client or using a statically configured default route.
Running a dynamic routing protocol on every end-host may be infeasible for a number
of reasons, including administrative overhead, processing overhead, security issues,
or lack of a protocol implementation for some platforms. Neighbor or router discovery
protocols may require active participation by all hosts on a network, leading to large
timer values to reduce protocol overhead in the face of large numbers of hosts. This
can result in a significant delay in the detection of a lost (i.e., dead) neighbor, that may
introduce unacceptably long "black hole" periods.
The Virtual Router Redundancy Protocol (VRRP), specified by IETF RFC 3768 is
designed to eliminate the single point of failure inherent in the static default routed
environment. VRRP specifies an election protocol that dynamically assigns
responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP
router controlling the IP address(es) associated with a virtual router is called the
Master, and forwards packets sent to these IP addresses. The election process
provides dynamic fail-over in the forwarding responsibility should the Master become
unavailable. Any of the virtual router's IP addresses on a LAN can then be used as the
default first hop router by end-hosts. The advantage gained from using VRRP is a
higher availability default path without requiring configuration of dynamic routing or
router discovery protocols on every end-host.
VRRP provides a function similar to the proprietary protocol "Hot Standby Router
Protocol (HSRP)" [HSRP].
The VRRP protocol design provides rapid transition from Backup Router to Master
Router to minimize service interruption, and incorporates optimizations that reduce
protocol complexity while guaranteeing controlled Master transition for typical
operational scenarios. The optimizations result in an election protocol with minimal
runtime state requirements, minimal active protocol states, and a single message type
and sender. The typical operational scenarios are defined to be two redundant routers
and/or distinct path preferences among each router. These are likely to cover the vast
majority of deployments, loss of the Master router is infrequent, and the expected
duration in Master election convergence is quite small ( << 1 second ). Thus the
VRRP optimizations represent significant simplifications in the protocol design while
incurring an insignificant probability of brief network degradation.
The enhanced VRRP hello-timers with sub-second failover are guaranteed in the
access network. When the network is properly configured, Layer 3 failures cause
outages that last less than 1 second. A working document was submitted to the IETF
RFC Repository, as an Internet-Draft, regarding these features.
There is also work in progress for the specification of VRRP for IPv6 (Internet-Draft).

3.3.6 High Availability in IP Routing

The main problem with very fast times in recovering after a network failure
(communication links, network elements/equipments and services), is that the
scalability of the network and speed of recovering/convergence are contradictory
goals. The faster a network converges, the less stable it is likely to be; fast reactions
to changes in the network topology tend to create positive feedback loops that result in
a network that simply will not converge.
Recent technologies and experience have shown, despite of this contradiction, that
such a goal: sub-second convergence of a network, is possible and feasible.

© EUROCAE, 2009
 50

Analysing the problem of high availability and rapid convergence in IP-routed networks
we could and should split it into some different areas:
• physical layer – the time of detecting a failure of a link, and how fast can it be.
This depends on the speed with which a device on the network can detect and
react to a failure of one of its own components, or the failure of a component in
a routing protocol peer.
• Information dissemination/propagation: the speed with which the failure in
the previous stage can be communicated to other devices in the network
• routing protocol convergence – the time in which a network reacts to
topology changes, and how fast can it be. This rely on the speed with which all
devices on the network—having been notified of the failure—can calculate an
alternate path through which data can flow
• data forwarding – how fast the data begins to be correctly forwarded around
network failures, by the forwarding engines in the routers, after the routing
protocol has determined the new paths in the network
In other words, the network convergence involves usually at least the following steps:
• Detection of the occurred event
• Propagate the event
• Process the event
• Update related forwarding structures
An improvement in any one of these stages provides an improvement in overall
convergence.

3.3.6.1 Routing protocols convergence

Each routing protocol has a different method of updating the routing table, affecting
the time to converge the routing tables. In the following we examine the technology for
fast downlink detection and routing protocols convergence for interior gateway
protocols (EIGRP - Enhanced Interior GatewayRouting Protocol , IS-IS - Intermediate
System-to-Intermediate System and OSPF – Open Shortest Path First).

3.3.6.1.1 OSPF Convergence

The steps for OSPF convergence are as follows:

(1) When a router detects a link failure, the router sends an LSA to its neighbors. If
the router is on a multiaccess link, it sends the update to the designated router
(DR) and the backup designated router (BDR), not to all neighbors.
(2) The path is removed from the originating router’s tables.
(3) On receipt of the LSA, all routers update the topology table and flood the LSA
out its interfaces.
(4) The routing protocol runs the Dijkstra algorithm to rebuild the routing table.
For OSPF, convergence is detection time, plus LSA flooding, plus 5 seconds before
computing the topology table. This amounts to a few seconds. We should add that
these calculations are made based on the assumption that the default routing timers
are configured. These timers (LSA flooding timer, SPF calculation delay timer) are
usually adjustable and an appropriate configuration of them, together with an
appropriate design can lead to subsecond convergence times.

© EUROCAE, 2009
 51

3.3.6.1.2 IS-IS Convergence

The steps for IS-IS convergence are as follows:

(1) When a router detects a link failure, an LSP is sent to its neighbors. If the router
is on a multiaccess link, the update is sent to the designated intermediate
system (DIS the IS-IS term for a designated router), not to all neighbors.
(2) The path is removed from the originating router’s tables.
(3) On receipt of the LSP, all routers update the topology table and flood the LSP
out its interfaces, except for the interface that received the LSP.
(4) Each router runs the Dijkstra algorithm to rebuild the forwarding table.
For IS-IS, convergence is detection time, plus LSP flooding. The time to converge the
network amounts to a few seconds. If convergence is deemed to be the topology table
being updated, this could take longer. Again, these calculations are made based on
the assumption that the default routing timers are configured. These timers (LSA
flooding timer, SPF calculation delay timer) are usually adjustable and an appropriate
configuration of them, together with an appropriate design can lead to subsecond
convergence times.

3.3.6.1.3 BGP Convergence

BGP convergence is different, depending on whether IBGP or EBGP is being run.

Reliability is far more important to EBGP than how long it takes to update the routing
table, whereas IBGP needs to ensure a faster convergence to remain synchronized
with the interior routing protocol.
When a neighbor is no longer available, the BGP router tries to reconnect to its
neighbor. If this fails, the session is formally closed and the information from the router
is removed from the database. An update is sent to all neighbors.

3.3.6.1.4 Failure/event detection

When we have some methods in place to prevent a network meltdown when events
occur, we can consider ways to discover events faster.
There are two ways to detect a down neighbor or link: polling and event driven.
The method commonly used for detecting a link or adjacency failure is polling, or
periodically sending Hello packets to the adjacent device, and expecting a periodic
Hello packet in return. The speed at which Hello packets are transmitted and the
number of Hello packets missed before declaring a link or adjacency as failed are the
two determining factors in the speed at which polling can discover a failed link or
device.
Normally, a neighbor or link is declared down if three Hello packets are lost, meaning
that the hold time, or the dead time, will always be about three times the Hello time, or
polling interval. Normally, for Layer 2 links and routing protocols, the Hello interval is
measured in seconds.
For instance:
• EIGRP running over a point-to-point link sends one Hello every 5 seconds, and
declares a neighbor down if no Hellos are heard for 15 seconds.
• EIGRP running over a lower-speed point-to-multipoint link sends one Hello
every 60 seconds, and declares a neighbor down if no Hellos are received in
180 seconds.
• OSPF normally sends a Hello every 10 seconds, and declares a neighbor down
if no Hellos are heard for 40 seconds.

© EUROCAE, 2009
 52

• Frame Relay Local Management Interface (LMI) messages, the equivalent of a

Hello, are transmitted every 10 seconds. If an LMI is not received in 30
seconds, the circuit is assumed to have failed.
• High-Level Data Link Control (HDLC) keepalive messages are transmitted
every 10 seconds. If a keepalive message is not received within 30 seconds,
the circuit is assumed to have failed.
In the last years the requirements of data and voice over data communications forced
the main vendors of network equipments to implement features like sub-second hellos
(which was impossible few years ago, the minimum interval between hellos being 1
second). Sending hello packets at hundreds of miliseconds intervals, will speed up the
process of event detection, and further, the process of convergence.
Fast Hellos can decrease these timers to Hello intervals on the order of 300
milliseconds, and dead timers of around 1 second.
Each routing protocol has a different limit on how Fast Hellos can be transmitted and
how often they must be received for a neighbor to be considered alive. OSPF and IS-
IS have both implemented the fastest Hellos, with a minimum of 330 millisecond
Hellos, and a dead interval of 1 second.
EIGRP can run with Hellos as fast as one per second, with a 3-second dead time.
BGP can use similar timers, with a keepalive interval of 1 second.
Caution should be used when configuring Fast Hellos on a network. Congestion, high
processor use, and other problems can cause false down indications that may cause
higher rates of network failure than would normally occur.
For instance, if a router has 1000 neighbors and is using a Hello interval of 330
milliseconds, the router has to be able to receive and process 3000 Hellos per second
and send 1000 Hellos per second.
Timers in this range leave little room for processes that consume a router processor
for long periods of time, short-term packet loss on a link due to congestion, and other
factors.
Rather than polling at a fast interval, event-driven notifications rely on devices within
the network that can sense the state of a link through lower layers (electrical,
electronic, or optical state) to notify the routers attached to the link when the link has
failed. SONET links are probably the best example of media with built-in capabilities
for sensing link failures and notifying attached devices. There are also techniques that
can be used to speed up the reporting of failed links in Frame Relay circuits, and
techniques are being developed for allowing switches to notify devices attached to an
Ethernet VLAN about a loss of connection to an attached device.
The first of these stages—failure/event detection—can be the most problematic and
inconsistent.
• Different routing protocols use varying methods and timers to detect the loss of
a routing adjacency with a peer
• Link-layer failure detection times can vary widely depending on the physical
media and the Layer 2 encapsulation used
• Intervening devices (eg: Ethernet switch) can hide link-layer failures from
routing protocol peers
Packet over SONET (POS) tends to have the best failure detection time amongst the
different Layer 1/2 media choices. It can typically detect and react to media or protocol
failures in ~50 milliseconds. This has become the benchmark against which other
protocols are measured.

© EUROCAE, 2009
 53

The event/failure detection is now typically accomplished via hardware detection

mechanisms. However, the signals from these mechanisms are not always conveyed
directly to the upper protocol layers. When the hardware mechanisms do not exist (eg:
Ethernet) or when the signaling does not reach the upper protocol layers, the
protocols must rely on their much slower strategies to detect failures. The detection
times in existing protocols are typically greater than one second, and sometimes much
longer. For some applications, like VoIP, this is too long to be useful.
Bi-directional Forwarding Detection (BFD) provides rapid failure detection times
between forwarding engines, while maintaining low overhead. It also provides a single,
standardized method of link/device/protocol failure detection at any protocol layer and
over any media. BFD can provide fast failure detection times for all media types,
encapsulations, topologies, and routing protocols. In the best-case scenario, it can
provide fast failure detection similar to that found in POS (in about 50 ms).
A secondary benefit of BFD, in addition to fast failure detection, is that it provides
network administrators with a consistent method of detecting failures. Thus, one
availability methodology could be used, irrespective of the Interior Gateway Protocol
(IGP) or the topology of the target network. This eases network profiling and planning,
because reconvergence time should be consistent and predictable.
Bidirectional Forwarding Detection provides a method for network administrators to
configure sub-second Layer 2 failure detection between adjacent network nodes.
Furthermore, the routing protocols can be configured to respond to BFD notifications,
and begin Layer 3 route convergence almost immediately.

3.3.6.1.5 Propagate and process the event, update forwarding structures

The caveat is that speeding up too much the event detection, we could go into
instability. As mentioned above, even desired, a routing protocol configured to react
very quickly to changes in network topology tends to develop positive feedback loops,
which result in a network that will not converge at all. This is the main issue, for
instance, in the case of flapping interfaces/links, which cause network adjacencies
between neighbouring routers to be formed and tear down at such a speed that the
routers can build a consistent routing table for few seconds only, and they cannot use
it for data forwarding actually. This is an example of how reacting too fast to topology
changes can negatively impact the network and conduct to a network meltdown.
In order to prevent this kind of problems to appear and negatively impact the stability
of the networks, technology does offer some methods:
• Not reporting all interface transitions from the physical layer up to the routing
protocol. This is called debouncing the interface; most interface types wait
some number of milliseconds before reporting a change in the interface state
• Slow neighbor down timers. For instance, the amount of time a router waits
without hearing from a given neighbor before declaring that a neighbor has
failed is generally on the order of tens of seconds in most routing protocols,
going down to 1 second at the time of this writing. The dead timer does not
impact down neighbor detection on point-to-point links, because when the
interface fails, the neighbor is assumed to be down, but there are other “slow-
down” timers here, as well.
• Slow down the distribution of information about topology changes.
• Slow down the time within which the routing protocol reacts to
information about topology changes.

© EUROCAE, 2009
 54

The above mentioned methods are typically used in routing protocols design and
implementation to provide stability within a IGP routing system. For instance:
• In IS-IS, a timer regulates how often an intermediate system (router) may
originate new routing information, and how often a router may run the shortest
path first (SPF) algorithm used to calculate the best paths through the network.
• In OSPF, similar timers regulate the rate at which topology information can be
transmitted, and how often the shorter path first algorithm, which calculates the
new topology tree, may be run.
• In EIGRP, the simple rule: “no route may be advertised until it is installed in the
local routing table” dampens the speed at which routing information is
propagated through the network, and routing information is also paced when
being transmitted through the network based on the bandwidth between two
routers.
Also we would mention some other technologies which, properly implemented,
depending on the topology of the network, could speed-up the convergence of the
network. These technologies are related to link-state protocols like OSPF and IS-IS,
and are based on the fact that the routers do not need to rebuild the entire Shortes
Path First tree in some cases, in which an event in the network does not affect some
portions of it. These technologies are called Incremental SPF and they provide an
improved SPF algorithm for calculating the new topology. Incremental SPF computes
only the steps needed to apply the changes in the network topology diagram. That
process requires that the system keep more information about the topology in order to
apply the incremental changes. Also, more processing must be done on each node
for which the system receives a new LSP. However, incremental SPF typically
reduces demand on CPU.

3.3.6.1.6 Network Stability Protection

Few steps can be used to protect the network stability in terms of avoiding the
propagation of inconsistent events. Off course, the best report between stability and
convergence should be found and this would depend a lot on the network topology,
network size etc.
If it is necessary to slow down the reporting of events when they occur more frequently
(or when they occur rapidly), and/or speed up the reporting of events when they occur
less frequently (or when they occur slowly), this is possible through a series of
features built into router’s software within the last year or two, applying the concept of
the exponential timers. An exponential timer changes the amount of delay between an
event occurring and the reporting of that event by the frequency at which the event
occurs, possibly not reporting the event at all, in some situations. Two
implementations of exponential timers are exponential backoffs and dampening.
• Exponential backoff is applied to timers used by the routing protocols in
propagating events
• Dampening is applied to events that have a boolean component; a route that is
either advertised or withdrawn, an interface that is either up or down, etc.
Exponential backoff simply deals with events in general, whereas dampening adds
value based on the type of event, as well as the frequency at which the event occurs.
So, dampening reacts to events by simply not reporting events if they occur too
frequently, whereas exponential backoff reacts to events by reporting each event that
occurs, but slowing down the reporting of events as they occur more frequently.
Dampening is currently implemented in two places:
• Border Gateway Protocol (BGP) route flap dampening
• Interface dampening

© EUROCAE, 2009
 55

BGP route flap dampening is a well-known technology, deployed in the Internet on a

wide scale to increase the stability of the Internet routing table.
Interface dampening allows the network engineer to prevent rapidly flapping interfaces
from having a wide-ranging impact on the entire network. When an interface fails and
comes back up numerous times within a short time period, the interface is placed in
the down state from an IP perspective, and not advertised within routing protocols, or
used for forwarding packets.
It is important to note that the interface is allowed to change states freely at Layer 2;
an interface that continues to change state rapidly continues to accumulate penalties,
and continues to show down to the IP subsystem.
Exponential backoff is implemented in several places in link state protocols at this
point, including:
• The ability to exponentially back off the amount of time between a change in the
network topology being detected and the transmission of a link state packet
being transmitted to report the change; exponential backoff has been applied to
the link state generation timer.
• The ability to exponentially back off the amount of time between receiving a link
state packet reporting a change in the network topology, and running SPF to
recalculate the path to each reachable destination in the network; exponential
backoff has been applied to the SPF timer.
The two options we want to examine, then, are not reporting every event, and slowing
down as the network speeds up. First we will discuss these two options, and then
discuss speeding up the reporting of network events, which plays a large role in
decreasing convergence times.

3.3.6.2 Non-stop Forwarding and Graceful Restart

It sounds simple just to say that a router should not report every event within the
network it is aware of, but it becomes more complicated as we consider the issues
involved. What we need to do is sort out which events are important, in some sense,
and which are not. For instance, if a router loses contact with an adjacent router
because the adjacent router restarted for some reason, do not report the resulting
change in topology until you are certain the neighbor is not coming back.
The problem is how long to wait before deciding the problem is real, and what
happens to traffic you would normally forward to that neighbor while you are waiting.
Finally, how to reconnect in a way that allows the network to continue operating
correctly.
A technology recently incorporated in routing protocols called Graceful Restart (GR),
combined with another technology called Non-Stop Forwarding (NSF), can combine to
answer these questions.
In some high-end routers, the actual switching, or forwarding, of packets is performed
by different processors and physical circuitry than the control plane processes run on
(such as routing protocol processes, routing table calculation, and other processes).
Therefore, if the control plane fails or restarts for any reason, the data plane could
continue forwarding traffic based on the last known good information.
Non-stop Forwarding allows this continuous forwarding, regardless of the state of the
control plane, to take place. Normally, when the control plane resets, it sends a signal
to the data plane that it should clear its tables out, and reset, as well. With NSF
enabled, this signal from the control plane simply acts as a signal to mark the current
data as stale, and to begin aging the information out.

© EUROCAE, 2009
 56

3.3.6.2.1 Deploying Fast Convergence Technologies and Graceful Restart

We now have a full range of options we can use to improve network availability,
including GR and NSF, event dampening, and fast convergence techniques. When
speaking about the deployment, generally, the technologies can be placed in one of
three categories:
• Fast reaction to node or link failure, to route around the failure. We use Layer 2
techniques and Fast Hellos to quickly determine when an adjacent node, or a
link to that node, has failed.
• Slow reaction to node of link failure, combined with routing through the failure.
We rely on moderate speed reactions to node failures to allow
resynchronization of routing data while forwarding of traffic continues.
• Fast recalculation of the best path when a topology change has been reported.
As we can see, the first two are complementary; we could not deploy both of them in
the same place in the network. The third one, fast recalculation, can be deployed with
either (or both) fast reaction and slow reaction techniques to increase network
availability. The primary question then becomes: which of these two techniques do
you deploy in your network, and where?
The basic premise behind making this design decision follows:
• If there is a fast, online backup available to a node or a link, it probably makes
more sense to route around any problems that occur as rapidly as possible.
• If any existing backup is going to take a good deal of time to bring online, or
there is no backup path (such as a single homed remote office, or a remote
office with dial backup), it probably makes more sense to route through any
problems.
In general, then, we want to deploy techniques that improve network convergence
time everywhere—techniques that bring down the time a network is down when a
failure occurs, is detected, and a new path calculated.
At the same time, we want to evaluate each point in the network we would like to
protect from failure, and determine the best means to protect that point of failure:
redundancy with fast down detection, GR, or NSF.

3.3.6.3 IGP Routing Protocol Convergence Sample

We use the following network architecture to make some considerations about IGP
routing protocols convergence in terms of convergence time.
When trying to answer to the question which protocol is better, the first thing is to
clarify what better means. Some protocols are easier to configure and manage, others
are easier to troubleshoot, some are more flexible, and so on.
This sample examines convergence time. We could choose any number of other
measures, including ease of management, ease of configuration, on-the-wire
efficiency etc.
The average uptime (or reliability) of a network is affected by two elements: how often
does the network fail and how long does it take to recover from a failure.
The network design and your choice of right equipment in the right place answers to
the first issue.
The second issue, how fast the network is recovering from failures is also very
important, mainly when speaking about critical systems like in ATC.

© EUROCAE, 2009
 57

All the routing protocols can converge quickly or slowly, depending on a lot of factors
strictly related to network design, without even considering the hardware, types of
links, and other random factors that play into convergence speed in different ways with
each protocol. As a specific example, considering the network above, we would try to
consider the various factors that might influence the convergence speed in this
network.

FIGURE 22 : IGP ROUTING PROTOCOL EXAMPLE

Figure 22 purposefully has no labels showing anything concerning routing protocols
configuration or design; instead, this section covers several possible routing
configurations and examines how the same protocol could converge more or less
quickly even on a network this small through just minor configuration changes.
Case 1) EIGRP as routing protocol with the bandwiths:
• The Router RTRA to RTRC link has a bandwidth of 64 kbps
• The Router RTRA to RTRB link has a bandwidth of 10 Mbps
• The Router RTRB to RTRD and Router RTRC to RTRD links have equal
bandwidths.
According to the EIGRP algorithm, router RTRD will learn the network
192.168.100.0/24 through Router B as the best path (the successor in EIGRP terms).
The path through Router RTRC will not be marked as a feasible successor, because
the differential in the metrics is too great between the two paths (link bandwidth is one
of the attributes of the route metric in EIGRP). To the EIGRP process running on
Router RTRD, the path through Router RTRC cannot be proven based on the metrics
advertised by Routers RTRB and RTRC, so the path through Router RTRC will not be
installed as a possible backup route.
This means that if the link between Router RTRB to RTRD fails, RTRD is forced to
mark 192.168.100.0/24 as active (a kind of unknown) and send a query to RTRC to
ask for an alternative path to this network. The convergence time is the sum of the
folowing:
• RTRD to examine its local topology table and determine that no other known
loop-free paths exist.
• RTRD to build and transmit a query to RTRC.
• RTRC to receive and process the query, including examining its local EIGRP
topology table, and find it still has an alternate path.
• RTRC to build a reply to the query and transmit it.
• RTRD to receive the reply and process it, including route installation time and
the time required to change the information in the forwarding tables on the
router.

© EUROCAE, 2009
 58

Many factors are contained in these steps; any one of them could take a long time. In
the real world, the total time to complete the steps in this network is less than 2(two)
or 3(three) seconds.
Case 2) EIGRP as routing protocol with the bandwidths:
• The Router RTRA to RTRC link and RTRA to RTRB links have equal
bandwidth.
• The Router RTRB to RTRD link has a bandwidth of 64 kbps.
• The Router RTRB to RTRD link has a bandwidth of 10 Mbps.
Again, according to the EIGRP algorithm, with the network conditions have been
changed only slightly, the results are altered dramatically. In this case, the path to
192.168.100.0/24 through Router RTRC is chosen as the best path. EIGRP then
examines the path through Router RTRB and finds that it is a loop-free path, based on
the information embedded in EIGRP metrics. What happens if the Router RTRC to
RTRD link fails?
The process has exactly one step: Router RTRD examines its local EIGRP topology
table and finds that an alternate loop-free path is available. Router RTRD installs this
alternate route in the local routing table and alters the forwarding information as
needed. This processing takes on the order of 150 milliseconds or less.
Case 3) OSPF as routing protocol
OSPF and IS-IS have similar convergence characteristics, so this example will treat
only OSPF. Using the same network, we examine the various reactions of OSPF to
link failures.
• The Router RTRB to RTRD link has a cost of 20
• All other links in the network have a cost of 10
• All routes are internal OSPF routes.
What happens if the Router RTRB to RTRD link fails?
Router RTRB and RTRD detect the link failure and wait some period of time, called
the link-state advertisement (LSA) generation time. Then they flood modified router
LSAs with this information.
The remaining routers in the network receive this new LSA and place it in their local
link-state databases. The routers wait some period of time, called the shortest path
first (SPF) wait time, and then run SPF.
In the process of running SPF, or after SPF has finished running (depending on the
implementation), OSPF will install new routing information in the routing table.
With the default timers, it could take up to one second (or longer, in some situations)
to detect the link failure and then about three and a half seconds to flood the new
information. Finally, it could take up to two and a half seconds before the receiving
routers will run SPF and install the new routing information. With faster times and
various sorts of tuning, you can decrease these numbers to about one second or
even in the 300-millisecond range in some specific deployments.
Making Router RTRD an area border router (ABR) dramatically impacts the
convergence time from the Router RTRE perspective because Router RTRD has to
perform all the preceding steps to start convergence. After Router RTRD has
calculated the new correct routing information, it must generate and flood a new
summary LSA to Router RTRE, and Router RTRE has to recalculate SPF and install
new routes.
Redistributing 192.168.100.0/24 into the network and making the area that contains
Routers RTRA, RTRB, RTRC, and RTRD into a not-so-stubby area (NSSA) throws
another set of timers into the problem. Router RTRD now has to translate the Type 7
external LSA into an external Type 5 LSA before it can flood the new routing
information to Router RTRE.

© EUROCAE, 2009
 59

These conditions do not even include the impact of multiple routes on the
convergence process. EIGRP, for instance, can switch from its best path to a known
loop-free path for 10,000 routes just about as fast as it can switch 1 route under
similar conditions. OSPF performance is adversely impacted by the addition of 10,000
routes into the network, possibly doubling convergence time.
As it can be seen, it is not so simple to say, "EIGRP will always converge faster than
OSPF," "IS-IS will always converge faster than EIGRP," or any other combination you
can find. Some people say that OSPF always converges faster than EIGRP, for
instance, but they are generally considering only intrarea convergence and not the
impact of interarea operations, the impact of various timers, the complexity of the SPF
tree, and other factors. Some people say that EIGRP always converges faster than
any link-state protocol, but that depends on the number of routers involved in the
convergence event. The shorter the query path, the faster the network converges.
If you align all the protocol convergence times based on the preceding examination,
you generally find the convergence times in this order, from shortest to longest:
1) EIGRP with feasible successors
2) Intrarea OSPF or IS-IS with fast or tuned timers
3a) EIGRP without feasible successors
3b) Intrarea OSPF or IS-IS with standard timers
3c) Interarea OSPF or IS-IS
The last three are highly variable, in reality. In any particular network, OSPF, IS-IS,
and EIGRP without feasible successors might swap positions on the list. The network
design, configuration, and a multitude of other factors impact the convergence time
more than the routing protocol does. You get the best convergence time out of a
routing protocol if you play the network design to the strengths of the protocol.

3.4 CONCLUSION AND RECOMMENDATION

Fast, stable networks are possible with today’s techniques in routing; some large
networks, with several hundred routers, measure their convergence times in the
milliseconds, with 1 second as their outside convergence goal.
With the appropriate network design, the IP infrastructure for VoIP applications in
ATM, can meet the requirements imposed by the operational specifications in terms of
speed, reliability, redundancy and availability.
However, it is highly recommended developing trials in which equipments and
technologies could demonstrate the facts.

© EUROCAE, 2009
 60

CHAPTER III REFERENCES

1. The Internet Protocol Journal, Volume 7, Issue 1, Cisco Systems, March 2004.
2. High Availability in IP Routing, Micah Bartel, Cisco Networkers Presentations,
2004.
3. Juniper VoIP Solutions, White Paper, Sean Christensen, June 2001.
4. IETF RFC 2328: OSPF v2, April 1998.
5. IETF RFC 3623: Graceful OSPF Restart. J. Moy, P. Pillay-Esnault, A. Lindem,
November 2003.
6. IETF RFC 1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li.,
March 1995.
7. IETF RFC 2439: BGP Route Flap Damping. C. Villamizar, R. Chandra, R.
Govindan, November 1998.
8. IETF RFC 3847: Restart Signaling for Intermediate System to Intermediate
System (IS-IS). M. Shand, L. Ginsberg. July 2004.
9. IETF: Bidirectional Forwarding Detection, draft-ietf-bfd-base-03.txt,
http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-03.txt.
10. UniDirectional Link Detection (UDLD) Protocol, draft-foschiano-udld-00.txt,
http://www.ietf.org/internet-drafts/draft-foschiano-udld-00.txt.
11. Virtual Router Redundancy Protocol (VRRP),
http://www.ietf.org/rfc/rfc3768.txt.
12. Timer Enhancements to Reduce Failover Times for the Virtual Router
Redundancy Protocol for IPv4,
http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv4-timers-00.txt.
13. Hinden, R., "Virtual Router Redundancy Protocol for IPv6", draft-ietf-vrrp-ipv6-
spec-07 (work in progress), September 2004,
http://www.ietf.org/internet-drafts/draft-ietf-vrrp-ipv6-spec-07.txt.
14. Split Multi-link Trunking (SMLT),
http://www.ietf.org/internet-drafts/draft-lapuh-network-smlt-05.txt.
15. Cisco Systems web site:
www.cisco.com.
16. Juniper Networks web site:
www.juniper.net.

© EUROCAE, 2009
 61

CHAPTER IV

QUALITY AND PERFORMANCE

4.1 BANDWIDTH AND PERFORMANCE

Telephone users are accustomed to the voice quality provided by the PSTN and
private PBX-based networks. These connection-oriented, circuit-switched networks
provide each user with dedicated bandwidth for the duration of the call. The result is a
high quality communication, with extremely low latency and jitter, and minimal
disruption due to noise on the connections.
When trying to implement VoIP systems, several difficulties to provide the same high
quality in voice communications usually appear, with regard to traditional systems.
The very first point to have into account is the bandwidth and afterwards there are
some parameters that have a significant influence in the performance, such as delay
or latency, jitter and packet loss.

4.1.1 Bandwidth

VoIP refers to the transmission of telephone conversations over a packet-switched IP

network. So, phone conversations are converted to a stream of IP packets and sent
over an Ethernet network.
Key aspects in VoIP systems to achieve the desired level of performance in the
communication between end-points are, on one hand the utilization of the required
bandwidth to support the entire conversation, and on the other hand, the utilisation of
different techniques to avoid the main troubles that appear in this type of networks:
jitter, packet delay and packet loss.
The design of the bandwidth may result a crucial design matter to consider, as well as
delay, jitter and packet loss are the major shortcomings that VoIP systems are going
to suffer from. A wide explanation of the previous concepts and several techniques to
improve its negative effects are exposed in this paper, so as to fulfil with the highest
requirements in VoIP systems.

4.1.1.1 Basic concepts

Bandwidth is the plain data transmission capacity of the network, and its design may
result of paramount importance in the system because an inadequate bandwidth may
cause delay and packet loss.
Bandwidth requirement may increase depending on the kind of codification or
compression performed. The following are some commonly ITU-T standards codecs
and the amount of one-way delay that they introduce:
- ITU-T G.711 [2] uncompressed 64 Kbps speech adds negligible delay.
- ITU-T G.729 [3] encodes speech at 8 Kbps and adds a one-way delay of about
25 ms.
- ITU-T G.723.1 [11] encodes speech at 6.4 Kbps or 5.3 Kbps and adds a one-
way delay of about 67.5 ms.

4.1.1.2 Calculating Bandwidth Demand

Depending on the type of voice- compression method used, each one-way VoIP
transmission requires up to 64 Kbps of bandwidth, as specified in G.711. Some
compression methods as G.729 may operate at 8 Kbps. As it can be seen the
bandwidth that is required for each VoIP session is relatively low. The goal to achieve
is to make the bandwidth available in spite of the network utilization.

© EUROCAE, 2009
 62

In order to calculate the bandwidth needed, it is very important to have into account
the IP protocol stack model. For VoIP telephony the following protocols are relevant:
RTP (Real Time Protocol), UDP (User-Datagram Protocol), IP (Internet Protocol) and
the Network Interface (e.g. Ethernet or Token Ring MAC – Media Access Control.
These four activities let to handle the MIBs throughout the SNMP protocol.
The bandwidth demand per call for a specific link is defined by the next formula, as it
can be seen in [4]:
Bw (b/s) = ( V + I + L) (B/pkt) * 8 (b/B)* P (pkt/s)
where,
• V is the voice payload for each packet, is a function of the code selected (G.711
is 64000 b/s; G.729 is 8000 b/s),
• I is the IP/UDP/RTP header overhead per packet, is a constant 40, unless RTp
header compression is enabled, and then the resulting overhead is vendor
specific.
• L is the link-layer overhead for the specific link type, and its value can be very
variable owing to there are optional fields and vendor specific capabilities.
• P is the number of packets or frames generated per second, expressed in
milliseconds – 10ms, 20 ms 30ms.
The results obtained for different compression techniques for one VoIP call is exposed
in Table 7.

Link Type G.711 (20ms) G.711 (30ms) G.729 (20ms) G.729 (30ms)
802.3 full duplex 190.4 169.6 78.4 57.6
802.3 half
95.2 84.8 39.2 28.8
duplex
PPP 83.2 76.8 27.2 20.8
TABLE 7 : BANDWIDTH DEMAND PER VOIP CALL (KBPS)

In this sense, the total Bandwidth demand for a specific call is defined by:
TBw = Bw (b/s) * N (calls),
where N is the number of active calls in the link. This result indicates the minimum
bandwidth needed per link to have the system working properly.
As it can be seen from the information exposed in the Table 1 the main goal achieved
by speech compression (e.g. G.729) is the reduction of bandwidth requirements end-
to-end. However, some other problems may appear. Packet loss has much more
serious consequences when high compression codecs are used because more data is
lost per packet. So, although G.711 has high bandwidth requirements, it is the most
widely codec used.
Some enhancements can be addressed regarding to G.711 by using Voice Activation
Detection (VAD). At one specific call, the media path is either active (100 percent
bandwidth demand) or is inactive (almost zero percent bandwidth demand). Besides,
there is another technique known as Comfort Noise Generator (CNG), that plays
background noise instead of no sound at all, which users find preferable to silence.
These bandwidth conservation techniques can provide about a 30-50 % bandwidth
savings in a 64 Kbps full duplex voice conversation.

4.1.1.3 Improving Bandwidth Design

One of the most recognized features from IP network traffic is its irregularity, so a
really significant manner to improve the bandwidth performance is the utilization of
some kind of prioritisation. The most known techniques used to prioritise packets are
described in section ‘Quality of Service QoS’ (4.3).

© EUROCAE, 2009
 63

4.1.2 Packet Loss

Since for IP networks the treatment for voice and data is the same, i.e., the network
just transmits packets, if there are frames hit by errors, corrupted during failures or
discarded by routers under congestion, these frames will be dropped.
When working with data packets, lost packets can be re-transmitted, but this solution
is not acceptable in case of transporting voice packets, which can contains up to 40 or
as many as 80 ms of speech information.
Even in case of using G.711, which is considered the most solid coder against packet
loss, if just an 1% of packet loss appears, this can result significantly annoying for the
user. Other coders cause more damaging effects, such as G.723 and G.729, because
they compress the signal more severely.

4.1.2.1 Reduce Packet Loss

There are two main algorithms used to compensate for packet loss at the endpoint:
Packet Loss Concealment (PLC) and Packet Loss Recovery (PLR). When using PLC
algorithm with G.711 up to a 5% rate of packet loss can be acceptable. Some speech
coders based on Codebook Excited Linear Prediction (CELP), such as G.723, G.728
and G.729 have PLC built-in.
One example of Packet Loss Concealment for use with G.711 may be found at ANSI
T1.521a-200 (Annex B) Standard for Packet Loss Concealment [8]. The PLC
technique described in this standard uses linear predictive model of speech production
to estimate the vocal tract and excitation information from the previously received
packets to reconstruct the signal contained in the missing packet; it works with packet
sizes of 5-30 ms. This standard uses an algorithm that estimates the spectral
characteristics of a missing speech segment and then synthesizes a high-quality
approximation of the missing segment using the LPC speech production model [13].
This algorithm is implemented entirely at the receiver side of the transmission channel.
A complete revision and study about Packet Loss Recovery Techniques is described
in [9]. These techniques may be divided into two types: sender and receiver-based.
The most known sender-based techniques are forward error correction (FEC) ,
interleaving and retransmission.
Packet loss may be reduced by means of Payload Redundancy (RFC 2198) [10], as
well, but it may result in an increasing bandwidth.

4.1.3 Header Compression

The headers of IP, UDP and RTP contribute 40 bytes in IPv4 and 60 bytes in IPv6 of
overhead to each packet. Several techniques have been developed to reduce these
three headers between 2 and 4 bytes, achieving a significant improvement into the
system bandwidth and performance.
Some of these techniques will be briefly explained in this section: CRTP (Compressed
Real - time Transport Protocol), Enhanced RTP (Enhanced Compressed Real - time
Transport Protocol) and ROHC (RObust Header Compression).

4.1.3.1 CRTP (Compressed Real - time Transport Protocol)

CRTP header compression, as described in RFC 2508 [13] was designed to reduce
the header overhead of IP/UDP/RTP datagrams by compressing the three headers to
2 bytes when no UDP checksums are being sent, or 4 bytes when cheksums are
used. At the beginning, this technique was thought to deal with slow-speed serial and
reliable links with low round trip time. In order to manage with other kind of links, with
packet loss or higher delay, extensions to this protocol have been produced, as it will
be exposed later in this paper.

© EUROCAE, 2009
 64

The IP/UDP/RTP compression scheme defined in [13] may be used with IPv4, IPv6 or
packets encapsulated with more than one IP header, and it is intended to fit with the
more general compression framework specified in RFC 2507, "Header Compression
for IPv6" [19].

4.1.3.1.1 Compression Algorithm

CRTP algorithm draws heavily upon TCP/IP header compression as described in RFC
1144 [15].
In TCP/IP header compression, the first point to have into account is that half of the
bytes of the header remain constant during connection. So, after sending the
uncompressed header once, some fields may be deleted from the compressed
headers that follow. The remaining comes from differential coding on the changing
fields to reduce their size.
For RTP header compression, the big gain comes from the observation that the
difference from packet to packet is often constant and therefore the second difference
is zero. The uncompressed header and the first order difference is kept in the session
state shared between compressor and decompressor, so, all that must be
communicated is an indication that that the second-order difference is zero. Therefore,
reconstruction may be performed by the decompressor only by adding the first order
difference to the uncompressed header.
As well as TCP/IP keeps shared state for multiple simultaneous TCP connections, the
IP/UDP/RTP compression must maintain state for multiple session contexts. A session
context is defined by the IP source and destination address, the UDP source and
destination ports and the RTP SSRC field, as defined in RFC 3550 [16].

4.1.3.1.2 The Protocol

As it was previously mentioned, the compression protocol must keep some shared
information between compressor and decompressor. There is a separate session
context for each IP/UDP/RTP stream RTP identified by a unique 8-bit or 16-bit
identifier, and the number of session contexts is negotiated between compressor and
decompressor.
Both compressed and uncompressed packets must carry the context identifier (CID)
and a 4-bit sequence number to detect packet loss between the compressor and
decompressor.
The shared information in each context consists of the following:
- Full IP, UDP and RTP headers
- The first-order difference for the IPv4 field
- The first-order difference for the RTP timestamp field
- The last value of the 4-bit sequence number
- The current generation number for non-differential coding of UDP packets with
IPv6.
- A context specific data encoding table may be optionally negotiated for each
context.
There are four new packet formats which are used in this protocol so as to
communicate packets in the various uncompressed and compressed form:
− FULL_HEADER - communicates the uncompressed IP header plus any
following headers and data to establish the uncompressed header state in the
decompressor for a particular context.
− COMPRESSED_UDP - communicates the IP and UDP headers compressed to
6 or fewer bytes (often 2 if UDP checksums are disabled), followed by any
subsequent headers (possibly RTP) in uncompressed form, plus data.

© EUROCAE, 2009
 65

− COMPRESSED_RTP - indicates that the RTP header is compressed along with

IP and UDP headers. This packet type is used when the second-order
difference is zero. It includes delta encodings for those fields that have changed
by other than the expected amount to establish the first order differences.
− CONTEXT STATE - indicates a special packet sent from the decompressor to
the compressor to communicate a list of context CIDs for which synchronisation
may have lost.
When this compression scheme is used with IPv6, another packet type may be used:
− COMPRESSED_NON_TCP - communicates the compressed IP and UDP
headers as without differential encoding.

4.1.3.1.3 Error Recovery

If the 4-bit sequence number for a particular context increments by other than 1
(except when set by a FULL_HEADER or COMPRESSED_NON_TCP packet), the
decompressor must invalidate the context and send a CONTEXT_STATE packet back
to the compressor indicating that the context has been invalidated.
The sequence for initialization and operation of header compression can be
appreciated in Figure 23 (obtained from "IPv6 Header Compression" [20]).

FIGURE 23 : INITIALIZATION AND OPERATION OF HEADER COMPRESSION PROTOCOLS

© EUROCAE, 2009
 66

4.1.3.2 Enhanced CRTP

CRTP was not designed to perform well on links with high delay, because packets are
discarded before context is repaired and with packet loss, due to the context
corruption, and the consequent reordering of packets. To correct the behaviour of
CRTP over such links, a few extensions to the protocol have been developed, as can
be seen in RFC 3545 [17].
These extensions are mainly based on reducing context corruption by changing the
way the compressor updates the context at the decompressor: updates are repeated
and the sending of absolute (uncompressed) values in addition to delta values for
selected context parameters is allowed.

4.1.3.2.1 Preventing Packet Loss

The main problem for the CRTP decompressor appears not when a packet is lost, but
when the next compressed packet arrives. If the next packet contains the same
context update as in the lost packet, the context at the decompressor may be correctly
updated. But, if the lost packet included an update to a delta field, the next packet will
not be able to compensate for the loss, since the update of a delta value is relative to
the previous packet which was lost.

4.1.3.2.2 Enhanced CRTP features

The main improvements that the Enhanced version of CRTP achieves are:
- The inclusion to extensions to the COMPRESSED_UDP packet to allow
updating the differential RTP values in the decompressor context and to
selectively update the absolute CID and the following RTP values: sequence
number, timestamp, payload type, CSRC count and CSRC list. This allows
context synchronisation to be maintained even with some packet loss.
- The use of "headers checksum" to be inserted by the compressor and removed
by the decompressor when the UDP checksum is not present so that validation
of the decompressed headers is still possible. This allows the decompressor to
verify that context synchronisation has not been lost after packet loss.
The utilisation of IP/UDP/RTP compression (CRTP) over a particular link is a function
of the link-layer protocol. It is expected that negotiation of the use of CRTP will be
defined separately for each link layer. For link layers which have previously defined a
negotiation for the use of "simple" CRTP, an extension to that negotiation will be
required to indicate the use of the Enhanced CRTP functionalities, since the syntax of
the existing packet formats has been extended.

4.1.3.3 ROHC (RObust Header Compression)

The major problem with CRTP and its enhanced versions is that it is not sufficiently
robust against packets being damaged between compressor and decompressor. In
that sense, new mechanisms have been developed to achieve the combination of
robustness against packet loss and maximal compression efficiency.
ROHC technique provides better performance than CRTP in high bit error rate (BER),
and high round-trip-time wireless links, as it is exposed in RFC 3095 [18]. This
improvement achieved by ROHC is based mainly on a more complex implementation
than CRTP protocol. A detailed description of the requirements specified for ROHC
may be found in RFC 3096 [19].

4.1.3.3.1 States Machine functioning

Header compression with ROHC can be characterized as an interaction between two

state machines, one compressor machine and one decompressor machine, each
initiated once per context. The compressor and the decompressor have three states
each and both machines start in the lowest compression state and transit gradually to
higher states.

© EUROCAE, 2009
 67

Transitions need not be synchronized between the two machines. In normal operation
it is only the compressor that temporarily transits back to lower states. The
decompressor will transit back only when context damage is detected.
For ROHC compression, the three compression states are the Initialization and
Refresh (IR), First Order (FO), and Second Order (SO) states. The compressor starts
in the lowest compression state (IR) and transits gradually to higher compression
rates. Decompressor states are No Context (NC), Static Context (SC) and Full
Context (FC), and gradually transits to higher states. All the details of state machines,
and a fully explanations of their concrete specifications states can be found in RFC
3095.

4.1.3.3.2 Modes of operation

The ROHC scheme has three modes of operation, called Unidirectional, Bidirectional
Optimistic, and Bidirectional Reliable mode. The state abstraction is the same for all
modes of operation, while the mode controls the logic of state transitions and what
actions to perform each state.
The optimal mode to operate in depends on the characteristics of the environment of
the compression protocol, such as feedback abilities, error probabilities and
distributions, effects of header size variation, etc. All ROHC implementations must
implement and support all three modes of operation. The three modes of operation are
completely described in RFC 3095.

4.1.3.3.3 ROHC improvements

ROHC incorporates enhanced mechanisms compared to CRTP header compression

technique. The two main goals achieved by this compression scheme are:
- Implementation flexibility - capability to compress headers with or without
feedback mechanism.
- Improved compression ratios and optimized encoding schemes (e.g., Window-
based Least Significant Bit (W-LSB).
To sum up, it may be affirmed that ROHC provides greater compression compared to
CRTP and Enhanced CRTP techniques, at the cost of greater implementation
complexity.

4.1.3.4 General header compression considerations

The incorporation of any kind of header compression between two nodes places
restrictions on underlying link layer:
- IPv6 payload length must be inferred from the underlying header.
- Decompressor must receive the packets in the same order that the compressor
sends them.
- Packets are not duplicated by the link layer between the compressor and
decompressor.
Header compression techniques require extra resources on nodes that implement the
compression algorithms, such as:
- Additional memory required on nodes for storage of context information.
- Additional processing required on nodes for compression and decompression of
packets.
Commercial applications of Header Compression techniques are not easy to find.
However, Cisco Systems router Internetwork Operating System (IOS) provides CRTP
implementation.

© EUROCAE, 2009
 68

4.1.4 Conclusions & Recommendations

VoIP networks must be able to support streaming of VoIP packets between the two
end-points for the duration of the phone conversation. VoIP traffic requires a network
to guarantee bandwidth and capacity for VoIP traffic.
To support VoIP traffic consistently and reliably, a network must be able to provide, in
the first place, a guaranteed network bandwidth and capacity for VoIP sessions during
periods of network congestion. In the second place, performance in VoIP is
determined mainly by three factors: jitter, packet delay and packet loss.
Packet delay or latency must not exceed the maximum tolerable level for a VoIP
conversation (150-200 ms). Jitter, which is the variation of latency over time, must be
below acceptable values, and the jitter buffer must be accurately designed with this
purpose. Packet loss is pretty harmful when transmitting voice, so it is necessary the
use of Packet Loss Concealment techniques and Packet Loss Recovery techniques,
such as sender-based and receiver-based techniques, to deal with it.
In order to improve the use of the bandwidth required to perform VoIP
communications, and more specifically when transmitting voice by means of the RTP
protocol, header compression techniques may be implemented, such as CRTP,
Enhanced CRTP and ROHC. By using IPv6, the IP/UDP/RTP header may be reduced
from 60 to 4 - 2 bytes. CRTP do not perform adequately on links with high delay and
packet loss. Nevertheless, Enhanced CRTP achieves best performance in this type of
environments with long delays and packet loss. Eventually, ROHC provides a highly
robust header compression scheme and better compression efficiency than CRTP
protocols, at the cost of greater implementation complexity.
General performance considerations of network elements
For the choice of appropriate equipment (routers, switches, …) the following issues
shall be investigated:
• How many packets can be handled?
• How many Digital Singnal Processors DSP’s (in case you do encoding in
network equipment) are necessary?
• How much bandwidth can be handled?

4.2 DELAY AND JITTER

Two of the major concerns in VoIP networks today are the problems experienced with
delay and jitter.
In the past up today, the PSTN has been delivering real−time voice across the
network with an average one-way-delay of 30 to 50 ms. The average delay on a
satellite−based network in geosynchronous orbit is approximated 250 ms.
In the VoIP delivery today, the average response and delay factors must be dealt with.
VoIP Performance is affected by
• Delay
• Jitter
• Packet Loss
• Bandwidth
When you design VoIP networks, it is important to understand and account for the
delay components. If you account correctly for all potential delays, it ensures that
overall network performance is acceptable. Overall voice quality is a function of many
factors that include the compression algorithm, errors and frame loss, echo
cancellation, and delay.
This section explains the sources of delays over packet networks. Voice traffic has
unique demands regarding these parameters which are discussed.

© EUROCAE, 2009
 69

4.2.1 Standards for Delay Limits

The effect of delay on voice transmission is discussed in ITU-T G.114 [5].

This ITU-T Recommendation provides specifications for transmission time, including
delay due to equipment processing time as well as propagation delay, in connections
with echo adequately controlled
Recognizing that delay became a limited resource in modern networks, this ITU-T
Recommendation is intended to assist network operators and transmission planners
as well as equipment manufacturers in controlling the detrimental effects of pure delay
(even if echo is perfectly controlled) on end-to-end speech transmission quality.
All applications with overall performance which depend on user or terminal interactivity
are concerned.
This recommendation defines three bands of one-way delay as shown in Table 8.

Range in Milliseconds Description

0-150 Acceptable for most user applications (this value can be increased
up to 200 ms12).
150-400 Acceptable provided that administrators are aware of the
transmission time and the impact it has on the transmission quality
of user applications.
Above 400 Unacceptable for general network planning purposes. However, it is
recognized that in some exceptional cases this limit is exceeded.
TABLE 8 - ONE-WAY DELAY SPECIFICATIONS

These recommendations are for connections with echo adequately controlled. This
implies that echo cancellers are used. Echo cancellers are required when one-way
delay exceeds 25 ms as described in ITU-T G.131 [6].
To provide high quality voice, the VoIP network must be capable of guaranteeing low
delay (or also called latency). To assure high quality voice communication for Air
Traffic Management the reasonable delay limit for voice applications should be 150 or
200 ms.

Satellite Quality

High Quality Fax Relay, Broadcast

0 100 200 300 400 500 600 700 800

Time (msec)
Delay Target

FIGURE 24 : CUMULATIVE TRANSMISSION PATH DELAY

12
The latest version of ITUT-T G.114 (05/2003) even defines 200ms as an absolute maximum of a
one-way-transmission delay.

© EUROCAE, 2009
 70

Since this includes the entire voice path the network should have transit latencies of
considerably less than the delay target.
When considering the one-way delay of voice traffic, one must take into account the
delay added by the different segments and processes in the network.

4.2.2 Sources of Delay

Before assessing the impact, it is useful to first identify the sources of delays.

• CODEC (Encode)
Voice Path • Packetization
• Output queuing
Delay • Access (up) link transmission
+ • Backbone network transmission
Delay • Access (down) link transmission
Variation
• Input queuing
• Jitter buffer
• CODEC (Decode)

FIGURE 25 : SOURCES OF DELAY

Some components in the delay budget need to be broken into fixed and variable
delay. For example, for the backbone transmission there is a fixed transmission delay
which is dictated by the distance, plus a variable delay which is the result of changing
network conditions. The sources of delay can be classified as follows:
• Coder (Processing) delay (Fixed) • Queuing/Buffering delay (Variable)
• Packetization delay (Fixed) • Network switching delay (Variable)
• Serialization delay (Fixed)
• Network components delay (Fixed)
• Propagation delay (Fixed)
• De-Jitter delay (Fixed)

4.2.2.1 Fixed Delay Components

Fixed delay components add directly to the overall delay on the connection.

4.2.2.1.1 Processing Delay

This is the time taken by the digital signal processor (DSP) to compress a block of
PCM samples. This is often also called coder delay. This delay varies with the voice
coder used and processor speed.
Table 9 summarizes the processing delay of common coding standards (best and
worst case values). For design purposes use the worst case time.
Coder Rate Required Best Case Worst Case
Sample Block Coder Delay Coder Delay
ADPCM, G.726 32 Kbps 10 ms 2.5 ms 10 ms
CS-ACELP, G.729A 8.0 Kbps 10 ms 2.5 ms 10 ms
MP-MLQ, G.723.1 6.3 Kbps 30 ms 5 ms 20 ms
MP-ACELP, G.723.1 5.3 Kbps 30 ms 5 ms 20 ms
TABLE 9 - PROCESSING DELAY

© EUROCAE, 2009
 71

4.2.2.1.2 Algorithmic Delay

This is the delay introduced by the CODEC and is inherent in the coding algorithm.
Table 10 summarizes the algorithmic delay of common coding standards.
Coder Algorithmic Delay
G.711 ~0 ms
G.726 ~0 ms
G.729 5 ms (+ lookahead buffer 10ms)
G.723.1 7.5 ms (+ lookahead buffer 30ms)
TABLE 10 - ALGORITHMIC DELAY

4.2.2.1.3 Packetization Delay

This delay is the time taken to fill a packet payload with encoded/compressed speech.
It is a function of the sample block size and the number of blocks placed in a single
frame.
Voice samples are often accumulated before putting into a frame for transmission to
reduce the amount of overhead. RFC 1890 [22] specifies that the default packetization
period should be 20 ms. For G.711 [2] this means that 160 samples will be
accumulated and then transmitted in a single frame. On the other hand, G.723.1 MP-
ACELP [11] generates a voice frame every 30 ms and each voice frame is usually
transmitted as a single packet.
Coder Rate Payload Packetization Payload Size Packetization
Size (Bytes) Delay (ms) (Bytes) Delay (ms)

PCM, 64 Kbps 160 20 240 30

G.711

ADPCM, 32 Kbps 80 20 120 30

G.726

CS-ACELP, 8.0 Kbps 20 20 30 30

G.729A

MP-MLQ, 6.3 Kbps 24 24 60 48

G.723.1

MP-ACELP, 5.3 Kbps 20 30 60 60

G.723.1

TABLE 11 - PACKETIZATION DELAY

NOTE: You have to balance the Packetization delay against the CPU load. The
lower the delay, the higher the frame rate, and the higher the load on the
CPU of switching components.

© EUROCAE, 2009
 72

4.2.2.1.4 Serialization Delay

Serialization delay is the fixed delay required to clock a voice or data frame onto the
network interface. It is directly related to the clock rate on the link.

Frame Size
1 64 128 256 512 1024 1500
Byte Bytes Bytes Bytes Bytes Bytes Bytes

56kbps 143μs 9ms 18ms 36ms 72ms 144ms 214ms

64kbps 125μs 8ms 16ms 32ms 64ms 128ms 187ms

128kbps 62.5μs 4ms 8ms 16ms 32ms 64ms 93ms

Link 256kbps 31μs 2ms 4ms 8ms 16ms 32ms 46ms

Speed
512kbps 15.5μs 1ms 2ms 4ms 8ms 16ms 23ms

768kbps 10μs 640μs 1.28ms 2.56ms 5.12ms 10.24ms 15ms

1536kbs 5μs 320μs 640μs 1.28ms 2.56ms 5.12ms 7.5ms

2048kbs 3.8μs 250μs 500μs 1ms 2 ms 4ms 5.75ms

TABLE 12 - SERIALIZATION DELAY

Table 12 shows the serialization delay required for different frame sizes at different
line speeds. This table uses total frame size and not payload sizes.

4.2.2.1.5 Propagation Delay

This is the time required for the electrical or optical signal to travel along a
transmission medium and is a function of the geographic distance. The propagation
speed in a cable is approximately 4 to 6 microseconds per kilometre. For satellite
transmission, the delay is 110 ms for a 14000-km altitude satellite and 260 ms for a
36000-km altitude satellite.

4.2.2.1.6 Network Component Delay

This delay is caused by the various components within the transmission system. For
example, a frame passing through a router has to move from the input port to the
output port through the backplane. There is some minimum delay due to the speed of
the backplane and some variable delays due to buffering and router processing. This
delay is typically very low; one must look at the incremental transit delay caused by
the components.
A typical calculation can be found in section 4.2.2.3.2.

© EUROCAE, 2009
 73

4.2.2.1.7 De-Jitter Delay

Because speech is a constant bit-rate service, the jitter from all the variable delays
(see 4.2.2.2) must be removed before the signal leaves the network.
A de-jitter has to hold the incoming frames in a playout buffer long enough to allow the
slowest frames to arrive in time to be played in the correct sequence. The larger the
amount of jitter, the longer some of the frames will be held in the buffer, which
introduces additional delay.
The de-jitter buffer transforms the variable delay into a fixed 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. The adaptive de-jitter buffers can be
configured; the delay becomes a variable figure. However, the maximum delay is fixed
and can be used as worst case for design purposes.

4.2.2.2 Variable Delay Components, Jitter

Variable Delay is a variation in packet transit delay caused by queuing, congestion or

other effects on the path through the network. There is also a delay variation in case
of network reconfiguration (for example to find new network paths in case of
component or line faults).
The different variable delay components will cause the end-to-end jitter. Jitter controls
the regularity in which voice packets arrive. Typical voice sources generate voice
packets at a constant rate. The matching voice decompression algorithm also expects
incoming voice packets to arrive at a constant rate. However, the packet-by-packet
delay inflicted by the network may be different for each packet. This is illustrated in
Figure 26.

Source Receiver
S1
S2 R1
S3 R2
Di = (Ri − Si ) − (Ri −1 − Si −1 )
R3 = (Ri − Ri −1 ) − (Si − Si −1 )

∑
n
Si Di
Jitter = i
Ri n

FIGURE 26 : JITTER

Variable delays are handled through the de-jitter buffer at the receiving router/gateway
(see 4.2.2.1.7).

© EUROCAE, 2009
 74

4.2.2.2.1 Queuing/Buffering Delay

After the compressed voice payload is built, a header is added and the frame is
queued for transmission on the network connection. Voice needs to have absolute
priority in the router/gateway. Therefore, a voice frame must only wait for either a data
frame that already plays out, or for other voice frames ahead of it. Essentially the
voice frame waits for the serialization delay of any preceding frames in the output
queue. Queuing delay is dependent on the link speed and the state of the queue.
There are random elements associated with the queuing delay.
For example, assume that you are on a 64 Kbps line, and that you are queued behind
one data frame (48 bytes) and one voice frame (42 bytes). Because there is a random
nature as to how much of the 48 byte frame has played out, you can safely assume,
on average, that half the data frame has been played out. Based on the data from the
serialization table, your data frame component is 6 ms * 0.5 = 3 ms. When you add
the time for another voice frame ahead in the queue (5.25 ms), it gives a total time of
8.25 ms queuing delay.

4.2.2.2.2 Network Switching Delay

The public or private Wide Are Network (WAN) that interconnects the endpoint
locations is the source of the largest delays for voice connections. Network Switching
Delays are also the most difficult to quantify.
If wide-area connectivity is provided by a private network, it is possible to identify the
individual components of delay. In general, the fixed components are from
propagation delays on the trunks within the network, and variable delays are from
queuing delays clocking frames into and out of intermediate switches. In order to
estimate propagation delay, a popular estimate of 10 microseconds/mile or 6
microseconds/km (G.114) is widely used. However, intermediate multiplexing
equipment, backhauling, microwave links, and other factors found in carrier networks
create many exceptions.
The other significant component of delay is from queuing within the wide-area
network. In a private network, it can be possible to measure existing queuing delays or
to estimate a per-hop budget within the wide-area network.
Typical carrier delays for Frame Relay connections are 40 ms fixed and 25 ms
variable for a total worst case delay of 65 ms. Carriers sometimes offer premium
services. These services are usually for voice traffic, where the network delay is
guaranteed and less than the standard service level (for example 50 ms rather than
the standard service's 65 ms).
As an example the Round-Trip Times on the Internet can be found in Table 13.
These values show what is possible. The average round trip time within Europe is
about 43 ms. The average network delay (including component and propagation
delay) for one way is about 21.5 ms.
Another example can be found in Table 14: Round Trip Delay in ms from SITA's
IPVPN Network Edge Routers to Edge Routers (PE to PE routers RTD).
An example for a private national network can be found in Figure 27: The average
round trip times in the DFS WAN between centre sites are below 24 ms which means
the average network delay is less than 12 ms.

© EUROCAE, 2009
 75

TABLE 13 - AVERAGE ROUND TRIP TIMES ON THE INTERNET

More information on IEPM Home Page ‘Internet End-to-end Performance Monitoring’

[26].

RTD (ms) Amsterdam Brussels Bucharest Frankfurt Geneva Washington Paris London Madrid Oslo Milan Vienna
Amsterdam 7 45 12 28 85 19 12 46 41 34 25
Brussels 7 50 17 32 90 24 17 51 46 40 30
Bucharest 45 50 39 59 129 50 57 77 85 66 53
Frankfurt 12 17 39 22 92 13 20 41 49 29 30
Geneva 28 32 59 22 91 12 19 39 47 27 36
Washington 85 90 129 92 91 82 76 112 105 98 105
Paris 19 24 50 13 12 82 10 30 38 19 27
London 12 17 57 20 19 76 10 40 32 26 33
Madrid 46 51 77 41 39 112 30 40 68 46 55
Oslo 41 46 85 49 47 105 38 32 68 54 61
Milan 34 40 66 29 27 98 19 26 46 54 43
Vienna 25 30 53 30 36 105 27 33 55 61 43

TABLE 14 - ROUND TRIP DELAY FROM SITA'S IPVPN NETWORK (EXTRACT)

Bremen Berlin
SD

RTEL PASSPORT
SD

RTEL PASSPORT

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Sa
t t us A C P owe r S up pl y Sa
t t us A C P owe r S up pl y Sa
t t us A C P ower S up pl y

Status ACPo we r Sup pl y Status ACPowe r Sup pl y Status ACPowe r Sup pl y

Powe r Sup pl y 1 Powe r Su p pl y 2 Powe r Su pp l y 3

Po wer Sup pl y 1 Po wer Sup pl y 2 Po wer Sup pl y 3

Ai r F i tl e r
Remo ve coo l n
i g u ni t d rawe r fi rst
Ai r Fi tl e r
Rem ove co ol n
i g u ni t d rawe r fi rst

Sta tu s Cool i ng Uni t

Status Coo li ng Un ti

23 ms Frankfurt (Rhein- 16 ms
Main Region)
SD

RTEL PASSPORT

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

S t at us A C P owe r S up pl y S ta t us AC P ower S upp yl St at u s A C Po wer Su ppl y

Po wer Sup pl y 1 Po we r Sup pl y 2 Powe r Su pp yl 3

Ai r F i tl e r
Remo ve coo l n
i g un i t d rawe r fi rst

Sta tu s Cool i ng Uni t

8 ms 13 ms
SD SD

RTEL PASSPORT RTEL PASSPORT

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Sta tus ACPowe r Sup pl y Sta tus ACPowe r Sup pl y Sta tus ACPower Sup pl y Status AC Po we r Su ppl y Status ACPo we r Su ppl y Status ACPo we r Sup pl y

Powe r Sup pl y 1 Powe r Su p pl y 2 Powe r Su pp l y 3 Po wer Sup pl y 1 Po wer Sup pl y 2 Po wer Sup pl y 3

Ai r F i tl e r Ai r Fi l te r
Remo ve coo l in g u ni t d rawe r fi rst Rem ov e co ol i ng u ni t dra wer if rst

Sta tu s Cool i ng Uni t Status Coo il ng Un ti

Karlsruhe Munich

FIGURE 27 : ROUND TRIP DELAY WITHIN DFS WAN (EXTRACT)

© EUROCAE, 2009
 76

4.2.2.3 Additional delay reflections

4.2.2.3.1 Fragmentation in the WAN

Large packets can cause de-jitter buffer underruns especially on slower links.
Ethernet [28] Frames can carry 46 to 1500 bytes of data (pay load). Without any
cutting mechanism this can cause a very high additional queuing delay depending on
the serialization time of this frame. This is shown in Figure 28.

Voice Packet Voice Packet Voice Packet

60 bytes 60 bytes 60 bytes
Every 20ms Every >187ms Every >187ms

~187ms Serialization Delay

Voice 1500 bytes of Data Voice Voice 1500 bytes of Data Voice Voice 1500 bytes of Data Voice

100mbps Ethernet 100mbps Ethernet

64kb WAN

FIGURE 28 : LARGE PACKETS ‘FREEZE OUT’ VOICE

Solution:
Large data packets can be split into smaller ones, this methodology is called
fragmentation.
Fragmentation has to be used on links < 1024 kbps as shown in Figure 29.

Fragmentation of Data packets

Data Data Voice Data

FIGURE 29 : FRAGMENTATION OF DATA PACKETS

© EUROCAE, 2009
 77

4.2.2.3.2 Switch Latency

Switch latency is defined as the time it takes for a networking device to process a data
frame. For switches that store, process and then forward incoming frames, latency is
measured as the elapsed time between receiving the last bit of the incoming packet
and transmitting the first bit of the resulting outgoing packet (LIFO latency). For cut-
through switches or fragment-free cut-through switches, the processing delay or
latency is the elapsed time between receiving the first bit of the incoming packet and
transmitting the first bit of the resultant outgoing packet (FIFO latency).
In comparing the impact on end-to-end delay caused by cut-through switches and
store-and-forward switches, one must look at the incremental transit delay caused by
the switch. On principle this delay is fixed and assigned to 4.2.2.1.6 Network
Component Delay. In essence, this requires adding back the packet transmission time
to the LIFO latency of store-and-forward switches and comparing this to the FIFO
latency of cut-through and fragment-free switches.

4.2.2.3.2.1 Cut Through Switching

Cut through is a type of network switch (or router) architecture for packet switching
systems. Wherein the switch starts forwarding that frame (or packet) before the whole
frame has been received, normally as soon as the destination address is processed.
This technique reduces latency through the switch. In packet switched networks such
as Ethernet, cut-through switching can only be used where the outgoing interface is
equal in speed to, or slower than the incoming interface.
The switch only needs the destination address to route the whole frame. The first 14
Bytes have to be read (8 Bytes preamble and 6 Bytes destination address). The
latency TL of a Cut-Through Ethernet-Switches can then be calculated as follows:
TL = TIG + 14 × 8 × TBK [μs ]
The interframe gap is a 96 bit time delay provided between frame transmissions to
allow the network interfaces and other components some recovery time between
frames. With an interframe gap of TIG and a Bit period of TBK:
10Mbps LAN
TL = 9.6 + 14 × 8 × 0.1 = 20.8μs

100Mbps LAN
TL = 0.96 + 14 × 8 × 0.01 = 2.08μs

4.2.2.3.2.2 Store and Forward Switching

Store and forward is a communications technique in which messages are sent to an

intermediate station where they are kept and sent at a later time to the final destination
or to another intermediate station
Before processing (crc, address resolution, filtering…) the whole frame has to be
stored. After successful processing the frame is forwarded to its destination. The
latency TL of an Ethernet Store-and-Forward switch can then be calculated as follows:
TL = TIG + F × 8 × TBK [μs ]

© EUROCAE, 2009
 78

The minimum frame size F of an Ethernet frame is 72 Bytes; the maximum frame size
is 1526 Bytes:
10Mbps LAN
TL min = 9.6 + 72 × 8 × 0.1 = 67.2 μs
TL max = 9.6 + 1526 × 8 × 0.1 = 1230μs
100Mbps LAN
TL min = 0.96 + 72 × 8 × 0.01 = 6.72 μs
TL max = 0.96 + 1526 × 8 × 0.01 = 123μs
4.2.2.3.2.3 Fragment Free Switching

Fragment-free switching is suitable for backbone applications in a congested network,

or when connections are allocated to a number of users. The switching device checks
the source and destination MAC address of a packet, and sends the packet to the port
corresponding to the destination. The packets are sent through the switch as a
continuous flow of data - the transmit and receive rates are always the same. Because
of this, fragment-free switching cannot pass packets to higher speed networks, for
example, to forward packets from a 10 Mbps to a 100 Mbps Ethernet network.
Therefore, if you opt for fragment-free switching, you cannot make direct connections
to higher speed networks from that port. Fragment-free switching offers a compromise
between cut through (which offers the fastest possible forwarding at the expense of
any error checking) and store-and-forward (which offers maximum error checking at
the expense of latency), to provide an average latency of approximately 60µs and
sufficient error checking to eliminate most common errors.
Summary: These figures show that latency on the LAN can be considered as ~0ms,
especially when using Fast Ethernet LAN`s and small voice frames.

4.2.3 Delay Engineering

4.2.3.1 The Delay Budget

When engineering voice traffic many fixed delays are known and can be used for the
network design. But how much variable delay or jitter can the system tolerate?

Overview: Sources of delay

IP

IP

IP

IP

IP

IP

IP

IP
WAN,
LAN Access Access LAN
IP Core

Algorithmic Ethernet ~0 ms Serialization Network Switching Serialization Ethernet ~0 ms De-Jitter

Packetization Queuing/Buffering -Propagation Queuing/Buffering
Network Component -Serialization Network Component
-Queuing/Buffering
-Network Components

Voice samples

FIGURE 30 : NETWORK DELAY OVERVIEW

© EUROCAE, 2009
 79

Figure 30 shows a typical design of a VoIP network and the sources of delay.
As an example the delay budget can be constructed:
Delay source Fixed delay in ms
Algorithmic delay (G.723.1) 37.5
Packetization delay 30.0
Serialization delay of Access (on a 64 Kbps line, a CS-ACELP 5.0
voice frame with a length of 38 bytes [37+1 flag] has a
serialization delay of 4.75 ms)
Network component delays 2.0
Propagation delay (1000km of fiber) 5.0
Total 79.5
TABLE 15 EXAMPLE OF FIXED DELAY CALCULATION

Assume an end-to-end delay target of 150 ms.

Variable delay limit = 150 – 79.5 = 70.5 ms
In this example, the fixed (minimum) delay is calculated to be 79.5 ms. The presence
of jitter will add to the end-to-end delay.
If the end-to-end delay target is 150 ms, then the maximum jitter that can be tolerated
is 70.5 ms. The assumption is that the jitter will be removed by a de-jitter buffer which
can delay frames up to 70.5 ms.
This calculation is nearly a worst-case scenario. Even with a network delay of 42ms
there is still a budget of about 80ms jitter or additional delay.

4.2.3.2 Reduce Delay and Jitter

The main actions to take to reduce latency and jitter are described in [1]. Keeping
delay under some limits is essential to optimising VoIP systems (approximately 170
ms). Since jitter increases effective latency is really crucial to control this two
parameters.
There are two scenarios to have into account to decrease both latency and jitter: at
the endpoint system and from end-to-end.

4.2.3.2.1 Reducing delay at the endpoint

Several methods can be employed to get the delay reduced at an end point, such as:
- Optimize jitter buffering
- Optimize packet size
- Avoid asynchronous transcoding
- Use a stable packet size
- Use a low compression codec such as G.711
- Ensure that network protocol stacks are efficient and correctly priorized for VoIP
traffic.

4.2.3.2.2 Reducing End-to-End Delay

The main tool used to reduce end-to-end delay is packets priorization, by using the
techniques mentioned in section ‘Quality of Service QoS’ (4.3)

© EUROCAE, 2009
 80

4.2.4 Conclusion

VOIP calls must achieve the 150ms bound to successfully emulate the QoS that
today’s phones provide. This time constraint leaves very little margin for error in
packet delivery.
Delay is not confined to the endpoints of the system. Each hop along the network
introduces a new queuing delay and possibly a processing delay if it is a security
checkpoint. The better you know your network the better you can characterize the
queuing delay and necessary buffers. Generally, one needs to design for the worst
case scenario and then tune performance when implementation starts.
Jitter refers to non-uniform packet delays. It is often caused by low bandwidth or high
utilisation situations in networks leading to congestion and/or queuing.
Jitter can be controlled throughout the VOIP network by using routers, firewalls, and
other network elements that support Quality of Service (QoS).
QoS is fundamental to the operation of a VOIP network especially to handle delay,
jitter and packet loss.

4.3 QUALITY OF SERVICE QOS

QoS (Quality of Service) is a major issue in VOIP implementations. The issue is how
to guarantee that packet traffic for a voice or other media connection will not be
delayed or dropped due interference from other lower priority traffic.
Things to consider are
¾ Latency: Delay for packet delivery
¾ Jitter: Variations in delay of packet delivery
¾ Packet loss: Too much traffic in the network causes the network to drop
packets
For the end user, large delays can cause bad echos. It's hard to have a working
conversation with too large delays. You keep interrupting each other. Jitter causes
strange sound effects, but can be handled to some degree with "jitter buffers" in the
software. Packet loss causes interrupts. Some degree of packet loss won't be
noticeable, but lots of packet loss will make sound bad.

4.3.1 VoIP QoS requirements

Latency
Callers usually notice roundtrip voice delays of 250ms or more. ITU-T G.114 [5]
recommends a maximum of a 150 ms one-way latency. Since this includes the entire
voice path, the network should have transit latencies of considerably less than 150
ms.
For ATC purposes it is recommended to offer best speech quality. SG1 of EUROCAE
WG-67 defined the requirement of a maximum of 100ms for the voice path.
Jitter
Jitter can be measured in several ways. There are jitter measurement calculations
defined in:
¾ IETF RFC 3550 RTP: A Transport Protocol for Real-Time Applications [16]
¾ IETF RFC 3611 RTP Control Protocol Extended Reports (RTCP XR) [34]
But, equipment and network vendors often don't detail exactly how they are
calculating the values they report for measured jitter. Most VOIP endpoint devices
have jitter buffers to compensate for network jitter.

© EUROCAE, 2009
 81

Packet Loss
VOIP is not tolerant of packet loss. Even 1% packet loss can "significantly degrade" a
VOIP call using a G.711 [2] codec and other more compressing codecs can tolerate
even less packet loss.
Ideally, there should be no packet loss for VoIP but typically noticeable less than 1%
(for example: 0.1%).

4.3.2 QoS Definition

There are many definitions about Quality of Service; for better understanding three
different perspectives are explained below.

4.3.2.1 The Application Perspective

The Application perspective can be described as follows:

)
QoS is the ability of a network to service a given application efficiently, without
affecting its function or performance.

QoS
Network provides
Level of performance needed for
application to function.

FIGURE 31 : DEFINITION OF QOS

4.3.2.2 The Network Perspective

First of all a general description of a network pipe; Definition of a Pipe: The path from
point A to point B, as perceived by a Packet.
Bandwidth

A The Path, as perceived by a Packet! B

Delay

FIGURE 32 : DEFINITION OF A PIPE

© EUROCAE, 2009
 82

The Network Perspective can then be described as follows:

QoS is the set of techniques to manage:
¾ Bandwidth—the perceived width of the Pipe

) ¾ Delay—the perceived length of the Pipe

¾ Jitter—the perceived variation in the length
¾ Packet Loss—the perceived leak in the Pipe

4.3.2.3 The Business Perspective:

The Business Perspective is only mentioned for the sake of completeness and is not
important for WG-67 tasks.
Bandwidth, delay, jitter, and packet loss can all be thought of as resources, as you can
only guarantee so much of each to a given user/application.
The Business Perspective can then be described as follows:

)
QoS is a resource management of the network, in order to have an application
insurance policy, and maximize the ROI on the network infrastructure.

4.3.2.4 The Need For QoS

The Internet Protocol IP was used primarily in UNIX environments or for connecting to
the Internet; other protocols, like X.25 were used for other purposes. Many companies
have begun using IP for everything-from sharing information within the company to
running voice and other real-time applications across their global enterprise networks.

Data Single Infrastructure

Voice

Packet-Based
Video Multiservice Network
Internet

FIGURE 33: INTEGRATED MULTISERVICE NETWORK

The rise of IP as a foundation for a universal network raises several issues, not the
least of which is how to guarantee that applications will receive the service levels they
require to perform adequately across the network.
Standard Internet Protocol (IP)-based networks provide "best effort" data delivery by
default. Best-effort IP allows the complexity to stay in the end-hosts, so the network
can remain relatively simple. This scales well, as evidenced by the ability of the
Internet to support its growth. As more hosts are connected, network service demands
eventually exceed capacity, but service is not denied. Instead it degrades gracefully.
Although the resulting variability in delivery delays (jitter) and packet loss do not
normally affect typical Internet applications (file transfer, email, www) other
applications cannot adapt to inconsistent service levels. Too high delay, jitter or packet
loss can cause problems for applications with real-time requirements, such as VoIP.
Increasing bandwidth can help to serve these real-time applications, but it is still not
enough to avoid jitter during traffic bursts. Even on a relatively unloaded IP network,
delivery delays can vary enough to affect real-time applications. This requires adding
some rules to the net to distinguish traffic with strict timing requirements from those
that can tolerate delay, jitter and loss. That is what Quality of Service (QoS) protocols
are designed to do.

© EUROCAE, 2009
 83

)
QoS does not create bandwidth, but manages it so it is used more effectively to meet
the wide range or application requirements. The goal of QoS is to provide some level
of predictability and control beyond the current IP "best-effort" service.

4.3.3 QoS Protocols and Standards

As already described there is more than one way to characterize Quality of Service
(QoS). In this chapter QoS is the ability of a network element (e.g. an application, a
host or a router) to provide some level of assurance for consistent network data
delivery.
Some applications are more stringent about their QoS requirements than others, and
for this reason (among others) we have two basic types of QoS available:
¾ Resource reservation (integrated services): network resources are
apportioned according to an application's QoS request, and subject to
bandwidth management policy.
¾ Prioritization (differentiated services): network traffic is classified and
apportioned network resources according to bandwidth management policy
criteria. To enable QoS, network elements give preferential treatment to
classifications identified as having more demanding requirements.
These types of QoS can be applied to individual application "flows" or to flow
aggregates, hence there are two other ways to characterize types of QoS:
¾ Per Flow: A "flow" is defined as an individual, uni-directional, data stream
between two applications (sender and receiver), uniquely identified by a 5-tuple
(transport protocol, source address, source port number, destination address,
and destination port number).
¾ Per Aggregate: An aggregate is simply two or more flows. Typically the flows
will have something in common (e.g. any one or more of the 5-tuple
parameters, a label or a priority number, or perhaps some authentication
information).
Applications, network topology and policy dictate which type of QoS is most
appropriate for individual flows or aggregates. To accommodate the need for these
different types of QoS, there are a number of different QoS protocols and algorithms:
¾ Reservation Protocol (RSVP): Provides the signalling to enable network
resource reservation (otherwise known as Integrated Services). Although
typically used on a per-flow basis, RSVP is also used to reserve resources for
aggregates.
¾ Differentiated Services (DiffServ): Provides a coarse and simple way to
categorize and prioritize network traffic (flow) aggregates.
¾ Multi Protocol Labeling Switching (MPLS): Provides bandwidth management
for aggregates via network routing control according to labels in (encapsulating)
packet headers.
¾ Subnet Bandwidth Management (SBM): Enables categorization and
prioritization at Layer 2 (the data-link layer in the OSI model) on shared and
switched IEEE 802 networks.

© EUROCAE, 2009
 84

4.3.3.1 Resource Reservation Protocol (RSVP)

RSVP (RFC 2205 [39]), which enables non-QoS technologies such as Ethernet and IP
to make QoS requests of the network, is an IETF Internet-Draft that has received a lot
of attention. Specifically, the protocol lets end stations request specific QoS levels for
QoS-enabled applications. For example, for a video conferencing application, a
request could include information that defines the maximum frame transmission rate,
the maximum frame jitter, and the maximum end-to-end delay.
When an end station makes an RSVP request for an application, each router situated
between it and the source makes note of the QoS request and attempts to honor it.

Resource Reservation
• call setup, signaling (RSVP)
• traffic, QoS declaration
• per-element admission control

request/
reply

QoS-sensitive
scheduling

FIGURE 34 : RESOURCE RESERVATION ARCHITECTURE

If a router can't comply with the request-that is, if it can't guarantee the bandwidth or
performance - the requesting station receives an error message, the equivalent of a
busy signal on the voice network.
As you can see from all of these conditional statements, nothing is absolutely
guaranteed automatically with IP-based networks, even with an additional protocol like
RSVP. For example, if a router refuses an RSVP request because it has already
allocated its RSVP bandwidth, the packets associated with the request get dumped.

4.3.3.2 IntServ and RSVP

Integrated Services use a token-bucket model to characterize its input/output queuing

algorithm. A token-bucket is designed to smooth the flow of outgoing traffic, but unlike
a leaky-bucket model (which also smoothes the out-flow), the token-bucket model
allows for data bursts--higher send rates that last for short periods (C. Partridge, [40]).

© EUROCAE, 2009
 85

Tokens

r tokens/sec

Bucket holds up to
Overflow b tokens
Tokens

Packets Arriving Conform

¾ bucket can hold b tokens Exceed

¾ tokens generated at rate r token/sec unless bucket full

¾ over interval t: number of packets admitted less than or equal to (r t + b)

FIGURE 35 : TOKEN BUCKET MODEL

Data flows for an RSVP session are characterized by senders in the TSpec (traffic
specification) contained in PATH messages, and mirrored in the RSpec (reservation
specification) sent by receivers in RESV messages (see 4.3.3.2.2). The token-bucket
parameters-bucket rate, bucket depth, and peak rate--are part of the TSpec and
RSpec.
For a detailed discussion of the token bucket model, and other traffic shaping
schemes, see [40].
RSVP enables Integrated Services, of which there are two fundamentally different
types:
¾ Guaranteed: This comes as close as possible to emulating a dedicated virtual
circuit. It provides firm (mathematically provable) bounds on end-to-end queuing
delays by combining the parameters from the various network elements in a
path, in addition to ensuring bandwidth availability according to the TSpec
parameters.
¾ Controlled Load: This is equivalent to "best effort service under unloaded
conditions." Hence, it is "better than best-effort," but cannot provide the strictly
bounded service that Guaranteed service promises.
The IntServ QoS Service models are defined in RFC 2211 [37] and RFC 2212 [38].

4.3.3.2.1 RSVP functional blocks

RSVP can be divided into the following functional blocks:

¾ RSVP Process - this is the RSVP deamon process, implementing the RSVP
protocol control functions; It maintains all data structures for the protocol, the
node’s state, receiving and processing the RSVP protocol messages.
¾ Policy control - this module determines whether the user has administrative
permission to make the reservation.

© EUROCAE, 2009
 86

¾ Traffic Control
Admission control - this module determines whether the node has sufficient
available resources to supply the requested QoS. It is decided whether a
request for resources can be granted.
Packet classifier - determines the QoS class for each data packet.
When a router receives a packet, the classifier will perform a Multi-Field (MF)
classification and put the packet in a specific queue based on the classification
result.
Packet scheduler - for each outgoing interface, achieves the promised QoS.
Schedule the packet accordingly to meet its QoS requirements.

Host (sender, receiver) Router

RSVP RSVP
Process Process
Application Policy Routing Policy
control Process control

Data

Admission Admission
control control

Packet Packet Packet Packet

classifier scheduler classifier scheduler

Traffic control Traffic control

FIGURE 36 : RSVP FUNCTIONAL BLOCKS

4.3.3.2.2 RSVP Signaling

The Reservation Protocol (RSVP) is a signaling protocol that provides reservation

setup and control to enable the integrated services (IntServ).
Here is a simplified overview of how the protocol works, as illustrated in Figure 37:
(1) Traffic Specification (TSpec) in Path message from Sender profiles the data
flow to be sent. RSVP sends a PATH message from the sender that contains
this traffic specification (TSpec) information to the (unicast or multicast
receiver(s)) destination address.
(2) Path message flows downstream to receiver through each router hop.
(3) Receiver receives PATH request from sender. PATH request provides return
path for RESV message.

© EUROCAE, 2009
 87

(4) Upon receipt of path request, Receiver send RESV message upstream to
Sender. In addition to the TSpec, the RESV message includes a request
specification (RSpec) that indicates the type of Integrated Services required-
either Controlled Load or Guaranteed--and a filter specification (filter spec) that
characterizes the packets for which the reservation is being made (e.g. the
transport protocol and port number). Together, the RSpec and filter spec
represent a flow-descriptor that routers use to identify each reservation (a.k.a.,
a "flow" or a "session").
(5) Each (RSCP-enabled) router in path reserves necessary resources requested
in Sender's TSpec. The routers along the downstream route establish a "path-
state" that includes the previous source address of the PATH message (i.e. the
next hop "upstream" towards the sender). When each RSVP router along the
upstream path receives the RESV message, it uses the admission control
process to authenticate the request and allocate the necessary resources. If the
request cannot be satisfied (due to lack of resources or authorization failure),
the router returns an error back to the receiver. If accepted, the router sends the
RESV upstream to the next router.
PATH and RESV requests are transparent to non-RSVP routers. There is an explicit
tear-down process for a reservation when sender or receiver ends an RSVP session
(not shown in the figure).

TH
1 2 3
4 5 6
7 8 9

PA
* 8 #

SV
RE
1
PAT 4
TH

H
PA

1 2 3
4 5 6
7 8 9
* 8 #

RES
SV

V
RE

PA
TH
2
TH
PA
RE
SV SV
RE

FIGURE 37 : RSVP SIGNALING

4.3.3.2.3 RSVP Summary and Issues

RSVP isn’t simple, for better understanding a summary of the main characteristics of
the RSVP Protocol mechanisms are given below:
¾ RSVP is not a transport, but a network (control) protocol. As such, it does not
carry data, but works in parallel with TCP or UDP data "flows."
¾ Applications require APIs to specify the flow requirements, initiate the
reservation request, and receive notification of reservation success or failure
after the initial request and throughout a session. To be useful, these APIs also
need to include RSVP error information to describe a failure during reservation
setup or anytime thereafter during the lifetime of a reservation as conditions
change.
¾ Reservations in each router are "soft," which means they need to be refreshed
periodically by the receiver(s).

© EUROCAE, 2009
 88

¾ Reservations are receiver-based, in order to efficiently accommodate large

heterogeneous (multicast) receiver groups.
¾ Multicast reservations are "merged" at traffic replication points on their way
upstream, which involves complex algorithms.
¾ Although RSVP traffic can traverse non-RSVP routers, this creates a "weak-
link" in the QoS chain where the service falls-back to "best effort" (i.e. there is
no resource allocation across these links).
¾ RSVP supports both IPv4 and IPv6
As mentioned already the Reservation Protocol (RSVP) is a signaling protocol that
provides reservation setup and control to enable the integrated services (IntServ),
which is intended to provide the closest thing to circuit emulation on IP networks.
RSVP is the most complex of all the QoS technologies, for applications (hosts) and for
network elements (routers and switches). As a result, it also represents the biggest
departure from standard "best-effort" IP service and provides the highest level of QoS
in terms of service guarantees, granularity of resource allocation and detail of
feedback to QoS-enabled applications and users
RSVP could also lead to a perceived degradation of some network services. In a non-
RSVP network, an application might run slowly or badly - but at least it'll run. In an
RSVP network, the application might not run at all if there's not enough bandwidth to
support it.
Another problem is that routing protocols such as OSPF and Border Gateway Protocol
(BGP) do not currently support RSVP - and, ideally, they should, because a QoS
request is actually made after a route is chosen for a particular data flow. It would be
far better for an RSVP priority level to be taken into account before a route was
chosen.
Another criticism of RSVP is its inability to scale. Some industry watchers have
warned that the protocol might not be suitable for large enterprise networks,
specifically because each and every router along a particular path must support it.
WG-67 is discussing about technology and not money – but a potential downside of
RSVP is cost. Because the protocol requires each router to understand and support
QoS requests, you might have to invest in firmware or hardware upgrades to enable it.

4.3.3.3 Differentiated Services (DiffServ)

DiffServ provides methods of categorizing traffic into different classes, also called
class of service (CoS), and applying QoS parameters to those classes.
To accomplish this, packets are first divided into classes by marking the type of
service (ToS) byte in the IP header. A 6-bit pattern (called the Differentiated Services
Code Point DSCP, RFC 2474 [42]) in the IPv4 ToS Octet or the IPv6 Traffic Class
Octet is used to this end as shown in Figure 38.

© EUROCAE, 2009
 89

6 Bits 2 Bits
Differentiated Service Code Point currently unused
(DSCP)

DS field DSCP CU

IPv6 header
Based on IPv4 header (not shown) 0 4 12 16 24 31
¾ Field DSCP (TOS octet) ver Traffic Class Flow Label
which is 6bits Payload length Next header Hop limit
¾ 2^6 possible combinations,
64 classes
Based on IPv6 header IP Sender
¾ DSCP field that belongs to
Traffic Class
¾ Possible use of flow label
(for flow classification)
IP Destination
standardized with RFC 3697

FIGURE 38 : DIFFERENTIATED SERVICES FIELD (DS FIELD)

Once packets are classified at the edge of the network, specific forwarding treatments,
formally called PHB (Per-Hop Behavior), are applied on each network element,
providing the packet the appropriate delay-bound, jitter-bound, bandwidth, etc.
This combination of packet marking and well-defined PHBs results in a scalable QoS
solution for any given packet, and thus any application. Thus, in DiffServ, signaling for
QoS is eliminated, and the number of states required to be kept at each network
element is drastically reduced, resulting in a simple and scalable end-to-end QoS
solution.

4.3.3.3.1 The Differentiated Services Architecture

RFC 2474 [42] and RFC 2475 [43] define the architecture, and the general use of bits
within the DS field.
Elements are generally placed in ingress and egress boundary nodes of a
differentiated services domain and in interior DS-compliant nodes.
There are different responsibilities for edge routers and core routers as shown in
Figure 39.

© EUROCAE, 2009
 90

Simple tasks
scheduling

..
.

Complex
tasks
r marking
Edge router: DSCP Data
b
• Traffic Classification
• Policing

• Shaping
Core router:
• Buffering and Scheduling based on marking at edge

• Assured Forwarding

FIGURE 39 : DIFFSERV NETWORK ARCHITECTURE

4.3.3.3.1.1 DiffServ Edge Router

The Edge router architecture has two major components: Classification and
Conditioning (see Figure 40).
Packet Classifiers
¾ Classification is done with packet classifiers, which select packets based on the
content of packet headers according to well-defined rules determined by the
Traffic Conditioning Agreement.
¾ Behaviour Aggregate (BA) classifier, which selects packets based on the DS
Codepoint only.
¾ Multi- Field (MF) classifier, which performs the selection based on the
combination of one or more header fields.
Traffic Conditioners
¾ Meter: Measures submitted traffic for conformance to a profile; It determines
whether a given packet stream class is within or exceeds the service level
guaranteed for that class.
¾ Marker: Sets the DS Codepoint in a packet based on well defined rules.
¾ Shaper: delays packets within a traffic stream to cause the stream to conform to
some defined traffic profile.
¾ Dropper/Policer: Drops packets based on specified rules, e.g. when the rate of
packets of a given class exceeds the limit in the profile for that class.

© EUROCAE, 2009
 91

Packet Flow Conditioning

Classification Shaper
Classifier Marker
Dropper
Meter
Control Flow

FIGURE 40 : DIFFSERV ARCHITECTURE (SIMPLIFIED) FOR EDGE ROUTERS

4.3.3.3.2 Per-Hop-Behaviour PHB

The main job of the core routers is differentiating incoming packets based on code
point and entries in PHB (per-hop-behaviour) table.
Now that packets can be marked using the DSCP, how do we provide meaningful
classification on flows (Class of Service - CoS), and provide the QoS that is needed?
First, the collection of packets that have the same DSCP value (also called a
Codepoint) in them, and crossing in a particular direction is called a Behavior
Aggregate (BA). Thus, packets from multiple applications/sources could belong to the
same BA.
Formally, RFC-2475 [43] defines a PHB as the externally observable forwarding
behavior applied at a DS-compliant node to a DS behavior aggregate. In more
concrete terms, a PHB refers to the packet scheduling, queuing, policing, or shaping
behavior of a node on any given packet belonging to a BA, and as configured by an
SLA or policy.
To date, four standard PHBs are available to construct a DiffServ-enabled network
and achieve CoS and QoS:
¾ The Default PHB
(Defined in RFC-2474 [42]). The default PHB essentially specifies that a packet
gets the traditional best effort service from a DS-compliant node.
¾ Class-Selector PHBs
(Defined in RFC-2474 [42]). These PHBs ensure that DS-compliant nodes can
co-exist with IP-Precedence aware nodes.
¾ Expedited Forwarding (EF):
(Defined in RFC-2598 [46]). Has a single codepoint (DiffServ value). EF
minimizes delay and jitter and provides the highest level of aggregate quality of
service. Any traffic that exceeds the traffic profile (which is defined by local
policy) is discarded. EF PHB is especially suitable for applications (like VoIP)
that require very low packet loss, guaranteed bandwidth, low delay, and low
jitter.
¾ Assured Forwarding (AF):
(Defined in RFC-2597 [45]). Has four classes and three drop-precedences
within each class (so a total of twelve codepoints). Excess AF traffic is not
delivered with as high probability as the traffic "within profile," which means it
may be demoted but not necessarily dropped.

© EUROCAE, 2009
 92

4.3.3.3.3 DiffServ Summary and Issues

Here is a summary of the main characteristics of the DiffServ mechanisms:

¾ IP QoS architecture based on packet-marking, these allow IP traffic to be
classified into a finite number of service classes that receive different router
treatment.
¾ DS field or Codepoint (DSCP) is Type of Service field in IPv4 Traffic Class Field
in IPv6; Differentiating traffic classes according to requirements (policies).
¾ No signaling protocols required.
¾ No attempt to make end-to-end guarantees, no end-to-end resource
reservation.
¾ DiffServ attempts to restrict complexity to only the edge routers, amount of state
information required per node is proportional to number of service classes and
not proportional to the number of application flows.
DiffServ, as great as it is, in enabling scalable and coarse-grained QoS throughout the
network, has some drawbacks.
Here are the most important issues for WG67:
¾ Provisioning
Unlike RSVP/IntServ, DiffServ needs to be provisioned. Setting up the various
classes throughout the network requires knowledge of the applications, and
traffic statistics for aggregates of traffic on the network. This process of
application discovery and profiling can be time-consuming, although tools such
as Performance Management, Protocol Analyzers, and RMON (Remote
Monitoring) probes can make life easier.
¾ QoS and Routing
One of the biggest drawbacks of both the IntServ and DiffServ models comes
from the fact that signaling/provisioning happens separate from the routing
process. Thus, there may exist a path (other than the non-default Interior
Gateway Protocol IGP, such as OSPF, ISIS, EIGRP, and so on)/Exterior
Gateway Protocol (EGP, such as BGP-4, path) in the network that has the
required resources, even when RSVP/DiffServ fails to find the resources. This is
where traffic engineering and MPLS come into play.

4.3.3.4 Multi Protocol Label Switching MPLS

MPLS is more of a "traffic engineering" protocol than a QoS protocol, per se. MPLS
routing is used to establish "fixed bandwidth pipes" analogous to ATM or Frame Relay
virtual circuits. The difference is arguable since the end-result is service improvement
and increased service diversity with more flexible, policy-based network management
control, all of which the other QoS protocols also provide. The MPLS standards can be
found at IETF [49].

4.3.3.4.1 MPLS Technical background and concepts

Multi-Protocol Label Switching (MPLS) is similar to DiffServ in some respects, as it

also marks traffic at ingress boundaries in a network, and un-marks at egress points.
But unlike DiffServ, which uses the marking to determine priority within a router, MPLS
markings (20-bit labels) as shown in Figure 41 are primarily designed to determine the
next router hop.

© EUROCAE, 2009
 93

L2 Header (PPP/Ethernet/...) L2 Header Label Stack Layer 3 Header

Generic Encapsulation/ Shim Header Label (0) Exp S TTL

20 Bits 3 1 8 Bits
Bits Bit
¾ EXP: Experimental Use (used as QoS bits)
¾ S: Bottom of Stack (set to 1 for last entry, 0
for all other label stack entries)
¾ TTL: Time to Live
The Label Stack consists of a sequence of Label Stack Entries equal or greater 1.

FIGURE 41 : LABEL ENCAPSULATION

MPLS is not application controlled (no MPLS APIs exist), nor does it have an end-host
protocol component. Unlike some other QoS protocols, MPLS resides only on routers.
And MPLS is protocol-independent, so it can be used with network protocols other
than IP (like IPX, ATM, PPP or Frame-Relay) or directly over data-link layer as well.

4.3.3.4.1.1 Labels and Paths

An end-to-end MPLS connection is called a Label Switch Path (LSP). This connection
may be established for a variety of purposes, such as to guarantee a certain level of
performance, to route around network congestion, or to create IP tunnels for network-
based virtual private networks. In many aspects, LSPs are no different than switched
paths in ATM or Frame Relay networks, except that they are not dependent on a
particular Layer 2 technology. Traffic is assigned to LSPs based on pre-defined criteria
such as destination IP address, TCP/UDP port number, VLAN Identifier, DiffServ, or
802.1p priority.
Information about the connection is summarized into an MPLS label, which is inserted
between the Layer 2 and Layer 3 headers of each packet. Labels enable different
paths to be established for different customers, or even for different applications for a
single customer. Labels are assigned and distributed via a protocol used for this
purpose.
Labels can be "stacked" (to allow MPLS "routes within routes"), and labeled packets
have a time-to-live value (TTL). The TTL works essentially the same way TTL in an IP
header works: each router hop decrements the value by one until it hits zero. The
difference is that when an MPLS TTL reaches zero, the action is label dependent (so
unlike with IP, the datagram may not be discarded and an ICMP "TTL Exceeded"
message may not be generated).
A more complex aspect of MPLS involves the distribution and management of labels
among MPLS routers, to ensure they agree on the meaning of various labels. The
Label Distribution Protocol LDP (RFC 3036 [53]) is specifically designed for this
purpose, but it is not the only possibility. There are proposals to use RSVP, BGP, and
PIM possibly "piggy-backing" label management information.

© EUROCAE, 2009
 94

4.3.3.4.1.2 MPLS Routers

The first label is added to an incoming packet by a Label Edge Router (LER), also
called an Edge LSR. Labels are a simple indexing mechanism that replaces traditional
Layer 2 (Ethernet/ATM) or Layer 3 (IP) packet forwarding with fast, simple switching.

LSP Label Switched

Path

LER Label Edge Router

• L3 Routing
IP Packet
LSR Label Switching Router
IP Packet w/ Label
• Label Swapping
FIGURE 42 : MPLS NETWORK ARCHITECTURE

4.3.3.4.1.3 Forwarding Equivalence Classes

The “Forwarding Equivalence Class” FEC is an important concept in MPLS. An FEC is

any subset of packets that are treated the same way by a router. By “treated” this can
mean, forwarded out the same interface with the same next hop and label. It can also
mean given the same class of service, output on same queue, given same drop
preference, and any other option available to the network operator.
When a packet enters the MPLS network at the ingress node, the packet is mapped
into an FEC. The assignment of a particular packet to a particular FEC is done just
once (when the packet enters the network). The mapping can also be done on a wide
variety of parameters, address prefix (or host), source/destination address pair, or
ingress interface. This greater flexibility adds functionality to MPLS that is not available
in traditional IP routing.

4.3.3.4.1.4 Switching example

At each hop in the network, a router examines the incoming label to figure out the next
forwarding hop for the packet. This eliminates resource intensive address lookups that
reduce overall packet throughput and limit scalability.
¾ Along the path, each Label Switch Router (LSR) makes forwarding decisions
based solely on the contents of the label.
¾ At each hop, the LSR strips off the existing label and applies a new label which
tells the next hop LSR how to forward the packet.
¾ All MPLS routers within the network regularly exchange label and reachability
information to build a complete picture of the network, which is then used to
determine paths and specify the new label to place onto the packet.

© EUROCAE, 2009
 95

Local Remote Address Interface Local Remote Address Interface

Lbl Lbl Prefix Lbl Lbl Prefix
X 1 128.89 1 Label Information 1 7 128.89 0
X 2 171.69 1 Base 2 5 171.69 4
.. … … 3 … …
128.89
0
I/f 1
171.69.12.1 Data I/f 4
2 171.69.12.1 Data 171.69
5 171.69.12.1 Data
Unlabeled Data

171.69.12.1 Data
CEF Forwarding Table Populated with
Unlabeled Data
Routing Topology Information
Each Route/Prefix Mapped to a Label Value
Switching Decision Then Only ‘Label-
Swaps’ via the Label Information Base (LIB)

FIGURE 43 : MPLS - SWITCHING EXAMPLE

4.3.3.4.2 MPLS and Quality of Service

The LSP can be a best-effort connection, in which case Label Distribution Protocol
(LDP) may be used. Alternatively, an LSP may request that bandwidth be reserved for
its exclusive use. Once allocated, MPLS guarantees that the bandwidth is available for
the entire path. If the bandwidth is not available, then the connection request is
refused. The LSP reserves bandwidth using either Resource Reservation Protocol
with Traffic Engineering extensions (RVSP-TE, RFC 3209 [56]) or Constraint-based
Routing LDP (CR-LDP, RFC 3214 [57]).
This is conceptually similar to Frame Relay's Committed Information Rate (CIR).
However, CIR applies to the access link, and does not guarantee bandwidth across
the backbone.

4.3.3.4.3 Traffic Engineering

Service providers need a way to control the escalating amount of traffic they must
handle. This traffic is dynamic and hard to predict because flows are constantly
changing and therefore do not necessarily match the network topology that has been
put in place. Traffic engineering via MPLS allows the traffic to be mapped efficiently to
the current network topologies. By setting up paths through a network to
accommodate traffic, MPLS offers control over traffic that traditional routing algorithms
cannot.
Traffic engineering via MPLS improves the reliability of networks in two ways.
¾ It allows to route traffic around congested points and to avoid "hot spots" in the
network.
¾ The MPLS paths that traverse a network can be set up to be redundant and
load sharing. This assures that critical traffic like VoIP for ATM always has a
path through the network.

© EUROCAE, 2009
 96

4.3.3.4.4 High Availability

To enable network availability, MPLS provides mechanisms to quickly find an alternate

path if the primary path is no longer available (typically due to a node or link failure).
This Fast Re-Route (FRR, RFC 4090 [58]) allows to offer high availability. Each node
stores information about multiple paths to the destination, and selects the appropriate
path (based on defined criteria such as link speeds, number of hops or traffic priority)
across the network. As soon as the network recognizes that a path is unavailable, it
can begin using the "next best" alternate path.
Alternatively, the network may store only one path to each destination. In the event of
a failure, this "conservative label retention" requires that the signaling protocol
determine a new optimal path after the failure is detected. This can take several
seconds, since it may be necessary for the underlying IP routing protocols (typically
iBGP, OSPF or IS-IS) to re-converge. To eliminate this delay, alternate IP paths
through the network may be pre-defined.

4.3.3.4.5 MPLS Summary and Issues

Here is a summary of the main characteristics of MPLS:

¾ Small labels are added to all packets at the ingress to the network. Note: These
labels do not replace the IP addresses.
¾ Packets are then switched based upon these labels, table lookups are
simplified: Core routers just forward packets based upon labels - Switching
instead of routing.
¾ Labels can be assigned based upon destination address, QoS, costs, security
or any other criteria.
¾ Label is then removed by the egress router.
¾ Traffic is mapped to forwarding equivalency class (FEC) - FEC is determined by
destination address and COS - Supports QoS.
¾ Adopted by all major equipment vendors
¾ Traffic Engineering to solve congestion and improve network throughput – path
determination on ingress.
¾ Differentiated services extentions to offer quality of service (QoS).
¾ ATM and Frame Relay integration to IP Networks.
MPLS facilitates offering a wide range of optional services which provide value beyond
those offered on traditional packet networks:
¾ High Availability: MPLS provides the ability to circumvent failed links and nodes
within 50 milliseconds.
¾ Guaranteed Bandwidth: Unlike traditional packet networks, MPLS provides the
option for end-to-end bandwidth reservation. This ensures timely delivery of
critical information.
¾ Network Convergence: Enterprises and service providers can save money by
integrating voice, video and data on a common network. Bandwidth can be
reserved for individual connections such as VoIP or critical data applications.
Best-effort traffic can also share the MPLS backbone.
¾ Layer 2 Interworking: MPLS is able to integrate sites connected via different
technologies. For example, a site connected via Frame Relay will be able to
exchange information with another site which is connected via Ethernet.

© EUROCAE, 2009
 97

MPLS has some drawbacks, some of them are important for WG67:
¾ The “Multiprotocol” component of MPLS currently only refers to IPv4. IPv6 is
possible but not a standard.
¾ MPLS standards are still evolving.

4.3.3.4.6 Remark about Virtual Private LAN Services VPLS

Virtual Private LAN Service (VPLS) [60] is a L2 service that emulates LAN across an
IP and an MPLS-enabled IP network, allowing standard Ethernet devices
communicate with each other as if they were connected to a common LAN segment.
VPLS can be used to offer not only Ethernet services but also to interconnect
metropolitan area networks based on various technologies such as Next Generation
SDH or Resilient Packet Ring (RPR).
Here is a summary of the main characteristics of MPLS:
¾ Links multiple sites together in a single Ethernet VPN
¾ Uses MPLS to allow configuration of multi-point Layer 2 Ethernet VPNs
¾ Different LANs can be interconnected by BGP MPLS VPN Backbone
¾ Improves scalability and availability (not limited by number of unique VLAN IDs)
It is expected that the VPLS drafts ([59], and especially [60]), which have already been
approved as IETF working group documents, will become RFCs. In the meantime,
most networking vendors have already implemented the VPLS approach, and there
have been a number of developments within the industry that highlight the progress of
VPLS development.
With VPLS it might be possible to have an appropriate QoS solution for Local Area
Networks (LAN); another solution is described in the next chapter.

4.3.3.5 Subnet Bandwidth Manager SBM

QoS assurances are only as good as their weakest link. The QoS "chain" is end-to-
end between sender and receiver, which means every router along the route must
have support for the QoS technology in use, as we have described with the previous
QoS protocols. The QoS "chain" from top-to-bottom is also an important consideration,
however, in two aspects:
¾ Sender and receiver hosts must enable QoS so applications can enable it
explicitly or the system can enable it implicitly on behalf of the applications.
Each OSI layer from the application down must also support QoS to assure that
high-priority send and receive requests receive high priority treatment from the
host's network system.
¾ Local Area Network (LAN) must enable QoS so high-priority frames receive
high-priority treatment as they traverse the network media (e.g., host-to-host,
host-to-router, and router-to-router). LANs are OSI Layer 2, the data-link layer,
whereas the QoS technologies described previous to this have been Layer 3
(DiffServ) and above (RSVP & MPLS).
Some Layer 2 technologies have always been QoS-enabled, such as Asynchronous
Transfer Mode (ATM). However, other more common LAN technologies such as
Ethernet were not originally designed to be QoS-capable. As a shared broadcast
medium or even in its switched form, Ethernet provides a service analogous to
standard "best effort" IP Service, in which variable delays can affect real-time
applications. However, the IEEE has "retro-fitted" Ethernet and other Layer 2
technologies to allow for QoS support by providing protocol mechanisms for traffic
differentiation.

© EUROCAE, 2009
 98

4.3.3.5.1 SBM Technical background and concepts

The IEEE 802.1p [65], 802.1Q [63] and 802.1D [64] standards define how Ethernet
switches can classify frames in order to expedite delivery of time-critical traffic. The
Internet Engineering Task Force (IETF) Integrated Services over Specific Link Layers
(ISSLL) Working Group is chartered to define the mapping between upper-layer QoS
protocols and services with those of Layer 2 technologies, like Ethernet. Among other
things, this has resulted in the development of the "Subnet Bandwidth Manager"
(SBM) for shared or switched 802 LANs such as Ethernet (also FDDI, Token Ring,
etc.). SBM (RFC 2814 [62]) is a signaling protocol that allows communication and
coordination between network nodes and switches in the SBM Framework and
enables mapping to higher-layer QoS protocols.
Original LAN architectures had simple priority structures
¾ Ethernet didn’t have QoS, except for some unusual standards
¾ Token Ring had simple prioritization, not often used
¾ FDDI allowed bandwidth reservation and prioritization, rarely used
¾ IEEE 802.1Q defines VLAN encapsulation field to standardize VLANs among
manufacturers
¾ IEEE 802.1p defines 3-bit user priority field in MAC (802.1p is now in IEEE
802.1D – 1998)

Layer 2 802.1Q/p

TAG
PREAM. SFD DA SA Type PT DATA FCS
4 Bytes

Three Bits Used for CoS

(802.1D User Priority)

VLAN ID

FIGURE 44 : PRIORITY FIELD IN LAYER 2 802.1Q/P

4.3.3.5.1.1 SBM and Designated SBM

DSBM (Designated SBM):

¾ A L2 or L3 device manages resources on a L2 segment.
¾ At most one DSBM exists for each L2 segment.
SBM:
¾ A L2 or L3 device that is capable of managing resources on a segment.
¾ When more than one SBM exists on a segment, one of the SBMs is elected to
be a DSBM.
¾ Dividing the election scope.
¾ Reducing the size and complexity of managed segments.
A fundamental requirement in the SBM framework is that all traffic must pass through
at least one SBM-enabled switch.
The DSBM is responsible for admission control over the rescue reservation requests
originating from the DSBM clients in its managed segment. More than one SBM might
reside on a single segment. One of the SBM's is elected to be a DSBM. One DSBM
can preside over multiple L2 segments provided they are joined by some SBM
transparent device.

© EUROCAE, 2009
 99

4.3.3.5.1.2 Admission Control Procedure

DSBM Client Initialization:

¾ For each interface attached, a DSBM client determines whether a DSBM exists
on the interface (by periodical I_AM_DSBM message).
¾ If the client is capable of serving as DSBM on the segment, it may choose to
participate in the election to become the DSBM.
DSBM-based Admission Control:
Step 1 When a DSBM client sends or forwards a PATH message to a managed
segment, it sends the PATH message to its DSBM instead of sending it to
the RSVP session destination address.
Step 2 The DSBM
¾ builds and maintains a PATH state for the session and notes the
previous hop that sent it the PATH message,
¾ puts its own IP address in the PHOP (RSVP_HOP), and
¾ forwards the PATH message towards its destination address.
Step 3 The receiver sends a RESV message to the previous hop address
Step 4 Resource reservation
¾ The DSBM processes the RSVP RESV message based on the
bandwidth available and returns a ResvErr message to the requester
if the request can not be granted.
¾ The admission control algorithm at DSBM ensures that sufficient
bandwidth is available on managed segments between the NHOP and
the PHOP before accepting a request.
Step 5 If the L2 domain contains more than one managed segment,
¾ the original PATH message would propagate through many DSBMs
¾ the RESV message would reach the original forwarder on the L2
domain if admission control at all DSBM succeeds
All SBM-specific messages are formatted as RSVP messages with an RSVP common
header followed by SBM-specific objects.
An example is shown in Figure 45:
Sender: Outside the L2 domain; Receiver: Host A; R1: DSBM client

© EUROCAE, 2009
 100

L2 domain

Router Host DSBM Host Router

R2 C B R3

Path

LAN Path
Segment
Host Router DSBM
A DSBM R1 client
client
Path
SBM

FIGURE 45 : EXAMPLE OF A MANAGED SEGMENT

4.3.3.5.2 SBM Summary

RSVP and its service class definitions are largely independent of the underlying
network technologies. This independence requires that a user define the mapping of
RSVP onto subnetwork technologies.
The Subnetwork Bandwidth Manager (SBM) feature answers this requirement for
RSVP in relation to IEEE 802-based networks. SBM specifies a signalling method and
protocol for LAN-based admission control for RSVP flows. SBM allows RSVP-enabled
routers and Layer 2 and Layer 3 devices to support reservation of LAN resources for
RSVP-enabled data flows. The SBM signalling method is similar to that of RSVP itself.
SBM and RSVP:
¾ RSVP is designed for Routers/Hosts to reserve resources.
¾ SBM is suitable for Switches (Layer-2 or Layer-3) to reserve resources within a
subnet.
SBM might become more and more important in the near future due to switches will
dominate the network devices.

4.3.3.6 Queuing and scheduling

Providing QoS in a packet network requires the use of traffic scheduling algorithms in
the switches or routers. The function of a scheduling algorithm is to select, for each
outgoing link of the switch (or router) the packet to be transmitted in the next cycle
from the available packets belonging to the flows sharing the output link.
Implementation of the algorithm may be in hardware or software.
There are many different algorithms (queuing mechanisms) available. In this chapter
only the main Queuing mechanisms are described.

© EUROCAE, 2009
 101

4.3.3.6.1 FIFO, First In First Out

FIFO queuing involves storing packets when the network is congested and forwarding
them in order of arrival when the network is no longer congested. FIFO has several
shortcomings. Most importantly, FIFO queuing makes no decision about packet
priority; the order of arrival determines bandwidth, promptness, and buffer allocation.
Characteristics of FIFO
¾ Strict Round-Robin queuing discipline
¾ Queuing-induced jitter component (for example in Figure 46: Compare green
and red distance between packets 1 and 5)

3
6 5 4 3 2 1
5 1
6 2
FIGURE 46 : FIFO, FIRST IN FIRST OUT
FIFO still exists, but today's intelligent networks need more sophisticated algorithms.

4.3.3.6.2 Precedence Queuing

Characteristics of Precedence Queuing (see Figure 47):

¾ Multiple queues, each served in FIFO order
¾ Jitter and delay for high precedence queues still present at short time intervals
¾ Precedence algorithm denies any service to lower level queues until all higher
level queues are exhausted
Stream
Input arrival timing precedence

5 2 1
Queue Output
4 2
7 3 6 5 4 2 1
6 1 3

7 3 4

FIGURE 47 : PRECEDENCE QUEUING

4.3.3.6.3 Class Based Queuing

Characteristics of Class Based Queuing:

¾ Multiple queues, serviced in proportionate levels
¾ Divide service among traffic classes
¾ Divide service among delay classes
¾ Class-based queues attempt to allocate fixed proportion of resource to each
service queue

© EUROCAE, 2009
 102

8 5 2 50%

4 20%
7 6 8 4 5 3 2 1
6 1 20%

7 3 10%

FIGURE 48 : CLASS BASED QUEUING

4.3.3.6.4 Weighted Fair Queuing WFQ

Weighted Fair Queuing is based on Bit-wise Scheduling (which emulates a TDM

system) and on Weighted Bit-wise Scheduling (see Figure 49)
Characteristics of Weighted Bit-wise Scheduling:
¾ Bits from each class are serviced in rotation,
¾ weighted by relative service weight

8 5 2 50%

4 20%
6 1 20%
7 3 10% Bit service interval

FIGURE 49 : WEIGHTED BIT-WISE SCHEDULING

Characteristics of Weighted Fair Queuing (see Figure 50):

¾ Schedule traffic in the sequence such that an equivalent Weighted Bit-wise
Scheduling would deliver the same order of trailing bits of each packet
¾ Discriminates between CoS
¾ Aggregate guaranteed bandwidth allocated to each CoS
¾ Excess bandwidth shared by all CoS’s (based on weight)
¾ High scalability/performance

8 5 1 50%

4 20%
7 6 8 3 5 4 2 1
6 2 20%

7 3 10%

FIGURE 50 : WEIGHTED FAIR QUEUING

4.3.3.6.5 Queue Management and Congestion-Avoidance

Congestion avoidance is a form of queue management. Congestion-avoidance

techniques monitor network traffic loads in an effort to anticipate and avoid congestion
at common network bottlenecks, as opposed to congestion-management techniques
that operate to control congestion after it occurs.

© EUROCAE, 2009
 103

4.3.3.6.5.1 Random Early Detection (RED)

The random early detection (RED) algorithms are designed to avoid congestion before
it becomes a problem. RED works by monitoring traffic load at points in the network
and stochastically discarding packets if the congestion begins to increase. The result
of the drop is that the source detects the dropped traffic and slows its transmission.

4.3.3.6.5.2 Weighted RED

Weighted RED (WRED) combines the capabilities of the RED algorithm with COS.
This combination provides for preferential traffic handling for higher-priority packets. It
can selectively discard lower-priority traffic when the interface starts to get congested
and can provide differentiated performance characteristics for different classes of
service (see Figure 51). WRED is also RSVP-aware and can provide an integrated
services controlled-load QoS.

Packet
Drop
Without Proba
RED bility
Queue Queue Max

Packet
Drop
With “Slope” is
Proba
RED bility
adjustable

Queue Length Queue Max

Packet Premium
Drop Service
With Proba Standard
WRED bility Service
Queue Length Std. Min. Prem. Min. Queue Max

FIGURE 51 : QUEUE MANAGEMENT

4.3.3.6.6 Queuing Summary

Queue management-including the number of queues and their depth, as well as the
algorithms used to manage them is very important to QoS implementations.
Based on Queuing mechanisms mentioned in this chapter the network vendors have
invented further queuing technologies in order to improve QoS, like Priority Queuing
(PQ), Custom Queuing (CQ) or Class-Based Weighted Fair Queuing (CBWFQ).

© EUROCAE, 2009
 104

4.3.3.7 Comparison of Qos Protocols

Table 16 compares the QoS protocols and different bandwidth management

algorithms in terms of the level of QoS they provide and where the service and control
are implemented - in the Application (App) or in the Network (Net). Notice that this
table also refers to router queue management algorithms such as Weighted Fair
Queuing (WFQ), Random Early Drops (RED).
QoS Net App Description
most Provisioned resources end-to-end (e.g. private FrameRelay or ATM
X
network)
X X RSVP (IntServ Guaranteed) Service (provides feedback to application)
X X RSVP (IntServ Controlled Load) Service (provides feedback to application)
X Multi-Protocol Label Switching (MPLS)
Differentiated Services (DiffServ) applied at network core ingress
appropriate to RSVP reservation service level for that flow.
X X
Prioritization using Subnet Bandwidth Manager (SBM) applied on the LAN
would also fit this category.
X X DiffServ or SBM applied on per-flow basis by source application
X DiffServ applied at network core ingress
X Fair queuing applied by network elements (e.g. WFQ, RED)

Best effort service

least
TABLE 16 - COMPARISON OF QOS PROTOCOLS

How can we understand that table? Do provisioned resources end-to-end and RSVP
offer the best and WFQ or the ‘Best effort service’ the worst QoS?
Unfortunately it isn’t that easy: A totally busy and congested provisioned private
network can be worse than the Internet (which delivers only ‘best effort’).
This is where the network engineers come into business. A proper designed and well
engineered network is essential.
In general RSVP provides the highest level of IP QoS available (provisioned
resources aren’t pure IP services). It allows an application to request QoS with a high
level of granularity and with the best guarantees of service delivery possible. This
sounds wonderful and leaves one wondering why we need anything else.
The reason is that it comes at the price of complexity and overhead, thus is overkill for
many applications and for many networks (especially when they are proper designed).
Simpler methods are needed, and that is what for example DiffServ provides.

4.3.3.7.1 QoS Interworking

The QoS protocols we are focused on in this paper vary, but they are not mutually
exclusive of one another. On the contrary, they complement each other nicely. There
is a variety of architectures in which these protocols work together to provide end-to-
end QoS across multiple service providers.
Example: RSVP – DiffServ Integration
¾ Routers at edge of a DS cloud perform flow classification, policing, and marking
¾ Guaranteed Load set to the EF, Controlled load set to AF, Default is Best Effort
¾ Service Model to Forwarding Class mapping is arbitrary

© EUROCAE, 2009
 105

¾ RSVP signaling is used in both (IntServ, DiffServ) regions for admission control
¾ The DiffServ core makes and manages aggregate reservations for the DS
Forwarding Classes based on the RSVP flow reservations
¾ The core then schedules and forwards packets based only on the DS Field

Border Routers implement per- The DiffServ region

flow classification, policing, and aggregates the flows
marking into DS Forwarding
Classes
DiffServ Region

RSVP Signaling is
propagated End-to End

The IntServ regions

contain Guaranteed or
Controlled Load flows

FIGURE 52 : RSVP – DIFFSERV INTEGRATION

In Figure 53 there is another example of the Interworking of different QoS protocols:

SBM, Intserv, DiffServ and MPLS can work together in existing networks.
End-to-end RSVP signaling
802.1p Intserv
aggregate per-flow Diffserv MPLS
data data aggregate Label Switch
handling handling data handling Path

Switched Large MPLS

Small
Network Routed Routed Network
Network Network
(Diffserv)
Admission control Admission control Admission control Admission control
agent for 802.1 agents for Intserv agent for diffserv agent for MPLS
network (DSBM) network network network

FIGURE 53 : INTERWORKING OF QOS PROTOCOLS

© EUROCAE, 2009
 106

4.3.4 Conclusion

Quality of Service generally encompasses bandwidth allocation, prioritization, and

control over network latency for network applications. There are several ways to
ensure QoS. The easiest one is simply to throw bandwidth at the problem until service
quality becomes acceptable. This approach might involve upgrading the backbone to
a high-speed technology such as Gigabit Ethernet or 622Mbit/sec ATM. If you have
fairly light traffic in general, more bandwidth may be all you need to ensure that
applications receive the high priority and low latency they require.
However, this simplistic strategy collapses if a network is even moderately busy. In a
complex environment - one that has a lot of data packets moving in many paths
throughout the network, or that has a mixture of data and real-time applications like
VoIP - you could run into bottlenecks and congestion.
Also, simply adding bandwidth doesn't address the need to distinguish high-priority
traffic flows from lower-priority ones and to fulfil different Service Level Agreements
(SLA).
As you can see, additional bandwidth can solve some of your short-term problems, but
it's not a viable long-term solution.
So how can you flag special traffic as high priority on an IP network? Options like
Weighted Fair Queuing or DiffServ can help you give sensitive applications the
resources they need – but nothing is absolutely guaranteed with IP-based networks,
even with an additional protocol like RSVP. For example, if a router refuses an RSVP
request because it has already allocated its RSVP bandwidth, the packets associated
with the request get dumped.
Therefore a proper network design, engineering and continuous performance
monitoring of the network is essential and can be the ‘most important QoS features’
around.
Which QoS protocol should we use or recommend: Each protocol mentioned in this
document can be recommended but it seems that in the last years the focus has
shifted towards Differentiated services; Focus is on QoS for flow aggregates, e.g., all
the flows belonging to one customer or service are prioritized.
Differentiated services can be a good and reliable technique for VoIP. However, it is
highly recommended developing a field trial in which equipment and technology could
demonstrate the facts together with the VoIP ATM application.

© EUROCAE, 2009
 107

CHAPTER IV REFERENCES

[1] "Overcoming Barriers to High-quality Voice over IP Deployments”, Intel

Whitepaper.
[2] ITU-T Recommendation G.711, "Pulse Code Modulation (PCM) of voice
frequencies".
http://www.itu.int/home/index.html
[3] ITU-T Recommendation G.729, “Coding of speech at 8 Kbit/s using conjugate-
structure algebraic-code-excited linear-prediction (CS-ACELP)”.
http://www.itu.int/home/index.html
[4] Michels Mathew R., “Design VoIP Networks: Lessons from the Edge “,
Bussiness Communications Review, February 2003.
www.nortel.com
[5] ITU-T Recommendation G.114 (05/00), "One way transmission time".
http://www.itu.int/home/index.html
[6] ITU-T Recommendation G.131 (11/03), "Talker echo and its control”.
http://www.itu.int/home/index.html
[7] Understanding Delay in Packet Voice Networks; Cisco Systems Document ID:
5125
www.cisco.com
[8] ANSI, “Packet Loss Concealment for use with ITU-T Recommendation G.711",
July 2000, ANSI Recommendation T1.521a-2000 (Annex B).
[9] Perkins C., Hodson O., Hardman V., “ A Survey of Packet Loss Recovery
Techniques for Streaming Audio”, University College London, IEEE Network,
October 1998.
[10] Perkins C., Kouvelas I., Hodson O. “RTP Payload for Redundant Audio Data”,
RFC 2198, Network Working Group, September 1997.
http://www.ietf.org/rfc/rfc2198.txt
[11] ITU-T Recommendation G.723.1, “Dual rate speech coder for multimedia
communications transmitting at 5.3 and 6.3 Kbit/s”
http://www.itu.int/home/index.html
[12] Deering S., Hinden R., “Internet Protocol, Version 6 (IPv6) Specification”, RFC
2460, Network Working Group, December 1998.
http://www.ietf.org/rfc/rfc2460.txt
[13] S., Casner and V., Jacobson, "Compressing IP/UDP/RTP headers for Low-
Speed Serial Links", RFC 2508, February 1999.
http://www.ietf.org/rfc/rfc2508.txt
[14] Degermark, M., Nordgren, B. and S. Pink "Header Compression for IPv6", RFC
2507, February 1999.
http://www.ietf.org/rfc/rfc2507.txt
[15] Jacobson, V., "TCP / IP Compression for Low - Speed Serial Links", RFC 1144,
February 1999.
http://www.ietf.org/rfc/rfc1144.txt
[16] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport
Protocol for real-time applications", RFC 3550, July 2003.
http://www.ietf.org/rfc/rfc3550.txt

© EUROCAE, 2009
 108

[17] Koren, T., Casner, S., Geevarghese, J., Thompson, B., Ruddy, P, "Enhanced
Compressed RTP (CRTP) for links with high delay, packet loss and reordering",
RFC 3545, July 2003.
http://www.ietf.org/rfc/rfc3545.txt
[18] Bormann, C., Burmeister, C., Degemark, M., Fukushima, H., "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and
uncompressed" RFC 3095, July 2001.
http://www.ietf.org/rfc/rfc3095.txt
[19] Degermar, M., "Requirements for robust IP/UDP/RTP header compression",
RFC 3096, July 2001.
http://www.ietf.org/rfc/rfc3096.txt
[20] Ertekin E., Chistou, C., Hamiltob, B., "IPv6 Header Compression", North
American IPv6 Summit, June 2004.
[21] IP Telephony Design Guide; Alcatel
www.alcatel.com
[22] IETF RFC 1890;RTP Profile for Audio and Video Conferences with Minimal
Control; Henning Schulzrinne
http://www.ietf.org/rfc/rfc1890.txt
[23] ITU-T Recommendation G.729; Coding of speech at 8 kbit/s using conjugate-
structure algebraic-code-excited linear-prediction (CS-ACELP)
http://www.itu.int/home/index.html
[24] ITU-T Recommendation G.726; 40, 32, 24, 16 kbit/s adaptive differential pulse
code modulation (ADPCM)
http://www.itu.int/home/index.html
[25] Voice over IP (VoIP);
Angus Ma (B.Eng., M.Eng., M.B.A.)
[26] IEPM Home Page; Internet End-to-end Performance Monitoring
http://www-iepm.slac.stanford.edu/
[27] VoIP Networking Design; Tim Danford
www.cisco.com
[28] IEEE 802.3; CSMA/CD Access Method; Ethernet
http://standards.ieee.org/getieee802/
[29] NIST Security Considerations for Voice Over IP Systems;
D. Richard Kuhn, Thomas J. Walsh, Steffen Fries
[30] C-N. Chuah, “Providing End-to-End QoS for IP based Latency sensitive
Applications”; Technical Report, Dept. of Electrical Engineering and Computer
Science, University of California at Berkeley, 2000.
[31] W.C. Hardy, VOIP Service Quality: Measuring and Evaluating Packet-Switched
Voice, McGraw-Hill, 2003.
[32] ITU-T Recommendation G.114 (05/00); One-way transmission time;
http://www.itu.int/home/index.html
[33] IETF RFC 3550; RTP Profile : A Transport Protocol for Real-Time Applications
http://www.ietf.org/rfc/rfc3550.txt
[34] IETF RFC 3611; RTP Control Protocol Extended Reports (RTCP XR)
http://www.ietf.org/rfc/rfc3611.txt
[35] ITU-T Recommendation G.711; Pulse code modulation (PCM) of voice
frequencies
http://www.itu.int/home/index.html

© EUROCAE, 2009
 109

[36] Computer Networking: A Top Down Approach Featuring the Internet, 3rd
edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2004
[37] IETF RFC 2211; Specification of the Controlled-Load Network Element Service
http://www.ietf.org/rfc/rfc2211.txt
[38] IETF RFC 2212; Specification of Guaranteed Quality of Service
http://www.ietf.org/rfc/rfc2212.txt
[39] IETF RFC 2205; Resource ReSerVation Protocol (RSVP), Version 1 Functional
Specification
http://www.ietf.org/rfc/rfc2205.txt
[40] C. Partridge. Gigabit Networking. Addison Wesley, Reading, MA, USA, 1994.
[41] S. Vegesna, IP Quality of Service: The Complete Resource for Understanding
and Deploying IP Quality of Service for Cisco Networks, Cisco Press,
Indianapolis, USA, 2001
[42] IETF RFC 2474; Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers
http://www.ietf.org/rfc/rfc2474.txt
[43] IETF RFC 2475; An Architecture for Differentiated Services
http://www.ietf.org/rfc/rfc2475.txt
[44] IETF RFC 1349; Type of Service in the Internet Protocol Suite
http://www.ietf.org/rfc/rfc1349.txt
[45] IETF RFC 2597; Assured Forwarding PHB Group
http://www.ietf.org/rfc/rfc2597.txt
[46] IETF RFC 2598; An Expedited Forwarding PHB
http://www.ietf.org/rfc/rfc2598.txt
[47] Cisco Systems; DiffServ -- The Scalable End-to-End QoS Model
http://www.cisco.com/en/US/tech/tk543/tk766/technologies_white_paper09186a00800
a3e2f.shtml
[48] Yee-Ting Li Homepage, High Energy Physics Group, London
http://www.hep.ucl.ac.uk/~ytl/index.html
[49] Multiprotocol Label Switching (MPLS) Charter (Internet Drafts and RFC’s)
http://www.ietf.org/html.charters/mpls-charter.html
[50] IETF RFC 2702; Requirements for Traffic Engineering Over MPLS
http://www.ietf.org/rfc/rfc2702.txt
[51] IETF RFC 3031; MPLS Architecture
http://www.ietf.org/rfc/rfc3031.txt
[52] IETF RFC 3032; MPLS Label Stack Encoding
http://www.ietf.org/rfc/rfc3032.txt
[53] IETF RFC 3036; LDP Specification
http://www.ietf.org/rfc/rfc3036.txt
[54] Nortel Solutions: Multiprotocol Label Switching (MPLS)
http://www.nortel.com/solutions/providers/enabling_tech/mpls/index.html
[55] The MPLS Resource Center
http://www.mplsrc.com/
[56] IETF RFC 3209; RSVP-TE: Extensions to RSVP for LSP Tunnels
http://www.ietf.org/rfc/rfc3209.txt

© EUROCAE, 2009
 110

[57] IETF RFC 3214; LSP Modification Using CR-LDP

http://www.ietf.org/rfc/rfc3214.txt
[58] IETF RFC 4090; Fast Reroute Extensions to RSVP-TE for LSP Tunnels
http://www.ietf.org/rfc/rfc4090.txt
[59] Layer 2 Virtual Private Networks (l2vpn)
http://www.ietf.org/html.charters/l2vpn-charter.html
[60] Virtual Private LAN Services over MPLS
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-07.txt
[61] VPLS.ORG - Central Source for VPLS News and Technology
http://www.vpls.org/index.shtml
[62] IETF RFC 2814; SBM (Subnet Bandwidth Manager): A Protocol for RSVP-
based Admission Control over IEEE 802-style networks
http://www.ietf.org/rfc/rfc2814.txt
[63] IEEE 802.1Q, IEEE Standards for Local and Metropolitan Area Networks:
Virtual Bridged Local Area Networks
http://standards.ieee.org/catalog/olis/lanman.html
[64] IEEE 802.1D, IEEE Standards for Local and Metropolitan Area Networks: Media
access control (MAC) Bridges
http://standards.ieee.org/catalog/olis/lanman.html
[65] IEEE 802.1p - Traffic Class Expediting and Dynamic Multicast Filtering
(published in 802.1D-1998)
http://standards.ieee.org/catalog/olis/lanman.html
[66] Quality of Service: Delivering QoS in the Internet and the Corporate Network
http://www.wiley.com/legacy/compbooks/ferguson/
[67] Cisco Systems; Quality of Service Networking
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm
[68] Traffic Scheduling in Packet-Switched Networks
http://www.cse.ucsc.edu/research/hsnlab/projects/scheduling.html
[69] References on CBQ (Class-Based Queuing)
http://ftp.ee.lbl.gov/floyd/cbq.html

© EUROCAE, 2009
 111

CHAPTER V

MULTICAST CONSIDERATIONS

5.1 INTRODUCTION

With the growing of IP networks all around the world, diffusion of information over IP
becomes more and more a reality. The diffusion is achieved in effective way with the
help of IP multicast, which is the unavoidable solution. A lot of work has been done to
improve protocols supporting IP multicast and this is the purpose of this chapter to
discuss about them.
As far as VoIP in Air Traffic Management is concerned, it is expected that IP multicast
will be used for radio reception diffusion and perhaps furthermore for telephone
conference and recording.

5.2 BACKGROUND & SCOPE

Multicast architecture is based on specific protocols. These protocols permit, first the
receiver of the flow to join a multicast group, and secondly, to route multicast flows
from the sources to the receivers.
Multicast routing protocols use the unicast routing tables, result of static routing or of
the current running unicast routing protocols. Nevertheless, the unicast routing
protocols are out of the scope of this chapter.
In this document are summarized the different available solutions and protocols for
multicast flows and their capabilities to meet VoIP ATM requirements. This is done for
both IPv4 and IPv6.
In addition some topology recommendations are given in order to obtain an optimised
and efficient network for multicast.
This document assumes that the reader has already some knowledge on multicast
architectures and focuses on the capabilities of multicast solution to fulfil VoIP ATM
voice flows requirements.

5.3 INTRA-DOMAIN MULTICAST SOLUTIONS FOR IPV4

5.3.1 Multicast protocols overview

Three protocol families are used in IPv4 for multicast: IGMP, PIM and Rendez-vous
point election/management protocols.

5.3.1.1 IGMP

IGMP (Internet Group Management Protocol) defines how hosts tell the routers about
their group membership.
One of the routers connected to the LAN is elected as the “Querier” and transmits
IGMP membership queries on the LAN. Other routers “listen” to IGMP messages and
register corresponding information.
If the current Querier fails, the election process permits another router to take the role
of the Querier. The recovery time with default IGMP timers values can take few tens of
seconds, but IGMP timer values can be tuned in order not to have impact on multicast
flows during switchover.
This means that Querier redundancy is not an issue if the design is done in order to
have 2 components per LAN being able to take the role of the Querier.

© EUROCAE, 2009
 112

5.3.1.2 PIM

Although a number of protocols such as CBT (Core Based Tree), DVMRP (Distance
Vector Multicast Routing Protocol), etc… exists for building multicast tree among all
receivers and sources in the same administrative domain, PIM is the most widely used
protocol.
PIM (Protocol Independent Multicast) is based on the unicast routing tables and has
four modes allowing different multicast architecture solutions tuned for each type of
multicast flows.
PIM architecture is based on 4 key components: the Rendez-vous point (RP), the
Designated Router (DR), the Single Forwarder (SF which can be elected by Assert
function) and the Designated Forwarder (DF). Some components may not be used
depending on the active mode of PIM.
The PIM modes are PIM-Dense Mode (PIM-DM), PIM-Sparse Mode (PIM-SM), PIM-
Source Specific Multicast (PIM-SSM) and Bidirectional-PIM (Bidir-PIM).
PIM-Dense Mode has major drawbacks. So it is no more discussed in the § 5.3.1.
The RP is used by PIM-SM and Bidir-PIM. In PIM-SM, it is the senders and receivers
rendez-vous at this point to learn of each others existence. In Bidir-PIM, the RP acts
as a focal point for all flows.
The DR is used in PIM-SM and PIM-SSM. It is located on source and receivers LANs.
In PIM-SM, it is responsible for sending triggered join/prune and register messages
towards the RP. In addition, for both modes, it forwards multicast flows from the
source to the network and from the network towards receivers.
In case of multi-access transit LANs, only one router is allowed to forward a multicast
flow on the LAN. This router is the SF. In the event where it happens that the same
multicast flow is forwarded by different routers, PIM Assert function is used to elect
which router will continue to forward the multicast flow. The Assert function can be
involved for both PIM-DM and PIM-SM (switch-over to SPT) modes. For PIM-SSM
and Bidir-PIM, it is not possible to have the case where 2 routers are forwarding
multicast flow on a LAN at the same time and so the assert function is never involved.
The DF is used in Bidir-PIM. It is the router on the LAN which offers the best path to
the RP.
PIM includes mechanisms in order to recover from DR, SF or DF failure:
• PIM hello messages are used by peer neighbours to detect a DR failure. If no
hello messages are received during 3 times hello period, a new DR will be
elected. The default value of hello period can be decreased reasonably till 1
second which will give a recovery time of 3 seconds. CISCO IOS proprietary
function offers the possibility to decrease on DR, the hello period till 100 ms
which leads to a recovery time of 300 ms for a DR failure.
• PIM hello messages and Assert messages are used by peer neighbours to
detect the SF failure. If no hello messages are received before Neighbour
Liveness Timer expires another router will become the SF. If no Assert
messages are received before Assert timer expires, another router will become
the SF. With a hello period of 1 second, Neighbour Liveness Timer = 3.5 and
hello period = 3.5 seconds. Default value of Assert timer is 180 seconds and
cannot be modified. This means that, if Assert function is used to recover from a
failure, the recovery time can take till 3 minutes.
• PIM hello messages and MRIB (Multicast Routing Information Base) RPF
(Reverse Path Forwarding) changes at downstream router are used to detect a
DF failure. If there is a downstream router, the switchover to a redundant router
in case of a failure, is done in a very short time. In all of other cases, this is the
Neighbour Liveness Timer which is used i.e 3.5 seconds.

© EUROCAE, 2009
 113

One should be aware that in all cases, unicast routing recovery time has to be added
to PIM recovery time. The overall recovery time value obtained can be either a sub-
second one or much more higher depending on the network topology.

5.3.1.3 Rendez-vous point election/management

Few standard and non-standard protocols exist for the election/management of the
rendez-vous point, which are:
• Auto RP,
• PIM BSR,
• Static RP,
• Anycast-RP.
They are discussed later in this document.

5.3.1.4 Generic architecture presentation

As a summary, the following figures describe general multicast architecture for each
PIM mode. The architectures presented are not necessarily “realistic”, but the
objective is to show the location of each key component.

PIM-SM architecture

SF DR, Q
DR SF RP A A
A A SF SF
A
Receiver
Sender
B
Q B
B B
B

Source tree A Forwarding router

Shared tree
Shortest path (source) tree B Non forwarding router

Q: Querier, IGMP component DR, SF, RP: PIM components

FIGURE 54 : PIM-SM ARCHITECTURE

© EUROCAE, 2009
 114

PIM-SSM architecture

DR SF DR
A A A A

Receiver
Sender

Q Q
B B B B

Shortest path (source) tree A Forwarding router

Q: Querier, IGMP component
DR, SF: PIM components
B Non forwarding router

FIGURE 55 : PIM-SSM ARCHITECTURE

Bidir-PIM-architecture

RP

DF DF DF DF, Q
A A
A A

Receiver
Sender

Q B
B B
B

Shared tree A Forwarding router

Q: Querier, IGMP component B Non forwarding router

DF, RP: PIM components

Note: RP could only be an address on the Rendez-vous point link

FIGURE 56 : BIDIR-PIM ARCHITECTURE

It should be noted that IGMP and PIM component roles can be played by different
routers or by the same router.

© EUROCAE, 2009
 115

5.3.2 Multicast flow types

The multicast flows are divided into five categories. Each of them has specificities
which require different design of the network to meet efficiency.
These are:
• One-to-many: video, TV, radio,
• Few-to-few: small (<10 members) audio/video conferences,
• Few-to-many: TIBCO RV servers (publishing),
• Many-to-many: stock trading floor, gaming,
• Many-to-few applications: TIBCO RV Clients (subscriptions).

5.3.3 Multicast protocols comparison

5.3.3.1 PIM

PIM provides four different modes. Some of them have been standardized few year
ago whereas, others are still under IETF process.
The following table gives an overview of PIM modes for VoIP in ATM:

© EUROCAE, 2009
 116

Protocol Standard Description Pros/Cons Type of flow

name
PIM-DM RFC 3973 PIM-Dense Mode Bad mode : Don’t use it
- cut of the flow during prune time out i.e. till
3mn
- can generate loops inside the network
- use a lot of memory and CPU as it will
create an (S,G) entry for every active
Source / Group in every router in the
network at all times
PIM-SM RFC 2362 + PIM-Sparse Mode: Pros: One-to-many
Draft-ietf- - support both source tree - traffic sent down on “joined” branches only
pim-sm-v2- and shared tree - basis for inter-domain multicast routing Few-to-few
new-11 - use a RP, DR and SF Cons: Few-to-many
- Shortest Path Tree - non optimized path for voice flows with
(SPT) switchover shared tree
- redundancy of the RP (recovery time)
- redundancy of the DR and SF (recovery
time)
- jitter when switchover to SPT (compatible
with voice flow requirement ?)
PIM-SSM RFC 3569 + PIM-Source Specific Pros: One-to-many
Draft-ietf- Multicast - optimized path which can help to have Few-to-few
pim-sm-v2- - use only source tree optimized delay,
new-11 - no RP - no problem of redundancy with RP
- use of DR and SF - no use of assert function
- host responsible for Cons:
source discovery - need out of band mechanism to get source
IP address
- redundancy of DR and SF (recovery time)
- need IGMPv3 or some migration
technology in the receivers or at receivers
DR (CISCO DR offers proprietary
mechanism when IGMPv2 is used)
Bidir-PIM Draft-ietf- Bidirectional PIM Pros: Many-to-few
pim-bidir-07 - less states on the routers (save router’s Many-to-many
- shared tree only CPU loading and memory)
- use the same tree for Cons:
traffic from source to RP - non optimized delay for voice flows with
and from RP to receivers. shared tree
The RP can be virtual and - redundancy of DFs and RP if any RP
represented by an IP (recovery time)
address. - need a way to monitor active sources.
- requires DFs Since no source state is created there is no
easy way to perform trouble shooting for
badly behaved sources. NFv9 on CISCO
routers solves this problem.
TABLE 17 - COMPARISON OF PIM MODES

© EUROCAE, 2009
 117

5.3.4 Rendez-vous point election/management

Four Rendez-vous point election/management protocols exist in IPv4. They are

discussed in the following table:

Protocol name Standard Description Pros/Cons

Auto-RP Cisco - All routers learn automatically RP address Cons:
- Mapping Agent (MA) receives RP and MA back up time out of the
announcement from Candidate RP (C-RP), scope of ATM needs
- Make use of multicast to distribute info, PIM Dense Mode needed to distribute
- Permit back up of RP, the RP-announce and RP-discover
- can be used with Admin-Scoping groups. This creates the potential for
DM Fallback to occur
PIM BSR RFC 2362 - a BootStrap Router (BSR) is elected, Cons:
+ Draft-ietf- - BSR receives Candidate RP (C-RP) RP and BSR back up time out of the
pim-sm-v2- messages and store the information to scope of ATM needs
new-11 Group-to-RP mapping cache,
+ Draft-ietf- - BSR sends the Group-to-RP mapping
pim-sm-bsr- cache to all C-RPs,
05 - All C-RPs execute the same algorithm and
decide which C-RP is the RP
- Draft-ietf-pim-sm-bsr-05: specifies a way to
implement admin-scoping
Static RP N/A Hard coded RP address Cons:
No RP back up
Anycast-RP RFC 3446 - within a domain deploy more than one RP Pros:
for the same multicast group range - RP back up possible
- give each RP the same IP address - RP recovery time is based on unicast
assignment protocol recovery time
- sources and receivers use closest RP Cons:
- use MSDP (Multicast Source Discovery - distribution of RP address: static or
Protocol) to communicate existence of Auto-RP can be used for this
sources between RPs
- compatible with admin-scoping
TABLE 18 - COMPARISON OF RP ELECTION/MANAGEMENT

5.3.5 IGMP

Three versions of IGMP are existing. The following table gives an overview of IGMP
for VoIP in ATM:
Protocol name Standard Description Used by
IGMPv1 RFC 1112 Superseded by
IGMPv2
IGMPv2 RFC 2236 Backward compatible with IGMPv1 PIM-DM, PIM-SM,
Bidir-PIM
“Join (*,G)” based protocol
Introduction of the leave group message to be more
efficient
IGMPv3 RFC 3376 New feature: include/exclude source list PIM-SSM
“Join (S,G)” based protocol
Requires new “IPMulticastListen API”
New IGMPv3 stack required in the OS
Start to be implemented
TABLE 19 - COMPARISON OF IGMP

© EUROCAE, 2009
 118

5.4 INTRA-DOMAIN MULTICAST SOLUTIONS FOR IPV6

5.4.1 Multicast protocols overview

Multicast architecture in IPv6 is based on the same solutions as in IPv4. PIM and
Rendez-vous point election/management protocols are still existing while IGMP is
replaced by MLD (Multicast Listener Discover).
The following table summarizes IPv6 situation:
IP multicast IPv4 IPv6 IPv6 standard
service
Group IGMPv1 No equivalent -
management IGMPv2 MLDv1 RFC 2710
IGMPv3 MLDv2 RFC 3810
Multicast routing PIM-DM Will never exist -
protocols PIM-SM PIM-SM RFC 2362
+ Draft-ietf-pim-sm-v2-new-11
PIM-SSM PIM-SSM requires MLDv2 RFC 3569 + Draft-ietf-pim-sm-
v2-new-11
Bidir-PIM Bidir-PIM Draft-ietf-pim-bidir-07
RP Auto RP No study on it -
election/manage PIM BSR PIM BSR RFC 2362
ment + Draft-ietf-pim-sm-v2-new-11
+ Draft-ietf-pim-sm-bsr-05
Static RP Static RP -
Anycast RPs Under study -
- Embedded RP: RFC 3956 and subset of RFC
– no RP redundancy, 3306
– not supported by Bidir-PIM
TABLE 20 - MULTICAST FOR IPV6

As shown by the here upper table, rendez-vous point redundancy issues are not
finalized yet for IPv6. At the moment, there are no protocols able to meet VoIP ATM
needs.

5.5 DESIGN CONSIDERATIONS

5.5.1 Unwanted flooding

Multicast flows can easily be flooded to unwanted host and router ports. This may lead
to an overload of hosts and network equipment for nothing. In order to avoid such a
situation the following rules should be applied:
• Use of IGMP snooping (IPv4) and MLD snooping (IPv6) on layer 3 switches for
host networks. In addition CISCO CGMP can be used instead of IGMP
snooping,
• Use of PIM snooping (IPv4/IPv6) on core network. In addition CISCO RGMP
can be used instead of PIM snooping,
• Dissociation of flows with the use of point-to-point VLANs in core network.
“Snooping” functions are proprietary functions and in the case of a failure, recovery
time to get back the multicast flow is network equipment implementation dependant.
Furthermore, it is not recommended to use at the same time both IGMP Snooping and
Spanning Tree (or any of its variants) for fast multicast convergence. In a L2 network,
the multicast "tree" depends on the Spanning Tree. In case of a Spanning Tree
topology change, re-convergence time is not deterministic and in addition, IGMP
snooping can be obliged to flood multicast traffic till next IGMP query cycle.

© EUROCAE, 2009
 119

5.5.2 Domain control

Domain control concerns:

• RP domains where RP control mechanism messages have to be constrained.
• Limitation on the domain where multicast data flow is allowed to go.
Bidir-PIM and PIM-SM are concerned by both RP domain issues and multicast data
flow diffusion control.
PIM-SSM is only concerned by multicast data flow diffusion control.
The domain control is achieved by the use of routers, configured as border (for
example, use of multicast boundaries or access lists), and also by using “Admin-
scoping” facility.

5.5.3 Inter-domain communication

In IPv4, inter-domain communication can be implemented with MBGP/PIM-SSM or

MBGP/MSDP/PIM-SM.
In IPv6, inter-domain communication can be implemented with MBGP/PIM-SSM or
MBGP/Embedded RP. In the later case, it is not possible to have a redundant RP.
Bidir-PIM can only be used inside one domain.
MBGP is not designed to be a very rapidly convergent protocol with the emphasis
being on stability rather than convergence. In general terms we expect MBGP
reconvergence to occur in a timescale of an order of minutes rather than seconds.
For critical flows which request fast switchover, MBGP will not be applicable and it will
not be possible to implement inter-domain communication with those types of flow.

5.5.4 Coexistence of different PIM modes on the same network topology

In order to be able to map different PIM modes on the same network topology, specific
address ranges in IPv4 and IPv6 have been reserved for both PIM-SSM and Bidir-
PIM.
Depending on the address range, key PIM component and routers will apply the
corresponding PIM mode rules.

5.5.5 Convergence

Convergence time can be calculated with the following formula:

MCvg = T∆t + U∆t + N(RPF∆t + JP∆t)
• MCvg = Multicast Convergence Time
• T∆t = Topology Change Detection Time
• U∆t = Unicast Convergence Time
• N = Number of Multicast State Entries
• RPF∆t = Reverse Path Forward Calculation Time
• JP∆t = Join/Prune Processing Time

© EUROCAE, 2009
 120

As we can see, the topology change detection time is an important element for
convergence and particularly link failure detection. In order to have a fast link failure
detection it is recommended to use the following types of links between neighbour
routers:
• POS (Packet Over SDH),
• GBIC with BFD (Bidirectional Forwarding Detection – 50ms detection time),
• Other physical media: network equipment suppliers can propose solutions in
order to have a fast time failure detection. This is the case for CISCO who
recommends to use point to point links with “carrier-delay-msec” parameter set
to “0”
The loss of a neighbour router connected through these types of links will be detected
very fast by other routers thanks to the associated link signalling. As a consequence, it
is not necessary to tune PIM timers in this case.
The only critical case is the failure detection time of the DR on the LAN part of the
network which doesn’t provide link signalling between neighbour routers. In this case,
Hello Timer has to be tuned on the PIM routers connected to the LAN.
Layer 2 cores should be avoided as there is no link signalling between neighbour
routers and failure detection rely on PIM timers which cannot be tuned at the core
level.
Additional proprietary mechanisms can be added by equipment providers in order to
improve convergence.
About “carrier-delay-msec” parameter:
The “carrier-delay-msec” parameter allows link outages to be filtered and not reported
as a link down event if they occur before the carrier delay timer expires.
Setting “carrier-delay msec” to “0” turns off any delay in the report of “UP/DOWN”
transitions to interfaces. By doing that, it is recommended to implement the Cisco IP
Event Dampening functionality (refer to CHAPTER III for more information), to more
easily detect and react to rapidly flapping links.

5.6 CONCLUSION

IP multicast issues are not completely stable in IPv6 and work is still in progress at
IETF around RP redundancy mechanisms and Inter-domain communication. As for
example a new IETF draft (draft-ietf-pim-anycast-rp-03) has been edited in order to
define how Anycast RP can work inside a domain without MSDP.
Nevertheless, PIM-SSM seems to be the best PIM mode for VoIP ATM for the
following reasons:
• VoIP ATM flows belong to the one-to-many and few-to-few flow types, which
are the types of flow to which PIM-SSM can cope with,
• PIM-SSM ensures the best path inside network which can help for delay
optimization,
• There is no switch over from one multicast tree to another one, creating a path
rupture and as a consequence a “jitter step”,
• There is no RP and the corresponding redundancy issues, which involve
complex mechanisms and which are not stable yet in IPv6, have no more to be
addressed,
• DR and SF still require redundancy but with PIM-SSM and hello timer tuning,
this should not be any more an issue,
• It is possible to deploy another type of multicast architecture on the same
network topology; other PIM modes can be deployed for multicast flows which
are not VoIP ATM flows,

© EUROCAE, 2009
 121

• Its specifications are already stable in IPv6,

• PIM-SSM is more secured than other modes because the source is specified in
the join message and so other sources cannot flood. In addition, there is no RP
which a key component which can be the object of attacks.
PIM-SSM will require IGMPv3 or MLDv2 which is not widespread at the moment, but
we can assume that they will become widely available when VoIP ATM will be
deployed.
Inter-domain communications based on MBGP should have long convergence time in
order to have a stable network which is not compatible with VoIP for ATC needs.
In addition, network design should take into account the rules given in paragraph 5.5.
The content of this document is issued only from a “paper study”, so, it is highly
recommended:
• To define more application needs i.e. forwarding traffic and multicast states,
• To define the topology,
• To DO tests with a representative network of the deployment topology in order
to confirm assumptions made during design.

© EUROCAE, 2009
 122

APPENDIX A

ADDITIONAL QUESTIONS & ANSWERS

1) Is it possible to tune better PIM timers in order to obtain a better recovery time
for DR, SF and DF?
Answer: standards don’t offer the possibility to tune timer value. On CICO IOS,
Hello Timer value on DR can be decreased till 100 ms. This is the only timer
which can be modified because changing other timer value is too dangerous.
Another answer from CISCO about Assert function: We suggest designing
networks so as to never depend on the Assert function. Assert has numerous
corner cases where it can fail for up to 3 minutes. This is typically what happens
if the SF fails just after winning the Assert process. There are other corner
cases where the Assert function can have problems dealing with special
situations and thus we try to avoid Asserts.
By using PIM-SM instead of PIM-DM, you almost completely eliminate the use
of any Asserts. The only place that the Assert process can occur in PIM-SM is
the SPT-Switchover process. This can also be eliminated by the use of SSM or
Bidir which make use of SPT's only and Shared Trees only, respectively.
2) What overall recovery time failure can we expect with PIM + unicast routing
protocols?
Answer: the reconfiguration time value depends on network topology but with a
well designed network, sub-second value can be obtained.
3) Will it be necessary to have a domain control mechanism?
Answer: yes in order to avoid specific multicast traffic from entering or leaving
VoIP ATM domain.
4) In the case another mode than PIM-SSM is chosen for VoIP ATM, will it be
necessary to have Inter-domain communication?
Answer: inter-domain communication may be used for both PIM-SM and PIM-
SSM. The necessity to implement it depends on design:
- MBGP is needed if you are doing inter-domain multicast between
Autonomous Systems (AS) in the global internet,
- if PIM-SM domains are within the same AS (i.e. Internet is not used as a
transit network), then it is possible to do inter-domain multicast without
MBGP,
- BGP is often used in large private networks between OSPF domains for
scalability purposes. In that case, the use of MBGP “might” also be used
to provide noncongruent multicast/unicast routing between OSPF
domains.
5) What is the recovery time value for RP with Anycast-RP? Is-it really the unicast
routing protocol recovery time? Is there no extra delay? Even if Anycast-RP is
not available for IPv6, it could be helpful to have the value for IPv4 in order to
extrapolate to what can be obtained in IPv6 in very next future.
Answer: recovery time = routing reconfiguration time + IGMP joins time.
Moreover, the failure of the RP has an impact on “new comers” for which there
is not an established flow but not on established flows which are not crossing
RP router.

© EUROCAE, 2009
 123

6) How inter-domain communication is achieved in IPv4 and IPv6? Is, what is

stated in the working paper, the real situation?
Answer: No. In IPv4: MBGP/PIM-SSM or MBGP/MSDP/PIM-SM can be used.
In IPv6 MBGP/PIM-SSM or MBGP/Embedded RP can be used.
7) What is the CISCO equipment recovery time failure for IGMP snooping and PIM
snooping ? It could be helpful to know what CISCO equipment is capable to
achieve in order to determine whether or not IGMP snooping and PIM snooping
are usable in VoIP ATM environment.
Answer: depends on topology. Lab tests should be done with the chosen
topology. IGMP snooping and spanning tree protocols should not be used at the
same time. IGMP snooping is necessary to save switching power or link
bandwidth in case of very important multicast flows.
8) Specific address ranges in IPv4 and IPv6 have been reserved for both PIM-
SSM and Bidir-PIM. Depending on the address range, key PIM component and
routers will apply the corresponding PIM mode rules. Is this already
implemented in network component and particularly in CISCO equipment ?
Answer: this is implemented for PIM-SM and PIM-SSM .
9) What convergence time can we expect from MBGP (new question asked to
CISCO following 9th EUROCAE WG67 meeting of July 2005) ?
Answer: MBGP is not designed to be a very rapidly convergent protocol with the
emphasis being on stability rather than convergence. In general terms we
expect MBGP reconvergence to occur in a timescale of an order of minutes
rather than seconds
10) why don't you recommend to use IGMP snooping with RSTP ? (new question
asked to CISCO following 9th EUROCAE WG67 meeting of July 2005) ?
Answer from CISCO: Cisco does not promote IGMP Snooping and Spanning
Tree (or any of its variants) for fast multicast convergence. We recommend the
deployment L3 devices (routers running PIM-SM) to deal with topology
changes. This is because it is only at L3 that there is any direct tree building
protocol.
In a L2 network, the multicast "tree" depends on the Spanning Tree.
Subsequently IGMP Snooping must "listen in" on the conversation between
host and router to build multicast forwarding state.
Any changes in Spanning Tree topology are signalled by "Topology Change"
flags in the switch which requires IGMP Snooping to re-establish multicast
forwarding state. In a worst case scenario, an IGMP Snooping Switch may
have to flood traffic out of all ports until the next IGMP Query cycle establishes
receiver locations.
There is no standard for IGMP Snooping. Its implementation differs even
between different Cisco switches due to differences in hardware architectures.
Thus the exact convergence numbers are:
1) Non-deterministic
2) Platform dependant
The only way to really obtain the numbers you seek is to build the specific
topology in a lab with the specific switches and test the convergence
times. However, even these numbers vary due to real-world network
condition of traffic load, spanning tree configuration, etc.
Given all of this and the fact that spanning tree is a rather archaic
technology and often causes more problems than it solves) an excellent
philosophy is "No VLAN should ever leave a box except via a router
connection." This way there is no Spanning Tree to interfere with
multicast tree building mechanisms based on PIM-SM signalling.

© EUROCAE, 2009
 124

Finally, note that we used to build networks at L2 because we could

switch packets at that level much faster than we could at L3. However,
we can now switch packets at L3 just as fast as we can at L2.
Hence, there is very little need for Spanning Tree in modern networks.

© EUROCAE, 2009
 125

APPENDIX B

ACRONYMS

A
ATM - Air Traffic Management
B
Bidir-PIM - Bidirectional Protocol Independent Multicast
BSR - BootStrap Router
C
CBT - Core Based Tree
CGMP - Cisco Group Management Protocol
C-RP - Candidate Rendez-vous Point
D
DF - Designated Forwarder
DR - Designated Router
DVMRP - Distance Vector Multicast Routing Protocol
I
IGMP - Internet Group Management Protocol
M
MA - Mapping Agent
MLD - Multicast Listener Discover
MRIB - Multicast Routing Information Base
MSDP - Multicast Source Discovery Protocol
P
PIM - Protocol Independent Multicast
PIM BSR - Protocol Independent Multicast BootStrap Router
PIM-DM - Protocol Independent Multicast Dense Mode
PIM-SM - Protocol Independent Multicast Sparse Mode
PIM-SSM - Protocol Independent Multicast Source Specific Multicast
Q
Q - Querier
R
RP - Rendez-vous Point
RPF - Reverse Path Forwarding
S
SF - Single Forwarder
SPT - Shortest Path Tree
V
VoIP - Voice over IP

© EUROCAE, 2009
 126

APPENDIX C

CONFERENCE CALL RECOMMENDATION (NETWORK POINT OF VIEW)

Concept Logical view Pro’s Con’s

‚simple Many traffic
concecpt’
Unicast
CWP (only Costs
unicast is
used)

Delay
Unicast
Mixer efficient

1 ‚simple More Delay

CWP concept’
SIP UA (only More
unicast is Traffic
Conference 2+3 used) (increases
Unit 1 risk of
congestion)
2
CWP
1+3
Mixer SIP UA
2

1+2

3 3
CWP
SIP UA

Delay Complexity
efficient
Unicast
CWP Multicast
Traffic involve
efficient additional
routing and
(Path protocols
Multicast
Mixer efficient)

Conclusion:
Using last concept with Multicast is most efficient for the network (but might not be the
best for application design).

© EUROCAE, 2009
 127

CHAPTER V REFERENCES

[1] IETF RFC 1112: Host extensions for IP multicasting (IGMPv1), Aug-01-1989,
status: standard
http://www.ietf.org/rfc/rfc1112.txt
[2] IETF RFC 2236: Internet Group Management Protocol, Version 2, November
1997, status: proposed standard
http://www.ietf.org/rfc/rfc2236.txt
[3] IETF RFC 2362: Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification, June 1998, status: experimental
http://www.ietf.org/rfc/rfc2362.txt
[4] IETF RFC 2365: Administratively Scoped IP Multicast, July 1998, status: best
current practice
http://www.ietf.org/rfc/rfc2365.txt
[5] IETF RFC 2710: Multicast Listener Discovery (MLD) for IPv6 (MLDv1), October
1999, status: proposed standard
http://www.ietf.org/rfc/rfc2710.txt
[6] IETF RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses, August 2002,
status: proposed standard
http://www.ietf.org/rfc/rfc3306.txt
[7] IETF RFC 3376: Internet Group Management Protocol, Version, October 2002,
status: proposed standard
http://www.ietf.org/rfc/rfc3376.txt
[8] IETF RFC 3446: Anycast Rendevous Point (RP) mechanism using Protocol
Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP),
January 2003, status: informational
http://www.ietf.org/rfc/rfc3446.txt
[9] IETF RFC 3569: An Overview of Source-Specific Multicast (SSM), July 2003,
status: informational
http://www.ietf.org/rfc/rfc3569.txt
[10] IETF RFC 3810: Multicast Listener Discovery Version 2 (MLDv2) for IPv6, June
2004, status: proposed standard
http://www.ietf.org/rfc/rfc3810.txt
[11] IETF RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6
Multicast address, November 2004, status: proposed standard
http://www.ietf.org/rfc/rfc3956.txt
[12] IETF RFC 3973: Protocol Independent Multicast - Dense Mode (PIM-DM):
Protocol Specification, January 2005, status: experimental
http://www.ietf.org/rfc/rfc3973.txt
[13] IETF Draft-ietf-pim-sm-v2-new-11: Protocol Independent Multicast - Sparse
Mode (PIM-SM): Protocol Specification (Revised), October 2004, status: active,
state: In Last Call
[14] IETF Draft-ietf-pim-sm-bsr-05: Bootstrap Router (BSR) Mechanism for PIM,
February 2005, status: active, state: ID Exists

© EUROCAE, 2009
 128

[15] IETF Draft-ietf-pim-bidir-07: Bi-directional Protocol Independent Multicast

(BIDIR-PIM), July 2004, status: active, state: AD is watching
[16] IETF Draft-ietf-pim-anycast-rp-03: Anycast-RP using PIM, April 2005, status:
active, state: AD Evaluation
[17] IETF Draft-ietf-bfd-base-03: Bidirectional Forwarding Detection, July 2005,
status: active, state: ID exists
[18] Fundamentals of IP Multicast, Cisco Networkers Presentations, 2004
[19] IPv6, Cisco Networkers Presentations, 2004
[20] Multicast Convergence, Cisco Networkers Presentations, 2004

© EUROCAE, 2009
 129

CHAPTER VI

IP ADDRESSING

6.1 INTRODUCTION

Network addressing is embedded in IP packets to enable their routing to intermediate

or end systems (e.g., servers or telephones). The format of this addressing is
dependent on the version of IP being used (i.e., IPv4 [1] or IPv6 [1], [3]), which are
described below.

6.2 IPv4 OVERVIEW

IPv4 addresses are used to identify device interfaces to hosts, routers, gateways,
adapters, and IPv4 telephones. Each device interface in an IPv4 network must be
assigned to a unique IPv4 address to receive or transmit voice and data packets.
IPv4 uses 32-bit binary numbers to identify the source and destination address in each
information packet. IPv4 addresses are parsed into two portions - Network and Host.
The predominance of one portion over the other within the 32-bit space determines
the Address Class. Those classes are referred to as Class A through Class E [1].
Please see information about CIDR Address Allocation Architecture in [2].
Figure 57 illustrates the five IPv4 address class formats.

32 bits
0 Byte 2 Byte 3 Byte 4
Class A Byte 1 Host portion
Network portion

1 0
Class B Networking portion Host portion

1 1 0
Class C Networking portion Host portion

1 1 1 0
Class D Multicast address

1 1 1 1 Byte Byte 2 Byte 3 Byte 4

1
Class E Experimental
FIGURE 57: IPv4 ADDRESSING FORMAT

Class A frames are identified by a 0 value high order bit. They provide 7 bits for the
network portion of the address, and 24 bits for the host. Class A addresses were
allocated at the initial deployment of the Internet, and are primarily held by North
American government agencies, and legacy companies that were involved in early
Internet research and development.

© EUROCAE, 2009
 130

Class B frames are identified with the two high order bits set to 10. These addresses
are typically allocated to Internet Service Providers (ISP) and large organizations.
Class C frames are identified with the three high order bits set to 110. Each of these
addresses can support up to 256 hosts. These addresses are typically allocated to
LAN and WAN nodes.

NOTE: Class A, B, and C addresses are assigned by the InterNIC to ISPs, from
which they assign addresses to their customers.

Class D addresses are identified by the four high order bits set to 1110. These
addresses are used for multi-casting applications, where voice and data packets can
be sent to groups of multiple nodes concurrently. These groups are pre-defined in the
network topology by aggregation of node addresses. Multicasting enables efficient
transmission of high-bandwidth payloads by minimizing multiple streams of voice and
data to individual nodes.
Class E addresses are identified by the four high order bits set to 1111. This address
space is reserved for experimental research.
Table 21 shows the numeric ranges and decimal equivalents.
Class Length of network Address number range
address (bits) (decimal)
A 8 0 – 127
B 16 128 - 191
C 24 192 - 223
TABLE 21 - NUMERIC RANGES

Private Internet [7] defines address allocation, which can be used for VoIP ATM.
Some consideration should take place, security and address conflicts, because of the
different addressing blocks is used by different organizations. Also firewall that
provides addresses translations between a numbers of Private Internet address.

6.3 IPv6 OVERVIEW

IPv6 [1], [4], [5], [9], [12] features a much larger addressing space than IPv4, as
shown in Figure 58. This enables an ISP or enterprise organization to aggregate the
prefixes of node or user groups (e.g., customers, or internal users) under a single
Network Prefix for advertisement on the IPv6 Internet.
XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX

Network Prefix Interface ID

FIGURE 58: IPv6 ADDRESSING FORMAT

XXXX = 0000 through FFFF, while X is a 4-bit hexadecimal value.

The 128-bit IPv6 address is separated into eight 16-bit hexadecimal numbers. In order
to alleviate the cumbersome size of these addresses, the IPv6 community has
developed the following notational shorthand:
• Leading “0”s can be removed
• 0000 = 0 (compressed form)
• “::” represent one or more groups of 16-bits, “0”can only appear once in an
address. For example, 2001:0:13FF:09FF:0:0:0:0001 = 2001:0:13FF:09FF::1
• The lower four 8-bits can use decimal representation of IPv4 address for
example, 0:0:0:0:0:0:192.168.0.1

© EUROCAE, 2009
 131

IPv6 addressing encompasses the following types:

• Unicast [6] – used to identify a single interface. Unicast supports the following
address types: Global Unicast Address, Site – Local Unicast address, and Link
– Local Unicast address as illustrated in Figure 59
001 Global routing Prefix Subnet ID Interface ID
(3- (45 - bits) (16 - bits) (64 - bits)
bits)
Global Unicast Address Format

1111111011 Subnet ID
or Set value to Site Link Interface ID
FEC0::10 “0” add (16- (64 – bits)
(10 - bits) (38 – bits) bits)
Site – Local Unicast Address Format

1111111010
or Set value to “0” Interface ID
FE80::10 (54 – bits) (64 – bits)
(10 - bits)
Link – Local Unicast Address format
FIGURE 59 : TYPE OF UNICAST ADDRESSING FORMAT

Table 22 illustrates IPv6 main addressing type.

Allocation Prefix Function of Address
Space
Global Unicast Addresses 001 1/8

Link Local Addresses 1111 1110 10 1/1024

Site Local Addresses 1111 1110 11 1/1024

Multicast Addresses 1111 1111 1/256

TABLE 22 : IPv6 MAIN ADDRESSING TYPE

• Anycast [9] – a global address that is assigned to a set of interfaces belonging

to different nodes. Anycast addresses have the following restrictions:
1. An Anycast address must not be used as a source address of an IPv6
packet
2. An Anycast address must not be assigned to an IPv6 host. It may be
assigned to an IPv6 router.
Figure 60 shows the anycast addressing format.
Subnet prefix 00000000000000000000

128 – Bits
FIGURE 60 : ANYCAST ADDRESSING FORMAT

© EUROCAE, 2009
 132

Within each subnet, the highest 128 interface identifier values are reserved for
assignment as subnet anycast addresses. The construction of these addresses
depends upon the IPv6 address type used in the subnet, as indicated by the format
prefix of the address. In particular, IPv6 address types requiring 64 – bit interface
identifiers in Extended Unique Identifier-64 (EUI-64) format [14] are constructed as
depicted in Figure 61.
Subnet Prefix 111111X1111….111 Anycast ID
(64 – bits) (57- bits) (7 – bits)

FIGURE 61 : RESERVED SUBNET ANYCAST ADDRESS FORMAT WITH EUI-64 INTERFACE

IDENTIFIERS

X = “1” if EUI-64 Globally Administrated, and “0” if EUI-64 Locally Administrated.

• An IPv6 Address with Embedded IPv4 Address is used in transition techniques
when migrating IPv4 domains to IPv6, as shown in Figure 62. The 16 “X” bits
take a value of “0000” when assigned as a Unicast address to IPv6 nodes in an
IPv4 routing infrastructure, and is known as an “IPv4-compatible IPv6 address”.
The 16 “X” bits take a value of “FFFF” when used to represent IPv4 nodes in an
IPv6 address format, and is known as an “IPv4-mapped IPv6 address” [9].
0000………………………………….0000 XXXX IPv4 address
(80 – bits) (16-bits) (32 – bits)

FIGURE 62 : IPv6 WITH EMBEDDED IPV4 ADDRESS

• Multicast [9] is assigned to a set of interfaces that may belong to different

nodes. A packet sent to a multicast address is delivered to all interfaces
identified by that address. Its format is shown in Figure 63.
11111111 Flags (4-bits)
(8-bits) and Group ID (112 – bits)
Scope (4-bits)
FIGURE 63: MULTICAST ADDRESSING FORMAT

The leading 8 bits (“11111111”) identifies the address as being a multicast address.
“Flags” is a set of 4 bit, as configured below:
0 0 0 T

T = 0 indicates a permanently-assigned address by the Internet Assigned Number

Authority (IANA) [8].
T = 1 indicates a non-permanently-assigned (transient) multicast address.
Scope is a 4-bit field, used to limit the scope of the multicast group. The values are:
1 = Interface – local
2 = Link - local
3 = Subnet - local
4 = Admin - local
5 = Site - local
8 = Organization – local
E = Global

© EUROCAE, 2009
 133

Table 23 illustrates IPv4 concepts and their IPv6 equivalent [13].

IPv4 Address
Internet address classes
Addresses are 32 bits in length
Multicast address (224.0.0.0/4)
Broadcast addresses
Unspecified address is 0.0.0.0
Loop-back address is 127.0.0.1
Public IP addresses
Private IP addresses (10.0.0.0/8,
172.16.0.0/12, and 192.168.0.0/16)
Auto-configured address (169.254.0.0/16)
Text representation: Dotted decimal notation
Network bits representation: Subnet mask in
dotted decimal notation or prefix length
IPSec support is optional
TABLE 23 - IPv4 AND IPV6 EQUIVALENT
IPv6 Address
Not applicable in IPv6
Addresses are 128 bits in length
IPv6 multicast addresses (FF00::/8)
Not applicable in IPv6
Unspecified address is ::
Loop-back address is ::1
Global Unicast addresses
Site-local addresses (FEC0::/10)
Link-local addresses (FE80::/64)
Text representation: Colon hexadecimal format
with suppression of leading zero and zero
compression. IPv4-compatible addresses are
expressed in dotted decimal notation
Network bits presentation: Prefix length
notation only
IPSec support is required

6.4 WHY IPv6?

IPv6, which provides the networking services found in IPv4, as well as these additional
features:
• Larger address spaces
• More efficient addressing design and handling at the IP network layer
• Better QoS support
• Imbedded security
• Mobility and broadcasting
• Increased support for a variety of communication services
• Ensure future compatibility with industry, government, and international systems
• Airline industry is collaborating on a standard for airborne IPv6
IPv4 was initially standardized in 1981. As the Internet became more ubiquitous, the
inherent IPv4 QoS, security, addressing, and scalability capabilities were pushed to
their limit. These deficiencies, as well as new network services, exacerbated the strain
placed on IPv4 technology and its quest to accommodate the global needs for Internet
services. To continue using IPv4 under this load required that new features and
capabilities be developed, standardized, and “bolted on”. This approach would have
been costly, risky, and difficult to manage. This resulted in the development of a next
generation networking protocol IPv6. IPv6 was designed to overcome the limitations
of IPv4 by:
• Expanding available IP address space to accommodate future demand
• Improving QoS to minimize packet loss/drops
• Operating over greater bandwidths for video conferencing and Voice over IP
(VoIP) applications
• Enhancing end-to-end security, which is critical for the ATM
• Providing more robust system management on an enterprise scale
• Eliminating the need for network address translation (NAT)
• Incorporating a fixed header structure, which expedites packet routing

© EUROCAE, 2009
 134

There are many vendors offering IPv6 product lines that are often bundled with router
and operating system offerings on the market.
As ATM communication services proliferate domestically and internationally, its
connectivity and communications capabilities need to become more robust and
scalable. IPv6 is an industry-standard solution that can support such growth in
communication demand and geographical scope.

6.5 TRANSITION MECHANISMS

Support of legacy systems while transitioning to an IPv6 infrastructure is enabled with

the following strategies, as described:
• Dual stack, which requires that all end systems and networking devices host
concurrent IPv4 and IPv6 services in order to maintain connectivity until full
operational capability of IPv6 is achieved. Implementation of this strategy may
incur additional cost and management resources to support the deployment of
dual stacks at the various end systems.
• Tunnelling, by encapsulating IPv4 traffic from legacy end systems within IPv6
packets to traverse the upgraded backbone
• Translation, via gateways between legacy systems and IPv6 backbone

© EUROCAE, 2009
 135

CHAPTER VI REFERENCES

[1] IETF RFC-791, September 1991; IETF RFC-2460, December 1998: Internet
Protocol (IPv4); IPv6 Specifications;
http://www.ietf.org/rfc/rfc791.txt; http://www.ietf.org/rfc/rfc2460.txt
[2] IETF RFC-1518, September 1993; An Architecture for IP Address Allocation
with CIDR;
http://www.ietf.org/rfc/rfc1518.txt
[3] IETF RFC-1752, January 1995: The Recommendation for IP Next Generation
Protocol
http://www.ietf.org/rfc/rfc1752.txt
[4] IETF RFC-1883, December 1995: IPv6 Specification (Changes from IPv4 to
IPv6)
http://www.ietf.org/rfc/rfc1883.txt
[5] IETF RFC-1886, December 1995: Obsolete!! DNS Extension to support IPv6
http://www.ietf.org/rfc/rfc1886.txt
[6] IETF RFC-1887, December 1995: An Architecture for IPv6 Unicast Address
Allocation
http://www.ietf.org/rfc/rfc1887.txt
[7] IETF RFC-1918, February 1996: Address Allocation for Private Internets
http://www.ietf.org/rfc/rfc1918.txt
[8] IETF RFC-3232, January 2002, (Information): Assigned Numbers: RFC-1700 is
replaced by On-line Database
http://www.ietf.org/rfc/rfc3232.txt
[9] IETF-RFC-3513, April 2003: IPv6 Addressing Architecture for Unicast, Anycast,
Multicast, and an IPv6 node’s required addresses
http://www.ietf.org/rfc/rfc3513.txt
[10] Internet Protocol for Aeronautical Exchange Task Force (iPAX-TF)
http://www.eurocontrol.int/communications/public/standard_page/com_network.
html
[11] Voice and Data Internetworking, 1998: Compliment of CISCO Systems,
Published by McGraw-Hill
[12] IXIA White Paper, 2004: IPv6 Conformance and Performance Testing
http://www.ofcnfoec.org/materials/IXIA2.pdf
[13] IPv6 and Interoperability by Raytheon
Waseem_Naqvi@raytheon.com
[14] IETF RFC-2526, 1999: Reserved IPv6 Subnet Anycast Addresses, using EUI-
64 format
http://www.ietf.org/rfc/rfc2526.txt
[15] IETF RFC-4213, 2005: Basic Transition Mechanisms for IPv6 Hosts and
Routers
http://www.ietf.org/rfc/rfc4213.txt
[16] IETF RFC-2766, 2000: Network Address Translation – Protocol Translation
(NAT-PT)
http://www.ietf.org/rfc/rfc2766.txt

© EUROCAE, 2009
 136

CHAPTER VII

SECURITY CONSIDERATIONS

7.1 INTRODUCTION

Current ATM voice switching services for Ground-to-Ground (G-G) networking are
supported with private dedicated links. Such networks are considered secure, since
they are not vulnerable to network-layer attacks by viruses and other malicious cyber
activities.
However, migration of ATM G-G voice communications to a VoIP medium is
underway, which will enable flexible deployment of high-availability services, and cost-
effective sharing of common media with data communications. On the other hand, the
accessibility provided by this technology leaves it open to malicious intrusion. To
address such vulnerabilities, an architecture founded upon robust security protections
should be developed, based upon stakeholder policies and needs, and industry
standards and best practices.
The scope of this chapter is to cover the main security issues for VoIP
implementations to support ATM communications, and also to investigate
technologies and practices in securing VoIP networks

7.2 VOICE OVER IP SECURITY OVERVIEW

In Voice over IP systems and networks, the need for security is compounded because
two invaluable assets, data and voice should be protected. Security of voice
conversations is required in ATM applications.
The key to secure VOIP is to use the security mechanisms like those deployed in data
networks (firewalls, encryption, etc.) to emulate the security level currently enjoyed by
PSTN network users.
The potential threats and vulnerabilities in a VOIP environment, include vulnerabilities
of VOIP phones, switches, and other network elements. Threat discussion is included
because the varieties of threats faced by an organization determine the priorities in
securing its communications equipment. Not all threats are present in all
organizations.
Information security risks can be broadly categorized into the following three types:
confidentiality, integrity, and availability.
Additional risks relevant to switches are fraud and risk of physical damage to the
switch, physical network, or telephone extensions.
Packet networks depend for their successful operation on a large number of
configurable parameters: IP and MAC (physical) addresses of voice terminals,
addresses of routers and firewalls, and VOIP specific software such as Call Servers
and other programs/platforms used to place and route calls.
Many of these network parameters are established dynamically every time a network
component is restarted, or when a VOIP telephone is restarted or added to the
network. Because there are so many places in a network with dynamically
configurable parameters, intruders have a wide array of potentially vulnerable points to
attack.

© EUROCAE, 2009
 137

7.2.1 Threats in VoIP networks

7.2.1.1 Confidentiality and Privacy

Confidentiality refers to the need to keep information secure and private. In a

telecommunications switch, eavesdropping on conversations is an obvious concern,
but the confidentiality of other information on the switch must be protected to defend
against toll fraud, voice and data interception, and denial of service attacks. Network
IP addresses, operating system type, telephone extension to IP address mappings,
and communication protocols are all examples of information that, while not critical as
individual pieces of data, can make an attacker’s job easier.
With conventional telephones, eavesdropping usually requires either physical access
to tap a line, or penetration of a switch. Attempting physical access increases the
intruder’s risk of being discovered, and conventional PBXs have fewer points of
access than VOIP systems. With VOIP, opportunities for eavesdroppers increase
dramatically, because of the many nodes in a packet network.

7.2.1.2 Integrity Issues

Integrity of information means that information remains unaltered by unauthorized

users. Telecommunication switches must protect the integrity of their system data and
configuration. Because of the richness of feature sets available on switches, an
attacker who can compromise the system configuration can accomplish nearly any
other goal. For example, an ordinary extension could be re-assigned into a pool of
phones that supervisors can listen in on or record conversations for quality control
purposes. Damaging or deleting information about the IP network used by a VOIP
switch results in an immediate denial of service.
The security system itself provides the capabilities for system abuse and misuse. That
is, compromise of the security system not only allows system abuse but also allows
the elimination of all traceability and the insertion of trapdoors for intruders to use on
their next visit. For this reason, the security system must be carefully protected.
Integrity threats include any in which system functions or data may be corrupted,
either accidentally or as a result of malicious actions. Misuse may involve legitimate
users (i.e. insiders performing unauthorized operations) or intruders.
A legitimate user may perform an incorrect, or unauthorized, operations function (e.g.,
by mistake or out of malice) and may cause deleterious modification, destruction,
deletion, or disclosure of switch software and data. This threat may be caused by
several factors including the possibility that the level of access permission granted to
the user is higher than what the user needs to remain functional.

7.2.1.3 Availability and Denial of Service

Availability refers to the notion that information and services be available for use when
needed. Availability is the most obvious risk for a switch. Attacks exploiting
vulnerabilities in the switch software or protocols may lead to deterioration or even
denial of service or functionality of the switch. For example: if unauthorized access
can be established to any branch of the communication channel (such as a CCS link
or a TCP/IP link), it may be possible to flood the link with bogus messages causing
severe deterioration (possibly denial) of service. A voice over IP system may have
additional vulnerabilities with Internet connections. Because intrusion detection
systems fail to intercept a significant percentage of Internet based attacks, attackers
may be able to bring down VOIP systems by exploiting weaknesses in Internet
protocols and services.
Any network may be vulnerable to denial of service attacks, simply by overloading the
capacity of the system. With VOIP the problem may be especially severe, because of
its sensitivity to packet loss or delay.

© EUROCAE, 2009
 138

7.3 QUALITY OF SERVICE IMPLICATIONS

VoIP has strict performance requirements. The factors that affect the quality of data
transmission are different from those affecting the quality of voice transmission. For
example, data generally is not affected by small delays. The quality of voice
transmissions, on the other hand, is lowered by relatively small amounts of delay.
VoIP call quality depends on three network factors, as mentioned earlier:
- Latency: The time it takes for a voice transmission (or any transmission) to
travel from source to destination is increased as packets traverse each security
node. Primary latency- producing processes are firewall/NAT traversal,
negotiation of long ACLs, and traffic encryption/decryption.
- Jitter (variable packet delays): Jitter may be increased, because in many
circumstances, jitter is a function of hop count.
- Packet loss: The number of non-QoS-aware routers and firewalls that ignore or
fail to properly process Type of Service (ToS) fields in the IP header can
influence packet loss.
The strict performance requirements of VOIP have significant implications for security,
particularly denial of service (DoS) issues. VOIP-specific attacks (i.e., floods of
specially crafted SIP messages) may result in DoS for many VOIP-aware devices. For
example, SIP phone endpoints may freeze and crash when attempting to process a
high rate of packet traffic SIP proxy servers also may experience failure and
intermittent log discrepancies with a VOIP-specific signaling attack of under 1Mb/sec.
In general, the packet rate of the attack may have more impact than the bandwidth;
i.e., a high packet rate may result in a denial of service even if the bandwidth
consumed is low.
Also, several factors, including the expansion of packet size, encryption latency, and a
lack of QoS urgency in the cryptographic engine itself can cause an excessive amount
of latency in the VOIP packet delivery. This could lead to degraded voice quality, so
there is a tradeoff between security and voice quality, and a need for speed.
Fortunately, the difficulties are not insurmountable. Technologies embedded in today’s
equipments address most of these caveats, making possible the coexistence of
security and QoS in VoIP networks. Anyway, due to specific requirements in ATM
applications, care should be taken in implementing security controls (authentication,
encryption), in order to still maintain the required quality and parameters of voice
conversations.

7.4 SECURITY TECHNOLOGIES

Voice over IP network could be protected by implementing security technologies, most

of them being inherited from IP data networks technologies, to which were added
some VoIP specific features.
Numerous problems, from device failures to malicious attacks, affect the uptime of
networks. With the reliance on the IP network for telephony, IP-based threats must be
mitigated. Varying levels of security are available to suit individual corporate
requirements. The requirements for secured IP telephony include the following:
- It must provide ubiquitous IP telephony services to the locations and to the
users that require them.
- It must maintain as many of the characteristics of traditional telephony as
possible, while doing so in a secure manner.
- It must integrate with existing security architecture and not interfere with existing
functions.

© EUROCAE, 2009
 139

The starting point for any security implementation is the development of a security
policy. In a converged network, the security policy must account for the impact of
security measures on voice traffic. The security policy should address the following
points that affect voice:
- Transport security: Traffic traversing public access and backbone networks
must be properly secured. IPSec and VPNs provide transport security by
ensuring data confidentiality using encryption, data integrity, and data
authentication between participating peers. Encryption adds to the overhead
and delays the voice packet. You must factor in encryption when testing the
delay budget and bandwidth calculations.
- Network security: Firewalls provide stateful perimeter security that is critical to
any public-facing network, such as a VPN. When deploying voice across VPNs,
it is critical to statefully inspect all multiservice traffic traversing the firewall.
Firewalls must be configured to allow known signal and payload ports to pass
into the network. It is important to understand where the VPN terminates. If the
VPN terminates inside the firewall, then the traffic passing through the firewall is
encrypted and is subject to stateful inspection. If the VPN terminates outside the
firewall, then the firewall has access to RTP/UDP/TCP/IP headers and is able to
inspect the packet for call setup.
- Intrusion detection: The so called Host Intrusion Detection Systems provide
threat protection for server and desktop computing systems, also known as
endpoints. It identifies and prevents malicious behavior, thereby eliminating
known and unknown security risks and helping to reduce operational costs. The
HIDS aggregate and extend multiple endpoint security functions by providing
host intrusion prevention, distributed firewall capabilities, malicious mobile code
protection, operating system integrity assurance, and audit log consolidation, all
within a single product. In addition, because most of HIDS analyze behavior
rather than relying on signature matching, it provides robust protection with
reduced operational costs.

7.4.1 Encryption for VoIP networks

7.4.1.1 IPSec Encryption

IPsec, Internet Protocol Security, is a set of protocols defined by the IETF, Internet
Engineering Task Force, to provide IP security at the network layer.
IPSec is a large protocol suite designed to provide the following security services for
IP networks: Data Integrity, Authentication, Confidentiality, and Application-transparent
Security.

7.4.1.2 IPSec Overview

IPSec is the preferred form of VPN tunneling across the Internet or other insecure
networks. There are two basic protocols defined in IPSec: Encapsulating Security
Payload (ESP) and Authentication Header (AH) (see figure below). Both schemes
provide connectionless integrity, source authentication, and an anti-replay
service.
The tradeoff between ESP and AH is the increased latency in the encryption and
decryption of data in ESP and a “narrower” authentication in ESP, which normally
does not protect the IP header “outside” the ESP header, although IKE can be used to
negotiate the security association (SA), which includes the secret symmetric keys. In
this case, the addresses in the header (transport mode) or new/outer header (tunnel
mode) are indirectly protected, since only the entity that negotiated the SA can
encrypt/decrypt or authenticate the packets. Both schemes insert an IPSec header
(and optionally other data) into the packet for purposes, such as authentication.

© EUROCAE, 2009
 140

IPSec also supports two modes of delivery: Transport and Tunnel.

- Transport mode encrypts the payload (data) and upper layer headers in
the IP packet. The IP header and the new IPSec header are left in plain sight.
So if an attacker were to intercept an IPSec packet in transport mode, they
could not determine what it contained; but they could tell where it was headed,
allowing rudimentary traffic analysis. On a network entirely devoted to VOIP,
this would equate to logging which parties were calling each other, when, and
for how long.
- Tunnel mode encrypts the entire IP datagram and places it in a new IP
Packet. Both the payload and the IP header are encrypted. The IPSec header
and the new IP Header for this encapsulating packet are the only information
left in the clear. Usually each “tunnel” is between two network elements such as
a router or a gateway. In some cases, such as for mobile users, the tunnel
could be between a router/gateway on one end and a client on the other end.
The IP addresses of these nodes are used as the unencrypted IP address at
each hop. Hence, at no point is a plain IP header sent out containing both the
source and destination IP. Thus if an attacker were to intercept such packets,
they would be unable to discern the packet contents or the origin and
destination. Note that some traffic analysis is possible even in tunnel mode,
because gateway addresses are readable. If a gateway is used exclusively by a
particular organization, an attacker can determine the identity of one or both
communicating organizations from the gateway addresses.
IPSec allows nodes in the network to negotiate not only a security policy, which
defines the security protocol and transport mode as described previously, but also a
security association defining the encryption algorithm and algorithm key to be used.
The IP security (IPSec) protocol was defined by the Internet Engineering Task Force
(IETF) to provide security for IP networks. IPSec is a large protocol suite designed to
provide the following security services for IP networks: Data Integrity, Authentication,
Confidentiality, and Application-transparent Security. IPSec secures packet flows and
key transmission. Since we are interested in NAT and encryption, we’ll ignore most of
the protocol suite including key exchange (IKE), and the various hash and encryption
algorithms, and focus instead on the protocols that are used to secure packet flows.
The AH and ESP protocols can operate in two modes: Transport Mode can be
visualized simply as a secure connection between two concurring hosts. In Tunnel
Mode—more of a “VPN-like” mode— IPSec completely encapsulates the original IP
datagram, including the original IP header, within a second IP datagram. ESP and AH
normally are implemented independently, though it’s possible (but uncommon) to use
them both together.
The Authentication Header (AH) and the Encapsulating Security Payload (ESP) are
the two main network protocols used by IPSec. The AH provides data origin
authentication, message integrity, and protection against replay attacks, but has no
provision for privacy—data is not encrypted. The key to the AH authentication process
is the inclusion in the AH header of an Integrity Check Value (ICV) —a hash based
upon a secret key that is calculated over a subset of the original IP header fields,
including the source and destination IP addresses. AH guarantees (if implemented
correctly) that the data received is identical to the data sent, and asserts the identity of
the true sender. AH provides authentication for as much of the IP header as pos sible,
as well as for upper level protocol data. However, some IP header fields (SIP, DIP,
TTL, CHKSUM, and optionally, TOS, FLAGS, and OPTIONS) change in transit. The
values of such fields usually are not protected by AH. In transport mode, AH is
inserted after the IP header and before the upper layer protocol (TCP, UDP, ICMP,
etc.) header. In tunnel mode, the AH header precedes the encapsulated IP header.
Figure bellow shows the AH transport and tunnel modes.

© EUROCAE, 2009
 141

FIGURE 64 : IPSEC HEADER

In Figure 64, sections A and B show the location of the AH header in transport mode.
Sections C and D show the location of the AH header in tunnel mode. The data field in
all packets is not to scale (indicated by the double slanted lines). You can see from
this figure that tunnel mode AH adds an additional 20 bytes to the length of each
packet. None of the fields in this figure are encrypted.
ESP, on the other hand, was used initially only for encryption; authentication
functionality was subsequently added. The ESP header is inserted after the IP header
and before the upper layer protocol header (transport mode) or before an
encapsulated IP header (tunnel mode).
Figure 65 shows the location of the ESP header in both transport mode (sections A
and B) and tunnel mode (sections C and D) for TCP (sections A and C) and UDP
(sections B and D). In transport mode, the original IP header is followed by the ESP
header. The rightmost field contains the ESP trailer and optionally, the ESP
authorization field. Only the upper-layer protocol header, data, and the ESP trailer
(also, optionally, the ESP authorization field) is encrypted. The IP header is not
encrypted.

© EUROCAE, 2009
 142

FIGURE 65 : ESP HEADER IN TRANSPORT AND TUNNEL MODE

In transport mode, ESP encrypts the entire packet. This means that the entire original
IP datagram, including the original IP and protocol header, is encrypted. In this mode,
when IP traffic moves between gateways, the outer, unencrypted IP header contains
the IP addresses of the penultimate source and destination gateways, and the inner,
encrypted IP header contains the IP source and destination addresses of the true
endpoints. However, even though ESP encrypts most of the IP datagram in either
transport or tunnel mode, ESP is relatively compatible with NAT, since ESP does not
incorporate the IP source and destination addresses in its keyed message integrity
check. Still, ESP has a dependency on TCP and UDP checksum integrity through
inclusion of the pseudo-header in the calculation. As a result, when checksums are
calculated, they will be invalidated by passage through a NAT device (except in some
cases where the UDP checksum is set to zero).

7.4.1.2.1 The Role of IPSec in VOIP

The prevalence and ease of packet sniffing and other techniques for capturing packets
on an IP based network makes encryption a necessity for VOIP. Security in VOIP is
concerned both with protecting of voice traffic as well as the identity of speakers.
IPSec can be used to achieve both of these goals as long as it is applied with ESP
using the tunnel method. This secures the identities of both the endpoints and protects
the voice data from prohibited users once packets leave the corporate intranet. The
incorporation of IPSec into IPv6 will increase the availability of encryption, although
there are other ways to secure this data at the application level. VOIPSec (VOIP using
IPSec) helps reduce the threat of man in the middle attacks, packet sniffers, and many
types of voice traffic analysis. Combined with the firewall implementations, IPSec
makes VOIP more secure than a standard phone line, where people generally assume
the need for physical access to tap a phone line is deterrent enough. It is important to
note, however, that IPSec is not always a good fit for some applications, so some
protocols will continue to rely on their own security features.

© EUROCAE, 2009
 143

7.4.1.2.2 Local VPN Tunnels

Virtual Private Networks (VPNs) are “tunnels” between two endpoints that allow for
data to be securely transmitted between the nodes. The IPSec ESP tunnel is a
specific kind of VPN used to traverse a public domain (the Internet) in a private
manner. Many implementations of VOIP have attempted to make use of other VPN
techniques, including VPN tunneling within an organization’s intranet. VPN tunnels
within a corporate LAN or WAN are much more secure and generally faster than the
IPSec VPNs across the Internet because data never traverses the public domain, but
they are not scaleable. This sort of implementation has a physical limit at the size of
the private network, and as VOIP becomes more widely spread, it is not practical for
an implementation to regard calls outside the local network as a black box. Also, no
matter how the VPN is set up, the same types of attacks and issues associated with
IPSec VPNs are applicable, so we consider here only the case of IPSec tunneling and
assume the security solutions can be scaled down to an internal network if needed.

7.4.1.2.3 Difficulties Arising from Voice Over IPSec

IPSec has been included in IPv6. It is a reliable, robust, and widely implemented
method of protecting data and authenticating the sender. However, there are several
issues associated with VOIP that are not applicable to normal data traffic. Of particular
interest are the Quality of Service (QoS) issues discussed before. The crucial
parameters of a VoIP call quality are latency, jitter, and packet loss. Issues are
introduced into the VOIP environment because it is a real time media transfer, with
only 150 ms one-way delay to deliver each packet. In standard data transfer over
TCP, if a packet is lost, it can be resent by request. In VOIP, there is no advantage in
retransmitting the lost packets, due to time constraints.
Packets must arrive at their destination and they must arrive fast. Of course the
packets must also be secure during their travels, thus the introduction of VOIPSec.
However, the price of this security could be a decisive drop in QoS caused by a
number of factors like encryption latency, expanded packet size, compatibility issues
between IPSec and NAT.

7.4.1.2.4 Encryption / Decryption Latency

Studies performed revealed the cryptographic engine as a bottleneck for voice traffic
transmitted over IPSec. The driving factor in the degraded performance produced by
the cryptography was the scheduling algorithms and the lack of QoS in the
crypto-engine itself. However, there still was significant latency due to the actual
encryption and decryption.
Encryption/decryption latency is a problem for any cryptographic protocol,
because much of it results from the computation time required by the
underlying encryption. With VOIP’s use of small packets at a fast rate and
intolerance for packet loss, maximizing throughput is critical.
Some results related to the round-trip delay introduced by the IPSec
encryption/decryption are shown in Table 24.
Description Speed Round-trip delay
Clear Voice Only 2 MB 7ms
Clear Voice Only 128Kbps 69ms
IPSec 3DES, SHA Voice Only (Software) 2 MB 22ms
IPSec 3DES, SHA Voice Only (Software) 128Kbps 104ms
IPSec 3DES, SHA Voice Only 2 MB 11-12ms
IPSec 3DES, SHA Voice Only 128Kbps 95ms
TABLE 24 - IPSEC AND INTRODUCED DELAY

© EUROCAE, 2009
 144

Due to the problems that IPSec encryption could arise, there is always a challenge in
the network design to balance between security and voice quality. Two solutions to
this problem are using faster encryption algorithms (SRTP with MIKEY) and
incorporating QoS into the crypto-engine. Due to the specific delay restrictions, latency
is less of a problem for management and/or signaling data than for voice channel
traffic.

7.4.1.2.5 Scheduling and the need of QoS in the Crypto-Engine

The crypto-engine is a severe bottleneck in the VOIP network. As just noted, the
encryption process has a negative effect on QoS, but this is not the highest degree
factor in the slowdown. Instead, the driving force behind the latency associated with
the crypto-engine is the scheduling algorithm for packets that entered the
encryption/decryption process. While routers and firewalls take advantage of QoS to
determine priorities for packets, crypto-engines provide no support for manual
manipulation of the scheduling criteria. In ordinary data traffic this is less of an issue
because inordinately more packets pass through the router than the crypto-engine,
and time is not as essential. But in VOIP, a voluminous number of small packets must
pass through both the crypto engine and the router. Considering the time urgency
issues of VOIP, the standard FIFO scheduling algorithm employed in today’s crypto-
engines creates a severe QoS issue.
These QoS violations derived from the crypto-engine are augmented by the presence
of actual data traffic on a VOIP network. Since one of the primary motivations for the
development of VOIP is the ability of voice and data to share the same network, this
scenario is to be expected. Experiments showed that such a combination of traffic has
disastrous effects on VOIPSec. This is especially true if the heterogeneous data
needs to be encrypted and decrypted. Since the crypto-engine has no functionality for
changing its own priority schema based on the type of traffic it is presented with, the
VOIP packets are at the mercy of the FIFO scheduling algorithm, and are often left
waiting behind larger heterogeneous packets, despite the lesser urgency of these
large packets. The non-uniform pattern of data traffic also contributes to a great deal
of jitter in VOIP. The variation in the bandwidth usage caused by heterogeneous
packets introduces variation to the delay times of the fairly uniform VOIP packets,
causing them to arrive in spurts. If these spurts exceed the timing mechanism
associated with the de-jitter buffer, then packet loss can occur. The development of
VOIP-aware crypto schedulers would help to relieve this problem.
The last added features of the main vendors allow for queueing techniques in crypto-
engines. For instance, Cisco has introduced Low Latency Queueing in its recent
software for routers.
Low Latency Queueing (LLQ) for IPSec encryption engines helps reduce packet
latency by introducing the concept of queueing before crypto engines. Prior to this, the
crypto processing engine gave data traffic and voice traffic equal status.
Administrators now designate voice traffic as priority. Data packets arriving at a router
interface are directed into a data packet inbound queue for crypto engine processing.
This queue is called the best effort queue. Voice packets arriving on a router
interface are directed into a priority packet inbound queue for crypto engine
processing. This queue is called the priority queue. The crypto engine undertakes
packet processing in a favorable ratio for voice packets. Voice packets are guaranteed
a minimum processing bandwidth on the crypto engine.
The Low Latency Queueing (LLQ) for IPSec encryption engines feature guarantees a
certain level of crypto engine processing time for priority designated traffic.

© EUROCAE, 2009
 145

7.4.1.2.6 Expanded Packet Size

IPSec also increases the size of packets in VOIP, which leads to more QoS issues. It
has been shown that increased packet size increases throughput through the crypto-
engine, but to conclude from this that increased packet size due to IPSec leads to
better throughput would be fallacious. The difference is that the increase in packet
size due to IPSec does not result in an increased payload capacity. The increase is
actually just an increase in the header size due to the encryption and encapsulation of
the old IP header and the introduction of the new IP header and encryption
information. This leads to several complications when IPSec is applied to VOIP. First,
the effective bandwidth is decreased as much as 63%. Bandwidth performance
reductions are associated with the various encryption algorithms. The size
discrepancy can also cause latency and jitter issues as packets are delayed by
decreased network throughput or bottlenecked at hub nodes on the network (such as
routers or firewalls).

7.4.1.2.7 IPSec and NAT Incompatibility

IPSec and NAT compatibility is far from ideal. NAT traversal completely invalidates the
purpose of AH because the source address of the machine behind the NAT is masked
from the outside world. Thus, there is no way to authenticate the true sender of the
data. The same reasoning demonstrates the inoperability of source authentication in
ESP. Since this is an essential feature of VOIPSec, this is a serious problem. There
are several other issues that arise when ESP traffic attempts to cross a NAT. If only
one of the endpoints is behind a NAT, the situation is easier. If both are behind NATs,
IKE negotiation can be used for NAT traversal, with UDP encapsulation of the IPSec
packets.

7.4.1.3 Other encryption solutions

7.4.1.3.1 Encryption at the End Points

One proposed solution to the bottlenecking at the routers due to the encryption issues
is to handle encryption/decryption solely at the endpoints in the VOIP network. One
consideration with this method is that the endpoints must be computationally powerful
enough to handle the encryption mechanism. But typically endpoints are less powerful
than gateways, which can leverage hardware acceleration across multiple clients.
Though ideally encryption should be maintained at every hop in a VOIP packet’s
lifetime, this may not be feasible with simple IP phones with little in the way of
software or computational power. In such cases, it may be preferable for the data be
encrypted between the endpoint and the router (or vice versa) but unencrypted traffic
on the LAN is slightly less damaging than unencrypted traffic across the Internet.
Fortunately, the increased processing power of newer phones is making endpoint
encryption less of an issue. In addition, SRTP and MIKEY are future protocols for
media encryption and key management enabling secure interworking between H.323
and SIP based clients.

7.4.1.3.2 Secure Real Time Protocol (SRTP) – RFC 3711

RTP (Real-time Transport Protocol) is commonly used for the transmission of real-
time audio/video data in Internet telephony applications. Without protection RTP is
considered insecure, as a telephone conversation over IP can easily be
eavesdropped. Additionally, manipulation and replay of RTP data could lead to poor
voice quality due to jamming of the audio/video stream. Modified RTCP (Real-time
Transport Control Protocol) data could even lead to an unauthorized change of
negotiated quality of service and disrupt the processing of the RTP stream.
The Secure Real-time Protocol is a profile of the Real-time Transport Protocol (RTP)
offering not only confidentiality, but also message authentication, and replay
protection for the RTP traffic as well as RTCP (Real-time Transport Control Protocol).
SRTP was being standardized at the IETF in the AVT working group. It was released
as RFC 3711 in March 2004.

© EUROCAE, 2009
 146

SRTP provides a framework for encryption and message authentication of RTP

and RTCP streams. SRTP can achieve high throughput and low packet
expansion.
SRTP is independent of a specific RTP stack implementation and of a specific key
management standard, but Multimedia Internet Keying (MIKEY) has been designed to
work with SRTP.
AES in counter mode is the default algorithm, if encryption is desired. The pre-defined
authentication transform is HMAC-SHA1. The default session authentication key-
length is 160 bits, the default authentication tag length is 80 bits. The key derivation
function is AES in counter mode with a 128-bit master key from the key management.
Interface for hardware-crypto support (e.g. IP phones). In comparison to the security
options for RTP there are some advantages to using SRTP. The advantages over the
RTP standard security and also over the H.235 security for media stream data are
listed below.
SRTP provides increased security, achieved by:
- Confidentiality for RTP as well as for RTCP by encryption of the respective
payloads;
- Integrity for the entire RTP and RTCP packets, together with replay protection;
- The possibility to refresh the session keys periodically, which limits the amount
of cipher text produced by a fixed key, available for an adversary to
cryptanalyze;
- An extensible framework that permits upgrading with new cryptographic
algorithms;
- A secure session key derivation with a pseudo-random function at both ends;
- The usage of salting keys to protect against pre-computation attacks;
- Security for unicast and multicast RTP applications.
SRTP has improved performance, attained by:
- Low computational cost asserted by pre-defined algorithms;
- Low bandwidth cost and a high throughput by limited packet expansion and by
a framework preserving RTP header compression efficiency;
- Small footprint that is a small code size and data memory for keying information
and replay lists.
The following characteristics also argue for SRTP:
- It is defined as a profile of RTP, so that it can be easily integrated into existing
RTP stacks. For example SRTP may use RTP padding because the encrypted
portion is the exact size of the plaintext for the pre-defined algorithms.
- It provides independence from the underlying transport, network, and physical
layers used by RTP, in particular high tolerance to packet loss and re-ordering,
and robustness to transmission bit-errors in the encrypted payload.
- It lightens the burden of the key management due to the fact that a single
master key can provide keying material for confidentiality and integrity
protection, both for the SRTP stream and the corresponding SRTCP stream.
For special requirements a single master key can protect several SRTP
streams.
Because SRTP is defined as an RTP profile it may be used with existing multimedia
standards. H.323 SRTP support is defined within the H.235 Annex G (currently in draft
status), for SIP or more precisely SDP enhancements have been defined to transport
the key management data necessary for SRTP.

© EUROCAE, 2009
 147

Thus, the combination of SRTP and MIKEY may be used to provide end-to-end
encryption even between different multimedia signaling standards like H.323
and SIP.

7.4.2 VoIP protection - Perimeter security with firewalls

7.4.2.1 Firewalls

Firewalls are a staple of security in today’s IP networks. Whether protecting a LAN,

WAN, encapsulating a DMZ, or just protecting a single computer, a firewall is usually
the first line of defense against would be attackers. Firewalls work by blocking traffic
deemed to be invasive, intrusive, or just plain malicious from flowing through them.
Traffic not meeting the requirements of the firewall is dropped. Processing of traffic is
determined by a set of rules programmed into the firewall by the network
administrator.
A useful property of a firewall, in this context, is that it provides a central location for
deploying security policies. It is the ultimate bottleneck for network traffic because
when properly designed, no traffic can enter or exit the LAN without passing through
the firewall. This situation lends itself to the VOIP network where firewalls simplify
security management by consolidating security measures at the firewall gateway,
instead of requiring all the endpoints to maintain up to date security policies. This
takes an enormous burden off the VOIP network infrastructure. Note that this
abstraction and simplification of security measures comes at a price. The introduction
of firewalls to the VOIP network complicates several aspects of VOIP, most notably
dynamic port trafficking and call setup procedures. This chapter describes various
complications firewalls introduce into the system. But since firewalls are an essential
and often already deployed component of the modern network, we will also examine
some proposed and applied solutions to these problems.

7.4.2.2 Stateful Firewalls

Most VOIP traffic travels across UDP ports. Firewalls typically process such traffic
using a technique called packet filtering. Packet filtering investigates the headers of
each packet attempting to cross the firewall and uses the IP addresses, port numbers,
and protocol type (collectively known as the 5-tuple) contained therein to determine
the packets’ legitimacy. In VOIP and other media streaming protocols, this information
can also be used to distinguish between the start of a connection and an established
connection. There are two types of packet filtering firewalls, stateless and stateful.
Stateless firewalls retain no memory of traffic that has occurred earlier in the session.
Stateful firewalls do remember previous traffic and can also investigate the application
data in a packet. Thus, stateful firewalls can handle application traffic that may not be
destined for a static port.

7.4.2.3 VOIP specific Firewall Needs

In addition to the standard firewall practices, firewalls are often deployed in VOIP
networks with the added responsibility of brokering the data flow between the voice
and data segments of the network. This is a crucial functionality for a network
containing PC-Based IP phones that are on the data network, but need to send voice
messages. All voice traffic emanating from or traveling to such devices would have to
be explicitly allowed in if no firewall was present because RTP makes use of dynamic
UDP ports (of which there are thousands). Leaving this many UDP ports open is an
egregious breach of security. Thus, it is recommended that all PC-based phones be
placed behind a stateful firewall to broker VOIP media traffic. Without such a
mechanism, a UDP DoS attack could compromise the network by exploiting the
plethora of open ports. This is one example of how firewalls are used to provide a
logical segmentation of the network, providing a barrier between voice and data
sectors. Some of the key points of collision between voice and data traffic where
firewalls are necessary, could include:
- PC-Based IP phones (data) require access to the (voice) segment to place
calls, leave messages, etc.

© EUROCAE, 2009
 148

- IP Phones and call managers (voice) accessing voice mail (data),

- users (data) accessing the proxy server (voice)
- the proxy server (voice) accessing network resources (data).
- traffic from IP Phones (voice) to the call processing manager (voice) or proxy
server (voice) must pass through the firewall because such contacts use the
data segment as an intermediary.
Firewalls could also be used to broker traffic between physically segmented traffic
(one network for VOIP, one network for data) but such an implementation could be
unacceptable for most organizations, since one of the benefits of VOIP is voice and
data sharing the same physical network.

7.4.2.4 Firewalls, NATs, and VOIP Issues

Some VOIP issues with firewalls and NATs are unrelated to the call setup protocol
used. Both network devices make it difficult for incoming calls to be received by a
terminal behind the firewall / NAT. Also, both devices affect QoS and can raise issues
with the RTP stream. The following sections describe these non-protocol specific
issues.

7.4.2.4.1 Incoming Calls

Regardless of the protocol used for call setup, firewalls and NATs present
considerable difficulties for incoming calls. Allowing signal traffic through a firewall
from an incoming call means leaving several ports open that might be exploited by
attackers. Careful administration and rule definitions should be used if holes are to be
punched in the firewall allowing incoming connections. Solutions exist without such
holes, including Application Level Gateways and Firewall Control Proxies. NAT
creates even more difficulties for incoming calls. Any IP application, including VOIP,
that needs to make a connection from an external realm to a point behind a NAT
router, would need to know this point’s external IP and port number assigned by the
router. This situation is far from ideal because it precludes a caller outside the NAT
from reaching an internal address except in extreme circumstances. In fact, with
dynamic ports being assigned by the NAT, this is nearly an impossible situation
because the port the caller requests will be changed by the NAT. Thus, an IP
telephony endpoint behind a NAT being analogous to a phone behind a switchboard
such that it can only make outgoing calls. For endpoints behind firewalls and NATs, it
may be necessary to publish the contact address to enable other clients to call them.
This is not an acceptable solution for thousands of people using NAT today. However,
there are some solutions to this problem.

7.4.2.4.2 Effects on QoS

Both firewalls and NATs can degrade QoS in a VOIP system by introducing latency
and jitter. NATs can also act as a bottleneck on the network because all traffic is
routed through a single node.
VOIP is highly sensitive to latency. So a firewall needs to be able to broker data traffic,
but cannot incur time penalties of any significant length, even those that would go
unnoticed with simple data traffic. At issue is not only how fast the firewall can interact
with the network traffic, but how fast its processor can handle VOIP packets. Two
aspects of VOIP can cause degraded behavior in the firewall CPU. First, the call setup
process has to be done using H.323 or SIP. Regardless of the protocol used, firewalls
need to “dig deeper” into these packets to determine their validity. A flood of call
request packets, as the result of an increase in call volume or a malicious attack, can
intensify this effect. The presence of a NAT compounds this issue because the
payload of the packet must then be changed at the application level to correspond to
the NAT translated source or destination address and ports, requiring not only
analyzing the packet but changing some fields of it. All this labor puts a tremendous
burden on the firewall processor, which must accomplish all these tasks while

© EUROCAE, 2009
 149

introducing the bare minimum in latency, especially if protocol security measures are
used, such as message integrity.
The other aspect of VOIP that can put a strain on a firewall CPU is the small but
plentiful number of RTP packets that make up a VOIP conversation. Firewalls are
rarely concerned with the size of a packet, but since each packet must be inspected, a
large number of packets can stress the firewall. For example, a firewall may support
100 Mbit/sec (based on the assumption of large packets), but may be overloaded by a
flood of small 50 byte packets long before the 100 Mbit/sec rate is reached. QoS/VOIP
aware firewalls are designed to avoid performance problems such as these.
No matter how fast the network connection, the firewall CPU is a bottleneck for all
unencrypted network packets. Thus a solution to this issue could be to use a VPN for
all VOIP traffic.

7.4.2.4.3 Firewalls and NATs

Firewalls have difficulties sorting through VOIP signaling traffic. There are solutions to
this but there is an additional, and even more vexing problem associated with firewalls
and VOIP media. RTP traffic is dynamically assigned an even port number in the
range of UDP ports (1024-65534). In addition, the RTCP port controlling this stream
will flow through an associated, randomly-assigned port. Allowing such traffic along
such a vast number of ports by default would leave the system highly exposed. So
firewalls must be made aware dynamically of which ports media is flowing across and
between which terminals. For this reason, only stateful firewalls that can process
H.323 and SIP should be incorporated into the network to open and close ports. Many
new firewalls come equipped with such functionality, although sometimes they support
only one protocol (H.323 or SIP).
NATs also introduce major design complications into media traffic control in VOIP.
First of all, the standard NAT practice of assigning new port numbers at random
breaks the pair relationship of RTP and RTCP port numbers. The translation of IP
Addresses and ports by NAT is also problematic for the reception of VOIP packets. If
the NAT router does not properly process the traffic, the new addresses/ports will not
correspond to those negotiated in the call setup process. In this scenario, the VOIP
gateway may not properly deliver the RTP packets. The problem is exacerbated if
both call participants are behind NATs.
The use of NATs adds another possible complication to VOIP call signaling due to the
finite nature of NAT bindings. At a NAT, a public IP address is bound to a private one
for a certain period of time (t). This entry gets deleted if no traffic was observed at the
NAT for t seconds or the connection was torn down explicitly. A SIP INVITE message,
which triggers the binding of the private address to the public one, establishes “state”
information when it passes through NATs or firewalls. This state eventually must be
cleared. When TCP is used, closure of the TCP connection is usually a good indicator
of the termination of the application. However, when SIP runs over UDP such a clear
indication is missing. Furthermore, as a silence period during a conversation might be
longer than t seconds, not receiving traffic for t seconds might not suffice as an
indication of session termination. As a result, it is possible that some state information
is destroyed before the transaction and/or the call actually completes.

7.4.2.4.4 Call Setup Considerations with NATs and Firewalls

VOIP users will not tolerate excessive latency in the call setup process, which
corresponds to lifting the receiver and dialing in a traditional system. Users may be
annoyed with a setup process that requires more than a few seconds. Many factors
influence the setup time of a VOIP call. At the network level, these include the
topology of the network and the location of both endpoints as well as the presence of
a firewall or NAT. At the application level, the degree or lack of authentication and
other data security measures, as well as the choice of protocol used to set up the call,
can dramatically alter the time necessary to prepare a VOIP connection.

© EUROCAE, 2009
 150

7.4.3 Application Level Gateways

Application Level Gateways (ALGs) are the typical commercial solution to the
firewall/NAT traversal problem. An ALG is embedded software on a firewall or NAT,
that allows for dynamic configuration based on application specific information. A
firewall with a VOIP ALG can parse and understand H.323 or SIP, and dynamically
open and close the necessary ports. When NAT is employed, the ALG needs to open
up the VOIP packets and reconfigure the header information therein to correspond to
the correct internal IP addresses on the private network, or on the public network for
outgoing traffic. This includes modifying the headers and message bodies (e.g., SDP)
in H.323 and SIP. The NAT problem is alleviated when the ALG replaces the private
network addresses with the address of the ALG itself. It works by not only changing
the IP address, but also mapping RTP traffic into ports the ALG can read from and
forward to the correct internal machine. The need for consecutive ports for RTP and
RTCP can cause a problem here because all VOIP traffic on the network (and data
traffic as well) is being routed through the ALG, so as call volume increases, finding
enough consecutive ports may become an issue. So although both endpoints may
have adequate ports to convene a conversation, the firewall’s deficiencies may cause
the call to be rejected as “busy” by the ALG itself.
There are significant performance and fiscal costs associated with the implementation
of an ALG. Performance-wise, the manipulation of VOIP packets introduces latency
into the system and can contribute to jitter when high call volumes are experienced.
Depending on the firewall architecture, this can also slow down throughput in the
firewall, contributing to general network congestion. A firewall with ALG support can
be expensive, and would need to be upgraded or replaced each time the standards for
VOIP change. Also, the addition of application intelligence to a firewall can introduce
instabilities into the firewall itself. Some firewalls have been found vulnerable to an
attack in which a high rate of call setups can be sent, depleting the connection tables
of the firewall. These half-open VOIP sessions may not time out in the firewall for
more than 24 hours. Still with all these detractions, an ALG remains the simplest and
safest workaround to allow the coexistence of VOIP, firewalls, and NAT.

7.4.4 Middlebox Solutions

One drawback to ALGs is that they are embedded in the firewall itself, and thus the
latency and throughput slowdown of all traffic traversing the firewall is aggregated and
then compounded by the VOIP call volume. Middlebox-style solutions attempt to
alleviate this malady by placing an extra device outside the firewall that performs
many of the functions associated with an ALG. The device that the application
intelligence is extracted to can be an “in-path” system such as an H.323 gatekeeper or
a SIP Proxy that sits in the control path of the session and is considered to be a
“trusted system” that parses VOIP traffic and instructs the firewall to open or close
ports based on the needs of the VOIP signaling via a midcom protocol (see figure
below). The midcom protocol has not been finalized yet by the IETF. Abstracting
stateful inspection and manipulation of signaling packets from the NATs and firewalls
(middleboxes) will improve scalability and in the long run, reduce the cost of updating
the network by not having to replace the firewall every time the protocols change.
There is also a performance improvement that comes from abstracting two highly
processor intensive tasks (VOIP parsing and packet filtering) into two separate
spheres of influence. This strategy is currently being pursued by the IETF in the
Middlebox Communications (Midcom) Working Group.
There are some drawbacks to this approach. First, the firewall must be configured for
control by the application-aware device, which incurs an initial setup cost. Also, the
middlebox itself requires protection from attackers. A compromised midcom agent is
disastrous for the network at large because the firewall takes control cues from the
“trusted” device running the midcom agent. Thus an intruder taking control of the
midcom agent could open any ports in the firewall and then gain access to the private
network. So if the application aware device (like a SIP Proxy) is placed outside the
firewall, a second firewall would have to be used to protect that device.

© EUROCAE, 2009
 151

FIGURE 66 : MIDDLEBOX CONCEPT

7.4.5 Session Border Controllers

A Session Border Controller (SBC) is a session-aware device that manages VoIP and
MoIP calls at the borders of an IP network. Unlike most network devices session
border controllers are aware of the relationship between the two parts of a VoIP call:
signalling and media.
SBCs can be divided into two types of architectures:
- The stand-alone Session Border Controller - this contains all of the intelligence
and resources needed to process both the signalling and the media of the VoIP
call.
- The distributed Session Border Controller - In this case the signalling and media
functions are divided between two systems that communicate with each other.
Among the main functions of an SBC we could find:
- NAT Traversal: One of the key functions of the Session Border Controller is the
ability to provide SIP services across NAT and Firewalls devices located at a
customer premise or within the network. The problem is actually twofold:
o Whilst Firewalls are able to dynamically open and close multiple ports as
required by VoIP signalling protocols such as SIP, they remain ineffective
at securely supporting unsolicited incoming media flows.
o NATs prevent two-way voice and multimedia communication, because
the private IP addresses and ports inserted by client devices (IP phones,
etc.) in the packet payload are not routable in public networks. Thus
incoming calls, essential to any service intended to replace the PSTN,
are not possible with existing NAT/Firewalls.
SBCs provide traversal of NAT/Firewalls without additional customer premise
equipment, and do not require the replacement of existing Firewalls and NATs.
- Security: Session Border Controllers protect core networks elements, such as
Softswitches, from signalling attacks by identifying malicious traffic before it
reaches the core. SBCs also perform topology hiding, removing internal network
information from the signalling stream thus preventing internal details from
being propagated.

© EUROCAE, 2009
 152

- Quality of Service: Session border controllers occupy a unique position in the

network enabling them to control the quality of end-user communications and
enforce operators' Service Level Agreements.
o Session (Call) Admission Control - SBCs can monitor the number of calls
and bandwidth in use and can reject new calls in order to preserve the
quality of established calls.
o Policing - SBCs can ensure that the signalled media requirements match
the actual media being transmitted in a call, discarding excessive data.
This prevents service theft and protects against a media DoS attack.
o Anti-Tromboning - often a call may be most effectively transported
entirely within the subscribers' private network, in this case the SBC
allows the media the flow directly between client devices.
o QoS Re-mapping - SBCs can monitor and optionally re-mark the quality
settings of a user's data (Type of Service bits and DiffServ Code Point
bits). This ensures the users receive the quality they pay for. When SBC
are used in network interconnections they can map one service provider's
quality settings onto another's.
- Regulatory: It has become increasingly clear recently that VoIP services will be
expected to provide Lawful Intercept and Emergency Call Handling services to
the same level experienced in the PSTN. The FCC in North America for
example has mandated that both emergency calls and Lawful Intercept must be
available.
o Lawful Intercept - must be performed without the user being aware of any
change in their normal communications. Session Border Controllers
handle both media and signalling, intercept can be performed in a
completely undetectable manner.
o Emergency Call Handling - SBCs must identify emergency calls and
forward them on to a SIP Proxy that is able to route emergency calls.
Emergency Calls must be carried under all traffic load conditions.
SBCs hold a unique position in VoIP networks. They form the border between access
and core networks and, between core networks in the case of interconnect. In
essence they form the gateway into and out of the Carriers core network:
- Interconnect - the session border controller forms the border between network
operators. Here it secures the network border, enforces Quality of Service
policies, ensure any intermediate NAT and firewalls can be traversed, and
provides regulatory compliance.
- Access - the session border controller enables the service provider to access
the residential and corporate user across NAT and firewall devices whilst also
providing Quality of Service, core network security and Regulatory compliance.

© EUROCAE, 2009
 153

7.4.6 IPS (Intrusion Prevention Systems)

7.4.6.1 IPS Overview

The latest technology to protect the networks is known as an Intrusion Prevention

System (IPS). Unlike a traditional Intrusion Detection System (IDS), intrusion
prevention technology enables to stop intrusion traffic before it enters the network by
placing the sensor as a forwarding device in the network.
Figure 67 shows possible locations for IPS sensors in a network.

FIGURE 67 : IPS CONCEPTS

7.4.6.2 IPS/IDS Triggers

The purpose of any IPS/IDS is to detect when an intruder is attacking your network.
Not every IDS/ IPS, however, uses the same triggering mechanisms to generate
intrusion alarms.
There are three major triggering mechanisms used by current intrusion systems:
- Anomaly detection, also sometimes referred to as profile-based detection.
With anomaly detection, you must build profiles that define what activity is
considered normal. These profiles can be learned over a period of time or they
can be modeled on historical behavior. After defining which traffic or activity is
considered normal, then anything that deviates from this normal profile
generates an alert (since it is abnormal).
- Misuse detection, also known as signature-based detection, looks for
intrusive activity that matches specific signatures. These signatures are based
on a set of rules that match typical patterns and exploits used by attackers to
gain access to your network. Highly skilled network engineers research known
attacks and vulnerabilities to develop the rules for each signature.
- Protocol analysis. With protocol analysis, the IPS/IDS analyzes the data
stream based on the normal operation of a specific protocol. Therefore, the
intrusion system is verifying the validity of the packets with respect to the
protocol definition and then looking for specific patterns in the various fields of
the protocol or a packet's payload. This in-depth analysis utilizes a protocol's
Request for Comments (RFC) as a baseline and focuses on two major areas:

© EUROCAE, 2009
 154

Triggering mechanisms refer to the action that causes the IDS/IPS to generate an
alarm. The triggering mechanism for a home burglar alarm could be a window
breaking. A network IDS may trigger an alarm if it sees a packet to a certain port with
specific data in it. A host-based IPS/ IDS may generate an alarm if a certain system
call is executed. Anything that can reliably signal an intrusion can be used as a
triggering mechanism.

7.4.6.3 IPS Responses

The standard response to a triggered signature is the generation of an alert (alarm).

Other actions that your IPS signatures can invoke, include the following:
- Inline actions. By adding inline functionality, an IPS is able to incorporate the
following signature actions:
o Deny Packet Inline, causes the sensor to drop any packets that match
the signature's parameters. This action is useful for preventing specific
attack traffic while allowing all other traffic to continue to travel through
the network.
o Deny Connection Inline, causes the sensor to drop all traffic for the
connection that triggered the signature. A connection is defined as all
traffic in which the following fields match the traffic that triggered the
signature: Source IP Address, Source Port, Destination IP Address,
Destination Port
o Deny Attacker Inline, causes the sensor to drop all packets from the
attacker's IP address. This action prevents the entry of all traffic
originating from the attacker's IP address, not just traffic that matches the
initial connection that triggered the signature.
These actions impact even the initial traffic from an attacking system.
Therefore, they can be used to prevent attack traffic from reaching the
target system or network. To use these actions, however, the sensor
must be configured using inline mode.
- Logging Actions. IP logging enables you to capture the actual packets that an
attacking host is sending to your network. These packets are stored on the
sensor, either on the hard drive or in memory (for sensors without hard drives).
You can then analyze these packets by using a packet analysis tool, such as
Ethereal, to determine exactly what an attacker is doing.
You can capture traffic by using IP logging in response to both a signature
configured with the IP logging action as well as a manually initiated IP logging
request. When logging an attacker's activity, you have the following three
options:
o Log Attacker Packets causes the sensor to log (or capture) traffic from
the source IP address that caused the signature to trigger. This will show
all the systems and services that the attacking system is accessing.
o Log Pair Packets causes a signature to log only the traffic that matches
both the source and destination IP addresses that initially triggered the
signature.
o Log Victim Packets causes the sensor to log all the packets going to the
victim (destination) IP address. This option is useful for monitoring the
target system in situations where the attack may be coming from multiple
IP addresses. By logging traffic to the target system, it is possible to
identify all the traffic going to the victim machine.

© EUROCAE, 2009
 155

- IP blocking enables to halt future traffic from an attacking host for a specified
period of time, thereby limiting the attacker's access to your network. Usually
there are two options with respect to IP blocking:
ƒ Request Block Host
ƒ Request Block Connection
- TCP Reset
The TCP reset response action essentially kills the current TCP connection
from the attacker by sending a TCP reset packet to both systems involved in the
TCP connection. This response is effective only for TCP-based connections.
UDP traffic, for example, is unaffected by TCP resets.
Intrusion Prevention Systems should be used when necessary to protect
sensitive network segments and/or equipments. However, due to the high
complexity of configuration and possible problems which could appear, care
should be taken in implementing these security controls in the network.
Misconfigured IPS could lead to service degradation and/or disruption.

7.5 BEST PRACTICES SOLUTIONS FOR PROTECTING VOIP/IP TELEPHONY

NETWORKS

In securing Voice over IP we could take the following approach:

1. Secure the network infrastructure for voice
2. Protect Voice over IP endpoints
3. Protect Voice over IP servers
4. Protect Voice over IP applications
The attacks against Voice over IP could be categorized as follows:
- Attacks against VoIP/IP telephony endpoints
ƒ Reconnaissance
ƒ DHCP starvation
ƒ Eavesdropping/Man-in-the-middle
ƒ Directed TCP and ICMP attacks
- Attacks against VoIP/IP telephony servers
ƒ Worms, viruses and trojans
ƒ DoS and DdoS
ƒ Directed probes, floods
- Attacks against VoIP/IP telephony applications
ƒ Intercept administration and user traffic
ƒ Rogue servers
ƒ Toll fraud
With respect to the classification above, the best practices offered today by technology
to put against the threats mentioned are:

© EUROCAE, 2009
 156

7.5.1 Secure the network infrastructure for voice

General Security Best Practices:

- Out-of-band management
- Management and signalling secure protocols: SSH/HTTPS
- Permit lists (filters)
- Routing process authentication
- Network Intrusion Detection/Prevention Systems
- Security management
- Firewall or ACL in front of VoIP servers
- Rate limiting (for example MicroFlow policing)
Switching Security Features:
- Separate voice and data VLANs
- VLAN ACLs (VACLs)
- DHCP snooping
- Dynamic ARP inspection
- IP source guard
- Port security
Interconnecting sites:
- Use IPSec to protect all traffic, not just voice
- Terminate in VPN concentrator or large router as needed on inside of FW or
ACL
- Easier to get through FW than defining all ports in an ACL
- Remember clustering over- the-WAN metrics

7.5.2 Attacks against VoIP Endpoints

Attacks against VoIP endpoints:

- Directed TCP and ICMP attacks: SYN/FIN/RST
- DHCP spoofing and starvation attacks
- Man-in-the-middle attacks or traffic interception (ettercap, dsniff)
- Eavesdropping attacks (VOMIT)
- Reconnaissance
- Subvert security features
Best practices:
TCP and ICMP attacks:
- Phones only need to send RTP to each other and a small number of TCP/UDP
protocols to servers
- Phones have no reason to send TCP or ICMP to each other
- Use a simple VLAN ACL to limit traffic to exactly that
- Stops TCP and ICMP attacks against the phones

© EUROCAE, 2009
 157

Man-in-the-middle attacks:
- Built on DHCP snooping binding table
- Dynamic ARP inspection watches ARP/GARP for violations
- IP source guard examines every IP packet
- Will drop packets or disable port
Ignore Gratuitous ARP:
- Block acceptance of Gratuitous ARP (GARP) by the phone
- Prevents malicious device from assuming the identity of something else (default
router) to become man-in-the-middle
- Doesn’t really ignore it; just doesn’t update ARP cache
- Still susceptible to DHCP DoS attack—“I have your address”
- Can still ARP poison the default router
- Better to do this in layer two
Block PC Access to Voice VLAN:
- Blocks 802.1q tagged with voice VLAN being sent to or received from the PC
port on the phone
- Blocks the malicious sniffing of voice streams from the PC port of a phone
- Also blocks intentional sniffing in troubleshooting or monitoring situations
- There are other ways to sniff, such as the SPAN and R-SPAN feature on LAN
switches
Stop rogue images from entering phones:
- Signed firmware images
- Digital signatures for endpoints
- Signed configuration files for endpoints: valid configuration from a trusted TFTP
server
In conclusion, securing VoIP endpoints can be achieved with the following features:
- VLAN ACLs and IP-Source Guard stop directed TCP and ICMP attacks
- DHCP snooping stops rogue DHCP servers and slows starvation attacks
- DAI prevents man-in-the-middle attacks or traffic interception (ettercap, dsniff)
- Blocking PC access to voice VLAN stops eavesdropping attacks (VOMIT)
- Disabling web access to a phone inhibits reconnaissance
- Signed firmware and configuration files prevent security features from being
subverted

7.5.3 Voice over IP Servers protection

Attacks against VoIP servers:

- Targeted TCP and UDP attacks and port scans
- DoS and DDoS attacks on signaling ports to servers
- Common Windows exploits
- Targeted and anonymous illicit behavior
- Worms, viruses, and trojans

© EUROCAE, 2009
 158

Best practices:
There are two options regarding firewalls presence in the network, in front of the
servers:
Firewall pros:
- Need a network mechanism to isolate and protect telephony servers
- Firewalls provide stateful inspection of protocols that use ephemeral port
ranges. Otherwise, have to open entire port range in static ACL
- Should be tied with rate limiting, but don’t provide rate limiting themselves
Firewall cons:
- Reduced throughput with voice ALG (Application Layer Gateway)
- As load increases so does jitter and latency (how much?)
- Impact of mixing voice traffic with non-voice
- Reduced multicast or QoS features?
- Limited configuration guidelines
Firewall design recommendations:
- Keep it simple: two interfaces, secure and insecure
- Keep voice and other application data separate
- Exhaustive testing in lab before putting into production, addressing the main
issues for VoIP: delay, jitter, QoS
For servers:
- Hardening Operating Systems
- OS Security best practices
- Limiting administrative access to servers, based on authentication and
authorization mechanysms

7.5.4 Voice over IP application protection:

Attacks Against IP Telephony Applications:

- Intercept administration and user traffic
- Install rogue server or phone on the network
- Interpret intercepted media and signaling
- Hijack voicemail messages
- Toll fraud
Best practices:
- Use secure protocols for administrative traffic: HTTPS, SSL, SSH
- Establishing a Trust Basis in IP Phones
- Public key/private key pair—Every device generates its own pair so the private
key NEVER crosses the wire:
o Default key length—1024 bits; optionally 512 or 2048 bits
o Used for signatures and identity

© EUROCAE, 2009
 159

- X.509v3 digital certificate:

o Establishes a device’s identity
o Used to share a device’s public key
o Signed by a trusted certificate authority
- Certificate trust list:
o Identical file held by every endpoint
o Contains the certificates of devices the endpoints should trust:
CallManagers, TFTP servers, other servers
Certificate based authentication and encryption:
- TLS—Transport Layer Security protects signaling between Call Servers and
endpoints:
o RSA signatures
o HMAC-SHA-1 authentication tags
o AES-128-CBC encryption
o Supports any application-layer protocol: HTTP, FDP, LDAP etc.
o Bi-directional PKI establishes Identity
o HMAC provides Integrity
o Encryption offers Privacy
o Needs secure method to exchange shared secret
ƒ Bi-directional PKI pairs for mutual authentication
ƒ Shared secret generated using RSA
o Computes Hashed Message Authentication Code (HMAC)
ƒ Allows MD5 or SHA1
o Conventional cryptography using shared secret
ƒ DES, 3DES, AES
ƒ RC2, RC4
ƒ IDEA
- SRTP—Secure RTP (RFC3711) protects media (voice) traffic between
endpoints
o HMAC-SHA-1 authentication tags
o AES-128-CM encryption

© EUROCAE, 2009
 160

ANNEX 1

IPSEC TERMS GLOSSARY

Advanced Encryption Standard (AES): AES was finalized as a Federal Information
Processing Standard (FIPS)-approved cryptographic algorithm to be used in order to
protect electronic data transmission (FIPS PUB 197). AES is based on the Rijndael
algorithm, which specifies how to use keys with a length of 128, 192, or 256 bits to
encrypt blocks with a length of 128, 192, or 256 bits (all nine combinations of key
length and block length are possible).
Authentication Header (AH): A security protocol that provides authentication and
optional replay-detection services. AH is embedded in the data to be protected (a full
IP datagram, for example). AH can be used either by itself or with Encryption Service
Payload (ESP). Refer to the RFC 2402.
Authentication: One of the functions of the IPSec framework. Authentication
establishes the integrity of datastream and ensures that it is not tampered with in
transit. It also provides confirmation about datastream origin.
Certification Authority (CA): A third-party entity with the responsibility to issue and
revoke certificates. Each device that has its own certificate and public key of the CA
can authenticate every other device within a given CA's domain. This term also
applies to server software that provides these services.
Certificate: A cryptographically signed object that contains an identity and a public
key associated with this identity.
Certificate Revocation List (CRL): A digitally signed message that lists all of the
current but revoked certificates listed by a given CA. This is analogous to a book of
stolen charge card numbers that allow stores to reject bad credit cards.
Data integrity: Data integrity mechanisms, through the use of secret-key based or
public-key based algorithms, that allow the recipient of a piece of protected data in
order to verify that the data has not been modified in transit.
Data confidentiality: Method where protected data is manipulated so that no attacker
can read it. This is commonly provided by data encryption and keys that are only
available to the parties involved in the communication.
Data origin authentication: A security service where the receiver can verify that
protected data could have originated only from the sender. This service requires a
data integrity service plus a key distribution mechanism, where a secret key is shared
only between the sender and receiver.
Data Encryption Standard (DES): The DES was published in 1977 by the National
Bureau of Standards and is a secret key encryption scheme based on the Lucifer
algorithm from IBM. The contrast of DES is public-key.
Diffie-Hellman: A method of establishing a shared key over an insecure medium.
Diffie-Hellman is a component of Oakley (see the definition for Oakley contained in
this definition list).
DSS: A digital signature algorithm designed by The US National Institute of Standards
and Technology (NIST) based on public key cryptography. DSS does not do user
datagram encryption. DSS is a component in classic crypto, as well as the Redcreek
IPSec card, but not in IPSec implemented in Cisco IOS software.
Encapsulating Security Payload (ESP): A security protocol that provides data
confidentiality and protection with optional authentication and replay-detection
services. ESP completely encapsulates user data. ESP can be used either by itself or
in conjunction with AH. Refer to RFC 2406: IP Encapsulating Security Payload (ESP).

© EUROCAE, 2009
 161

Hash: A one way function that takes an input message of arbitrary length and
produces a fixed length digest. Cisco uses both Secure Hash Algorithm (SHA) and
Message Digest 5 (MD5) hashes within our implementation of the IPSec framework
(see the definition for HMAC).
HMAC: A mechanism for message authentication using cryptographic hashes such as
SHA and MD5. For an exhaustive discussion of HMAC, refer to RFC 2104.
Internet Key Exchange (IKE): A hybrid protocol that uses part Oakley and part of
another protocol suite called SKEME inside the Internet Security Association and Key
Management Protocol (ISAKMP) framework. IKE is used to establish a shared
security policy and authenticated keys for services (such as IPSec) that require keys.
Before any IPSec traffic can be passed, each router/firewall/host must be able to verify
the identity of its peer. This can be done by manually entering pre-shared keys into
both hosts, by a CA service, or the forthcoming secure DNS (DNSSec). This is the
protocol formerly known as ISAKMP/Oakley, and is defined in RFC 2409: The Internet
Key Exchange (IKE).
Internet Security Association and Key Management Protocol (ISAKMP): A
protocol framework that defines the mechanics of implementing a key exchange
protocol and negotiation of a security policy. ISAKMP is defined in the Internet
Security Association and Key Management Protocol (ISAKMP).
ISAKMP/Oakley: See IKE.
Message Digest 5 (MD5): A one way hashing algorithm that produces a 128-bit hash.
Both MD5 and Secure Hash Algorithm (SHA) are variations on MD4, which is
designed to strengthen the security of this hashing algorithm. SHA is more secure
than MD4 and MD5.
Oakley: A key exchange protocol that defines how to acquire authenticated keying
material. The basic mechanism for Oakley is the Diffie-Hellman key exchange
algorithm. You can find the standard in RFC 2412: The OAKLEY Key Determination
Protocol.
Perfect Forward Secrecy (PFS): PFS ensures that a given IPSec SA key was not
derived from any other secret (like some other keys). In other words, if someone
breaks a key, PFS ensures that the attacker is not able to derive any other key. If PFS
is not enabled, someone can potentially break the IKE SA secret key, copy all the
IPSec protected data, and then use knowledge of the IKE SA secret in order to
compromise the IPSec SAs setup by this IKE SA. With PFS, breaking IKE does not
give an attacker immediate access to IPSec. The attacker needs to break each IPSec
SA individually.
Replay-detection: A security service where the receiver can reject old or duplicate
packets in order to defeat replay attacks (replay attacks rely on the attacker sending
out older or duplicate packets to the receiver and the receiver thinking that the bogus
traffic is legitimate). Replay-detection is done by using sequence numbers combined
with authentication, and is a standard feature of IPSec.
RSA: A public key cryptographic algorithm (named after its inventors, Rivest, Shamir
and Adleman) with a variable key length. RSA's main weakness is that it is
significantly slow to compute compared to popular secret-key algorithms, such as
DES. With the Diffie-Hellman exchange, the DES key never crosses the network (not
even in encrypted form), which is not the case with the RSA encrypt and sign
technique. RSA is not a public domain, and must be licensed from RSA Data Security.
Security Association (SA): An instance of security policy and keying material applied
to a data flow. Both IKE and IPSec use SAs, although SAs are independent of one
another. IPSec SAs are unidirectional and they are unique in each security protocol. A
set of SAs are needed for a protected data pipe, one per direction per protocol. For
example, if you have a pipe that supports ESP between peers, one ESP SA is
required for each direction. SAs are uniquely identified by destination (IPSec endpoint)
address, security protocol (AH or ESP), and security parameter index (SPI).

© EUROCAE, 2009
 162

IKE negotiates and establishes SAs on behalf of IPSec. A user can also establish
IPSec SAs manually.
An IKE SA is used by IKE only. Unlike the IPSec SA, it is bi-directional.
Secure Hash Algorithm (SHA): A one way hash put forth by NIST. SHA is closely
modeled after MD4 and produces a 160-bit digest. Because SHA produces a 160-bit
digest, it is more resistant to brute-force attacks than 128-bit hashes (such as MD5),
but it is slower.
Transform: A transform describes a security protocol (AH or ESP) with its
corresponding algorithms. For example, ESP with the DES cipher algorithm and
HMAC-SHA for authentication.
Transport Mode: An encapsulation mode for AH/ESP. Transport Mode encapsulates
the upper layer payload (such as Transmission Control Protocol (TCP) or User
Datagram Protocol (UDP)) of the original IP datagram. This mode can only be used
when the peers are the endpoints of the communication. The contrast of Transport
Mode is Tunnel Mode.
Tunnel Mode: Encapsulation of the complete IP Datagram for IPSec. Tunnel Mode is
used on order to protect datagrams sourced from or destined to non-IPSec systems
(such as in a Virtual Private Network (VPN) scenario).

© EUROCAE, 2009
 163

ANNEX 2

COMPARISON BETWEEN IPSEC AND MPLS-BASED VPN

IP Security (IPSec) and MPLS comprise a set of complementary technologies that are
emerging to form the predominant foundations for delivery of new security services.
Table 25 describes the characteristics, benefits, positioning, and differentiation
between IPSec and MPLS-based VPNs.

Characteristics IPSec-based VPN MPLS-based VPN

Service Models High-speed Internet services, High-speed Internet services,
business-quality IP VPN services, business-quality IP VPN services,
e-commerce and application- e-commerce and application-
hosting services hosting services
Scalability Large-scale deployment required Highly scalable since no site-to-
planning and coordination to site peering is required. A typical
address issues on key distribution, MPLS-based VPN deployment is
key management, and peering capable of supporting large-scale
configuration VPN groups over the same
network
Place in Network Best at the local loop, edge and off- Best within a service provider’s
net where there is a higher degree core network where QoS, traffic
of exposure to data privacy and engineering, and bandwidth
where IPSec security mechanisms utilization can be fully controlled,
such as tunneling and encryption especially if
can best be applied
Service Level Agreement (SLA) or
Service Level Guarantee (SLG) is
to be offered as part of the VPN
service
TABLE 25 - IPSEC AND MPLS-BASED VPN COMPARISON

© EUROCAE, 2009
 164

CHAPTER VII REFERENCES

[1] IETF RFC 2119: Key words for use in RFCs to Indicate Requirement
Levels;
http://www.ietf.org/rfc/rfc2119.txt
[2] NIST Security Considerations for Voice Over IP Systems; D. Richard
Kuhn, Thomas J. Walsh, Steffen Fries
http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf
[3] IP Telephony Security: Threats and Mitigation Techniques; Richard
Dodsworth, Cisco Networkers 2005 Technical Session Presentation
[4] IETF RFC 791: Internet Protocol (IP) version 4;
http://www.ietf.org/rfc/rfc791.txt
[5] IETF RFC 2460: Internet Protocol (IP) version 6 Specification;
http://www.ietf.org/rfc/rfc2460.txt
[6] IETF RFC 3711: The Secure Real-Time Transport Protocol (SRTP);
http://www.ietf.org/rfc/rfc3711.txt
[7] IETF RFC 4301: Security Architecture for the Internet Protocol;
http://www.ietf.org/rfc/rfc4301.txt
[8] IETF RFC 2246: The TLS Protocol Version 1.0; IETF RFC 3546: TLS
Extensions
http://www.ietf.org/rfc/rfc2246.txt, http://www.ietf.org/rfc/rfc3546.txt
[9] IETF RFC 2402: IP Authentication Header (AH);
http://www.ietf.org/rfc/rfc2402.txt
[10] IETF RFC 2406: IP Encapsulating Security Payload (ESP);
http://www.ietf.org/rfc/rfc2406.txt
[11] IETF RFC 2407: The Internet IP Security Domain of Interpretation for
ISAKMP;
http://www.ietf.org/rfc/rfc2407.txt
[12] IETF RFC 2408: Internet Security Association and Key Management
Protocol (ISAKMP);
http://www.ietf.org/rfc/rfc2408.txt
[13] IETF RFC 2409: The Internet Key Exchange (IKE);
http://www.ietf.org/rfc/rfc2409.txt
[14] IETF RFC 3550: RTP: A Transport Protocol for Real-Time Applications;
http://www.ietf.org/rfc/rfc3550.txt
[15] IETF RFC 3261: SIP: Session Initiation Protocol;
http://www.ietf.org/rfc/rfc3261.txt
[16] IETF RFC 3265: Session Initiation Protocol (SIP) – Specific Event
Notification;
http://www.ietf.org/rfc/rfc3265.txt
[17] ITU H.235: Security and encryption for H-Series (H.323 and other H.245-
based) multimedia terminals;
http://www.itu.int/rec/T-REC-H.235/en
[18] ITU H.323: Packet-based multimedia communication systems;
http://www.itu.int/rec/T-REC-H.323/en
[19] IETF RFC 2764: A Framework for IP Based Virtual Private Networks;
http://www.ietf.org/rfc/rfc2764.txt
[20] IETF RFC 4251: The SSH Protocol Architecture;
http://www.ietf.org/rfc/rfc4251.txt

© EUROCAE, 2009
 165

CHAPTER VIII

NETWORK MANAGEMENT
8.1 INTRODUCTION

In spite of there are still a number of air traffic communication systems which
are based on analog lines, the benefits of digital technology is evident on this
type of communications systems. The facilities and functionalities supported by
VoIP establish this technology as a serious alternative to analog links.
In order to perform the necessary network management in this sort of systems,
the most suitable option aims to the Simple Network Management Protocol
(SNMP), which provides a complete framework to handle, define and exchange
network management information.
The first version of this network management framework was named SNMv1
and was subsequently enhanced by SNMv2. Currently, a set of RFCs has been
published so as to correct the main shortcomings of SNMv1 and SNMv2, mainly
in aspects related to security features, such as authentication, privacy and
access control. This version has been released as SNMPv3.
In this chapter, the principal SNMP concepts are outlined, and a discussion
about the three network management frameworks, SNMPv1, SNMPv2 and
SNMPv3 is performed.

8.2 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)

The Simple Network Management Protocol (SNMP) defines a protocol for the
exchange of management information, as well as a procedure for representing
this type of information by means of specific data base structures, called
management information bases (MIBs). Very valuable information about the
network can be obtained by using this protocol, and the solution of quite
different management network troubles is eased.
SNMP is placed into a more general context known as the Internet-Standard
Management Framework, which contents all the components to deploy a
complete management network system.
Nowadays, two standards has been released regarding to this Management
Framework, the original Internet-Standard Management Framework (SNMPv1)
and the second Internet-Standard Management Framework (SNMPv2). The
main SNMPv1 features and the corresponding improvements achieved by
SNMPv2 can be found at [19]. One more specification is pending to become an
standard (SNMPv3), which enhances the main features of the previous ones. A
complete comparison between the three versions can be found in RFC 3410
[16].
In this chapter a short explanation of the Internet Standard Management
Framework will be exposed, as well as a discussion about the different versions
specifications and characteristics will be developed.

8.2.1 Basic structure

The Internet Standard Management Framework comprises of the following

components:
• one or more agents, which are installed in the managed nodes to provide
access to remote devices. These devices collect the necessary
information by means of SNMP, the management protocol that makes
this information available to the network manager.
• network controlling and monitoring of the managed devices, which is
provided by the Network Manager System.

© EUROCAE, 2009
 166

• management information structured hierarchically to form Management

Information Bases (MIBs), which can be accessed by the SNMP protocol.
The three versions of the Internet Standard Management Framework share the
basic structure mentioned above.
In addition to this, SNMP defines a Structure of Management Information (SMI),
which states a standard data representation, using Abstract Syntax Notation
One (ASN.1), in order to get round the incompatibilities between different
devices attached to the managed network.
Apart from these features that the three versions have in common, basically
what SNMPv2 incorporates into the system with regard to SNMPv1, are some
enhancements and additional protocol operations, which will be pointed lately.
The main goals achieved by SNMPv3 rather than the other two previous
versions are mainly related to security and administration capabilities. These
characteristics will be exposed in next chapters in this working paper.

8.2.2 SNMP Version 1 (SNMPv1)

The first Internet-Standard Network Management Framework implementation is

called SNMPv1, and it is described in several documents, such as : RFC 1157
[1], which defines the SNMP protocol and RFC 1155 [2], which defines the
Structure of Management Information (SMI). Some other documents complete
the whole specifications for this version [3] [4].

8.2.2.1 SNMPv1 Management Information

According to the Structure of Management Information (SMI), it was first defined

the Management Information Base I (MIB-I), as specified in RFC 1066 [5] and
lately it was published the MIB-II, as specified in RFC 1213 [6].
The SMI defines several types of specifications: ASN.1 data types, SMI-specific
data types and SNMP MIB tables. So, every object managed must be formed
by at least a minimum sub-group from the ASN.1 notation, in order to identify
correctly to each object. Furthermore, the SMI specific data types may be split
into two categories: simple data types and application wide data types. Finally,
MIB tables are highly organized to group the instances of objects with multiple
variables.

8.2.2.2 SNMPv1 Protocol operations

SNMPv1 protocol operations are described in RFC 1157 [1], and they are quite
straightforward; they are based on the request / response protocol. Four
operations are defined which are carried out by protocol data units (PDUs) in
this document: Get, GetNext, Set and Trap. These four activities let to handle
the MIBs throughout the SNMP protocol.

8.2.2.3 SNMPv1 Security and Administration

In spite of SNMPv1 anticipates the definition of several security schemes, an

acceptable grade of security is only reached by SNMPv3. The only
authentication schemes exposed by SNMPv1 are based on community strings,
which results fairly insufficient for so many applications.
In that sense, it was thought that an authentication block could be defined after
some time to achieve the necessary grade of security. Therefore, SNMPv3 is
able to incorporate this block to its architecture to offer the required
authentication service level.

© EUROCAE, 2009
 167

8.2.3 SNMP Version 2 (SNMPv2)

The next step in network management was the publication of SNMPv2 as a set
of proposed Internet standards in 1993, currently it is a draft standard. The
SNMPv2 Management Framework is published in [7-13].
The main enhancements that SNMPv2 add to the SNMPv1 functionality are:
• expanded data types
• improved efficiency and performance
• confirmed event notification
• richer error handling
• improved sets, especially row creation and deletion
• fine tuning of the data definition language

8.2.3.1 SNMPv2 Management Information

SNMP Structure of Management Information (SMI) defines the data definition

language and the management information by means of ASN.1, as can bee
seen in RFC 1902 [7].
The main improvements that SNMPv2 achieves are concerned to bit strings,
network addresses and counters. Bit strings are new in SNMPv2, they were not
defined before, and network addresses are enlarged from 32 bit IP addresses
that supported SNMPv1 to many other types supported. Counters are expanded
as well, they can reach now a value of 64 bit rather than the 32 bit defined for
SMPv1.
Furthermore, SNMPv2 SMI defines information modules, which specify a group
of related definitions. Examples of these new features are: MIB modules,
compliance statements and capability statements. These three new
characteristics will improve the information exchange between the network
manager and the different agents related to it.

8.2.3.2 SNMPv2 Protocol operations

Regarding to protocol operations, SNMPv2 continues the use of operations

such as Get, GetNext and Set, but several enhancements are added in this
version. Firstly, the handle of errors is improved by means of a new Trap
operation, with the same functionality than SNMPv1 but with a new enhanced
message format.
Furthermore, two new protocol operations are defined: Getbulk and Inform.
Getbulk is defined to manage large quantities of data, for instance, multiple
rows in a table. Inform the information exchanges between two network
managers, for example, one manager send a trap operation and then. receive a
response.

8.2.3.3 SNMPv2 Security and Interoperability

The principal SNMPv2 security deficiency is the absence of authentication

facilities, what increases the weakness of the Management Framework
considerably. Consequently not so many vendors feel really confident to
implement the whole SNMPv2 functionality (for example Set operations), rather
than using it as a monitoring facility.
There are two main aspects in which SNMPv2 is not compatible with SNMPv1:
their messages use a different header and protocol data unit (PDU), and
SNMPv2 defines some protocol operations which are not specified in SNMPv1.

© EUROCAE, 2009
 168

In that sense, two possible solutions have been thought to get the compatibility :
the use of proxy agents to act as “gateway” between the versions, or the
utilization of a Bilingual Network Management system, which would support
both of them. Further information about these two strategies can be obtained
from RFC 1908 [13].

8.2.4 SNMP Version 3 (SNMPv3)

SNMPv3 is produced based on a modular architecture, in which all the

enhancements that SNMPv2 addressed with respect to SNMPv1 still remain,
but new security and administrative capabilities are incorporated to this new
Management Framework.
In this sense, the main goals achieved by the Internet-Standard Network
Management Framework version 3, SNMPv3, are the following:
- authentication: origin identification, message integrity, and some aspects
of replay protection
- privacy: confidentiality
- authorization and access control
- suitable remote configuration and administration capabilities for these
features.

8.2.4.1 SNMPv3 Management Information

The Structure of Management Information is incorporated from SNMPv2 and

the main features are published in RFC 2578-2580 [14-15]. The Structure of
Management Information (SMIv2) defines data types, an object model and the
rules for writing and revising MIB modules.
MIB modules define management information to be remotely accessible by the
management agents, transported by the management protocol and controlled
by the network manager. The number of standard MIB modules is permanently
increasing, and it is defined in the “Internet Official Protocol Standards” list [26].
Owing to the management information defined in any MIB module is compatible
with any version of the SNMP protocol, MIB modules defined in conformity with
the Structure Management Information version 1 (SMIv1), will be perfectly
compatible with the SNMPv3 Management Framework. The only exception is
the Counter64 datatype, defined in SMIv2, which can not be supported by
SNMPv1.

8.2.4.2 SNMPv3 Protocol operations

The specifications for the SNMPv3 protocol operations are obtained from
SNMPv2 Management Framework as well, and can be found in the RFC 3416
“Version 2 of the Protocol Operations for the Simple Network Management
Protocol (SNMP)” [17].
In addition, the specification for transport mappings can be found in RFC 3417,
“Transport Mappings for the Simple Network Management Protocol (SNMP)”
[18].

8.2.4.3 SNMPv3 Architecture / Security and Administration

A complete description of a Management Framework Architecture together with

the principal features of Security and Administration are described in
“Architecture for SNMP Management Frameworks”, RFC 3411[20].
SNMPv3 Architecture can be named as a SNMP entity and is formed by two
parts basically, the SNMP engine and the SNMP applications.
The SNMP engine contains several components:

© EUROCAE, 2009
 169

8.2.4.3.1 Dispatcher

The Dispatcher main tasks are:

- sending and receiving SNMP messages to/from the network and
determining the version of each SNMP message.
- providing an abstract interface to SNMP applications to interact with
others applications and entities.

8.2.4.3.2 Message Processing Subsystem

As its own name addresses, the Message Processing Subsystem is in charge

of proceeding the incoming messages and preparing the outgoing ones.
This subsystem may contain several Message Processing Models depending
on the version of each one, for example, SNMPv3 Message Processing Model
and SNMPv2 Message Processing Model.

8.2.4.3.3 Security Subsystem

The Security Subsystem has two main tasks. On the first hand, it supplies
mainly two security services such as authentication and privacy of messages.
On the other hand it contains one or more Security Models.
The Security Models specify the threats against it protects, as well as the
security protocols used to provide security services.
The main threats that could be present into a Management Framework are the
following:
- Modification of the information, i.e., SNMP messages can be altered by
some unknown individual.
- Masquerade, i.e., manager identity could be assumed by a not authorized
user.
- Message stream modification, i.e., natural SNMP stream in the managed
network could be delayed, mixed up or even destroyed by any intruder.
- Disclosure, i.e., SNMP exchanges into the management network could
be spied by a not authorized user.
- Denial of service, i.e., rejection of a request from an authorized user
which should have been attended.
- Traffic Analysis attacks in the Management Framework before
established.
The Security Model for SNMPv3 is defined in RFC 3414, “User-based Security
Model (USM) for version 3 of the Simple Network Management Protocol
(SNMPv3)”. This document defines the USM to defend against the following
threats: modification of information, masquerade, message stream modification
and disclosure. These threats are considered in the primary and secondary
level of danger.
In order to guarantee data integrity, the USM uses MD5[21] and the Secure
Hash Algorithm [22] to achieve:
- Protection against data modification attacks.
- Data origin authentication.
- Defence against masquerade attacks.
Protection against certain message stream modification attacks is obtained by
means of the use of synchronized monotonically increasing time indicators.
Finally, the USM utilizes the Data Encryption Standard (DES) [23] to get the
defence against disclosure.

© EUROCAE, 2009
 170

The security protocols describe the procedures and MIB objects used to provide
the above mentioned security services. All the protocols used by the USM are
based on private-keys mechanisms. In theory, SNMPv3 lets the use of not only
private-keys mechanisms (also known as symmetric) but also public key ones
(also known as asymmetric). However, currently there is no public key
mechanism using as a standard.

8.2.4.3.4 Access Control Subsytem

This subsystem specifies authorization services by using one or more Access

Control Models. An Access Control Model provide one specific access decision
function so as to support decisions regarding access rights., for example the
View-Based Access Control Model
This model is specified in the RFC 3415, “View-Based Access Control Model
(VACM) [24] for the Simple Network Management Protocol (SNMP). The VACM
is able to support multiples and different Access Control Models active and
present at the same time in a single engine implementation.
There are various SNMP applications, such as:
- command generators, which monitor and manipulate management data,
- command responders, which provide access to management data,
- notification originators, which initiate asynchronous messages,
- notification receivers, which process asynchronous messages, and
- proxy forwarders, which forward messages between entities.
All of these applications make use of the services provided by the SNMP
engine. Besides, depending on the type of applications specified, different types
of entities will be defined.
For instance, an SNMP entity containing its corresponding SNMP engine and
one or more command generator and / or notification receiver applications is
called a traditional SNMP Manager. Another example would be an SNMP entity
containing one or more command responder and / or notification originator
applications (together with the corresponding SNMP engine) is called a
traditional SNMP Agent.

8.2.4.4 SNMPv3 Coexistence and Transition

The interoperability between the different versions of SNMP is discussed in the

RFC 3584, “Coexistence between Version 1, Version 2 and Version 3 of the
Internet-Standard Network Management Framework” [25], where it can be
showed the transition and coexistence between the SNMPv3 Management
Framework, the SNMPv2 Management Framework and the original SNMPv1
Management Framework.
The main tasks which are explained in the previous document, to guarantee the
interoperability between the different SNMP versions are:
- Conversion of MIB documents from Structure Management Information
version 1 (SMIv1) to Structure Management Information version 2
(SMIv2).
- Mapping of notification parameters.
- Management information exchange between different entities from
different SNMP versions, by means of either multi-lingual
implementations or proxy implementations.
- The adaptation between the SNMPv1 Message Processing Model into
the View-Based Access Control Mode [24].

© EUROCAE, 2009
 171

8.3 CONCLUSIONS & RECOMMENDATIONS

The utilization of VoIP represents an important enhancement for air traffic

management systems, due to the all the facilities and features that VoIP technology
incorporates. In this sense, it can result quite useful the employment of SNMP to
perform the different activities that implies network management between the different
parts of the air traffic systems.
SNMPv1 was the first standard about network management on TCP/IP based
networks. Most of the characteristics of SNMPv1 were improved by the publication of
SNMPv2, such as the expansion of data types and the errors handling , as well as the
enhancement of efficiency and performance.
Nevertheless, the main SNMPv1 deficiency, security, was not corrected with SNMPv2
version. With the purpose to achieve this primary need has been published a new
SNMP version, SNMPv3. SNMPv3 has been conceived as a framework with a
modular architecture, to be as much compatible as possible with the previous SNMP
versions, and also to be susceptible of future enhancements. Mainly, the new
expected goals addressed by SNMPv3 are support of authentication, privacy and
access control. So, SNMPv3 is called to be the protocol to replace SNMPv1 and
SNMPv2, to provide new operability and improved functionalities to network
management on TCP/IP based networks.

© EUROCAE, 2009
 172

CHAPTER VIII REFERENCES

[1] Case, J., Fedor, M., Schoffstall, M. and Davin, J., "Simple Network
Management Protocol", STD 15, RFC 1157, May 1990.
[2] Rose, M. and K. McCloghrie, "Structure and Identification of Management
Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
[3] McCloghrie, K. and M. Rose, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March
1991.
[4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215,
March 1991.
[5] McCloghrie, K. and M. Rose, "Management Information Base for Network
Management of TCP/IP-based Internets", RFC 1156, March 1990.
[6] McCloghrie, K. and M. Rose, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March
1991.
[7] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of
Management Information for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1902, January 1996.
[8] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions
for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC
1903, January 1996.
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Conformance
Statements for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1904, January 1996.
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for
Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905,
January 1996.
[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for
Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906,
January 1996.
[12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management
Information Base for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1907, January 1996.
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between
Version 1 and Version 2 of the Internet-Standard Network Management
Protocol ", RFC 1908, January 1996.
[14] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S.
Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[15] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S.
Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April
1999.
[16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability
Statements for Internet-Standard Management Framework", RFC 3410,
December 2002.
[17] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2
of the Protocol Operations for the Simple Network Management Protocol
(SNMP)", STD 62, RFC 3416, December 2002.
[18] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for the Simple Network Management Protocol (SNMP)", STD 62,
RFC 3417, December 2002.

© EUROCAE, 2009
 173

[19] Cisco Systems, "Simple Network Management Protocol", chapter 56,

Internetworking Technologies Handbook.
[20] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing
Simple Network Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.
[21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[22] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995)
http://csrc.nist.gov/fips/fip180-1.txt (ASCII)
http://csrc.nist.gov/fips/fip180-1.ps (Postscript)
[23] Data Encryption Standard, National Institute of Standards and Technology.
Federal Information Processing Standard (FIPS) Publication 46-1. Supersedes
FIPS Publication 46, (January, 1977; reaffirmed January, 1988).
[24] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model
(VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC
3415, December 2002.
[25] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1,
Version 2, and Version 3 of the Internet-Standard Network Management
Framework", RFC 3584, August 2003.
[26] "Official Internet Protocol Standards", http://www.rfc-editor.org/rfcxx00.html also
STD0001.

© EUROCAE, 2009
 174

VOIP LEXICON
ABR – Available Bit Rate is a Quality of Service category that may attributed to a
network traffic class, providing no guarantees regarding cell loss or delay, providing
only best-effort service
ADPCM – Adaptive Differential Pulse Code Modulation is an algorithm which encodes
analog voice samples into high-quality digital signals at a low bit rate. This is achieved
by recording the difference between samples and adjusting the coding scale
dynamically to accommodate large and small differences
A-G- Air to Ground
ARP – Address Resolution Protocol used to map an IP address to a MAC address. It
is defined in IETF STD 37
ATM – Asynchronous Transfer Mode is a network technology based on transferring
data in cells or packets of a fixed size. The small, constant cell size allows ATM
equipment to transmit video, audio and computer data over the same network,
assuring that no single type of data utilizes excessive bandwidth on the line
ATM – Air Traffic Management provides management, control, and maintenance
services for air traffic flow
ATS – Air Traffic Services
Backbone – The main trunk that connects nodes across a LAN or WAN
Bandwidth – The amount of data that can be transmitted in a fixed amount of time.
For digital networks, the bandwidth is usually expressed in bits per second (bps) or
bytes per second
Broadcast – A packet delivered to all workstation on a network. Broadcasts exist at
layer 2 and at layer 3
Broadband – Descriptive term for evolving digital technology that provides consumers
a single node offering integrated access to voice, high-speed data service, video-on-
demand services, and interactive delivery services
Call – Establishment of voice connection between two endpoints
Call deflection – Call deflection is a feature under H.450.3 call diversion (call
forwarding) that allows a called H.323 endpoint to redirect the unanswered call to
another H.323 endpoint
CO – Central Office, a local telephony company office which connects to all local
loops in a given area and where circuit switching of customer lines occurs
Codec – Coder/Decoder. In telecommunications, it is a device that encodes or
decodes a signal. For example, telephone companies use codecs to convert binary
signals transmitted on their digital networks to analog signals converted on their
analog networks. They are defined by the ITU-T “G.7xx” family of recommendations
Compression – Any technique that reduces the number of digital packets, frames, or
cells to lower the bandwidth or space required for transmission or storage
Congestion – The situation in which the traffic presented to the network exceeds
available network bandwidth/capacity, resulting rising latency and lower throughput
Class of Services – Class of Services (CoS) is an enterprise network has many
different type of traffic flow across it, for voice and data transmissions. There are 3
major technologies that are used to create classes and prioritizing:
• IEEE 802.1p (layer 2 tagging)
• Type of Services (ToS), layer 3 IP header
• Differentiated Services (DiffServ), layer 3

© EUROCAE, 2009
 175

Delay – Amount of time a call spends waiting to be processed. A system performance

metric, delay can refer to actual transmission time, the waiting time in buffer, the time
it takes for the data to travel between any two network nodes, the processing time
(e.g., packetization, depacketization, protocol processing, coding) or to the time for
data to be switched through a switch or router
DiffServ - differentiates IP traffic so that the relative priority of each traffic class could
be determined on a per-hop basis
DTMF – Dual Tone Multi-Frequency: The set of standardized, superimposed tones
used in telephony signaling as generated by a touch tone pad
DSP – Digital Signal Processor is a high-speed processor designed to do real-time
signal manipulation
DHCP – Dynamic Host Configuration Protocol provides a mechanism for allocating IP
addresses dynamically, enabling their reuse when hosts no longer need them
Echo Cancellation – When transmitting a signal, some of the energy may be
reflected back to the transmitter. For full duplex communication, this will interface with
a real signal being sent to the transmitter. A full duplex device can eliminate some of
this noise in a received signal by applying a correction signal derived from its
transmitted signal
Echo Control – The control of reflected signals in a telephone transmission path
E-1 – A wide-area digital transmission scheme: 2,048 Mbits/s; 31 channels, 64 Kbps
each
E.164 – The international public telecommunication numbering plan. An E.164 number
uniquely identifies a public network termination point and typically consists of three
fields, CC (Country Code), NDC (National Destination Code), and SN (Subscriber
Number), up to 15 digits in total
Endpoint – SIP or H.323 terminal or gateway
Failed Call – An attempted call that does not elicit a Connect message from the
destination host
Firewall – A system designed to prevent unauthorized access to or from a private
network
FR – Frame Relay, a packet-switching protocol for connecting devices on a WAN
H.323 – A standard approved by the ITU-T that defines how audiovisual conferencing
data is transmitted across networks. It is an umbrella of standards for packet-based
multimedia communications systems. This standard defines the different multimedia
entities that make up a multimedia system – endpoints, gateways, MCUs, and
gatekeepers – and their interaction. This standard is used for many VoIP applications
Hop off – In VoIP, hop off is a point or gateway at which a call moves from an H.323
network to a network that uses some other protocol, typically at a gateway
G-G – Ground to Ground
Gate keeper – A gatekeeper is a management tool for H.323 multimedia networks. A
single gatekeeper controls interactions for each zone, which comprises the terminals,
MCUs, and gateways within a particular domain. Depending on the demands of the
specific network, the gatekeeper oversees authentication, authorization, telephone
directory, and PBX services, as well as call control and routing. Other functions may
include monitoring the network for load balancing and real-time network management
applications, intrusion detection and prevention, and providing interfaces to legacy
systems
Gateway – In IP telephony, a network device that converts voice and fax calls, in real
time, between the public switched telephone network and IP network
GRP – Generation Partnership Project
GRQ – Gatekeeper Request

© EUROCAE, 2009
 176

ICAO – International Civil Aviation Organization

IEs – Information Elements
IETF – The Internet Engineering Task Force is the body that defines standard Internet
operating protocols such as TCP/IP. The IETF is supervised by the Internet Society
Internet Architecture Board (IAB). IETF members are drawn from the Internet
Society's individual and organization membership. Standards are expressed in the
form of Requests for Comments (RFCs) and Standards (STD)
IP – Internet Protocol: A layer 3 (network layer) protocols that contains addressing and
control information that allows packets to be routed. Defined in RFC 791 (IPv4) and
RFC 2460 (IPv6)
IPSec – IP security, a set of protocols being developed by the IETF to support secure
exchange of packets at the IP layer
Internet Telephony – Generic term used to describe various approaches to running
voice telephony over IP
ISDN – Integrated Services Digital Network: An international communications
standard for sending voice, data, and video over digital telephone lines or normal
telephone wires
ISP – Internet Service Provider: A business that enables individuals and companies to
connect to the Internet by providing the interface to the backbone
ITU-T – International Telecommunication Union: An international body of member
countries whose task is to define recommendations and standards relating to the
international telecommunications industry
Jitter – In voice over IP (VoIP), jitter is the variation in the time between packets
arriving, caused by network congestion, timing drift, or route changes. A jitter buffer
can be used to handle jitter
Latency – In a network, latency, a synonym for delay, is an expression of how much
time it takes for a packet of data to get from one designated point to another.
LAN – Local Area Network, a network covering a relative small geographic area
Load Balancing – Distribution of calls among terminating nodes based on the
priorities and weights assigned by the switches to optimize quality of service
LRQ – Location Request
MCU – Multipoint Control Unit, a device in videoconferencing that connects two or
more audiovisual terminals together into one single videoconference call. The MCU
collects information about the capabilities of the systems at each of the
videoconference endpoints and sets the conference at the lowest common
denominator so that everyone can participate
MGCP – Media Gateway Control Protocol, a protocol complementary to H.323 and
SIP, designed to control media gateways from external call control elements in
decomposed gateway architectures
MOS – Mean Opinion Score, a system of grading the voice quality of telephone
connections. The MOS is a statistical measurement of voice quality, derived from a
large number of subscribers judging the quality of the connection
MPLS – Multi-Protocol Label Switching, an IETF initiative that integrates layer 2
information about network links (bandwidth, latency, utilization) into layer 3 (IP) within
a particular autonomous system in order to simplify and improve IP packet exchange
Node – Physical equipment such as switch, computer, terminal, router that terminates
one or more network segments
Packet – A logical grouping of information that includes a header and user data
Packet Loss Rate – The measured loss of data packets, over a specific time period,
as a percentage of the total packet traffic transmitted

© EUROCAE, 2009
 177

PPP – Point-to-Point is a layer 2 protocol which provides router-to-router and

computer-to-network connections across a wide area circuit
PBX – Private Branch eXchange is a private telephone network used within an
enterprise. Users of the PBX share a certain number of outside lines for making
telephone calls external to the PBX
PGP – Pretty Good Privacy
Protocol – A formal description of a set of rules and conventions that govern how
devices on a network exchange information
Protocol Stack – Related layers of protocol software that function together to
implement particular communications architecture. Example: OSI reference model
PSTN – Public Switched Telephone Network, a general term referring to the variety of
telephone networks and services in place worldwide
PINT – PSTN/Internet Networking
PVC – Permanent Virtual Circuit, a virtual circuit that is permanently available
PCM – Pulse Code Modulation, transmission of analog information in digital form
through sampling, and encoding the samples with a fixed number of bits
Q.931 – ISDN connection control protocol, roughly comparable to TCP in the TCP/IP
stack. Q.931 does not provide flow control or retransmission capabilities, because the
underlying layers are assumed to be reliable and the circuit-oriented nature of ISDN
allocates bandwidth in fixed increments of 64 Kbps. In H.323 scenario, this protocol is
encapsulated in TCP
QoS – Quality of Service. It is a measure of performance for transmission systems
that reflects its transmission quality and service availability. Standards-based QoS for
VoIP usually involves the implementation of Ethernet standards 802.1p and 802.1q at
layer 2 across an Ethernet. At layer 3, the IP standard DiffServ defines bit setting in
the IP header which will identify packets as being associated with a specific service
QSIG – Q (point of ISDN model) signaling, system between a PBX and CO, or
between PBXs to support enhanced features such as forwarding and follow me
Radio Station – An aeronautical telecommunication station having responsibility for
handling communication between ground station(s) and aircraft in given area
RAS – The Registration, Admission and Status channel is used to carry messages
used in the gatekeeper discovery and endpoint registration processes which associate
an endpoint alias address with its call signaling channel transport address
Router – A networking device for forwarding packets and interconnecting nodes that
may belong to homogeneous or non-homogeneous networks. A router is a
sophisticated device that operates at the network layer
RSVP – Resource ReSerVation setup Protocol is designed for an integrated services
Internet. It is used by a host on behalf of an application data stream to request a
specific quality of service from the network for particular data streams or flows. It is
also used by routers to deliver QoS control requests to all nodes
RTCP – RTP Control Protocol, a protocol providing support for applications with real-
time properties, including timing reconstruction, loss detection, security, and content
identification. RTCP provides support for real-time conferencing for large groups within
an Internet, including source identification and support for gateways (like audio and
video bridges) and multicast-to-unicast translators. Define in RFCs 2205-2209
RTP – Real-Time Transport Protocol, the standard protocol for streaming applications
developed within IETF RFC 3550. RTP is designed to provide end-to-end network
transport functions for applications transmitting real-time data, such as audio, video, or
simulation data over multicast or unicast network services

© EUROCAE, 2009
 178

RTSP – Real-Time Streaming Protocol is a control protocol that initiates and directs
delivery of streaming multimedia data from media servers. Its role is to provide the
remote control (i.e., signaling); the actual data delivery is done separately, most likely
by RTP.
RTT – Round Trip Time it is a measure of the time it takes for a packet to travel from a
computer, across a network to another computer, and back.
Server – A computer device on a network that manages network resources
SDP – provides multimedia sessions for the purpose of session announcement,
session invitation and other forms of multimedia session initiation.
Signaling – Commands between devices to manage call sessions (e.g., call set
up/tear down)
SIP – Session Initiation Protocol, an application layer control, a signaling protocol for
Internet Telephony. SIP can establish sessions for audio/videoconferencing,
interactive gaming, and call forwarding to be deployed over IP networks. It enables
service providers to integrate basic IP telephony services with user authentication,
redirect and registration services. SIP servers support traditional telephony features
such as personal mobility, time-of-day routing and call forwarding based on the
geographical location of the person being called
SNMP – Simple Network Management Protocol, a protocol for managing complex
networks. SNMPv1 reports only whether a device is functioning properly. SNMPv3
provides additional information, in a secure fashion
SRTP – The secure Real-time Transport Protocol it integrates with RTP and RTCP as
an optional layer of security in the protocol stack
Switch – Electronic device which opens or closes circuits, changes operating
parameters, or selects paths either on a frequency or time division basis
SVC – Switched Virtual Circuit, a virtual circuit that is dynamically established on
demand and is torn down when transmission is completed. An SVC is used in
situations where data transmission is sporadic
T-1 – 1.544-Mbps point-to-point dedicated digital circuit provided by telephone
companies consisting of 24 channels
T-3 – The digital signal carried on a North America high-speed facility operating at
approximately 45 Mbps
Terminal – a device that enables a person to communicate with a host or network
TCP – Transmission Control Protocol, a connection-oriented transport (layer 4)
protocol that provides reliable full-duplex data transmission
TLS – Transport Layer Security, a security protocol based on SSL. TLS uses digital
certificates to authenticate the user as well as the network
Trunk – A communications channel between two nodes, typically referring to large
bandwidth telephone channels between switches or routers that handle many
simultaneous voice and data signals
UDP – User Datagram Protocol is a connection-less protocol that runs on top of IP
networks. UDP provides very few error recovery services, offering instead a direct way
to send and receive datagram over an IP network. It is used primarily for broadcasting
and voice messaging over an IP network
VoIP – Voice over Internet Protocol, the capability to carry normal telephone-style
voice over an IP-based internet with acceptable reliability and voice quality. VoIP
enables a router to carry voice traffic over an IP network
VPDN – Virtual Private Dial-Up Network, also known as virtual private dial network. A
VPDN is a network that extends remote access to a private network using a shared
infrastructure. VPDNs use layer 2 tunnel technologies to extend the layer 2 and higher
parts of the network connection from a remote user across an ISP network to a private
network

© EUROCAE, 2009
 179

VPN – Virtual Private Network enables IP traffic to travel securely over a public
TCP/IP network by encrypting all traffic within its domain. A VPN uses “tunneling” to
encrypt all information at IP Level
WAN – Wide Area Network, data communications network that serves users across a
broad geographic area and often uses transmission devices provided by common
carriers

© EUROCAE, 2009
 180

LIST OF FIGURES
FIGURE 1 VIENNA AGREEMENT ................................................................................................................. 2
FIGURE 2 CONSIDERED VOICE APPLICATIONS IN WG67 ....................................................................... 3
FIGURE 3 IP NETWORK DOMAIN CONCEPT.............................................................................................. 4
FIGURE 4 SUBGROUP 3 PARTICIPATION (NO PATICULAR ORDER) ...................................................... 5
FIGURE 5 VOIP ARCHITECTURE & LAYERS .............................................................................................. 8
FIGURE 6 INTEGRATED NETWORK............................................................................................................ 10
FIGURE 7 VOIP INTERFACE TO PSTN VIA ATS GATEWAY ...................................................................... 11
FIGURE 8 EXAMPLE OF A CONVERGED VOIP NETWORK ....................................................................... 11
FIGURE 9 H.323 ARCHITECTURE ............................................................................................................... 19
FIGURE 10 SIP ARCHITECTURE ................................................................................................................. 20
FIGURE 11 VOIP WITH SIP........................................................................................................................... 23
FIGURE 12 IPV4 AND IPV6 HEADER ........................................................................................................... 25
FIGURE 13 PROPOSED IPV6 ADDRESS STRUCTURE.............................................................................. 28
FIGURE 14 TYPICAL VOIP COMPONENT ARCHITECTURE ...................................................................... 30
FIGURE 15 SYSTEM AVAILABILITY OF ELEMENTS IN SERIES ................................................................ 39
FIGURE 16 SYSTEM AVAILABILITY OF ELEMENTS IN PARALLEL ........................................................... 39
FIGURE 17 NETWORK ELEMENTS AND DESIGN ...................................................................................... 40
FIGURE 18 NETWORK AVAILABILITY OF DIFFERENT DESIGNS ............................................................. 41
FIGURE 19 MULTIPLE SPANNING TREE PROTOCOL ............................................................................... 44
FIGURE 20 LINK AGGREGATION CONTROL PROTOCOL ......................................................................... 47
FIGURE 21 UNI-DIRECTIONAL LINK DETECTION ...................................................................................... 48
FIGURE 23 IGP ROUTING PROTOCOL EXAMPLE ..................................................................................... 57
FIGURE 23 INITIALIZATION AND OPERATION OF HEADER COMPRESSION PROTOCOLS .................. 65
FIGURE 24 CUMULATIVE TRANSMISSION PATH DELAY ......................................................................... 69
FIGURE 25 SOURCES OF DELAY................................................................................................................ 70
FIGURE 26 JITTER........................................................................................................................................ 73
FIGURE 27 ROUND TRIP DELAY WITHIN DFS WAN (EXTRACT).............................................................. 75
FIGURE 28 LARGE PACKETS ‘FREEZE OUT’ VOICE................................................................................. 76
FIGURE 29 FRAGMENTATION OF DATA PACKETS................................................................................... 76
FIGURE 30 NETWORK DELAY OVERVIEW................................................................................................. 78
FIGURE 31 DEFINITION OF QOS................................................................................................................. 81
FIGURE 32 DEFINITION OF A PIPE ............................................................................................................. 81
FIGURE 33 INTEGRATED MULTISERVICE NETWORK .............................................................................. 82
FIGURE 34 RESOURCE RESERVATION ARCHITECTURE ........................................................................ 84
FIGURE 35 TOKEN BUCKET MODEL .......................................................................................................... 85
FIGURE 36 RSVP FUNCTIONAL BLOCKS ................................................................................................... 86
FIGURE 37 RSVP SIGNALING...................................................................................................................... 87
FIGURE 38 DIFFERENTIATED SERVICES FIELD (DS FIELD).................................................................... 89
FIGURE 39 DIFFSERV NETWORK ARCHITECTURE .................................................................................. 90
FIGURE 40 DIFFSERV ARCHITECTURE (SIMPLIFIED) FOR EDGE ROUTERS ........................................ 91
FIGURE 41 LABEL ENCAPSULATION.......................................................................................................... 93
FIGURE 42 MPLS NETWORK ARCHITECTURE .......................................................................................... 94
FIGURE 43 MPLS - SWITCHING EXAMPLE................................................................................................. 95
FIGURE 44 PRIORITY FIELD IN LAYER 2 802.1Q/P.................................................................................... 98
FIGURE 45 EXAMPLE OF A MANAGED SEGMENT .................................................................................... 100
FIGURE 46 FIFO, FIRST IN FIRST OUT ....................................................................................................... 101
FIGURE 47 PRECEDENCE QUEUING ......................................................................................................... 101
FIGURE 48 CLASS BASED QUEUING ......................................................................................................... 102

© EUROCAE, 2009
 181

FIGURE 49 WEIGHTED BIT-WISE SCHEDULING ....................................................................................... 102

FIGURE 50 WEIGHTED FAIR QUEUING ...................................................................................................... 102
FIGURE 51 QUEUE MANAGEMENT............................................................................................................. 103
FIGURE 52 RSVP – DIFFSERV INTEGRATION ........................................................................................... 105
FIGURE 53 INTERWORKING OF QOS PROTOCOLS ................................................................................. 105
FIGURE 54 PIM-SM ARCHITECTURE .......................................................................................................... 113
FIGURE 55 PIM-SSM ARCHITECTURE........................................................................................................ 114
FIGURE 56 BIDIR-PIM ARCHITECTURE ...................................................................................................... 114
FIGURE 57 IPV4 ADDRESSING FORMAT ................................................................................................... 129
FIGURE 58 IPV6 ADDRESSING FORMAT ................................................................................................... 130
FIGURE 59 TYPE OF UNICAST ADDRESSING FORMAT ........................................................................... 131
FIGURE 60 ANYCAST ADDRESSING FORMAT .......................................................................................... 131
FIGURE 61 RESERVED SUBNET ANYCAST ADDRESS FORMAT WITH EUI-64 INTERFACE IDENTIFIERS 132
FIGURE 62 IPV6 WITH EMBEDDED IPV4 ADDRESS.................................................................................. 132
FIGURE 63 MULTICAST ADDRESSING FORMAT ....................................................................................... 132
FIGURE 64 IPSEC HEADER ......................................................................................................................... 141
FIGURE 65 ESP HEADER IN TRANSPORT AND TUNNEL MODE.............................................................. 142
FIGURE 66 MIDDLEBOX CONCEPT ............................................................................................................ 151
FIGURE 67 IPS CONCEPTS ......................................................................................................................... 153

LIST OF TABLES
TABLE 1 AUTHORS AND CONTRIBUTORS OF THIS DOCUMENT............................................................ 5
TABLE 2 CODEC PERFORMANCE FACTORS ............................................................................................ 16
TABLE 3 EXAMPLE OF VOIP HEADER ........................................................................................................ 17
TABLE 4 PROMINENT CODEC CHARACTERISTICS .................................................................................. 18
TABLE 5 COMPARISON OF H.323 AND SIP CAPABILITIES ....................................................................... 21
TABLE 6 AVAILABILITY FIGURES................................................................................................................ 38
TABLE 7 BANDWIDTH DEMAND PER VOIP CALL (KBPS) ......................................................................... 62
TABLE 8 ONE-WAY DELAY SPECIFICATIONS............................................................................................ 69
TABLE 9 PROCESSING DELAY.................................................................................................................... 70
TABLE 10 ALGORITHMIC DELAY................................................................................................................. 71
TABLE 11 PACKETIZATION DELAY ............................................................................................................. 71
TABLE 12 SERIALIZATION DELAY............................................................................................................... 72
TABLE 13 AVERAGE ROUND TRIP TIMES ON THE INTERNET ................................................................ 75
TABLE 14 ROUND TRIP DELAY FROM SITA'S IPVPN NETWORK (EXTRACT)........................................ 75
TABLE 15 EXAMPLE OF FIXED DELAY CALCULATION ............................................................................. 79
TABLE 16 COMPARISON OF QOS PROTOCOLS ....................................................................................... 104
TABLE 17 COMPARISON OF PIM MODES .................................................................................................. 116
TABLE 18 COMPARISON OF RP ELECTION/MANAGEMENT .................................................................... 117
TABLE 19 COMPARISON OF IGMP.............................................................................................................. 117
TABLE 20 MULTICAST FOR IPV6................................................................................................................. 118
TABLE 21 NUMERIC RANGES ..................................................................................................................... 130
TABLE 22 IPV6 MAIN ADDRESSING TYPE.................................................................................................. 131
TABLE 23 IPV4 AND IPV6 EQUIVALENT ..................................................................................................... 133
TABLE 24 IPSEC AND INTRODUCED DELAY ............................................................................................. 143
TABLE 25 IPSEC AND MPLS-BASED VPN COMPARISON ......................................................................... 163

© EUROCAE, 2009