Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. EARNEST: The Future of Routing & Networking Technology HEAnet National Networking Conference 2007 15 November 2007, Kilkenny, Ireland
  2. 2. <ul><li>EC-funded GN2 project (35 NRENs including HEAnet ): </li></ul><ul><ul><li>Build and operate GÉANT2, the pan-European research and education backbone. </li></ul></ul><ul><ul><li>Joint Research Activities (JRA 1-5) to investigate and develop network enhancements. </li></ul></ul><ul><ul><li>Service Activities (SA 1-6) to procure network and connect NRENs. </li></ul></ul><ul><ul><li>Networking Activities (NA 1-7) to provide user support, dissemination, addressing digital divide, coordination activities, conferences and workshops, and undertake foresight study . </li></ul></ul><ul><li>GN2-NA4 = Education And Research Networking Evolution STudy (EARNEST) </li></ul>EARNEST Background
  3. 3. <ul><li>Aims to identify trends, developments, and to make recommendations for future research and education networks. </li></ul><ul><li>Seven sub-studies: </li></ul><ul><ul><li>Organisational and Governance issues </li></ul></ul><ul><ul><li>Economic issues (move to dark fibre, and provision of new services) </li></ul></ul><ul><ul><li>Researchers’ needs (what type of network and services are required?) </li></ul></ul><ul><ul><li>Other users’ needs (e.g. schools, healthcare, arts & humanities) </li></ul></ul><ul><ul><li>Geographic issues (examining and quantifying digital divide) </li></ul></ul><ul><ul><li>Campus issues (infrastructure, services, expertise and collaboration) </li></ul></ul><ul><ul><li>Technical issues (transmission, control plane & routing, network virtualisation, operations and performance, middleware) </li></ul></ul><ul><li>All sub-study reports plus final conclusions available shortly. </li></ul><ul><li> </li></ul>EARNEST Background
  4. 4. Technical Study Areas <ul><li>Transmission Technologies </li></ul><ul><ul><li>Fibre provisioning, transmission protocols, equipment evolution. </li></ul></ul><ul><li>Control Plane & Routing Technologies </li></ul><ul><ul><li>Switching & routing developments (optical & IP), IPvX, multicasting. </li></ul></ul><ul><li>Operations and Performance </li></ul><ul><ul><li>QoS vs overprovisioning, end-to-end performance, network management (optical & IP), network monitoring, PERT. </li></ul></ul><ul><li>Middleware </li></ul><ul><ul><li>AAIs, identity management, federations, mobility. </li></ul></ul><ul><li>Network Virtualisation </li></ul><ul><ul><li>Customer-enabled networks utilising virtual routers, lightpaths, VPNs, VLLs controlled by UCLP, DRAC etc.. </li></ul></ul>
  5. 5. Methodology & Caveats <ul><li>Technical panel with expertise in specific areas advised on important or emerging technologies. </li></ul><ul><li>Interviews with key personnel from 11 vendors, 3 research institutes, and a number of NRENs. </li></ul><ul><li>Technological briefings and research papers also used. </li></ul><ul><li>Primary goal was to investigate technologies applicable to NRENs, although attempts to address other types of network as well. </li></ul><ul><li>R&E networks often have different requirements to telco and ISP sectors, and usually have fewer legacy issues. </li></ul>
  6. 6. Transmission Technology Findings
  7. 7. Ethernet or SDH? <ul><li>No obvious path for SDH beyond OC-768 (40 Gbps), and likely to become legacy technology in coming years. </li></ul><ul><li>All manufacturers developing 40 and/or 100 Gigabit Ethernet because of cost advantages, and because packet-based services are increasingly prevalent. </li></ul><ul><li>Vendors don’t wish to repeat experience of having to support different variants of 10 GE (i.e. LAN-PHY, WAN-PHY). </li></ul><ul><li>Was initially expected that 100 GE would be next standard, but this is proving to be technically difficult. </li></ul>
  8. 8. Ethernet or SDH? <ul><li>100 GE implementations not expected before 2010, and likely later. </li></ul><ul><ul><li>Initially likely to be 4 x 25 Gbps and restricted to short-haul applications. </li></ul></ul><ul><ul><li>Full serial implementations not expected until at least 2012. </li></ul></ul><ul><li>40 GE may be interim solution as implementations possible by 2009 </li></ul><ul><ul><li>Expected to be 40% the cost of OC-768. </li></ul></ul><ul><ul><li>Supposedly intended for data centre applications, but some vendors talking about WAN capabilities (80 km before amplification/2000 km before regeneration). </li></ul></ul>
  9. 9. Ethernet Enhancements <ul><li>Ethernet scalability initially addressed with IEEE 802.1Q and 802.1ad. </li></ul><ul><li>PBB (IEEE 802.1ah) aims to greatly increase number of customer networks, and defines protocols for connecting provider-bridged networks. </li></ul><ul><li>Carrier-grade OAM&P and virtual circuit functionality is also currently being added: </li></ul><ul><ul><li>PBBTE (802.1Qay) will support point-to-point circuits over Ethernet. </li></ul></ul><ul><ul><li>CFM (802.1ag) will support hop-by-hop detection, isolation of connectivity problems </li></ul></ul><ul><ul><li>Shortest-Path Bridging (IEEE 802.1aq) being developed as alternative to Spanning Tree for loop-free forwarding. </li></ul></ul><ul><li> </li></ul>
  10. 10. DWDM Systems <ul><li>Trade-off between number of wavelengths, faster line rates and longer reaches due to CD, PMD, XPM and FWM. </li></ul><ul><li>New modulation techniques (e.g. DP-QPSK) are becoming practical and promise longer reaches at 40 Gbps+ speeds, whilst minimising need for EDCM. </li></ul><ul><li>Most manufacturers focusing on 50 GHz spacing for DWDM channels (i.e. ~80 channels per fibre). This has been found to provide optimal performance with respect to faster line rates and longer reaches. </li></ul><ul><li>Tunable lasers, VOAs, EDCMs, multi-degree ROADM technology, and PIC-based OEOs promise easier-to-facilitate (and potentially cheaper) DWDM systems. Also make meshed optical networks possible. </li></ul><ul><li>Passive Optical Networks (PONs) being trialled. </li></ul>
  11. 11. DWDM Systems <ul><li>Questions to ponder: </li></ul><ul><ul><li>There was a lot of hype about DWDM five years ago, but actually how important is this to NRENs? </li></ul></ul><ul><ul><li>Dark fibre is increasingly available to NRENs, but few fully exploit DWDM possibilities. </li></ul></ul><ul><ul><li>Why is the take-up of DWDM by NRENs so slow? </li></ul></ul><ul><ul><li>Is being ‘faster’ or ‘fatter’ more important to NRENs? </li></ul></ul>
  12. 12. Control Plane & Routing Findings
  13. 13. IP Routing <ul><li>Routing scalability becoming problematic (again). </li></ul><ul><ul><li>Huge rise in number of hosts, fragmentation of service provider hierarchy, increase in multihoming, and amount of traffic. </li></ul></ul><ul><ul><li>Global routing table now >230,000 entries, which generates around 400,000 BGP updates per day. </li></ul></ul><ul><ul><li>Concern that growth is starting to outstrip router chipset and memory developments, but more specifically the cost of provisioning these. </li></ul></ul><ul><ul><li>IPv6 doesn’t help as end-users unwilling to use provider-assigned addresses, or renumber when changing service providers. </li></ul></ul>
  14. 14. IP Routing <ul><li>Not immediate cause for concern, but IAB/IETF looking for efficiencies. </li></ul><ul><ul><li>Multihoming and traffic engineering should be possible. </li></ul></ul><ul><ul><li>Addresses should be provider-independent </li></ul></ul><ul><ul><li>Work with IPv6, and ideally IPv4. </li></ul></ul><ul><li>Proposals based on splitting IP addresses into identifiers and locators. </li></ul><ul><ul><li>End hosts would have unique identifier regardless of location (EID) </li></ul></ul><ul><ul><li>Locator used for intermediate routing, but is dynamically allocated in accordance with network location (RLOC) </li></ul></ul><ul><ul><li>Locator would be provider dependent and allow for better aggregation. </li></ul></ul>
  15. 15. IP Routing <ul><li>How to do it? </li></ul><ul><ul><li>NAT sort of achieves the same thing, but uses private IP addresses which introduce other problems. </li></ul></ul><ul><ul><li>e-FIT would use EIDs within user networks, and encapsulate packets using RLOCs in transit networks. Routing separated between networks. </li></ul></ul><ul><ul><li>LISP also uses encapsulation, but this happens at edge routers. Is transparent to BGP. </li></ul></ul><ul><ul><li>Six/One based on 8+8/GSE and shim6. Lowest 64-bits are unique identifer, but top 64-bits written by edge router (although hosts can suggest route). </li></ul></ul><ul><ul><li>EID-to-RLOC mapping: APT (all nodes hold limited database with default routes), NERD (all nodes hold complete database), and LISP-CONS (distributed query) </li></ul></ul><ul><ul><ul><li>What part of the network should have global overview? </li></ul></ul></ul><ul><ul><ul><li>How to determine default routes? </li></ul></ul></ul><ul><ul><ul><li>How dynamic can/should mapping be? </li></ul></ul></ul><ul><ul><ul><li>Security? </li></ul></ul></ul>
  16. 16. IPv6 <ul><li>Core IPv6 specifications and related protocols largely completed some years ago. </li></ul><ul><li>Most NRENs already support IPv6 in dual-stack systems, but also tend to have more IPv4 address space. </li></ul><ul><li>Some router and user equipment still has limited support. </li></ul><ul><li>Still limited support in most campuses. </li></ul><ul><li>New predictions suggest IPv4 address space could be exhausted in 3-5 years. </li></ul><ul><li>Regional Internet Registries discussing rationing measures. </li></ul>
  17. 17. IP Multicasting <ul><li>Never really taken off in past 20 years, but IPTV in context of ‘triple play’ increasing interest amongst service providers. </li></ul><ul><li>Increased availability to end-users may make it easier to deploy across Internet. </li></ul><ul><li>Inter-domain multicast routing still complex, although SSM may improve situation. </li></ul><ul><li>Automatic Multicast Tunnelling (ATM) allows hosts to find convenient multicast relay if native multicast not available. </li></ul><ul><li>Many peer-to-peer applications already multicast at application layer. </li></ul>
  18. 18. Dynamic-control of hybrid networks <ul><li>Lightpaths are still largely manually configured. </li></ul><ul><li>Optical and IP domains still managed separately. </li></ul><ul><li>GMPLS offers possibility of integrating IP routing and WDM control planes (amongst other things). </li></ul><ul><ul><li>In development for long time, but only just starting to be deployed using vendor-specific solutions. </li></ul></ul><ul><ul><li>Still signalling and interoperability issues to resolve, especially between domains. </li></ul></ul><ul><ul><li>Peer or overlay model? </li></ul></ul><ul><ul><li>Probably necessary for fully exploiting hybrid networks, but introduces more complexity. </li></ul></ul>
  19. 19. Network Virtualisation Findings
  20. 20. Network Virtualisation <ul><li>Virtualisation concepts starting to be used across all networking layers. </li></ul><ul><li>Basic virtualisation already implemented in certain modern routers to enable upgrades and troubleshooting of specific interfaces, and programmable features. </li></ul><ul><li>NRENs (e.g. CANARIE, CESNET) pioneered customer-empowered network concept, where resources on NREN-provisioned infrastructure can be managed by customers to build logical networks. </li></ul><ul><li>Deployment of UCLP, DRAC and similar technologies are first step towards full network virtualisation. </li></ul><ul><li>Need for technology agnostic infrastructure, although most users still want IP connectivity as part of service. </li></ul>
  21. 21. Network Virtualisation <ul><li>MANTICORE and FEDERICA projects aim to develop network virtualisation to allow disruptive technologies to be tested over production infrastructure. </li></ul><ul><li>US-based GENI initiative extends concept to wireless and sensor networks as well. </li></ul><ul><li>EARNEST study revealed there was little knowledge in wider R&E community about virtualisation initiatives, but lot of potential interest. </li></ul><ul><li>TERENA NGN Workshop (06/11/07) had session on network virtualisation/customer-empowered networks. </li></ul><ul><ul><li>Generated much discussion. </li></ul></ul><ul><ul><li>Support for information exchange and coordination activity (e.g. task force). </li></ul></ul><ul><li>Need a better term to describe all this though! </li></ul>
  22. 22. Operations & Performance Findings
  23. 23. Layer 0-2 Management <ul><li>NRENs have traditionally only managed Layer 3 and above, so have limited experience at the optical level (WDM systems and/or SDH). </li></ul><ul><li>Limited tools for managing Network Layers 0-2, and expensive. </li></ul><ul><ul><li>Although some R&E developments such as TL1 Toolkit and NDL. </li></ul></ul><ul><li>Management of Layers 0-2 is currently labour intensive and relies heavily on documentation. </li></ul><ul><li>NRENs have not really made extensive use of WDM systems to-date, and the management of much so-called dark fibre is often outsourced. </li></ul><ul><li>Is this something to investigate further? </li></ul>
  24. 24. Overprovisioning vs QoS <ul><li>Core networks likely to continue to be overprovisioned as bandwidth is (relatively) cheap. </li></ul><ul><li>Some edge networks do need to undertake traffic engineering though, so QoS transparency should be supported. </li></ul><ul><li>Increasing availability of dark fibre allows R&E networks to operate hybrid networks, enabling dedicated links to be provisioned for demanding customers using C/DWDM. </li></ul><ul><li>Should encourage innovation through network neutrality, subject to traffic engineering requirements. </li></ul>
  25. 25. End-to-End Connectivity <ul><li>Most end-to-end performance issues are due to problems at customer sites. </li></ul><ul><li>Middleboxes such firewalls, NATs, rate shapers, caches and other ‘black box’ solutions are responsible for many of these problems. </li></ul><ul><ul><li>This is due to instrinic architecture, misconfigurations, or simply intentional behaviour. </li></ul></ul><ul><ul><li>They encourage workarounds that circumvent what the box is trying to achieve in the first place. </li></ul></ul><ul><ul><li>Consider improving network transparency, either through protocol support, or moving functionality closer to end-hosts. </li></ul></ul><ul><ul><li>Filtering and firewalling should also be weighed against reduction in innovation capabilities within research environment. </li></ul></ul><ul><li>Buggy or sub-optimally tuned software also responsible for some problems (e.g. TCP stacks for large file transfers). </li></ul><ul><li>Consider evolution of PERT concept. </li></ul>
  26. 26. Middleware Findings
  27. 27. <ul><li>Identity federations are solution for supporting user access to remote services. </li></ul><ul><li>Most NRENs have identity federation or are establishing one. Others should plan to do so within next couple of years. </li></ul><ul><li>NRENs are natural candidates for supporting technical organisation within their countries, as well as representing national federations. </li></ul><ul><li>User-centric identity (e.g. OpenId) management also growing, and abstract identity framework also being worked on. NRENs should monitor developments. </li></ul><ul><ul><li>Already integrations of identity federation and OpenId </li></ul></ul>Identity Federations
  28. 28. Interoperability <ul><li>Inter-operability of identity federation happening: </li></ul><ul><ul><li>SAML 2.0 is today choice for exchanging identity data for web-based applications. </li></ul></ul><ul><ul><li>All the identity federations technologies are SAML2.0-compatible or they migrating to be SAML2.0-compatible. </li></ul></ul><ul><ul><li>Schemas such as eduPerson or SCHAC becoming more important to facilitate inter-operability. </li></ul></ul><ul><li>In order to be able to handle different AAIs it is recommended that NRENs support multiple trust infrastructures: </li></ul><ul><ul><li>X.509 certificates used quite a lot. </li></ul></ul><ul><ul><li>SAML signed tokens, coming up. </li></ul></ul><ul><li>It is recommended that NRENs try to minimise number necessary (e.g. by reusing existing PKIs). </li></ul><ul><li>Still open issue: No well established standard for communicating identity data to applications. </li></ul><ul><ul><li>NRENs should be proactive about this (possible task force?) </li></ul></ul>
  29. 29. Further Information <ul><li>EARNEST Reports </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li>(Draft Technical Report available, minus some updates) </li></ul></ul><ul><li>TERENA NGN Workshop </li></ul><ul><ul><li> </li></ul></ul><ul><li>Thanks to: </li></ul><ul><ul><li>Alcatel-Lucent, Calient, Cisco, DTU-COM, DANTE, Extreme Networks, Force10, i2CAT, IBM, Juniper, Liberty Alliance, MERLIN Project, Nortel, Sun Microsystems & SxIP </li></ul></ul><ul><ul><li>plus the Advisory Panellists </li></ul></ul>