Aeronautical Telecommunication Network (ATN)
ATN merupakan jaringan komunikasi data yang dirancang oleh ICAO yang mampu menyediakan layanan bersama untuk kebutuhan Air/Ground subnetworks dan Ground/Ground subnetworks yang berbeda-beda dengan tingkat keamanan yang memenuhi persyaratan Air Traffic Services Communications (ATSC)/ Aeronautical Industry Service Communication (AINSC) untuk menunjang otomatisasi ATM(Air Traffic Management)
ATN Internet
ATN terdiri dari sekelompok Routing Domain(RD) yang saling tehubung. Masing-masing RD ini terdiri dari Intermediate System dan End System dari ATSC/AINSC.
Terdapat 2 jenis RD
Memiliki kemampuan melalukan/routing Network Protocol Data Unit(NPDU) dari 1 RD ke RD yang lain.
Merupakan tujuan akhir/system yang tidak memiliki kemampuan untuk melalukan NPDU
ATN RD
ATN RD harus memenuhi standar ISO 9575 dan terdiri juga dari 1 atau beberapa ATN Router. Setiap ATN RD memiliki Routing Domain Identifier(RDI), RDI dikenal juga sebagai Network Entity Title(NET) dengan syntax yang sama dengan ATN Network Service Access Point(NSAP)
Fixed RD
Setiap negara harus mempunyai minimal 1 ATN RD untuk interkoneksi dengan ATN RD yang lain.
Mobile RD
Mobile ATN(pesawat terbang) harus mempunyai minimal 1 ATN RD yang merupakan END RD dan Airborne Router.
The Ground ATN Internet
Terdiri dari 1 atau lebih ATN Island RDC(Routing Domain Confederations)
ATN Island RDC
Terdiri dari sekumpulan ATN RD tidak diperbolehkan adanya ATN Mobile RD
The Global ATN Backbone
Terdiri dari minimal 1 ATN RD dari setiap ATN Island yang terhubung dengan anggota lain dari Global ATN Backbone . Anggota-anggota dari Global ATN Backbone membentuk ATN Island Backbone RDC
ATN End System
directly or indirectly, to provide end-to-end communication service for Air/Ground or Ground/Ground applications, or both.
communication over the ATN by providing either the connection mode transport service, or the connectionless mode transport service, or both.
Physical and Data Link Layer
ATN End Systems shall implement the appropriate Physical and Data Link Layer functions
for access to the ATN subnetwork(s) to which they are attached.
Network Layer
ATN End Systems shall implement:
a) The End System provisions of ISO/IEC 8473, as specified in 5.6, as the Subnetwork
Independent Convergence Function (SNICF).
b) a Subnetwork Access Protocol (SNAcP) suitable for each underlying subnetwork.
c) a Subnetwork Dependent Convergence Function (SNDCF) providing byte and code
independent service to the SNICF (i.e. ISO/IEC 8473) via the appropriate Subnetwork Access Protocol, as specified in 5.7.
Recommendation.— ATN End Systems should implement the End System provisions of
ISO/IEC 9542 to facilitate the exchange of routing information between the ES and any locally attachedIS(s).
Transport Layer
Depending on the requirements of the application and its supporting upper-layer protocols,
ATN End Systems shall implement either one or both of the following:
a) ISO/IEC 8073
b) ISO/IEC 8602
Applications
Note.— The requirements for Air/Ground and Ground/Ground applications are contained in
Sections 2 and 3 of the ATN SARPs respectively.
ATN Routers
ATN Router Classes
Class Name Routing Protocols Supported
1. Static Router ISO/IEC 9542 (optional)
2. Level 1 Router ISO/IEC 9542 (optional)
ISO/IEC 10589 Level 1only
3. Level 2 Router ISO/IEC 9542 (optional)
ISO/IEC 10589 Level 1and Level 2
4. G/G Router ISO/IEC 9542 (optional)
ISO/IEC 10589 (optional)
ISO/IEC 10747
5. Air/G Router ISO/IEC 9542
ISO/IEC 10589 (optional)
ISO/IEC 10747
Route Initiation Procedures
6. Airborne Router
with IDRP
ISO/IEC 9542
ISO/IEC 10747
Route Initiation Procedures
7. Airborne Router
without IDRP
ISO/IEC 9542
Route Initiation Procedures
All ATN Inter-Domain Routers (i.e. Router Classes 4 to 7 inclusive) shall support:
a) the ISO/IEC 8473 Connectionless Network Protocol (CLNP) ,
including the use of the CLNP options security parameter, and shall interpret and
obey the Routing Policy Requirements expressed therein, whilst routing the packet
in accordance with any restrictions placed on the traffic types that may be carried
over a given ATN Subnetwork, by forwarding CLNP NPDUs.
b) the ISO/IEC 10747 Inter-Domain Routing Protocol (IDRP) for
the exchange of inter-domain routing information
An Airborne (Router Classes 6 or 7) or Air/Ground Router (Router Class 5) shall support the
Mobile SNDCF for the use of CLNP over an ATN Mobile Subnetwork, and the ISO/IEC
9542 ES-IS routing information exchange protocol, for support of the route initiation
procedures
Physical and Data Link Layers
ATN Routers shall implement the appropriate Physical and Data Link Layer functions for
access to the ATN subnetwork(s) to which they are attached.
Network Layer
An ATN Router shall implement:
a) the Intermediate System provisions of ISO/IEC 8473, as the Subnetwork Independent Convergence Function (SNICF).
b) a Subnetwork Access Protocol (SNAcP) suitable for each underlying subnetwork.
c) a Subnetwork Dependent Convergence Function (SNDCF) providing byte and code
independent service to the SNICF (i.e. ISO/IEC 8473) via the selected Subnetwork
Access Protocol.
d) The routing protocols specified in Table 5.2-1 for the Router*s Router Class
e) The Route Initiation procedures appropriate to the Router Class.
f) Where an ATN Router is directly connected to one or more Mobile Subnetworks, it
shall implement a sub-set of the ISO/IEC 9542 for operation over those subnetworks
to facilitate the exchange of addressing information (BIS Network Entity Title)
between the Router and its peer.
ATN Routers of class 5 (Air/Ground Routers) and of class 7 (Airborne Routers without IDRP)
shall also implement the mechanisms necessary to support the “optional non-use of ISO/IEC 10747”
ATN Subnetworks
An ATN Subnetwork is any fixed or Mobile data communications network that fulfils the
following requirements.
Requirements for All ATN Subnetworks
Both fixed and Mobile ATN subnetworks shall conform to the following requirements.
Byte and Code Independence
Data shall be transferred through ATN Subnetworks in a byte and code independent manner.
Note.— If necessary, this byte and code independence may be ensured through the services of the
SNDCF.
Subnetwork QoS
A Subnetwork service provider shall provide an indication of the Subnetwork Quality of
Service (QoS) available, in order to support the internetwork routing decision process.
Subnetwork Addressing
An ATN subnetwork shall provide a mechanism for uniquely and unambiguously identifying each ATN router attached to that subnetwork.
Internal Subnetwork Routing
Routing between specified source and destination Subnetwork Point of Attachment (SNPA)
addresses on an ATN subnetwork shall be carried out by mechanisms internal to the subnetwork.
Minimum SNSDU Size
An ATN subnetwork shall support a minimum Subnetwork Service Data Unit (SNSDU) size
of 1100 octets.
Note 1.— The 1100 octet number is derived from a 1024 octets user data, 9 octets fixed
ISO/IEC 8473 header, 42 octets Source and Destination NSAP Addresses, 4 octets for the SNDCF local
reference option, 3 octets for the QoS Maintenance parameter, 3 octets for the priority parameter, and 15
octets for the security parameter.
Note 2.— This will permit the use of the non-segmenting ISO/IEC 8473 subset for NSDUs of up to
1024 octets.
ATN Security Concept
ATN Security Functions are concerned with:
a) Protecting ATN Data Link applications from internal and external threats;
b) Ensuring that application Quality of Service and Routing Policy Requirements are
maintained, including service availability; and,
c) Ensuring that Air/Ground subnetworks are used in accordance with ITU resolutions
on frequency utilisation.
Other than through the provision of physical security mechanisms, no security mechanisms
are provided in the ATN Internet for protecting ATN Data Link applications. ATN Data Link applicationsnneed to develop their own security mechanisms for countering any threats to their proper operation. This may change in future versions of the specification.
There are currently no mechanisms for protecting the Routing Information Base from an
attacker. However, the use of ISO/IEC 10747 type 2 authentication is under consideration for specification in future versions of this specification.
The ATN Internet does provide mechanisms to support items (b) and (c) above. These
mechanisms are defined to take place in a common domain of trust, and use a Security Label in the header of each CLNP PDU to convey information identifying the “traffic type” of the data and the application*s routing policy and/or strong QoS Requirements. No mechanisms are provided to protect the integrity of this label or its binding to the application data.
In order to permit the later extension of the ATN to handle classified data, the Security
Label in the CLNP PDU header can additionally be used to convey Security Classification information.
The Routing Information necessary to support this Security Label is maintained through
information conveyed in the ISO/IEC 10747 Security Path Attribute about each route. ATN Routers of classes 4 and above reference this routing information during the NPDU forwarding process in order to meet the application*s requirements expressed through the NPDU*s Security Label and to enforce any applicable ITU resolutions on frequency utilisation.
The ATN Security Label
General
The ATN Security Label shall be encoded
An ATN Security Label shall be provided as part of the header of every CLNP NPDU, except
for those that convey General Communications applications data.
Traffic Types
A CLNP Data NPDU*s Security Label shall identify the “Traffic Type” of its user data, as either:
a) ATN Operational Communications
b) ATN Administrative Communications
c) ATN Systems Management Communications.
For the ATN Operational Communications traffic type and the ATSC traffic category, routing
policy requirements shall be expressed through further information encoded into the Security Label, as either:
a) A preferred ATSC Class, or
b) no routing policy preference.
For the ATN Operational Communications traffic type and the AOC traffic category, routing
policy requirements shall be expressed through further information encoded into the Security Label, as eitherno routing policy preference, or an ordered list of appropriate Air/Ground subnetworks to be used.
Applications Use of ATN Security Labels
ATN Data Link applications shall specify an ATN Security Label for each message category
that they support. This ATN Security Label shall identify:
a) the Traffic Type appropriate for the message; and,
b) for ATN Operational Communications applications, the application*s requirements
for the routing of the message
When sent using the connection-mode transport service, a message shall only be conveyed over a transport connection which is associated with the same ATN Security Label as that specified for the message*s message category.
When sent using the connectionless-mode transport service, the TSDU conveying that message shall be associated with the ATN Security Label of the specified message category.
Transport Layer Security
In the Connection Mode
Except when a transport connection is used to convey general communications data, each
transport connection shall be associated with a single ATN Security Label.
The value of this label shall be determined when the connection is initiated.
Every NSDU passed to the Network Layer that contains a TPDU from a transport connection
associated with an ATN Security Label shall be associated with the same ATN Security Label.
TPDUs from transport connections associated with different ATN Security Labels shall not
be concatenated into the same NSDU.
When an incoming CR TPDU is received, the ATN Security Label, if any, encoded into the
header of the NPDU that conveyed it, shall define the ATN Security Label that is associated with the transport connection.
In the Connectionless Mode
In the connectionless mode, unless used to convey General Communications data, each
incoming or outgoing TSDU shall be associated with an ATN Security Label.
For outgoing TSDUs, this ATN Security Label shall be encoded into the header of the
resulting NPDU(s).
For incoming TSDUs, the associated ATN Security Label shall be the ATN Security Label
that was encoded into the header of the incoming NPDU(s) that contained the TSDU.
Network Layer Security
Service Provider to the Transport Layer
The Network Service shall provide a mechanism that permits an ATN Security Label to be
associated with an NSDU:
a) When passed from the Transport Layer to the Network Layer in an NSUNITDATA.
request. This ATN Security Label shall be encoded into the header of the corresponding CLNP NPDU(s)
b) When passed from the Network Layer to the Transport Layer in an
NS-UNITDATA.indication. This ATN Security Label shall be that received in the
header of the associated CLNP NPDU(s).
Routing Control
When present in an NPDU header, the network layer routing functions shall ensure that:
a) The Routing Policy requirements, if any, encoded into the ATN Security Label are
obeyed, and
b) The NPDU is only routed over paths through the internetwork which both permit and
are suitable for data of the traffic type identified by the ATN Security Label.
Note 1.— 5.3.2.2 specifies the forwarding procedures that ensure the above.
Note 2.— The Security Information conveyed in ISO/IEC 10747 (IDRP) routes is used to provide
the forwarding process with the information needed to support the above.
Protection of the Routing Information Base
IDRP type 1 Authentication, as specified in ISO/IEC 10747, shall be used as a mechanism
for ensuring the integrity of routing information exchange by IDRP.
Note.— A later extension to support type 2 authentication will enable the routing information base
to be protected from attackers that try to modify routing information while in transit, or which attempt tomasquerade as genuine ATN Routers.
Subnetwork Provisions
Note.— There are no requirements for security mechanisms in ATN Subnetworks. However,
Administrations and other Organisations implementing ATN subnetworks are encouraged to ensure the
general security and availability of ATN subnetworks through the use of physical security mechanisms.
ATN Use of Priority
Note 1.— The purpose of priority is to signal the relative importance and/or precedence of data,
such that when a decision has to be made as to which data to action first, or when contention for access to
shared resources has to be resolved, the decision or outcome can be determined unambiguously and in line
with user requirements both within and between applications.
Note 2.— In the ATN, priority is signalled separately by the application in the transport layer and
network layer, and in ATN subnetworks. In each case, the semantics and use of priority may differ.
Figure 5.2-2 illustrates where priority is applied in the ATN, and where it is necessary to map the semantics and syntax of ATN priorities.
Note 3.— In the ATN Internet, priority has the essential role of ensuring 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.
Application Priority
Note.— Priority in ATN Application Protocols is used to distinguish the relative importance and urgency of application messages within the context of that application alone.
For the purpose of
a) distinguishing the relative importance and urgency of messages exchanged by
different ATN Applications, and
b) distinguishing the relative importance and urgency of messages of the same
application during their transit through the ATN,
application messages shall be grouped into one or more categories listed in Table 1.2-2 .
Note.— An ATN Application may include messages from more than one category.
When a message is sent between ATN Application Entities, the message shall be sent using
either:
a) a transport connection established using the Transport Connection Priority listed in
Table 1.2-2 for the message*s message category, or
b) the connectionless transport service, signalling the Connectionless Transport Service
Priority listed in Table 1.2-2 for the message*s message category.
Note.— The priority of an individual transport connection cannot be changed during the lifetime of
the connection. Therefore, if an application exchanges messages belonging to more than one message
category using the connection mode transport service, then a separate transport connection needs to be
established for each message category.
Transport Connection Priority
Note 1.— Transport connection priority is concerned with the relationship between transport
connections and determines the relative importance of a transport connection with respect to (a) the order in which TCs are to have their QoS degraded, if necessary, and (b) the order in which TCs are to be broken in order to recover resources.
Note 2.— The transport connection priority is specified by the transport user either explicitly or implicitly, when the transport connection is established.
When an ATN Transport Layer entity is unable to satisfy a request for a transport connection
from either a local or remote TSAP, and which is due to insufficient local resources available to the transport layer entity, then it shall terminate a lower priority transport connection, if any, in order to permit the establishment of a new higher priority transport connection.
Note.— Implementations may also use transport connection priority to arbitrate access to other resources (e.g. buffers). For example, this may be achieved by flow control applied to local users, by discarding received but unacknowledged TPDUs, by reducing credit windows, etc.
All TPDUs sent by an ATN Transport Layer Entity shall be transferred by the ATN Internet
Layer, using the Network Protocol Priority that corresponds to the transport connection*s priority
Connectionless Transport Service Priority
Note.— There are no procedures required of the ATN Connectionless Transport Entity in respect
of priority, except for mapping the TSDU priority supplied by the service user (i.e. an ATN Application), to the corresponding Network Layer Priority, and vice versa.
All UD TPDUs sent by an ATN Transport Layer Entity shall be transferred by the ATN
Internet Layer using the Network Protocol Priority that corresponds to the TSDU priority provided by the service user according to Table 1.2-2.
ATN Internet Priority
Note.— In the ATN Internet Layer, an NPDU of a higher priority is given preferred access to
resources. During periods of higher network utilisation, higher priority NPDUs may therefore be expected to be more likely to reach their destination (i.e. are less likely to be discarded by a congested router) and to have a lower transit delay (i.e. be more likely to be selected for transmission from an outgoing queue) than are lower priority packets.
ATN Internet Entities shall maintain their queues of outgoing NPDUs in strict priority order,
such that a higher priority NPDU in an outgoing queue will always be selected for transmission in preference to a lower priority NPDU.
Note.— Priority zero is the lowest priority.
During periods of congestion, or when any other need arises to discard NPDUs currently held by an ATN Internet Entity, lower priority NPDUs shall always be discarded before higher priority NPDUs.
Note.— In addition to NPDUs containing user (i.e. transport layer) data, the Internet Layer also
forwards routing information contained in CLNP Data PDUs (e.g. IDRP) and as distinct NPDUs (e.g. ESIS).
These must all be handled at the highest priority if changes to network topology are to be quickly
actioned and the optimal service provided to users.
BISPDUs exchanged by IDRP shall be considered as Network/Systems Management category
messages, and shall be sent using CLNP priority 14.
ES-IS (ISO/IEC 9542) PDUs shall be implicitly assumed to have priority 14 and shall be
forwarded as if they were CLNP PDUs of priority 14.
Note.— The priority encoded in an ISH PDU conveys the priority of the sending system, and not the
priority of the PDU.
ATN Subnetwork Priority
Connection-Mode Subnetworks
Note 1.— In a connection-mode ATN subnetwork, priority is used to distinguish the relative
importance of different data streams (i.e. the data on a subnetwork connection), with respect to gaining access to communications resources and to maintaining the requested Quality of Service.
Note 2.— On some subnetworks (e.g. public data networks), not all data streams will be carrying ATN messages. Therefore, subnetwork priority is also used to distinguish ATN and non-ATN data streams.
Note 3.— So as not to incur the overhead and cost of maintaining too many simultaneous
subnetwork connections, NPDUs of a range of Network Layer priorities may be sent over the same
subnetwork connection.
When an ATN connection mode subnetwork does not support prioritisation of subnetwork
connections, then the ATN Internet Entity shall not attempt to specify a subnetwork connection priority, and NPDUs of any priority may be sent over the same subnetwork connection.
When an ATN connection mode subnetwork does support prioritisation of subnetwork
connections, then unless the relationship between ATN Internet Priority and subnetwork priority is explicitly specified by the subnetwork specification, the following shall apply:
a) Subnetwork connections shall be established as either “High” or “Low” priority
connections.
b) For the “Low” priority connection type, the priority to gain a connection, keep a
connection and for data on the connection shall be the defaults for routine use of the
subnetwork.
c) “High” priority connections shall be used to convey NPDUs of priority ten and above.
“Low” priority connections shall be used to convey all other NPDUs.
Note.— The above does not apply to the AMSS Subnetwork, which has specified its own priority mapping scheme.
When a subnetwork connection is established between two ATN Internet Entities and no other subnetwork connection between these two entities exists over any subnetwork, then that subnetwork connection shall always be established at a priority suitable for conveying NPDUs of priority 14 (i.e. Network/Systems Management).
Note.— This is to ensure that routing information can be exchanged at the appropriate priority.
Connectionless-Mode Subnetworks
When an NPDU is sent over a connectionless-mode ATN Subnetwork which supports data
prioritisation, then the subnetwork priority assigned to the transmitted packet shall be that specified by the subnetwork provider as corresponding to the NPDU priority.
ATN Routing
This chapter provides requirements and recommendations pertaining to the deployment of
ATN components within the ATN Internet; use of routing information distributed according to ISO/IEC
10747 in order to support policy based and Mobile routing in the ATN; and the Route Initiation procedures
for initiating the exchange of routing information using the ISO/IEC 10747 protocol. In the case of
Air/Ground data links, route initiation also includes the use of the ISO/IEC 9542 protocol. This chapter is
not concerned with compliancy with the ISO/IEC 10747 and ISO/IEC 9542 protocols.
A route shall only be advertised by an ATN Router to an adjacent ATN RD when it can be
ensured that data sent over that route by the RD to which the route is advertised is acceptable to every RD and RDC in the route's path, and will be relayed by them to the route's destination.
Note.— The acceptability of a route may be determined using a priori knowledge derived from
interconnection agreements with other RDs.
Forwarding CLNP NPDUs
General
The forwarding processes for a CLNP NDPU shall operate by selecting the FIB identified by
the combination of the QoS Maintenance and Security Parameters found in the CLNP Header, and selecting from that FIB, the entry, if any, identified by the longest matching NSAP Address Prefix.
The next hop information found in this FIB entry shall then be used to forward the NPDU.
Note.— Forwarding decisions that take into account the CLNP QoS Maintenance Parameter are a local matter and an ATN Router may hence ignore this parameter.
Forwarding a CLNP NPDU when no Security Parameter is present in the PDU Header
Note.— This case applies for General Communications data (see 5.2.7.1).
When a CLNP NPDU is received by an ATN Router and that NPDU does not contain a
Security Parameter in the PDU Header then that NPDU shall be forwarded over the selected route to the NPDU’s destination with the longest matching NSAP Address Prefix and which, either:
1) contains a security path attribute comprising the ATN Security Registration
Identifier and security information that does not contain an ATSC Class
Security Tag indicating support for only ATSC traffic, and comprises:
a) either an Air/Ground Subnetwork Security Tag that has “General
Communications” in its set of permissible Traffic Types, or
b) no Air/Ground Subnetwork Security Tag,
or
2) does not contain any security path attribute.
If no such route can be found then the NPDU shall be discarded.
Forwarding a CLNP NPDU when a Security Parameter is present in the PDU Header
General
When a CLNP NPDU is received by an ATN Router and that NPDU contains a Security
Parameter in the Globally Unique Format, and encodes security related information under
the ATN Security Registration Identifier, then the NPDU shall be forwarded according to the procedures specified below.
Note 1.— The CLNP NPDU Header Security Parameter is used to indicate the Traffic Type of the application data contained in the NPDU, and the application*s routing policy requirements.
Note 2.— The procedures for handling an NPDU with any other format of Security Parameter, or with any other Security Registration Identifier are outside the scope of this specification.
ATN Operational Communications Traffic Type - ATSC Traffic Category
Note.— In this case, either no Traffic Type policy preference may be specified, or an ATSC Class may be specified.
No Traffic Type Policy Preference
Note.— This case corresponds to a Traffic Type and Associated Routing Policy Security Tag value of 000 00001.
If the NPDU contains a CLNP NPDU Header Security Parameter in the globally unique
format, and encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and a traffic category of Air
Traffic Service Communications, and
c) no Traffic Type Policy Preference,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. An Air/Ground Subnetwork Security Tag that has “ATN Operational Communications - Air
Traffic Services Communications” in its set of permissible Traffic Types, or
ii. no Air/Ground Subnetwork Security Tag,
and an ATSC Class Security Tag indicating support of the lowest class out of all such routes available.
Note 1.— This requirement always takes precedence over selection based on ATSC
Class i.e. a route with a longer matching NSAP Address Prefix with a higher ATSC Class is always preferred over a route with a lower ATSC Class but with a shorter NSAP Address Prefix. This is essential for the
avoidance of routing loops.
Note 2.— ATSC Class “H” is the lowest and Class “A” is the highest.
If no such route can be found, then the NPDU shall be discarded.
ATSC Class Specified
Note.— This case corresponds to Traffic Type and Associated Routing Policy Security Tag values 000 10000 to 000 10111 inclusive.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and Air Traffic Service
Communications traffic category, and
c) a requirement to route the NPDU over a route of a specified ATSC Class,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. An Air/Ground Subnetwork Security Tag that has “ATN Operational Communications - Air Traffic Services Communications” in its set of permissible Traffic Types, or
ii. no Air/Ground Subnetwork Security Tag
and an ATSC Class Security Tag indicating:
I. support of the required class, or a higher class, or
II. if no such route is available then, the route with the highest ATSC Class available is
chosen.
Note 1.— This requirement always takes precedence over selection based on ATSC
Class i.e. a route with a longer matching NSAP Address Prefix with a higher ATSC Class is always preferred Internet communications service V-31
ICAO ATNP Version 2.3 - Editors’ Draft
over a route with a lower ATSC Class but with a shorter NSAP Address Prefix. This is essential for the avoidance of routing loops.
Note 2.— ATSC Class “H” is the lowest and Class “A” is the highest.
If no such route can be found then the NPDU shall be discarded.
If multiple routes are available which meet or exceed the required ATSC Class, then the route with the lowest relative cost shall be selected.
ATN Operational Communications Traffic Type - AOC Traffic Category
Note.— In this case, either no routing policy may be specified, or an Air/Ground Subnetwork type
may be specified, or an Air/Ground subnetwork order of preference may be specified.
No Traffic Type Policy Preference
Note.— This case corresponds to a Traffic Type and Associated Routing Policy Security Tag value of 001 00001.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and Aeronautical Operational
Control traffic category, and
c) no Traffic Type Policy Preference,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. an Air/Ground Subnetwork Security Tag that has “ATN Operational
Communications - Aeronautical Operational Control” in its set of permissible Traffic
Types, or
ii. no Air/Ground Subnetwork Security Tag;
and which does not contain an ATSC Class Security Tag indicating support for only ATSC traffic.
If no such route can be found, then the NPDU shall be discarded.
Air/Ground Subnetwork Type Specified
Note 1.— This case corresponds to Traffic Type and Associated Routing Policy Security Tag values 001 00010 through to 001 00110 inclusive.
Note 2.— The Air/Ground Subnetworks that may be specified are: Gatelink, VDL, AMSS, HF and Mode S.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and Aeronautical Operational
Control traffic category, and
c) a requirement to route traffic only via a specific Air/Ground Subnetwork only,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises either
i. an Air/Ground Subnetwork Security Tag that indicates that the route passes over that
Air/Ground Subnetwork and has “ATN Operational Communications —
Aeronautical Operational Control” in its set of permissible Traffic Types, or,
ii. no Air/Ground Subnetwork Security Tag,
and which does not contain an ATSC Class Security Tag indicating support for only ATSC traffic.
If no such route can be found, then the NPDU shall be discarded.
Air/Ground Subnetwork Order of Preference Specified
Note 1.— This case corresponds to Traffic Type and Associated Routing Policy Security Tag values 001 00111 through to 001 01001 inclusive.
Note 2.— The Air/Ground Subnetworks for which an order of preference may be specified are:
Gatelink, VDL, AMSS, HF and Mode S.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and Aeronautical Operational
Control traffic category, and
c) a requirement to route traffic only via certain Air/Ground Subnetworks and with a
specified order of preference,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. an Air/Ground Subnetwork Security Tag that indicates that the route passes over the
first preference Air/Ground Subnetwork and has “ATN Operational Communications
- Aeronautical Operational Control” in its set of permissible Traffic Types, if present,
or
ii. an Air/Ground Subnetwork Security Tag that indicates that the route passes over the
second preference Air/Ground Subnetwork and has “ATN Operational
Communications - Aeronautical Operational Control” in its set of permissible Traffic
Types, if present, and so on until a suitable route is found or no further preferences
are specified, or
iii. no Air/Ground Subnetwork Security Tag,
and which does not contain an ATSC Class Security Tag indicating support for only ATSC traffic.
If no such route can be found, then the NPDU shall be discarded.
If after applying the above procedures, a more specific route is available to the NPDU*s
destination, but
1) the route has an Air/Ground Subnetwork Security Tag that indicates that the
route passes over a lower preference Air/Ground Subnetwork while
2) having “ATN Operational Communications - Aeronautical Operational
Control” in its set of permissible Traffic Types, then
3) the more specific route shall be selected in preference to the less specific
route.
Note.— The purpose of this requirement is to ensure that the NPDU is not forced to visit a default
route provider only to find that a higher preference route does not actually exist to the NPDU*s destination.
ATN Administrative Communications Traffic Type
Note.— This case corresponds to a Traffic Type and Associated Routing Policy Security Tag value of 001 10000.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Administrative Communications,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. either an Air/Ground Subnetwork Security Tag that has “ATN Administrative
Communications” in its set of permissible Traffic Types, or
ii. no Air/Ground Subnetwork Security Tag
and which does not contain an ATSC Class Security Tag indicating support for only ATSC traffic.
If no such route can be found, then the NPDU shall be discarded.
ATN Systems Management Communications Traffic Type
Note.— This case corresponds to a Traffic Type and Associated Routing Policy Security Tag value of 011 00000.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Systems Management Communications,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which:
1) contains a security path attribute comprising the ATN Security Registration
Identifier and security information that comprises:
a) either an Air/Ground Subnetwork Security Tag that has “ATN Systems
Management Communications” in its set of permissible Traffic Types, or
b) no Air/Ground Subnetwork Security Tag,
or
2) contains no security path attribute.
5.3.2.2.3.5.2 If no such route can be found, then the NPDU shall be discarded.
Ground/Ground Interconnection
Interconnection Scenarios
Note 1.— Ground/Ground interconnection procedures apply to the interconnection of two
Ground/Ground Routers, and to the interconnection of an Air/Ground Router and a Ground/Ground Router.
Note 2.— Formally, these procedures only apply to interconnection between ATN Routers in different
Administrative Domains. However, in practice, they are also applicable to interconnection scenarios within
the same Administrative Domain.
Ground/Ground Route Initiation
Note.— Route Initiation is defined to be the point at which routing information exchange can begin,
and the route initiation procedures are those that permit the exchange of routing information to commence.
When the network administrators agree to the ground/ground interconnection of one or more ATN Routers within their respective Administrative Domains, they shall:
a) Make available suitable subnetwork connectivity including, where necessary the
physical installation of suitable communications equipment for end-to-end
communications between the ATN Routers, and supporting the Quality of Service
necessary for the applications data that will be routed over this interconnection.
Note.— The choice of appropriate subnetwork(s) to support the interconnection is a matter for
bilateral agreement between network administrators, including agreement on responsibility for installation,
operating and maintenance costs, and fault management.
b) Using global or local Systems Management mechanisms, establish one or more
subnetwork connections between the two ATN Routers, unless the subnetwork
technology is connectionless in which case this step may be omitted.
Note 1.— Typically (e.g. with X.25), one ATN Router will be placed in a state where it will accept
an incoming connection from the other ATN Router, and then the other ATN Router is stimulated to initiate
one or more subnetwork connection(s) to the other ATN Router.
Note 2.— Multiple concurrent subnetwork connections over the same or different subnetworks may
be required in order to meet throughput and other QoS requirements.
c) Using global or local Systems Management mechanisms, ensure that the forwarding
information base in each ATN Router, used to support the connectionless network
protocol specified in 5.6, contains sufficient information to forward CLNP NPDUs
addressed to the NET of the other ATN Router, over the newly established
subnetwork connection(s).
Note.— This step is necessary to ensure that the connectionless network service can be used to
exchange the BISPDUs of IDRP.
d) Using global or local Systems Management mechanisms, append the NET of the
remote ATN Router to the externalBISNeighbor attribute of the BIS*s idrpConfig
MO,
e) Using global or local Systems Management mechanisms, create an AdjacentBIS
Managed Object (MO) in each ATN Router to represent the other ATN Router, and
f) Using global or local Systems Management mechanisms, invoke the start event action
on each such MO, in order to initiate a BIS-BIS connection between the two ATN
Routers.
Note.— As a matter for the bilateral agreement of the network administrators, either (a) both ATN Routers will attempt to open the BIS-BIS connection, or (b) one and only one acts as the BIS-BIS connectioninitiator.
Ground/Ground Routing Information Exchange
Routing information shall be exchanged using the ISO/IEC 10747 Inter-Domain Routing
Protocol according to the profile specified in 5.8.
In support of Air/Ground communications, the exchange of routing information shall be subject to appropriate routing policies specified in 5.3.7.1, 5.3.7.3, or 5.3.7.4, depending upon the role of the Routing Domain in which each ATN Router is located.
Ground/Ground Route Termination
Note 1.— Route Termination is defined to be the point at which routing information ceases to be exchanged between two ATN Routers, and, in consequence, the routes made available over the adjacency cease to be useable and must be withdrawn. The route termination procedures are those procedures which
terminate the exchange of routing information.
Note 2.— Route Termination may result from a failure in the underlying subnetwork(s) causing a loss of communication between the two ATN Routers. Alternatively, it may result from a deliberate decision of network administrators to terminate the interconnection, either temporarily or permanently.
Note 3.— No special recovery procedures are specified if route termination is due to a network fault.
Once the fault has been repaired, the procedures of 5.3.4.2 may be re-invoked, as appropriate to re-establish
communication, and to exchange routing information.
When a network administrator decides to temporarily or permanently terminate an interconnection between two ATN Routers then, using global or local Systems Management mechanisms applied to either or both of the two ATN Routers, the deactivate action shall be invoked on the AdjacentBIS
MO that represents the remote ATN Router with which the BIS-BIS connection is to be terminated.
If the adjacency is to be permanently terminated, then the AdjacentBIS MO shall also be
deleted, and the forwarding information base shall be updated to remove the route to the NET of the remote ATN Router.
For either temporary or permanent termination, and if required, by using global or local
Systems Management mechanisms, the network administrator(s) shall also terminate the underlying subnetwork connections.
5.3.6 Handling Routing Information
5.3.6.1 All ATN Routers in the same RD shall implement the same routing policy.
Note 1.— As specified in 5.8, an ATN Router supports both the empty (default) RIB_Att, and the RIB_Att comprising the Security Path Attribute identifying the ATN Security Registration Identifier. An ATN Router therefore includes two RIBs known as the default RIB and the Security RIB, each of which comprises a Loc-RIB, and an Adj-RIB-In and an Adj-RIB-Out for each adjacent BIS.
Note 2.— Each ATN RD will necessarily have a distinct routing policy that depends on its nature, and the nature of the RDs to which it is interconnected. Section 5.3.7 specifies the baseline Routing Policy for each class of RD identified in 5.2.2.2 to 5.2.2.5 inclusive. ATN RDs may then extend the specified baseline to match their actual requirements.
Note 3.— Each Routing Policy is expressed as a set of policy statements or rules.
Note 4.— These baseline policy statements given below are always subject to the ISO/IEC 10747 requirement that routes are only advertised when the DIST_LIST_INCL and DIST_LIST_EXCL path attributes, if present, permit the route to be so advertised. Routes may never be advertised to an RD or RDC which the route has already traversed.
Policy Based Selection of Routes for Advertisement to Adjacent RDs
Note.— In general, the selection of routes for advertisement to adjacent Routing Domains is
performed according to local routing policy rules. This specification mandates such routing policy rules for support of Air/Ground routing only. Routing Policy rules for support of Ground/Ground routing are a local matter.
5.3.7.1 Routing Policy Requirements for Members of an ATN Island Backbone RDC
5.3.7.1.1 General
5.3.7.1.1.1 An ATN RD that is a member of an ATN Island Backbone RDC shall implement a Routing Policy that is compatible with the policy statements given in this section and its subordinate sections.
5.3.7.1.2 Adjacent ATN RDs within the Backbone RDC
Note.— These policy statements apply to the routes advertised by an ATN Router in an RD that is a member of an ATN Island Backbone RDC, to an adjacent ATN Router in a different RD, which is also a member of the same ATN Island Backbone RDC.
5.3.7.1.2.1 Each ATN Router that is in an RD that is a member of an ATN Island Backbone RDC shall provide the following routes to each adjacent ATN RD within the same ATN Island Backbone RDC, and for the Security RIB-Att:
a) A route to NSAPs and NETs contained within the RD; the route's destination shall
be one or more NSAP Address prefixes common to all NSAP Addresses and NETs
in the RD. If restrictions on distribution scope are applied by local routing policy,
then they shall not prevent distribution of this route to any member of the same ATN
Island Backbone RDC.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may also be present. For
example, to restrict the scope of the information to members of the ATN Island Backbone RDC only. The RDIs of other RDs and RDCs may also be present at the discretion of the local Administrative Domain, and by bilateral agreement.
Note 2.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all its neighbours within the backbone RDC about itself.
b) The selected route to every Mobile RD for which a route is available.
Note.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will inform all other Backbone RDC members within the island about all mobiles that it has available.
c) The selected route to every Fixed ATN RD in the same ATN Island, for which a
route is available.
Note.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will
tell other members of the same Backbone RDC about all fixed RDs that it knows about.
d) Each selected route to a Mobile RD's “home”.
Note 1.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all other members of the same Backbone RDC about all the “homes” that it knows about.
Note 2.— Such a route can be characterised by an NSAP Address Prefix which ends at the ADM field.
e) A route to each “Home” that the ATN TRD itself provides for Mobile RDs. This
route has as its destination, the common NSAP Address Prefix(es) for those mobile
RDs. The Security Path attribute shall contain an ATSC Class Security Tag
indicating support for both ATSC and non-ATSC traffic, and for all ATSC classes
supported for Air/Ground data interchange, if any.
Note.— The objective of this item is to ensure that all RDs in the ATN Island Backbone RDC are aware that the identified “Homes” are located here.
All other ATN RDs within the ATN Island
Note.— These policy statements apply to the routes advertised by an ATN Router in an RD that is a member of an ATN Island Backbone RDC to an adjacent ATN Router in a different RD, which is also a member of the same ATN Island RDC, but which is not a member of that ATN Island Backbone RDC.
An ATN Router that is in an RD that is a member of an ATN Island Backbone RDC shall provide the following routes to each adjacent ATN RD within the ATN Island RDC, which is not a member of the ATN Island*s Backbone RDC, and for the Security RIB-Att :
a) A route to NSAPs and NETs contained within the RD; the route's destination shall
be one or more NSAP Address prefixes common to all NSAP Addresses and NETs
in the RD. If restrictions on distribution scope are applied by local routing policy,
then they shall not prevent distribution of this route to any member of the same ATN
Island RDC.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may also be present. For
example, to restrict the scope of the information to members of the ATN Island only. The RDIs of other RDs and RDCs may also be present at the discretion of the local Administrative Domain, and by bilateral agreement.
Note 2.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all RDs within the island about itself.
b) The selected route to every Fixed ATN RD in the same ATN Island for which a route
is available.
Note.— The objective of this rule is to ensure that an ATN Router located in an RD that is a member of an ATN Island Backbone RDC, will tell all RDs within the island about all the fixed RDs it knows about.
c) A route to all AINSC Mobiles and all ATSC Mobiles. The well known discretionary
attribute DIST_LIST_INCL shall be present, and shall contain the RDI of the ATN
Island RDC as its value. The Security Path attribute shall contain an ATSC Class
Security Tag indicating support for both ATSC and non-ATSC traffic, and for all
ATSC classes supported for Air/Ground data interchange, if any.
Note 1.— The objective of this rule is to tell the rest of the island that each RD in the ATN Island Backbone RDC provides a default route to all aircraft.
Note 2.— The distribution scope of the route is limited because the ATN Island defines the domain of the default route provider. This route is invalid outside of the local ATN Island.
Note 3.— This route is formally the result of aggregating all the routes to Mobile Systems and routes to “Home” RDs, known to the ATN Router.
d) A route to each Mobile RD for which the adjacent RD is advertising a route to the
Mobile RD's “home”.
Note.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all adjacent off Backbone RDs about all routes to Mobile RDs which have “home” routes advertised.
Mobile RDs
Note.— These policy statements apply to the routes advertised by an ATN Router in an RD that is a member of an ATN Island Backbone RDC to an adjacent ATN Router in a Mobile RD.
When IDRP is being used to exchange routing information with an Airborne Router, an ATN
Router in an RD that is a member of an ATN Island Backbone RDC shall provide to each adjacent Mobile RD a route to NSAPs and NETs contained within the local RD for the Security RIB-Att; the route's destination shall be one or more NSAP Address prefixes common to all NSAP Addresses and NETs in the local RD.
Note.— The objective of this rule is to ensure that an RD that is a member of an ATN Island
Backbone RDC will tell all adjacent Mobiles about itself.
An ATN RD that is a member of an ATN Island Backbone RDC should also provide to each adjacent Mobile RD, and for the Security RIB-Att and for which a suitable route exists:
a) An aggregated route to NSAPs and NETs contained within the local ATN Island
RDC;
Note.— The objective of this rule is to ensure that an RD that is a member of an ATN Island
Backbone RDC provides to each connected Mobile RD, a route to all fixed ATN RDs within the island.
b) An aggregated route to NSAPs and NETs contained within all other ATN Islands
for which a route is available.
Note.— The objective of this rule is to ensure that an RD that is a member of an ATN Island
Backbone RDC will provide to each connected Mobile RD routing information to the backbone of other ATN islands
.
ATN RDs in other ATN Islands
Note.— These policy statements apply to the routes advertised by an ATN Router in an RD that is a member of an ATN Island Backbone RDC to an adjacent ATN Router in a different RD, which is a member of a different ATN Island's ATN Island Backbone RDC.
An ATN Router in an RD that is a member of an ATN Island Backbone RDC shall provide
the following routes to each adjacent ATN Router that is a member of a Backbone RDC in another ATN Island, and or the Security RIB-Att:
a) An aggregated route to NSAPs and NETs contained within the ATN Island RDC.
Note.— The objective of this rule is to ensure that an RD that is a member of an ATN Island
Backbone RDC will tell all adjacent RDs that are members of ATN Island Backbone RDCs in different ATN Islands about the local ATN Island.
b) Each selected route to a Mobile RD’s “home”.
c) A route to each “Home” that the ATN TRD itself provides for Mobile RDs. This
route has as its destination, the common NSAP Address Prefix(es) for those Mobile
RDs. The Security Path attribute shall contain an ATSC Class Security Tag
indicating support for both ATSC and non-ATSC traffic, and for all ATSC classes
supported for Air/Ground data interchange, if any.
Note 1.— The objective of this rule is to ensure that an ATN Island Backbone RD will tell all
adjacent RDs that are member of an ATN Island Backbone RD in different ATN Islands about routes to Mobiles whose “home” is in the local island.
Note 2.— The “home” identified above needs not correspond to a geographical notion of a home.
Note 3.— The “home” is typically identified by an NSAP Address Prefix that identifies all the RD's belonging to the organisation responsible for the Mobile RD (i.e. aircraft), or all the Mobile RDs belonging
to the organisation. The former is only possible if all such Fixed RDs are part of the same ATN Island RDC.
d) A known route to each Mobile RD for which the adjacent RD is advertising a route
to the Mobile RD's “home”.
Note.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all adjacent RDs in different islands about all routes to Mobile RDs which have “home” routes
advertised.
Routing Policy Requirements for a Mobile RD
When IDRP is being used to exchange routing information with an Airborne Router, a Mobile RD shall provide to each ATN RD to which it is currently connected, a route to NSAPs and NETs contained within the Mobile RD for the Security RIB-Att.
The objective of this rule is to ensure that a Mobile RD will tell adjacent RDs about itself.
This policy statement applies to the routes advertised by an ATN Router in a Mobile RD
to an adjacent ATN Air/Ground Router in a Fixed ATN RD.
Routing Policy Requirements for an ATN TRD that is not a Member of the ATN Island
Backbone RDC
General
An RD that is a member of an ATN Island RDC, and is a TRD, but which is not a member
of that ATN Island's Backbone RDC shall implement a Routing Policy that is compatible with the policy statements given in this section and its subordinate sections.
Note.— An ATN RD that operates as a transit routing domain is referred to in this chapter as an ATN TRD.
Adjacent ATN RDs that are Members of the ATN Island*s Backbone RDC
Note.— These policy statements apply to the routes advertised by an ATN Router in an ATN TRDto an adjacent ATN Router in an RD which is a member of the local ATN Island's Backbone RDC.
When an ATN TRD that is not itself a member of an ATN Island Backbone RDC is adjacent
to an RD that is a member of an ATN Island Backbone RDC, then it shall provide the following routes to each such adjacent ATN RD, and for the Security RIB-Att:
a) A route to NSAPs and NETs contained within the RD; the route's destination shall
be one or more NSAP Address prefixes common to all NSAP Addresses and NETs
in the RD.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may also be present. For
example, to restrict the scope of the information to members of the ATN Island only. The RDIs of other RDs
and RDCs may also be present at the discretion of the local Administrative Domain, and by bilateral agreement.
Note 2.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of an ATN Island Backbone RDC, will tell all adjacent ATN RDs which are members of an ATN Island BackboneRDC within the same ATN Island about itself.
b) The selected route to every Mobile RD for which a route is available.
Note.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of an ATNIsland Backbone RDC, will tell all adjacent ATN RDs which are members of an ATN Island Backbone RDC within the same ATN Island about all Mobiles it knows about.
c) The selected route to every Fixed ATN RD in the ATN Island for which a route is
available.
Note.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of an ATN
Island Backbone RDC, will tell all adjacent ATN RDs which are members of an ATN Island Backbone RDC
within the same ATN Island about all fixed RDs it knows about in the same ATN Island.
d) A route to each “Home” that the ATN TRD itself provides for Mobile RDs. This
route shall have as its destination, the common NSAP Address Prefix(es) for those
Mobile RDs. The Security Path attribute shall contain an ATSC Class Security Tag
indicating support for both ATSC and non-ATSC traffic, and for all ATSC classes
supported for Air/Ground data interchange.
Note.— The objective of this rule is to support the operation of the Home Domain concept on any ATN TRD directly connected to an ATN Island Backbone RD.
Adjacent ATN RDs within the same ATN Island and which are not Members of the ATN
Island*s Backbone RDC
Note.— These policy statements apply to the routes advertised by an ATN Router in an ATN TRD to an adjacent ATN Router in an ATN RD on the same ATN Island.
An ATN TRD shall provide the following routes to each adjacent ATN RD within the ATN
Island RDC, other than ATN RDs which are members of the ATN Island Backbone RDC, and for the Security RIB-Att:
a) A route to NSAPs and NETs contained within the RD for the Security RIB-Att; the
route's destination shall be one or more NSAP Address prefixes common to all NSAP
Addresses and NETs in the RD.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may also be present. For
example, to restrict the scope of the information to members of the ATN Island only. The RDIs of other RDs and RDCs may also be present at the discretion of the local Administrative Domain, and by bilateral agreement, including the RDI of the ATN Island Backbone RD or RDC, when the adjacent RD is providing the local RD's route to the ATN Island Backbone.
Note 2.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of the ATN Island Backbone RDC, will tell all adjacent RDs within the island about itself.
b) The selected route to every Fixed RD in the same ATN Island for which a route is
available.
Note.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of theATN Island Backbone RDC, will tell all adjacent RDs within the island about all fixed ATN RDs in the same ATN Island that it knows about.
c) If the RD is currently advertising the preferred route to all AINSC and ATSC
Mobiles, then every route to an AINSC Mobile and an ATSC Mobile that is known
to the local RD shall be advertised to this RD, subject only to constraints imposed by
any DIST_LIST_INCL and DIST_LIST_EXCL path attributes.
Note.— The objective of this rule is to ensure that the provider of the default route to all aircraft (i.e.the Backbone) is kept informed of the actual location of every aircraft adjacent to the Island.
d) The preferred route to all Mobiles, except when the RD is the source of this route.
Note.— The objective of this rule is to ensure propagation of the default route to all Mobiles
throughout the ATN Island.
e) A route to each Mobile RD for which the adjacent RD is advertising the preferred
route to the Mobile RD's “home”.
Note.— The objective of this rule is to ensure routes to Mobile RDs are propagated to off Backbone Homes.
f) A route to each “Home” that the ATN TRD itself provides for Mobile RDs. This
route has as its destination, the common NSAP Address Prefix(es) for those Mobile
RDs. The Security Path attribute shall contain an ATSC Class Security Tag
indicating support for both ATSC and non-ATSC traffic, and for all ATSC classes
supported for Air/Ground data interchange, if any.
Note.— The objective of this item is to ensure that all RDs in the ATN Island are aware that the identified “Homes” are located here.
Mobile RDs
Note.— These policy statements apply to the routes advertised by an ATN Router in an ATN TRD to an adjacent ATN Router in a Mobile RD.
When IDRP is being used to exchange routing information with the airborne router, an ATN TRD shall provide to each adjacent Mobile RD a route to NSAPs and NETs contained within the RD for the Security RIB-Att; the route's destination shall be one or more NSAP Address prefixes common to all NSAP
Addresses and NETs in the RD.
Note.— The objective of this rule is to ensure that an ATN TRD will tell adjacent Mobile RDs about itself.
Recommendation.— An ATN TRD should also provide to each adjacent Mobile RD, and
for the Security RIB-Att and for which a suitable route exists:
a) an aggregated route to NSAPs and NETs contained within the local ATN Island
RDC;
b) an aggregated route to NSAPs and NETs contained within all other ATN Islands
for which a route is available.
Note.— The objective of this rule is to encourage an RD to provide to each adjacent Mobile RD routing information about: a) all fixed RDs within the island, and b) other ATN islands.
The Routing Policy for a Fixed ATN ERD
Fixed ATN ERD shall provide to each ATN RD to which it is currently connected, a route
to NSAPs and NETs contained within the RD, for the Security RIB-Att.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may be present, unless the RD permits routes to destinations within itself to be advertised by other ATN RDs without restriction to any other ATN RD, or non-ATN RD.
Note 2.— This policy statement applies to the routes advertised by an ATN Router in a fixed ATN ERD to an adjacent ATN Router in an ATN RD.
Note 3.— An ERD does not advertise routes to destinations in any other RD, to another RD.
5.4 NETWORK AND TRANSPORT ADDRESSING SPECIFICATION
5.4.1 Introduction
Note 1.— The ATN Internet Addressing Plan defines an OSI Network Service Access Point (NSAP) address structure which can support efficient internet routing procedures, and which conforms to common abstract syntax, semantic and encoding rules throughout the ATN OSI environment.
Note 2.— This addressing plan also defines the format and use of TSAP Selectors to enable the unambiguous identification of Multiple Transport Service users within a single End System.
5.4.1.1 Addressing Plan Scope
5.4.1.1.1 The ATN Internet Addressing Plan shall be used by ATN End Systems and Intermediate Systems.
Note.— The ATN Internet Addressing Plan serves the needs of a variety of aeronautical data
communication user groups, including ATSC and AINSC users.
5.4.1.2 Addressing Plan Applicability
Note.— The ATN Internet Addressing Plan defines the Network and Transport Layer addressing information to be utilized by ATN End Systems, and by ATN Intermediate Systems.
5.4.1.3 Reserved Values in Address Fields
5.4.1.3.1 Address field values specified as “reserved” shall not be used until assigned by future versions of this specification.
5.4.1.4 Values of Character Format Fields
5.4.1.4.1 When the value of a field is defined as a character string, then the actual value of the field shall be derived from the IA-5 encoding of each character in the character string.
5.4.1.4.2 The IA-5 encoding of the first character in the string shall be taken as the value of the first octet of the field and so on until all octets in the field have been given a value.
5.4.1.4.3 If the length of the character string is smaller than the number of octets in the field, then the character string shall be right padded with the space character.
5.4.1.4.4 The most significant bit of each octet shall be set to zero.
Note.— For example, the character string ‘EUR’ would be encoded as 455552 hexadecimal, in a three octet field.
5.4.2 Transport Layer Addressing
5.4.2.1 General
Note 1.— This section provides requirements on the format of ATN TSAP addresses. An ATN TSAP address is an NSAP address and a TSAP selector.
Note 2.— The requirements in this section apply to the administration of transport addresses local to an ATN End System. They do not apply to all systems in a global OSI Environment. An ATN System may allow remote transport addresses to obey different standards, e.g. when interworking with a non-ATN system is required.
5.4.2.2 ATN TSAP Selector
5.4.2.2.1 An ATN TSAP selector shall be either one or two octets in length.
5.4.2.2.2 The TSAP Selector field shall be administered on a local basis.
5.4.2.2.3 Valid ATN TSAP Selector field values shall be in the range 0 to 65535.
5.4.2.2.4 The TSAP Selector field shall be encoded as an unsigned binary number.
5.4.2.2.5 If the TSAP Selector needs to be encoded in more than one octet, then the number shall be encoded with the most significant octet first.
Note.— This follows the encoding rules specified in ISO/IEC 8073.
5.4.2.2.6 Recommendation.— TSAP selector values in the range 0 to 255 should be encoded using one octet, higher values should be encoded using two octets
5.4.3 Network Layer Addressing
5.4.3.1 NSAP Addresses and Network Entity Titles (NETs)
Note 1.— The NSAP Address is formally defined in ISO/IEC 8348. It is the name of a Network
Service Access Point (NSAP) located in an End System, and uniquely identifies that NSAP. It is also an address that may be used to find that NSAP.
Note 2. — The Network Entity Title (NET) is also formally defined in ISO/IEC 8348 and is the name of a Network Entity located within an End or Intermediate System. NETs are syntactically identical to NSAP Addresses and are allocated from the same address space. An NET is also an address that may be used to find the Network Entity.
Note 3.— An NSAP Address Prefix is a substring of an NSAP Address or NET that is comprised of the first ‘n’ characters of the NSAP Address or NET.
5.4.3.2 Network Addressing Domains
Note 1.— A Network Addressing Domain comprises all NSAP Addresses and NETs with a common NSAP Address Prefix, and is always a sub-domain of the Global NSAP Addressing Domain which contains all NSAP Addresses. This nesting of network addressing domains within the Global Network Addressing Domain is conceptually illustrated in Figure 5.4-1.
Note 2.— A Network Addressing Domain has a single Administrator responsible for the assignment of NSAP Addresses and NSAP Address Prefixes within the domain. A Network Addressing Domain is often sub-divided into a number of sub-ordinate domains each characterised by a unique NSAP Address Prefix.
Management of such sub-ordinate Network Addressing Domains may then be devolved to another Administrator.
5.4.3.2.1 An ATSC Network Addressing Domain shall be a Network Addressing Domain administered by an ATSC authority.
5.4.3.2.2 An AINSC Network Addressing Domain shall be a Network Addressing Domain administered by a member of the Aeronautical Industry.
5.4.3.2.3 ATN End Systems or Intermediate Systems located on-board general aviation aircraft shall belong to an ATSC Network Addressing Domain, whereas ATN systems installed on-board commercial aircraft shall belong to an AINSC Network Addressing Domain.
5.4.3.3 The Syntax of an NSAP Address
Note 1.— Following ISO/IEC 10589, a Router interprets an NSAP Address as a three-fields bit
string. This is illustrated in Figure 5.4-2 below.
Area Address System Identifier SEL
Note 2.— An Area Address is typically common to all NSAP Addresses and NETs assigned to
systems in a single Routing Area.
Note 3.— An Area Address is an example of an NSAP Address Prefix.
Note 4.— A System Identifier uniquely identifies an End or Intermediate System within a Routing
Area.
Note 5.— A Selector (SEL) identifies a Network Service User or the Network Entity within an End
or Intermediate System.
5.4.3.4 The ATN Addressing Plan
Note 1.— ISO/IEC 8348 has specified how the Global Network Addressing Domain is broken down into a number of sub-ordinate Network Addressing Domains, each of which is identified by a uniqueidentifier that forms the initial part of all NSAP Addresses and NETs in those sub-ordinate domains. This initial part is known as the Initial Domain Part (IDP). The IDP itself is defined as comprising two parts: anAuthority Format Identifier (AFI) and an Initial Domain Identifier (IDI). The AFI identifies the format and
allocation procedures for the IDI and the format of the remainder of the NSAP Address.
Note 2.— The ATN Network Addressing Domain is such a sub-ordinate Network Addressing Domainand has an IDP that uses an ISO 6523-ICD IDI.
Note 3.— The IDP is always expressed as decimal digits. However, ISO/IEC 8348 permits NSAPAddresses in an ISO 6523-ICD domain to have either a binary or a decimal format for the remainder of the address - the Domain Specific Part (DSP). The format of the DSP is determined by the AFI.
5.4.3.4.1 All ATN NSAP Addresses shall have an AFI with the value 47 decimal.
Note.— This AFI value is defined by ISO/IEC 8348 to imply an ISO 6523-ICD IDI with a binary
format DSP.
5.4.3.4.2 All ATN NSAP Addresses shall have an IDI value of 0027 decimal.
Note.— This value has been allocated by ISO to ICAO under the ISO 6523-ICD scheme. An IDP of 470027 therefore forms the common NSAP Address Prefix to all ATN NSAP Addresses and effectively defines the ATN Network Addressing Domain, as a sub-domain of the Global Network Addressing Domain.
5.4.3.5 The Reference Publication Format
Note.— The Reference Publication Format is defined by ISO/IEC 8348 for the publication of NSAP Addresses and NETs in a form suitable for text documents.
5.4.3.5.1 Recommendation.— For the purposes of publication in a text format, ATN NSAP Addresses and NETs should be written as the character sequence “470027+”, identifying the common prefix for all ATN NSAP Addresses, followed by the DSP expressed as a sequence of hexadecimal characters.
Note.— The “+” sign is used as a separator between the decimal syntax IDP and the hexadecimal syntax DSP.
5.4.3.5.2 Each successive pair of hexadecimal digits shall correspond to the next binary octet of the DSP.
5.4.3.6 The ATN NSAP Address Format
Note 1.— The derivation of the ATN NSAP Address Format is illustrated in Figure 5.4-3. This starts with the AFI and IDI fields required by ISO/IEC 8348. It ends with the System ID (SYS) and SEL fields required by ISO/IEC 10589. The remaining DSP fields are specified below and used to co-ordinate the allocation of ATN NSAP Addresses.
Note 2.— The VER field is used to partition the ATN Addressing Domain into a number of
sub-ordinate addressing domains, each of which provides a different approach to address management.
Note 3.— The ADM field is then used to break down each such partition into a number of
sub-ordinate addressing domains, each of which may then be managed by a different manager.
Note 4.— In Fixed Network Addressing Domains, the ARS field may then be used to identify a
Network Addressing Domain that will correspond to each Routing Domain under the control of each such manager, and the LOC field may then be used to identify each Routing Area within each Routing Domain.
Note 5.— In Mobile Network Addressing Domains, the ARS field identifies an aircraft. Where all ATN systems onboard an aircraft form a single Routing Domain, the ARS field also identifies the Addressing Domain that will correspond to that Routing Domain, and the LOC field is used as above. However, when the ATN systems onboard a single aircraft form more than one Routing Domain, then part of the LOC field is also used to identify such an Addressing Domain.
Note 6.— The reason for the existence of the RDF field is historical.
5.4.3.7 NSAP Address Encoding
Note 1.— In ISO/IEC 8348 terms, the IDP has an abstract decimal syntax, and the DSP has an
abstract binary syntax. The reason for the use of the word abstract is to emphasise the fact that the actual encoding is outside of the scope of ISO/IEC 8348, and instead is the responsibility of the standards that specify the encoding of network layer protocols.
Note 2.— ISO/IEC 8348 does, however, describe two possible encoding schemes, the “preferred binary encoding” and the “preferred decimal encoding”. ISO/IEC 8473 mandates the use of the preferred binary encoding for CLNP, while ISO/IEC 10747 mandates a modified version of the preferred binary encoding in order to cope with bit aligned NSAP Address Prefixes.
Note 3.— In consequence, this specification only specifies how each field of the DSP is allocated as an unsigned binary number. The actual encoding of the resulting bitstring in an NPDU is then according to the applicable protocol specification.
5.4.3.8 Allocation of the DSP
Note.— The DSP fields of an ATN NSAP Address are the VER, ADM, RDF, ARS, LOC, SYS and SEL fields. The size of each of these fields is given in Table 5.4-1.
5.4.3.8.1 The Version (VER) Field
Note 1.— The purpose of the VER field is to partition the ATN Network Addressing Domain into a number of sub-ordinate Addressing Domains.
Note 2.— The values currently specified for the VER Field and the Network Addressing Domains so defined, are summarised in Table 5.4-2.
5.4.3.8.1.1 The VER Field shall be one octet in length.
5.4.3.8.1.2 A VER field value of [0000 0001] shall be used for all NSAP Addresses and NETs in the Network Addressing Domain that comprises all Fixed AINSC NSAP Addresses and NETs.
Note.— The NSAP Address Prefix “470027+01” is therefore the common NSAP Address Prefix for the Fixed AINSC Network Addressing Domain.
5.4.3.8.1.3 A VER field value of [0100 0001] shall be used for all NSAP Addresses and NETs in the Network Addressing Domain that comprises all Mobile AINSC NSAP Addresses and NETs.
Note.— The NSAP Address Prefix “470027+41” is therefore the common NSAP Address Prefix for the Mobile AINSC Network Addressing Domain.
Address Field
Name
Address Field Size
VER 1 Octet
ADM 3 Octets
RDF 1 Octet
ARS 3 Octets
LOC 2 Octets
SYS 6 Octets
SEL 1 Octet
Table 5.4-1 DSP NSAP Address Field Sizes
5.4.3.8.1.4 A VER field value of [1000 0001] shall be used for all NSAP Addresses and NETs in the Network Addressing Domain that comprises all Fixed ATSC NSAP Addresses and NETs.
Note.— The NSAP Address Prefix “470027+81” is therefore the common NSAP Address Prefix forthe Fixed ATSC Network Addressing Domain.
5.4.3.8.1.5 A VER field value of [1100 0001] shall be used for all NSAP Addresses and NETs in the Network Addressing Domain that comprises all Mobile ATSC NSAP Addresses and NETs.
Note.— The NSAP Address Prefix “470027+C1” is therefore the common NSAP Address Prefix forthe Mobile ATSC Network Addressing Domain.
5.4.3.8.1.6 All other VER field values shall be reserved.
VER Field Value Network Addressing Domain Common NSAP
Address Prefix for Domain
[0000 0001] Fixed AINSC 470027+01
[0100 0001] Mobile AINSC 470027+41
[1000 0001] Fixed ATSC 470027+81
[1100 0001] Mobile ATSC 470027+C1
Table 5.4-2 VER Field Assigned Values
Internet communications service V-73
ICAO ATNP Version 2.3 - Editors’ Draft
5.4.3.8.2 The Administration (ADM) Field
5.4.3.8.2.1 General
Note.— The purpose of the ADM field is to sub-divide each of the Network Addressing Domains introduced by the VER field into a further set of sub-ordinate Network Addressing Domains, and to permit devolved administration (i.e. address allocation) of each resulting domain to an individual State or Organisation.
5.4.3.8.2.1.1 The ADM field shall be three octets in length.
5.4.3.8.2.2 Fixed AINSC NSAP Addresses and NETs
Note.— In the Fixed AINSC Network Addressing Domain, the ADM field is used to sub-divide this Addressing Domain into a number of sub-ordinate Network Addressing Domains, each of which comprises NSAP Addresses and NETs for fixed systems operated by a single AINSC Organisation.
5.4.3.8.2.2.1 Allocation of NSAP Addresses and NETs in each such Network Addressing Domain subordinate to the Fixed AINSC Network Addressing Domain shall be the responsibility of the organisation identified by the value of the ADM field.
5.4.3.8.2.2.2 Recommendation.— The field value should be derived from the set of three-character alphanumeric symbols representing an IATA Airline or Aeronautical Stakeholder Designator, according to 5.4.1.4.
Note.— AINSC Organisations are intended to register their ADM values with IATA.
5.4.3.8.2.3 Fixed ATSC NSAP Addresses and NETs
Note.— In the Fixed ATSC Network Addressing Domain, the ADM field is used to sub-divide this Addressing Domain into a number of sub-ordinate Network Addressing Domains, each of which comprises NSAP Addresses and NETs for fixed systems operated by a single State or within an ICAO Region.
5.4.3.8.2.3.1 Allocation of NSAP Addresses and NETs in each such Network Addressing Domain subordinate to the Fixed ATSC Network Addressing Domain shall be the responsibility of the State or ICAO Region identified by the value of the ADM field.
5.4.3.8.2.3.2 When used for identifying a State, the ADM field shall be derived from the State’s three-character alphanumeric ISO 3166 Country Code, represented as upper case characters.
5.4.3.8.2.3.3 In this case, the value of the field shall be determined according to 5.4.1.4.
Note.— For example, the encoding of ‘GBR’ is 474252 in hexadecimal. Therefore the NSAP Address Prefix 470027+81474252 is the common NSAP Address Prefix for all NSAP Addresses and NETs in the UK Fixed ATSC Network Addressing Domain.
5.4.3.8.2.3.4 When used to identify an ICAO Region, the first octet of the ADM field shall identify the ICAO Region, according to Table 5.4-3, while the values of the remaining two octets shall be assigned by the identified ICAO Region.
Note 1.— The ISO 3166 character codes are always represented as binary octets, each of which has a zero most significant bit. Therefore, it is possible to guarantee that the field values listed in Table 5.4-3 do not conflict with ISO 3166 derived State Identifiers.
ADM Field First Octet ICAO Region
[1000 0000] Africa
[1000 0001] Asia
[1000 0010] Caribbean
[1000 0011] Europe
[1000 0100] Middle East
[1000 0101] North America
[1000 0110] North Atlantic
[1000 0111] Pacific
[1000 1000] South America
Table 5.4-3 ICAO Region Identifiers
Note 2.— This Addressing Plan enables ICAO Regions to allocate ADM field values in the Fixed ATSC Network Addressing Domain to States and Organisations within the ICAO Region, in a structured manner. This is in order to permit the efficient advertisement of routing information. For example, in the advertisement of routes to ‘all RDs in the same ATN Island’ as recommended in 5.3.7.1.4.2.
5.4.3.8.2.3.5 All ADM field values in the Fixed ATSC Network Addressing Domain that do not correspond to valid ISO 3166 Country Codes or which are not assigned to ICAO Regions shall be reserved.
5.4.3.8.2.4 Mobile NSAP Addresses and NETs
Note.— In both the Mobile AINSC and the Mobile ATSC Network Addressing Domains, the ADM field is used to sub-divide this Addressing Domain into a number of sub-ordinate Network Addressing
Domains, each of which comprises NSAP Addresses and NETs for mobile systems operated by a single Airline or onboard the General Aviation aircraft of a single State.
5.4.3.8.2.4.1 For Mobile AINSC NSAP Address and NETs, the ADM field value shall be set according to 5.4.3.8.2.2, and the corresponding sub-ordinate Network Addressing Domain administered by the organisation identified by the value of the ADM field.
5.4.3.8.2.4.2 For Mobile ATSC NSAP Address and NETs, the ADM field value shall be set according to 5.4.3.8.2.3, and the corresponding sub-ordinate Network Addressing Domain administered by the State identified by the value of the ADM field.
5.4.3.8.3 The Routing Domain Format (RDF) Field
Note 1.— There is no absolute requirement for the remainder of the DSP in each of the above defined Network Addressing Domains to be allocated according to a co-ordinated addressing plan, or for even the same fields to exist, or the NSAP Addresses to have the same length. However, in order to encourage common equipment development, this specification specifies the existence, size and use of the RDF, ARS and LOC fields.
Note 2.— The reason for the existence of the RDF field is historical.
5.4.3.8.3.1 The RDF field shall be one octet in length and its value shall be [0000 0000] in binary.
5.4.3.8.3.2 All other values shall be reserved.
5.4.3.8.4 The Administrative Region Selector (ARS) Field
Note 1.— In Fixed Network Addressing Domains, the purpose of the ARS field is to distinguish
Routing Domains operated by the same State or Organisation.
Note 2.— In Mobile Network Addressing Domain, the purpose of the ARS field is to identify the aircraft on which the addressed system is located. When the systems onboard an aircraft form a single Routing Domain, then the ARS field also identifies the Routing Domain. When the systems onboard an aircraft form multiple RDs, then part of the LOC field is used to distinguish them.
5.4.3.8.4.1 The ARS field shall be three octets in length.
5.4.3.8.4.2 In the Fixed AINSC and ATSC Network Addressing Domains, the value of the ARS field shall be a 24-bit unsigned binary number that uniquely identifies the NSAP Addresses and NETs assigned to systems in a single Routing Domain.
5.4.3.8.4.3 In the Fixed AINSC and ATSC Network Addressing Domains, the State or Organisation identified by the value of the ADM field shall be responsible for assigning the ARS field.
Note 1.— For example, 470027+8147425200000000 and 470027+8147425200000001 are therefore NSAP Address Prefixes common to all NSAP Addresses and NETs assigned to fixed systems in two distinct
Routing Domains operated by the UK ATSC authority.
Note 2.— Where necessary, the allocation of NSAP Addresses and NETs may thus readily be
delegated to a Network Administrator responsible for each Network Addressing Domain that corresponds to each Routing Domain.
5.4.3.8.4.4 In Mobile AINSC and ATSC Network Addressing Domains, the value of the ARS field shall be the 24-bit ICAO Aircraft Identifier that uniquely identifies the NSAP Addresses and NETs in a single Routing Domain.
Note 1.— If the aircraft is operated by an IATA Airline then the NSAP Address or NET is in a MobileAINSC Network Addressing Domain.
Note 2.— For General Aviation Aircraft, the NSAP Address or NET is in a Mobile ATSC Network Addressing Domain.
5.4.3.8.5 The Location (LOC) Field
Note 1.— In Fixed Network Addressing Domains, the purpose of the LOC field is to distinguish
Routing Areas within the same Routing Domain.
Note 2.— In Mobile Network Addressing Domains, the LOC field is used
a) to distinguish Routing Areas within the same Mobile Routing Domain, or,
b) when more than one Routing Domain is located on a single Aircraft, to distinguish
each Routing Domain and the Routing Areas contained within them.
Note 3.— For example, the first octet of the LOC field may be used to distinguish each Routing Domain on board a single aircraft, and the second octet to distinguish each Routing Area.
Note 4.— The combination of AFI, IDI, VER, ADM, RDF, ARS and LOC fields therefore forms an
Area Address.
5.4.3.8.5.1 The LOC field shall be two octets in length and may be given any binary value.
5.4.3.8.5.2 The administrator of the Network Addressing Domain that co-incides with the Routing Domain in which a given Routing Area is located, shall be responsible for the allocation of a LOC field value that provides a unique Area Address for that Routing Area.
Note.— For example, 470027+81474252000000010045 is an Area Address in a Routing Domainoperated by the UK ATSC Administration.
5.4.3.8.6 The System Identifier (SYS) Field
Note.— ISO/IEC 10589 defines the System Identifier as a variable length field which uniquely
identifies an End or Intermediate System within a ISO/IEC 10589 Routing Area. Within a Routing Area, all System Identifiers are of the same length, although a Router is not able to make assumptions about the length of this field outside of its own Routing Area. However, the ATN Addressing Plan does specify this field toalways be six octets in length in order to encourage a common equipment base.
5.4.3.8.6.1 In an ATN NSAP Address or NET, the System Identifier (SYS field) shall be six octets in length.
5.4.3.8.6.2 The value of the SYS field shall be a unique binary number assigned by the addressing authority responsible for the Network Addressing Domain that corresponds with the Routing Area in which the identified system is located.
Note.— If the System is attached to an IEEE 802 Local Area Network (e.g. an Ethernet), then a common approach is to use the 48-bit LAN address as the value of the SYS field.
5.4.3.8.7 The NSAP Selector (SEL) Field
Note.— The NSAP Selector (SEL) field identifies the End System or Intermediate System network entity or network service user process responsible for originating or receiving Network Service Data Units (NSDUs).
5.4.3.8.7.1 The SEL field shall be one octet in length.
5.4.3.8.7.2 The SEL field value for an Intermediate System network entity shall be [0000 0000], except for the case of an airborne Intermediate System implementing the procedures for the optional non-use of IDRP.
5.4.3.8.7.3 In the case of an airborne Intermediate System implementing the procedures for the optional non-use of IDRP, the SEL field value shall be [1111 1110].
5.4.3.8.7.4 The SEL field value [1111 1111] shall be reserved.
Note 1.— In an Intermediate System, any other SEL field value may be assigned to NSAPs. The actual value chosen is a local matter.
Note 2.— SEL field values in stand-alone End Systems (i.e. in End Systems not co-located with
Intermediate Systems) are not constrained.
5.4.3.8.7.5 SEL field values other than those defined for Intermediate System Network Entities in 5.4.3.8.7.2 and 5.4.3.8.7.3 above or being reserved, shall be assigned by the addressing authority responsible for the identified End or Intermediate System.
5.4.3.9 Pre-Defined NSAP Address Prefixes
5.4.3.9.1 All AINSC Mobiles
5.4.3.9.1.1 The NSAP Address Prefix 470027+41 shall provide a common NSAP Address Prefix for all AINSC Mobiles.
5.4.3.9.2 All ATSC Mobiles
5.4.3.9.2.1 The NSAP Address Prefix 470027+C1 shall provide a common NSAP Address Prefix for all ATSC Mobiles.
Note.— The NLRI for the Default Route to all Mobiles comprises both the NSAP Address Prefixes defined above.
5.4.3.9.3 All Aircraft Belonging to an Airline
5.4.3.9.3.1 The NSAP Address Prefix 470027+41 plus the value of the ADM field assigned to the airline shall provide a common NSAP Address Prefix for all AINSC Mobiles operated by a single airline.
Note.— The NLRI for the Route to the “Home” for the aircraft belonging to a given airline contains this NSAP Address Prefix.
5.4.3.9.4 All General Aviation and Other Types of Aircraft Registered by a State
5.4.3.9.4.1 The NSAP Address Prefix 470027+C1 plus the value of the ADM field assigned to the State shall provide a common NSAP Address Prefix for all ATSC Mobiles registered by a single State.
Note.— The NLRI for the Route to the “Home” for the General Aviation and other types of aircraft registered by a single State contains this NSAP Address Prefix.
5.5 TRANSPORT SERVICE AND PROTOCOL SPECIFICATION
5.5.1 General
5.5.1.1 Overview
5.5.1.1.1 The COTP (Connection Oriented Transport Protocol ) shall be used to provide an end-to-end reliable data transfer service between Transport Service users on two ATN End Systems.
5.5.1.1.2 In ATN End Systems, the implementation of the COTP shall conform to ISO/IEC 8073 and the mandatory requirements given in this Chapter.
5.5.1.1.3 The CLTP (Connectionless Mode Transport Protocol) shall be used to provide a
Connectionless data transfer service between Transport Service users on two ATN End Systems.
5.5.1.1.4 In ATN End Systems, the implementation of the CLTP shall conform to ISO/IEC 8602 and the mandatory requirements given in this chapter.
Note.— The transport protocols specified for use in ATN End Systems provide both Connection Mode and Connectionless Mode communication services. The implementation and use of a particular mode
of the Transport Layer service depends on the requirements of the application(s) supported by a given ATN End System.
5.5.1.2 Transport Service Description
Note 1.— When the TS-user requires use of the connection mode transport service the TS-user will provide the following information to the TS-provider on a per Transport Connection basis:
a) called and calling TSAP address;
b) whether or not the expedited data option is required;
c) the required residual error rate (RER) to determine whether use or non-use of the
transport checksum is allowed;
d) the Application Service Priority to be mapped into the resulting CLNP NPDUs
according to Table 1.2-2;
e) the ATN Security Label specifying the ATN Traffic Type, i.e.
C ATN Operational Communications;
C ATN Administrative Communications;
C General Communications;
C ATN Systems Management Communications.
V-80 Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN)
ICAO ATNP Version 2.3 - Editors’ Draft
Note 2.— In the case where the Traffic Type specified is ATN Operational Communications theTS-user will additionally provide the traffic category, i.e. Air Traffic Services Communications (ATSC) orAeronautical Operational Control (AOC).
Note 3.— In the case of the ATSC traffic category the TS-user will further specify the required ATSC
Class as defined in Table 1.2-1, or no traffic type policy preference.
Note 4.— In the case of the AOC traffic category the TS-user will further specify the subnetwork preference (including no preference).
Note 5.— The ATN Traffic Types and their associated traffic categories are specified in Table 5.6-1.
The encoding of the ATN Security Label is specified in Figure 5.6-1 and 5.6.2.2.2.2 bullet b).
Note 6.— The TS-user is not required to specify any other Transport Service Quality of Service
parameters.
5.5.1.3 Transport Service Access Point Addresses
5.5.1.3.1 A TSAP address shall comprise two elements, a NSAP address and a TSAP selector.
5.5.1.3.2 The NSAP address and the TSAP selector shall conform to the provisions in 5.4.
5.5.1.4 Exchange of Transport-Selector parameters
Note.— TSAP Selectors are transmitted in Calling and Called Transport-Selector parameters in COTP, and in Source and Destination Transport-Selector parameters in CLTP.
5.5.1.4.1 The transport entity shall support Transport-Selector parameters to accommodate the ATN TSAP selector syntax and encoding requirements as specified in 5.4.
5.5.1.4.2 Recommendation.— The transport entity should support remote Transport-Selector parameters of variable size from 0 up to 32 octets using any encoding and any value.
Note.— The absence of a Calling and Called Transport-Selector assumes the Network Address alone unambiguously defines the Transport Address.
5.5.1.4.3 In COTP, on receipt of CR (Connection Request) TPDU, the absence of a Calling or Called Transport-Selector shall be treated as equivalent to a zero length Calling or Called Transport-Selector.
5.5.1.4.4 The absence of a Calling or Called Transport-Selector in a received CC (Connection Confirm)
TPDU shall indicate that Calling or Called Transport-Selector is equivalent to the corresponding parameter
specified in the sent CR TPDU.
5.5.1.4.5 When present in a received CC TPDU, Calling and Called Transport-Selector parameters shall be identical in length and value to the corresponding parameter specified in the sent CR TPDU.
5.5.1.4.6 In CLTP, on receipt of UD (User Data) TPDU, the absence of a Source or Destination
Transport-Selector shall be treated as equivalent to a zero length Source or Destination Transport-Selector.
5.5.2 Connection Mode Transport Layer Operation
5.5.2.1 Connection Mode Transport Service Primitives
Note 1.— For the purpose of describing the notional interfaces between different OSI protocol layers, each protocol layer is assumed to provide a service to the next higher protocol layer. The assumed service provided by the ATN transport layer to its user is described in ISO/IEC 8072.
Note 2.— ATN Applications may specify their use of the COTP implemented in ATN End Systems using the Transport Service specified in ISO/IEC 8072, including use of ATN priority, and security parameters as defined in this specification.
Note 3.— There is no requirement to implement the service specified in ISO/IEC 8072 as a software interface.
5.5.2.2 ATN Specific Requirements
5.5.2.2.1 ATN End Systems shall implement the ISO/IEC 8073 Class 4 transport protocol in order to provide Connection Mode communications over the ATN Internet.
5.5.2.2.2 The COTP shall operate using the CLNS (Connectionless Network Service) as specified in 5.6.
Note.— TPDUs (Transport Protocol Data Units) are sent via the N-UNITDATA Request primitive.
5.5.2.2.3 The transport entity shall not concatenate TPDUs from TCs with different transport priorities or different Security Labels.
5.5.2.2.4 Recommendation.— The Selective Acknowledgement mechanism should be used for conservation of bandwidth by preventing retransmission of correctly received out-of-sequence TPDUs.
5.5.2.2.5 Recommendation.— The Request of Acknowledgement mechanism should be used to reduce AK traffic.
5.5.2.2.6 Recommendation. — The maximum TPDU size should be at least 1024 octets.
Note.— This is to support efficient transmission of anticipated application data exchanges.
5.5.2.2.7 Recommendation.— The Transport Layer should propose a TPDU size of at least 1024 octets.
5.5.2.2.8 Recommendation.— The Transport Layer should use the TPDU size parameter rather than the preferred maximum TPDU size parameter.
5.5.2.2.9 Recommendation.— Implementations of the ATN Transport Layer should propose use of normal format in the CR TPDU.
5.5.2.2.10 Recommendation.— The Extended format should only be proposed when explicitly necessary to meet application Quality of Service requirements.
Note.— Because the increased TPDU size resulting from use of extended data TPDU numbering may be more inefficient, this option is used on a TC only when absolutely required.
5.5.2.2.11 Recommendation.— The Transport Layer should accept non-use of checksum whenproposed in a CR TPDU.
5.5.2.2.12 Implementations of the transport protocol shall support configurable values for all timers and protocol parameters, rather than having fixed values, in order to allow modification as operational experience is gained.
5.5.2.2.13 When intended for operation over Air/Ground subnetworks, transport protocol
implementations shall support the minimum - maximum ranges for COTP timer values as presented in Table 5.5-1.
5.5.2.2.13.1 Recommendation.— Nominal values indicated in Table 5.5-1 should be used.
5.5.2.2.13.2 Recommendation.— The assignment of optimized values for timers and parameters other than the nominal values indicated in Table 5.5-1 should be based on operational experience.
5.5.2.2.14 Recommendation.— When intended for operation exclusively over Ground/Ground subnetworks, implementations of transport protocol timer values should be optimized to ensure interoperability.
5.5.2.3 Connection Mode Transport Quality of Service
5.5.2.3.1 Connection Mode Transport Priority
5.5.2.3.1.1 The Transport Layer shall allow a TC (Transport Connection) priority in the range [0 - 14]
5.5.2.3.1.2 The Transport Layer shall not alter the proposed TC priority specified by the TS-user.
5.5.2.3.1.3 The Transport Layer shall treat all connections without expressed priority as being at the default TC priority.
5.5.2.3.1.4 The default TC priority shall be the lowest priority, i.e. priority [14].
5.5.2.3.1.5 When a TS-user specifies a TC priority, the relationship between this TC priority and the CLNP priority shall be as specified in Table 1.2-2.
5.5.2.3.2 Connection Mode Transport Security
Note.— The ATN security mechanism does not make use of the ISO/IEC 8073 Protection parameter.
The support of the Protection parameter is therefore optional.
Internet communications service V-85
5.5.2.3.2.1 The Transport Layer shall allow a TS-user to specify a Security Label for a transport connection. The transport security procedure shall be implemented as specified in 5.2.7.3.1.
5.5.2.3.2.2 The Security Label format shall be according to 5.2.7.1. The Transport Layer shall not alter the Security Label specified by the TS-user.
Note.—When no Security Label is present, a « General Communications » traffic type is implied.
In this case, CLNP NPDUs are generated without the Security parameter.
5.5.2.4 Encoding of Transport Protocol Data Units
5.5.2.4.1 General
5.5.2.4.1.1 The encoding of TPDUs shall conform to ISO/IEC 8073 for the COTP.
5.5.2.4.2 Encoding of the Acknowledgment Time Parameter
5.5.2.4.2.1 In ATN compliant systems, the acknowledgement time parameter of the CR and CC TPDUs
shall be encoded as follows:
Parameter
Code:
1000 0101
Note 1.— This is identical to the ISO/IEC 8073 standard
parameter.
Parameter
Length:
2 or 3 octets.
Parameter
Value:
Acknowledgment Timer (AL) value expressed in milliseconds (per
ISO/IEC 8073 standard)
Note 2.— This enhancement is in response to the unique requirements of the aeronautical
environment which may require longer acknowledgment times than foreseen in ISO/IEC 8073.
Note 3.— Initial values of these timers may depend upon the subnetwork, traffic type and routing policy requirements expressed in the associated ATN Security Label.
Note 4.— In cases where the AL value is expressed in 2 octets (less than 65536 milliseconds), the ATN implementation will behave in compliance with the ISO/IEC 8073 standard.
Note 5.— Implementors are advised to permit systems administrators to readily specify initial values.
5.5.2.5 Transport Layer Congestion Avoidance
5.5.2.5.1 General
V-86 Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN)
ICAO ATNP Version 2.3 - Editors’ Draft
Note 1.— The congestion avoidance mechanisms in the Transport Layer make use of the notification by the Network Layer of Congestion Experienced flags in received NPDUs. This mechanism allows transport entities to reduce the window, i.e. the number of DT TPDUs allowed to be sent without acknowledgement,
when the proportion of NPDUs indicating congestion reaches a certain threshold.
Note 2.— This congestion information consists of the total length of the sequence of NPDUs forming the associated NSDU, and the number of NPDUs of that sequence that had their congestion experienced flag set upon reception.
Note 3.— Transport Congestion Avoidance measures are applicable to the Connection Mode
transport service only.
5.5.2.5.1.1 The transport entity shall implement the congestion avoidance algorithm defined in this section.
5.5.2.5.1.2 This algorithm shall be applied for each transport connection individually.
5.5.2.5.2 Advertised Window
5.5.2.5.2.1 General
5.5.2.5.2.1.1 A receiving transport entity shall provide the sending transport entity with the lower window edge and the size of the advertised window (W) by using the explicit flow control mechanisms specified in ISO/IEC 8073.
Note.— The advertised window is the window advertised by the receiver of the data to the sender
of the data. It indicates the number of DT TPDUs that the receiver is willing to accept.
5.5.2.5.2.2 Initialisation of the Advertised Window
5.5.2.5.2.2.1 The initial value of the window W0 that is advertised to the sending transport entity shall have
a locally configurable value.
5.5.2.5.2.2.2 This initial window shall be sent to the sending transport entity in the first CDT field
transmitted.
5.5.2.5.3 Receiving Transport Entity Congestion Avoidance
5.5.2.5.3.1 General
5.5.2.5.3.1.1 Congestion avoidance shall be performed within repeated update phases.
5.5.2.5.3.1.2 Each update phase shall terminate with the possible advertisement of a new window size to
the sending transport entity.
Internet communications service V-87
ICAO ATNP Version 2.3 - Editors’ Draft
5.5.2.5.3.2 Start of Update Phase
5.5.2.5.3.2.1 An update phase of the advertised window shall start after the receiving transport entity has
advertised a new value of the window Wnew to the sending transport entity.
5.5.2.5.3.3 Ignoring Congestion Information
5.5.2.5.3.3.1 After having advertised a new window size, the receiving transport entity shall ignore
congestion information coming from the Network Layer, until it has received W (i.e. the « old » advertised
window size) further DT-TPDUs. It then shall enter the sampling sub-phase.
5.5.2.5.3.3.2 When the sending transport entity advertises the initial window size W0, it shall set W to 0.
5.5.2.5.3.4 Sampling Congestion Information
5.5.2.5.3.4.1 The receiving transport entity shall maintain a count N equal to the total number of NPDUs
that convey DT-TPDUs, and a count NC equal to the number of such NPDUs that had their congestion
experienced flag set upon reception.
5.5.2.5.3.4.2 Upon entering the sampling sub-phase, these counts shall be reset to zero.
5.5.2.5.3.4.3 These counts shall be updated upon receipt of a DT-TPDU using the congestion information
supplied by the Network Layer.
5.5.2.5.3.4.4 The sampling sub-phase shall end as soon as the transport entity has received Wnew DT-TPDUs
within the sampling sub-phase. The end of the sampling sub-phase also terminates the update phase.
5.5.2.5.3.5 Action Upon the End of the Update Phase
5.5.2.5.3.5.1 The receiving transport entity shall take the following actions at the end of each update phase:
a) If the count NC is less than 8 % of the count N, the receiving transport entity shall
increase the size of the advertised window by adding up to a maximum based on the
local buffer management policy. Otherwise, it shall decrease the size of the advertised
window by multiplying it by $. If the result of this multiplication has a decimal part,
the new window size shall be the truncated to its integer value. The size of the
advertised window shall not go to a value smaller than 1.
b) The counts N and NC shall be reset to 0.
c) The new window size shall be transmitted to the sending transport entity in
accordance with the explicit flow control mechanisms specified in ISO/IEC 8073.
Note.— This procedure does not explicitly require the reduction of the upper window edge, as it is possible to gradually reduce the credit window.
5.5.2.5.4 Recommended Algorithm Values
5.5.2.5.4.1 Recommendation.— The value settings defined in the following table should be implemented and configurable by a System Manager:
5.5.2.6 Use of the ATN Network Service
Note.— This section specifies how the COTP operates over the CLNS provided by the ATN Network Layer.
5.5.2.6.1 Use of the N-UNITDATA Request
5.5.2.6.1.1 General
5.5.2.6.1.1.1 The Transport Layer shall use the N-UNITDATA Request primitive, as defined in ISO/IEC 8073, to transmit TPDUs.
Note.— The way the parameters are exchanged between the transport entity and the Network Service is a local matter.
5.5.2.6.1.1.2 The length indication given to the network service shall be equal to the length of the TPDU(s).
Note.— The maximum size of each TPDU is restricted to the locally defined maximum NSDU size.
5.5.2.6.1.2 NS-user-data
Note.— Transport entities transmit TPDUs as NS-user-data of the N-UNITDATA Request primitive.
5.5.2.6.1.3 Network Service Access Point Addresses
Note.— The Transport Layer has knowledge of the source and destination address parameters only as octet strings.
5.5.2.6.1.4 Network Quality of Service
5.5.2.6.1.4.1 General
5.5.2.6.1.4.1.1 The COTP shall use the network QoS parameters as defined in the sections below.
5.5.2.6.1.4.2 Network Layer Priority
5.5.2.6.1.4.2.1 The COTP shall use the network priority parameter to indicate the relative priority of a NSDU.
5.5.2.6.1.4.2.2 When a transport priority has been specified, the value of network priority shall be determined based on the transport connection priority, as defined in Table 1.2-2.
5.5.2.6.1.4.2.3 If the Transport Layer supports levels of TC priority numerically greater than 14, TPDUs
associated with the TC shall be transmitted using a network priority level of zero.
Note.— As specified in ISO/IEC 8073, the Transport Layer priority level zero is highest. ISO/IEC 8473 specifies zero as the lowest network priority and fourteen as the highest. Table 1.2-2 defines the required mapping between these two schemes for use by ATN systems.
5.5.2.6.1.4.3 Network Layer Security
Note.— The use of the Network Layer security is specified in 5.2.7.3.1.
5.5.2.6.2 Use of the N-UNITDATA Indication
5.5.2.6.2.1 General
5.5.2.6.2.1.1 The Transport Layer shall be capable of receiving TPDUs from the ATN network service using the N-UNITDATA indication primitive, as defined in ISO/IEC 8073.
Note.— The way the parameters are exchanged between the transport entity and the Network Service is a local matter.
5.5.2.6.2.2 NS-user-data
Note.— Transport entities receive TPDUs as NS-user-data of the N-UNITDATA Indication primitive.
5.5.2.7 Connection Mode Transport APRL
5.5.2.7.1 Mandatory and Optional Functions
5.5.2.7.1.1 General
Note.— The requirements for the COTP are provided in the form of an ATN Protocol Requirements List (APRL). The APRL has been prepared using the PICS (Protocol Implementation Conformance Statement) proforma provided with ISO/IEC 8073.
5.5.2.7.1.1.1 An implementation of the ISO/IEC 8073 Transport Protocol shall be used in an ATN End System if and only if its PICS is in compliance with the APRL provided with these SARPs.
ATN3 Support of ATN Security Label? 5.5.2.6.1.4.3 M
ATN4 Configurable Transport Timers? 5.5.2.2.12 M
ATN5 Enhanced encoding of Acknowledgment Time
Parameter?
5.5.2.4.2 M
5.5.2.7.1.3 Initiator/Responder Capability for Protocol Classes 0-4
5.6 INTERNETWORK SERVICE AND PROTOCOL SPECIFICATION
5.6.1 Introduction
Note 1.— The ATN Internet comprises a number of interconnected ATN routers and constituent
subnetworks supporting data communication among host computers operating the ATN Internet protocols.
Note 2.— All ATN NPDUs (Network Protocol Data Units) are encapsulated within appropriate
subnetwork protocol data units for transfer among ATN network entities using the connectionless ISO OSI Network Layer service provided by the ATN Internet. As the ATN Internet protocol is connectionless, any information required to process a particular NPDU is carried within the header of that network protocol data unit for processing by ATN routers and host computers.
5.6.1.1 Scope
Note 1.— This chapter provides requirements and recommendations pertaining to the use of the
ISO/IEC 8473 by ATN End System and Intermediate System Network entities. This Chapter is concerned with the use of ISO/IEC 8473 in the context of the internetworking protocol approach to the provision of CLNS as defined in ISO/IEC 8348. This Chapter contains ATN-specific protocol implementations and is concerned with the interoperability of protocol implementations. It therefore provides appropriate compliance statements and APRLs for this purpose.
Note 2.— The ATN Network Layer Connectionless-Mode Network Service supports the transfer of
a connectionless network service data unit (NSDU) from a source NSAP to a destination NSAP within the ATN network. Each such NSDU transfer is the result of a single invocation of the connectionless-mode Network Service encompassed within the ATN.
5.6.1.2 Applicability of Requirements
5.6.1.2.1 All ATN Intermediate System and End System Network entities shall comply with the
provisions contained in 5.6.2 and 5.6.3, in addition to all APRLs specified in 5.6.4.
5.6.2 ATN Specific Features
5.6.2.1 Purpose of ATN Specific Features
Note 1.— The ATN infrastructure, referred to as an Internet, comprises the interconnection of
computers with gateways and routers via real subnetworks. This internetworking infrastructure, allows for the incorporation of differing Air/Ground and Ground/Ground subnetworks servicing differing user groups,
i.e., Air Traffic Services (ATS), Aeronautical Operational Control Services (AOC), and others.
Note 2.— The CLNP (Connectionless Network Protocol) protocol used to operate this
internetworking infrastructure is based on ISO/IEC 8473 with ATN-specific additions to reflect the unique communications environment of the ATN.
Note 3.— The ATN specific functions listed in this chapter reflect responses to the additional
functional needs of ATN Network entities in order to support user requirements concerned with:
a) Ensuring that information is conveyed about Traffic Type and Routing Policy
requirements pertaining to user data in NPDUs;
b) Ensuring that a priority scheme can be applied for management of End Systems and
Intermediate Systems output queues and buffers;
c) Ensuring that specific policies and procedures are available to handle congestion
avoidance and congestion control requirements within the ATN.
5.6.2.2 The Security Function
5.6.2.2.1 General
5.6.2.2.1.1 The SECURITY Function of ISO/IEC 8473, as defined in this specification, shall be
supported by ATN End System or Intermediate System Network entities receiving or transmitting inter-domain traffic other than Traffic Type as General Communications.
5.6.2.2.1.2 ATN Network entities shall therefore provide the Globally Unique Security format for all
created NPDUs.
5.6.2.2.1.3 The sole exception to this requirement is for General Communications traffic where no
Security parameter information is required to be encoded in created NPDUs.
5.6.2.2.2 Encoding of the Security Parameter
5.6.2.2.2.1 The CLNP Options Security Parameter shall be used in the ATN to convey information about the Traffic Type and Routing Policy Requirements pertaining to the user data of the NPDU (other than General Communications).
Note.— The CLNP Options Security Parameter may also be used to convey a security classification.
5.6.2.2.2.2 The value component of the CLNP Options Security Parameter (in the NPDU header) shall
be encoded as follows:
a) The first octet shall always be encoded as [1100 0000] to indicate the Globally
Unique Security Format;
b) The remaining octets shall contain the ATN Security Label encoded as the four fields
illustrated in Figure 5.6-1, and defined below.
Security Registration
ID Length
Security
Registration ID
(variable)
Security
Information Length
Security
Information
(optional)
Octet 0 1 n n+1
5.6.2.2.3 Security Registration ID Length
5.6.2.2.3.1 This field shall be one octet long and contain the length in octets of the Security Authority's
Security Registration Identifier.
Note.— The Security Registration ID identifies the authority that has specified the associated
security policy.
5.6.2.2.4 Security Registration ID
5.6.2.2.4.1 This field shall contain the following hexadecimal string which identifies the ATN Security
Registration ID:
[ 06 04 2b 1b 00 00 ]
Note.— The ATN Security Registration ID value defined above is the encoding useing ASN.1 Basic
Encoding Rules [ISO/IEC 8825-1] of the ATN Security Registration Identifier defined as {1 3 27 0 0}. This
ATN Security Registration Identifier identifies the ATN Security Authority as an object in the ICAO object
hierarchy. ICAO has been assigned an International Code Designator (ICD) decimal value [0027] in
accordance with the dictates of ISO/IEC 6523. According to ISO/IEC 6523 and ISO/IEC 8824 this value
identifies an arc of the identified organisation of ISO. ICAO object identifiers designate an ICAO defined
hierarchy starting with {1 3 27}. Under this arc, {0} has been designated as ATN, and the flat address space
under ATN starts with object identifiers {0,1,2,3,4, ...}. Value {0} has been assigned as the Traffic Type and
Routing Policy identifier.
5.6.2.2.5 Security Information Length
5.6.2.2.5.1 This field shall be one octet in length and shall define the length in octets of the Security
Information.
V-110 Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN)
ICAO ATNP Version 2.3 - Editors’ Draft
5.6.2.2.5.2 If there is no security information, this field shall be set to zero.
5.6.2.2.6 Security Information
5.6.2.2.6.1 General
5.6.2.2.6.1.1 When present, the Security Information field of the ATN Security Label shall be used to
convey, as separate Tag Sets:
a) The Traffic Type and Routing Policy Requirements, if any, applicable to the transfer
of the user data through the ATN.
b) The Security Classification
5.6.2.2.6.1.2 When no traffic type is identified then the General Communications traffic type shall be
assumed, with a routing policy requirement of “no preference”. When no security classification is specified then
“unclassified” shall be assumed.
5.6.2.2.6.2 Encoding of the Security Information Field
5.6.2.2.6.2.1 The Security Information Field shall comprise zero, one or more Security Tag Sets. A Security
Tag with the same Tag Set Name shall not occur more than once in the options Security Parameter of the CLNP NPDU.
Tag Set Name Length Tag Set Name Tag Set Length Security Tag
Octet 0 1 n n+1
Figure 5.6-2: Security Tag Set Format
5.6.2.2.6.2.2 Each Security Tag Set shall consist of four fields, as illustrated in Figure 5.6-2, and shall be as defined in the following sections.
Note.— This format has been chosen to provide for an extensible type-length-value encoding method
for security related information placed in the CLNP Header under rules specified by the ATN Security
Authority.
5.6.2.2.6.3 Security Tag Set Name Length
5.6.2.2.6.3.1 The Security Tag Set Name Length shall contain the length in octets of the Tag Set Name field.
5.6.2.2.6.4 Security Tag Set Name
5.6.2.2.6.4.1 The Security Tag Set Name shall be used to uniquely identify the Tag Set.
5.6.2.2.6.5 Tag Set Length
5.6.2.2.6.5.1 The Tag Set Length Field shall contain the length in octets of the Security Tag field.
5.6.2.2.6.6 Security Tag
5.6.2.2.6.6.1 The Security Tag field shall be used to convey security related information for which the
syntax and semantics are identified by the preceding Tag Set Name.
5.6.2.2.6.7 Encoding of the Tag Set for Traffic Type and Associated Routing Policies
5.6.2.2.6.7.1 The Tag Set Name shall be set to [0000 1111].
5.6.2.2.6.7.2 When present in the CLNP options Security Parameter, this Tag Set shall always be the first Tag Set to be encoded in the Security Information field of the ATN Security Label.
Note.— This Tag Set is used to identify the traffic type of the data, whether it is for ATC or Airline
communications, and, for Operational Communications, any Routing Policy requirements that apply.
5.6.2.2.6.7.3 The Security Tag shall indicate the Routing Policy Requirements for the data contained in the same NPDU, according to Table 5.6-1.
Note.— See 5.2.7 for detailed information on the ATN Security Policy.
5.6.2.2.6.8 Encoding of the Tag Set for Security Classification
5.6.2.2.6.8.1 The Tag Set Name shall be set to [0000 0011].
5.6.2.2.6.8.2 When present in the security parameter, this Tag Set shall always follow the Tag Set for
Traffic Type and Associated Routing Policies (see 5.6.2.2.6) if present, but otherwise shall be the first Tag Set to be encoded in the field.
Note.— The purpose of this field is to permit the later extension of the ATN to handle classified data.
5.6.2.3 Management of Network Priority
Note.— Network priority handling provisions are specified in 5.2.8.
5.6.2.4 Congestion Management
Note 1.— The congestion management provisions in the Network Layer are intended to guarantee
the notification to the Transport Layer of potential risks of congestion via the CE bit conveyed in the QoS Maintenance parameter of an ISO/IEC 8473 NPDU. 5.5.2.5 defines the measures that the Transport Layer implements upon receipt of NPDUs with the CE bit set.
Note 2.— The above requirement is applicable to all types of ISO/IEC 8473 NPDUs.
5.6.2.4.1 Setting of the congestion experienced flag
5.6.2.4.1.1 The congestion experienced flag (CE-flag) in the QoS maintenance parameter in the options part of an NPDU header shall initially be set to zero by the originator of the NPDU.
5.6.2.4.1.2 When a NPDU is being forwarded by an ATN Intermediate System, the Intermediate System shall examine the depth of the output queue selected for that NPDU.
5.6.2.4.1.3 If the depth of the selected output queue exceeds a threshold " (see Table 5.6-3), the ATN
Intermediate System shall set the CE-flag in the NPDU header.
Note.— The above assumes a single output queue per network (CLNP) priority. If mixed priority
queues are implemented, which is valid provided that priority order is always maintained, then the CE-flag is set only when the number of NPDUs on the queue of the same or a higher priority exceeds alpha.
5.6.2.4.1.4 Once the CE-flag is set, it shall not be reset by any ATN Intermediate System traversed by
the NPDU further along to the path towards the destination.
5.6.2.4.2 Forwarding congestion information to the receiving NS-User
5.6.2.4.2.1 For each sequence of NPDUs that together form an NSDU, the destination network entity shall keep two counters:
a) the first one, n-total, shall reflect the length of that sequence.
b) the second one, n-CE, shall reflect the number of those NPDUs of this sequence, that
had the CE-flag set on reception by the destination network entity.
Note.— Each NSDU is forwarded through the network as a sequence consisting of one or more
NPDUs.
5.6.2.4.2.2 When the destination network entity passes an NSDU to the receiving NS-User, it shall convey the associated counters n-total and n-CE to the NS-User.
Note.— The conveyance of the congestion information associated with an NSDU to the NS-User is
a local matter.
5.6.2.4.3 Required algorithm values
5.6.2.4.3.1 The value settings defined in the following table shall be implemented:
Table 5.6-3 Required Value for "
Name Description Required range
" Output queue threshold 1 packet
5.6.3 ATN Specific Requirements for ISO/IEC 8473
Note.— This section defines ATN specific requirements on the ISO/IEC 8473 Protocol.
5.6.3.1 Segmentation Function.
5.6.3.1.1 ATN Intermediate Systems (ISs) shall support both the segmenting and the non-segmenting
subsets of ISO/IEC 8473.
5.6.3.1.2 ATN End Systems shall support the ISO/IEC 8473 segmenting subset.
5.6.3.1.3 Recommendation. — ATN End Systems should use the non-segmenting ISO/IEC 8473 subset for NSDUs of up to 1024 octets.
5.6.3.2 Security Function
Note.— The ATN Specific use of the ISO/IEC 8473 Security Function is specified in 5.6.2.2.
5.6.3.3 Echo Request Function
5.6.3.3.1 Recommendation. — ATN End System and Intermediate System Network Entities (NEs)
should support the ECHO REQUEST Function as invoked by Network Layer management.
Note.— The Echo Request Function is invoked to obtain information on the reachability of specific
network entities and the path characteristics between NEs through the operation of Network Layer routing functions.
5.6.3.4 Network Priority
Note.— The ATN Specific use of the ISO/IEC 8473 Priority is specified in 5.2.8.4.
ATN Internet
ATN terdiri dari sekelompok Routing Domain(RD) yang saling tehubung. Masing-masing RD ini terdiri dari Intermediate System dan End System dari ATSC/AINSC.
Terdapat 2 jenis RD
- Transit RD
Memiliki kemampuan melalukan/routing Network Protocol Data Unit(NPDU) dari 1 RD ke RD yang lain.
- End RD
Merupakan tujuan akhir/system yang tidak memiliki kemampuan untuk melalukan NPDU
ATN RD
ATN RD harus memenuhi standar ISO 9575 dan terdiri juga dari 1 atau beberapa ATN Router. Setiap ATN RD memiliki Routing Domain Identifier(RDI), RDI dikenal juga sebagai Network Entity Title(NET) dengan syntax yang sama dengan ATN Network Service Access Point(NSAP)
Fixed RD
Setiap negara harus mempunyai minimal 1 ATN RD untuk interkoneksi dengan ATN RD yang lain.
Mobile RD
Mobile ATN(pesawat terbang) harus mempunyai minimal 1 ATN RD yang merupakan END RD dan Airborne Router.
The Ground ATN Internet
Terdiri dari 1 atau lebih ATN Island RDC(Routing Domain Confederations)
ATN Island RDC
Terdiri dari sekumpulan ATN RD tidak diperbolehkan adanya ATN Mobile RD
The Global ATN Backbone
Terdiri dari minimal 1 ATN RD dari setiap ATN Island yang terhubung dengan anggota lain dari Global ATN Backbone . Anggota-anggota dari Global ATN Backbone membentuk ATN Island Backbone RDC
ATN End System
- ATN End Systems are capable of communicating with other ATN End Systems, either
directly or indirectly, to provide end-to-end communication service for Air/Ground or Ground/Ground applications, or both.
- An ATN End System is a realisation of the OSI End System architectural entity.
- An ATN End System supports one or more ATN Applications and supports their
communication over the ATN by providing either the connection mode transport service, or the connectionless mode transport service, or both.
Physical and Data Link Layer
ATN End Systems shall implement the appropriate Physical and Data Link Layer functions
for access to the ATN subnetwork(s) to which they are attached.
Network Layer
ATN End Systems shall implement:
a) The End System provisions of ISO/IEC 8473, as specified in 5.6, as the Subnetwork
Independent Convergence Function (SNICF).
b) a Subnetwork Access Protocol (SNAcP) suitable for each underlying subnetwork.
c) a Subnetwork Dependent Convergence Function (SNDCF) providing byte and code
independent service to the SNICF (i.e. ISO/IEC 8473) via the appropriate Subnetwork Access Protocol, as specified in 5.7.
Recommendation.— ATN End Systems should implement the End System provisions of
ISO/IEC 9542 to facilitate the exchange of routing information between the ES and any locally attachedIS(s).
Transport Layer
Depending on the requirements of the application and its supporting upper-layer protocols,
ATN End Systems shall implement either one or both of the following:
a) ISO/IEC 8073
b) ISO/IEC 8602
Applications
Note.— The requirements for Air/Ground and Ground/Ground applications are contained in
Sections 2 and 3 of the ATN SARPs respectively.
ATN Routers
- ATN Routers are capable of the relaying and routing of Network Layer protocol data units with other ATN Routers and with directly connected ATN End Systems.
- An ATN Router is a realisation of the OSI Intermediate System architectural entity. ATN Routers that additionally implement ISO/IEC 10747 are also known as Boundary Intermediate Systems (BISs).
ATN Router Classes
Class Name Routing Protocols Supported
1. Static Router ISO/IEC 9542 (optional)
2. Level 1 Router ISO/IEC 9542 (optional)
ISO/IEC 10589 Level 1only
3. Level 2 Router ISO/IEC 9542 (optional)
ISO/IEC 10589 Level 1and Level 2
4. G/G Router ISO/IEC 9542 (optional)
ISO/IEC 10589 (optional)
ISO/IEC 10747
5. Air/G Router ISO/IEC 9542
ISO/IEC 10589 (optional)
ISO/IEC 10747
Route Initiation Procedures
6. Airborne Router
with IDRP
ISO/IEC 9542
ISO/IEC 10747
Route Initiation Procedures
7. Airborne Router
without IDRP
ISO/IEC 9542
Route Initiation Procedures
All ATN Inter-Domain Routers (i.e. Router Classes 4 to 7 inclusive) shall support:
a) the ISO/IEC 8473 Connectionless Network Protocol (CLNP) ,
including the use of the CLNP options security parameter, and shall interpret and
obey the Routing Policy Requirements expressed therein, whilst routing the packet
in accordance with any restrictions placed on the traffic types that may be carried
over a given ATN Subnetwork, by forwarding CLNP NPDUs.
b) the ISO/IEC 10747 Inter-Domain Routing Protocol (IDRP) for
the exchange of inter-domain routing information
An Airborne (Router Classes 6 or 7) or Air/Ground Router (Router Class 5) shall support the
Mobile SNDCF for the use of CLNP over an ATN Mobile Subnetwork, and the ISO/IEC
9542 ES-IS routing information exchange protocol, for support of the route initiation
procedures
Physical and Data Link Layers
ATN Routers shall implement the appropriate Physical and Data Link Layer functions for
access to the ATN subnetwork(s) to which they are attached.
Network Layer
An ATN Router shall implement:
a) the Intermediate System provisions of ISO/IEC 8473, as the Subnetwork Independent Convergence Function (SNICF).
b) a Subnetwork Access Protocol (SNAcP) suitable for each underlying subnetwork.
c) a Subnetwork Dependent Convergence Function (SNDCF) providing byte and code
independent service to the SNICF (i.e. ISO/IEC 8473) via the selected Subnetwork
Access Protocol.
d) The routing protocols specified in Table 5.2-1 for the Router*s Router Class
e) The Route Initiation procedures appropriate to the Router Class.
f) Where an ATN Router is directly connected to one or more Mobile Subnetworks, it
shall implement a sub-set of the ISO/IEC 9542 for operation over those subnetworks
to facilitate the exchange of addressing information (BIS Network Entity Title)
between the Router and its peer.
ATN Routers of class 5 (Air/Ground Routers) and of class 7 (Airborne Routers without IDRP)
shall also implement the mechanisms necessary to support the “optional non-use of ISO/IEC 10747”
ATN Subnetworks
An ATN Subnetwork is any fixed or Mobile data communications network that fulfils the
following requirements.
Requirements for All ATN Subnetworks
Both fixed and Mobile ATN subnetworks shall conform to the following requirements.
Byte and Code Independence
Data shall be transferred through ATN Subnetworks in a byte and code independent manner.
Note.— If necessary, this byte and code independence may be ensured through the services of the
SNDCF.
Subnetwork QoS
A Subnetwork service provider shall provide an indication of the Subnetwork Quality of
Service (QoS) available, in order to support the internetwork routing decision process.
Subnetwork Addressing
An ATN subnetwork shall provide a mechanism for uniquely and unambiguously identifying each ATN router attached to that subnetwork.
Internal Subnetwork Routing
Routing between specified source and destination Subnetwork Point of Attachment (SNPA)
addresses on an ATN subnetwork shall be carried out by mechanisms internal to the subnetwork.
Minimum SNSDU Size
An ATN subnetwork shall support a minimum Subnetwork Service Data Unit (SNSDU) size
of 1100 octets.
Note 1.— The 1100 octet number is derived from a 1024 octets user data, 9 octets fixed
ISO/IEC 8473 header, 42 octets Source and Destination NSAP Addresses, 4 octets for the SNDCF local
reference option, 3 octets for the QoS Maintenance parameter, 3 octets for the priority parameter, and 15
octets for the security parameter.
Note 2.— This will permit the use of the non-segmenting ISO/IEC 8473 subset for NSDUs of up to
1024 octets.
ATN Security Concept
ATN Security Functions are concerned with:
a) Protecting ATN Data Link applications from internal and external threats;
b) Ensuring that application Quality of Service and Routing Policy Requirements are
maintained, including service availability; and,
c) Ensuring that Air/Ground subnetworks are used in accordance with ITU resolutions
on frequency utilisation.
Other than through the provision of physical security mechanisms, no security mechanisms
are provided in the ATN Internet for protecting ATN Data Link applications. ATN Data Link applicationsnneed to develop their own security mechanisms for countering any threats to their proper operation. This may change in future versions of the specification.
There are currently no mechanisms for protecting the Routing Information Base from an
attacker. However, the use of ISO/IEC 10747 type 2 authentication is under consideration for specification in future versions of this specification.
The ATN Internet does provide mechanisms to support items (b) and (c) above. These
mechanisms are defined to take place in a common domain of trust, and use a Security Label in the header of each CLNP PDU to convey information identifying the “traffic type” of the data and the application*s routing policy and/or strong QoS Requirements. No mechanisms are provided to protect the integrity of this label or its binding to the application data.
In order to permit the later extension of the ATN to handle classified data, the Security
Label in the CLNP PDU header can additionally be used to convey Security Classification information.
The Routing Information necessary to support this Security Label is maintained through
information conveyed in the ISO/IEC 10747 Security Path Attribute about each route. ATN Routers of classes 4 and above reference this routing information during the NPDU forwarding process in order to meet the application*s requirements expressed through the NPDU*s Security Label and to enforce any applicable ITU resolutions on frequency utilisation.
The ATN Security Label
General
The ATN Security Label shall be encoded
An ATN Security Label shall be provided as part of the header of every CLNP NPDU, except
for those that convey General Communications applications data.
Traffic Types
A CLNP Data NPDU*s Security Label shall identify the “Traffic Type” of its user data, as either:
a) ATN Operational Communications
b) ATN Administrative Communications
c) ATN Systems Management Communications.
For the ATN Operational Communications traffic type and the ATSC traffic category, routing
policy requirements shall be expressed through further information encoded into the Security Label, as either:
a) A preferred ATSC Class, or
b) no routing policy preference.
For the ATN Operational Communications traffic type and the AOC traffic category, routing
policy requirements shall be expressed through further information encoded into the Security Label, as eitherno routing policy preference, or an ordered list of appropriate Air/Ground subnetworks to be used.
Applications Use of ATN Security Labels
ATN Data Link applications shall specify an ATN Security Label for each message category
that they support. This ATN Security Label shall identify:
a) the Traffic Type appropriate for the message; and,
b) for ATN Operational Communications applications, the application*s requirements
for the routing of the message
When sent using the connection-mode transport service, a message shall only be conveyed over a transport connection which is associated with the same ATN Security Label as that specified for the message*s message category.
When sent using the connectionless-mode transport service, the TSDU conveying that message shall be associated with the ATN Security Label of the specified message category.
Transport Layer Security
In the Connection Mode
Except when a transport connection is used to convey general communications data, each
transport connection shall be associated with a single ATN Security Label.
The value of this label shall be determined when the connection is initiated.
Every NSDU passed to the Network Layer that contains a TPDU from a transport connection
associated with an ATN Security Label shall be associated with the same ATN Security Label.
TPDUs from transport connections associated with different ATN Security Labels shall not
be concatenated into the same NSDU.
When an incoming CR TPDU is received, the ATN Security Label, if any, encoded into the
header of the NPDU that conveyed it, shall define the ATN Security Label that is associated with the transport connection.
In the Connectionless Mode
In the connectionless mode, unless used to convey General Communications data, each
incoming or outgoing TSDU shall be associated with an ATN Security Label.
For outgoing TSDUs, this ATN Security Label shall be encoded into the header of the
resulting NPDU(s).
For incoming TSDUs, the associated ATN Security Label shall be the ATN Security Label
that was encoded into the header of the incoming NPDU(s) that contained the TSDU.
Network Layer Security
Service Provider to the Transport Layer
The Network Service shall provide a mechanism that permits an ATN Security Label to be
associated with an NSDU:
a) When passed from the Transport Layer to the Network Layer in an NSUNITDATA.
request. This ATN Security Label shall be encoded into the header of the corresponding CLNP NPDU(s)
b) When passed from the Network Layer to the Transport Layer in an
NS-UNITDATA.indication. This ATN Security Label shall be that received in the
header of the associated CLNP NPDU(s).
Routing Control
When present in an NPDU header, the network layer routing functions shall ensure that:
a) The Routing Policy requirements, if any, encoded into the ATN Security Label are
obeyed, and
b) The NPDU is only routed over paths through the internetwork which both permit and
are suitable for data of the traffic type identified by the ATN Security Label.
Note 1.— 5.3.2.2 specifies the forwarding procedures that ensure the above.
Note 2.— The Security Information conveyed in ISO/IEC 10747 (IDRP) routes is used to provide
the forwarding process with the information needed to support the above.
Protection of the Routing Information Base
IDRP type 1 Authentication, as specified in ISO/IEC 10747, shall be used as a mechanism
for ensuring the integrity of routing information exchange by IDRP.
Note.— A later extension to support type 2 authentication will enable the routing information base
to be protected from attackers that try to modify routing information while in transit, or which attempt tomasquerade as genuine ATN Routers.
Subnetwork Provisions
Note.— There are no requirements for security mechanisms in ATN Subnetworks. However,
Administrations and other Organisations implementing ATN subnetworks are encouraged to ensure the
general security and availability of ATN subnetworks through the use of physical security mechanisms.
ATN Use of Priority
Note 1.— The purpose of priority is to signal the relative importance and/or precedence of data,
such that when a decision has to be made as to which data to action first, or when contention for access to
shared resources has to be resolved, the decision or outcome can be determined unambiguously and in line
with user requirements both within and between applications.
Note 2.— In the ATN, priority is signalled separately by the application in the transport layer and
network layer, and in ATN subnetworks. In each case, the semantics and use of priority may differ.
Figure 5.2-2 illustrates where priority is applied in the ATN, and where it is necessary to map the semantics and syntax of ATN priorities.
Note 3.— In the ATN Internet, priority has the essential role of ensuring 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.
Application Priority
Note.— Priority in ATN Application Protocols is used to distinguish the relative importance and urgency of application messages within the context of that application alone.
For the purpose of
a) distinguishing the relative importance and urgency of messages exchanged by
different ATN Applications, and
b) distinguishing the relative importance and urgency of messages of the same
application during their transit through the ATN,
application messages shall be grouped into one or more categories listed in Table 1.2-2 .
Note.— An ATN Application may include messages from more than one category.
When a message is sent between ATN Application Entities, the message shall be sent using
either:
a) a transport connection established using the Transport Connection Priority listed in
Table 1.2-2 for the message*s message category, or
b) the connectionless transport service, signalling the Connectionless Transport Service
Priority listed in Table 1.2-2 for the message*s message category.
Note.— The priority of an individual transport connection cannot be changed during the lifetime of
the connection. Therefore, if an application exchanges messages belonging to more than one message
category using the connection mode transport service, then a separate transport connection needs to be
established for each message category.
Transport Connection Priority
Note 1.— Transport connection priority is concerned with the relationship between transport
connections and determines the relative importance of a transport connection with respect to (a) the order in which TCs are to have their QoS degraded, if necessary, and (b) the order in which TCs are to be broken in order to recover resources.
Note 2.— The transport connection priority is specified by the transport user either explicitly or implicitly, when the transport connection is established.
When an ATN Transport Layer entity is unable to satisfy a request for a transport connection
from either a local or remote TSAP, and which is due to insufficient local resources available to the transport layer entity, then it shall terminate a lower priority transport connection, if any, in order to permit the establishment of a new higher priority transport connection.
Note.— Implementations may also use transport connection priority to arbitrate access to other resources (e.g. buffers). For example, this may be achieved by flow control applied to local users, by discarding received but unacknowledged TPDUs, by reducing credit windows, etc.
All TPDUs sent by an ATN Transport Layer Entity shall be transferred by the ATN Internet
Layer, using the Network Protocol Priority that corresponds to the transport connection*s priority
Connectionless Transport Service Priority
Note.— There are no procedures required of the ATN Connectionless Transport Entity in respect
of priority, except for mapping the TSDU priority supplied by the service user (i.e. an ATN Application), to the corresponding Network Layer Priority, and vice versa.
All UD TPDUs sent by an ATN Transport Layer Entity shall be transferred by the ATN
Internet Layer using the Network Protocol Priority that corresponds to the TSDU priority provided by the service user according to Table 1.2-2.
ATN Internet Priority
Note.— In the ATN Internet Layer, an NPDU of a higher priority is given preferred access to
resources. During periods of higher network utilisation, higher priority NPDUs may therefore be expected to be more likely to reach their destination (i.e. are less likely to be discarded by a congested router) and to have a lower transit delay (i.e. be more likely to be selected for transmission from an outgoing queue) than are lower priority packets.
ATN Internet Entities shall maintain their queues of outgoing NPDUs in strict priority order,
such that a higher priority NPDU in an outgoing queue will always be selected for transmission in preference to a lower priority NPDU.
Note.— Priority zero is the lowest priority.
During periods of congestion, or when any other need arises to discard NPDUs currently held by an ATN Internet Entity, lower priority NPDUs shall always be discarded before higher priority NPDUs.
Note.— In addition to NPDUs containing user (i.e. transport layer) data, the Internet Layer also
forwards routing information contained in CLNP Data PDUs (e.g. IDRP) and as distinct NPDUs (e.g. ESIS).
These must all be handled at the highest priority if changes to network topology are to be quickly
actioned and the optimal service provided to users.
BISPDUs exchanged by IDRP shall be considered as Network/Systems Management category
messages, and shall be sent using CLNP priority 14.
ES-IS (ISO/IEC 9542) PDUs shall be implicitly assumed to have priority 14 and shall be
forwarded as if they were CLNP PDUs of priority 14.
Note.— The priority encoded in an ISH PDU conveys the priority of the sending system, and not the
priority of the PDU.
ATN Subnetwork Priority
Connection-Mode Subnetworks
Note 1.— In a connection-mode ATN subnetwork, priority is used to distinguish the relative
importance of different data streams (i.e. the data on a subnetwork connection), with respect to gaining access to communications resources and to maintaining the requested Quality of Service.
Note 2.— On some subnetworks (e.g. public data networks), not all data streams will be carrying ATN messages. Therefore, subnetwork priority is also used to distinguish ATN and non-ATN data streams.
Note 3.— So as not to incur the overhead and cost of maintaining too many simultaneous
subnetwork connections, NPDUs of a range of Network Layer priorities may be sent over the same
subnetwork connection.
When an ATN connection mode subnetwork does not support prioritisation of subnetwork
connections, then the ATN Internet Entity shall not attempt to specify a subnetwork connection priority, and NPDUs of any priority may be sent over the same subnetwork connection.
When an ATN connection mode subnetwork does support prioritisation of subnetwork
connections, then unless the relationship between ATN Internet Priority and subnetwork priority is explicitly specified by the subnetwork specification, the following shall apply:
a) Subnetwork connections shall be established as either “High” or “Low” priority
connections.
b) For the “Low” priority connection type, the priority to gain a connection, keep a
connection and for data on the connection shall be the defaults for routine use of the
subnetwork.
c) “High” priority connections shall be used to convey NPDUs of priority ten and above.
“Low” priority connections shall be used to convey all other NPDUs.
Note.— The above does not apply to the AMSS Subnetwork, which has specified its own priority mapping scheme.
When a subnetwork connection is established between two ATN Internet Entities and no other subnetwork connection between these two entities exists over any subnetwork, then that subnetwork connection shall always be established at a priority suitable for conveying NPDUs of priority 14 (i.e. Network/Systems Management).
Note.— This is to ensure that routing information can be exchanged at the appropriate priority.
Connectionless-Mode Subnetworks
When an NPDU is sent over a connectionless-mode ATN Subnetwork which supports data
prioritisation, then the subnetwork priority assigned to the transmitted packet shall be that specified by the subnetwork provider as corresponding to the NPDU priority.
ATN Routing
This chapter provides requirements and recommendations pertaining to the deployment of
ATN components within the ATN Internet; use of routing information distributed according to ISO/IEC
10747 in order to support policy based and Mobile routing in the ATN; and the Route Initiation procedures
for initiating the exchange of routing information using the ISO/IEC 10747 protocol. In the case of
Air/Ground data links, route initiation also includes the use of the ISO/IEC 9542 protocol. This chapter is
not concerned with compliancy with the ISO/IEC 10747 and ISO/IEC 9542 protocols.
A route shall only be advertised by an ATN Router to an adjacent ATN RD when it can be
ensured that data sent over that route by the RD to which the route is advertised is acceptable to every RD and RDC in the route's path, and will be relayed by them to the route's destination.
Note.— The acceptability of a route may be determined using a priori knowledge derived from
interconnection agreements with other RDs.
Forwarding CLNP NPDUs
General
The forwarding processes for a CLNP NDPU shall operate by selecting the FIB identified by
the combination of the QoS Maintenance and Security Parameters found in the CLNP Header, and selecting from that FIB, the entry, if any, identified by the longest matching NSAP Address Prefix.
The next hop information found in this FIB entry shall then be used to forward the NPDU.
Note.— Forwarding decisions that take into account the CLNP QoS Maintenance Parameter are a local matter and an ATN Router may hence ignore this parameter.
Forwarding a CLNP NPDU when no Security Parameter is present in the PDU Header
Note.— This case applies for General Communications data (see 5.2.7.1).
When a CLNP NPDU is received by an ATN Router and that NPDU does not contain a
Security Parameter in the PDU Header then that NPDU shall be forwarded over the selected route to the NPDU’s destination with the longest matching NSAP Address Prefix and which, either:
1) contains a security path attribute comprising the ATN Security Registration
Identifier and security information that does not contain an ATSC Class
Security Tag indicating support for only ATSC traffic, and comprises:
a) either an Air/Ground Subnetwork Security Tag that has “General
Communications” in its set of permissible Traffic Types, or
b) no Air/Ground Subnetwork Security Tag,
or
2) does not contain any security path attribute.
If no such route can be found then the NPDU shall be discarded.
Forwarding a CLNP NPDU when a Security Parameter is present in the PDU Header
General
When a CLNP NPDU is received by an ATN Router and that NPDU contains a Security
Parameter in the Globally Unique Format, and encodes security related information under
the ATN Security Registration Identifier, then the NPDU shall be forwarded according to the procedures specified below.
Note 1.— The CLNP NPDU Header Security Parameter is used to indicate the Traffic Type of the application data contained in the NPDU, and the application*s routing policy requirements.
Note 2.— The procedures for handling an NPDU with any other format of Security Parameter, or with any other Security Registration Identifier are outside the scope of this specification.
ATN Operational Communications Traffic Type - ATSC Traffic Category
Note.— In this case, either no Traffic Type policy preference may be specified, or an ATSC Class may be specified.
No Traffic Type Policy Preference
Note.— This case corresponds to a Traffic Type and Associated Routing Policy Security Tag value of 000 00001.
If the NPDU contains a CLNP NPDU Header Security Parameter in the globally unique
format, and encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and a traffic category of Air
Traffic Service Communications, and
c) no Traffic Type Policy Preference,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. An Air/Ground Subnetwork Security Tag that has “ATN Operational Communications - Air
Traffic Services Communications” in its set of permissible Traffic Types, or
ii. no Air/Ground Subnetwork Security Tag,
and an ATSC Class Security Tag indicating support of the lowest class out of all such routes available.
Note 1.— This requirement always takes precedence over selection based on ATSC
Class i.e. a route with a longer matching NSAP Address Prefix with a higher ATSC Class is always preferred over a route with a lower ATSC Class but with a shorter NSAP Address Prefix. This is essential for the
avoidance of routing loops.
Note 2.— ATSC Class “H” is the lowest and Class “A” is the highest.
If no such route can be found, then the NPDU shall be discarded.
ATSC Class Specified
Note.— This case corresponds to Traffic Type and Associated Routing Policy Security Tag values 000 10000 to 000 10111 inclusive.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and Air Traffic Service
Communications traffic category, and
c) a requirement to route the NPDU over a route of a specified ATSC Class,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. An Air/Ground Subnetwork Security Tag that has “ATN Operational Communications - Air Traffic Services Communications” in its set of permissible Traffic Types, or
ii. no Air/Ground Subnetwork Security Tag
and an ATSC Class Security Tag indicating:
I. support of the required class, or a higher class, or
II. if no such route is available then, the route with the highest ATSC Class available is
chosen.
Note 1.— This requirement always takes precedence over selection based on ATSC
Class i.e. a route with a longer matching NSAP Address Prefix with a higher ATSC Class is always preferred Internet communications service V-31
ICAO ATNP Version 2.3 - Editors’ Draft
over a route with a lower ATSC Class but with a shorter NSAP Address Prefix. This is essential for the avoidance of routing loops.
Note 2.— ATSC Class “H” is the lowest and Class “A” is the highest.
If no such route can be found then the NPDU shall be discarded.
If multiple routes are available which meet or exceed the required ATSC Class, then the route with the lowest relative cost shall be selected.
ATN Operational Communications Traffic Type - AOC Traffic Category
Note.— In this case, either no routing policy may be specified, or an Air/Ground Subnetwork type
may be specified, or an Air/Ground subnetwork order of preference may be specified.
No Traffic Type Policy Preference
Note.— This case corresponds to a Traffic Type and Associated Routing Policy Security Tag value of 001 00001.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and Aeronautical Operational
Control traffic category, and
c) no Traffic Type Policy Preference,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. an Air/Ground Subnetwork Security Tag that has “ATN Operational
Communications - Aeronautical Operational Control” in its set of permissible Traffic
Types, or
ii. no Air/Ground Subnetwork Security Tag;
and which does not contain an ATSC Class Security Tag indicating support for only ATSC traffic.
If no such route can be found, then the NPDU shall be discarded.
Air/Ground Subnetwork Type Specified
Note 1.— This case corresponds to Traffic Type and Associated Routing Policy Security Tag values 001 00010 through to 001 00110 inclusive.
Note 2.— The Air/Ground Subnetworks that may be specified are: Gatelink, VDL, AMSS, HF and Mode S.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and Aeronautical Operational
Control traffic category, and
c) a requirement to route traffic only via a specific Air/Ground Subnetwork only,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises either
i. an Air/Ground Subnetwork Security Tag that indicates that the route passes over that
Air/Ground Subnetwork and has “ATN Operational Communications —
Aeronautical Operational Control” in its set of permissible Traffic Types, or,
ii. no Air/Ground Subnetwork Security Tag,
and which does not contain an ATSC Class Security Tag indicating support for only ATSC traffic.
If no such route can be found, then the NPDU shall be discarded.
Air/Ground Subnetwork Order of Preference Specified
Note 1.— This case corresponds to Traffic Type and Associated Routing Policy Security Tag values 001 00111 through to 001 01001 inclusive.
Note 2.— The Air/Ground Subnetworks for which an order of preference may be specified are:
Gatelink, VDL, AMSS, HF and Mode S.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Operational Communications and Aeronautical Operational
Control traffic category, and
c) a requirement to route traffic only via certain Air/Ground Subnetworks and with a
specified order of preference,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. an Air/Ground Subnetwork Security Tag that indicates that the route passes over the
first preference Air/Ground Subnetwork and has “ATN Operational Communications
- Aeronautical Operational Control” in its set of permissible Traffic Types, if present,
or
ii. an Air/Ground Subnetwork Security Tag that indicates that the route passes over the
second preference Air/Ground Subnetwork and has “ATN Operational
Communications - Aeronautical Operational Control” in its set of permissible Traffic
Types, if present, and so on until a suitable route is found or no further preferences
are specified, or
iii. no Air/Ground Subnetwork Security Tag,
and which does not contain an ATSC Class Security Tag indicating support for only ATSC traffic.
If no such route can be found, then the NPDU shall be discarded.
If after applying the above procedures, a more specific route is available to the NPDU*s
destination, but
1) the route has an Air/Ground Subnetwork Security Tag that indicates that the
route passes over a lower preference Air/Ground Subnetwork while
2) having “ATN Operational Communications - Aeronautical Operational
Control” in its set of permissible Traffic Types, then
3) the more specific route shall be selected in preference to the less specific
route.
Note.— The purpose of this requirement is to ensure that the NPDU is not forced to visit a default
route provider only to find that a higher preference route does not actually exist to the NPDU*s destination.
ATN Administrative Communications Traffic Type
Note.— This case corresponds to a Traffic Type and Associated Routing Policy Security Tag value of 001 10000.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Administrative Communications,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which contains a security path attribute comprising the ATN Security Registration Identifier and security information that comprises:
i. either an Air/Ground Subnetwork Security Tag that has “ATN Administrative
Communications” in its set of permissible Traffic Types, or
ii. no Air/Ground Subnetwork Security Tag
and which does not contain an ATSC Class Security Tag indicating support for only ATSC traffic.
If no such route can be found, then the NPDU shall be discarded.
ATN Systems Management Communications Traffic Type
Note.— This case corresponds to a Traffic Type and Associated Routing Policy Security Tag value of 011 00000.
If the NPDU contains a CLNP Header Security Parameter in the globally unique format, and
encodes:
a) security related information according to 5.6.2.2 under the ATN Security Registration
Identifier, and
b) a traffic type of ATN Systems Management Communications,
then the NPDU shall be forwarded over the selected route to the NPDU*s destination with the longest matching NSAP Address Prefix, and which:
1) contains a security path attribute comprising the ATN Security Registration
Identifier and security information that comprises:
a) either an Air/Ground Subnetwork Security Tag that has “ATN Systems
Management Communications” in its set of permissible Traffic Types, or
b) no Air/Ground Subnetwork Security Tag,
or
2) contains no security path attribute.
5.3.2.2.3.5.2 If no such route can be found, then the NPDU shall be discarded.
Ground/Ground Interconnection
Interconnection Scenarios
Note 1.— Ground/Ground interconnection procedures apply to the interconnection of two
Ground/Ground Routers, and to the interconnection of an Air/Ground Router and a Ground/Ground Router.
Note 2.— Formally, these procedures only apply to interconnection between ATN Routers in different
Administrative Domains. However, in practice, they are also applicable to interconnection scenarios within
the same Administrative Domain.
Ground/Ground Route Initiation
Note.— Route Initiation is defined to be the point at which routing information exchange can begin,
and the route initiation procedures are those that permit the exchange of routing information to commence.
When the network administrators agree to the ground/ground interconnection of one or more ATN Routers within their respective Administrative Domains, they shall:
a) Make available suitable subnetwork connectivity including, where necessary the
physical installation of suitable communications equipment for end-to-end
communications between the ATN Routers, and supporting the Quality of Service
necessary for the applications data that will be routed over this interconnection.
Note.— The choice of appropriate subnetwork(s) to support the interconnection is a matter for
bilateral agreement between network administrators, including agreement on responsibility for installation,
operating and maintenance costs, and fault management.
b) Using global or local Systems Management mechanisms, establish one or more
subnetwork connections between the two ATN Routers, unless the subnetwork
technology is connectionless in which case this step may be omitted.
Note 1.— Typically (e.g. with X.25), one ATN Router will be placed in a state where it will accept
an incoming connection from the other ATN Router, and then the other ATN Router is stimulated to initiate
one or more subnetwork connection(s) to the other ATN Router.
Note 2.— Multiple concurrent subnetwork connections over the same or different subnetworks may
be required in order to meet throughput and other QoS requirements.
c) Using global or local Systems Management mechanisms, ensure that the forwarding
information base in each ATN Router, used to support the connectionless network
protocol specified in 5.6, contains sufficient information to forward CLNP NPDUs
addressed to the NET of the other ATN Router, over the newly established
subnetwork connection(s).
Note.— This step is necessary to ensure that the connectionless network service can be used to
exchange the BISPDUs of IDRP.
d) Using global or local Systems Management mechanisms, append the NET of the
remote ATN Router to the externalBISNeighbor attribute of the BIS*s idrpConfig
MO,
e) Using global or local Systems Management mechanisms, create an AdjacentBIS
Managed Object (MO) in each ATN Router to represent the other ATN Router, and
f) Using global or local Systems Management mechanisms, invoke the start event action
on each such MO, in order to initiate a BIS-BIS connection between the two ATN
Routers.
Note.— As a matter for the bilateral agreement of the network administrators, either (a) both ATN Routers will attempt to open the BIS-BIS connection, or (b) one and only one acts as the BIS-BIS connectioninitiator.
Ground/Ground Routing Information Exchange
Routing information shall be exchanged using the ISO/IEC 10747 Inter-Domain Routing
Protocol according to the profile specified in 5.8.
In support of Air/Ground communications, the exchange of routing information shall be subject to appropriate routing policies specified in 5.3.7.1, 5.3.7.3, or 5.3.7.4, depending upon the role of the Routing Domain in which each ATN Router is located.
Ground/Ground Route Termination
Note 1.— Route Termination is defined to be the point at which routing information ceases to be exchanged between two ATN Routers, and, in consequence, the routes made available over the adjacency cease to be useable and must be withdrawn. The route termination procedures are those procedures which
terminate the exchange of routing information.
Note 2.— Route Termination may result from a failure in the underlying subnetwork(s) causing a loss of communication between the two ATN Routers. Alternatively, it may result from a deliberate decision of network administrators to terminate the interconnection, either temporarily or permanently.
Note 3.— No special recovery procedures are specified if route termination is due to a network fault.
Once the fault has been repaired, the procedures of 5.3.4.2 may be re-invoked, as appropriate to re-establish
communication, and to exchange routing information.
When a network administrator decides to temporarily or permanently terminate an interconnection between two ATN Routers then, using global or local Systems Management mechanisms applied to either or both of the two ATN Routers, the deactivate action shall be invoked on the AdjacentBIS
MO that represents the remote ATN Router with which the BIS-BIS connection is to be terminated.
If the adjacency is to be permanently terminated, then the AdjacentBIS MO shall also be
deleted, and the forwarding information base shall be updated to remove the route to the NET of the remote ATN Router.
For either temporary or permanent termination, and if required, by using global or local
Systems Management mechanisms, the network administrator(s) shall also terminate the underlying subnetwork connections.
5.3.6 Handling Routing Information
5.3.6.1 All ATN Routers in the same RD shall implement the same routing policy.
Note 1.— As specified in 5.8, an ATN Router supports both the empty (default) RIB_Att, and the RIB_Att comprising the Security Path Attribute identifying the ATN Security Registration Identifier. An ATN Router therefore includes two RIBs known as the default RIB and the Security RIB, each of which comprises a Loc-RIB, and an Adj-RIB-In and an Adj-RIB-Out for each adjacent BIS.
Note 2.— Each ATN RD will necessarily have a distinct routing policy that depends on its nature, and the nature of the RDs to which it is interconnected. Section 5.3.7 specifies the baseline Routing Policy for each class of RD identified in 5.2.2.2 to 5.2.2.5 inclusive. ATN RDs may then extend the specified baseline to match their actual requirements.
Note 3.— Each Routing Policy is expressed as a set of policy statements or rules.
Note 4.— These baseline policy statements given below are always subject to the ISO/IEC 10747 requirement that routes are only advertised when the DIST_LIST_INCL and DIST_LIST_EXCL path attributes, if present, permit the route to be so advertised. Routes may never be advertised to an RD or RDC which the route has already traversed.
Policy Based Selection of Routes for Advertisement to Adjacent RDs
Note.— In general, the selection of routes for advertisement to adjacent Routing Domains is
performed according to local routing policy rules. This specification mandates such routing policy rules for support of Air/Ground routing only. Routing Policy rules for support of Ground/Ground routing are a local matter.
5.3.7.1 Routing Policy Requirements for Members of an ATN Island Backbone RDC
5.3.7.1.1 General
5.3.7.1.1.1 An ATN RD that is a member of an ATN Island Backbone RDC shall implement a Routing Policy that is compatible with the policy statements given in this section and its subordinate sections.
5.3.7.1.2 Adjacent ATN RDs within the Backbone RDC
Note.— These policy statements apply to the routes advertised by an ATN Router in an RD that is a member of an ATN Island Backbone RDC, to an adjacent ATN Router in a different RD, which is also a member of the same ATN Island Backbone RDC.
5.3.7.1.2.1 Each ATN Router that is in an RD that is a member of an ATN Island Backbone RDC shall provide the following routes to each adjacent ATN RD within the same ATN Island Backbone RDC, and for the Security RIB-Att:
a) A route to NSAPs and NETs contained within the RD; the route's destination shall
be one or more NSAP Address prefixes common to all NSAP Addresses and NETs
in the RD. If restrictions on distribution scope are applied by local routing policy,
then they shall not prevent distribution of this route to any member of the same ATN
Island Backbone RDC.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may also be present. For
example, to restrict the scope of the information to members of the ATN Island Backbone RDC only. The RDIs of other RDs and RDCs may also be present at the discretion of the local Administrative Domain, and by bilateral agreement.
Note 2.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all its neighbours within the backbone RDC about itself.
b) The selected route to every Mobile RD for which a route is available.
Note.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will inform all other Backbone RDC members within the island about all mobiles that it has available.
c) The selected route to every Fixed ATN RD in the same ATN Island, for which a
route is available.
Note.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will
tell other members of the same Backbone RDC about all fixed RDs that it knows about.
d) Each selected route to a Mobile RD's “home”.
Note 1.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all other members of the same Backbone RDC about all the “homes” that it knows about.
Note 2.— Such a route can be characterised by an NSAP Address Prefix which ends at the ADM field.
e) A route to each “Home” that the ATN TRD itself provides for Mobile RDs. This
route has as its destination, the common NSAP Address Prefix(es) for those mobile
RDs. The Security Path attribute shall contain an ATSC Class Security Tag
indicating support for both ATSC and non-ATSC traffic, and for all ATSC classes
supported for Air/Ground data interchange, if any.
Note.— The objective of this item is to ensure that all RDs in the ATN Island Backbone RDC are aware that the identified “Homes” are located here.
All other ATN RDs within the ATN Island
Note.— These policy statements apply to the routes advertised by an ATN Router in an RD that is a member of an ATN Island Backbone RDC to an adjacent ATN Router in a different RD, which is also a member of the same ATN Island RDC, but which is not a member of that ATN Island Backbone RDC.
An ATN Router that is in an RD that is a member of an ATN Island Backbone RDC shall provide the following routes to each adjacent ATN RD within the ATN Island RDC, which is not a member of the ATN Island*s Backbone RDC, and for the Security RIB-Att :
a) A route to NSAPs and NETs contained within the RD; the route's destination shall
be one or more NSAP Address prefixes common to all NSAP Addresses and NETs
in the RD. If restrictions on distribution scope are applied by local routing policy,
then they shall not prevent distribution of this route to any member of the same ATN
Island RDC.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may also be present. For
example, to restrict the scope of the information to members of the ATN Island only. The RDIs of other RDs and RDCs may also be present at the discretion of the local Administrative Domain, and by bilateral agreement.
Note 2.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all RDs within the island about itself.
b) The selected route to every Fixed ATN RD in the same ATN Island for which a route
is available.
Note.— The objective of this rule is to ensure that an ATN Router located in an RD that is a member of an ATN Island Backbone RDC, will tell all RDs within the island about all the fixed RDs it knows about.
c) A route to all AINSC Mobiles and all ATSC Mobiles. The well known discretionary
attribute DIST_LIST_INCL shall be present, and shall contain the RDI of the ATN
Island RDC as its value. The Security Path attribute shall contain an ATSC Class
Security Tag indicating support for both ATSC and non-ATSC traffic, and for all
ATSC classes supported for Air/Ground data interchange, if any.
Note 1.— The objective of this rule is to tell the rest of the island that each RD in the ATN Island Backbone RDC provides a default route to all aircraft.
Note 2.— The distribution scope of the route is limited because the ATN Island defines the domain of the default route provider. This route is invalid outside of the local ATN Island.
Note 3.— This route is formally the result of aggregating all the routes to Mobile Systems and routes to “Home” RDs, known to the ATN Router.
d) A route to each Mobile RD for which the adjacent RD is advertising a route to the
Mobile RD's “home”.
Note.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all adjacent off Backbone RDs about all routes to Mobile RDs which have “home” routes advertised.
Mobile RDs
Note.— These policy statements apply to the routes advertised by an ATN Router in an RD that is a member of an ATN Island Backbone RDC to an adjacent ATN Router in a Mobile RD.
When IDRP is being used to exchange routing information with an Airborne Router, an ATN
Router in an RD that is a member of an ATN Island Backbone RDC shall provide to each adjacent Mobile RD a route to NSAPs and NETs contained within the local RD for the Security RIB-Att; the route's destination shall be one or more NSAP Address prefixes common to all NSAP Addresses and NETs in the local RD.
Note.— The objective of this rule is to ensure that an RD that is a member of an ATN Island
Backbone RDC will tell all adjacent Mobiles about itself.
An ATN RD that is a member of an ATN Island Backbone RDC should also provide to each adjacent Mobile RD, and for the Security RIB-Att and for which a suitable route exists:
a) An aggregated route to NSAPs and NETs contained within the local ATN Island
RDC;
Note.— The objective of this rule is to ensure that an RD that is a member of an ATN Island
Backbone RDC provides to each connected Mobile RD, a route to all fixed ATN RDs within the island.
b) An aggregated route to NSAPs and NETs contained within all other ATN Islands
for which a route is available.
Note.— The objective of this rule is to ensure that an RD that is a member of an ATN Island
Backbone RDC will provide to each connected Mobile RD routing information to the backbone of other ATN islands
.
ATN RDs in other ATN Islands
Note.— These policy statements apply to the routes advertised by an ATN Router in an RD that is a member of an ATN Island Backbone RDC to an adjacent ATN Router in a different RD, which is a member of a different ATN Island's ATN Island Backbone RDC.
An ATN Router in an RD that is a member of an ATN Island Backbone RDC shall provide
the following routes to each adjacent ATN Router that is a member of a Backbone RDC in another ATN Island, and or the Security RIB-Att:
a) An aggregated route to NSAPs and NETs contained within the ATN Island RDC.
Note.— The objective of this rule is to ensure that an RD that is a member of an ATN Island
Backbone RDC will tell all adjacent RDs that are members of ATN Island Backbone RDCs in different ATN Islands about the local ATN Island.
b) Each selected route to a Mobile RD’s “home”.
c) A route to each “Home” that the ATN TRD itself provides for Mobile RDs. This
route has as its destination, the common NSAP Address Prefix(es) for those Mobile
RDs. The Security Path attribute shall contain an ATSC Class Security Tag
indicating support for both ATSC and non-ATSC traffic, and for all ATSC classes
supported for Air/Ground data interchange, if any.
Note 1.— The objective of this rule is to ensure that an ATN Island Backbone RD will tell all
adjacent RDs that are member of an ATN Island Backbone RD in different ATN Islands about routes to Mobiles whose “home” is in the local island.
Note 2.— The “home” identified above needs not correspond to a geographical notion of a home.
Note 3.— The “home” is typically identified by an NSAP Address Prefix that identifies all the RD's belonging to the organisation responsible for the Mobile RD (i.e. aircraft), or all the Mobile RDs belonging
to the organisation. The former is only possible if all such Fixed RDs are part of the same ATN Island RDC.
d) A known route to each Mobile RD for which the adjacent RD is advertising a route
to the Mobile RD's “home”.
Note.— The objective of this rule is to ensure that a member of an ATN Island Backbone RDC will tell all adjacent RDs in different islands about all routes to Mobile RDs which have “home” routes
advertised.
Routing Policy Requirements for a Mobile RD
When IDRP is being used to exchange routing information with an Airborne Router, a Mobile RD shall provide to each ATN RD to which it is currently connected, a route to NSAPs and NETs contained within the Mobile RD for the Security RIB-Att.
The objective of this rule is to ensure that a Mobile RD will tell adjacent RDs about itself.
This policy statement applies to the routes advertised by an ATN Router in a Mobile RD
to an adjacent ATN Air/Ground Router in a Fixed ATN RD.
Routing Policy Requirements for an ATN TRD that is not a Member of the ATN Island
Backbone RDC
General
An RD that is a member of an ATN Island RDC, and is a TRD, but which is not a member
of that ATN Island's Backbone RDC shall implement a Routing Policy that is compatible with the policy statements given in this section and its subordinate sections.
Note.— An ATN RD that operates as a transit routing domain is referred to in this chapter as an ATN TRD.
Adjacent ATN RDs that are Members of the ATN Island*s Backbone RDC
Note.— These policy statements apply to the routes advertised by an ATN Router in an ATN TRDto an adjacent ATN Router in an RD which is a member of the local ATN Island's Backbone RDC.
When an ATN TRD that is not itself a member of an ATN Island Backbone RDC is adjacent
to an RD that is a member of an ATN Island Backbone RDC, then it shall provide the following routes to each such adjacent ATN RD, and for the Security RIB-Att:
a) A route to NSAPs and NETs contained within the RD; the route's destination shall
be one or more NSAP Address prefixes common to all NSAP Addresses and NETs
in the RD.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may also be present. For
example, to restrict the scope of the information to members of the ATN Island only. The RDIs of other RDs
and RDCs may also be present at the discretion of the local Administrative Domain, and by bilateral agreement.
Note 2.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of an ATN Island Backbone RDC, will tell all adjacent ATN RDs which are members of an ATN Island BackboneRDC within the same ATN Island about itself.
b) The selected route to every Mobile RD for which a route is available.
Note.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of an ATNIsland Backbone RDC, will tell all adjacent ATN RDs which are members of an ATN Island Backbone RDC within the same ATN Island about all Mobiles it knows about.
c) The selected route to every Fixed ATN RD in the ATN Island for which a route is
available.
Note.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of an ATN
Island Backbone RDC, will tell all adjacent ATN RDs which are members of an ATN Island Backbone RDC
within the same ATN Island about all fixed RDs it knows about in the same ATN Island.
d) A route to each “Home” that the ATN TRD itself provides for Mobile RDs. This
route shall have as its destination, the common NSAP Address Prefix(es) for those
Mobile RDs. The Security Path attribute shall contain an ATSC Class Security Tag
indicating support for both ATSC and non-ATSC traffic, and for all ATSC classes
supported for Air/Ground data interchange.
Note.— The objective of this rule is to support the operation of the Home Domain concept on any ATN TRD directly connected to an ATN Island Backbone RD.
Adjacent ATN RDs within the same ATN Island and which are not Members of the ATN
Island*s Backbone RDC
Note.— These policy statements apply to the routes advertised by an ATN Router in an ATN TRD to an adjacent ATN Router in an ATN RD on the same ATN Island.
An ATN TRD shall provide the following routes to each adjacent ATN RD within the ATN
Island RDC, other than ATN RDs which are members of the ATN Island Backbone RDC, and for the Security RIB-Att:
a) A route to NSAPs and NETs contained within the RD for the Security RIB-Att; the
route's destination shall be one or more NSAP Address prefixes common to all NSAP
Addresses and NETs in the RD.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may also be present. For
example, to restrict the scope of the information to members of the ATN Island only. The RDIs of other RDs and RDCs may also be present at the discretion of the local Administrative Domain, and by bilateral agreement, including the RDI of the ATN Island Backbone RD or RDC, when the adjacent RD is providing the local RD's route to the ATN Island Backbone.
Note 2.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of the ATN Island Backbone RDC, will tell all adjacent RDs within the island about itself.
b) The selected route to every Fixed RD in the same ATN Island for which a route is
available.
Note.— The objective of this rule is to ensure that an ATN TRD that is not itself a member of theATN Island Backbone RDC, will tell all adjacent RDs within the island about all fixed ATN RDs in the same ATN Island that it knows about.
c) If the RD is currently advertising the preferred route to all AINSC and ATSC
Mobiles, then every route to an AINSC Mobile and an ATSC Mobile that is known
to the local RD shall be advertised to this RD, subject only to constraints imposed by
any DIST_LIST_INCL and DIST_LIST_EXCL path attributes.
Note.— The objective of this rule is to ensure that the provider of the default route to all aircraft (i.e.the Backbone) is kept informed of the actual location of every aircraft adjacent to the Island.
d) The preferred route to all Mobiles, except when the RD is the source of this route.
Note.— The objective of this rule is to ensure propagation of the default route to all Mobiles
throughout the ATN Island.
e) A route to each Mobile RD for which the adjacent RD is advertising the preferred
route to the Mobile RD's “home”.
Note.— The objective of this rule is to ensure routes to Mobile RDs are propagated to off Backbone Homes.
f) A route to each “Home” that the ATN TRD itself provides for Mobile RDs. This
route has as its destination, the common NSAP Address Prefix(es) for those Mobile
RDs. The Security Path attribute shall contain an ATSC Class Security Tag
indicating support for both ATSC and non-ATSC traffic, and for all ATSC classes
supported for Air/Ground data interchange, if any.
Note.— The objective of this item is to ensure that all RDs in the ATN Island are aware that the identified “Homes” are located here.
Mobile RDs
Note.— These policy statements apply to the routes advertised by an ATN Router in an ATN TRD to an adjacent ATN Router in a Mobile RD.
When IDRP is being used to exchange routing information with the airborne router, an ATN TRD shall provide to each adjacent Mobile RD a route to NSAPs and NETs contained within the RD for the Security RIB-Att; the route's destination shall be one or more NSAP Address prefixes common to all NSAP
Addresses and NETs in the RD.
Note.— The objective of this rule is to ensure that an ATN TRD will tell adjacent Mobile RDs about itself.
Recommendation.— An ATN TRD should also provide to each adjacent Mobile RD, and
for the Security RIB-Att and for which a suitable route exists:
a) an aggregated route to NSAPs and NETs contained within the local ATN Island
RDC;
b) an aggregated route to NSAPs and NETs contained within all other ATN Islands
for which a route is available.
Note.— The objective of this rule is to encourage an RD to provide to each adjacent Mobile RD routing information about: a) all fixed RDs within the island, and b) other ATN islands.
The Routing Policy for a Fixed ATN ERD
Fixed ATN ERD shall provide to each ATN RD to which it is currently connected, a route
to NSAPs and NETs contained within the RD, for the Security RIB-Att.
Note 1.— The well known discretionary attribute DIST_LIST_INCL may be present, unless the RD permits routes to destinations within itself to be advertised by other ATN RDs without restriction to any other ATN RD, or non-ATN RD.
Note 2.— This policy statement applies to the routes advertised by an ATN Router in a fixed ATN ERD to an adjacent ATN Router in an ATN RD.
Note 3.— An ERD does not advertise routes to destinations in any other RD, to another RD.
5.4 NETWORK AND TRANSPORT ADDRESSING SPECIFICATION
5.4.1 Introduction
Note 1.— The ATN Internet Addressing Plan defines an OSI Network Service Access Point (NSAP) address structure which can support efficient internet routing procedures, and which conforms to common abstract syntax, semantic and encoding rules throughout the ATN OSI environment.
Note 2.— This addressing plan also defines the format and use of TSAP Selectors to enable the unambiguous identification of Multiple Transport Service users within a single End System.
5.4.1.1 Addressing Plan Scope
5.4.1.1.1 The ATN Internet Addressing Plan shall be used by ATN End Systems and Intermediate Systems.
Note.— The ATN Internet Addressing Plan serves the needs of a variety of aeronautical data
communication user groups, including ATSC and AINSC users.
5.4.1.2 Addressing Plan Applicability
Note.— The ATN Internet Addressing Plan defines the Network and Transport Layer addressing information to be utilized by ATN End Systems, and by ATN Intermediate Systems.
5.4.1.3 Reserved Values in Address Fields
5.4.1.3.1 Address field values specified as “reserved” shall not be used until assigned by future versions of this specification.
5.4.1.4 Values of Character Format Fields
5.4.1.4.1 When the value of a field is defined as a character string, then the actual value of the field shall be derived from the IA-5 encoding of each character in the character string.
5.4.1.4.2 The IA-5 encoding of the first character in the string shall be taken as the value of the first octet of the field and so on until all octets in the field have been given a value.
5.4.1.4.3 If the length of the character string is smaller than the number of octets in the field, then the character string shall be right padded with the space character.
5.4.1.4.4 The most significant bit of each octet shall be set to zero.
Note.— For example, the character string ‘EUR’ would be encoded as 455552 hexadecimal, in a three octet field.
5.4.2 Transport Layer Addressing
5.4.2.1 General
Note 1.— This section provides requirements on the format of ATN TSAP addresses. An ATN TSAP address is an NSAP address and a TSAP selector.
Note 2.— The requirements in this section apply to the administration of transport addresses local to an ATN End System. They do not apply to all systems in a global OSI Environment. An ATN System may allow remote transport addresses to obey different standards, e.g. when interworking with a non-ATN system is required.
5.4.2.2 ATN TSAP Selector
5.4.2.2.1 An ATN TSAP selector shall be either one or two octets in length.
5.4.2.2.2 The TSAP Selector field shall be administered on a local basis.
5.4.2.2.3 Valid ATN TSAP Selector field values shall be in the range 0 to 65535.
5.4.2.2.4 The TSAP Selector field shall be encoded as an unsigned binary number.
5.4.2.2.5 If the TSAP Selector needs to be encoded in more than one octet, then the number shall be encoded with the most significant octet first.
Note.— This follows the encoding rules specified in ISO/IEC 8073.
5.4.2.2.6 Recommendation.— TSAP selector values in the range 0 to 255 should be encoded using one octet, higher values should be encoded using two octets
5.4.3 Network Layer Addressing
5.4.3.1 NSAP Addresses and Network Entity Titles (NETs)
Note 1.— The NSAP Address is formally defined in ISO/IEC 8348. It is the name of a Network
Service Access Point (NSAP) located in an End System, and uniquely identifies that NSAP. It is also an address that may be used to find that NSAP.
Note 2. — The Network Entity Title (NET) is also formally defined in ISO/IEC 8348 and is the name of a Network Entity located within an End or Intermediate System. NETs are syntactically identical to NSAP Addresses and are allocated from the same address space. An NET is also an address that may be used to find the Network Entity.
Note 3.— An NSAP Address Prefix is a substring of an NSAP Address or NET that is comprised of the first ‘n’ characters of the NSAP Address or NET.
5.4.3.2 Network Addressing Domains
Note 1.— A Network Addressing Domain comprises all NSAP Addresses and NETs with a common NSAP Address Prefix, and is always a sub-domain of the Global NSAP Addressing Domain which contains all NSAP Addresses. This nesting of network addressing domains within the Global Network Addressing Domain is conceptually illustrated in Figure 5.4-1.
Note 2.— A Network Addressing Domain has a single Administrator responsible for the assignment of NSAP Addresses and NSAP Address Prefixes within the domain. A Network Addressing Domain is often sub-divided into a number of sub-ordinate domains each characterised by a unique NSAP Address Prefix.
Management of such sub-ordinate Network Addressing Domains may then be devolved to another Administrator.
5.4.3.2.1 An ATSC Network Addressing Domain shall be a Network Addressing Domain administered by an ATSC authority.
5.4.3.2.2 An AINSC Network Addressing Domain shall be a Network Addressing Domain administered by a member of the Aeronautical Industry.
5.4.3.2.3 ATN End Systems or Intermediate Systems located on-board general aviation aircraft shall belong to an ATSC Network Addressing Domain, whereas ATN systems installed on-board commercial aircraft shall belong to an AINSC Network Addressing Domain.
5.4.3.3 The Syntax of an NSAP Address
Note 1.— Following ISO/IEC 10589, a Router interprets an NSAP Address as a three-fields bit
string. This is illustrated in Figure 5.4-2 below.
Area Address System Identifier SEL
Note 2.— An Area Address is typically common to all NSAP Addresses and NETs assigned to
systems in a single Routing Area.
Note 3.— An Area Address is an example of an NSAP Address Prefix.
Note 4.— A System Identifier uniquely identifies an End or Intermediate System within a Routing
Area.
Note 5.— A Selector (SEL) identifies a Network Service User or the Network Entity within an End
or Intermediate System.
5.4.3.4 The ATN Addressing Plan
Note 1.— ISO/IEC 8348 has specified how the Global Network Addressing Domain is broken down into a number of sub-ordinate Network Addressing Domains, each of which is identified by a uniqueidentifier that forms the initial part of all NSAP Addresses and NETs in those sub-ordinate domains. This initial part is known as the Initial Domain Part (IDP). The IDP itself is defined as comprising two parts: anAuthority Format Identifier (AFI) and an Initial Domain Identifier (IDI). The AFI identifies the format and
allocation procedures for the IDI and the format of the remainder of the NSAP Address.
Note 2.— The ATN Network Addressing Domain is such a sub-ordinate Network Addressing Domainand has an IDP that uses an ISO 6523-ICD IDI.
Note 3.— The IDP is always expressed as decimal digits. However, ISO/IEC 8348 permits NSAPAddresses in an ISO 6523-ICD domain to have either a binary or a decimal format for the remainder of the address - the Domain Specific Part (DSP). The format of the DSP is determined by the AFI.
5.4.3.4.1 All ATN NSAP Addresses shall have an AFI with the value 47 decimal.
Note.— This AFI value is defined by ISO/IEC 8348 to imply an ISO 6523-ICD IDI with a binary
format DSP.
5.4.3.4.2 All ATN NSAP Addresses shall have an IDI value of 0027 decimal.
Note.— This value has been allocated by ISO to ICAO under the ISO 6523-ICD scheme. An IDP of 470027 therefore forms the common NSAP Address Prefix to all ATN NSAP Addresses and effectively defines the ATN Network Addressing Domain, as a sub-domain of the Global Network Addressing Domain.
5.4.3.5 The Reference Publication Format
Note.— The Reference Publication Format is defined by ISO/IEC 8348 for the publication of NSAP Addresses and NETs in a form suitable for text documents.
5.4.3.5.1 Recommendation.— For the purposes of publication in a text format, ATN NSAP Addresses and NETs should be written as the character sequence “470027+”, identifying the common prefix for all ATN NSAP Addresses, followed by the DSP expressed as a sequence of hexadecimal characters.
Note.— The “+” sign is used as a separator between the decimal syntax IDP and the hexadecimal syntax DSP.
5.4.3.5.2 Each successive pair of hexadecimal digits shall correspond to the next binary octet of the DSP.
5.4.3.6 The ATN NSAP Address Format
Note 1.— The derivation of the ATN NSAP Address Format is illustrated in Figure 5.4-3. This starts with the AFI and IDI fields required by ISO/IEC 8348. It ends with the System ID (SYS) and SEL fields required by ISO/IEC 10589. The remaining DSP fields are specified below and used to co-ordinate the allocation of ATN NSAP Addresses.
Note 2.— The VER field is used to partition the ATN Addressing Domain into a number of
sub-ordinate addressing domains, each of which provides a different approach to address management.
Note 3.— The ADM field is then used to break down each such partition into a number of
sub-ordinate addressing domains, each of which may then be managed by a different manager.
Note 4.— In Fixed Network Addressing Domains, the ARS field may then be used to identify a
Network Addressing Domain that will correspond to each Routing Domain under the control of each such manager, and the LOC field may then be used to identify each Routing Area within each Routing Domain.
Note 5.— In Mobile Network Addressing Domains, the ARS field identifies an aircraft. Where all ATN systems onboard an aircraft form a single Routing Domain, the ARS field also identifies the Addressing Domain that will correspond to that Routing Domain, and the LOC field is used as above. However, when the ATN systems onboard a single aircraft form more than one Routing Domain, then part of the LOC field is also used to identify such an Addressing Domain.
Note 6.— The reason for the existence of the RDF field is historical.
5.4.3.7 NSAP Address Encoding
Note 1.— In ISO/IEC 8348 terms, the IDP has an abstract decimal syntax, and the DSP has an
abstract binary syntax. The reason for the use of the word abstract is to emphasise the fact that the actual encoding is outside of the scope of ISO/IEC 8348, and instead is the responsibility of the standards that specify the encoding of network layer protocols.
Note 2.— ISO/IEC 8348 does, however, describe two possible encoding schemes, the “preferred binary encoding” and the “preferred decimal encoding”. ISO/IEC 8473 mandates the use of the preferred binary encoding for CLNP, while ISO/IEC 10747 mandates a modified version of the preferred binary encoding in order to cope with bit aligned NSAP Address Prefixes.
Note 3.— In consequence, this specification only specifies how each field of the DSP is allocated as an unsigned binary number. The actual encoding of the resulting bitstring in an NPDU is then according to the applicable protocol specification.
5.4.3.8 Allocation of the DSP
Note.— The DSP fields of an ATN NSAP Address are the VER, ADM, RDF, ARS, LOC, SYS and SEL fields. The size of each of these fields is given in Table 5.4-1.
5.4.3.8.1 The Version (VER) Field
Note 1.— The purpose of the VER field is to partition the ATN Network Addressing Domain into a number of sub-ordinate Addressing Domains.
Note 2.— The values currently specified for the VER Field and the Network Addressing Domains so defined, are summarised in Table 5.4-2.
5.4.3.8.1.1 The VER Field shall be one octet in length.
5.4.3.8.1.2 A VER field value of [0000 0001] shall be used for all NSAP Addresses and NETs in the Network Addressing Domain that comprises all Fixed AINSC NSAP Addresses and NETs.
Note.— The NSAP Address Prefix “470027+01” is therefore the common NSAP Address Prefix for the Fixed AINSC Network Addressing Domain.
5.4.3.8.1.3 A VER field value of [0100 0001] shall be used for all NSAP Addresses and NETs in the Network Addressing Domain that comprises all Mobile AINSC NSAP Addresses and NETs.
Note.— The NSAP Address Prefix “470027+41” is therefore the common NSAP Address Prefix for the Mobile AINSC Network Addressing Domain.
Address Field
Name
Address Field Size
VER 1 Octet
ADM 3 Octets
RDF 1 Octet
ARS 3 Octets
LOC 2 Octets
SYS 6 Octets
SEL 1 Octet
Table 5.4-1 DSP NSAP Address Field Sizes
5.4.3.8.1.4 A VER field value of [1000 0001] shall be used for all NSAP Addresses and NETs in the Network Addressing Domain that comprises all Fixed ATSC NSAP Addresses and NETs.
Note.— The NSAP Address Prefix “470027+81” is therefore the common NSAP Address Prefix forthe Fixed ATSC Network Addressing Domain.
5.4.3.8.1.5 A VER field value of [1100 0001] shall be used for all NSAP Addresses and NETs in the Network Addressing Domain that comprises all Mobile ATSC NSAP Addresses and NETs.
Note.— The NSAP Address Prefix “470027+C1” is therefore the common NSAP Address Prefix forthe Mobile ATSC Network Addressing Domain.
5.4.3.8.1.6 All other VER field values shall be reserved.
VER Field Value Network Addressing Domain Common NSAP
Address Prefix for Domain
[0000 0001] Fixed AINSC 470027+01
[0100 0001] Mobile AINSC 470027+41
[1000 0001] Fixed ATSC 470027+81
[1100 0001] Mobile ATSC 470027+C1
Table 5.4-2 VER Field Assigned Values
Internet communications service V-73
ICAO ATNP Version 2.3 - Editors’ Draft
5.4.3.8.2 The Administration (ADM) Field
5.4.3.8.2.1 General
Note.— The purpose of the ADM field is to sub-divide each of the Network Addressing Domains introduced by the VER field into a further set of sub-ordinate Network Addressing Domains, and to permit devolved administration (i.e. address allocation) of each resulting domain to an individual State or Organisation.
5.4.3.8.2.1.1 The ADM field shall be three octets in length.
5.4.3.8.2.2 Fixed AINSC NSAP Addresses and NETs
Note.— In the Fixed AINSC Network Addressing Domain, the ADM field is used to sub-divide this Addressing Domain into a number of sub-ordinate Network Addressing Domains, each of which comprises NSAP Addresses and NETs for fixed systems operated by a single AINSC Organisation.
5.4.3.8.2.2.1 Allocation of NSAP Addresses and NETs in each such Network Addressing Domain subordinate to the Fixed AINSC Network Addressing Domain shall be the responsibility of the organisation identified by the value of the ADM field.
5.4.3.8.2.2.2 Recommendation.— The field value should be derived from the set of three-character alphanumeric symbols representing an IATA Airline or Aeronautical Stakeholder Designator, according to 5.4.1.4.
Note.— AINSC Organisations are intended to register their ADM values with IATA.
5.4.3.8.2.3 Fixed ATSC NSAP Addresses and NETs
Note.— In the Fixed ATSC Network Addressing Domain, the ADM field is used to sub-divide this Addressing Domain into a number of sub-ordinate Network Addressing Domains, each of which comprises NSAP Addresses and NETs for fixed systems operated by a single State or within an ICAO Region.
5.4.3.8.2.3.1 Allocation of NSAP Addresses and NETs in each such Network Addressing Domain subordinate to the Fixed ATSC Network Addressing Domain shall be the responsibility of the State or ICAO Region identified by the value of the ADM field.
5.4.3.8.2.3.2 When used for identifying a State, the ADM field shall be derived from the State’s three-character alphanumeric ISO 3166 Country Code, represented as upper case characters.
5.4.3.8.2.3.3 In this case, the value of the field shall be determined according to 5.4.1.4.
Note.— For example, the encoding of ‘GBR’ is 474252 in hexadecimal. Therefore the NSAP Address Prefix 470027+81474252 is the common NSAP Address Prefix for all NSAP Addresses and NETs in the UK Fixed ATSC Network Addressing Domain.
5.4.3.8.2.3.4 When used to identify an ICAO Region, the first octet of the ADM field shall identify the ICAO Region, according to Table 5.4-3, while the values of the remaining two octets shall be assigned by the identified ICAO Region.
Note 1.— The ISO 3166 character codes are always represented as binary octets, each of which has a zero most significant bit. Therefore, it is possible to guarantee that the field values listed in Table 5.4-3 do not conflict with ISO 3166 derived State Identifiers.
ADM Field First Octet ICAO Region
[1000 0000] Africa
[1000 0001] Asia
[1000 0010] Caribbean
[1000 0011] Europe
[1000 0100] Middle East
[1000 0101] North America
[1000 0110] North Atlantic
[1000 0111] Pacific
[1000 1000] South America
Table 5.4-3 ICAO Region Identifiers
Note 2.— This Addressing Plan enables ICAO Regions to allocate ADM field values in the Fixed ATSC Network Addressing Domain to States and Organisations within the ICAO Region, in a structured manner. This is in order to permit the efficient advertisement of routing information. For example, in the advertisement of routes to ‘all RDs in the same ATN Island’ as recommended in 5.3.7.1.4.2.
5.4.3.8.2.3.5 All ADM field values in the Fixed ATSC Network Addressing Domain that do not correspond to valid ISO 3166 Country Codes or which are not assigned to ICAO Regions shall be reserved.
5.4.3.8.2.4 Mobile NSAP Addresses and NETs
Note.— In both the Mobile AINSC and the Mobile ATSC Network Addressing Domains, the ADM field is used to sub-divide this Addressing Domain into a number of sub-ordinate Network Addressing
Domains, each of which comprises NSAP Addresses and NETs for mobile systems operated by a single Airline or onboard the General Aviation aircraft of a single State.
5.4.3.8.2.4.1 For Mobile AINSC NSAP Address and NETs, the ADM field value shall be set according to 5.4.3.8.2.2, and the corresponding sub-ordinate Network Addressing Domain administered by the organisation identified by the value of the ADM field.
5.4.3.8.2.4.2 For Mobile ATSC NSAP Address and NETs, the ADM field value shall be set according to 5.4.3.8.2.3, and the corresponding sub-ordinate Network Addressing Domain administered by the State identified by the value of the ADM field.
5.4.3.8.3 The Routing Domain Format (RDF) Field
Note 1.— There is no absolute requirement for the remainder of the DSP in each of the above defined Network Addressing Domains to be allocated according to a co-ordinated addressing plan, or for even the same fields to exist, or the NSAP Addresses to have the same length. However, in order to encourage common equipment development, this specification specifies the existence, size and use of the RDF, ARS and LOC fields.
Note 2.— The reason for the existence of the RDF field is historical.
5.4.3.8.3.1 The RDF field shall be one octet in length and its value shall be [0000 0000] in binary.
5.4.3.8.3.2 All other values shall be reserved.
5.4.3.8.4 The Administrative Region Selector (ARS) Field
Note 1.— In Fixed Network Addressing Domains, the purpose of the ARS field is to distinguish
Routing Domains operated by the same State or Organisation.
Note 2.— In Mobile Network Addressing Domain, the purpose of the ARS field is to identify the aircraft on which the addressed system is located. When the systems onboard an aircraft form a single Routing Domain, then the ARS field also identifies the Routing Domain. When the systems onboard an aircraft form multiple RDs, then part of the LOC field is used to distinguish them.
5.4.3.8.4.1 The ARS field shall be three octets in length.
5.4.3.8.4.2 In the Fixed AINSC and ATSC Network Addressing Domains, the value of the ARS field shall be a 24-bit unsigned binary number that uniquely identifies the NSAP Addresses and NETs assigned to systems in a single Routing Domain.
5.4.3.8.4.3 In the Fixed AINSC and ATSC Network Addressing Domains, the State or Organisation identified by the value of the ADM field shall be responsible for assigning the ARS field.
Note 1.— For example, 470027+8147425200000000 and 470027+8147425200000001 are therefore NSAP Address Prefixes common to all NSAP Addresses and NETs assigned to fixed systems in two distinct
Routing Domains operated by the UK ATSC authority.
Note 2.— Where necessary, the allocation of NSAP Addresses and NETs may thus readily be
delegated to a Network Administrator responsible for each Network Addressing Domain that corresponds to each Routing Domain.
5.4.3.8.4.4 In Mobile AINSC and ATSC Network Addressing Domains, the value of the ARS field shall be the 24-bit ICAO Aircraft Identifier that uniquely identifies the NSAP Addresses and NETs in a single Routing Domain.
Note 1.— If the aircraft is operated by an IATA Airline then the NSAP Address or NET is in a MobileAINSC Network Addressing Domain.
Note 2.— For General Aviation Aircraft, the NSAP Address or NET is in a Mobile ATSC Network Addressing Domain.
5.4.3.8.5 The Location (LOC) Field
Note 1.— In Fixed Network Addressing Domains, the purpose of the LOC field is to distinguish
Routing Areas within the same Routing Domain.
Note 2.— In Mobile Network Addressing Domains, the LOC field is used
a) to distinguish Routing Areas within the same Mobile Routing Domain, or,
b) when more than one Routing Domain is located on a single Aircraft, to distinguish
each Routing Domain and the Routing Areas contained within them.
Note 3.— For example, the first octet of the LOC field may be used to distinguish each Routing Domain on board a single aircraft, and the second octet to distinguish each Routing Area.
Note 4.— The combination of AFI, IDI, VER, ADM, RDF, ARS and LOC fields therefore forms an
Area Address.
5.4.3.8.5.1 The LOC field shall be two octets in length and may be given any binary value.
5.4.3.8.5.2 The administrator of the Network Addressing Domain that co-incides with the Routing Domain in which a given Routing Area is located, shall be responsible for the allocation of a LOC field value that provides a unique Area Address for that Routing Area.
Note.— For example, 470027+81474252000000010045 is an Area Address in a Routing Domainoperated by the UK ATSC Administration.
5.4.3.8.6 The System Identifier (SYS) Field
Note.— ISO/IEC 10589 defines the System Identifier as a variable length field which uniquely
identifies an End or Intermediate System within a ISO/IEC 10589 Routing Area. Within a Routing Area, all System Identifiers are of the same length, although a Router is not able to make assumptions about the length of this field outside of its own Routing Area. However, the ATN Addressing Plan does specify this field toalways be six octets in length in order to encourage a common equipment base.
5.4.3.8.6.1 In an ATN NSAP Address or NET, the System Identifier (SYS field) shall be six octets in length.
5.4.3.8.6.2 The value of the SYS field shall be a unique binary number assigned by the addressing authority responsible for the Network Addressing Domain that corresponds with the Routing Area in which the identified system is located.
Note.— If the System is attached to an IEEE 802 Local Area Network (e.g. an Ethernet), then a common approach is to use the 48-bit LAN address as the value of the SYS field.
5.4.3.8.7 The NSAP Selector (SEL) Field
Note.— The NSAP Selector (SEL) field identifies the End System or Intermediate System network entity or network service user process responsible for originating or receiving Network Service Data Units (NSDUs).
5.4.3.8.7.1 The SEL field shall be one octet in length.
5.4.3.8.7.2 The SEL field value for an Intermediate System network entity shall be [0000 0000], except for the case of an airborne Intermediate System implementing the procedures for the optional non-use of IDRP.
5.4.3.8.7.3 In the case of an airborne Intermediate System implementing the procedures for the optional non-use of IDRP, the SEL field value shall be [1111 1110].
5.4.3.8.7.4 The SEL field value [1111 1111] shall be reserved.
Note 1.— In an Intermediate System, any other SEL field value may be assigned to NSAPs. The actual value chosen is a local matter.
Note 2.— SEL field values in stand-alone End Systems (i.e. in End Systems not co-located with
Intermediate Systems) are not constrained.
5.4.3.8.7.5 SEL field values other than those defined for Intermediate System Network Entities in 5.4.3.8.7.2 and 5.4.3.8.7.3 above or being reserved, shall be assigned by the addressing authority responsible for the identified End or Intermediate System.
5.4.3.9 Pre-Defined NSAP Address Prefixes
5.4.3.9.1 All AINSC Mobiles
5.4.3.9.1.1 The NSAP Address Prefix 470027+41 shall provide a common NSAP Address Prefix for all AINSC Mobiles.
5.4.3.9.2 All ATSC Mobiles
5.4.3.9.2.1 The NSAP Address Prefix 470027+C1 shall provide a common NSAP Address Prefix for all ATSC Mobiles.
Note.— The NLRI for the Default Route to all Mobiles comprises both the NSAP Address Prefixes defined above.
5.4.3.9.3 All Aircraft Belonging to an Airline
5.4.3.9.3.1 The NSAP Address Prefix 470027+41 plus the value of the ADM field assigned to the airline shall provide a common NSAP Address Prefix for all AINSC Mobiles operated by a single airline.
Note.— The NLRI for the Route to the “Home” for the aircraft belonging to a given airline contains this NSAP Address Prefix.
5.4.3.9.4 All General Aviation and Other Types of Aircraft Registered by a State
5.4.3.9.4.1 The NSAP Address Prefix 470027+C1 plus the value of the ADM field assigned to the State shall provide a common NSAP Address Prefix for all ATSC Mobiles registered by a single State.
Note.— The NLRI for the Route to the “Home” for the General Aviation and other types of aircraft registered by a single State contains this NSAP Address Prefix.
5.5 TRANSPORT SERVICE AND PROTOCOL SPECIFICATION
5.5.1 General
5.5.1.1 Overview
5.5.1.1.1 The COTP (Connection Oriented Transport Protocol ) shall be used to provide an end-to-end reliable data transfer service between Transport Service users on two ATN End Systems.
5.5.1.1.2 In ATN End Systems, the implementation of the COTP shall conform to ISO/IEC 8073 and the mandatory requirements given in this Chapter.
5.5.1.1.3 The CLTP (Connectionless Mode Transport Protocol) shall be used to provide a
Connectionless data transfer service between Transport Service users on two ATN End Systems.
5.5.1.1.4 In ATN End Systems, the implementation of the CLTP shall conform to ISO/IEC 8602 and the mandatory requirements given in this chapter.
Note.— The transport protocols specified for use in ATN End Systems provide both Connection Mode and Connectionless Mode communication services. The implementation and use of a particular mode
of the Transport Layer service depends on the requirements of the application(s) supported by a given ATN End System.
5.5.1.2 Transport Service Description
Note 1.— When the TS-user requires use of the connection mode transport service the TS-user will provide the following information to the TS-provider on a per Transport Connection basis:
a) called and calling TSAP address;
b) whether or not the expedited data option is required;
c) the required residual error rate (RER) to determine whether use or non-use of the
transport checksum is allowed;
d) the Application Service Priority to be mapped into the resulting CLNP NPDUs
according to Table 1.2-2;
e) the ATN Security Label specifying the ATN Traffic Type, i.e.
C ATN Operational Communications;
C ATN Administrative Communications;
C General Communications;
C ATN Systems Management Communications.
V-80 Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN)
ICAO ATNP Version 2.3 - Editors’ Draft
Note 2.— In the case where the Traffic Type specified is ATN Operational Communications theTS-user will additionally provide the traffic category, i.e. Air Traffic Services Communications (ATSC) orAeronautical Operational Control (AOC).
Note 3.— In the case of the ATSC traffic category the TS-user will further specify the required ATSC
Class as defined in Table 1.2-1, or no traffic type policy preference.
Note 4.— In the case of the AOC traffic category the TS-user will further specify the subnetwork preference (including no preference).
Note 5.— The ATN Traffic Types and their associated traffic categories are specified in Table 5.6-1.
The encoding of the ATN Security Label is specified in Figure 5.6-1 and 5.6.2.2.2.2 bullet b).
Note 6.— The TS-user is not required to specify any other Transport Service Quality of Service
parameters.
5.5.1.3 Transport Service Access Point Addresses
5.5.1.3.1 A TSAP address shall comprise two elements, a NSAP address and a TSAP selector.
5.5.1.3.2 The NSAP address and the TSAP selector shall conform to the provisions in 5.4.
5.5.1.4 Exchange of Transport-Selector parameters
Note.— TSAP Selectors are transmitted in Calling and Called Transport-Selector parameters in COTP, and in Source and Destination Transport-Selector parameters in CLTP.
5.5.1.4.1 The transport entity shall support Transport-Selector parameters to accommodate the ATN TSAP selector syntax and encoding requirements as specified in 5.4.
5.5.1.4.2 Recommendation.— The transport entity should support remote Transport-Selector parameters of variable size from 0 up to 32 octets using any encoding and any value.
Note.— The absence of a Calling and Called Transport-Selector assumes the Network Address alone unambiguously defines the Transport Address.
5.5.1.4.3 In COTP, on receipt of CR (Connection Request) TPDU, the absence of a Calling or Called Transport-Selector shall be treated as equivalent to a zero length Calling or Called Transport-Selector.
5.5.1.4.4 The absence of a Calling or Called Transport-Selector in a received CC (Connection Confirm)
TPDU shall indicate that Calling or Called Transport-Selector is equivalent to the corresponding parameter
specified in the sent CR TPDU.
5.5.1.4.5 When present in a received CC TPDU, Calling and Called Transport-Selector parameters shall be identical in length and value to the corresponding parameter specified in the sent CR TPDU.
5.5.1.4.6 In CLTP, on receipt of UD (User Data) TPDU, the absence of a Source or Destination
Transport-Selector shall be treated as equivalent to a zero length Source or Destination Transport-Selector.
5.5.2 Connection Mode Transport Layer Operation
5.5.2.1 Connection Mode Transport Service Primitives
Note 1.— For the purpose of describing the notional interfaces between different OSI protocol layers, each protocol layer is assumed to provide a service to the next higher protocol layer. The assumed service provided by the ATN transport layer to its user is described in ISO/IEC 8072.
Note 2.— ATN Applications may specify their use of the COTP implemented in ATN End Systems using the Transport Service specified in ISO/IEC 8072, including use of ATN priority, and security parameters as defined in this specification.
Note 3.— There is no requirement to implement the service specified in ISO/IEC 8072 as a software interface.
5.5.2.2 ATN Specific Requirements
5.5.2.2.1 ATN End Systems shall implement the ISO/IEC 8073 Class 4 transport protocol in order to provide Connection Mode communications over the ATN Internet.
5.5.2.2.2 The COTP shall operate using the CLNS (Connectionless Network Service) as specified in 5.6.
Note.— TPDUs (Transport Protocol Data Units) are sent via the N-UNITDATA Request primitive.
5.5.2.2.3 The transport entity shall not concatenate TPDUs from TCs with different transport priorities or different Security Labels.
5.5.2.2.4 Recommendation.— The Selective Acknowledgement mechanism should be used for conservation of bandwidth by preventing retransmission of correctly received out-of-sequence TPDUs.
5.5.2.2.5 Recommendation.— The Request of Acknowledgement mechanism should be used to reduce AK traffic.
5.5.2.2.6 Recommendation. — The maximum TPDU size should be at least 1024 octets.
Note.— This is to support efficient transmission of anticipated application data exchanges.
5.5.2.2.7 Recommendation.— The Transport Layer should propose a TPDU size of at least 1024 octets.
5.5.2.2.8 Recommendation.— The Transport Layer should use the TPDU size parameter rather than the preferred maximum TPDU size parameter.
5.5.2.2.9 Recommendation.— Implementations of the ATN Transport Layer should propose use of normal format in the CR TPDU.
5.5.2.2.10 Recommendation.— The Extended format should only be proposed when explicitly necessary to meet application Quality of Service requirements.
Note.— Because the increased TPDU size resulting from use of extended data TPDU numbering may be more inefficient, this option is used on a TC only when absolutely required.
5.5.2.2.11 Recommendation.— The Transport Layer should accept non-use of checksum whenproposed in a CR TPDU.
5.5.2.2.12 Implementations of the transport protocol shall support configurable values for all timers and protocol parameters, rather than having fixed values, in order to allow modification as operational experience is gained.
5.5.2.2.13 When intended for operation over Air/Ground subnetworks, transport protocol
implementations shall support the minimum - maximum ranges for COTP timer values as presented in Table 5.5-1.
5.5.2.2.13.1 Recommendation.— Nominal values indicated in Table 5.5-1 should be used.
5.5.2.2.13.2 Recommendation.— The assignment of optimized values for timers and parameters other than the nominal values indicated in Table 5.5-1 should be based on operational experience.
5.5.2.2.14 Recommendation.— When intended for operation exclusively over Ground/Ground subnetworks, implementations of transport protocol timer values should be optimized to ensure interoperability.
5.5.2.3 Connection Mode Transport Quality of Service
5.5.2.3.1 Connection Mode Transport Priority
5.5.2.3.1.1 The Transport Layer shall allow a TC (Transport Connection) priority in the range [0 - 14]
5.5.2.3.1.2 The Transport Layer shall not alter the proposed TC priority specified by the TS-user.
5.5.2.3.1.3 The Transport Layer shall treat all connections without expressed priority as being at the default TC priority.
5.5.2.3.1.4 The default TC priority shall be the lowest priority, i.e. priority [14].
5.5.2.3.1.5 When a TS-user specifies a TC priority, the relationship between this TC priority and the CLNP priority shall be as specified in Table 1.2-2.
5.5.2.3.2 Connection Mode Transport Security
Note.— The ATN security mechanism does not make use of the ISO/IEC 8073 Protection parameter.
The support of the Protection parameter is therefore optional.
Internet communications service V-85
5.5.2.3.2.1 The Transport Layer shall allow a TS-user to specify a Security Label for a transport connection. The transport security procedure shall be implemented as specified in 5.2.7.3.1.
5.5.2.3.2.2 The Security Label format shall be according to 5.2.7.1. The Transport Layer shall not alter the Security Label specified by the TS-user.
Note.—When no Security Label is present, a « General Communications » traffic type is implied.
In this case, CLNP NPDUs are generated without the Security parameter.
5.5.2.4 Encoding of Transport Protocol Data Units
5.5.2.4.1 General
5.5.2.4.1.1 The encoding of TPDUs shall conform to ISO/IEC 8073 for the COTP.
5.5.2.4.2 Encoding of the Acknowledgment Time Parameter
5.5.2.4.2.1 In ATN compliant systems, the acknowledgement time parameter of the CR and CC TPDUs
shall be encoded as follows:
Parameter
Code:
1000 0101
Note 1.— This is identical to the ISO/IEC 8073 standard
parameter.
Parameter
Length:
2 or 3 octets.
Parameter
Value:
Acknowledgment Timer (AL) value expressed in milliseconds (per
ISO/IEC 8073 standard)
Note 2.— This enhancement is in response to the unique requirements of the aeronautical
environment which may require longer acknowledgment times than foreseen in ISO/IEC 8073.
Note 3.— Initial values of these timers may depend upon the subnetwork, traffic type and routing policy requirements expressed in the associated ATN Security Label.
Note 4.— In cases where the AL value is expressed in 2 octets (less than 65536 milliseconds), the ATN implementation will behave in compliance with the ISO/IEC 8073 standard.
Note 5.— Implementors are advised to permit systems administrators to readily specify initial values.
5.5.2.5 Transport Layer Congestion Avoidance
5.5.2.5.1 General
V-86 Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN)
ICAO ATNP Version 2.3 - Editors’ Draft
Note 1.— The congestion avoidance mechanisms in the Transport Layer make use of the notification by the Network Layer of Congestion Experienced flags in received NPDUs. This mechanism allows transport entities to reduce the window, i.e. the number of DT TPDUs allowed to be sent without acknowledgement,
when the proportion of NPDUs indicating congestion reaches a certain threshold.
Note 2.— This congestion information consists of the total length of the sequence of NPDUs forming the associated NSDU, and the number of NPDUs of that sequence that had their congestion experienced flag set upon reception.
Note 3.— Transport Congestion Avoidance measures are applicable to the Connection Mode
transport service only.
5.5.2.5.1.1 The transport entity shall implement the congestion avoidance algorithm defined in this section.
5.5.2.5.1.2 This algorithm shall be applied for each transport connection individually.
5.5.2.5.2 Advertised Window
5.5.2.5.2.1 General
5.5.2.5.2.1.1 A receiving transport entity shall provide the sending transport entity with the lower window edge and the size of the advertised window (W) by using the explicit flow control mechanisms specified in ISO/IEC 8073.
Note.— The advertised window is the window advertised by the receiver of the data to the sender
of the data. It indicates the number of DT TPDUs that the receiver is willing to accept.
5.5.2.5.2.2 Initialisation of the Advertised Window
5.5.2.5.2.2.1 The initial value of the window W0 that is advertised to the sending transport entity shall have
a locally configurable value.
5.5.2.5.2.2.2 This initial window shall be sent to the sending transport entity in the first CDT field
transmitted.
5.5.2.5.3 Receiving Transport Entity Congestion Avoidance
5.5.2.5.3.1 General
5.5.2.5.3.1.1 Congestion avoidance shall be performed within repeated update phases.
5.5.2.5.3.1.2 Each update phase shall terminate with the possible advertisement of a new window size to
the sending transport entity.
Internet communications service V-87
ICAO ATNP Version 2.3 - Editors’ Draft
5.5.2.5.3.2 Start of Update Phase
5.5.2.5.3.2.1 An update phase of the advertised window shall start after the receiving transport entity has
advertised a new value of the window Wnew to the sending transport entity.
5.5.2.5.3.3 Ignoring Congestion Information
5.5.2.5.3.3.1 After having advertised a new window size, the receiving transport entity shall ignore
congestion information coming from the Network Layer, until it has received W (i.e. the « old » advertised
window size) further DT-TPDUs. It then shall enter the sampling sub-phase.
5.5.2.5.3.3.2 When the sending transport entity advertises the initial window size W0, it shall set W to 0.
5.5.2.5.3.4 Sampling Congestion Information
5.5.2.5.3.4.1 The receiving transport entity shall maintain a count N equal to the total number of NPDUs
that convey DT-TPDUs, and a count NC equal to the number of such NPDUs that had their congestion
experienced flag set upon reception.
5.5.2.5.3.4.2 Upon entering the sampling sub-phase, these counts shall be reset to zero.
5.5.2.5.3.4.3 These counts shall be updated upon receipt of a DT-TPDU using the congestion information
supplied by the Network Layer.
5.5.2.5.3.4.4 The sampling sub-phase shall end as soon as the transport entity has received Wnew DT-TPDUs
within the sampling sub-phase. The end of the sampling sub-phase also terminates the update phase.
5.5.2.5.3.5 Action Upon the End of the Update Phase
5.5.2.5.3.5.1 The receiving transport entity shall take the following actions at the end of each update phase:
a) If the count NC is less than 8 % of the count N, the receiving transport entity shall
increase the size of the advertised window by adding up to a maximum based on the
local buffer management policy. Otherwise, it shall decrease the size of the advertised
window by multiplying it by $. If the result of this multiplication has a decimal part,
the new window size shall be the truncated to its integer value. The size of the
advertised window shall not go to a value smaller than 1.
b) The counts N and NC shall be reset to 0.
c) The new window size shall be transmitted to the sending transport entity in
accordance with the explicit flow control mechanisms specified in ISO/IEC 8073.
Note.— This procedure does not explicitly require the reduction of the upper window edge, as it is possible to gradually reduce the credit window.
5.5.2.5.4 Recommended Algorithm Values
5.5.2.5.4.1 Recommendation.— The value settings defined in the following table should be implemented and configurable by a System Manager:
5.5.2.6 Use of the ATN Network Service
Note.— This section specifies how the COTP operates over the CLNS provided by the ATN Network Layer.
5.5.2.6.1 Use of the N-UNITDATA Request
5.5.2.6.1.1 General
5.5.2.6.1.1.1 The Transport Layer shall use the N-UNITDATA Request primitive, as defined in ISO/IEC 8073, to transmit TPDUs.
Note.— The way the parameters are exchanged between the transport entity and the Network Service is a local matter.
5.5.2.6.1.1.2 The length indication given to the network service shall be equal to the length of the TPDU(s).
Note.— The maximum size of each TPDU is restricted to the locally defined maximum NSDU size.
5.5.2.6.1.2 NS-user-data
Note.— Transport entities transmit TPDUs as NS-user-data of the N-UNITDATA Request primitive.
5.5.2.6.1.3 Network Service Access Point Addresses
Note.— The Transport Layer has knowledge of the source and destination address parameters only as octet strings.
5.5.2.6.1.4 Network Quality of Service
5.5.2.6.1.4.1 General
5.5.2.6.1.4.1.1 The COTP shall use the network QoS parameters as defined in the sections below.
5.5.2.6.1.4.2 Network Layer Priority
5.5.2.6.1.4.2.1 The COTP shall use the network priority parameter to indicate the relative priority of a NSDU.
5.5.2.6.1.4.2.2 When a transport priority has been specified, the value of network priority shall be determined based on the transport connection priority, as defined in Table 1.2-2.
5.5.2.6.1.4.2.3 If the Transport Layer supports levels of TC priority numerically greater than 14, TPDUs
associated with the TC shall be transmitted using a network priority level of zero.
Note.— As specified in ISO/IEC 8073, the Transport Layer priority level zero is highest. ISO/IEC 8473 specifies zero as the lowest network priority and fourteen as the highest. Table 1.2-2 defines the required mapping between these two schemes for use by ATN systems.
5.5.2.6.1.4.3 Network Layer Security
Note.— The use of the Network Layer security is specified in 5.2.7.3.1.
5.5.2.6.2 Use of the N-UNITDATA Indication
5.5.2.6.2.1 General
5.5.2.6.2.1.1 The Transport Layer shall be capable of receiving TPDUs from the ATN network service using the N-UNITDATA indication primitive, as defined in ISO/IEC 8073.
Note.— The way the parameters are exchanged between the transport entity and the Network Service is a local matter.
5.5.2.6.2.2 NS-user-data
Note.— Transport entities receive TPDUs as NS-user-data of the N-UNITDATA Indication primitive.
5.5.2.7 Connection Mode Transport APRL
5.5.2.7.1 Mandatory and Optional Functions
5.5.2.7.1.1 General
Note.— The requirements for the COTP are provided in the form of an ATN Protocol Requirements List (APRL). The APRL has been prepared using the PICS (Protocol Implementation Conformance Statement) proforma provided with ISO/IEC 8073.
5.5.2.7.1.1.1 An implementation of the ISO/IEC 8073 Transport Protocol shall be used in an ATN End System if and only if its PICS is in compliance with the APRL provided with these SARPs.
ATN3 Support of ATN Security Label? 5.5.2.6.1.4.3 M
ATN4 Configurable Transport Timers? 5.5.2.2.12 M
ATN5 Enhanced encoding of Acknowledgment Time
Parameter?
5.5.2.4.2 M
5.5.2.7.1.3 Initiator/Responder Capability for Protocol Classes 0-4
5.6 INTERNETWORK SERVICE AND PROTOCOL SPECIFICATION
5.6.1 Introduction
Note 1.— The ATN Internet comprises a number of interconnected ATN routers and constituent
subnetworks supporting data communication among host computers operating the ATN Internet protocols.
Note 2.— All ATN NPDUs (Network Protocol Data Units) are encapsulated within appropriate
subnetwork protocol data units for transfer among ATN network entities using the connectionless ISO OSI Network Layer service provided by the ATN Internet. As the ATN Internet protocol is connectionless, any information required to process a particular NPDU is carried within the header of that network protocol data unit for processing by ATN routers and host computers.
5.6.1.1 Scope
Note 1.— This chapter provides requirements and recommendations pertaining to the use of the
ISO/IEC 8473 by ATN End System and Intermediate System Network entities. This Chapter is concerned with the use of ISO/IEC 8473 in the context of the internetworking protocol approach to the provision of CLNS as defined in ISO/IEC 8348. This Chapter contains ATN-specific protocol implementations and is concerned with the interoperability of protocol implementations. It therefore provides appropriate compliance statements and APRLs for this purpose.
Note 2.— The ATN Network Layer Connectionless-Mode Network Service supports the transfer of
a connectionless network service data unit (NSDU) from a source NSAP to a destination NSAP within the ATN network. Each such NSDU transfer is the result of a single invocation of the connectionless-mode Network Service encompassed within the ATN.
5.6.1.2 Applicability of Requirements
5.6.1.2.1 All ATN Intermediate System and End System Network entities shall comply with the
provisions contained in 5.6.2 and 5.6.3, in addition to all APRLs specified in 5.6.4.
5.6.2 ATN Specific Features
5.6.2.1 Purpose of ATN Specific Features
Note 1.— The ATN infrastructure, referred to as an Internet, comprises the interconnection of
computers with gateways and routers via real subnetworks. This internetworking infrastructure, allows for the incorporation of differing Air/Ground and Ground/Ground subnetworks servicing differing user groups,
i.e., Air Traffic Services (ATS), Aeronautical Operational Control Services (AOC), and others.
Note 2.— The CLNP (Connectionless Network Protocol) protocol used to operate this
internetworking infrastructure is based on ISO/IEC 8473 with ATN-specific additions to reflect the unique communications environment of the ATN.
Note 3.— The ATN specific functions listed in this chapter reflect responses to the additional
functional needs of ATN Network entities in order to support user requirements concerned with:
a) Ensuring that information is conveyed about Traffic Type and Routing Policy
requirements pertaining to user data in NPDUs;
b) Ensuring that a priority scheme can be applied for management of End Systems and
Intermediate Systems output queues and buffers;
c) Ensuring that specific policies and procedures are available to handle congestion
avoidance and congestion control requirements within the ATN.
5.6.2.2 The Security Function
5.6.2.2.1 General
5.6.2.2.1.1 The SECURITY Function of ISO/IEC 8473, as defined in this specification, shall be
supported by ATN End System or Intermediate System Network entities receiving or transmitting inter-domain traffic other than Traffic Type as General Communications.
5.6.2.2.1.2 ATN Network entities shall therefore provide the Globally Unique Security format for all
created NPDUs.
5.6.2.2.1.3 The sole exception to this requirement is for General Communications traffic where no
Security parameter information is required to be encoded in created NPDUs.
5.6.2.2.2 Encoding of the Security Parameter
5.6.2.2.2.1 The CLNP Options Security Parameter shall be used in the ATN to convey information about the Traffic Type and Routing Policy Requirements pertaining to the user data of the NPDU (other than General Communications).
Note.— The CLNP Options Security Parameter may also be used to convey a security classification.
5.6.2.2.2.2 The value component of the CLNP Options Security Parameter (in the NPDU header) shall
be encoded as follows:
a) The first octet shall always be encoded as [1100 0000] to indicate the Globally
Unique Security Format;
b) The remaining octets shall contain the ATN Security Label encoded as the four fields
illustrated in Figure 5.6-1, and defined below.
Security Registration
ID Length
Security
Registration ID
(variable)
Security
Information Length
Security
Information
(optional)
Octet 0 1 n n+1
5.6.2.2.3 Security Registration ID Length
5.6.2.2.3.1 This field shall be one octet long and contain the length in octets of the Security Authority's
Security Registration Identifier.
Note.— The Security Registration ID identifies the authority that has specified the associated
security policy.
5.6.2.2.4 Security Registration ID
5.6.2.2.4.1 This field shall contain the following hexadecimal string which identifies the ATN Security
Registration ID:
[ 06 04 2b 1b 00 00 ]
Note.— The ATN Security Registration ID value defined above is the encoding useing ASN.1 Basic
Encoding Rules [ISO/IEC 8825-1] of the ATN Security Registration Identifier defined as {1 3 27 0 0}. This
ATN Security Registration Identifier identifies the ATN Security Authority as an object in the ICAO object
hierarchy. ICAO has been assigned an International Code Designator (ICD) decimal value [0027] in
accordance with the dictates of ISO/IEC 6523. According to ISO/IEC 6523 and ISO/IEC 8824 this value
identifies an arc of the identified organisation of ISO. ICAO object identifiers designate an ICAO defined
hierarchy starting with {1 3 27}. Under this arc, {0} has been designated as ATN, and the flat address space
under ATN starts with object identifiers {0,1,2,3,4, ...}. Value {0} has been assigned as the Traffic Type and
Routing Policy identifier.
5.6.2.2.5 Security Information Length
5.6.2.2.5.1 This field shall be one octet in length and shall define the length in octets of the Security
Information.
V-110 Manual of Technical Provisions for the Aeronautical Telecommunication Network (ATN)
ICAO ATNP Version 2.3 - Editors’ Draft
5.6.2.2.5.2 If there is no security information, this field shall be set to zero.
5.6.2.2.6 Security Information
5.6.2.2.6.1 General
5.6.2.2.6.1.1 When present, the Security Information field of the ATN Security Label shall be used to
convey, as separate Tag Sets:
a) The Traffic Type and Routing Policy Requirements, if any, applicable to the transfer
of the user data through the ATN.
b) The Security Classification
5.6.2.2.6.1.2 When no traffic type is identified then the General Communications traffic type shall be
assumed, with a routing policy requirement of “no preference”. When no security classification is specified then
“unclassified” shall be assumed.
5.6.2.2.6.2 Encoding of the Security Information Field
5.6.2.2.6.2.1 The Security Information Field shall comprise zero, one or more Security Tag Sets. A Security
Tag with the same Tag Set Name shall not occur more than once in the options Security Parameter of the CLNP NPDU.
Tag Set Name Length Tag Set Name Tag Set Length Security Tag
Octet 0 1 n n+1
Figure 5.6-2: Security Tag Set Format
5.6.2.2.6.2.2 Each Security Tag Set shall consist of four fields, as illustrated in Figure 5.6-2, and shall be as defined in the following sections.
Note.— This format has been chosen to provide for an extensible type-length-value encoding method
for security related information placed in the CLNP Header under rules specified by the ATN Security
Authority.
5.6.2.2.6.3 Security Tag Set Name Length
5.6.2.2.6.3.1 The Security Tag Set Name Length shall contain the length in octets of the Tag Set Name field.
5.6.2.2.6.4 Security Tag Set Name
5.6.2.2.6.4.1 The Security Tag Set Name shall be used to uniquely identify the Tag Set.
5.6.2.2.6.5 Tag Set Length
5.6.2.2.6.5.1 The Tag Set Length Field shall contain the length in octets of the Security Tag field.
5.6.2.2.6.6 Security Tag
5.6.2.2.6.6.1 The Security Tag field shall be used to convey security related information for which the
syntax and semantics are identified by the preceding Tag Set Name.
5.6.2.2.6.7 Encoding of the Tag Set for Traffic Type and Associated Routing Policies
5.6.2.2.6.7.1 The Tag Set Name shall be set to [0000 1111].
5.6.2.2.6.7.2 When present in the CLNP options Security Parameter, this Tag Set shall always be the first Tag Set to be encoded in the Security Information field of the ATN Security Label.
Note.— This Tag Set is used to identify the traffic type of the data, whether it is for ATC or Airline
communications, and, for Operational Communications, any Routing Policy requirements that apply.
5.6.2.2.6.7.3 The Security Tag shall indicate the Routing Policy Requirements for the data contained in the same NPDU, according to Table 5.6-1.
Note.— See 5.2.7 for detailed information on the ATN Security Policy.
5.6.2.2.6.8 Encoding of the Tag Set for Security Classification
5.6.2.2.6.8.1 The Tag Set Name shall be set to [0000 0011].
5.6.2.2.6.8.2 When present in the security parameter, this Tag Set shall always follow the Tag Set for
Traffic Type and Associated Routing Policies (see 5.6.2.2.6) if present, but otherwise shall be the first Tag Set to be encoded in the field.
Note.— The purpose of this field is to permit the later extension of the ATN to handle classified data.
5.6.2.3 Management of Network Priority
Note.— Network priority handling provisions are specified in 5.2.8.
5.6.2.4 Congestion Management
Note 1.— The congestion management provisions in the Network Layer are intended to guarantee
the notification to the Transport Layer of potential risks of congestion via the CE bit conveyed in the QoS Maintenance parameter of an ISO/IEC 8473 NPDU. 5.5.2.5 defines the measures that the Transport Layer implements upon receipt of NPDUs with the CE bit set.
Note 2.— The above requirement is applicable to all types of ISO/IEC 8473 NPDUs.
5.6.2.4.1 Setting of the congestion experienced flag
5.6.2.4.1.1 The congestion experienced flag (CE-flag) in the QoS maintenance parameter in the options part of an NPDU header shall initially be set to zero by the originator of the NPDU.
5.6.2.4.1.2 When a NPDU is being forwarded by an ATN Intermediate System, the Intermediate System shall examine the depth of the output queue selected for that NPDU.
5.6.2.4.1.3 If the depth of the selected output queue exceeds a threshold " (see Table 5.6-3), the ATN
Intermediate System shall set the CE-flag in the NPDU header.
Note.— The above assumes a single output queue per network (CLNP) priority. If mixed priority
queues are implemented, which is valid provided that priority order is always maintained, then the CE-flag is set only when the number of NPDUs on the queue of the same or a higher priority exceeds alpha.
5.6.2.4.1.4 Once the CE-flag is set, it shall not be reset by any ATN Intermediate System traversed by
the NPDU further along to the path towards the destination.
5.6.2.4.2 Forwarding congestion information to the receiving NS-User
5.6.2.4.2.1 For each sequence of NPDUs that together form an NSDU, the destination network entity shall keep two counters:
a) the first one, n-total, shall reflect the length of that sequence.
b) the second one, n-CE, shall reflect the number of those NPDUs of this sequence, that
had the CE-flag set on reception by the destination network entity.
Note.— Each NSDU is forwarded through the network as a sequence consisting of one or more
NPDUs.
5.6.2.4.2.2 When the destination network entity passes an NSDU to the receiving NS-User, it shall convey the associated counters n-total and n-CE to the NS-User.
Note.— The conveyance of the congestion information associated with an NSDU to the NS-User is
a local matter.
5.6.2.4.3 Required algorithm values
5.6.2.4.3.1 The value settings defined in the following table shall be implemented:
Table 5.6-3 Required Value for "
Name Description Required range
" Output queue threshold 1 packet
5.6.3 ATN Specific Requirements for ISO/IEC 8473
Note.— This section defines ATN specific requirements on the ISO/IEC 8473 Protocol.
5.6.3.1 Segmentation Function.
5.6.3.1.1 ATN Intermediate Systems (ISs) shall support both the segmenting and the non-segmenting
subsets of ISO/IEC 8473.
5.6.3.1.2 ATN End Systems shall support the ISO/IEC 8473 segmenting subset.
5.6.3.1.3 Recommendation. — ATN End Systems should use the non-segmenting ISO/IEC 8473 subset for NSDUs of up to 1024 octets.
5.6.3.2 Security Function
Note.— The ATN Specific use of the ISO/IEC 8473 Security Function is specified in 5.6.2.2.
5.6.3.3 Echo Request Function
5.6.3.3.1 Recommendation. — ATN End System and Intermediate System Network Entities (NEs)
should support the ECHO REQUEST Function as invoked by Network Layer management.
Note.— The Echo Request Function is invoked to obtain information on the reachability of specific
network entities and the path characteristics between NEs through the operation of Network Layer routing functions.
5.6.3.4 Network Priority
Note.— The ATN Specific use of the ISO/IEC 8473 Priority is specified in 5.2.8.4.
Posting Komentar untuk "Aeronautical Telecommunication Network (ATN)"