Autonomes System

Ein autonomes System (kurz AS) ist, laut klassischer Definition[1], eine Menge von Routern (die mehrere Netzwerke verbinden) mit einem gemeinsamen inneren Gateway-Protokoll (IGP) und gemeinsamen Metriken, die bestimmen, wie Pakete innerhalb eines AS vermittelt werden, unter einer einzigen technischen Verwaltung.

Allerdings ist es nicht mehr unüblich, in einem AS mehrere IGP und mehrere Sätze von Metriken zu verwalten. Ein autonomes System ist dann ein System, das sich anderen autonomen Systemen so präsentiert, als hätte es nur einen einzigen inneren Routing-Plan, um ein beständiges Bild davon abzugeben, welche Ziele (z. B. andere Netzwerke) durch dieses System erreicht werden können.[2][1]

Autonome Systeme sind untereinander verbunden und bilden so das Internet.

Verwaltung

Jedem autonomen System wird eine eindeutige AS-Nummer (Autonomous System Number, ASN) zugewiesen. Diese sind definiert als 32-Bit-Ganzzahl (RFC 6996; historisch: 16 Bit, RFC 1930). Private ASN, die nicht zur Verwendung im Internet, sondern nur innerhalb einer Organisation vorgesehen sind, liegen im Bereich von 64512 bis 65534 (FC00_hex … FFFE_hex) für 16-Bit-Nummern bzw. für 32-Bit-AS-Nummern im Bereich 4200000000 bis 4294967294 (FA56EA00_hex … FFFFFFFE_hex). Ende August 2016 waren 54.969 AS-Nummern vergeben[3]. Die Erweiterung auf 32 Bit lange ASN ist abgeschlossen und wird unter anderem seit 2007 auch vom RIPE NCC unterstützt. Seit dem 1. Januar 2009 werden von RIPE NCC 32-Bit-AS-Nummern als Standard vergeben, es ist aber noch möglich, ASN mit einer Länge von 16 Bit (d. h. aus dem Bereich 1-64511) zu beantragen.[4]

Die Verwaltung der ASN übernimmt die Internet Assigned Numbers Authority (IANA). Diese delegiert die Zuteilung weiter an die Regional Internet Registries (RIR). Dies sind ARIN (Nordamerika), RIPE NCC (Europa, Naher Osten und Zentralasien), APNIC (Asien-Pazifik), LACNIC (Lateinamerika, Karibik) und AfriNIC (Afrika). Um eine AS-Nummer zu erhalten, muss ein ISP mit mindestens zwei anderen autonomen Systemen ein dynamisches Routingprotokoll verwenden (in der Regel sinnvollerweise BGP; aber auch andere wie z. B. das Vorläufer-Protokoll von BGP (EGP) oder das theoretisch auch als Intradomain-Routingprotokoll verwendbare EIGRP sind denkbar). Werden mit nur einem AS Routen ausgetauscht, kann dies über private AS-Nummern, über statisches Routing oder andere Lösungen erfolgen.

Durch die Aufteilung des Internets in autonome Systeme wird eine bessere Skalierbarkeit durch eine Reduzierung des Speicherplatzes sowie des Übertragungsbedarfs der zum Routing notwendigen Informationen erreicht (Hierarchisches Routing): Da nicht mehr die Netzwerktopologie auf Basis einzelner Router, sondern auf Basis von Netzwerken übermittelt wird, reduziert sich der Informationsaufwand deutlich.

Routing

Für das Routing innerhalb eines AS, das sogenannte Intra-AS-Routing, ist der Betreiber verantwortlich; für das Inter-AS-Routing zwischen den autonomen Systemen gibt es einheitliche Standards. Inter-AS-Routing-Protokolle heißen auch Exterior-Gateway-Protokoll (EGP). Das einzige derzeit weltweit eingesetzte EGP ist das Border Gateway Protocol (BGP). Mit BGP setzt man das sogenannte policy-basierte Routing um, welches weiter unten in einem eigenen Abschnitt beschrieben ist.

Intra-AS-Routing-Protokolle heißen auch Interior Gateway Protocol (IGP). Beispiele sind das Routing Information Protocol (RIP), das Open Shortest Path First (OSPF) oder das IS-IS (Intermediate System to Intermediate System Routing Protocol).

Kunden, Peers, Provider

Beim Inter-AS-Routing wird (auf einer Meta-Ebene) typischerweise zwischen Kunden, Peers und Providern unterschieden:

Ein anderes autonomes System ist mein Kunde („Customer“; „downstream“), wenn er mir Geld dafür zahlt, dass er über eine direkte Leitung („Link“) mit mir (und über mich mit dem Rest des Internets) Daten austauschen kann.
Ein anderes autonomes System ist umgekehrt mein Provider („upstream“), wenn ich ihm Geld dafür zahle, dass ich über eine direkte Leitung („Link“) mit ihm und dem Rest des Internets Daten austauschen kann.
Sind zwei autonome Systeme ähnlich groß, wichtig, einflussreich und gut angebunden, so können sie sich darauf einigen, dass sie die Kosten für direkte Leitungen untereinander teilen. In diesem Fall gibt es weder Kunde noch Provider, sondern man spricht von gleichberechtigten Peers. (Diese Peers sollten nicht mit den Peers eines Peer-to-Peer-Netzes verwechselt werden.)
Die ganz großen Internet-Provider, welche nur Kunden und Peers haben, aber nirgendwo die Rolle eines Kunden einnehmen, bezeichnet man auch als Tier-1-Provider. Autonome Systeme, die ausschließlich Kunden von Tier-1-Providern sind, nennt man auch Tier-2-Provider. Allgemein ließe sich die Zugehörigkeit zu Tier-n definieren als die Kunden von Tier-(n-1); üblicherweise werden solche Unterscheidungen jedoch nicht gemacht.
Daneben gibt es auch noch sogenannte Sibling-Beziehungen zwischen Autonomen Systemen (englisch für Geschwister). Sie tritt beispielsweise auf, wenn eine Firma von einer anderen übernommen wird, jedoch die Netzwerke der beiden Firmen jeweils ihre eigenen ASN behalten.

Die Unterscheidung zwischen Kunden, Providern und Peers findet nur auf einer Meta-Ebene statt – in den vom Routing-Protokoll übermittelten Daten spiegelt sie sich nur indirekt wider, nämlich insbesondere in der Festlegung der Routing-Policys.

Stub-AS, Transit-AS, Multihoming

Je nachdem, ob ein AS einen End- oder einen Zwischenknoten im übergeordneten Netz bildet, unterscheidet man folgende AS-Typen:

Stub-AS sind über genau einen Link an genau einen Provider angeschlossen (Endknoten). Eigentlich sollte es Stub-AS nicht geben, da gemäß Vergabekriterien für AS mindestens zwei Provider vorhanden sein müssen.
Dualhomed Stub-AS sind über mehr als einen Link an genau einen Provider angeschlossen.
Multihomed AS sind aus Gründen der Ausfallsicherheit über mehrere Links an mindestens zwei verschiedene Provider angeschlossen (Endknoten)[5].
Transit-AS sind an andere Transit-AS angebunden und stellen die Serviceprovider für die vorgenannten drei Typen in der Form von Internet-Backbone-Netzwerken dar (Zwischenknoten). Ein Transit-AS ist also immer ein Provider für mindestens ein anderes AS.

Policybasiertes Interdomain-Routing

Die Grundzüge üblicher Policys für das Weiterleiten von Routinginformationen lassen sich folgendermaßen zusammenfassen:

Ist ein autonomes System mein Kunde, so teile ich ihm alle meine Routen mit, die ich kenne: Ich möchte es meinem Kunden ermöglichen, möglichst viel seines Verkehrs über mich abzuwickeln, weil ich damit Geld verdiene – normalerweise wird der Verkehr zwischen autonomen Systemen nämlich nach Volumen abgerechnet.
Ist ein autonomes System mein Provider, so teile ich ihm die Routen zu meinen Kunden mit, damit meine Kunden erreichbar sind und ich an ihnen verdienen kann. Ich teile meinem Provider aber nicht die Routen zu meinen Peers oder gar zu meinen anderen Providern mit: Ansonsten müsste ich für die über mich übertragenen Daten mehr Geld an meinen Provider bezahlen, würde aber nicht mehr verdienen (bei Peers) oder, noch schlimmer, müsste sogar zweimal bezahlen (nämlich auch an meinen zweiten Provider).
Gleiches gilt für Peers: Ich teile einem Peer nur Routen zu meinen Kunden mit, damit meine Kunden auch über den Peer erreicht werden können und ich für diese Verkehrswege kein Geld an meinen Provider zahlen muss. Allerdings teile ich meinem Peer keine Routen zu meinem Provider mit, da er ansonsten auf meine Kosten Daten austauschen kann, ohne dass ich daran verdiene. Meistens teile ich meinem Peer auch keine Routen zu meinen anderen Peers mit, da er ansonsten unnötig mein Netzwerk belastet, ohne dass ich daran verdiene.

Ein solches rein wirtschaftlich gesteuertes policybasiertes Routing resultiert meistens in Wegen, die technisch nicht optimal sind. Beispielsweise könnten theoretisch zwei Router bei verschiedenen Providern Daten über einen Router bei einem gemeinsamen Kunden austauschen und wären in diesem Fall nur zwei Hops voneinander entfernt – allerdings verbietet sich ein solches Szenario: der Kunde wird eine solche Wegewahl nicht zulassen, da er dabei finanzielle Verluste erleiden würde.

Beispiele

Typischerweise haben ISPs, aber auch große internationale Unternehmen und einige Hochschulen sowie zivilgesellschaftliche Organisationen, eigene AS-Nummern. Beispiele:

Deutsches Zentrum für Luft- und Raumfahrt	AS28
Europäische Weltraumorganisation	AS288
CERN	AS513
BelWü	AS553
DFN	AS680
Deutsche Telekom	AS3320
Vodafone	AS3209
freenet.de	AS5430
Wikimedia Foundation	AS14907 (USA) bzw. AS43821 (Europa)
Universität Frankfurt	AS20633
Der Träger von Freifunk in München: Freie Netze München e. V.	AS212567

Weblinks

Einzelnachweise

RFC 4271: A Border Gateway Protocol 4 (BGP-4) (englisch, Januar 2006)
RFC 1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) (englisch, März 1996)
Tony Bates, Philip Smith, Geoff Huston. "CIDR report (Memento vom 28. Mai 2013 im Internet Archive)". Abgerufen am 26. August 2016, archiviert bei .
RIPE NCC: englische Bekanntmachung von RIPE NCC
Nick Feamster: Multihoming and Multi-Path Routing. Abgerufen am 23. November 2016.

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. The authors of the article are listed here. Additional terms may apply for the media files, click on images to show image meta data.

[RFC4271-1] RFC 4271: A Border Gateway Protocol 4 (BGP-4) (englisch, Januar 2006)

[RFC1930-2] RFC 1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) (englisch, März 1996)

[3] Tony Bates, Philip Smith, Geoff Huston. "CIDR report (Memento vom 28. Mai 2013 im Internet Archive)". Abgerufen am 26. August 2016, archiviert bei .

[RIPE_NCC-4] RIPE NCC: englische Bekanntmachung von RIPE NCC

[5] Nick Feamster: Multihoming and Multi-Path Routing. Abgerufen am 23. November 2016.