network requirements and performances for voice over

network requirements and performances for voice over

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 1: NETWORK SPECIFICATION

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 1

February 2009

102 rue Etienne Dolet

92240 MALAKOFF, France

Web Site: www.eurocae.net

Tel: 33 1 40 92 79 30

Fax: 33 1 46 55 62 65

Email: [email protected]

NETWORK REQUIREMENTS AND PERFORMANCES FOR VOICE

OVER INTERNET PROTOCOL (VOIP) AIR TRAFFIC MANAGEMENT

(ATM) SYSTEMS

PART 1: NETWORK SPECIFICATION

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 1

February 2009

© EUROCAE, 2009

i

FOREWORD

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 qualify Network interconnecting VoIP ATM

Systems”.

6

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.

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: [email protected]

Web Site: www.eurocae.net

© EUROCAE, 2009

ii

TABLE OF CONTENTS

FOREWORD .......................................................................................................................... I

TABLE OF CONTENTS .................................................................................................................. II

CHAPTER I INTRODUCTION .............................................................................................. 1

1.1. Background....................................................................................................... 1

1.3. Terminology for requirements, recommendations, and options .......................

3

CHAPTER I REFERENCES............................................................................................................ 4

CHAPTER II NETWORK SPECIFICATION........................................................................... 5

2.1.1. Operational Voice Applications in ATM.............................................

6

2.1.2. Numbering of Requirements, Recommendations and Options.........

6

Network Services Requirements .................................................

7

2.3.

8

Network Functional and Performance Requirements....................................... 9

2.3.3. Availability.......................................................................................... 10

2.3.4. Class of Service CoS and Quality of Service QoS............................ 10

2.5.

2.4.2. Configuration Management ...............................................................

13

2.4.3. Performance Management................................................................ 13

Specific Safety and Security Requirements ..................................................... 14

2.5.2. Security Management ....................................................................... 14

CHAPTER II REFERENCES........................................................................................................... 16

CHAPTER III SECURITY POLICY ......................................................................................... 17

3.1. Background....................................................................................................... 17

3.2.1. Confidentiality .................................................................................... 17

3.2.2. Integrity.............................................................................................. 17

3.2.3. Availability.......................................................................................... 18

3.3.1. Threats

18

© EUROCAE, 2009

iii

3.5.1. Zone 1 (IP Core)................................................................................

21

3.5.2. Zone 2 (Access to the shared IP Core)............................................. 21

3.5.3. Zone 3 (ANSPs and other related Organizations Domain) ...............

22

CHAPTER III REFERENCES.......................................................................................................... 24

CHAPTER IV IP ADDRESSING.............................................................................................. 26

4.1. Background....................................................................................................... 26

4.2. Addressing Scheme (Revised iPAX Scheme).................................................. 32

ANNEX A NETWORK ADDRESS ASSIGNMENTS .......................................................................

34

CHAPTER IV REFERENCES .........................................................................................................

37

LIST OF EUROCAE WG-67 CONTRIBUTORS.............................................................................. 38

© 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.

• 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” was 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

The purpose of this document is to specify the network requirements and the needs of

VoIP services for ATM applications in the network - including IP Adressing and

Security - that are to provide the necessary high levels of availability, integrity, performance and Quality of Service (QoS) for VoIP in ATM applications.

ED-138 is divided into two parts:

ED-138 Part 1 (this document) o o o

Network Specification

Security Policy

IP Addressing Plan

ED-138 Part 2 [1]: o

Network Design Guideline

*

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

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

Each chapter in this document is independently referenced, where applicable.

© EUROCAE, 2009

1.3

3

TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS, AND OPTIONS

The terminology for requirements, recommendations, and options in this document is based on RFC 2119 [2], which specifies Best Current Practice regarding the use of

Key Words for the Internet Community. As such, the following terminology is applied:

To avoid confusion with their natural meanings in the English language, the words

SHALL, SHOULD, and MAY take on the meaning stated above only where printed in boldface. When printed in normal (Arial) typeface, the natural English meaning is meant.

Detailed description of terminology:

The key words "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT" and "MAY” in this document are to be interpreted as described in RFC 2119.

1. SHALL This word has the same meaning as the phrase "REQUIRED" and means that the definition is an absolute requirement of the specification.

2.

SHALL NOT

This phrase means that the definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.

5.

MAY

This word, or the adjective "OPTIONAL", mean that an item is truly optional.

© EUROCAE, 2009

4

CHAPTER I REFERENCES

[1] ED-138 Network Requirements and Performances for VoIP ATM Systems Part

2: Network Design Guideline; http://www.eurocae.net

[2] IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels; http://www.ietf.org/rfc/rfc2119.txt

© EUROCAE, 2009

5

CHAPTER II

NETWORK SPECIFICATION

For the purposes of this document, the reference architecture for specifying network requirements of VoIP in ATM is shown in Figure 2, based upon the “Vienna

Agreement”.

Network

FIGURE 2 - WG67 VIENNA AGREEMENT INCLUDING NETWORK CONCEPT

© EUROCAE, 2009

6

2.1.1 Operational Voice Applications in ATM

Eurocontrol EATM

1

G-G Communications Strategy plans to integrate ATM IP Voice communications with the ATM IP Data Network from 2010 onwards.

WG-67 assumed the responsibility to define the specification of VoIP for ATM

Systems to include the service types as described in Table 1.

SERVICE TYPE APPLICATION DESCRIPTION

GROUND

COORDINATION

AIR GROUND

SERVICES

A-G Voice

Principally for Centre/Centre and Centre/Tower coordination within an Air Navigation Service Provider

(ANSP) domain and between neighbouring ANSPs

This communication is between Voice Communication

Systems (VCS), as shown in Figure 3.

Principally nationally based but SES

2

may require transnational ground connectivity.

WG-67 only considered communication between VCS and

Radio without air links.

TABLE 1 - OPERATIONAL VOICE APPLICATIONS IN ATM

RADIO

WAN

VoIP

2.1.2

VCS 1

VCS 2

VCS = Voice Communication System

FIGURE 3 - CONSIDERED VOICE APPLICATIONS IN WG67

Numbering of Requirements, Recommendations and Options

All Requirements, Recommendations and Options in this chapter are marked with a cardinal number in brackets on the left side of the paragraph.

2

1

European Air Traffic Management

Single European Sky; http://www.eurocontrol.int/ses/public/subsite_homepage/homepage.html

© EUROCAE, 2009

7

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 4 shows the different Network domains and their terminology.

IP

IP

IP

IP

2.2

IP

IP

IP

LAN

IP

EDGE WAN EDGE

LAN

FIGURE 4 - IP NETWORK DOMAIN CONCEPT

SPECIFIC NETWORK AND SERVICES REQUIREMENTS

The IP [2] [3] infrastructure will be expected to provide smooth delivery of voice and signalling packets to the end systems. To support this, voice and data traffic are expected to be prioritized differently on the network, to accommodate the extra sensitivity of voice traffic to latency and because voice is a continuous streaming that should not be interrupted.

In addition, factors such as jitter, packet loss, security, and incompatibility can affect the quality of communication services, and need to be handled by the IP infrastructure.

© EUROCAE, 2009

2.2.1

2.2.2

8

These and other issues are to be addressed by the following requirements.

(1) The IP network SHALL be compliant with the following criteria to fulfil ATM

Voice communication needs:

Performance (e.g., bandwidth, response times for call set up and tear down, maximum latency, packet throughput, maximum packet size)

QoS/CoS mechanisms (e.g., prioritization of traffic classes to minimize jitter and packet loss)

• Reliability/Availability

• Security

(2) The IP network SHALL be able to support:

Signalling requirements (e.g., SIP)

Voice media requirements (e.g., RTP/RTCP)

Detailed explanations of these criteria are provided in this document and solutions are given in the ED-138 Network Requirements and Performances for VoIP ATM Systems

Part 2: Network Design Guideline [4].

IP Addressing and Protocols

(3) IPv6 (RFC 2460) SHALL be supported by the IP Network.

A detailed explanation of IP Addressing criteria is provided in Chapter IV.

(5) The transport of Multicast traffic according to PIM SSM (RFC 3569) SHALL be supported by the IP Network for an efficient distribution of audio streams.

A detailed explanation of Multicast criteria is provided in ED-138 Network

Requirements and Performances for VoIP ATM Systems Part 2: Network Design

Guideline chapter V.

IP Networking and Routing

(6) Native Routing of IPv6 packets SHALL be supported by the EDGE; IPv6 transportation SHALL be supported by the WAN and LAN.

(7) Border Gateway Protocol Version 4+ (BGP4+) [5] and static/default routing

SHALL be supported by the WAN entry point in order to properly route traffic between WANs.

(8) Open Shortest Path First (OSPF) [6] SHOULD be supported within the WAN domain.

A detailed explanation of Routing criteria is provided in ED-138 Network Requirements

and Performances for VoIP ATM Systems Part 2: Network Design Guideline chapter

III.

© EUROCAE, 2009

9

2.2.3 Applications and Quality of Service (QoS) requirements

Application

(9) The IP Network SHALL be able to support the applications with Quality of

Service QoS shown in Table 2. Typically these QoS parameters are defined in

Service Level Agreements (SLA’s).

(10) The IP Network SHALL be able to distinguish between different Classes of

Service (CoS) and different requirements regarding delay, jitter, bandwidth demand, and packet loss. The different requirements are shown in Table 2.

Typical packet length

1. payload only

2. with CRTP

3. with CRTP and

IPSec

Acceptable latency

3

(without jitter)

Acceptable Jitter

3

Acceptable

Packet Loss rate

Default

(best effort)

Telephone voice

Radio voice

1. 160 Bytes

2. 164 Bytes

3. 212-222 Bytes

1. 160 Bytes

2. 164 Bytes

3. 212-222 Bytes

100ms

50ms

15ms

15ms

0.5%

0.5%

Telephone

Signalling

Radio

Signalling

Recording

100ms

50ms

4

4

100ms

50ms

50ms

50ms

TABLE 2 - APPLICATION REQUIREMENTS

0.5%

0.5%

0.5%

2.3 NETWORK FUNCTIONAL AND PERFORMANCE REQUIREMENTS

(11) Ethernet according to IEEE 802.3 standards SHALL be available in the LAN environment for the access of client devices to the IP network.

(12) For legal recording local physical Ports which duplicates traffic (Span or Mirror

Port) MAY be available in LAN.

(13) If manual compensation mode for Climax

5

is chosen, fixed network paths

SHOULD be used in the IP Network.

5

4

3

All latency values are one-way delays

Value is given for the network path between two elements involved in the call-setup

Multi-station carrier offset mode, with voting override

© EUROCAE, 2009

10

A detailed explanation of these criteria is provided in ED-138 Network Requirements

and Performances for VoIP ATM Systems Part 2: Network Design Guideline chapter

IV.

(14) Maximum amount of possible concurrent voice calls (voice channels) V max

and signalling (signalling channels) S max

which are necessary for operational purposes SHALL be defined for IP Network (for each network-path especially edges). For the WAN area of the network, SLA’s SHALL be signed with the

WAN Provider in order to ensure the required performances in terms of bandwidth needed.

(15) The IP Network SHALL be able to accommodate up to V max

+ S max

concurrent channels.

(16) For this maximum amount of channels V max

+ S max

, the following parameters

SHALL not be exceeded in the IP Network: acceptable packet loss rate, acceptable latency, and acceptable jitter. These parameters are dependent on

Service Class (see Table 2). If this requirement cannot be fulfilled in exceptional cases (e.g., delay in long distance connections, loss of bandwidth), the proper function of the Voice calls associated with the Expedited Forwarding (EF) Class

(see Table 4) SHALL be assured. compression on low speed links and IPsec MAY not be used at the same time for the same service.

2.3.3 Availability

Availability is the probability that the network 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.

2.3.4

Note: Availability depends on the overall system architecture and usage of redundancy and backup-features and last resorts/emergency systems.

A detailed explanation of these criteria is provided in ED-138 Network Requirements

and Performances for VoIP ATM Systems Part 2: Network Design Guideline chapter

III.

Class of Service CoS and Quality of Service QoS

(19) Classification: IP Network SHALL provide methods of categorizing traffic into different classes, also called Class of Service (CoS), and applying QoS parameters to those classes. IP Network SHALL be able to reapply CoS and

QoS parameters to the packets sourced by different systems in the network, in order to ensure the proper functionality.

Class of Service in the LAN area, according to the IEEE 802.1p and IEEE

802.1q standards, based on a common schema among different participants in the network (ANSPs). IP Network SHALL provide methods of prioritising traffic based on Class of Service in the Edge and WAN area.

QoS architecture and SHOULD support the mapping of different service or traffic classes to Differentiated Service Code Point DSCP.

(22) The DSCP mapping SHALL be configurable when using Diffserv.

© EUROCAE, 2009

11

(23) When there is an unrecognized DSCP, assigned traffic SHALL be treated according to a default Per-hop-behaviour PHB that is ‘Best effort’.

(24) When using Diffserv the DSCP SHALL be set by the six most significant bits of

‘Traffic Class’ byte in IPv6 header. ‘Traffic Class’ SHALL be set by the VoIP

ATM application.

(25) When using Diffserv the DSCP SHALL be used and encoded for cross border communication as follows (see Table 3):

Eight Class Selector Codepoints compatible with IPv4 and IP Precedence

(CS0-7)

An Expedited Forwarding (EF) Class

IP packets are forwarded in N independent AF classes, each having M different levels of drop precedence. Therefore, the Codepoints with the classes and drop precedence form a matrix AF ij

, where 1

≤ i ≤ N and 1 ≤ j

≤ M. Four classes (N=4) are defined with three Drop Precedences (M=3).

Packets in a higher AF Classes SHOULD have a higher transmit priority

Packets with a higher Drop Precedence SHOULD be more likely to be dropped

DSCP value Codepoint DSCP value Codepoint

AF31

001000 CS1 011100 AF32

001010 AF11 011110 AF33

001100 AF12 100000 CS4

001110 AF13 100010 AF41

010000 CS2 100100 AF42

010010 AF21 100110 AF43

010100 AF22 101000 CS5

010110 AF23 101110 EF

011000 CS3 110000 CS6

TABLE 3 - DSCP VALUES

© EUROCAE, 2009

12

(26) For cross border communication the IP Network SHOULD set the DSCP field of outgoing packets to the values shown in Table 4.

Default

(best effort)

000000 CS0

Telephone voice

Radio voice

Telephone signalling

Radio signalling

Recording voice

101110

100010

011010

EF

AF41

AF31

TABLE 4 - DSCP MAPPING

Note:

Class Selector code points (CS1-7) are reserved and could be used for backward compatibility with IP Precedence.

(27) When using Diffserv the DSCP mapping in the IP Network SHOULD be used for national purposes as shown in

Table 4

.

Definitions and Standards of Diffserv and DSCP, IPv6 Traffic Class and IP

Precedence can be found in ED-138 Network Requirements and Performances for

VoIP ATM Systems Part 2: Network Design Guideline chapter IV.

2.3.5 Maintenance and Diagnostics

2.4

(28) The IP Network SHALL have the capability to conduct maintenance and diagnostic procedures to support the quality and performance requirements.

NETWORK MANAGEMENT AND PROCEDURES

The goal of fault management is to detect, filter, log, notify users of (e.g., trigger alarms), and automatically fix network problems, when possible, to keep the network running effectively. Because faults can cause downtime or unacceptable network degradation, fault management is perhaps the most widely implemented in network management elements. A graphical view of network topology is used to indicate network element connectivity and faults in real time.

Fault statistics are aggregated to compile long-term failure trends. For example, availability, reliability, and maintainability metrics may be compiled to assess network service compliance with service level agreements. necessary actions in order to report the failure, complete diagnosis, and fix network problems.

(30) Preventive fault management actions SHALL be prescribed and maintained to ensure the availability of primary and backup paths and components for the IP

Network.

© EUROCAE, 2009

13

The goal of configuration management is to monitor and control network configurations so that the effects on network operation of various types and versions of hardware and software elements can be tracked and managed.

The VoIP infrastructure changes dynamically, as various devices and their links are brought on and off line, and when their naming and addressing plans are adjusted.

Additionally, many of these devices host various types of software, each with its own release, version, and other identifying information, such as:

Network Manager Platform

Switch, router, and gateway platforms and hosted software

Traffic prioritization

The configuration management subsystem displays and highlights changes of network elements in real time. It also makes this information available for retrieval. All changes to system hardware and software configurations are effected through the configuration management subsystem. When a problem occurs, this archive can be searched for clues that may help solve the problem.

(31) The IP Network SHALL have a capability to monitor and control network configurations so that the effects on network operation of various types and versions of hardware and software elements can be tracked and managed.

The goal of performance management is to measure and optimize various aspects of network performance to maintain overall quality of service at an acceptable level.

Examples of performance variables that might be monitored include available bandwidth, jitter, latency, response times, and packet loss.

Within the purview of performance management fall the following disciplines:

Performance measurement – The measurement of performance variables at the network and application levels to ascertain compliance with Service Level

Agreements. Tools are available at the appropriate protocol layers to monitor these variables, trigger alarms when exceeding thresholds, and aggregate statistics for reporting.

Forensic analysis – The detailed analysis of protocol message exchanges for determining causes of performance degradation (e.g., packet retransmissions, handshake timeouts)

Capacity planning – The use of modeling techniques to predict the impact of new applications and increased loading on network performance

Bandwidth on demand – Dynamic allocation of network capacity based on utilization and traffic class

Load generation – Stress testing of networks with scripted usage loads to identify service saturation levels

(32) The IP Network SHALL have a capability to measure performance variables at the network level to ascertain compliance with Service Level Agreements. explained above.

(34) The IP Network MAY have a capability to perform Capacity planning and

Bandwidth on demand as explained above.

© EUROCAE, 2009

2.5

2.5.1

14

SPECIFIC SAFETY AND SECURITY REQUIREMENTS

An important consideration for safety and security is the implementation of mechanisms to ensure that voice communication services are delivered with acceptable security and availability for controllers in various ATM systems. Key requirements are as follows:

Priority for critical information (e.g., emergency call)

Tools that could support these requirements include:

Secure real-time transport protocol (SRTP)

Security and encryption using IP Security (IPsec)

Security Policy and requirements

(35) Security procedures and mechanisms SHALL be described for the IP Network to protect against security incidents; principles of Security Policy (CHAPTER III)

SHALL be used.

(36) Static firewalling rules MAY be used for Raw RTP sessions in the IP Network.

The goal of security management is to control access to network resources in accordance with the following criteria:

Authentication – Verify the person attempting to access a resource or service

Authorization – Verify that the user is permitted to perform certain operations offered by a resource or service

Packet integrity – Verify the integrity of the cryptographic data checksum that confirms the integrity of unaltered packets

Auditing – Historical tracking of logs used in postmortem investigations as a result of security incidents or proactive precautionary measures

Aside from securing the enterprise data, security management must also ensure that the infrastructure (e.g., network, servers) cannot be sabotaged intentionally or unintentionally. A security management subsystem, for example, can monitor users logging on to a network resource and can refuse access to those who enter inappropriate access codes.

Security management subsystems work by partitioning network resources into authorized and unauthorized areas. For some users, access to any network resource is inappropriate, mostly because such users are usually company outsiders. For other

(internal) network users, access to information originating from a particular department is inappropriate.

Security management subsystems perform several functions. They identify sensitive network resources (including systems, messages, and other entities) and determine mappings between sensitive network resources and user sets. They also monitor access points to sensitive network resources and log inappropriate access to sensitive network resources.

© EUROCAE, 2009

15

(37) The IP Network SHALL have a capability to control access to network elements.

(38) The IP Network SHALL have a capability to perform proactive measures to protect against security incidents.

(39) The IP Network SHALL have a capability to perform security monitoring, logging and reporting.

(40) The IP Network SHALL have a capability to take immediate action in the event of detected security incidents to protect network integrity and performance.

© EUROCAE, 2009

16

CHAPTER II REFERENCES

[1] 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

[2] IETF RFC 791: Internet Protocol (IP) version 4; http://www.ietf.org/rfc/rfc791.txt

[3] IETF RFC 2460: Internet Protocol (IP) version 6 Specification; http://www.ietf.org/rfc/rfc2460.txt

[4] ED-138 Network Requirements and Performances for VoIP ATM Systems Part

2: Network Design Guideline; http://www.eurocae.net

[5] IETF RFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain

Routing

IETF RFC 2858: Multiprotocol Extensions for BGP-4 http://www.ietf.org/rfc/rfc2545.txt

; http://www.ietf.org/rfc/rfc2858.txt

[6] IETF RFC 2740: OSPF for IPv6 http://www.ietf.org/rfc/rfc2740.txt

© EUROCAE, 2009

17

CHAPTER III

SECURITY POLICY

3.1 BACKGROUND

Current ATM voice switching services for 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 costeffective 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 define the security policy for VoIP implementations to support ATM communications. This includes the required security architecture and component mechanisms. This policy only covers information security, and does not establish requirements for physical security.

Detailed technical solutions are not given in this chapter – they can be found in ED-

138 Network Requirements and Performances for VoIP ATM Systems Part 2.

The complexity of ATM security needs in a VoIP environment is best addressed with a comprehensive policy. This is based upon well-known security principles that encompass the network, application, and architectural domains. Relevant requirements and recommendations are described below.

3.2 ATM SECURITY PRINCIPLES

ATM communications security is characterized by the level of confidentiality, integrity, and availability provided by the supporting infrastructure and connected systems.

3.2.1 Confidentiality

Confidentiality ensures that the information is not disclosed to unauthorized persons or processes. The concept of confidentiality attempts to prevent the intentional or unintentional unauthorized disclosure of message content. Loss of confidentiality can occur in many ways, such as through the intentional release of privileged information or through a misapplication of network access rights. In the ATM environment, this could be important for sensitive air traffic situations (e.g., military and government flight missions).

3.2.2 Integrity

Integrity ensures that the information relayed from its source to its intended destination is authentic, complete, and accurate within specified parameters.

Integrity is enabled with the following approaches:

Prevention of the modification of information by unauthorized users

Prevention of the unauthorized or unintentional modification of information by authorized users

Preservation of the internal and external consistency

This is crucial for VoIP messaging for ATM, where corrupted or modified messages could incur safety risks for aviation.

© EUROCAE, 2009

18

3.2.3 Availability

Availability ensures that authorized users have timely and uninterrupted access to the information in the system within specified parameters. As such, availability establishes a quantifiable guarantee that the required information, systems and services are operationally functional when needed. This is important for ATM operations, where communication interruptions could result in safety issues and flight operations delays.

3.3.1

The key to securing VoIP is to use security policies and mechanisms analogous to those implemented in data-only networks (e.g., firewalls, encryption, gateways) to emulate the security level currently available to Private Switched Telephone Network

(PSTN) network users.

Threats in VoIP networks

Potential threats to a VoIP environment exploit vulnerabilities in end-points, servers, and other network elements. These threats can have impacts on confidentiality, integrity and availability of a VoIP system.

Confidentiality

Their impact on confidentiality may be exemplified regarding a communications node, where eavesdropping on conversations is an obvious concern, but the confidentiality of other information must also be protected to defend against toll fraud, voice and data interception, and denial of service attacks. Network IP addresses, operating system type, telephone number-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.

Integrity

Communication nodes must protect the integrity of critical system data (e.g., configuration messages). Because of the richness of feature sets available on nodes, an attacker who can compromise the system configuration can accomplish nearly any other goal. Damaging or deleting information about the IP network used by a VoIP node could result in a 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 network functions or data may be corrupted, either accidentally or because 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 operational function (e.g., by mistake or out of malice) and may cause deleterious modification, destruction, deletion, or disclosure of sensitive network 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.

© EUROCAE, 2009

19

Availability

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. A voice over IP system may have additional vulnerabilities due its exposure to the Internet. As such, attackers may be able to bring down VoIP systems by exploiting weaknesses in Internet protocols and services.

It is known that any network may be vulnerable to denial of service attacks, simply by overloading the capacity of the system and interrupting traffic flow. With VoIP, the problem may be especially severe, because of its sensitivity to packet loss or delay.

The most significant security concerns in a VoIP environment are:

Denial of Service (DoS) Attacks: Endpoints, such as IP telephones, and VoIP gateways (w/ embedded SIP proxies), can be attacked via bombardment with rogue packets to disrupt communications.

Call Interception: Unauthorized monitoring of voice packets or hacking of the

Real-Time Transport Protocol (RTP) [12].

Signal Protocol Tampering: Similar to call interception but for signalling traffic, a malicious user could monitor and capture the packets that set up the call. By doing this, they can manipulate fields in the data stream and interfere with communications, which could be used for a DoS attack.

Presence Theft: Impersonation of a legitimate user sending or receiving data

Assumption: Air Navigation Service Provider (ANSP) local domains (either owned and defined by a single ANSP, or shared within an ANSP group) or other related organization domains are operated and managed autonomously. These domains (that each may contain networks and hosts) do not necessarily have mutual trusting relationships with each other.

Based on this assumption a simplified model was created to define the different security zones, as follows:

Zone 1: IP Core (e.g., Pan European Network Service (PENS) or an alternative shared IPv4/IPv6 00[3] Backbone)

This zone is typically used for cross border communication.

Zone 2: Access (from Organizations to the shared IP Core infrastructure)

Zone 3: ANSPs and other related Organizations Domains

© EUROCAE, 2009

20

Security

Zone 1

Security

Zone 2

Security

Zone 3

IP Core

Edge

Possible Interconnections

IP Core

IP Core

Edge

IP Core

Edge

Demarcation Line

Organization

Edge

Organization

(WAN)

LAN

Organization

Edge

Organization

(WAN)

LAN

Organization

Edge

Organization

(WAN)

LAN

Admin

Network

FIGURE 5 - SIMPLIFIED NETWORK MODEL

Figure 5 shows a simplified model of a multi-national ATM communications network.

The model shows a logical view.

The IP Core is a service offered by a Service Provider (SP); the IP Core Edge is the customer premises equipment to be installed at the designated access point locations.

This could be a combination of devices (e.g., modems, switches, routers, and cables) in order to deliver the communication service.

The Demarcation Line is the border between the different responsibilities (i.e.,

Organization and Service Provider domains).

The Organization Edge could also be a combination of devices (e.g., modems, switches, routers, firewalls and cables) with connection to the IP Core Edge.

Organization and IP Core Edge might be located in the same shelf or computer room

– however different responsibilities are assigned as shown in the figure.

Interconnections between different organization networks are possible without using a shared IP media (e.g., using dedicated leased lines or TDM links).

Such arrangements (as shown in Figure 5 as Possible Interconnections between

Organization Domains) are only required to comply with the ANSP/Organization Edge requirements in Section 3.5.2.

© EUROCAE, 2009

21

This section describes the security requirements for the Security Zones shown in

Figure 5.

Zone 1 (IP Core) 3.5.1

Requirements:

• Edge-to-Edge encryption SHALL be available for the different connections, its actual use is to be specified in Service-Level-Agreements (SLA’s).

• Network Management services SHALL use encrypted and authenticated technologies (e.g.,

SSH, SNMPv3, IPSec, TLS) and/or Out-Of-Band technologies.

3.5.2 Zone 2 (Access to the shared IP Core)

Requirements and recommendations:

Common requirements

• Network Management capabilities SHALL use encrypted and authenticated technologies (e.g.,

SSH, SNMPv3, IPSec, TLS) and/or Out-Of-Band technologies.

• There SHALL be coordination procedures defined between IP Core Provider and

ANSPs/organizations to mitigate the harmful effects of security incidents (e.g., activation of upstream-countermeasures by IP Core Provider in case of an attack-detection by the

ANSPs/organizations).

• Operation of Security elements SHALL stay up-to-date with the evolution of protection mechanisms.

ANSP/Organization Edge requirements

• Any incoming message source addresses (ANSP point of view) SHALL be monitored and controlled. If incoming traffic has a source address, which belongs to the (destination-) ANSP internal address space, the traffic SHALL be discarded.

• Outgoing traffic (ANSP point of view) SHALL be monitored and controlled. If the source address does not belong to the initiating ANSP or organization domain, the traffic SHALL be discarded. inspection”) SHALL be used to protect the network. Dynamic packet filtering (“stateful inspection”) SHOULD be used.

• Firewall configuration and maintenance procedures SHALL be defined and implemented for each organization.

IP Core Edge requirements

• Network Ingress Filtering [4] mechanisms SHALL be used in order to limit possible Denial of

Service (DOS) attacks.

• Mechanisms SHALL be implemented to prevent any unwanted traffic to be forwarded to the

ANSP/Organization Edge (e.g., Intrusion Detection and Prevention Systems, Sink Holes,

Access Rate Control)

© EUROCAE, 2009

22

3.5.3 Zone 3 (ANSPs and other related Organizations Domain)

Requirements:

• Firewalls and Intrusion Detection/Intrusion Prevention systems (IDS/IPS) SHALL be used in private networks to control traffic to/from non-operational networks (e.g., administrative networks). Non-operational networks can be private or public networks.

• Data and Voice networks SHALL be separated logically (e.g., VLAN technology) or physically.

• Filtering mechanisms for traffic between servers and clients SHALL be used to protect the servers.

• The network infrastructure SHALL offer technical means to ensure the integrity of the overall voice communication service. Any violation of the integrity SHOULD be detectable.

• The network infrastructure SHALL offer technical means to ensure the confidentiality of the overall voice communication service. Any violation of confidentiality SHOULD be detectable.

• The network infrastructure SHALL offer technical means to ensure the authenticity of the source/destination of the overall voice communication service. Any violation of the authenticity

SHOULD be detectable.

• The management functions SHALL be separated logically (e.g., VLAN, out of band) or physically.

• Network Configuration Management SHALL use encrypted and authenticated technologies

(e.g., SSH, SNMPv3, IPSec, TLS) and/or Out-Of-Band technologies.

• Operation of Security elements SHALL stay up-to-date with the evolution of protection mechanisms.

The most significant security concerns in a VoIP environment are mentioned in chapter 3.3.1.

Countermeasures to these threats include:

Secure Real-time Transport (SRTP), which provides confidentiality, message authentication, and replay protection for RTP and Real-time Transport Control

Protocol (RTCP) traffic [5].

Authentication: Mechanisms should be activated to ensure the integrity of the voice packets to ensure that what is presented at the destination node is identical to what was issued from the source node.

Access control: This is supported by a tool suite to enable blocking of unauthorized users from invoking voice services

© EUROCAE, 2009

23

NIST SP 800-58 [1] discusses the impact of these and related issues on VoIP over private and public networks, for which it recommends the following:

• Appropriate network architecture SHOULD be developed

• Voice and data SHOULD be separated on logically different networks.

• Multimedia protocols SHOULD be isolated from the data network. Strong authentication and access control SHOULD be used on the voice gateway system, which interfaces with the

PSTN, SIP, H.323, or MGCP [15] connections from data network.

• Mechanisms SHOULD be deployed for allowing VoIP traffic to traverse firewalls (e.g.,

Application Level Gateways, Session Border Controllers).

• Stateful packet filters SHOULD be implemented to track connections and deny non-compliant packets.

• IPSec [9] [10] [11], MPLS [20], and tunnelling technologies SHOULD be used to secure network and link layers and TLS [7] SHOULD be used to protect multimedia protocol signalling for upper layers.

• To enhance performance, encryption at the router or gateway SHOULD be invoked, not at the endpoints, to provide for IPSec tunnelling.

• Uninterruptible Power Supplies (UPS) and other mechanisms SHOULD be used to enhance availability and integrity.

• Separate Dynamic Host Configuration Protocol (DHCP) servers SHOULD be provided to ease the incorporation of intrusion-detection and VoIP firewall protection [17].

• Although the thrust of this document is to establish security policy for VoIP ATM communications, practitioners SHOULD analyse the tradeoff of implementing security mechanisms with their impact on ATM operational performance.

© EUROCAE, 2009

24

CHAPTER III REFERENCES

[1] Special Publication 800-58, 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

[2] IETF RFC 791: Internet Protocol (IP) version 4; http://www.ietf.org/rfc/rfc791.txt

[3] IETF RFC 2460: Internet Protocol (IP) version 6 Specification; http://www.ietf.org/rfc/rfc2460.txt

[4] IETF RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing; RFC 3704: Ingress Filtering for

Multihomed Networks http://www.ietf.org/rfc/rfc2827.txt

, http://www.ietf.org/rfc/rfc3704.txt

[5] IETF RFC 3711: The Secure Real-Time Transport Protocol (SRTP); http://www.ietf.org/rfc/rfc3711.txt

[6] IETF RFC 4301: Security Architecture for the Internet Protocol; http://www.ietf.org/rfc/rfc4301.txt

[7] IETF RFC 4346: The TLS Protocol Version 1.1; IETF RFC 4366: TLS

Extensions; IETF RFC 4680: TLS Handshake Message for Supplemental Data;

IETF RFC 4681: TLS User Mapping Extension http://www.ietf.org/rfc/rfc4346.txt

, http://www.ietf.org/rfc/rfc4366.txt, http://www.ietf.org/rfc/rfc4680.txt

, http://www.ietf.org/rfc/rfc4681.txt

[8] IETF RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet

Protocol Version 6 (IPv6) Specification; IETF RFC 4884: Extended ICMP to

Support Multi-part Messages http://www.ietf.org/rfc/rfc4443.txt, http://www.ietf.org/rfc4884.txt

[9] IETF RFC 4302: IP Authentication Header (AH); IETF RFC 4835: Cryptographic

Algorithm Implementation Requirements for Encapsulating Security Payload

(ESP) and Authentication Header (AH) http://www.ietf.org/rfc/rfc4302.txt

, http://www.ietf.org/rfc/rfc4835.txt

[10] IETF RFC 4303: IP Encapsulating Security Payload (ESP); IETF RFC 4835:

Cryptographic Algorithm Implementation Requirements for Encapsulating

Security Payload (ESP) and Authentication Header (AH) http://www.ietf.org/rfc/rfc4303.txt

, http://www.ietf.org/rfc/rfc4835.txt

http://www.ietf.org/rfc/rfc4306.txt

[12] IETF RFC 3550: RTP: A Transport Protocol for Real-Time Applications; http://www.ietf.org/rfc/rfc3550.txt

[13] IETF RFC 3261: SIP: Session Initiation Protocol; IETF RFC 3265: Session

Initiation Protocol (SIP)-Specific Event Notification; IETF RFC 3853: S/MIME

Advanced Encryption Standard (AES) Requirement for the Session Initiation

Protocol (SIP); IETF RFC 4320: Actions Addressing Identified Issues with the

Session Initiation Protocol's (SIP) Non-INVITE Transaction http://www.ietf.org/rfc/rfc3261.txt

, http://www.ietf.org/rfc/rfc3265.txt

, http://www.ietf.org/rfc/rfc3853.txt

, http://www.ietf.org/rfc/rfc4320.txt

[14] IETF RFC 3265: Session Initiation Protocol (SIP) – Specific Event Notification; http://www.ietf.org/rfc/rfc3265.txt

© EUROCAE, 2009

25

[15] IETF RFC 3435: Media Gateway Control Protocol version 1.0 (section 5); IETF

RFC 3661: Media Gateway Control Protocol (MGCP) Return Code Usage http://www.ietf.org/rfc/rfc3435.txt

, http://www.ietf.org/rfc/rfc3661.txt

[16] IETF RFC 2764: A Framework for IP Based Virtual Private Networks; http://www.ietf.org/rfc/rfc2764.txt

[17] IETF RFC 3315: DHCP for IPv6; IETF RFC 4361: Node-Specific Client

Identifiers for DHCPv4 http://www.ietf.org/rfc/rfc3315.txt

, http://www.ietf.org/rfc/rfc4361.txt

[18] IETF RFC 4251: The SSH Protocol Architecture; http://www.ietf.org/rfc/rfc4251.txt

[19] IETF STD 62: An Architecture for Describing SNMP Management Frameworks; http://www.ietf.org

[20] IETF RFC 3031 “Multiprotocol Label Switching Architecture”, RFC 3032 “MPLS

Label Stack Encoding”, RFC 3443 “TTL Processing in MPLS Networks”, RFC

4182 “Removing a Restriction on the Use of MPLS Explicit NULL” http://www.ietf.org/rfc/rfc3031.txt

, http://www.ietf.org/rfc/rfc3032.txt

, http://www.ietf.org/rfc/rfc3443.txt

, http://www.ietf.org/rfc/rfc4182.txt

[21] IETF RFC 3414, User-based Security Model (USM) for version 3 of the Simple

Network Management Protocol (SNMPv3) http://www.ietf.org/rfc/rfc3414.txt

© EUROCAE, 2009

26

CHAPTER IV

IP ADDRESSING

4.1 BACKGROUND

Voice over IP (VoIP) defines a way to carry voice calls over an IP network including the digitisation and packetisation of the voice streams. The use of IP telephony and the VoIP standards will support the creation of an ATM communication system where higher-level features (e.g., advanced call routing, voice mail, call/contact centre) can be deployed to support air traffic services.

This chapter proposes a standards-based common addressing structure to accommodate the heterogeneity of end systems in the national and international ATM domains.

The proposed addressing structure is an extract from the results of the iPAX Task

Force

6

.

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] [2] or IPv6 [1] [4] [5]), which are described below.

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 6 illustrates the five IPv4 address class formats.

32 bits

0 Byte 2 Byte 3

Class A Byte 1 Host portion

Network portion

1 0

Byte 4

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

1

Byte 2

Class E Experimental

Byte 3 Byte 4

FIGURE 6 - IPV4 ADDRESSING FORMAT

6

EUROCONTROL EATM Internet Protocol for Aeronautical Exchange Task Force

© EUROCAE, 2009

27

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.

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 local, national, or regional

Internet registries (the latter being RIPE NCC [Réseaux IP Européens

Network Coordination Centre] in Europe) 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 5 shows the numeric ranges and decimal equivalents.

Class Length of network address (bits)

Address number range

(decimal)

A

B

8

16

0 – 127

128 - 191

C 24 192 - 223

TABLE 5 - NUMERIC RANGES

To isolate the critical ATM VoIP infrastructure from the public Internet, and to mitigate the acquisition of scarce addressing from the global IP space, private addressing 0 [7] may be structured and allocated. However, this architecture may be incompatible with other independently structured privately addressed domains, or with the public

Internet, unless the Network Address Translation (NAT) mechanisms and firewalls supporting such private addressing are designed for this type of interfacing.

IPv6 [1], [5], [1], [9], features a much larger addressing space than IPv4, as shown in

Figure 7. 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 7 - IPV6 ADDRESSING FORMAT

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

© EUROCAE, 2009

28

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)

“::” represents 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

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 8

001

(3-bits)

Global routing Prefix

(45 - bits)

Subnet ID

(16 - bits)

Interface ID

(64 - bits)

Global Unicast Address Format

1111111011

or

FEC0::10

(10 - bits)

1111111010

or

FE80::10

(10 - bits)

Set value to

“0”

(38 – bits)

Subnet ID

Site Link add (16bits)

Interface ID

(64 – bits)

Site – Local Unicast Address Format

Set value to “0” Interface ID

(54 – bits) (64 – bits)

Link – Local Unicast Address format

FIGURE 8 - TYPE OF UNICAST ADDRESSING FORMAT

Table 6 illustrates IPv6 main addressing type.

Allocation

Global Unicast Addresses

Link Local Addresses

Site Local Addresses

Multicast Addresses

001

Prefix

1111 1110 10

1111 1110 11

1111 1111

Function of Address Space

1/8

1/1024

1/1024

1/256

TABLE 6 - IPV6 MAIN ADDRESSING TYPE

© EUROCAE, 2009

29

Anycast [9] – a global address that is assigned to a set of interfaces belonging to different nodes. Anycast addresses have the following restrictions:

An Anycast address must not be used as a source address of an IPv6 packet

An Anycast address must not be assigned to an IPv6 host. It may be assigned to an IPv6 router.

Figure 9 shows the anycast addressing format.

Subnet prefix 00000000000000000000

128 – Bits

FIGURE 9 - ANYCAST ADDRESSING FORMAT

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 [11] are constructed as depicted in Figure 10.

Subnet Prefix

(64 – bits)

111111X1111…. 111

(57- bits)

Anycast ID

(7 – bits)

FIGURE 10 - 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 11. 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

(80 – bits)

XXXX

(16-bits)

IPv4 address

(32 – bits)

FIGURE 11 - 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 12.

11111111

(8-bits)

Flags (4-bits)

and

Scope (4-bits)

Group ID (112 – bits)

FIGURE 12 - MULTICAST ADDRESSING FORMAT

© EUROCAE, 2009

30

The leading eight bits (“11111111”) identifies the address as being a multicast address. “Flags” is a set of four bits, as configured below:

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

Table 7 illustrates IPv4 concepts and their IPv6 equivalent [1].

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)

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)

Auto-configured address (169.254.0.0/16)

Text representation: Dotted decimal notation

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 representation: Subnet mask in dotted decimal notation or prefix length

IPSec support is optional

Network bits presentation: Prefix length notation only

IPSec support is required

TABLE 7 - IPV4 AND IPV6 EQUIVALENT

© EUROCAE, 2009

31

IPv4 was initially standardized in 1981. As the Internet became 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

More efficient addressing design and handling at the IP network layer

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 ATM applications

Enabling more granularity and flexibility in message dissemination to individuals and groups

Establishing a “plug and play” capability for installing devices in an Ipv6 network

Providing more robust network management on an enterprise scale

Eliminating the need for network address translation (NAT)

Incorporating a compact base header structure, which expedites packet routing

– less frequently used options are relegated to extension headers

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

L

scalable. IPv6 is an industry-standard solution that can support such growth in communication demand and geographical scope.

The key reason of deploying IPv6 is due to the current IPv4 deployments between

ANSPs which have extensive IP address domain overlaps making the use of inter-

WAN IPv4 too complex

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. At this moment VoIP gateways between

IPv4 and IPv6 remain unavailable.

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

32

4.2 ADDRESSING SCHEME (REVISED IPAX SCHEME)

An IPv6 addressing scheme was developed within the context of the iPAX Task Force

(TF) [10], as 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

ANSPs already work with a private “Class A” address (e.g., 10.x.y.z, where x and y are octets used to assign sites and subnets). With a /48 allocation, ANSPs have two octets to number their sites and subnets and can still make use of IPv6 address autoconfiguration.

RIPE Responsibilty

(32 bits)

3 13 13 3 3 13 16

FP TLA ID Sub-TLA Res.

NLA ID SLA ID

64

Interface ID

F1

3 bits

Net.

Prefix

7 bits v4/ v6

1 bit

F2

5 bits

Site

Location

LAN variable bits variable bits

ESI

64 bits

Common Responsibilty

(Coordination Body)

(16 bits)

ANSP Authority

(80 bits)

FIGURE 13 - PROPOSED IPV6 ADDRESS STRUCTURE

To summarise the iPAX addressing scheme:

The first 32 bits are fixed to 2001:4b50 (RIPE allocation)

Field F1 is reserved for future use

The fixed “Network Prefix” field is 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 v4/v6 field is a toggle bit that indicates if IP address translation is required at the network border.

The F2 field is assigned as defined in Annex A and has 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 3531 (A Flexible Method for Managing the

Assignment of Bits of an IPv6 Address Block) in concert with the Annex A methodology for F2 field assignments.

If required the use of the F1/F2 fields to number VoIP can be envisaged. The IPv6 addressing scheme is regularly presented to the EUROCONTROL EATM

Communication Team

© EUROCAE, 2009

4.2.1

33

Address Management

Each European ANSP or EUROCONTROL stakeholder is initially assigned a network prefix. Based on this network prefix, each organisation can advertise a /42 IPv6 address prefix at their network border as listed in Annex A.

EUROCONTROL will enter this information into the RIPE database and indicate the address space as being “sub-allocated”.

Then two /48 prefixes (one for real v6 nodes and the other to represent virtual v4 nodes) for operational networks and another two for pre-operational networks will be assigned. Looking at Figure 13, this will correspond to two values of the F2 field, each complemented by a v4/v6 toggle bit. As agreed with RIPE representatives,

EUROCONTROL will enter this information into the RIPE database on behalf of the organisation. These four assignments are referred to as the “basic assignment” and are listed in Annex A.

This process will provide the same address space to all organisations irrespective of their size. In reality, some organisations may be operating multiple, very large or regional networks. Therefore, the basic assignment may be insufficient or inappropriate. In such cases, an alternative assignment can be made within the organisations range as long as it remains within the RIPE policy and does not compromise the overall addressing scheme.

In order to coordinate the management of address space, a Local Internet Registry

(LIR) is required. EUROCONTROL applied to RIPE (the European Internet Authority) for LIR status in November 2004. This was accepted in December 2004 and in

January 2005; EUROCONTROL requested its first IPv6 allocation and received the standard LIR /32 allocation, as listed in the inet6num object extracted from the RIPE database ( http://www.ripe.net/db/index.html

): inet6num: 2001:4b50::/32 org: ORG-EitE1-RIPE netname: BE-EUROCONTROL-20050131 descr:

Navigation

EUROCONTROL, the European Organisation for the Safety of Air country: BE admin-c: tech-c: status: notify:

EJC2-RIPE

EJC2-RIPE

ALLOCATED-BY-RIR [email protected] mnt-by: RIPE-NCC-HM-MNT mnt-lower: EURO-HQ-MNT mnt-routes: EURO-HQ-MNT changed: [email protected] 20050131 source: RIPE

From this allocation, the EUROCONTROL Agency has begun the assignment of IPv6 addresses.

© EUROCAE, 2009

34

ANNEX A

NETWORK ADDRESS ASSIGNMENTS

The IPv6 addressing scheme is regularly presented to the EUROCONTROL EATM Communication Team.

TABLE 8 - CONFIRMED ASSIGNMENTS

© EUROCAE, 2009

35

TABLE 9 - CONFIRMED INTERLINK ADDRESSES

© EUROCAE, 2009

36

TABLE 10 - PLANNED ASSIGNMENTS

© EUROCAE, 2009

37

CHAPTER IV REFERENCES

[1] IETF RFC-791, September 1991; IETF RFC-2460, December 1998: Internet

Protocol version 4 and version 6 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-2474, December 1998; Definition of the Differentiated Services Field

(DS Field) in the IPv4 and IPv6 Headers http://www.ietf.org/rfc/rfc2474.txt

[4] IETF RFC-1752, January 1995: The Recommendation for IP Next Generation

Protocol http://www.ietf.org/rfc/rfc1752.txt

[5] IETF RFC-2460, December 1998: Internet Protocol, Version 6 (IPv6)

Specification

http://www.ietf.org/rfc/rfc2460.txt

[6] IETF RFC-1887, December 1995 (Information): An Architecture for IPv6 Unicast

Address Allocation http://www.ietf.org/rfc/rfc1887.txt

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-4291, February 2006: IPv6 Addressing Architecture http://www.ietf.org/rfc/rfc4291.txt

[10] Internet Protocol for Aeronautical Exchange Task Force (iPAX-TF); Eivan

Cerasi http://www.eurocontrol.int/communications/public/standard_page/com_network.

html

[11] IETF RFC-2526, March 1999: Reserved IPv6 Subnet Anycast Addresses http://www.ietf.org/rfc/rfc2526.txt

[12] IETF RFC-4213, October 2005: Basic Transition Mechanisms for IPv6 Hosts and Routers http://www.ietf.org/rfc/rfc4213.txt

[13] IETF RFC-2766, February 2000: Network Address Translation – Protocol

Translation (NAT-PT); IETF RFC-3596, October 2003: DNS Extensions to

Support IP Version 6 http://www.ietf.org/rfc/rfc2766.txt

; http://www.ietf.org/rfc/rfc3596.txt

© EUROCAE, 2009

38

LIST OF EUROCAE WG-67 CONTRIBUTORS

SURNAME NAME COMPANY

BALKS Annette Maria

BERTAGNOLIO Luca

BRUTE DE REMUR Valérie

CISCO

CISCO

THALES

KAMPICHLER Wolfgang FREQUENTIS

RAMOS GONZÁLEZ Juan Francisco INDRA

SAYADIAN Leon FAA

WEILL Eric SAIC (supporting FAA)

ZOMIGNANI Marcelo INDRA

© EUROCAE, 2009

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

92240 MALAKOFF, France

Web Site: www.eurocae.net

Tel: 33 1 40 92 79 30

Fax: 33 1 46 55 62 65

Email: [email protected]

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

document

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”.

6

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.

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: [email protected]

Web Site: www.eurocae.net

© EUROCAE, 2009

ii

TABLE OF CONTENTS

FOREWORD .......................................................................................................................... I

CHAPTER I INTRODUCTION .............................................................................................. 1

1.1 Background....................................................................................................... 1

1.2.1 Operational Voice Applications in ATM.............................................

3

REFERENCES OF INTRODUCTION ............................................................................................. 6

CHAPTER II VOIP OVERVIEW, PROTOCOLS AND STANDARDS ....................................

7

2.1.3 Gateway ............................................................................................ 12

2.2.1 Assumptions...................................................................................... 13

2.2.2 Voice over IP Components................................................................ 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.3.3 High-availability platforms .................................................................

40

3.3.4 High-availability network design........................................................ 40

3.4 Conclusion and Recommendation.................................................................... 59

CHAPTER III REFERENCES.......................................................................................................... 60

CHAPTER IV QUALITY AND PERFORMANCE..................................................................... 61

4.1.1 Bandwidth.......................................................................................... 61

4.1.2 Packet Loss.......................................................................................

63

© EUROCAE, 2009

iii

4.3

4.2.1 Standards Delay Limits ................................................................ 69

4.2.2 Sources

70

4.2.4 Conclusion......................................................................................... 80

Quality of Service QoS ..................................................................................... 80

4.3.1 VoIP QoS requirements .................................................................... 80

4.3.4 Conclusion......................................................................................... 106

CHAPTER IV REFERENCES ......................................................................................................... 107

CHAPTER V MULTICAST CONSIDERATIONS.................................................................... 111

5.1 Introduction ....................................................................................................... 111

5.3.5 IGMP ................................................................................................. 117

5.5.1 Unwanted flooding............................................................................. 118

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

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.1 Encryption VoIP networks............................................................ 139

7.4.2 VoIP protection - Perimeter security with firewalls............................ 147

7.5

7.4.6 IPS (Intrusion Prevention Systems) .................................................. 153

Best practices solutions for protecting VoIP/IP Telephony Networks .............. 155

7.5.1 Secure the network infrastructure for voice....................................... 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

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.

• 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

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 o

Network Specification

Security Policy

o

IP Adressing Plan

• ED-138

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

1.2.1

3

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 EATM

1

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 = Voice Communication System

FIGURE 2 : CONSIDERED VOICE APPLICATIONS IN WG67

VCS 2

1

European Air Traffic Management

© EUROCAE, 2009

4

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

LAN EDGE WAN EDGE

FIGURE 3 : IP NETWORK DOMAIN CONCEPT

LAN

IP

IP

IP

IP

© EUROCAE, 2009

1.2.3

5

Authors and Contributors

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

Non-permanent members

Permanent members

FIGURE 4 : SUBGROUP 3 PARTICIPATION (NO PATICULAR ORDER)

Authors Contributors

Catalin Apostol, ROMATSA

Armin Biegel, DFS

Annette Maria Balks, Cisco

Dragos Baloi, ROMATSA

Valérie Bruté de Rémur, THALES

Juan Francisco Ramos González, Indra

Leon Sayadian, FAA

Eric Weill, FAA

Marcelo Zomignani, Indra

Luca Bertagnolio, Cisco

Hung Do-Duy, INEO

Olivier Dupont, Cisco

Graham Fellows, Nortel

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

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).

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

• Interoperability

• Scalability

© EUROCAE, 2009

8

User

Adapter

OSI Layers

Layer

7, 6, and 5

Layer 4

Layer 3

Layer 2

Layer 1

T.120

(RTP)

T.130

(AVC)

H.450.x

H.225

Q.93

1

H.323/

H.460.x

H.225

RAS

H.235

H.24

TCP/UDP

IPv6

FR, ATM, MAC

Physical Interfaces T1/E1

Users

LAN/WAN/PSTN

FIGURE 5 : VOIP ARCHITECTURE & LAYERS

SIP

Users

© EUROCAE, 2009

9

• o o o o

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]

H.245 Call control [4]

H.246 Interlocking of H-Series multimedia terminal [5]

H.235 Security [3 and 32]

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 o

T.125 – Multipoint communication service protocole [89]

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 o o

RTCP (Real Time Control Protocol) [73] (defined in Appendix A)

SRTP (Secure Real Time Protocol) [74] (defined in Appendix A)

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.

TCP, UDP [37 and 38]

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

© EUROCAE, 2009

10

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

Network

Network

FIGURE 7 : VOIP INTERFACE TO PSTN VIA ATS GATEWAY

H.323

Manager or

Gatekeeper

Rtr/GW

To external networks

Video

Telephone

IP WAN (Router,

SW, GW )

PC

Convergence device and multiplexer

LAN

Convergence device and multiplexer

LEGEND

GW – Gateway

LAN – Local Area Network

PC – Personal Computer

Rtr – Router

SW – Switch

PC

Telephone

WAN – Wide Area Network

FIGURE 8 : EXAMPLE OF A CONVERGED VOIP NETWORK

Video

Telephone

PC

© EUROCAE, 2009

12

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]

T1, T3, E1, FDDI, SONET

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

2.1.1.7

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

ITU G.131 [94]

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.2

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

ITU-T G.107 [12]

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

2.2.2

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

Voice over IP Components

2.2.3

VoIP components are defined in Appendix F.

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

• 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 SRTP

2

by providing a robust setup mechanism for key agreement to establish a secure SIP

3

-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:

Delays (e.g., Algorithmic/Processing, Packetization, Propagation

5

Queuing), which could result in talker overlap

, and

• Jitter

G.711 with

PLC

G.711 without PLC

G.726

G.728

G.729A and

VAD

G.723.1A and VAD iLBC

9

GIPS with

VAD

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:

PCM A-law & µ-law at

64Kps

PCM A-law & µ-law at

64Kps

ADPCM at 16 – 40 Kbps

(ms)

Factor

6

Ie

(0% loss)

7

Ie

(2% loss)

MOS

8

4.3

4.4

1

LD-CELP at 16Kbps

CSACELP at 8 Kbps

MPMLQ at 6.3 Kbps low-bit rate, narrowband

13.3/15.2 kbps

3 - 5

10 (plus 5 ms look ahead)

30 (plus 7.5 ms look ahead)

30 (13.3Kbps)

20 (15.2Kbps)

7

4.0 -

4.2

4.0 -

4.2

75 - 79

70 - 75

11

15

19

24

4.2 -

3.99

3.8 -

4.0

0 2 -

3.67

10

Enhanced G.711 Variable bit rate, average 80Kbps

<0.125

TABLE 2 - CODEC PERFORMANCE FACTORS

0 2 4.3

4.4

11

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

11

Refer to: www.globalipsound.com

, iLBC white paper – October 2004, Figure1b

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 bytes

Payload 20 – 240 bytes for

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

© 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)

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

(CODEC)

Voice

Digitizing

Rate (kbps)

Digitizing

Delay (ms)

Complexity

PCM (G.711)

ADPCM (G.726)

LD-CELP (G.728)

CS-ACELP (G.729/G.729a)

MPMLG (G.723.1)

ACLEP (G.723.1)

64

32

16

8

6.3

5.3

0.75

1

3-5

10

30

30

N/A

Low

Very High

Moderate

N/A

N/A

TABLE 4 - PROMINENT CODEC CHARACTERISTICS

Mean

Opinion

Score

(MOS)

4.4

4.2

4.2

4.2

3.98

3.5

© 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

Codecs

G.7xx

Video

Codecs

H.261

[7]

H.263

[8]

RTP

RTCP

(Real Time

Transport

Control

Protocol)

T.120

(Real

Time)

T.130

(Audio-

Visual

Control)

H.450.1 Series

(Supplementary

Services)

H.225.0

RAS

Q.931

(Call

Signaling)

H.235

(Security)

H.245

(Control

Signaling)

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

PINT

(Interface to

PSTN

Signalling e.g., ATS-

QSIG)

Data

Services e.g., using

RTSP

Application and system control

Call Transfer/Conferences/Call Hold/

Call Monitoring and other

Supplementary Services

Extension

Header

SIP

Message Body (e.g., SDP)

Methods

AV I/O equipment

Audio Video

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

Call Set-up delay

3G (Third Generation)

Protocol Complexity

Extensibility

Addressing Support

Firewall Support

Instant Messaging

Loop Detection

Transport Protocol

Internet Application

Integration

Inter-domain Call Routing

Service Standardization

Supplementary Services

Internet Compatibility

Binary Code

=1.5 * RTT

No

High

Extensions added with vendor-specific non-standard elements

Host (without username), E.164 phone numbers; gatekeeper resolved alias (arbitrary case-sensitive string)

Poor

Textual

= 1.5 * RTT

Yes

Simple HTTP-style Protocol

Standards-based extensions to perform new functions

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.

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 vendors have settled on a non-standard version of

SIP.

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).

Accommodates many addressing formats (e.g., URL,

E-mail address, H.323, E.164)

Inadequate

H.323 ENUM Service Registration

Security in both protocols remains an issue, due to poor interoperability of vendor products (e.g., gateways)

No

Imperfect

Yes

Good

UDP and TCP. Mostly TCP.

Not designed for Internet implementation

H.225 Annex G

Services standardized in detail in the H.450 series

Rigorously defined

Low

UDP and TCP. Mostly UDP.

Designed to incorporate Internet style text-based applications

Domain Name System (DNS)

Services not standardized

Poorly defined

High

SIP: routing loops detected; “spirals” recognized and permitted.

Usage of TCP results in greater call set-up latency.

SIP is capable of integration with other services (e.g., a caller may send an E-mail to an unreachable callee).

For SIP, DNS is used to find the SIP server, but does not resolve to the addressee level

SIP only standardizes protocols and general interfaces

Both standards are upgrading

H.323 tries to impose ISDN architecture on IP network

Scalability

Type of Services

Vender Interoperability

Quality of Services (e.g.,

Call Setup delay, packet loss recovery, resource reservation capability)

Interoperability

Poor

Only media streams, including voice

Limited

Supports redundant gatekeepers. Policy Control has limited DiffServ support

Compatible with PSTN Signaling; uses Q.931-like messages, which are compatible with ATM-QSIG

(Private Network)

Add version 5, reference to H.510 draft Mobile/Wireless

Capabilities

3GPP (Third Generation

Partnership Project)

Security

Currently No

Defines security mechanisms and negotiation via

H.235; SSL may also be used

Architecture H.323 goes beyond basic signaling capabilities to include conference control, registration, capability negotiation, QoS, and service discovery.

Components Terminal/Gateway

Gatekeeper

Multicast Signaling

Conference

Click for Dial

Yes, with Location Requests (LRQ) and Gatekeeper

Request (GRQ)

Yes

Yes

Large Number of Domains H.225 Annex G defines communication between administrative domains, address resolution, access authorization, and usage reporting.

Excellent

No obvious limitations

Widespread

Loop detection algorithm using “VIA” header

Standards are draft

Designed for nomadic based services still on going

Yes

SIP is less complex and easy to customize

SIP is almost perfectly general

H.323 Interoperability is virtually non-existent

QoS capabilities are still not mature for H.323 and SIP over IPv4

Interfacing between H.323 and SIP, both protocols should translate call set-up and use RTP to communicate with each other.

Compatible

Supports authentication via HTTP; confidentiality with

SSL/TLS, SSH, S-HTTP, PGP, S/MIME; key exchange with SDP

Modular: Does only signaling; other functions (e.g.,

QoS, directory access, service discovery, and session content description) reside in separate, orthogonal protocols

UA (User Agents)

Compatible

Servers

Yes (e.g., group INVITEs) H.323 LRQ and GRQ are Registration, Admissions, and Status (RAS) messages for discovery

Yes

Yes

Inherent support for wide area addressing. Loop detection, Registrar, and redirect servers support user 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

Call priority designation

Transport of duplicate Q.931 IEs (Single-byte and Multi-byte),

Querying for alternative routes

QoS monitoring and reporting

SIP as a support protocol

SIP has been chosen as the standard for call set-up in IP-based networks by the 3 rd

Generation Partnership Project (3GPP), with the following enhancements:

Address resolution and Name mapping

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

© EUROCAE, 2009

Figure 11 shows VoIP with SIP.

SIP/TCP or UDP

Signaling

IP

23

Signaling

Voice

Voice

RTP/UDP

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:

More efficient addressing design and handling at the IP network layer

Better QoS support

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

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

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

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:

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

Country Code

(CC)

National ISDN Number

International ISDN Number

ISDN Address

National

Destination Code

(NDC)

Subscriber

Number (SN)

Subaddress

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

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

FP TLA ID Sub-TLA Res.

NLA ID SLA ID

64

Interface ID

F1

3 bits

Net.

Prefix

7 bits v4/ v6

1 bit

F2

5 bits

Site

Location

LAN variable bits variable bits

ESI

64 bits

Common Responsibilty

(Coordination Body)

(16 bits)

ANSP Authority

(80 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.

Q S IG

Ne tw ork

En te r p r is e

Sign ali ng

G W

PB X/

S wi tch

M G C P

M G

G W

S IG TR AN

M G C

S IP -T

N M S

Sign aling

G W

S IG TR AN

M G C

M G C P

M G

IP Ne tw ork

RTP

G W

RTP

PB X/

Switch

S S 7

Ne tw o rk

P riva te Ne tw ork s

R AS

R AS

G K

M C U

H.32 3 Te rm ina ls/

T e le phone s

FIGURE 14 : TYPICAL VOIP COMPONENT ARCHITECTURE

© EUROCAE, 2009

31

CHAPTER II REFERENCES

1

2

ITU-T H.323 Version 5, July 2003 Packet-based multimedia communications systems

ITU-T H.225.0, July 2003.

ITU-T H.225 Annex G, Sept.1999

Call Signaling Protocols and media stream packetization for packet-based multimedia communication systems

3 ITU-T H.235, August 2003

4 ITU-T H.245, July 2003

5 ITU-T H.246, February 1998

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

6 ITU-T H.248.1, September 2005 Gateway Control Protocol, version 3

7 ITU-T H.261, March 1993 Video Codec for Audiovisual services

8 ITU-T H.263, February 1998 Video Coding for Low Bit Rate Communication

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

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

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

Echo Cancellers

Digital Network Echo Cancellation

Pulse code modulation (PCM) of voice frequencies

17

18

19

20

21

ITU-T G.726, December 1990

ITU-T G.728, September 1992

ITU-T G.729 and G.729a, March

1996

ITU-T P.800 (August 1996),

P.800.1 (March 2003)

ITU-T P.861, February 1998

22 ITU-T P.862 (March 2003), 862.1

(November 2003)

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 conjugatestructure 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

32

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

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

28

30

ITU-T Y.1310, March 2004

29

ITU-T Y.1540, December 2002, and Amendment 1, August 2003

ITU-T Rec. Y.1541 (May 2002),

Amendment 1 (August 2003),

Amendment 2 (February 2004)

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)

31 ECMA 312, 3

32

33

34

35

June 2003 rd

Edition,

Internet Telephony Volume 7

Number 4, 2004

IEEE 802.1p, 1998

IEEE 802.1Q, 2003

IEEE 802.3, May 2000

36 IETF RFC 791, 1981; RFC 2474,

1998; RFC 3168, 2001; RFC

3260, 2002

37

38

39

40

41

43

IETF RFC 793, 1981

IETF RFC 768, 1981

IETF RFC 1680, August 1994

IETF RFC 2225, April 1998

IETF RFC 1754, January 1995

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

IETF RFC 4346, 2006; RFC

4366, 2006; RFC 4680, 2006;

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

33

44

45

46

47

48

49

50

51

RFC 4681, 2006

IETF RFC 2326, April 1998

IETF RFC 4566, July 2006

IETF RFC 2328, April 1998

IETF RFC 4302, 2005; RFC

4835, 2007

IETF RFC 4303, 2005; RFC

4835, 2007

IETF RFC 4306, 2005

IETF RFC-3142, 2001

ITU-T Rec., E.123, 1988

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

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

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

56 IETF RFC 4364, 2006; RFC

4577, 2006; RFC 4684, 2006

BGP/MPLS IP VPNs;

OSPF as the Provider/Customer Edge Protocol for

BGP/MPLS IP VPNs;

Constrained Route Distribution for BGP/MPLS IP

VPNs

57

IETF RFC 2597, June 1999; RFC

3260, April 2002

Assured Forwarding PHB Group; New Terminology and Clarifications for Diffserv

58 IETF RFC 2764, February 2000 A Framework for IP Based Virtual Private Network

(Informational)

59 IETF RFC 2824, May 2000 Call Processing Language Framework and

Requirements (Informational)

60 IETF RFC 2848, June 2000

61

62

IETF RFC 2871, June 2000

IETF RFC 3031, January 2001

63 IETF RFC 3168, 2001

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) 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

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)

67 IETF RFC 3263, June 2002

68 IETF RFC 3264, June 2002

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

70 IETF RFC 4566, July 2006

71 IETF RFC 3372, September

2002

72 IETF RFC 3525, June 2003

73 IETF RFC 3550, July 2003, and

IETF RFC 3551

74 IETF RFC 3711, 2004

75 EUR 145-05/GT 67-15, April

2005

76 IETF RFC 2974, October 2000

77

78

79

80

81

82

IETF RFC 3435, January 2003,

IETF RFC 3661, December 2003

IETF RFC 3762, 2004

IETF RFC 1157, May 1990

IETF RFC 3413, December 2002

IETF RFC 3764, 2004

IETF RFC 3953, 2005

ICAO Annex 10, Vol. III, Part II.,

Chapter 4, 1995, and

Doc 9804, 2002

Session Initiation Protocol (SIP)-Specific Event

Notification

SDP: Session Description Protocol

Session Initiation Protocol for Telephones (SIP-T):

Context and Architectures

Gateway Control Protocol Version 1

RTP: A Transport Protocol for Real-Time

Applications (RTCP)

The Secure Real-Time Transport Protocol (SRTP)

Minutes of the 7 th

Meeting of WG-67 (VoIP for ATM)

SAP: Session Announcement Protocol

Media Gateway Control Protocol V- 1.0.

MGCP Return Code Usage

Telephone Numbering Mapping (ENUM) Service

Registration for H.323

A Simple Network Management Protocol (SNMP);

SNMP Applications

Enum Service registration for SIP Address-of-Record

Telephone Numbering Mapping (ENUM) Service

Registration for Presence Services

Recommended Voice Addressing Plan.

Manual on ATS Ground Voice Switching

84 ITU-T E.160 rev.1, 1993

International Identification Plan for Mobile Terminal and Mobile Users

Definition Relating to National and International

Numbering Plan

86 ITU-T E.164, 1997

87 ECMA-155, 1997

88

89

IETF RFC 4733, December

2006; RFC 4734, December

2006

ITU-T.125, April 1994

Capability for 7 digit analysis of International E.164

Numbers

International Telephone Numbering Plan

Private Integrated Service Network-Addressing

RTP Payload for DTMF Digits, Telephony Tones and

Telephony Signals;

Definition of Events for Modem, Fax, and Text

Telephony Signals

Multipoint communication service protocol specification

90 NIST Spécial Publication 800-58,

January 2005

Security Considerations for VoIP Systems

91 ANSI T1.521a-2000, June 2000

Packet Loss Concealment with ITU-T

Recommendation G.711 Annex B

92 ITU G.113 Appendix I,

Septembre, 1999

Provisional Planning Values for the equipment impairment factor Ie

Notation for National and International Telephone

Numbering

94 ITU-T G.131 October, 1996

95 ITU-T Q.705, March 1993

96 ITU-T Q.708, March 1999

Control of Talker Echo

Signaling Network Structure

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

1997

RTP Payload Redundant Audio Data

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,

EUROCONTROL, October 2004

Report on ATS Ground Voice Network Numbering

Plan

105 draft-zimmermann-avt-zrtp-01.txt,

Internet-Draft, March 5, 2006

106 IETF RFC 3353, August 2002,

Informational

ZRTP: Extensions to RTP for Diffie-Hellman Key

Agreement for SRTP draft-zimmermann-avt-zrtp-01

Overview of IP Multicasting in a MPLS Environment

107 E67-IP03-SG1#5-EURO03

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,

November 1988

112 IETF RFC-2526, 1999

Specification of Signalling R2

113 IETF RFC-4213, 2005

114 IETF RFC-2766, 2000

Reserved IPv6 Subnet Anycast Addressing, using

EUI-64 format

Basic Transition Mechanisms for IPv6

Network Address Translation-Protocol (NAT-PT)

115 IETF RFC-2765, 2000

116 IETF RFC-4214, 2005

117 IETF RFC-2464, 1998

Stateless IP/ICMP translation Algorithms (SIIT)

Intra-Site Automatic Tunnel Addressing Protocol

(ISATAP)

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

121 ITU-T Rec., E.123, 1988

An IPv6-tp-IPv4 Transport Relay Translator

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.

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.

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.

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

4

5

6

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

1 90.0000%

2

3

99.0000%

99.9000%

99.9900%

99.9990%

99.9999%

Dowtime per Year

36 days, 12 hours

87 hours, 36 minutes

8 hours, 46 minutes

52 minutes, 33 seconds

5 minutes, 15 seconds

31.5 seconds

Types of System

Fax machines, printers

Dial ISPs, non-critical business systems

Data Centers

Redundant storage arrays

Aviation and military defense

TABLE 6 - AVAILABILITY FIGURES

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.

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

3.3.4

FIGURE 17 : NETWORK ELEMENTS AND DESIGN

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.

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

3.3.5

FIGURE 18 : NETWORK AVAILABILITY OF DIFFERENT DESIGNS

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 o

Multi-link Trunking and Split Multi-link Trunking (Nortel Proprietary)

IEEE Link Aggregation Control Protocol (IEEE 802.3ad)

Uni-directional Link Detection Protocol (UDLD)

© EUROCAE, 2009

3.3.5.1

3.3.5.1.1

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)

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

Access Layer – Layer 2 Redundancy

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

3.3.5.1.2

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.

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

3.3.5.1.3

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.

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 , s ervers 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

3.3.5.1.4

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 longhaul 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.

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-topoint 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:

FIGURE 20 : LINK AGGREGATION CONTROL PROTOCOL

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

3.3.5.2

3.3.5.2.1

3.3.6

49

Distribution Layer – Layer 3 Redundancy

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).

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

3.3.6.1

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.

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).

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

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.

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.

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

3.3.6.1.5

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.

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 “slowdown” 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.

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

© EUROCAE, 2009

3.3.6.2

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.

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

3.3.6.2.1

3.3.6.3

56

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.

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.

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-ipv6spec-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.

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 oneway delay of about 67.5 ms.

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

802.3 full duplex

802.3 half duplex

PPP

G.711 (20ms) G.711 (30ms) G.729 (20ms) G.729 (30ms)

190.4 169.6 78.4 57.6

95.2 84.8 39.2 28.8

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 endto-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.1

4.1.3.1

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.

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.

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).

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].

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].

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: communicates the compressed IP and UDP headers as without differential encoding.

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.2

4.1.3.3

4.1.3.3.1

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.

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.

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.

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].

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

4.1.3.3.2

4.1.3.4

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.

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.

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., Windowbased 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.

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

4.1.4

68

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?

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

• 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

0-150

150-400

Above 400

Description

Acceptable for most user applications (this value can be increased up to 200 ms

12

).

Acceptable provided that administrators are aware of the transmission time and the impact it has on the transmission quality of user applications.

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

Time (msec)

Delay Target

500 600 700 800

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

4.2.2

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.

Sources of Delay

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

Voice Path

Delay

+

Delay

Variation

CODEC (Encode)

Packetization

Output queuing

Access (up) link transmission

Backbone network transmission

Access (down) link transmission

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)

• Packetization delay (Fixed)

• Queuing/Buffering delay (Variable)

• Network switching delay (Variable)

• Network components delay (Fixed)

• De-Jitter delay (Fixed)

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

Coder

ADPCM, G.726

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.

CS-ACELP, G.729A

MP-MLQ, G.723.1

MP-ACELP, G.723.1

Rate Required

Sample Block

32 Kbps 10 ms

8.0 Kbps 10 ms

6.3 Kbps 30 ms

5.3 Kbps 30 ms

Best Case

Coder Delay

2.5 ms

2.5 ms

5 ms

5 ms

TABLE 9 - PROCESSING DELAY

Worst Case

Coder Delay

10 ms

10 ms

20 ms

20 ms

© EUROCAE, 2009

71

Coder

G.711

G.729

G.723.1

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.

Algorithmic Delay

~0 ms

5 ms (+ lookahead buffer 10ms)

7.5 ms (+ lookahead buffer 30ms)

TABLE 10 - ALGORITHMIC DELAY

Coder

PCM,

G.711

ADPCM,

G.726

CS-ACELP,

G.729A

MP-MLQ,

G.723.1

MP-ACELP,

G.723.1

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.

Rate Payload

Size (Bytes)

Packetization

Delay (ms)

Payload Size

(Bytes)

Packetization

Delay (ms)

64 Kbps 160 20 240 30

32 Kbps

8.0 Kbps

6.3 Kbps

5.3 Kbps

80

20

24

20

20

20

24

30

120

30

60

60

30

30

48

60

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

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

Byte

64

Bytes

128

Bytes

256

Bytes

512

Bytes

1024

Bytes

1500

Bytes

56kbps

64kbps

128kbps

Link

Speed

256kbps

512kbps

768kbps

143μs

125μs

62.5μs

31μs

15.5μs

10μs

9ms

8ms

4ms

18ms

16ms

8ms

36ms

32ms

16ms

72ms 144ms

214ms

64ms

128ms

187ms

32ms

64ms

93ms

16ms 32ms

46ms 2ms

4ms

8ms

1ms 2ms

4ms

8ms

16ms

23ms

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.6

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.

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

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.

Variable Delay Components, Jitter 4.2.2.2

Source

S

S

S

1

2

3

S

i

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.

Receiver

R

R

1

2

R

3

R

i

D i

Jitter

=

=

=

(

(

R i

R i

S i

R i

) (

1

R i

) (

1

S i

i n

D i n

S i

1

S i

1

)

)

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.2

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.

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

Brussels

Bucharest

Frankfurt

Geneva

Washington

Paris

London

Madrid

Oslo

Milan

Vienna

7

45

12

28

85

19

12

46

41

34

25

7

50

17

32

90

24

17

51

46

40

30

45

50

39

59

129

50

57

77

85

66

53

12

17

39

22

92

13

20

41

49

29

30

28

32

59

22

91

12

19

39

47

27

36

85

90

129

92

91

82

76

112

105

98

105

19

24

50

13

12

82

10

30

38

19

27

12

17

57

20

19

76

10

40

32

26

33

46

51

77

41

39

41

46

85

49

47

34

40

112 105 98

30 38 19

40 32

68

68

46

55

54

61

26

46

54

43

66

29

27

25

30

53

30

36

105

27

33

55

61

43

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

Bremen

RTEL PASSPORT

Berlin

RTEL PASSPORT

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

Powe r Sup pl y 1 Powe r Su p pl y 2

Remo ve coo l in g u ni t d rawe r fi rst Ai r F i lte r

Sta tu s Cool i ng Uni t

Powe r Su pp l y 3

Status AC Po we r Sup pl y Status AC Powe r Sup pl y Status AC Powe r Sup pl y

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

Ai r Fi lte r

Rem ove co ol in g u ni t d rawe r first

Status Coo li ng Un it

Po wer Sup pl y 3

23 ms

Frankfurt (Rhein-

Main Region)

RTEL PASSPORT

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

Po wer Sup pl y 1 Po we r Sup pl y 2

Remo ve coo l in g un i t d rawe r fi rst Ai r F i lte r

Powe r Su pp ly 3

Sta tu s Cool i ng Uni t

8 ms

16 ms

13 ms

RTEL PASSPORT RTEL PASSPORT

Sta tus AC Powe r Sup pl y Sta tus AC Powe r Sup pl y Sta tus AC Power Sup pl y Status AC Po we r Su ppl y Status AC Po we r Su ppl y Status AC Po we r Sup pl y

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

Rem ov e co ol i ng u ni t dra wer first Air Fi l te r

Status Coo li ng Un it

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

Remo ve coo l in g u ni t d rawe r fi rst Ai r F i lte r

Sta tu s Cool i ng Uni t

Powe r Su pp l y 3

Karlsruhe Munich

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

© EUROCAE, 2009

76

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

60 bytes

Every 20ms

Voice 1500 bytes of Data Voice

Voice Packet

60 bytes

Every

>187ms

Voice Packet

60 bytes

Every

> 1 8 7 m s

~187ms Serialization Delay

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

100mbps Ethernet

64kb WAN

100mbps Ethernet

Data

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 Voice Data

FIGURE 29 : FRAGMENTATION OF DATA PACKETS

© EUROCAE, 2009

77

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 cutthrough 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 T

L

of a Cut-Through Ethernet-Switches can then be calculated as follows:

T

L

=

T

IG

+

14

×

8

×

T

BK

[ ]

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 T

IG

and a Bit period of T

BK

:

10Mbps LAN

T

L

=

9 .

6

+

14

×

8

×

0 .

1

=

20 .

8

μ

s

100Mbps LAN

T

L

=

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

T

L

=

Before processing (crc, address resolution, filtering…) the whole frame has to be

T

IG

stored. After successful processing the frame is forwarded to its destination. The latency T

L

of an Ethernet Store-and-Forward switch can then be calculated as follows:

+

F

×

8

×

T

BK

[ ]

© EUROCAE, 2009

78

The minimum frame size F of an Ethernet frame is 72 Bytes; the maximum frame size is 1526 Bytes:

10Mbps LAN

T

L

min

=

9 .

6

+

72

×

8

×

0 .

1

=

T

L

max

=

9 .

6

+

1526

×

8

×

0 .

1

67 .

2

μ

s

=

1230

μ

s

100Mbps LAN

T

L

min

=

0 .

96

+

72

×

8

×

0 .

01

=

T

L

max

=

0 .

96

+

1526

×

8

×

0 .

01

6 .

72

μ

s

=

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.

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

LAN Access

Algorithmic

Packetization

Ethernet ~0 ms Serialization

Queuing/Buffering

Network Component

WAN,

IP Core

Network Switching

-Propagation

-Serialization

-Queuing/Buffering

-Network Components

Voice samples

IP

Access

Serialization

Queuing/Buffering

Network Component

LAN

Ethernet ~0 ms De-Jitter

IP

IP

IP

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

Algorithmic delay (G.723.1)

Fixed delay in ms

37.5

Packetization delay

Serialization delay of Access (on a 64 Kbps line, a CS-ACELP voice frame with a length of 38 bytes [37+1 flag] has a serialization delay of 4.75 ms)

30.0

5.0

Network component delays

Propagation delay (1000km of fiber)

Total

2.0

5.0

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

4.2.3.2.1

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.

Reducing delay at the endpoint

4.2.3.2.2

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.

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

4.3

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.

QUALITY OF SERVICE QOS

4.3.1

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.

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%).

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

The Application Perspective 4.3.2.1

)

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.

4.3.2.2

FIGURE 31 : DEFINITION OF QOS

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.

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.

V o i c e

D e a t t a

Single Infrastructure

Packet-Based

Multiservice Network

V i i d e o

I n t t e r r n e t

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

4.3.3.1

84

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

4.3.3.2

QoS-sensitive scheduling request/ reply

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.

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

Overflo

Packets Arriving w

Tokens

85

Tokens

r r t t o k e n s

/

/ s e c

B b u t t c o k k e e t t n h s o l l d s u p t t o

Conform

¾ bucket hold tokens

Exceed

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

¾ over

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 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 protocol control functions; It maintains all data structures for the protocol, the node’s state, receiving and processing the RSVP protocol messages.

¾ Policy permission to make the reservation.

© EUROCAE, 2009

86

¾ Traffic

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

Application

RSVP

Process

Policy control

Routing

Process

RSVP

Process

Policy control

Data

Packet classifier

Admission control

Packet scheduler

Packet classifier

Traffic control Traffic control

FIGURE 36 : RSVP FUNCTIONAL BLOCKS

Admission control

Packet scheduler

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 requiredeither 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 "pathstate" 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).

1 2 3

4 5 6

7 8 9

* 8 #

4.3.3.2.3

1

PATH

RESV

3

PA

TH

R

ES

V

1 2 3

4 5 6

7 8 9

*

8 #

4

PA

TH

R

ES

V

PAT

H

RES

V

2

PAT

H

RE

SV

5

FIGURE 37 : RSVP SIGNALING

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

4.3.3.3

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 "weaklink" 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.

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

DS field

6 B i i t t s

Differentiated Service Code Point

(DSCP)

D S C

P

2

B i i t t s

currently unused

C

U

Based on IPv4 header (not shown)

¾ Field DSCP (TOS octet) which is 6bits

¾ 2^6 possible combinations,

64 classes

Based on IPv6 header

¾ DSCP field that belongs to

Traffic Class

¾ Possible use of flow label

(for flow classification) standardized with RFC 3697

0 4 ver

Traffic Class

12

Payload length

IPv6 header

16 24

Flow Label

Next header Hop limit

31

IP Sender

IP Destination

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

marking

Edge router:

DSCP

Data

• Policing

• Shaping

Core router:

• Buffering and Scheduling based on marking at edge

FIGURE 39 : DIFFSERV NETWORK ARCHITECTURE

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

Classification

Classifier

Marker

Conditioning

Shaper

Dropper

Meter

Control Flow

FIGURE 40 : DIFFSERV ARCHITECTURE (SIMPLIFIED) FOR EDGE ROUTERS

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

(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 (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

4.3.3.3.3

4.3.3.4

4.3.3.4.1

92

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.

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].

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

L2 Header (PPP/Ethernet/...)

93

L2 Header Label Stack Layer 3 Header

Generic Encapsulation/ Shim Header

L a b e l l (

( 0 )

E x p S T T L

2 0 B i t t s

3

B i t s

1

B i i t t

8 B i i t t s

¾ 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 networkbased 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

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

LSR Label Switching Router

• Label Swapping

IP Packet

IP Packet w/ Label

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.

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

Lbl

X

X

..

Remote

Lbl

1

2

Address

Prefix

Interface

128.89

171.69

1

1

… …

4.3.3.4.2

Label Information

Base

Local

Lbl

1

2

Remote

Lbl

7

5

Address

Prefix

Interface

128.89

0

171.69

4

3 … …

128.89

0

171.69.12.1 Data

I/f 1

2

171.69.12.1 Data

I/f 4

5

171.69.12.1 Data

171.69

Unlabeled Data

171.69.12.1 Data

CEF

Forwarding Table Populated with

Routing Topology Information

Each Route/Prefix Mapped to a Label Value

Switching Decision Then Only ‘Label-

Swaps’ via the Label Information Base (LIB)

Unlabeled Data

FIGURE 43 : MPLS - SWITCHING EXAMPLE

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.

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.5

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.

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

4.3.3.4.6

4.3.3.5

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.

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.

Subnet Bandwidth Manager SBM

QoS assurances are only as good as their weakest link. The QoS "chain" is end-toend 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

P R E A M .

.

S F D D

A

S

A T y p e

4

T

B

A y

G t e s

P T D A T A F C S

Three Bits Used for CoS

(802.1D User Priority)

4.3.3.5.1.1

V L A

N

I

I

D

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

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

R2

Host

C

DSBM

Host

B

Router

R3

Path

LAN

Segment

Host

A

Path

DSBM client

Router

R1

DSBM client

Path

SBM

FIGURE 45 : EXAMPLE OF A MANAGED SEGMENT

4.3.3.6

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.

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)

4

6

5

3

6 5 4 3 2 1

1

2

FIGURE 46 : FIFO, FIRST IN FIRST OUT

FIFO still exists, but today's intelligent networks need more sophisticated algorithms.

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

Input arrival timing

Stream precedence

5

2

1

Queue Output

7

6

4

3

1

2

3

4

7

3 6 5 4 2 1

FIGURE 47 : PRECEDENCE 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

7

6

4.3.3.6.4

8

7

6

4.3.3.6.5

5

2

50%

4

1

20%

20%

7

6 8 4 5 3 2

1

3

10%

FIGURE 48 : CLASS BASED QUEUING

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%

5

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

1

50%

4

3

2

20%

20%

10%

7

6 8 3 5 4 2

1

FIGURE 50 : WEIGHTED FAIR QUEUING

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.

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.

Without

RED

Packet

Drop

Proba bility

Queue

Queue Max

With

RED

Packet

Drop

Proba bility

Queue Length

“Slope” is adjustable

Queue Max

With

WRED

Packet

Drop

Proba bility

Standard

Service

Queue Length Std. Min. Prem. Min.

Premium

Service

Queue Max

FIGURE 51 : QUEUE MANAGEMENT

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

X

Provisioned resources end-to-end (e.g. private FrameRelay or ATM network)

least

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

X

DiffServ applied at network core ingress

Fair queuing applied by network elements (e.g. WFQ, RED)

Best effort service

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.

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-toend 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 perflow classification, policing, and marking

DiffServ Region

The DiffServ region aggregates the flows into DS Forwarding

Classes

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 aggregate data handling

Intserv per-flow data handling

Diffserv aggregate data handling

MPLS

Label Switch

Path

Switched

Network

Small

Routed

Network

Large

Routed

Network

(Diffserv)

Admission control agent for 802.1 network (DSBM)

Admission control agents for Intserv network

Admission control agent for diffserv network

MPLS

Network

Admission control agent for MPLS 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 conjugatestructure 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 conjugatestructure 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

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

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 RSVPbased 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.3

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.

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

5.3.1.3

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 subsecond one or much more higher depending on the network topology.

Rendez-vous point election/management

Few standard and non-standard protocols exist for the election/management of the rendez-vous point, which are:

5.3.1.4

• Anycast-RP.

They are discussed later in this document.

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

DR, Q

Sender

DR

Q

SF

SF

RP

SF

SF

Receiver

Source tree

Shared tree

Shortest path (source) tree

Forwarding router

Non forwarding router

Q : Querier, IGMP component

DR, SF, RP : PIM components

FIGURE 54 : PIM-SM ARCHITECTURE

© EUROCAE, 2009

Sender

DR

Q

114

PIM-SSM architecture

SF DR

Q

Receiver

Sender

Shortest path (source) tree

Q : Querier, IGMP component

DR, SF : PIM components

Forwarding router

Non forwarding router

FIGURE 55 : PIM-SSM ARCHITECTURE

Bidir-PIM-architecture

RP

DF DF

DF DF, Q

Q

Receiver

Shared tree

Q : Querier, IGMP component

DF, RP : PIM components

Forwarding router

Non forwarding router

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

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,

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 name

PIM-DM

Standard

RFC 3973

PIM-SM RFC 2362 +

Draft-ietfpim-sm-v2new-11

PIM-SSM RFC 3569 +

Draft-ietfpim-sm-v2new-11

Bidir-PIM Draft-ietfpim-bidir-07

Description

Pros/Cons Type of flow

PIM-Dense Mode

PIM-Sparse Mode:

- support both source tree and shared tree

- use a RP, DR and SF

Bad mode :

- 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

Pros:

Don’t use it

One-to-many

- traffic sent down on “joined” branches only

- basis for inter-domain multicast routing

Cons:

Few-to-few

Few-to-many

- Shortest Path Tree

(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-Source Specific

Multicast

Pros:

- optimized path which can help to have

- use only source tree

- no RP optimized delay,

- no problem of redundancy with RP

- use of DR and SF

- host responsible for

- no use of assert function

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

One-to-many

Few-to-few

Bidirectional PIM

- shared tree only

- use the same tree for traffic from source to RP and from RP to receivers.

The RP can be virtual and technology in the receivers or at receivers

DR (CISCO DR offers proprietary mechanism when IGMPv2 is used)

Pros:

- less states on the routers (save router’s

CPU loading and memory)

Cons:

- non optimized delay for voice flows with shared tree

- redundancy of DFs and RP if any RP represented by an IP address.

- requires DFs

(recovery time)

- need a way to monitor active sources.

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.

Many-to-few

Many-to-many

TABLE 17 - COMPARISON OF PIM MODES

© EUROCAE, 2009

117

5.3.4 Rendez-vous point election/management

PIM BSR

Static RP

Anycast-RP

Protocol name Standard

Auto-RP

Cisco

Description

- All routers learn automatically RP address

- Mapping Agent (MA) receives announcement from Candidate RP (C-RP),

- Make use of multicast to distribute info,

- Permit back up of RP,

- can be used with Admin-Scoping

Pros/Cons

Cons:

RP and MA back up time out of the scope of ATM needs

PIM Dense Mode needed to distribute the RP-announce and RP-discover groups. This creates the potential for

DM Fallback to occur

Cons:

RP and BSR back up time out of the scope of ATM needs

RFC 2362

+ Draft-ietfpim-sm-v2new-11

+ Draft-ietfpim-sm-bsr-

05

- a BootStrap Router (BSR) is elected,

- BSR receives Candidate RP (C-RP) messages and store the information to

Group-to-RP mapping cache,

- BSR sends the Group-to-RP mapping cache to all C-RPs,

- 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

Hard coded RP address N/A

RFC 3446 - within a domain deploy more than one RP for the same multicast group range

- give each RP the same IP address assignment

- sources and receivers use closest RP

- use MSDP (Multicast Source Discovery

Protocol) to communicate existence of sources between RPs

- compatible with admin-scoping

Cons:

No RP back up

Pros:

- RP back up possible

- RP recovery time is based on unicast protocol recovery time

Cons:

- distribution of RP address: static or

Auto-RP can be used for this

TABLE 18 - COMPARISON OF RP ELECTION/MANAGEMENT

Four Rendez-vous point election/management protocols exist in IPv4. They are discussed in the following table:

5.3.5 IGMP

Protocol name

IGMPv1

IGMPv3

Three versions of IGMP are existing. The following table gives an overview of IGMP for VoIP in ATM:

Standard

RFC 1112

Description Used by

Superseded by

IGMPv2

PIM-DM, PIM-SM,

Bidir-PIM

“Join (*,G)” based protocol

Introduction of the leave group message to be more efficient

RFC 3376 New feature: include/exclude source list

“Join (S,G)” based protocol

Requires new “IPMulticastListen API”

New IGMPv3 stack required in the OS

Start to be implemented

PIM-SSM

TABLE 19 - COMPARISON OF IGMP

© EUROCAE, 2009

118

5.4 INTRA-DOMAIN MULTICAST SOLUTIONS FOR IPV6

5.4.1 Multicast protocols overview

IP multicast service

Group management

Multicast routing protocols

RP election/manage ment

The following table summarizes IPv6 situation:

IPv4 IPv6 IPv6

-

IGMPv2 MLDv1

IGMPv3 MLDv2

PIM-DM

PIM-SSM

Will never exist

PIM-SM PIM-SM

PIM-SSM requires MLDv2

Bidir-PIM Bidir-PIM

Auto RP

PIM BSR

No study on it

PIM BSR

Static RP Static RP

Anycast RPs Under study

RP:

– no RP redundancy,

– not supported by Bidir-PIM

TABLE 20 - MULTICAST FOR IPV6

-

2362

+ Draft-ietf-pim-sm-v2-new-11

RFC 3569 + Draft-ietf-pim-smv2-new-11

Draft-ietf-pim-bidir-07

-

RFC 2362

+ Draft-ietf-pim-sm-v2-new-11

+ Draft-ietf-pim-sm-bsr-05

-

-

RFC 3956 and subset of RFC

3306

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).

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.

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

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 “Adminscoping” facility.

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.

Coexistence of different PIM modes on the same network topology 5.5.4

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 9 th

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 9 th

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

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

M

MA

MLD

MRIB

MSDP

P

PIM

PIM BSR

PIM-DM

PIM-SM

PIM-SSM

Q

Q

R

RP

RPF

A

ATM

B

Bidir-PIM

BSR

C

CBT

CGMP

C-RP

D

DF

DR

DVMRP

I

IGMP

S

SF

SPT

V

VoIP

125

APPENDIX B

ACRONYMS

- Air Traffic Management

- Bidirectional Protocol Independent Multicast

- BootStrap Router

- Core Based Tree

- Cisco Group Management Protocol

- Candidate Rendez-vous Point

- Designated Forwarder

- Designated Router

- Distance Vector Multicast Routing Protocol

- Internet Group Management Protocol

- Mapping Agent

- Multicast Listener Discover

- Multicast Routing Information Base

- Multicast Source Discovery Protocol

- Protocol Independent Multicast

- Protocol Independent Multicast BootStrap Router

- Protocol Independent Multicast Dense Mode

- Protocol Independent Multicast Sparse Mode

- Protocol Independent Multicast Source Specific Multicast

- Querier

- Rendez-vous Point

- Reverse Path Forwarding

- Single Forwarder

- Shortest Path Tree

- Voice over IP

© EUROCAE, 2009

126

APPENDIX C

CONFERENCE CALL RECOMMENDATION (NETWORK POINT OF VIEW)

Concept Logical Con’s

‚simple concecpt’

Unicast

Many traffic

CWP

(only unicast is

Costs

Mixer

Unicast

used)

Delay efficient

Conference

Unit

Mixer

2+3

1

1+3

1

CWP

SIP UA

2

CWP

SIP UA

‚simple concept’

(only unicast is used)

More Delay

More

Traffic

(increases risk of congestion)

2

1+2

3 3

CWP

SIP UA

CWP

Unicast

Multicast

Delay efficient

Traffic efficient

(Path efficient)

Complexity

Multicast involve additional routing and protocols

Mixer

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.

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

Class A Byte 1 Host portion

Network portion

1 0

Byte 4

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

1

Byte 2

Class E Experimental

Byte 3 Byte 4

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 (bits)

Address number range

(decimal)

A

B

8

16

0 – 127

128 - 191

C 24

TABLE 21 - NUMERIC RANGES

192 - 223

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.

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

001

(3bits)

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

Global routing Prefix

(45 - bits)

Subnet ID

(16 - bits)

Interface ID

(64 - bits)

1111111011

or

FEC0::10

(10 - bits)

1111111010

or

FE80::10

(10 - bits)

Global Unicast Address Format

Set value to

0”

(38 – bits)

Subnet ID

Site Link add (16bits)

Interface ID

(64 – bits)

Site – Local Unicast Address Format

Set value to “0”

(54 – bits)

Interface ID

(64 – bits)

Link – Local Unicast Address format

FIGURE 59 : TYPE OF UNICAST ADDRESSING FORMAT

Table 22 illustrates IPv6 main addressing type.

Allocation

Global Unicast Addresses

Link Local Addresses

Site Local Addresses

Multicast Addresses

Prefix

001

1111 1110 10

1111 1110 11

1111 1111

Function of Address

Space

1/8

1/1024

1/1024

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

(64 – bits)

111111X1111….111

(57- bits)

Anycast ID

(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.

0000………………………………….0000

(80 – bits)

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].

XXXX

(16-bits)

IPv4 address

(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

(8-bits)

Flags (4-bits)

and

Scope (4-bits)

Group ID (112 – 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

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)

Network bits representation: Subnet mask in dotted decimal notation or prefix length

IPSec support is optional

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

TABLE 23 - IPv4 AND IPV6 EQUIVALENT

IPv6, which provides the networking services found in IPv4, as well as these additional features:

More efficient addressing design and handling at the IP network layer

Better QoS support

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.

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

[email protected]

[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 costeffective 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

7.2.1

7.2.1.1

7.2.1.3

137

Threats in VoIP networks

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.

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.

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

7.3

138

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.

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

7.4.1

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.

Encryption for VoIP networks

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.

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

7.4.1.2.1

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).

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.

Encryption / Decryption Latency 7.4.1.2.4

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

Clear Voice Only 2 MB 7ms

Clear Voice Only

IPSec 3DES, SHA Voice Only (Software)

128Kbps

2 MB

69ms

22ms

IPSec 3DES, SHA Voice Only (Software)

IPSec 3DES, SHA Voice Only

IPSec 3DES, SHA Voice Only

128Kbps

2 MB

128Kbps

104ms

11-12ms

95ms

TABLE 24 - IPSEC AND INTRODUCED DELAY

© EUROCAE, 2009

7.4.1.2.5

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.

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 cryptoengines 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 cryptoengines. 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

7.4.1.2.6

7.4.1.2.7

7.4.1.3

7.4.1.3.1

7.4.1.3.2

145

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 cryptoengine, 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).

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.

Other encryption solutions

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.

Secure Real Time Protocol (SRTP) – RFC 3711

RTP (Real-time Transport Protocol) is commonly used for the transmission of realtime 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 keylength 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

7.4.2

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.

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.3

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.

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

7.4.2.4

7.4.2.4.2

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.

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.

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.

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

7.4.2.4.3

7.4.2.4.4

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.

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.

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

7.4.3

150

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.

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

7.4.5

FIGURE 66 : MIDDLEBOX CONCEPT

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

7.4.6

153

IPS (Intrusion Prevention Systems)

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

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.

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 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.

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

7.5

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.

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

ƒ Eavesdropping/Man-in-the-middle

ƒ Directed TCP and ICMP attacks

-

Attacks against VoIP/IP telephony servers

ƒ Worms, viruses and trojans

ƒ DoS DdoS

ƒ

Directed probes, floods

-

Attacks against VoIP/IP telephony applications

ƒ Intercept administration and user traffic

ƒ Rogue

ƒ

Toll

With respect to the classification above, the best practices offered today by technology to put against the threats mentioned are:

© EUROCAE, 2009

7.5.1

7.5.2

156

Secure the network infrastructure for voice

General Security Best Practices:

-

-

-

Management and signalling secure protocols: SSH/HTTPS

Permit lists (filters)

Routing process authentication

-

-

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)

-

-

Dynamic ARP inspection

IP source guard

-

-

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

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

7.5.3

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

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

7.5.4

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

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

-

-

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 o

Default key length—1024 bits; optionally 512 or 2048 bits

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 o o o o

RSA o

HMAC-SHA-1 authentication tags o

AES-128-CBC o

Supports any application-layer protocol: HTTP, FDP, LDAP etc. o o

Bi-directional PKI establishes Identity

HMAC provides Integrity

Encryption offers Privacy

Needs secure method to exchange shared secret

ƒ

ƒ

Bi-directional PKI pairs for mutual authentication

Shared secret generated using RSA

Computes Hashed Message Authentication Code (HMAC)

ƒ Allows MD5 or SHA1

Conventional cryptography using shared secret

ƒ DES, 3DES, AES

ƒ RC2,

ƒ IDEA

-

SRTP—Secure RTP (RFC3711) protects media (voice) traffic between endpoints o

HMAC-SHA-1 authentication tags o

AES-128-CM

© 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

Characteristics IPSec-based VPN MPLS-based VPN

High-speed Internet services, business-quality IP VPN services,

High-speed Internet services, business-quality IP VPN services, e-commerce and applicationhosting services e-commerce and applicationhosting services

Scalability

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.

Place in Network

Large-scale deployment required planning and coordination to address issues on key distribution,

Highly scalable since no site-tosite peering is required. A typical

MPLS-based VPN deployment is key management, and peering configuration capable of supporting large-scale

VPN groups over the same network

Best at the local loop, edge and offnet where there is a higher degree of exposure to data privacy and where IPSec security mechanisms such as tunneling and encryption can best be applied

Best within a service provider’s core network where QoS, traffic engineering, and bandwidth utilization can be fully controlled, especially if

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

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.245based) 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.

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

8.2.2

8.2.2.3

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.

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].

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.

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.

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

8.2.3

8.2.3.3

167

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

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.

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.

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

8.2.4

8.2.4.3

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].

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

- authorization and access control

- suitable remote configuration and administration capabilities for these features.

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.

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].

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.

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.

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

8.2.4.3.4

8.2.4.4

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.

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.

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

8.3

171

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-ondemand 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

© 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 realtime 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

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement