1. Routing Challenges and Proposals (IS-IS)
Suman Pandey
DP&NM Lab.
Dept. of Computer Science and Engineering
POSTECH, Pohang Korea

2. 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

3. 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.

4. Design Goals for Scalable Internet Routing
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)

5. Main Challenges
STOC’08, May 17–20, 2008, Victoria, British Columbia, Canada. ACM /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.

6. 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

7. Re-Architecting the Internet
Trilogy
Re-Architecting the Internet
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.

8. 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.

9. 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.

10. 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.

11. 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

12. Trilogy Interactions

13. Publish-Subscribe Internet Routing Paradigm
PSIRP
Publish-Subscribe Internet Routing Paradigm
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).

14. 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.

15. 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

16. Example

17. 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.

18. 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.

19. 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

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

21. 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?

22. 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

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

24. 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

25. 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

26. 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. /8
PE BGP
/24 PE2 Mapping
/24 PE4 Mapping
PE3
PE2
PE2
/24
PE1
Customer
Site
CE2
Prefix TE Source
PE BGP
PE BGP
/ BGP
/24 PE2 Mapping
/24 PE4 Mapping

27. 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

28. 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

29. 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.