SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Multihomed ISPs and Policy Control <draft-ohta-multihomed-isps-00>

edolie avatar
edolie
16 diapositives · 332 Views · Sep 16, 2014

Multihomed ISPs and Policy Control <draft-ohta-multihomed-isps-00>. Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp. All the Hosts Should have Full (Default Free) Routing Table. Best locator of a peer from multiple ones absence of a TLA in the table means

#multihomed isps and policy control &lt;draft-ohta-multihomed-isps-00&gt; #multihomed isps and policy control &lt;draft-ohta-multihomed-isps-00&gt; ppt #powerpoint #presentation
Multihomed ISPs and Policy Control &lt;draft-ohta-multihomed-isps-00&gt; - slide 1
01 / 16Multihomed ISPs and Policy Control &lt;draft-ohta-multihomed-isps-00&gt;
1 / 17

Télécharger la présentation

Multihomed ISPs and Policy Control &lt;draft-ohta-multihomed-isps-00&gt;
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. Multihomed ISPs andPolicy Control<draft-ohta-multihomed-isps-00> Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp

  2. All the Hosts Should haveFull (Default Free) Routing Table • Best locator of a peer from multiple ones • absence of a TLA in the table means • routing system has detected the TLA is unreachable • metric entry of the table gives preference • Metric can be set according to the policy of a site • Source address selection for ingress filtering • no forwarding or source address based routing! • use source address entry (new!) of the table • selection is hard, unless routing system is involved

  3. IP Version 6 Addressing Architecture (RFC237[34]) • IPv6 addresses has STRONG hierarchy • 13 bits of TLA (Top Level Aggregator) • 24 bits of NLA (Next Level Aggregator) • Hierarchy of ISPs is assumed • TLIs (Top Level ISPs) get globally unique TLAs • NLIs (Next Level ISPs) get NLAs unique within TLA

  4. | 3| 13 | 8 | 24 | 16 | 64 bits | +--+-----+---+--------+--------+--------------------------------+ |FP| TLA |RES| NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+-----+---+--------+--------+--------------------------------+ <--Public Topology---> Site <--------> Topology <------Interface Identifier-----> IP Version 6 Addressing Architecture

  5. Multihomed ISPs • Why multihoming is necessary? • Robustness! • May NLIs be not so robust? • No! • NLIs MUST be multihomed to TLIs

  6. TLI NLI Subscribers Typical Scenario of IPv6 ISPs with Multihoming

  7. The Question • Can the number of TLAs limited? • Can NLIs be happy enough that not all ISPs require TLAs • Can NLIs control policy? • How much is the limit? • No question: how the limit is imposed • to be determined by global/regional/country NICs

  8. Can NLIs Control Policy? • ISPs are identified by AS#s • An NLI must peer with its TLI • the NLI may peer with any other ISP • Full egress control by NLIs possible • Ingress control? • Already limited today • locally possible if compatible with egress control

  9. ISP B ISP C ISP D ISP E ISP A ISP F ISP G ISP H ISP I policy essentially determined as egress ones (local arrangement negotiable) Propagation of Prefix of ISP A

  10. Ingress Control • Possible as long as NLA is propagated • An NLI can ask neighbor ISPs for the propagation • The NLA will be filtered by other ISPs • the NLI can still receive packets to NLA from corresponding TLA • not really a limitation

  11. ISP B (TLI of A) ISP C ISP D ISP E ISP A (NLI) ISP F ISP G ISP H ISP I arrangements with D, H, E and I necessary for ingress control Propagation of Prefix of ISP A

  12. ISP B (TLI of A) ISP C ISP D ISP E ISP A (NLI) ISP F ISP G ISP H (filter NLA) ISP I arrangement with H fail Propagation of Prefix of ISP A

  13. ISP B (TLI of A) ISP C ISP D ISP E ISP A (NLI) ISP F ISP G ISP H (pass NLA) ISP I Propagation of Prefix of ISP A

  14. ISP B (TLI of A) ISP C ISP D ISP E ISP A (NLI) ISP F ISP G ISP H (filter NLA) ISP I Propagation of Prefix of ISP A

  15. How Much is the Limit? • A lot larger than the number of those ISPs which claims to be global (tier1) • Much larger than the number of NICs • Better to be compatible with RFC237[34] • 1024~8192?

  16. Conclusion • NLIs must be multihomed to TLIs • NLIs policy can still be controlled • The number of TLAs should be limited below 1024~8192