/ International Civil Aviation Organization

WORKING PAPER / ACP-WG-I-06/WP-02
07 March 2008

AERONAUTICAL COMMUNICATIONS PANEL (ACP)

WG I – Internet Protocol Suite – 6th MEETING

Canada, Montreal, 17-21March 2008

Proposed definition ofIPSClasses of Service

Prepared by Eivan Cerasi (EUROCONTROL)

IPS CoS

1Introduction

Former WG-I#5 Working Paper 15 summarised IETF defined DiffServ Per Hop Behaviours (PHB) in order to apply these to the ATNIPS. Indeed, in practice most network operators group their offerings on the following PHBs:

  • EF (Expedited Forwarding) – defined in RFC 3246, intended as a low loss, lowdelay, low jitter service. This would typically be used for voice applications.
  • AF (Assured Forwarding) – defined in RFC 2597 and updated in RFC 3260. Assured forwarding allows the operator to provide assurance of delivery as long as the traffic does not exceed some subscribed rate. These classes would be used for delay sensitive data applications usually labelled AFx. Typically each specific customer applications would be matched to a specific AF class and usually one AF class is associated to multimedia applications e.g. video.AF classes have the same priority, but benefit ofindividual guaranteed bandwidth. This prevents one critical application to take allthe available bandwidth and block other critical applications.
  • Default – A best effort class which would be used for non mission-critical,non-delay sensitive applications.

The RFCs do not dictate the way to implement PHBs; this is the responsibility of the vendor. Typically, PHBs can be based on the values of the DSCP field, IP precedence (old ToS field) or IP header information.

As a result of WG-I#5 Working Paper 15, it was agreed to elaborate a mapping of ATNIPS applications to this CoS definition approach based on their level of operational importance and/or priority requirements defined in Annex 10, Volume III, Part I (Amd 83).

2Class Definitions

2.1Context

ATNIPS communication service providers are likely to make use of the same IPS infrastructure for ATN and other non-ATN defined applications; for example, ATSMHS and AIS application data. Sharing of resources can be at different levels, ATNIPS applications canuse the same type of class of service as other non-ATN applications over the same IP routed infrastructure. Alternatively, ATNIPS communication service providers may only wish to share the same physical infrastructureand operate a VPN per service; in this case a separate CoS model can be applied to each VPN service, one being the ATN/IPS.Fundamentally, ATNIPS communication service providers have flexibility in how they enable CoS for the ATNIPS over their infrastructure.

For CoS definitions, it is essential that ATNIPS traffic is sufficiently qualified in order to properly mark ingress traffic. As the IP packet enters the network core, PHBs are enforced, depending on the packet marking. ATNIPS communication service providers will need to handle un-marked or pre-marked ingress traffic and be prepared to mark or re-mark the traffic before it is routed over their infrastructure. The internal techniques, mechanisms and policies to enforce the PHB within the communications service provider networks are considered out of scope of the ATNIPS.

2.2Annex 10, Volume III, Part I

The following table defines the ATN priorities as extracted from the Annex 10, Volume III, Part I per Amendment 83.

Table 1 - Annex 10 Priority Table

As further noted in the ICAO Document 9705, the essential role of ATNpriority is to ensure that high priority safety related data is not delayed by low priority non-safety data, and in particular when the network is overloaded with low priority data. ATN priority covers two key aspects:

  • Mapping application priority through the transport and network layers to the subnetwork to signal priority at ingress
  • Use of the network priority value to ensure that traffic is handled properly by each intermediate ATN/OSI router within the routed network (but without specifying a mechanism)

Within their respective headers, the IETF TCP/UDP transport layers do not support a specific priority parameter. As a result, the ability to map application priorities needs to be accommodated through other means. In the case of the ATN/IPS this is met by:

  • Mapping of application priorities to PHBs to allow ATNIPS communication service providers appropriately mark ingress IP packets
  • Allow the ATNIPScommunication service provider select the optimum QoS mechanisms within its infrastructure in order to meet each PHB and select its means to relay this information between intermediate IP routers

The ATN/OSI also allows a given application entity to signal different priorities per user message category. However, it is recognised that this is not dynamic and may lead to the use of separate transport connections. The use of the ATN/OSI security label is also used as a means to convey the ATN/OSI ATSC Classes which are no longer part of Annex 10, Volume III, Part I.

2.3ATNIPS PHBs/CoS

The ATNIPS is to support legacy ATN applications over the IPS. Currently, this intended support covers CM(DLIC), FIS(ATIS), CPDLC, ADS-C, ATSMHS. Indeed, DIR is only specified for ATN/OSI and it is foreseen that AIDC will be implemented through regional solutions.

ATNIPSprovisions may also cover VoIP and surveillance data exchange services.

The dynamic support of different priorities per user message category is not considered in this table as each ATN application is mapped to a single CoS.

Table 2captures a proposed mapping table of the ATN applications to 5 Classes of Service labelled Very High, High, Normal and Best Effort. It is to be noted that if each application were to be part of a dedicated CoS the priority values in Annex 10 become meaningful. However, this paper proposes to regroup a number of applications into the 5 basic classes of service and allow communication service providers to make further class definitions if required.

Priority/Application Mapping / Traffic Identification (Ingress)
Class
(CoS Type) / ATN
Priority / ATN
Application / Transport
Port / IP
Source / IP Destination / Etc.
Very High (EF) / Voice (VoIP using G.729) / RTP numbers 16384-32767
High
(AF) / 0
1
2
3 / ADS-C
CPDLC
Normal
(AF) / 4 / AIDC / TCP 8500[1]
FIS(ATIS)
5 / METAR
6 / CM(DLIC)
ATSMHS / TCP 102
7
Best Effort
(Default) / 8 - 14 / - / -

Table 2 - ATN/IPS Priority mapping to Classes

In order to mark ingress traffic, the ATNIPS provider has several means to identify the traffic: destination transport port number, IP source address, IP destination address. This will need further development by the WGI.

Note:- Making user of the DSCP/ToS value set by the application or prior communication service provider may not the optimum approach as the value may be incorrectly configured or unknown.

3Traffic Characterisation

Traffic characterisation is a means to express the type of traffic patterns, integrity and delay requirements etc. It provides further information to the communication service provider to fully meet the user requirements in a specific implementation context. In most cases this information is also part of the contracted service level agreement in which further parameters are defined such as: service delivery points, service resilience, required bursting in excess of committed bandwidth, service metric points, MTTR, port speeds.

The following information would need to be complemented for Air/Ground applications and can be derived from the existing implementations and estimations within the FAA/EUROCONTROL COCR. The values for ground-ground services are derived from the Pan-European Network Services (PENS) specifications.

ATN
Application / Average
Message
Lenght / Expressed
Integrity / Jitter / Typical
Bandwidth
(point-to-point) / Network Delay
(1-way)
Voice (VoIP using G.729) / 70
(bytes) / - / <15ms / 12kbps / <100ms
OLDI/FMTP (Regional AIDC) / 150 (bytes) / 1 user corrupt message in 2000 / N/A / 10kbps / <1s
ATSMHS / 3 kbytes / 10-6(in terms of 1000bytes message blocks) / N/A / 20kbps / <5s

Table 3 - Traffic Characterisation

4Input for the ATNIPS Doc 9896

It is proposed that the ATNIPS Manual integrates the priority mappings into Part I (Detailed Technical Specifications) of Document 9896 and that the traffic characterisation as part of Part III (Guidance). Supporting guidance material can be also be prepared on the basis of sections 1 and 2.

5Action

The group is invited to consider the following recommendations:

  1. Confirm the approach to define CoS for the ATNIPS as specified in section 2.3
  2. Agree to integrate the mapping table of ATN Annex 10 priorities to classes as outlines in Table 2
  3. Agree to integrate guidance on the ATNIPS CoS approach and traffic characterisation information as part of the Guidance Material.

1

[1] This is applicable when OLDI/FMTP is used as a means to enable AIDC services.