ED-138 Part 1

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 Tel: 33 1 40 92 79 30

92240 MALAKOFF, France Fax: 33 1 46 55 62 65
Web Site: www.eurocae.net Email: eurocae@eurocae.net
NETWORK REQUIREMENTS AND PERFORMANCES FOR VOICE
OVER INTERNET PROTOCOL (VOIP) AIR TRAFFIC MANAGEMENT
(ATM) SYSTEMS
PART 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
1 The document ED-138 “Network Requirements and Performances for
VoIP ATM Systems” was prepared by EUROCAE Working Group 67 and
was accepted by the Council of EUROCAE on 2 February 2009.
2 EUROCAE is an international non-profit making organisation. Membership is
open to manufacturers and users in Europe of equipment for aeronautics,
trade associations, national civil aviation administrations and non-European
organisations. Its work programme is principally directed to the preparation
of performance specifications and guidance documents for civil aviation
equipment, for adoption and use at European and world-wide levels.
3 The findings of EUROCAE are resolved after discussion among its members
and, where appropriate, in collaboration with RTCA Inc., Washington D.C.
USA and/or the Society of Automotive Engineers (SAE), Warrendale, PA,
USA through their appropriate committee.
4 The document represents “the minimum specification required for
Manufacturers and Users to qualify Network interconnecting VoIP ATM
Systems”.
5 EUROCAE performance specifications are recommendations only.
EUROCAE is not an official body of the European governments; its
recommendations are valid statements of official policy only when adopted
by a particular government or conference of governments.
6 Copies of this document may be obtained from:
EUROCAE
102 rue Etienne Dolet
92240 MALAKOFF
France
Tel: 33 1 40 92 79 30
Fax: 33 1 46 55 62 65
Email: eurocae@eurocae.net
Web Site: www.eurocae.net
© EUROCAE, 2009
ii
TABLE OF CONTENTS
FOREWORD .......................................................................................................................... I
TABLE OF CONTENTS .................................................................................................................. II
CHAPTER I INTRODUCTION .............................................................................................. 1
1.1. Background....................................................................................................... 1
1.2. ED-138 Presentation ........................................................................................ 2
1.3. Terminology for requirements, recommendations, and options ....................... 3
CHAPTER I REFERENCES............................................................................................................ 4
CHAPTER II NETWORK SPECIFICATION........................................................................... 5
2.1. General information .......................................................................................... 5
2.1.1. Operational Voice Applications in ATM............................................. 6
2.1.2. Numbering of Requirements, Recommendations and Options......... 6
2.1.3. Network Concepts ............................................................................. 7
2.2. Specific Network and Services Requirements ................................................. 7
2.2.1. IP Addressing and Protocols ............................................................. 8
2.2.2. IP Networking and Routing................................................................ 8
2.2.3. Applications and Quality of Service (QoS) requirements.................. 9
2.3. Network Functional and Performance Requirements....................................... 9
2.3.1. Network connectivity ......................................................................... 9
2.3.2. Quality and Performance................................................................... 10
2.3.3. Availability.......................................................................................... 10
2.3.4. Class of Service CoS and Quality of Service QoS............................ 10
2.3.5. Maintenance and Diagnostics ........................................................... 12
2.4. Network Management and Procedures ............................................................ 12
2.4.1. Fault Management ............................................................................ 12
2.4.2. Configuration Management ............................................................... 13
2.4.3. Performance Management................................................................ 13
2.5. Specific Safety and Security Requirements ..................................................... 14
2.5.1. Security Policy and requirements...................................................... 14
2.5.2. Security Management ....................................................................... 14
CHAPTER II REFERENCES........................................................................................................... 16
CHAPTER III SECURITY POLICY ......................................................................................... 17
3.1. Background....................................................................................................... 17
3.2. ATM Security Principles.................................................................................... 17
3.2.1. Confidentiality.................................................................................... 17
3.2.2. Integrity.............................................................................................. 17
3.2.3. Availability.......................................................................................... 18
3.3. VoIP Security .................................................................................................... 18
3.3.1. Threats in VoIP networks .................................................................. 18
3.4. Network Model.................................................................................................. 19
© EUROCAE, 2009
iii
3.5. Security requirements....................................................................................... 21

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
3.6. General recommendations ............................................................................... 22
CHAPTER III REFERENCES.......................................................................................................... 24
CHAPTER IV IP ADDRESSING.............................................................................................. 26
4.1. Background....................................................................................................... 26
4.1.1. IPv4 Overview ................................................................................... 26
4.1.2. IPv6 Overview ................................................................................... 27
4.1.3. Why IPv6 ........................................................................................... 31
4.1.4. Transition Mechanisms ..................................................................... 31
4.2. Addressing Scheme (Revised iPAX Scheme).................................................. 32
4.2.1. Address Management ....................................................................... 33
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.
• Accordingly, make recommendations to upgrade current standardisation
documents.
• Develop a Technical Specification for an IP Voice ATM System including:
o Minimum performance and safety / security requirements for the system
and, if appropriate, for components
o Interoperability requirements between IP components of the IP Voice
ATM systems
o Minimum performance requirements of an IP Network aimed to support
Voice in ATM.
o Guidelines for qualification tests of IP Voice ATM systems and IP Voice
ATM components.
So four documents with a common reference to “Vienna Agreement” 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
1.2 ED-138 PRESENTATION
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 Network Specification
o Security Policy
o 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
3
1.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:
• The word SHALL denotes a mandatory requirement
• The word SHOULD denotes a recommendation
• The word MAY denotes an option
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. SHOULDThis 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
2.1 GENERAL INFORMATION
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 EATM1 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 G-G Voice Principally for Centre/Centre and Centre/Tower

COORDINATION 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.
AIR GROUND A-G Voice Principally nationally based but SES2 may require trans-
SERVICES national ground connectivity.
WG-67 only considered communication between VCS and
Radio without air links.
TABLE 1 - OPERATIONAL VOICE APPLICATIONS IN ATM
RADIO
WAN
VoIP
VCS 1 VCS 2
VCS = Voice Communication System
FIGURE 3 - CONSIDERED VOICE APPLICATIONS IN WG67
2.1.2 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.
1
European Air Traffic Management
2
Single European Sky; http://www.eurocontrol.int/ses/public/subsite_homepage/homepage.html
© EUROCAE, 2009
7
2.1.3 Network Concepts
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
IP
IP
IP
IP
LAN EDGE WAN EDGE LAN
FIGURE 4 - IP NETWORK DOMAIN CONCEPT
2.2 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
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
• Standardized Interfaces
(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].
2.2.1 IP Addressing and Protocols
(3) IPv6 (RFC 2460) SHALL be supported by the IP Network.

(4) The defined IP Addressing Scheme in Chapter 4.2 SHALL be used.
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.
2.2.2 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
(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 Acceptable
Acceptable
Application latency3 (without Acceptable Jitter3
2. with CRTP Packet Loss rate
jitter)
3. with CRTP and
IPSec
Default N/A N/A N/A N/A

(best effort)
1. 160 Bytes
Telephone voice 2. 164 Bytes 100ms 15ms 0.5%
3. 212-222 Bytes
1. 160 Bytes
Radio voice 2. 164 Bytes 50ms 15ms 0.5%
3. 212-222 Bytes
Telephone
100ms4 50ms 0.5%
Signalling
Radio
50ms4 50ms 0.5%
Signalling
Recording 100ms 50ms 0.5%
TABLE 2 - APPLICATION REQUIREMENTS
2.3 NETWORK FUNCTIONAL AND PERFORMANCE REQUIREMENTS
2.3.1 Network connectivity
(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 Climax5 is chosen, fixed network paths
SHOULD be used in the IP Network.
3
All latency values are one-way delays
4
Value is given for the network path between two elements involved in the call-setup
5
Multi-station carrier offset mode, with voting override
© EUROCAE, 2009
10
2.3.2 Quality and Performance
A detailed explanation of these criteria is provided in ED-138 Network Requirements

IV.
(14) Maximum amount of possible concurrent voice calls (voice channels) Vmax and
signalling (signalling channels) Smax 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 Vmax + Smax concurrent
channels.
(16) For this maximum amount of channels Vmax + Smax, 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.
(17) Header compression MAY be supported by the IP Network. Note: Header
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.
(18) IP Network SHALL achieve the required availability of the overall system.
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
III.
2.3.4 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.
(20) Prioritisation: IP Network SHALL provide methods of prioritising traffic based on
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.
(21) IP Network SHALL support Differentiated Service (Diffserv) (RFC2474/2475)
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 AFij, 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
000000 CS0 (DEFAULT) 011010 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
111000 CS7
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.
Application DSCP value Codepoint
Default 000000 CS0

(best effort)
Telephone voice 101110 EF

Radio voice
Telephone signalling 100010 AF41
Radio signalling
Recording voice 011010 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
(28) The IP Network SHALL have the capability to conduct maintenance and
diagnostic procedures to support the quality and performance requirements.
2.4 NETWORK MANAGEMENT AND PROCEDURES
2.4.1 Fault Management
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.
(29) Fault Management SHALL be available for the IP Network to undertake all
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
2.4.2 Configuration Management
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:
• Operating system
• 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.
2.4.3 Performance Management
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.
(33) The IP Network SHOULD have a capability to perform forensic analyses as
explained above.
(34) The IP Network MAY have a capability to perform Capacity planning and
Bandwidth on demand as explained above.
© EUROCAE, 2009
14
2.5 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:
• Fast delivery
• Priority for critical information (e.g., emergency call)
• Service Availability
• Redundancy/Backup services
Tools that could support these requirements include:
• Secure real-time transport protocol (SRTP)
• Security and encryption using IP Security (IPsec)
2.5.1 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.
2.5.2 Security Management
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;
[3] IETF RFC 2460: Internet Protocol (IP) version 6 Specification;
[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
© 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 cost-
effective sharing of common media with data communications. On the other hand, the
accessibility provided by this technology leaves it open to malicious intrusion. To
address such vulnerabilities, an architecture founded upon robust security protections
should be developed, based upon stakeholder policies and needs, and industry
standards and best practices.
The scope of this chapter is to 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 VOIP SECURITY
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.
3.3.1 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
3.4 NETWORK MODEL
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
IP Core Provider
Responsibility of
IP Core
IP Core IP Core IP Core

Edge Edge Edge
Security
Zone 2
Demarcation Line
Possible Interconnections
ANSPs/Organizations
Responsibility of
Organization Organization Organization

Edge Edge Edge
Security
Zone 3 Organization Organization Organization
(WAN) (WAN) (WAN) Admin
Network
LAN LAN LAN
VoIP VoIP VoIP
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
3.5 SECURITY REQUIREMENTS
This section describes the security requirements for the Security Zones shown in
Figure 5.
3.5.1 Zone 1 (IP Core)
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.
• Firewalling rules SHALL be defined and implemented; at least static packet filtering (“stateless
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.
3.6 GENERAL RECOMMENDATIONS
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].
• Softphone systems SHOULD be avoided when security and privacy is a concern.
• 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;
[3] IETF RFC 2460: Internet Protocol (IP) version 6 Specification;
[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);
[6] IETF RFC 4301: Security Architecture for the Internet Protocol;
[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,
[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)
[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)
[11] IETF RFC 4306: Internet Key Exchange (IKEv2) Protocol
[12] IETF RFC 3550: RTP: A Transport Protocol for Real-Time Applications;
[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
[14] IETF RFC 3265: Session Initiation Protocol (SIP) – Specific Event Notification;
© 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
[16] IETF RFC 2764: A Framework for IP Based Virtual Private Networks;
[17] IETF RFC 3315: DHCP for IPv6; IETF RFC 4361: Node-Specific Client
Identifiers for DHCPv4
[18] IETF RFC 4251: The SSH Protocol Architecture;
[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”
[21] IETF RFC 3414, User-based Security Model (USM) for version 3 of the Simple
Network Management Protocol (SNMPv3)
© 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
Force6.
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.
4.1.1 IPv4 Overview
IPv4 addresses are used to identify device interfaces to hosts, routers, gateways,
adapters, and IPv4 telephones. Each device interface in an IPv4 network must be
assigned to a unique IPv4 address to receive or transmit voice and data packets.
IPv4 uses 32-bit binary numbers to identify the source and destination address in each
information packet. IPv4 addresses are parsed into two portions - Network and Host.
The predominance of one portion over the other within the 32-bit space determines
the Address Class. Those classes are referred to as Class A through Class E [1].
Please see information about CIDR Address Allocation Architecture in [2].
Figure 6 illustrates the five IPv4 address class formats.
32 bits
0 Byte 2 Byte 3 Byte 4
Class A Byte 1 Host portion
Network portion
1 0
Class B Networking portion Host portion
1 1 0
Class C Networking portion Host portion
1 1 1 0
Class D Multicast address
1 1 1 1 Byte Byte 2 Byte 3 Byte 4

1
Class E Experimental
FIGURE 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 number range
address (bits) (decimal)
A 8 0 – 127
B 16 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.
4.1.2 IPv6 Overview
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 Global routing Prefix Subnet ID Interface ID

(3-bits) (45 - bits) (16 - bits) (64 - bits)
Global Unicast Address Format
1111111011 Subnet ID
or Set value to Site Link Interface ID
FEC0::10 “0” add (16- (64 – bits)
(10 - bits) (38 – bits) bits)
Site – Local Unicast Address Format
1111111010
or Set value to “0” Interface ID
FE80::10 (54 – bits) (64 – bits)
(10 - bits)
Link – Local Unicast Address format
FIGURE 8 - TYPE OF UNICAST ADDRESSING FORMAT
Table 6 illustrates IPv6 main addressing type.

Allocation Prefix Function of Address Space
Global Unicast Addresses 001 1/8
Link Local Addresses 1111 1110 10 1/1024
Site Local Addresses 1111 1110 11 1/1024
Multicast Addresses 1111 1111 1/256
TABLE 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 111111X1111…. 111 Anycast ID
(64 – bits) (57- bits) (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 XXXX IPv4 address
(80 – bits) (16-bits) (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 Flags (4-bits) Group ID (112 – bits)
(8-bits) and
Scope (4-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:
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
Table 7 illustrates IPv4 concepts and their IPv6 equivalent [1].

IPv4 Address IPv6 Address
Internet address classes Not applicable in IPv6
Addresses are 32 bits in length Addresses are 128 bits in length
Multicast address (224.0.0.0/4) IPv6 multicast addresses (FF00::/8)
Broadcast addresses Not applicable in IPv6
Unspecified address is 0.0.0.0 Unspecified address is ::
Loop-back address is 127.0.0.1 Loop-back address is ::1
Public IP addresses Global Unicast addresses
Private IP addresses (10.0.0.0/8, Site-local addresses (FEC0::/10)
172.16.0.0/12, and 192.168.0.0/16)
Auto-configured address (169.254.0.0/16) Link-local addresses (FE80::/64)
Text representation: Dotted decimal notation 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 Network bits presentation: Prefix length
dotted decimal notation or prefix length notation only
IPSec support is optional IPSec support is required
TABLE 7 - IPV4 AND IPV6 EQUIVALENT
© EUROCAE, 2009
31
4.1.3 Why IPv6
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
scalable. IPv6 is an industry-standard solution that can support such growth in
L 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
4.1.4 Transition Mechanisms
Support of legacy systems while transitioning to an IPv6 infrastructure is enabled with

the following strategies, as described:
• Dual stack, which requires that all end systems and networking devices host
concurrent IPv4 and IPv6 services in order to maintain connectivity until full
operational capability of IPv6 is achieved. Implementation of this strategy may
incur additional cost and management resources to support the deployment of
dual stacks at the various end systems. 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 auto-
configuration.
RIPE Responsibilty
(32 bits)
3 13 13 3 3 13 16 64
FP TLA ID Sub-TLA Res. NLA ID SLA ID Interface ID
Net. v4/ Site

F1 F2 LAN ESI
Prefix v6 Location
3 bits 7 bits 1 bit 5 bits variable bits variable bits 64 bits
Common Responsibilty ANSP Authority

(Coordination Body) (80 bits)
(16 bits)
FIGURE 13 - PROPOSED IPV6 ADDRESS STRUCTURE
To summarise the iPAX addressing scheme:

• The first 32 bits are fixed to 2001:4b50 (RIPE allocation)
• 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
33
4.2.1 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: EUROCONTROL, the European Organisation for the Safety of Air
Navigation
country: BE
admin-c: EJC2-RIPE
tech-c: EJC2-RIPE
status: ALLOCATED-BY-RIR
notify: eivan.cerasi@eurocontrol.int
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: EURO-HQ-MNT
mnt-routes: EURO-HQ-MNT
changed: hostmaster@ripe.net 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
[2] IETF RFC-1518, September 1993; An Architecture for IP Address Allocation
with CIDR
[3] IETF RFC-2474, December 1998; Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers
[4] IETF RFC-1752, January 1995: The Recommendation for IP Next Generation
Protocol
[5] IETF RFC-2460, December 1998: Internet Protocol, Version 6 (IPv6)
Specification
1
[6] IETF RFC-1887, December 1995 (Information): An Architecture for IPv6 Unicast
Address Allocation
[7] IETF RFC-1918, February 1996: Address Allocation for Private Internets
[8] IETF RFC-3232, January 2002, (Information): Assigned Numbers: RFC-1700 is
replaced by On-line Database
[9] IETF-RFC-4291, February 2006: IPv6 Addressing Architecture
[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
[12] IETF RFC-4213, October 2005: Basic Transition Mechanisms for IPv6 Hosts
and Routers
[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
© EUROCAE, 2009
38
LIST OF EUROCAE WG-67 CONTRIBUTORS

SURNAME NAME COMPANY
APOSTOL Catalin ROMATSA
BALKS Annette Maria CISCO
BALOI Dragos ROMATSA
BERTAGNOLIO Luca CISCO
BIEGEL Armin DFS
BRUTE DE REMUR Valérie THALES
DO-DUY Hung INEO
DUPONT Olivier CISCO
FELLOWS Graham NORTEL
GEILLER Christian INEO
KAMPICHLER Wolfgang FREQUENTIS
LEPERS Pascal SITA
MERULLI Davide OTE SELEX
PIALAT Valery SITA
RAMOS GONZÁLEZ Juan Francisco INDRA
ROYER Mickaël DSNA
SAYADIAN Leon FAA
WEILL Eric SAIC (supporting FAA)
ZOMIGNANI Marcelo INDRA
© EUROCAE, 2009

ED-138 Part 1

Uploaded by

Copyright:

Available Formats

ED-138 Part 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ED-138 Part 1

Uploaded by

Copyright:

Available Formats

The European Organisation for Civil Aviation Equipment

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

NETWORK REQUIREMENTS AND PERFORMANCES FOR VOICE

PART 1: NETWORK SPECIFICATION

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

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

PART 1: NETWORK SPECIFICATION

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

3.5. Security requirements....................................................................................... 21

FIGURE 1 - VIENNA AGREEMENT

1.2 ED-138 PRESENTATION

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

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

1.3 TERMINOLOGY FOR REQUIREMENTS, RECOMMENDATIONS, AND OPTIONS

The terminology for requirements, recommendations, and options in this document is

2.1.1 Operational Voice Applications in ATM

Eurocontrol EATM1 G-G Communications Strategy plans to integrate ATM IP Voice

SERVICE TYPE APPLICATION DESCRIPTION

GROUND G-G Voice Principally for Centre/Centre and Centre/Tower

FIGURE 3 - CONSIDERED VOICE APPLICATIONS IN WG67

2.1.2 Numbering of Requirements, Recommendations and Options

2.1.3 Network Concepts

FIGURE 4 - IP NETWORK DOMAIN CONCEPT

2.2 SPECIFIC NETWORK AND SERVICES REQUIREMENTS

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

2.2.1 IP Addressing and Protocols

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

2.2.2 IP Networking and Routing

2.2.3 Applications and Quality of Service (QoS) requirements

Default N/A N/A N/A N/A

2.3 NETWORK FUNCTIONAL AND PERFORMANCE REQUIREMENTS

2.3.1 Network connectivity

2.3.2 Quality and Performance

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

2.3.4 Class of Service CoS and Quality of Service QoS

(19) Classification: IP Network SHALL provide methods of categorizing traffic into

(23) When there is an unrecognized DSCP, assigned traffic SHALL be treated

DSCP value Codepoint DSCP value Codepoint

000000 CS0 (DEFAULT) 011010 AF31

Application DSCP value Codepoint

Default 000000 CS0

Telephone voice 101110 EF

TABLE 4 - DSCP MAPPING

2.3.5 Maintenance and Diagnostics

2.4 NETWORK MANAGEMENT AND PROCEDURES

2.4.1 Fault Management

2.4.2 Configuration Management

The goal of configuration management is to monitor and control network

2.4.3 Performance Management

The goal of performance management is to measure and optimize various aspects of

2.5 SPECIFIC SAFETY AND SECURITY REQUIREMENTS

An important consideration for safety and security is the implementation of

2.5.1 Security Policy and requirements

2.5.2 Security Management

The goal of security management is to control access to network resources in

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

3.2 ATM SECURITY PRINCIPLES

ATM communications security is characterized by the level of confidentiality, integrity,

Confidentiality ensures that the information is not disclosed to unauthorized persons or

3.3 VOIP SECURITY