Routing Challenges and Proposals (IS-IS) Suman Pandey DP&NM Lab. Dept. of Computer Science and Engineering POSTECH, Pohang Korea Email: {suman}@postech.ac.kr http://dpnm.postech.ac.kr/

Outline Measurement metrics for IS-IS Main Challenges of Routing ietf survey STOC’08 survey General Routing Research Efforts from Research Communities Trilogy PSIRP IRTF RING Explain one of the Key research for solving Scalability issues in inter domain and intra domain routing. CRIO Conclusion and future work

IS-IS measurements (RFC 4444) System-Wide Attributes isisSystem This table contains information specific to a single instance of the IS-IS protocol running on a router. isisManAreaAddr This table includes area addresses that are manually configured, which are used to control the associations formed between Level 1 Intermediate Systems. isisAreaAddr This table includes area addresses reported in relevant L1 LSPs. isisSummAddr This table holds summary addresses configured for each Level 2 instance of the IS-IS protocol running on a router. isisRedistributeAddr This table provides criteria to decide whether a route should be leaked from L2 to L1 when Domain Wide Prefix leaking is enabled isisRouter This table holds the hostname and router ID for Intermediate Systems in the network. isisSysLevel This table contains information specific to a domain (Level 2) or an area (Level 1) of the IS-IS protocol. isisNextCircIndex This scalar is used to provide a unique circuit index. Circuit-specific Attributes isisCirc This table contains information specific to a point-to-point or a broadcast interface in the system. isisCircLevel This table contains information specific to Level 1 or Level 2 of an interface. Counters isisSystemCounter Counters in the System table, such as number of times we have wrapped a sequence counter on one of our Link State PDUs. – isisCircuitCounter Counters of events particular to a circuit, such as PDUs with an illegal value of the System ID field length. isisPacketCounter Counts of IS-IS Protocol PDUs broken down into packet type. Attributes associated with an Adjacency isisISAdj This table contains information about adjacencies to routers maintained by the protocol. Entries in this table cannot be created by management action: they are established through the Hello protocol. isisISAdjAreaAddr This table contains the set of Area Addresses of neighboring Intermediate Systems, as reported in IIH PDUs. isisISAdjIPAddr This table contains the set of IP Addresses of neighboring Intermediate Systems, as reported in received IIH PDUs. isisISAdjProtSupp This table contains the set of protocols supported by neighboring Intermediate Systems, as reported in received IIH PDUs. Attributes Associated with Addresses isisRA The Reachable Address Table. This table contains information about an address prefix manually configured on the system or learned through another protocol. isisIPRA The IP Reachable Address Table. This table contains information about an IP reachable address manually configured on this system or learned from another protocol. Attributes Associated with Link State PDU Table isisLSPSummaryTable The Link State PDU Summary Table. This table contains information contained in the headers of Link State PDUs stored by the system. isisLSPTLVTable The Link State PDU TLV Table. This table holds the sequence of TLVs that make up an LSP fragment. Attributes Associated with a Notification isisNotification This table defines attributes that will be included when reporting IS-IS notifications.

Design Goals for Scalable Internet Routing http://www.ietf.org/internet-drafts/draft-irtf-rrg-design-goals-01.txt Improved routing scalability (required) Routing security (required) Deployability (required) Routing quality (strongly desired) Scalable support for multihoming (strongly desired) Scalable support for traffic engineering (strongly desired) Simplified renumbering (strongly desired) Decoupling location and identification (desired) Scalable support for mobility (desired)

Main Challenges STOC’08, May 17–20, 2008, Victoria, British Columbia, Canada. ACM 978-1-60558-047-0/08/05. Local policies: The nodes in the graph are controlled by different Autonomous Systems (ASes) that have their own (possibly conflicting) ideas about which paths are good. Greedy and adversarial nodes: Some nodes may intentionally try to manipulate the system to their own advantage, or to harm others. Scalability: The graph is very large, consisting of tens of thousands of ASes, millions of nodes, and billions of end hosts directing traffic through these nodes. Heterogeneity: The links may vary widely in their capacities and propagation delays, and the nodes in their computation and storage resources. Geographic distribution: The nodes are distributed all over the planet, and beyond. Topological churn: The topology changes over time due to equipment failure (and recovery), planned maintenance, and long-term growth. Multiple nodes and links may fail simultaneously, due to shared risks. Fast reaction to change: Most applications are intolerant of long disruptions in the delivery of data.

Efforts from Research Communities Collaborative projects within EU FP7 Trilogy: Renewing the Internet routing architecture – 3 years (2011) PSIRP: Replacing IP largely with pub-sub-oriented internetworking layer – 2 years (2010) IRTF: Part of IETF. The proposals are standardized here RING: Routing in Next Generation Onelab2: experimental efforts (currently submitted) EIFFEL: Caretaker (partner) and one of the main contributors

Re-Architecting the Internet Trilogy Re-Architecting the Internet http://www.trilogy-project.org The aim of Trilogy is to develop new solutions for the control architecture of the Internet that remove the known and emerging technical deficiencies while avoiding prejudging commercial and social outcomes for the different players. The focus is the control functions of the Internet – the neck of the hourglass, but for control.

First Concept First No separation between congestion control, routing mechanisms, and business demands (as reflected in policy). Re-architecting these mechanism and make it more coherent.

First Concept Develop a unified control architecture for the Future Internet that can adapt in a scalable, dynamic and robust manner to local operational and business requirements Develop and evaluate new technical solutions for key Internet control elements: reachability & resource control Assess commercial and social control aspects of architecture & technical solutions, including internal & external strategic evaluation The key is to allow the Internet to be different things in different places without hindering interoperability. In enabling tussles to play out within the architectural framework (as opposed to working against the architecture, as often happens today), Trilogy will permit differentiation, allowing greatly increased robustness for customers who really need it and have the means to pay. In addition, the enhanced flexibility and improved manageability will simultaneously allow service providers to reduce costs and provide additional services; two aspects that are critical in a world of falling communications margins where service providers are wondering where the money to upgrade their networks will come from in ten years time.

Second Concept Second (More Abstract) More sophistication in its control architecture, without imposing a single organizational model. Therefore, our key principles are to retain the ubiquity enabled by the hourglass model, and take the self-configuration philosophy one level further: seek a control architecture for the new Internet that can adapt in a scalable, dynamic, autonomous and robust manner to local operational and business requirements.

Second Concept Crudely: “Control” for “The Internet” “The Internet” == the bit which has to be universal Operate efficiently across arbitrary technologies Operate across arbitrary organizational/economic boundaries Isn’t this a done deal already? No! “The Internet Only Just Works” The absence of (usable) control mechanisms reduces it to a lowest-common denominator set of capabilities Vision of Convergence between mobile, fixed, public, private, home etc. Control architecture allows assumptions on ‘who controls what’ to shift but the technical scope is deliberately tightly focused We don’t look ‘downwards’ at particular link classes We don’t look ‘upwards’ at middleware, service support infrastructures, virtualization etc

Trilogy Interactions

Publish-Subscribe Internet Routing Paradigm PSIRP Publish-Subscribe Internet Routing Paradigm http://psirp.org/ The project aims to develop, implement and validate an internetworking architecture based on the publish-subscribe paradigm, which appears to be one of the most promising approaches to solving many of the biggest challenges of the current Internet. The consortium consists of eight partners from six European countries: Bulgaria (IPP-BAS), Finland (TKK-HIIT, LMF, NSNF), Germany (RWTH Aachen), Greece (AUEB-RC), Hungary (ETH), and United Kingdom (BT).

Why Publish/Subscribe Multimedia, including TV, is converging to the Internet We need efficient, secure dissemination and delivery of information We need to revise the Internet to meet the application’s requirements, handle the increasing traffic, and ensure availability We need to fix the imbalance of powers which currently is in the favor of the sender of information Subscriber-driven data delivery with authentication mitigates unwanted traffic Many applications are essentially publish/subscribe by nature Publish/subscribe is the most potential candidate paradigm for building the future Internet PSIRP bases its work on the publish-subscribe paradigm, which currently appears to be one of the most promising approaches to solving the main problems of the current Internet.

Approach Approaches: Internet Routing Incremental with overlay networks Radical clean-slate approach with a new networking stack Internet without IP Internet Routing We propose a new network design providing more trust and anonymity to Internet ensuring availability and rapid and accurate dissemination of crucial data The publish/subscribe model Subscibers and publishers of information Many-to-many communication Data-centric rendezvous, routing, forwarding

Example

Internet Research Task Force (Routing Research Group) Routing in Next Generation To promote research of importance to the evolution of the future Internet by creating focused, long-term and small Research Groups working on topics related to Internet protocols, applications, architecture and technology. http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup http://wiki.ist-ring.org/action.php

Some Proposals CRIO - The Core Router-Integrated Overlay (CRIO) reduces the sizes of the forwarding tables by setting up tunnels. LISP- The locator/identifier split (LISP) proposes to separate the locator and identifier functionality of IP addresses by a mapping service which is similar to the domain name system. Rbridges – Transparent Routing eFIT- (enable Future Internet innovation through Transitwire) is a proposal that implements this idea in a way which is compatible with the current Internet architecture. IPvLX- IP virtual link extensions (IPvLX) also use the idea of the locator/identifier split for routing of IPv6 addresses across IPv4 clouds.

CRIO Xinyang Zhang ,Paul Francis  , Jia Wang , Kaoru Yoshida “Scaling IP Routing with the Core Router-Integrated Overlay” , Proceedings of the Proceedings of the 2006 IEEE International Conference on Network Protocols

Goal Solves scalability problem Limits the unbounded growth of routing and forwarding system in internet

Why is Scaling a Problem? 200K Active BGP entries (FIB) 89 06 Date A glimpse of current routing system: Static table size Global IPv4 : ~ 200K entries VPN: ~800K entries And more routes are coming: IPV6, traffic-engineered, etc. Routing Dynamics BGP update churns Persistent instabilities Long convergence time (due to damping and MRAI timer) This talk is about the static characteristics of the scaling Validity of CRIO approach Looking into the future: Can we support a routing table twice (or 10 times) the size of today? Can we rely on the hardware advances to alleviate the scaling pressure?

CRIO Approach Tunneling Virtual Prefix Revisit old idea (by Deering) IP-GRE MPLS Decouples addressing from topology Virtual Prefix Novel approach Greatly shrink forwarding table

CRIO Tunneling: an Illustration Prefix TE Source Mapping Adv. 24.1.1.0/24 TE=PE2 PE2 ---- BGP Prefix TE Source 24.1.1.0/24 PE2 Mapping 24.1.1.0/24 ---- BGP/OSPF 24.1.1.0/24 PE3 Mapping Provider Networks PE1 PE2 24.1.1.1 PE2 24.1.1.1 PE3 24.1.1.1 Routing Adv. 24.1.1.0/24 NH=CE2 CE1 CE2 Customer Site C2 24.1.1.0/24 Customer Site C1

CRIO Tunneling: Benefits Separate Mapping from Routing CRIO tunneling effectively partitions the path into three distinct parts: UP: IP routing from the source to the TS. ACROSS: Tunneled from the TS to the TE. DOWN: IP routing from the TE to the destination. CRIO frees the routers in the across part of the path from having to compute BGP routes to all Internet destinations. Rather, BGP itself only needs to compute routes to the TE Prefix TE Prefix is aggregation of collection of address. On the order of one thousand entries Stable ISP provisioned prefixes Mappings are easy to distribute A mapping entry is the same no matter where it appears Support multi-homing without burdening the routing system

What about router’s forwarding table? CRIO tunneling can not shrink forwarding information Forwarding table is expected to get larger Since CRIO supports for fine-grained multi-homing Benefits for having small forwarding tables Smaller memory requirement on routers’ line cards Faster transfer for forwarding table updates

CRIO Virtual Prefix: an Illustration A virtual prefix is a super-prefix that spans a large portion of the address space Routers that advertise a given virtual prefix must hold the mappings for every prefix within the virtual prefix Prefix TE Source Routing Adv. 24.0.0.0/8 PE2 ---- BGP 24.1.1.0/24 PE2 Mapping 24.2.2.0/24 PE4 Mapping PE3 24.1.1.1 PE2 PE2 24.1.1.1 24.1.1.0/24 24.1.1.1 PE1 Customer Site CE2 Prefix TE Source PE2 ---- BGP PE3 ---- BGP 24.0.0.0/8 ---- BGP 24.1.1.0/24 PE2 Mapping 24.2.2.0/24 PE4 Mapping

CRIO Virtual Prefix: Trade-off Virtual prefixes provide a tuning knob for the router trade-off forwarding table size for path length Per-prefix basis It’s a good trade-off to make Few prefixes handle most traffic (power law) Routers could shed most of their prefixes with very little overall increase in traffic volume Save routers from handling large amount of mapping updates Virtual Prefix is particularly suitable for VPNs

Conclusions of CRIO CRIO is a new routing architecture, aimed to provide Scalable and stable core routing Reduce BGP RIB by two order of magnitude FIB size reduction Reduce FIB by one order of magnitude for global Internet, 10-20x for VPN

Conclusion Future work We saw the major challenges in routing Different on going work Elaborated the CRIO approach in detail Future work Understand more on going work Discuss manageability aspects of ongoing enhancements of routing.