1
ACP-SWGN110/WP-zz/
International Civil Aviation Organization
WORKING PAPER / ACP-SWGN1-10/WP-101620
24 September 2006
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
10th MEETING OF SUB-WORKING GROUP N-1
Montreal, Canada 25-29 September 2006
Agenda Item 5.4: / Review of latest modifications to the SARPs (Annex 10, Chapter 3)COMMENTS ON PAPER 1010 from the Secretary
Presented by the Secretary
EUROCONTROL DETAILED COMMENTS ON PROPOSED UPDATE TO ANNEX 10 ATN PROVISIONS
(Presented by Tony Kerr)
SUMMARYThis working paper provides comments on the detailed comments on the proposed updates to Annex 10 ATN provisions as provided in Working Paper 1010.
ACTION
SGN1 is requested to review the comments below.
1.INTRODUCTION
1.1This working paper provides detailed EUROCONTROL comments on the proposed updates to the ATN SARPs in Annex 10, Volume III, Part I, Chapter 3.
2.discussion
2.1General
2.1.1EUROCONTROL appreciates the need to evolve Annex 10 Chapter3 in the light of new technologies and changing ICAO policies, and fully supports the effort to update the Annex 10 SARPs.
2.1.2In the updated material, it is clear that ATN will become a generic term (with OSI and IP the implementation options) with the view to minimise dependencies on specific technologies.
2.1.3On-going studies are assessing Air-ground use of IPS; the impact of these studies on Annex 10 are unknown and can only be taken into account at a later stage.
2.2Comments on SWGN1-10 WP0509 and SWGN1-10 WP0612
Note.- WP0509 contains proposed revisions to Annex 10 ATN SARPs in the form of mark-ups to the existing published material. WP0612 is the same as WP0509, but with all revisions incorporated.
Ref / Section / Comment1 / General / General comment: ATN/OSI primarily refers to ITU-T Recommendations not ISO/IEC International Standards. It is suggested to replace “ATN based on Open Systems Interconnection (OSI) standards from the International Organisation for Standardisation.” by “ATN based on the OSI reference model”.
Secretary: This seems not ok; the reference model is also applied in IPS based networking. Maybe the legacy OSI and ITU-T standards can be reference differently or “relevant ITU-T satandards” could be added.
2 / 3.1 / The initial Note under 3.1 Definitions is vitally important, as it is the key reference to Doc 9705 and the draft IPS Manual. However, it does not relate to “definitions”, and should be moved either directly under the Chapter 3 heading, or as a new Note 2 in paragraph 3.3.
Secretary: OK, check with editorial practice.
3 / 3.4.20 / The new paragraph 3.4.20 “The ATN shall support the context management (CM) application …” should be moved to the section on CM, section 3.5.1.1.
Secretary: OK
4 / 3.5.1.1.1 / The new paragraph 3.5.1.1.1 “The ATN shall be capable of supporting the following DL applications…” does not belong under the CM heading, and should move to 3.5. The paragraph is incomplete as it refers to a non-existent list of DL applications.
Secretary: This seems ok.
5 / 3.5.1.1.1 / Under the 3.5.1.1 heading “Context Management (CM) Application,” CM should be described to the same level as ADS-C, CPDLC, etc. For example “The ATN shall be capable of supporting CM applications to provide the Data Link Initiation Capability described in Doc 9694.”
Secretary: See 4 above. OK
6 / 3.4.1
3.4.1bis / There is a conflict between paragraphs 3.4.1 and 3.4.1bis:
3.4.1 The ATN shall use ISO communication standards for OSI
3.4.1bis The ATN shall use ISOC communication standards for IPS
These 2 statements imply that all implementations must comply with both ISO/OSI and ISOC/IPS standards. The confusion appears to stem from the ambiguity of the word “for”, which could be interpreted as either: “The ATN shall use xxx for purpose A” or “The ATN shall use xxx standards which define mechanism B”.
It would be clearer to rephrase these statements and refer to relevant Technical Manuals.
Secretary: A potential confusion between the provisions 3.4.1 and 3.4.1 bis has been recognized. From a regulatory point of view, it would be ideal if the only Standard regulates the use of the IPS, including the requirement to comply with IPv6 and the provisions of paragraph 3.6.3. The (ongoing) alternative use of OSI and IPv4 subnetworks could be regulated through appropriate recommendations.
The following provisions are proposed:
3.4.1.The ATN shall use Internet Society (ISOC) communication standards developed for the Internet Protocol Suite (IPS) using IPv6 standards
3.4.1.1 Recommendation: Alternatively, ISO/OSI communication standards may be used
3.4.2.2 Recommendation: On a national level, ISOC communication standards for the IPS using IPv4 standards may be used.
An alternative option would be to amend the two Standards as follows and add a clarifying note (similar to the note to 3.6)
3.4.1 The ATN shall use International Organization for Standardization (ISO) communication standards developed for the open systems interconnection (OSI).
3.4.1.bisThe ATN shall use Internet Society (ISOC) communication standards developed for the Internet Protocol Suite (IPS)
Note .— There are two environments in which the ATN may operate internationally. The ATN may operate using the Internet Protocol Suite and the Internet Protocol version 6. The ATN may alternatively operate using the ISO/OSI standards. Use of the IPS IPv4 should be limited to within a State
7 / 3.4.11, 3.4.12, 3.4.13 3.4.19 / These Paragraphs should move to the section on Naming and Addressing (currently 3.7)
Secretary: OK
8 / 3.4.29 3.4.30 / These Paragraphs should move to the section on Security Requirements (currently 3.9)
Secretary: OK
9 / 3.6.4 / Paragraph 3.6.4 as currently worded mandates support for CLTP. This is not used by any currently defined application (except GACS), and should be Optional.
Secretary: replace the word and with or in case the reference to CLTP needs to remain
2.3Comments on SWGN1-10 WP0713
Note.- WP0713 provides proposals from the ICAO Secretariat for further changes to the ATN SARPs in Annex 10. These are considered in turn below.
1.1 Definition for the ATN and the ATN/OSI and ATN/IPS
The proposed new definition for ATN in Annex 10, Volume III, Part I, Chapter 1, based on the AFTN definition, is a good approach. However, the AFTN distinction between messages and digital data has been lost. This seems a useful distinction:
“Aeronautical telecommunication network (ATN). A global internetwork architecture that allows ground, air-ground and avionic data subnetworks to exchange messages and/or digital data primarily for the safety of air navigation and for the regular, efficient and economic operation of air traffic services.”
Secretary: the words “messages and/or” can be deleted.
1.2 Definition of AAC
The proposed new AAC definition is acceptable. The reference should be to Annex 10, Volume II, Chapter 4 (Aeronautical Fixed Service) paragraph 4.4.1.1.7 (not 4.4.1.6 as stated). But the scope of referenced sub-item (c) is limited to CAAs; it should be expanded to aeronautical operating agencies as per Annex 10, Volume III.
Secretary: the problem identified with sub-item c) lies within Annex 10, volume II. It could be solved by changing the word “between” into “with”, which will make this sub-item to read as follows:
cmessages exchanged with civil aviation authorities relating to aeronautical services
The proposed move to Chapter 1 (definitions) is accepted.
1.4 Definition of ADS-C
The proposed new definition of ADS-C is incomplete. It covers only the contract (ADS-C agreement) establishment phase, not the air-to-ground sending of ADS reports. The definition needs to be changed.
The definition for ADS-C has been recently amended to meet operational and technical requirements. No change to this definition is acceptable.
The move to Chapter 1 (definitions) is acceptable.
1.5 Definitions of AOC, ATIS, D-ATIS, ATS, CPDLC, FIS
The review of the definitions and their move to Chapter 1 (definitions) are accepted.
3 Paragraph 3.2
The proposed amendment, removing the reference to CNS/ATM, is acceptable.
4 Paragraph 3.3.1
The proposed amendment, removing the reference to application entities, is acceptable. It is understood that this is a high-level statement in Annex 10, Chapter 3. Doc 9705 further details the statement by explicitly distinguishes between communication services (ICS in Sub-Volume V, ULCS in Sub-Volume IV) and application entities (in Sub-Volumes II and III).
The proposed change to the bullet list is acceptable.
5 Paragraph 3.3.3
The proposed change appears to conflict with the proposed change in para 2 of WP0713, where the separate definitions of ATN/OSI and ATN/IPS are no longer considered necessary. This could be overcome by amending 3.3.3 along the following lines instead:
“Requirements for implementation of the ATN shall be made on the basis of a regional air navigation agreement. This agreement shall specify the area in which the ATN communications service provisions of Doc 9705 and/or Doc XXX are applicable.”
Secretary: Rather than referring to Doc. 9705 and Doc. XXXX, references to 3.4.1 and 3.4.1 bis should be included; the current text in paragraph 3.3.3 should be maintained.
6 Paragraph 3.4.3
The proposed amendment loses the intent of the provisions, i.e. for transition away from AFTN/CIDIN systems. This could be overcome by adding to the proposed amendment along the following lines:
“AFTN/AMHS and CIDIN/AMHS gateways shall ensure the interoperability of AFTN or CIDIN stations or networks with the ATN, as a migration step for legacy AFTN/CIDIN users and systems.”
Secretary: this proposal is mixing standards with implementations and is not recommended.
7 Paragraph 3.5.1.1
Agreed that the current 3.5.1.1 text is not in the appropriate place. Appropriate text for 3.5.1.1 is suggested in the comments on WP0509/WP0612 above.
8 3.5.1.2 ATN directory services (DIR)
Removal of the additional reference to Doc 9705 is acceptable. The bullets should be renumbered.
9 Section 3.5.2 Air-ground applications
It is recommended that the proposed changes should be coordinated with SGN2.
If the alternative form of words for 3.5.2.1 is adopted, it should be made consistent with 3.5.3, i.e. “The ATN shall be capable of supporting the following air-ground applications:”
With the view to remove unnecessary text, the following revision may also cover the comments above:
3.5.2 Air-ground applications
The ATN shall be capable of supporting the following air-ground applications:
3.5.2.1. The ATN shall be capable of supporting ADS-C as contained in Doc. 9694.
(further consideration required)
3.5.2.2. The ATN shall be capable of supporting CPDLC as contained in Doc. 9694. (further consideration required)
3.5.2.3.The ATN shall be capable of supporting ATIS as contained in Doc. 9694.
3.5.2.4 The ATN shall be capable of supporting data link-VOLMET for aircraft-initiated demand contracts. (further consideration required)
3.5.3 Ground-ground applications
The ATN shall be capable of supporting the following ground-ground applications:
3.5.3.1 The ATN shall be capable of supporting the AIDC applications as contained in Doc. 9694.
3.5.3.2.1 The ATN shall be capable of supporting the ATS message handling service application (ATSMHS). (MOD-ACP-WGW-01)
10 Section 3.5.3 Ground-ground applications
It is recommended that the proposed changes should be coordinated with SGN3.
11 3.6 ATN Communication service requirements
It is important to note that layers 1-2 (i.e. subnetwork provisions) are defined elsewhere, such as in the VDL SARPs in Annex 10, Volume III, Part I, Chapter 6). That was the intent of the deleted note “The requirements for layers 1 and 2 are outside the scope of ATN SARPs.” This is recognised as an open issue to be addressed by SGN1.
The proposed Note (former Note 2) under 3.6 states “There are two environments in which ATN applications may operate.” This implies that ATN applications can choose which environment to operate in. We propose to delete former Note 2 of 3.6 and integrate the definition of criteria to allow the selection of ATN/OSI (Doc 9705) and/or ATN/IPS (Doc XXX). This issue is to be addressed by SGN1.
The proposed text for 3.6.3 and 3.6.4 is over-specified in comparison with the rest of the Annex 10 ATN material. It also fails to take account of the specific profiles defined in Doc 9705 and Doc XXX. In 3.6.3.2, not all ATN IPS Routers have to support BGP. Similarly, in 3.6.4.2, not all ATN ISs have to support IDRP. In 3.6.4.1 a), no applications currently use CLTP.
It is suggested to delete all of the proposed paragraph 3.6 text and replace it with references to Doc 9705 and Doc XXX.
Secretary:
a. The absence of the data link layer and the physical layer in the SARPs does not require further clarification.
b. With regard to the comments on Note 2 to paragraph 3.6, the following revision may solve the difficulty identified
Note 2.— In areas where the provisions of paragraph 3.4.1 bis apply, ATN applications operate over the Internet Protocol Suite as a direct (i.e., native) application or through a convergence function . In areas where the provisions of 3.4.1 apply, ATN applications operate over the OSI ULCS which is based on the OSI upper layer communications model.
c.The provisions of 3.6.3 and 3.6.4 are essential, as they provide at the level of Annex 10 the minimum relevant IPS and OSI Standards to be applied. Deletion is not recommended
2.4Comments on SWGN1-10 WP08
Note.- WP0814 provides rationale for the proposed deletions from Annex 10 ATN provisions.
2.4.1Comment on revised 3.2
By deleting former text of 3.2, it now includes a single paragraph. It is proposed that this paragraph becomes a note. Furthermore, the term “exclusively” is ambiguous, it is proposed to replace the term by “is”.
Secretary: the term “exclusively” is inserted to avoid non-aviation use of the ATN; the provision should not be converted into a note
2.4.2Comment on deletion of 3.2.2. b)
WP0814 states: “The provisions of paragraph 3.2.2.b) are already covered by paragraphs 3.4.14, 3.4.15, 3.4.17 and 3.4.18.” This is only partly true; ‘multiple ground systems’ is not covered.
2.4.3Comment on deletion of 3.4.5 and 3.4.6
Clearly SGN1 should discuss whether these sections are part of Annex 10 or Doc 9705, Doc. XXX. SGN1 must discuss the content of 3.4.5 and 3.4.6 which are clearly not OSI specific.
2.4.4Comment on deletion of ATN systems management provisions
WP0814 states: “Systems management is not an international requirement for the ATN requiring international standards.” A comprehensive study by EUROCONTROL identified fault, performance, and configuration management are areas where cross-domain (international) system management functions would be necessary. It is proposed to maintain reference to such management areas in Chapter 3, even if there are subject to regional agreements.
Secretary: The removal of material on systems management from Annex 10 is intended to remove the prescriptive nature of systems management provisions as contained in Doc. 8795. Paragraph 3.4.33 could be re-inserted, e.g.as a Recommendation
2.4.5Comment on deletion of ATN Security provisions.
It is recommended that these deletions should be explicitly considered by SGN4.
In deleting 3.9.1 Note 1, WP0814 states: “However, if considered necessary, reference to Annex 17 and the security manual can be retained.” Reference to Annex 17 and the Security manual are considered necessary.
For the security recommendations in 3.9.1.1WP0814 states: “These provisions are not relevant to the technical standards for the ATN.” These high-level provisions are relevant and have to be stated somewhere. It is acceptable to delete them if the provisions exist in Annex 17 or the Security Manual.
Secretary: further review necessary in the light of the provisions of Annex 17
The Denial of Service text deleted from 3.9.2.3 should be retained.
2.4.6Comment on deletion of Figure 3-1.
Figure 3-1 should be retained and generalised to cover both OSI and IPS. The End System would become “ES or Host”, the Intermediate Systems would become “IS or Router”.
Secretary: Proposals for generalizing figure 3-1 are invited. Currently, the figure does not add anything particular to the SARPs
3.ACTION BY THE MEETING
3.1The ACP SGN1 is invited to endorse the comments provided and to forward them to the ICAO Secretariat.