============================================================================= DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT ============================================================================= EBONE 92 IP ROUTING MODEL ========================= Tony Bates, ULCC. And Peter Lothberg, SWIPnet. April 8, 1992 Abstract The goal is to implement, and put into production, a shared infrastructure for open architecture protocols in Europe; EBONE supports two achietectures, "OSI" and "TCP/IP" and this document describes both the model and implementation in terms of routing for achieving this. Content 1 Introduction. 1.1 Topology. 1.2 Basic Concepts. 2 Basic definitions. 3 Inter EBS routing. 3.1 Ebone IGP. 3.2 Ebone IBGP. 3.3 EBS examples. 4 EBS to RBS routing. 4.1 Single EBS to RBS connection. 4.1.1 Routing announcments towards the region from Ebone 4.1.2 Routing announcments towards Ebone 4.2 Other Scenarios 4.2.1 RBS to RBS routing 4.2.2 Routing for an RBS connected to more than one EBS. 4.2.3 Routing for a region with multiple RBS connections. 4.3 RBS examples. 5 Ebone to US routing. 5.1 Policy regarding Primary routes to the US. 5.2 Routing announcments towards ebone. 5.3 Routing announcements towards NSFnet. 5.4 Using Ebone as a backup to the US. 5.5 EBS to US examples. 5.6 Proposed next step for US - Europe routing. 6 References. 7 Appendix. A Ebone description. B EBS configuration guidelines. C RBS configuration guidelines. D US connectivity and backup guidelines. E Tutorial on BGP and OSPF. F Proposal for Ebone objects in RIPE database. 1. Introduction This document describes an initial routing implementation to be used within EBONE [1]. [1] defines two distinct systems to be used within the EBONE framework, The "Regional Boundary System" (RBS) and the "EBONE Boundary System" (EBS). It will cover Inter EBS routing. Routing between the Ebone Kernel and the continental US and routing between an EBS and its respective RBS.of both the basic concepts and topology within EBONE. However, it is recommended that there is an understanding of [1] prior to reading this document. 1.1 Basic concepts. The EBONE infrastructure complies to the generalised model of an open networking multi-architecture backbone and uses two technical concepts within it's model: - the EBONE Boundary Systems (EBSs); and: - the Regional Boundary Systems (RBSs). The EBSs are linked in such a way so as to create a resiliant backbone. The RBSs provide backbone access for regional networks (Autonomous systems) via a link to an EBS or multiple EBSs. 1.2 Basic Topology. The basic topology of EBONE is that of a pentagon which makes up the EBONE kernel. At each corner of the pentagon is situated an EBS which connects to two other EBS's. At each EBS an unspecified number of connections will be made to RBS's. At three of the EBS there exists a link to the USA. The Ebone topology is not "definite" but changes has to be carefully evaluated. Figure 1 shows this in some graphic form. /-- RBS /--- RBS /---- RBS LINK 1 /----- RBS USA <-------------- EBS / \ / \ / \ / \ / \ / \ / \ LINK 2 / \ USA <--------- EBS EBS /| |\ RBS ----- / | | \------- RBS RBS -----/ | | \------ RBS RBS ----/ | | \----- RBS | KERNEL | | | | | | | | | EBS---------------EBS / / \ EBS --/ / \----- RBS / / / LINK 3 / USA <----------------------------/ Figure 1. For a more detailed looked at the topology please refer to [2]. 2. Basic Definitions Throughout this document certain definitions are assumed. BGP is used to reference the routing protocol used on the border between two autonomous systems (AS). It is the routing protocol used for inter AS routing. It can be viewed as either the Border Gateway Protocol (BGP3) (RFC1267 - [3]) , the Exterior Gateway Protocol (EGP) (RFC904 [4]). The recommendation is to use BGP3 wherever possible for IP. See Appendix E. For OSI IS-IS [7] will be used as a boarder gateway protocol. ** To make Ebone work, and the task of maintaining the network it is a ** absolute need that the Ebone kernel is keept isolated from any regional ** IGP. Routing has to be injected into Ebone from a region, it cannot ** be generated in a Ebone internal system! ** This is not politics, it was learned the hard way when we implemented ** the EBS/RBS configuration in Stockholm. Once working, it makes network ** managemnt a pice of cake. -Peter IGP references the interior gateway protocol used inside an autonomous system and within the Ebone kernel itself. It contains such features as dynamic load sharing and subnet information. Initially Ebone will use cisco systems IGRP protocol (cisco ref ??? [5]). When a stable implementation of the Open Shortest Path First (OSPF) protocol (RFC1247 [6]) is available it will be used. For OSI the cisco OSI-IGRP will be used as an interim soulution. The term "cheapest" is taken to mean the closest and fastest path through Ebone, as viewed by the EBS and based on the IGP information it receives from its respective neighbors. The term Autonomous System (AS) is used in its classic sense here. As a set of routers or switches under a single technical administration. In routing terms it will use an interior gateway protocol and some sort of common metrics. It may sometimes in reality have more than one IGP running. However, the fact is that to other ASs it is seen a single coherant interior routing plan with a consistent view of its reachable networks. When talking to other ASs it will use an exterior routing protocol (our BGP definition above). 3. Inter EBS routing. 3.1 Ebone IGP. Ebone itself will act as a single AS. Two IGP protocols are used, IBGP and IGRP. There is a full mesh if IBGP peerings between all EBS systems, so they will have a consistent way of the sorrounding networks. The IBGP contains all the routing for networks external to the Ebone core. IGRP are run to keep track of the paths between the EBS systems, but does not have any information about external networks. IGRP information are more trusted than IBGP, so false information in the IGRP will make the packet forwarding to malfunktion, while the IBGP has correct information. The AS path from region A to region B will only see Ebone once, A-Ebone-B. The IGRP protocol itself will take care of finding the cheapest route through Ebone to any EBS that connects a given European network. This will be done on the basis of its metric. Initially not all the Ebone links will be of the same bandwidth and some slight tuning of the IGP metrics may be needed to avoid possible non-optimal routing from taking place. (IBGP are used for administration while IGRP are used for packet forwarding.) Routing within the Ebone kernel is effectively "open" from the point of view that no access control will be put on EBS routing announcements either in-bound or out-bound to the Ebone kernel. For control purposes and pragmatic reasons access control will take place at the EBS-RBS interface based on information in the RIPE database [4]. The Ebone IBGP will carry routing information for all Ebone internal networks. It is important to implement OSPF based routing as fast as possible so as to minimise the bandwidth consumed in routing updates and the time taken for routing information to converge following a topology change within the IGP. Carrying of CLNP routing is achieved by using ISO-IGRP as an interim solution. 3.2 EBONE IBGP It is possible to use BGP for Intra AS routing to maintain a coherant view of BGP derived routes. When used in this way we use the term IBGP. If we use BGP3 as our BGP we can use IBGP as well as and IGP within the the backbone. This will give us added functionality of avoiding routing loops and path AS path information within the backbone. Practically this is done by having a full mesh of IBGP sessions between all EBS systems, the BGP derived route in any EBS will be the view the EBS that connects to the RBS that has the destionation as its neighbour. The IGP has the responsibility to find the chepest path to that EBS. One of the cases where this important is when a region is having connections to more than one EBS. 3.3 Inter EBS example. Appendix B gives an example of a possible EBS configuration. It covers the details of inter EBS configuartion. The configuration examples are all based upon the cisco systems gateway software. 4. EBS to RBS routing For this discussion we assume the model given in section 3. From any EBS Ebone is seen as an AS. EBS to RBS routing is done on the basis of BGP. As such EBS to RBS routing is inter AS routing. In many ways Inter AS routing can be more complex than intra AS routing. Problems can occur when there are back-door routes between regions and also when a region is connected to more than one EBS. The basic case of a single EBS to RBS connection is first examined. Followed by more complex scearios. 4.1 Single EBS to RBS connection. For simplicity we look at routing as directional here taking each case seperately. 4.1.1 Routing announcments towards the region from Ebone The EBS peers with the RBS using BGP and redistributes relevant routes from the Ebone IBGP. In addition to europeon routes the EBS will provide routing to the NSFnet backbones as described below. It is recomended to use them as default networks in the RBS along with the Ebone backbone networks. Routes for non AUP networks are also carried, to ensure that they will use the correct paths and allow for policy based routing external to Ebone. In the the single EBS to RBS set-up the RBS can request to only receive the default networks. If BGP is being used AS path details will be given too along with the networks stating how these networks were derived. This makes it possible for the RBS to perform policy based routing. 4.1.2 Routing announcments towards Ebone The RBS should announce all networks that belong to the region to the EBS. Regions that have their own links to other regions should avoid announcing them to the EBS, as long as they do not have a bi-lateral backup arrangement for Ebone traffic with the transit region. Acces control will be done on in-bouund annoucemants received by the EBS using the RIPE database [8], [9]. It is recommended that the RBS uses some form of out-bound access filter for sensible routing. 4.2 Other Secnarios 4.2.1 RBS to RBS routing Inter RBS connections are primarily not a Ebone matter. However, some guidelines could be useful for a smooth integration with Ebone. When an RBS acts as a secondary access point for traffic from another region. AS paths announced towards Ebone have to be correct, both representing the current topology of the network and maintain consistency with the RIPE database. For more details see configuration examples. 4.2.2 Routing for an RBS connected to more than one EBS. The Ebone IBGP will take care of finding the shortest AS path to that region and the IGRP will take the cheapest path to the EBS next to the chosen RBS. If desired by the region, it can make use of the AS path received from the EBS. 4.2.3 Routing for a region with multiple RBS connections. A region must take care not to redistribute routes derived from one RBS connection across to any other RBS connection within its region. It is recommended that the region adopts IBGP or atleast OSPF as it's IGP. This gives the most functionality in that IBGP or OSPF as an IGP can carry AS path information derived from the BGP. It is up to the region to decide how it wishes to make best use of it's multiple connections to Ebone. 4.3 RBS examples. Appendix C shows examples of all the above scenarios relevent to EBS to RBS configurations. All configuaration examples are based upon cisco systems gateway software. C.1 Simple RBS to EBS with a region that uses IGRP and RIP. C.2 RBS that talks to both another regional RBS and a EBS. C.3 Using a router to turn IGRP<->BGP as a temporary kludge. 5. Ebone to US routing. The routing implementation for traffic between the continental US and Europe is a problem that has to be solved step by step. It needs co-ordination from both sides. Deployment should be in several phases, where this document describes the first and gives some guidleines for step2. The following issues must be taken into account: o Make use of a US link for PRIMARY access only where a bi-lateral agreement exists. o Maintain the current topology and connectivity wherever possible. o Avoid cross Ebone transit traffic. o Make use of Ebone for efficient backup of US links. o Avoid heavy routing traffic. o Avoid European routing via any of the US links. It should be noted that point one is a decision made by the Ebone executive and it will be seen that this has some impact on which EBS an RBS may decide to connect to. To make things simpler we view the US links as all connecting directly to the NSFnet backbone. In fact in reality this is not the case but hopefully it will be seen that this will not effect the implementation. Routing can be looked at seperately in the same "from and towards" Ebone concept as above. 5.1 Routing announcements towards NSFnet. The EBS that connects to an NSFnet backbone router (NSS/ENSS) announces all networks from Ebone that use that link with BGP, which will have been derived on reachability information from the Ebone IBGP. A network allowed on a certain link that is not reachable shall not be announced. One way of implementing this is by filtering the Ebone IBGP and advertise these routes to the NSFnet backbone. There will be a separate AS (as today) for each link. The NSFnet controls its routing by using a static database. So although it receives European network announcements from each of the peering EBS's it will construct an AS path selection on the basis of the cheapest route to the destination network. Hence, a simple matrix can be produced depending on which EBS your network is connected to. The matrix tabled below is based upon the issues given in section 5. The impact of this is that when connecting to an EBS as a region your intercontinental traffic will flow a certain way without any exception. Therefore an RBS must understand clearly the routing used in the matrix below. The matrix is based very much with a pragmatic and resource approach in mind. As such certain existing agreements on use of US links may NOT be possible. Key: LINK1 ~ KTH <-> CORNELL (NSS10) [512 Kbps] LINK2 ~ ULCC <-> FIX-E (NSS9) [384 Kbps] LINK3 ~ CERN <-> CORNELL (NSS10) [1.544 Mbps] EBS connected to | PATH selection | -----------------+-------------------------+ Stockholm | LINK1 | LINK2 | LINK3 | London | LINK2 | LINK1 | LINK3 | Montpellier* | LINK3 | LINK2 | LINK1 | Geneva | LINK3 | LINK2 | LINK1 | Amsterdam | LINK3 | LINK1 | LINK2 | -----------------+--------+-------+--------+ * - Mediterrian area. 5.2 Routing announcments towards ebone. (traffic to US) On an EBS that is connected to a US link, or an US-RBS-EBS configuration announce T1 and T3 networks as orginating in the AS that peers with the EBS. This implemention should be done such as if the peering with the NSS drops, the announcment should also go away. The EBS uses the T1 (network 129.140.0.0) and the T3 (network 140.222.0.0) networks as default networks. The IGP metric of US routes will be incremented for each EBS the routing information passes. So from any given EBS a packet destinated to the US will take the cheapest path through Ebone. This will of course mean that some assymmetric US routing might take place. When the EBS recives a packet that has to be routed it will be forwarded according to the IGP informationusing the cheapest path. If the destination network is not on a Ebone connected RBS or if the destination is unknown it will take the cheapest path through Ebone to a EBS that has a US connection. If the destination network is unreachable, then the NSS will reject it and return a ICMP Network Unreachable message to the packet originator. 5.3 Routing announcements towards NSFnet. (traffic from US) As the world does not have any politics or AUP we asume that such problems are taken care of elswere. The EBS announces all Ebone routes with BGP through the system(s) that connects the EBS to the NSS. NSFnet internal table driven routing takes care of using the intercontinental link that ends in the EBS that has the cheapest path to the destination. 5.4 Using Ebone as a backup to the US. While all links are operational the traffic flow will follow the current (920219) traffic pattern for those that are connected to a EBS that has a US link. Regions connected to a EBS without a US connection will follow the routing mechanism as set out in the above matrix. Again assymmetric routing will take place. Routing from Europe to US will take place according to the cheapest route to the default network as given by the Ebone IGP. This is only possible because the NSFnet accepts traffic inbound on any NSS. 5.5 EBS to US examples. ?????!?!??!?!?!? 5.6 Proposed next step for US - Europe routing. Implementing BGP carrying full AS paths between US and Ebone is a step that we need to take during 1992. Is it possible to use BGP metrics to balance the fact that the NSFnet is a T3 network, wile Ebone is only 1/4 E1. This would make a dynamic selection of paths. Another logical step would be to have a Ebone point of precence in the US and its own bandwidth to transit continetal US to reach destinations on the west-coast and Hawaii, Japan, Australia, New-Zeeland etc. 6. References. [1] Ebone-92 Proposal. Kit Miles. [2] Ebone Line and site installation plan. Bernhard Stockman. [3] BGP3. RFC1267. [4] EGP2. RFC 904. [5] Introduction to IGRP. Charles Hedrick. [6] OSPF2. RFC 1247. John Moy. [7] IS-IS. ISO 8473. [8] Ripe Databases. ripe-w02, Rob Blockzijl. [9] Proposed new Ebone routing objects in Ripe database. Bates, Lothberg. 7. Appendix. APPENDIX A Will add in the refernece of the Ebone installation. APPENDIX B EBS configuration guidelines. interface Ethernet 0 description Ebone stub in sthlm ip address 192.121.154.17 255.255.255.240 no mop enabled ! interface Serial 0 description US-Washington link to ICMnet ip address 192.121.154.241 255.255.255.240 bandwidth 768 delay 5000 ! interface Ethernet 1 description 123456789012345678901234567890123456789012345678901234567890 no ip address shutdown ! interface Serial 1 description London link to Mercury/ULCC ip address 192.121.154.33 255.255.255.240 ! interface Ethernet 2 description Peters test RBS ip address 192.108.209.1 255.255.255.0 bandwidth 1984 ! interface Serial 2 description SWIPnet RBS connection to HUB-3 ip address 130.244.7.1 255.255.255.248 bandwidth 1984 ! ! autonomous-system 1755 ;If we talk EGP this is needed ! router igrp 1755 ;Ebone kernel IGRP network 192.121.154.0 ;only on the Ebone network passive-interface Serial0 ;not used on US link ! router bgp 1755 ;BGP process network 192.121.154.0 ;only the Ebone netwirk is I neighbor 192.121.154.18 remote-as 1755 ;IBGP with EBS-2 neighbor 192.121.154.20 remote-as 1102 ;BGP with the Kludge region neighbor 130.244.7.2 remote-as 1257 ;BGP to Swipnet region neighbor 192.108.209.2 remote-as 1756 ;BGP to the test region neighbor 192.121.154.242 remote-as 701 ;BGP to ICM/Alternet neighbor 192.121.154.242 distribute-list 5 out ;Don't announce US to US neighbor 130.244.7.2 distribute-list 20 in ;Ripe registerd networks neighbor 192.108.209.2 distribute-list 21 in ;for each region ! ip default-network 129.140.0.0 ;deafult routing ip default-network 140.222.0.0 ;for any unknown destination ! ip domain-name ebone.net ip name-server 192.36.125.2 ip name-server 192.36.143.3 snmp-server community public ro snmp-server community ebone rw access-list 5 deny 129.140.0.0 access-list 5 deny 140.222.0.0 access-list 5 permit 0.0.0.0 255.255.255.255 access-list 20 permit 192.108.204.0 access-list 20 permit 192.108.205.0 access-list 20 permit 192.108.206.0 access-list 20 permit 192.108.207.0 access-list 20 permit 192.108.200.0 access-list 20 permit 192.108.201.0 access-list 20 permit 192.108.202.0 access-list 20 permit 192.108.203.0 access-list 20 permit 192.108.196.0 access-list 20 permit 192.108.197.0 access-list 20 permit 192.108.198.0 access-list 20 permit 192.36.143.0 access-list 20 permit 192.108.199.0 access-list 20 permit 192.108.195.0 access-list 20 permit 192.108.212.0 access-list 20 permit 192.108.213.0 access-list 20 permit 192.108.214.0 access-list 20 permit 192.108.215.0 access-list 20 permit 192.108.208.0 access-list 20 permit 192.108.209.0 access-list 20 permit 192.108.210.0 access-list 20 permit 192.108.211.0 access-list 20 deny 0.0.0.0 255.255.255.255 access-list 21 permit 192.36.115.0 access-list 21 permit 192.36.226.0 access-list 21 permit 192.36.215.0 access-list 21 permit 192.36.35.0 access-list 21 permit 192.108.213.0 access-list 21 permit 192.16.146.0 .... ..... access-list 21 permit 192.16.124.0 access-list 21 permit 140.150.0.0 access-list 21 permit 141.192.0.0 access-list 21 permit 192.121.7.0 access-list 21 permit 192.66.150.0 access-list 21 deny 0.0.0.0 255.255.255.255 banner motd  This is EBS-1 on Ebone in Stockholm Sweden For operational problems contact staff@swip.net or telephone +46 20 92 50 50  hostname EBS-1 APPENDIX C RBS configuration guidelines. C.1 Simple RBS to EBS with a region that uses IGRP and RIP. ! interface Ethernet 0 ip address 192.36.143.2 255.255.255.0 ! interface Serial 0 ip address 192.108.201.1 255.255.255.0 bandwidth 14 ! interface Ethernet 1 ip address 192.108.207.1 255.255.255.0 ! interface Serial 1 ip address 192.108.205.2 255.255.255.0 bandwidth 1900 ! interface Serial 2 ip address 192.108.209.2 255.255.255.0 bandwidth 2048 ! interface Serial 3 ip address 192.108.206.2 255.255.255.0 bandwidth 168 ! interface Serial 4 no ip address shutdown ! interface Serial 5 no ip address shutdown ! ! ! router bgp 1756 ;the as of my region network 192.36.143.0 ;a list of networks i have in my network 192.108.206.0 ;IGP, that i want to announce with network 192.108.205.0 ;BGP to ethe EBS network 192.108.209.0 network 192.108.196.0 network 192.108.197.0 network 192.108.195.0 network 192.108.200.0 network 192.108.198.0 network 192.108.199.0 network 192.108.201.0 neighbor 192.108.209.1 remote-as 1755 ;this is the session to the EBS ! router rip ;local ethernet has RIP, yeeck! default-metric 2 network 192.36.143.0 redistribute static ;dubble yeeck! passive-interface Serial0 ! router igrp 1756 ;this is the igrp used in my network 192.108.201.0 ;regional network network 192.198.207.0 network 192.108.205.0 network 192.108.206.0 ! ip default-network 129.140.0.0 ;when no explicit route is avaliable ip default-network 192.121.154.0 ;pass traffic to a higher level. ip default-network 192.121.154.0 ;this is the Stockholm EBS network ! snmp-server community public RO snmp-server community Ebone RW ! hostname Stupi-RBS ! end C.2 RBS that talks to both another regional RBS and a EBS. ! ! interface Ethernet 0 ip address 192.36.125.15 255.255.255.0 ip broadcast-address 0.0.0.0 ! interface Serial 0 ip address 130.244.3.9 255.255.255.248 bandwidth 10 ! interface Ethernet 1 ip address 130.237.210.15 255.255.255.0 no ip proxy-arp ! interface Serial 1 no ip address shutdown ! interface Ethernet 2 ip address 192.36.148.26 255.255.255.240 ! interface Serial 2 no ip address shutdown ! interface Ethernet 3 ip address 130.244.3.241 255.255.255.248 Description: Point-To-Point ethernet to Sunet ! .. .. ! interface Serial 11 ip address 130.244.7.2 255.255.255.248 bandwidth 2048 Description: 2.048 to EBS-1 ! ! autonomous-system 1257 ! router igrp 1257 ;this is our igrp for regional network 130.244.0.0 ;routing network 192.36.148.0 network 192.36.125.0 distance 98 ;if more than one IGRP are running redistribute static ;prefer our own routes over others. passive-interface Serial11 ; and don't send IGRP to the EBS ! router bgp 1257 network 130.244.0.0 network 192.36.148.0 network 192.36.125.0 network 192.108.206.0 network 192.16.143.0 network 132.196.0.0 network 134.138.0.0 network 192.71.236.0 network 192.121.204.0 network 192.36.19.0 network 192.36.220.0 network 192.36.221.0 network 192.16.141.0 network 192.71.15.0 network 192.71.168.0 .. .. network 192.36.188.0 network 192.71.247.0 neighbor 130.244.3.242 remote-as 1653 ;RBS to RBS (Link to Sunet) neighbor 130.244.7.1 remote-as 1755 ;RBS to EBS neighbor 130.244.7.1 distribute-list 3 out ;do not announce T1 and T3 ! router igrp 1653 ;this is Sunet routing network 130.244.0.0 network 130.237.0.0 passive-interface Serial11 ;stay off the EBS ! ip default-network 129.140.0.0 ;default routing ip default-network 192.121.154.0 ;EBS networks ! ! ! snmp-server community Ebone RW 1 snmp-server community public RO 1 ! access-list 3 deny 129.140.0.0 access-list 3 deny 140.222.0.0 access-list 3 permit 0.0.0.0 255.255.255.255 C.3 Using a router to turn IGRP<->BGP as a temporary kludge. ! interface Ethernet 0 description Ebone stub in sthlm ip address 192.121.154.20 255.255.255.240 no ip proxy-arp ! interface Serial 0 description amsterdam link ip address 192.121.158.18 255.255.255.240 bandwidth 256 ! interface Ethernet 1 no ip address shutdown ! ! autonomous-system 1102 ! router igrp 1755 ;this sits on the Ebone ethernet network 192.121.154.0 ;but is interacting as a RBS network 192.121.158.0 passive-interface Serial0 ;Dont give igrp 1655 to Amsterdam ! router bgp 1102 ;announce what we hear from distribute-list 21 out igrp 1102 ;Amsterdam with BGP 1102 to the EBS network 192.121.154.0 network 192.16.126.0 network 192.121.158.0 redistribute igrp 1102 neighbor 192.121.154.17 remote-as 1755 ;peer with Stockholm EBS-1 ! router igrp 1102 ;Turn BGP derivated routes into IGRP distribute-list 20 out ;the RIPE access-list default-metric 10000 2000 255 100 1500 ;with those metrics network 192.121.158.0 redistribute bgp 1102 metric 1000 neighbor 192.121.158.17 passive-interface Ethernet0 ! ip default-network 129.140.0.0 ! banner motd  This is EBS-4 on Ebone For operational problems contact staff@sunet.se or telehone +46 8 24 11 41  hostname EBS-4 APPENDIX D US connectivity and backup guidelies. APPENDIX E Tutorial on BGP and OSPF. P Lothberg The intent of this small tutorial is not to cover neither BGP3 or OSPF in deep, but to give a summarized breefing on the subject, in order to help the naive reader to more easy understand the Ebone routing model. BGP, --- BGP is a Inter-domain protocol, designed to be used as an domain to domain routing protocol. BGP is designed to be able to handle policy based routing, detect routing loops and has the possibilitie of using metrics so that intelligent routing decisions may be made by the routers. BGP does not impose topology restrictions like EGP does since it has the mechanism of detecting routing loops. BGP carries AS path information which *might* allow for policy based routing. BGP does incremental update which consume less resource of bandwidth, CPU of routers than periodic update routing protocols such as EGP. BGP is today slowly replacing EGP in large networks. Although designed as an interdomain protocol, BGP may be used both within and between domains. Two BGP neighbors communicating between domains much reside on the same physical network. BGP routers within the same domain communicate with one another for two reasons: - to ensure that they have a consistent view of the domain - to determine which BGP router within that domain will serve as the connection point to/from certain external domains Running BGP within a IGP are given the term IBGP, and most routers that implements BGP have this facility and maintain their BGP routing tables separated from the IGP and forwarding tables. Some domains are transit networks, in other words, some domains carry network traffic that did not originate within and is not destinated for them. BGP must interact with whatever intra-domain routing protocols used within these domains. Ebone is such a transit network, no routes is generated within the domain, it only transfers routing between its boarders. These interactions, while beyond the scope of this document, are detailed in the BGP protocol specification. OSPF is one of the few IGP protocols that have the hooks to be able to "avoid" the use of both a IBGP and IGP within a network that are transit, but there are no implementations comercially avaliable, yet. BGP update messages consist of network number/domain path pairs. The domain path contains the string of domains through which the specified network may be reached. These update messages are sent over the TCP reliable transport mechanism. The initial data exchange between two routers is the entire BGP routing table. Incremental updates are sent out as the routing tables change. Unlike some other routing protocols, BGP does not require periodic refresh of the entire routing table. Instead, routers running BGP retain the latest version of each peer routing table. Although BGP maintains a routing table with all feasible paths to a particular network, it only advertises the primary (optimal) path in its update messages. The BGP metric is an arbitrary unit number specifying the "degree of preference" of a particular path. These metrics are typically assigned by the network administrator through configuration files. Degree of preference may be based on any number of criteria, including domain count (paths with smaller domain count are generally better), type of link (is the link stable?, fast? reliable?), and other factors. OSPF ---- OSPF Open Shortest Path First, is a intra-domain hierarcical routing protocol. Information on attached interfaces, metrics used, and other variables are included in OSPF routing updates. This information is flooded throughout the routing area. As OSPF routers accumalate link state information, they are able to calculate the shortest path path to each node. Updates are only required when a link state changes. "Hello"messages act as keepalives to let routers know that other routers are still functional. Additional OSPF features include equal cost multi-path routing and routing based on upper-layer type of service (TOS) requests. TOS-based routing supports those upper-layer protocols that can specify particular types of service. For example, an application might specify that certain data is urgent. If OSPF has high priority links at its disposal, these may be used to transport the urgent datagram. OSPF supports one or more metrics. If only one metric is used, it is considered to be arbitrary, and TOS is not supported. If more than one metric is used, TOS is optionally supported through the use of a separate metric (and, therfore, a separate routing table) for each of the eight combinations created by the three IP TOS bits (the "delay", "throughput" and "reliable" bits). For example, if the IP TOS bits specify low delay, low throughput and high reliability, OSPF calculates routes to all destinations based on this TOS designation. Obviously, this calculations can be extremely resource intensive. APPENDIX E Ebone objects in RIPE database, proposal, T. Bates and P. Lothberg 1992 03 15 In order guarantee the rubustnes of the Ebone core against errounous routing information beeing propagated some kind of checking of routing information supplied by the EBS from an RBS has to be done. This is NOT intended for enforcing any policy (any policy has to be implemented by the RBS), just as a housekeeping tool. In order to avoid dubbeling the work performed by the RIPE NCC, ie maintain an Ebone routing database in pararell with the RIPE NCC database our proposal is to add this information into the RIPE database. Besides the savings in work, we think it will motivate networkers in Europe to update their information in the RIPE database. To ease the operations Ebone and create tools for troubleshooting some additional information is needed for a given network. - The AS number where this network number belongs. - A list of via wich AS numbers peering with an EBS this network is reachable, in priority order. Example: net: 192.108.200.0 con: Ripe|Nfs|swip|Ebone as: 1257 path: 1257|1654 Net and Con together with all existing information, no change. AS, is the as where this network belongs, the normal case is the region where it is connected. (Region in the term some collection of network(s) connected to an RBS.) Path, is a list of AS numbers belonging to RBSs peering directly with and EBS that has connectivity to the network and has agreed to transit trafic. In the case of multiple connections to Ebone, they has to implement the same policy as the primary path. Otherwise we will have black wholes instead of true redundancy. 192.108.200.0 are within the Swipnet AS (1257) and as the Swipnet-RBS peers direct with the Stockholm EBS, 1257 is the prefered way out from Ebone to this destination. Swipnet and Sunet (1654) has a bi-lateral agreement of backing eachother, so they talk IBGP between themself outside Ebone so that in the routing from the Sunet RBS all the 1257 routes will appear (and vice versa), but with a longer AS-path than the one throgh the Swipnet RBS. If 192.108.200.0 are announced from any other AS peering with Ebone, this is in error and shold be discarded. This is acomplished by generating a inbound routing filter list for the EBSs based on information derivied from the RIPE database. A suggestion is that this table updates will take place two times a week, mondays and thursdays, to allow one workday after each change. A databese over Regions, their ASes and contact persons would also be a usefull tool.