European organisation for the safety of air navigation



Download 0.53 Mb.
Page5/10
Date28.01.2017
Size0.53 Mb.
#10107
1   2   3   4   5   6   7   8   9   10

8.1Addressing scheme

8.1.1Structure of an ATN network address


  1. An ATN NSAP address is a 20-octet string used to uniquely identify and locate a given NSAP (i.e. a network service user) within the context of the ATN.

  2. The ATN NSAP address format is illustrated in Figure 2. This address format starts with the Initial Domain Part (IDP) which comprises the Authority Format Identifier (AFI) and Initial Domain Identifier (IDI) fields and is followed by the Domain Specific Part (DSP).

Figure 2: ATN NSAP Address Format



  1. The (decimal) IDP value 470027 forms the common, initial part of all ATN NSAP addresses and NETs, i.e. it is the common fixed address prefix of these addresses. This address prefix defines the ATN Network Addressing Domain as a sub-domain of the Global OSI Network Addressing Domain, as depicted in Figure 1, under addressing authority of ICAO and using a binary format for the DSP.

  2. The Domain Specific Part (DSP) of the ATN NSAP address format is structured into seven individual address fields which allow to co-ordinate the allocation of ATN NSAP addresses and NETs according to the hierarchical approach described in section 8.

  3. The Table 1 below outlines the ATN NSAP addressing plan. This table describes the complete ATN NSAP address format, semantics and field contents from which NSAP addresses, NETs, NSAP address prefixes and Routing Domain Identifiers (RDIs) are derived. Furthermore, the table shows the addressing and registration authorities for each of the address fields as specified in Chapter 5.4 of the ATN SARPs.

Field Name

Size (Octets)

Value / Range

Semantic

Contents

Value Assignment

Addressing

Authority

Registration Authority

AFI

1

47 (decimal)

ISO 6523 ICD IDI and binary DSP format

47

Fixed

ISO

ISO/IEC 8348

IDI

2

00 27 (decimal)

ATN NSAP Address

00 27

Fixed

ISO

British Standards Institute (BSI)

VER

1

01 (hex)

41 (hex)


81 (hex)

c1 (hex)


Ground AINSC NSAP Address

Mobile AINSC NSAP Address

Ground ATSC NSAP Address

Mobile ATSC NSAP Address



01

41

81



c1

Fixed

Fixed


Fixed

Fixed


ATN SARPs Subvolume 5

ICAO

(ATN SARPs, Appendix 5, Chapter 5.4)



ADM

3

00 00 00 - ff ff ff

(hex)

ATN Network Address (Sub-) Domain Authority

ISO Country Code, or

ICAO Region Identifier, or

IATA Airline or Aeronautical Stakeholder Designator


Fixed

Fixed/Variable 1

Fixed


ATN SARPs Subvolume 5

ISO 3166

ATN SARPs Subvolume 5

IATA Doc xxx


RDF

1

00

Unassigned

00

Fixed

ATN SARPs Subvolume 5

ATN SARPs Subvolume 5

ARS

3

00 00 00 - ff ff ff

(hex)

Routing Domain (in Ground Network Addressing Domains)

Aircraft or Routing Domain (in Mobile Netw. Addr. Domains)



Not defined (for Ground Netw. Addressing Domains)

ICAO 24-bit Aircraft Address (for Mobile Netw. Addressing Domains)



Variable

Fixed


Administration

ATN Network Addressing (Sub-) Domain Authority defined in ADM field

ICAO


LOC

2

00 00 - ff ff

(hex)

Routing Area (in Ground Network Addressing Domains)

Routing Domain or Routing Area (in Mobile Netw. Addr. Domains)



Not defined

Not defined



Variable

Administration

ATN network Addressing (Sub-) Domain Authority which contains the parent Routing Domain

SYS

6

00 00 00 00 00 00

-

ff ff ff ff ff ff

(hex)

ATN System

Not defined

Variable

Administration

ATN Network Addressing (Sub-) Domain Authority which contains the parent Routing Area

N-SEL

1

00 - ff

(hex)

Network Entity

or

Network Service User



fe (NE implementing optional non-use of IDRP)

00 (all other NEs)

Remaining values not defined


Fixed

Fixed


Variable

Administration

ATN SARPs Subvolume 5

ATN SARPs Subvolume 5



Locally

Table 1 : ATN NSAP Address Definition

8.1.2Rules governing the network address fields defining the nesting of the address domains


  1. The European ATN inter-network addressing plan shall conform to the ATN Addressing plan specified in the ATN SARPs.

  2. As shown in Table 1, four of the nine fields of an ATN NSAP address or NET have already fixed values allocated by the ATN SARPs. The values of the remaining five fields, marked as variable in Table 1 and highlighted by grey boxes in Figure 2, remain to be allocated. This is the main purpose of the following chapters.

  3. At the upper level, the ATN SARPs identify the following four ICAO sub-ordinate addressing Domains:

  • The fixed Air Traffic Services Communications domain(ATSC fixed), i.e. the set of ground network addressing (sub-)domains administered by ATSC authorities

  • The mobile Air Traffic Services Communications domain(ATSC mobile), i.e. the set of airborne network addressing (sub-)domains administered by ATSC authorities.

  • The fixed Aeronautical Industry Service Communications domain(AINSC fixed) ), i.e. the set of ground network addressing (sub-)domains administered by members of the Aeronautical Industry.

  • The mobile Aeronautical Industry Service Communications domain(AINSC mobile), i.e. the set of airborne network addressing (sub-)domains administered by members of the Aeronautical Industry.

  1. The allocation of values to the remaining five ATN NSAP fields depends in the first place on the membership of the addressed element to one of these ICAO sub-ordinate addressing domains.



  1. The Table 2 below is a simplified version of Table 1, summarising the rules for the allocation of values to the different NSAP fields, depending on the ICAO sub-ordinate addressing domain to which the addressed element belongs.

Domain

field

ATSC-fixed

ATSC-mobile

AINSC-fixed

AINSC-mobile

AFI

47

47

47

47

IDI

0027

0027

0027

0027

VER

81

C1

01

41

ADM

the first octet shall be set to an ICAO Region identifier and the remainder is assigned by the region, or the field identifies an ICAO State

the first octet shall be set to an ICAO Region identifier and the remainder is assigned by the region, or the field identifies an ICAO State

registered with IATA by the identified organisation

should be derived from the IATA airline or aeronautical stakeholder designator

registered with IATA by the identified organisation

should be derived from the IATA airline or aeronautical stakeholder designator

RDF

00

00

00

00

ARS

assigned by the state/organisation identified by the ADM field

shall be the 24-bit ICAO Aircraft Identifier

assigned by the organisation identified by the ADM field

shall be the 24-bit ICAO Aircraft Identifier

LOC

assigned by the addressing authority of the Routing Domain identified by the ARS field

SYS

assigned by the addressing authority of the Routing Area identified by the LOC field

SEL

00 for the NET of IS of Class 1,2,3,4,5 and 6

fe for the NET of Class 7 IS

ff is reserved

any other value may be assigned to NSAPs



Table 2 : Assignement of values to the ATN NSAP address fields

  1. The sections 8.1.3 and 8.1.3.4.1 below proposes additional rules for the allocation of field values to ATN internetwork addresses of European fixed or mobile ATSC systems or domains.

  2. The definition of rules for the allocation of field values to ATN internetwork addresses of European fixed or mobile AINSC systems or domains is considered to be out of the scope of this document (this falls within the competence of IATA and the European airlines).

8.1.3Rules governing the network address fields identifying the routing domains


  1. As described in the Figure 2: ATN NSAP Address Format, the routing domains address is structured into seven individual address fields . The following chapters describe such fields.

8.1.3.1AFI, IDI, VER and RDF fields


  1. For compliance to the SARPs, the AFI, IDI, VER and RDF fields of the ATN internetwork addresses of European fixed ATSC systems or domains will be respectively set to 47, 0027, 81 and 00.

  2. The AFI, IDI, VER and RDF fields of the ATN internetwork addresses of European mobile ATSC systems or domains will be respectively set to 47, 0027, C1 and 00.

8.1.3.2Rules governing the ADM field

8.1.3.2.1ADM field encoding method

  1. The ADM field is used to further break down the Ground and Mobile ATSC NSAP Addressing Domains and the Ground and Mobile AINSC Addressing Domains into a set of subordinate network addressing (sub-)domains to allow devolved administration of each resulting (sub-) domain by an ICAO Region, State, airline or aeronautical organisation. The value of the ADM field, combined with the values of the preceding fields, forms the NSAP address prefix of each such ATN NSAP addressing (sub-) domain and consequently of all NSAP addresses and NETs administered by a given ICAO Region, State, airline or aeronautical organisation.

  2. The ADM field is three octets long.

  3. In the case of the ATSC addressing domains the ADM field should contain the one-octet ICAO Region Identifier (equal to 83HEX for Europe), with the remaining two octets assigned within the responsibility of the identified ICAO Region, which is then responsible for the relevant addressing sub-domain.

  4. States and ATS organisations within an ICAO Region should register (a subset of) their systems under the network address space associated with the relevant ICAO Region. This allows ICAO Regions to allocate ADM field values in the ATSC Network addressing Domains to States and Organisations within the ICAO Region, in a structured manner.

  5. This method for encoding the ADM field presents some advantages. First, it allows all fixed ATSC domains (as well as all mobile ATSC domains), within a region, to share one common NSAP address prefix: as an example, the common prefix to all fixed European ATSC domains would be, with such encoding, 4700278183, and the common prefix to all mobile European ATSC domains would be 470027C183. This permits potential routing information reduction and efficient advertisement of routing information: it makes possible to form one single route to the Region keeping the overhead of inter-regional communications down to a minimum.

  6. The second advantage of having the ADM field encoded with the one-octet ICAO Region Identifier at the start, is that the 2 remaining octets can be used independently by the ICAO Regions. This permits the addressing of States, but also of specific organisations within the region. This may also allow to take into account regional particularities such as the routing organisation of the regional ATN.

  7. It is therefore recommended that the ADM field of European ATN ATSC domains be encoded with the one-octet ICAO Region Identifier, followed by the remaining two octets under the responsibility of a European body (such as the Regional ICAO office) or of a European organisation (such as Eurocontrol), in accordance with the national organisation responsible for the operation of the domain.

  8. However, it is noted that individual European States may still prefer to use the ADM field to identify their addressing domain using the three character country code format permitted by the ATN SARPs.
8.1.3.2.2ADM field structuring principles

  1. The ADM field has been proposed to be encoded with the European ICAO Region Identifier (i.e. 83HEX) as first octet.

  2. With regard to the assignment of values to the remaining two octets of the ADM field, the addressing plan first considers the different (sub-)domains that will be distinguished with different ADM field values.

  3. The ADM field shall be used to distinguish the following (sub-)domains:

  1. The ADM field should be used to distinguish the supra-national Routing Domain Confederations such as the backbone RDC or any RDCs grouping several European organisations and/or several European States.

  2. Additionally, depending on the extent in scope that is assigned by the Regional addressing authority to the ADM field, the field could be used to distinguish the different national ATSC organisations (e.g. the French Meteorological organisation, the German military organisation, the Italian ATSO, etc...).

  3. The addressing plan, and more particularly the assignment of value to the ADM field, shall also consider the hierarchies between these sub-domains that are desirable to be reflected in the address structure.

  4. In conclusion, the hierarchical model that is proposed to be reflected in the address structure of the ADM field is the one illustrated by Figure 3.

Figure 3 : Hierarchical model proposed to be reflected in the address structure


8.1.3.2.3ADM field values assignment principles

  1. Before proposing any ADM field value assignments, the extent in scope of the ADM field remains to be specified.

  2. The ADM field shall allow the unambiguous identification of the different European States (i.e. the national RDCs), of the supra-national organisations, and of the supra-national RDCs.

  3. On the other hand, the identification, at the ADM field level, of the national ATSC organisations is questionable. Although the two remaining octets of the ADM field allow, in principle, the identification of 65535 distinct domains, and are therefore sufficient for this purpose, it is considered that the identification (and addressing) of the national organisations fall within the responsibility of States, rather than within the responsibility of a European body or organisation. For this reason, it is proposed that national organisations be not distinguished at ADM field level, and be rather identified at ARS field level.

  4. Having defined the scope and the hierarchical structuring principles for the ADM field of fixed and mobile ATSC internetwork addresses, principles for the assignment of values can be expressed.

  5. Concerning the allocation of values to the 2 remaining octets of the ADM field, the following approach is proposed:

  1. For the National RDCs, the two remaining octets of the ADM field are derived from the State’s two character alphanumeric ISO 3166 Country Code, represented as upper case characters.

  2. For the supra-national organisations, the two remaining octets of the ADM field are set to a two character alphanumeric code, registered with the European ICAO group and represented as lower case characters.

  3. For other RDCs, the two remaining octets of the ADM field are set to a two octets numeric code in the hexadecimal range [8000-ffff], allocated by European ICAO group.

  1. On the basis of these principles, Table 7 in Appendix A : Guidance to implementers proposes specific value assignment for States and organisations being in the scope of the LINK2000+ study and for RDCs that have been identified.

8.1.3.3Rules governing the ARS field

8.1.3.3.1General

  1. In Ground Network Addressing Domains the purpose of the ARS field is to distinguish routing domains operated by the same State, airline or organisation. In this case, the value of the ARS field, when combined with the values of the preceding fields, identifies a network addressing sub-domain that corresponds to an ATN routing domain. Each ICAO Region, State, airline or other aeronautical organisation identified by the value in the ADM field will be responsible for establishing one or more such network addressing sub-domains according to their local routing requirements and for the assignment of appropriate ARS field values to the corresponding routing domains.

  2. In Mobile Network Addressing Domains the purpose of the ARS field is to identify the aircraft on which the addressed ATN system is located. In the case of a Mobile Network Addressing Domain the ARS field value is the aircraft’s ICAO 24-bit aircraft address encoded as a hexadecimal value. When the ATN 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.
8.1.3.3.2Guidelines for the allocation of values to the ARS field of fixed ATSC inter-network addresses

  1. Each State or organisation or RDC identified by the value in the ADM field is free to assign its own values to the ARS field. The aim of this section is therefore not to propose having fixed ARS values for all States and organisations, but to provide some guidelines and recommend some common practices for the assignment of ARS values.

  2. The ARS field shall allow the addressing of the different Routing Domains operated by the State or the organisation but shall also allow the addressing of the Routing Domains of any other possible lower level organisational units of the State or the organisation.

  3. It is therefore recommended to States and organisations that provision be made, in the assignment of ARS field values, for any potential lower level organisational units that could, in the future, operate an ATN Routing Domain.

  4. As far as the States are concerned, the following categories of organisations have been identified as potential future operators of an ATN Routing Domain:

  • The national ATSO(s),

  • The national military organisation,

  • The national meteorological organisation(s),

  • The airport operators.



  1. As a possible approach for the provision of ATN internet addresses to the different national organisations, it is proposed that different ranges of values for the first octet of the ARS field be allocated to the different national organisations. As an example, it is proposed that:

  • values [00-1f] of the first octet of the ARS field be reserved for the addressing of domains and systems operated by the national ATSO.

  • values [20-3f] of the first octet of the ARS field be reserved for the addressing of domains and systems operated by the national military organisation.

  • values [40-5f] of the first octet of the ARS field be reserved for the addressing of domains and systems operated by the national airport operators. (Note: this range matches the ASCII range of alphabetical upper case characters).

  • values [60-7f] of the first octet of the ARS field be reserved for the addressing of domains and systems operated by the national meteorological organisation

  • values [80-ff] be reserved.

  1. A national organisation will then be required to register one or more values for the first octet of the ARS field within the range that has been reserved for its organisation category, and to freely allocate values to the remaining 2 octets of the ARS field.

  2. In addition to be used for distinguishing the different national organisations, the first octets of the ARS field is proposed to be used for the identification of the particular role of the addressed domain. It is indeed a common practice in the ATC networking environment to have, in parallel to the operational networks, duplicate non-operational networks used for the trials and the pre-operational experiments. This double networking environment approach is likely to be followed for the ATN infrastructure of the national ATSOs (and possibly of other national organisations) and the first octet of the ARS field appears to be hierarchically well suited for distinguishing operational domains from other non-operational domains.

  3. The remaining 2 octets of the ARS field should then be used to further distinguish between the Routing Domains of the same national organisation and of the same operational nature. The recommendation concerning the allocation of these 2 octets is to anticipate the possible evolution of the routing organisation and to allocate different values of the ARS field to different zones if these zones are perceived as subject to become independent Routing Domains in a further re-structuring of the routing organisation.

  4. This recommendation requires some explanations, and is proposed to be illustrated by an example. Consider the French ATSO, and assume that its initial ATN infrastructure is planned to consist of one single RD covering the whole French territory. Assume then that this initial French ATN topology is expected to evolve toward a new routing organisation consisting of five RDs, one RD being formed around each of the five French ACCs and covering the related FIR.

  5. A first solution for addressing the initial single French Routing Domain, would be to simply assign a single ARS field value for the identification of this Routing Domain. As an example, the ARS field value 000001 could be assigned. This would result in having all French ATN ESs and ISs within this RD configured with addresses the common prefix of which would be something like: 4700278183465200000001. At the time of the French ATN routing reorganisation, it would be necessary to allocate different ARS values to the new five different RDs. As an example, we may assume that these five different RDs could be respectively identified by the following ARS field values 00000a, 00000b, 00000c, 00000d and 00000e. One of the impact of the routing reorganisation, would consequently be the necessity to reconfigure every French ATN ESs and ISs, to have their internetwork address prefixes changed from 4700278183465200000001 to respectively 470027818346520000000a, 470027818346520000000b, 470027818346520000000c, 470027818346520000000d and 470027818346520000000e.

  6. The purpose of the recommendation, with this example would have been to invite the French ATSO addressing authority to assign directly at the initial stage of the French ATN network, different ARS field values to the five different zones covering the French FIRs. As an example, the application of this recommendation could have resulted in having directly form the start, one of the following five different prefixes respectively used in each FIR for the addressing of the French ATN ESs and ISs: 4700278183465200000001, 4700278183465200000002, 4700278183465200000003, 4700278183465200000004 and 4700278183465200000005. In the initial period where the French ATN consists of one single RD used in an operational context, the 9-octets-long prefix 470027818346520000 which is common to these five 11-octets-long prefixes could then have been used as the Routing Domain Identifier and as the routing information advertised to adjacent Routing Domain (so meeting the requirements for information reduction). Then, at the time of the routing re-organisation with 5 routing domains, it would not be necessary to reconfigure every French ESs and ISs. The only change to be applied to the addressing would be to change the French RDI length from ten to eleven octets.
8.1.3.3.3Rules governing the ARS field values assignment

  1. On the basis of the recommendations expressed in the previous section, this section proposes a specific common approach for the assignment of ARS values by States. This is to be considered as a reference example, which could be looked at as a basis, and re-engineered taking into account the national particularities.

  2. The States are proposed to reserve ranges of values of the first octet of the ARS field to the different national organisations as illustrated by the example of the previous section. It is proposed that the range matching the ASCII range of alphabetical upper case characters (i.e. [40-5F]) be allocated to airport operators.

  3. It is proposed that national ATSOs, military organisations and meteorological organisations identify with each value of the first octet of the ARS field, a different set of Routing Domains as well as the operational nature of this set of Routing Domains. The following specific allocations are proposed for the value of the first octet of the ARS field:

  • 01 for the set of operational Routing Domains of the national ATSO,

  • 11 for the set of non-operational Routing Domains of the national ATSO,

  • 21 for the set of operational Routing Domains of the national military organisation,

  • 31 for the set of non-operational Routing Domains of the national military organisation,

  • 61 for the set of operational Routing Domains of the national meteorological organisation,

  • 71 for the set of non-operational Routing Domains of the national meteorological organisation.

  1. It is proposed that the 2 remaining octets of the ARS field be used to contain a two alphabetical characters code identifying one particular zone, in the ATN topology of the organisation. As far as the ATSOs are concerned, it is proposed that this 2 alphabetical characters code be used to identify a FIR. Considering that the 4-letter ICAO location indicators are well known codes in the aeronautical community and that the 2 last characters identify unambiguously a FIR or ACC in the context of a given country, it is proposed that these 2 last characters of the 4-letter ICAO location indicators associated with each FIR or ACC be used as value for the 2 last characters of the ARS field. The Table 8 in Appendix A : Guidance to implementers illustrates this proposal.

  2. For the Airport operators, it is proposed that the ARS field value be derived from the three-character alphanumeric international code of the airports (e.g. ‘CDG’ for Paris-CDG Airport operator)

  3. When used to identify a mobile ATSC Routing Domains, the ARS field will be set to the 24-bit ICAO Aircraft Identifier as specified in the ATN SARPs.

8.1.3.4Rules governing the LOC field

8.1.3.4.1General

  1. In Ground Network Addressing Domains (i.e. for the ATN NSAP address prefixes 47 0027 01 and 47 0027 81) the purpose of the LOC field is to distinguish routing areas within the same routing domain. In Mobile Network Addressing Domains (i.e. for the ATN NSAP address prefixes 47 0027 41 and 47 0027 c1) the purpose of the LOC field is to distinguish routing areas within the same routing domain, if only one routing domain exists onboard the aircraft. When more than one RD is located on a single aircraft, the LOC field distinguishes each such RD and the routing areas contained within them.

  2. The assignment of the LOC field value is under the responsibility of the organisation which constitutes the addressing authority for the routing domain in which the identified routing area is contained. The assignment of the LOC field value is entirely a matter local to the organisation and mainly depends on the intra routing domain organisation; it is therefore difficult to recommend a common approach.
8.1.3.4.2Rules governing the LOC field value assignment

  1. A routing area corresponds generally to one site, although it may happen that several areas are formed in one site or that one single area covers several sites.

  2. The LOC field value shall unambiguously identify an area in the context of one Routing Domain, but does not necessarily need to be unambiguous in the context of a group of Routing Domains. That means that an organisation operating several Routing Domains may assign the same LOC field value (e.g. 0001) to 2 different areas if these areas belong to different routing domains. However, it is generally preferred to assign well known sites/areas identifiers that are unambiguous in the context of the whole organisation rather than being only unambiguous in the context of a particular Routing Domain. Another common practice is to allocate different ranges of values to different categories of sites/areas. As an example, an ATSO may be willing to assign different ranges of LOC field values to en-route ACC areas, TMA and airports areas, technical services areas, and other areas. The Table 9 Appendix A : Guidance to implementers summarises the various recommended values.

8.1.4Recommendations governing the network address fields identifying a system lying within a routing domain

8.1.4.1SYS field


  1. The SYS field is used to uniquely identify an ATN end or intermediate system within a given routing area. The assignment of the SYS field value is under the responsibility of the organisation which constitutes the addressing authority for the routing area in which the identified ATN system is contained.

  2. The SYS field should be assigned a meaningful value within the context of the given routing area. For example, if the ATN system is attached to an IEEE 802 local area network, then a common approach is to use the LAN address of the system as the value of the SYS field. However this is generally not considered as being a good practice: one important criterion in selecting a Network address format is indeed the likely future stability of the resultant Network address, and this stability is best achieved by allocating a Network address which does not contain any subnetwork dependent information; use of physical subnetwork addresses in the SYS field, may mean that the NSAP address will have to be changed, if the hardware supporting the addressed system is replaced (e.g. replacement of an ethernet card or of the whole computer),

  3. In addition to constitute the unique identifier of a system within a routing area, the 6 octets of the SYS field may be used to encode different information on the system. Possible examples of the information that can be encoded in the SYS field are:

  • Whether the system is an IS or an ES,

  • The class (1 to 7) of an IS,

  • The standby role of the system (primary system, Hot standby system, cold standby system),

  • The type of the applications running on the system (e.g. Network Management station, AMHS User Agent, Air/Ground application server, etc...).

8.1.4.2SEL field


  1. The N-SEL field is used to identify either the network layer entity or a network service user within the context of a given ATN system. The assignment of the N-SEL field value is a matter local to the administrator of the ATN system, except for the cases of the NET of an intermediate system. For these cases, Chapter 5.4 of the Manual of Technical Provisions for the ATN has assigned appropriate N-SEL field values:

  • 00 shall be used as selector value for the NET of all ATN ISs, except for the case of airborne ISs implementing the procedures for the optional non-use of IDRP

  • FE shall be used as selector value for the NET of all airborne ISs implementing the procedures for the optional non-use of IDRP

  • the value FF is reserved and shall not be allocated.

8.1.5Examples of network addresses


  1. The address

  2. 470027+8183458300114342020001010505020200

  3. designates the router lying in the Barcelona RD administered by Spanish ATSO. This RD belongs to the Spanish RDC. This router is operated in test mode.

  4. The address

  5. 470027+8183444500615757030001010505020200

  6. designates the router lying in the Bremen RD administered by German meteorological organisation. This RD belongs to the German RDC. This router is operated in operational mode.


Download 0.53 Mb.

Share with your friends:
1   2   3   4   5   6   7   8   9   10




The database is protected by copyright ©ininet.org 2024
send message

    Main page