9
ACP-SWGN1-10/WP-xx/
International Civil Aviation Organization
WORKING PAPER / ACP-SWGN1-10/WP-1005
13 Sep 2006
AERONAUTICAL COMMUNICATIONS PANEL (ACP)
10th MEETING OF SUB-WORKING GROUP N-1
Montreal, Canada 25-29 September 2006
Agenda Item 5: / Development of new technical material arising from any new/revised requirementsATN IPS ASSUMPTIONS AND ROUTING PROTOCOL CONSIDERATIONS
(Presented by Eivan Cerasi)
SUMMARYThis paper identifies a series of assumptions for discussion derived from the analysis of the proposed amendments to Annex 10 and the ATN IPS Manual. It informs the Sub-Group on the result of routing trials performed by EUROCONTROL.
ACTION
It is strongly recommended that the ATN IPS material does not mandate a specific routing protocol at this stage but to consider this in the context of an evolution of the ATN IPS supported by the result of on-going application studies.
1. INTRODUCTION
1.1 The purpose of this document is to support the development of the ICAO ATN IPS.
1.2 It presents a series of assumptions that have been identified to better understand the evolution of the ATN IPS hence the immediate scope and content requirements of the ATN IPS material.
1.3 It is then followed by a technical section focusing on the foreseen routing protocol specifications derived from the results of EUROCONTROL internal lab trials documented in Annex.
2. discussion
2.1 Defining Assumptions for the IPS
2.2 As discussed within the previous Sub Group N1 meeting the physical topology and infrastructure of the ground IPS are unknown elements. On the other hand, by introducing the notion of Administrative Domains (AD), the draft Manual for IPS does propose a basic architecture.
2.3 If one is to consider the ground applications of the ATN IPS:
· AMHS is the first ATN application that is being rolled-out globally as a gradual replacement of the existing AFTN/CIDIN.
· AIDC solely requires communication between adjacent FIRs for the purpose of co-ordination and transfer; it does not require global network connectivity.
2.4 It is therefore reasonable to expect that the topology of ground ATN IP network interchanges will derive from the migration of AFTN/CIDIN to AMHS, benefiting of the existing international connectivity, bilateral agreements and working arrangements.
2.5 As a result of an understanding of the deployment context, a series of assumptions can be formulated for discussion to better understand the immediate content requirements of the ATN IPS material:
1. The essential goal of the ATN IPS is to ensure that ATN IPS hosts can communicate over an IP network interface not to build a new global IP network;
2. ATN applications define whether they should operate over TCP or UDP, the ATN IPS should assume that any special TCP or UDP settings e.g. port numbers, are to be part of the ATN application SARPs;
3. The ATN IPS can define items such as the addressing scheme and minimum key performance characteristics to be met in terms of network delay, network jitter and classes of service.
4. Mandatory statements within the ATN IPS material cannot lead to vendor exclusive mechanisms and must be interoperable;
5. The ATN IPS will be dis-jointed i.e. two ADs may be interconnected in isolation over a point-to-point link;
6. Within States, the ATN IP enabled nodes will operate on the same IP physical infrastructure as non-ATN applications i.e. civil-military, surveillance applications, etc.;
7. The ATN IPS will be deployed over a long period of time implying evolutions of the infrastructure and technology, the right balance between SARPs, Manuals and Guidance Material must be carefully addressed;
8. A growth pattern of ATN IP-enabled applications can be assumed, to both tailor the content of the ATN IPS material and accelerate it’s adoption:
· The ATN IP-enabled applications are likely to operate over private State/ANSP infrastructure, however, some States may wish to operate over public infrastructure;
· One should not expect investment into new dedicated network infrastructure for the sole purposes of the AMHS, it is likely that States/ANSPs will re-use or upgrade existing links, in particular those between AFTN/CIDIN COM centres as this will ease the application migration;
· In parallel, in an effort to reduce communication costs, one can expect a rationalisation of intra-regional infrastructure which will simplify intra-regional IP network topology;
· States/ANSPs that do deploy AIDC between ATSUs to automate coordination and transfer are likely to make use of new bilateral point-to-point links or multiplex on existing voice links
(Note:- European States have no plans to deploy AIDC);
· The impact of on-going studies for new ATN applications on the content of the ATN IPS is unknown (A/G in particular may or may not need global dynamic IP routing and/or mobility), this can be addressed in the context of an evolution of the ATN IPS material.
2.6 Routing Protocol
2.6.1 The draft ATN IPS material mandates a dynamic routing protocol between Administrative Domains irrespective of the topology or means of interconnection between peers. This is an over-specification in cases where two isolated ADs are interconnected with a point-to-point link.
2.6.2 Two options are proposed to alleviate this issue:
1. Condition or characterise the use of BGP4+ for inter-AD links; or
2. Remove BGP4+ from the ATN IPS material and integrate BGP4+ specifications into associated Guidance Material.
2.6.3 EUROCONTROL supports the second option.
2.7 Missing Provisions for BGP4+
2.7.1 Simply specifying BGP4+ as a routing protocol between Administrative Domains is insufficient. Essential configuration parameters of the protocol need to be specified in order to ensure a coherent BGP deployment in a de-centralised environment:
· A unique AS numbering scheme must be developed;
· The IP address space between BGP peers should come from ranges belonging to Administrative Domains (bilateral agreement) or globally reserved to avoid any source of conflict;
· BGP router IDs do not need to be globally unique but it is strongly suggested to develop a unique numbering scheme (draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt can be used as a guideline);
· BGP timers should be consistent between inter-AD routers;
· BGP inter-AD routers should advertise routes based on consistent prefix lengths or aggregate route prefixes;
2.8 BGP4+ Tests
2.8.1 At the last SGN1 meeting, EUROCONTROL indicated that it would investigate the impact of using BGP4+ for both inter-AD routing and within a regional AD.
2.8.2 The Annex describes the performed tests and the main results have been integrated into section 2.7.
2.8.3 SGN1 is invited to note that a significant number of issues such as management structures, prefix filtering (security), use of default convergence times, resilience were not addressed in these tests.
3. ACTION BY THE MEETING
3.1 The SGN1 is invited to discuss the identified assumptions of the ATN IPS.
3.2 The SGN1 is recommended to move all BGP4+ dynamic routing statements to Guidance Material.
APPENDIX A. BGP TESTS
4. Introduction
4.1 The purpose of the test is to determine the implications of potential AS number conflicts within the global ATN IP network.
4.2 The derived results from these tests are not vendor-specific.
5. Test setup description
5.1 A setup was built using Cisco routers to simulated the interconnection of 3 European ANSPs - each represented by one router - with the PEN – represented by 3 routers. 3 non-European networks, Canada, US and Asia – each represented by one router – were connected to the PEN network.
5.2 The number and countries depicted in the tests are illustrative and bear no relation to any actual or foreseen international arrangements.
5.3 All routers are configured with IPv6 addresses and are running BGP-4+. The network clouds are represented in the setup by one interface of the appropriate router.
Figure 1 - No BGP Cconfederation
6. Test scenarii
6.1 No conflicting AS numbers
6.1.1 All AS numbers are unique, as shown in the diagram above. In this case, all networks are able to reach all other networks.
6.1.2 2 different BGP architectures were validated:
· without confederations, as shown in Figure 1
· with a confederation, as shown in Figure 2.
6.1.3 In the confederation architecture, the PEN and European networks (Portugal + Greece + UK) are grouped together to form a confederation with AS number 65208.
6.1.4 Inside the confederation, the PEN BGP routers are assigned AS number 64001 and the Portuguese, Geek and UK routers keep their original AS numbers.
6.1.5 Note that in the confederation architecture, all European networks are seen by the US, Asian and Canadian routers as originating from AS number 65208.
Figure 2 - With a BGP Confederation
6.2 AS number conflict
6.2.1 The AS number of the US network is changed to 64676 so that is conflicts with the AS number of the Greek network which is also 64676.
6.2.2 The US BGP router no longer accepts routing updates that contain AS number 64676 in the path and therefore no longer has a route to reach the Greek network. Likewise, the BGP router for Greece also refuses routing updates with an AS path containing AS number 64676 and therefore has no route to reach the US network.
6.2.3 The following 5 mechanisms were considered to mitigate the conflict caused by the duplication of the AS number 64676.
6.3 Private AS number filtering
6.3.1 The PEN BGP routers can be configured to remove private AS numbers from the AS path in the routing updates they send to their neighbours. This is achieved using the Cisco command:
neighbour <ipv6 address> remove-private-as
6.3.2 As all AS numbers in this setup are private, all routing updates sent by the PEN BGP routers will contain a single AS number in the AS path which is the AS number of the PEN network, 65208.
6.3.3 This will restore communication between the US and Greek networks as the US and Greek BGP routers will receive routing updates that contain only the PEN AS number in the AS path.
6.3.4 The downside is that a lot of routing information is lost when the private AS numbers are discarded. Routing loops could occur.
6.3.5 This workaround also requires that all AS numbers be private. If a public AS number appears in the AS path of a routing update sent to one of the PEN BGP routers, then the PEN router will not strip the private AS numbers from the AS path of that update.
6.4 Use of confederations
6.4.1 A confederation is created as shown in Figure 2, except that the US network has an AS number of 64676 instead of 65002, causing a conflict with the AS number of the Greek network.
6.4.2 Unfortunately, this configuration is invalid, as BGP router PEN-1 will not allow a BGP peer to have an AS number which is part of the confederation.
6.4.3 To be able to test the effect of confederations, the US BGP router regains its original AS number 65002 and the Asian BGP router’s AS number is changed from 65001 to 64676.
6.4.4 There is now an AS number conflict between the Greek and Asian networks.
6.4.5 In the BGP routing updates sent by the PEN BGP routers to the US and Canadian BGP routers, the AS path never contains the AS numbers inside the confederation (64001, 64676, 64740 and 64796). The only AS number used is that of the confederation 65208. Therefore the routing updates received by the Asian BGP router via the US BGP router are accepted as they do not contain AS number 64676 in the AS path. This means that the Asian router has a route to reach the Greek network despite the AS number conflict.
6.4.6 However, the routing updates for the Asian network received by the Greek BGP router contain AS number 64676 in the AS path, so they are refused. This means that the Greek BGP router does not have a route to reach the Asian network.
6.4.7 To provide a workaround for this problem, another confederation would have to be created, containing the Asian network. This new confederation would have a unique AS number and routing updates received by the PEN BGP routers for the Asian network would bear this new AS number in the AS path.
6.5 Allowing duplicate AS numbers
6.5.1 There is a feature available on Cisco routers that allows a router running BGP not to discard a routing update which contains its own AS number in the AS path. The configuration command specifies how many occurrences of its own AS number in the AS path the router will allow before it considers the routing update invalid, so as to limit the chances of routing loops occurring.
6.5.2 The command syntax is:
neighbour <IPv6 address> allowas-in <number of occurrences>
6.5.3 To test this feature, the confederation is removed and all routers are returned to the configuration described in 3.2
6.5.4 The Greek and US BGP routers are configured to allow routing updates from their BGP peers which contain one occurrence of their own AS number (64676 for both routers).
6.5.5 This allows the US BGP router to accept the routing update containing the route to the Greek network, and vice-versa.
6.5.6 As this configuration deliberately bypasses one of BGP’s mechanisms for the prevention of routing loops, great care must be taken when using the “allowas-in” feature.
6.6 AS number manipulation
6.6.1 There is a feature available on Cisco routers which allows a BGP peer to override the AS path of an incoming BGP update. The BGP peer replaces the AS number of its peer with its own AS number in the AS path of the update.
6.6.2 This feature is apparently only implemented for the “vrf” (Virtual Routing and Forwarding) address family.
6.6.3 The command syntax is:
neighbour <IPv6 address> as-override
6.6.4 Cisco recommends that this feature be used with the site of origin extended community in the case of multi-homed ASes.
6.6.5 The site of origin extended BGP community can be used to avoid routing loops when the AS path based loop prevention mechanism has been circumvented using the “asoverride” or “allowas-in” features. This feature was not tested.
6.7 Route aggregation
6.7.1 When an aggregate route is advertised, information about the AS path of more specific routes may be lost. This could be used in the case of duplicate AS numbers to avoid situations where a BGP router will not accept a route to another network because the AS path in the routing update contains its own AS number.
6.7.2 This would require the IP address ranges assigned to the different networks to follow certain rules that would allow them to be aggregated and would be difficult to manage.
6.7.3 This situation was not tested.