1 / 52

IRTF RRG Activity for Future Internet

IRTF RRG Activity for Future Internet. Heeyoung JUNG. ETRI. Email: hyjung@etri.re.kr. Outline. Internet and why Future Internet? IRTF and RRG Overview RRG Documents LISP and ILNP Wrap Up. Internet. Network of networks (Not WWW ) Global inter-networking technology

julius
Télécharger la présentation

IRTF RRG Activity for Future Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IRTF RRG Activity for Future Internet Heeyoung JUNG ETRI Email: hyjung@etri.re.kr

  2. Outline • Internet and why Future Internet? • IRTF and RRG Overview • RRG Documents • LISP and ILNP • WrapUp heeyoung, ETRI

  3. Internet • Network of networks (Not WWW ) • Global inter-networking technology • But becoming a single basic tech for all kinds of networks (e.g. All-IP networks) • Core protocols • IPv4/v6 (network) + TCP/UDP (transport) + WWW (application) • A single power group • Standard: IETF, leaded a few big guys • Product: Cisco, more than 70% market share heeyoung, ETRI

  4. Basic Concepts • End-to-End argument • Hourglass model Intelligent end host Apps & Control Various applications StupidNetwork (just delivery) Common Thin waist Various underlying technologies Apps & Control Telecom networks (beads-on-a-string, dummy terminals/smart network) heeyoung, ETRI

  5. What’s been Happened? • On 1 January 1983, all ARPANnet switched to TCP/IP • Internet has had no big change since the flag day • But, environment has been continuously changed • Research network  for commercial networks, or a social infra • Best effort services  including QoS/E guaranteed services • Well-educated technician  Ordinary people • Reliable users  Lots of bad guys • Fixed oriented  Mobile oriented • A few apps  www, google, twitter, facebook, … • And lots of other things heeyoung, ETRI

  6. Ossification Peak? Fat waist heeyoung, ETRI

  7. Need Something New Internet (Clean-slate) Future Internet? heeyoung, ETRI

  8. Future Internet Activities • Typically classified as Arch and Experimental Facility (EF) • US • Mainly funded by NSF • Arch: MobilityFirst, NDN, Nebula, and XIA • EF: GENI • EU • Mainly supported through FP7 projects • Arch: 4WARD, PSIRP, ANA, etc. • EF: FIRE • Japan • Mainly leaded by NICT as a part of NWGN • Arch: AKARI (ID/LO split, network virtualization and optical packet) • EF: JGN2plus heeyoung, ETRI

  9. FI in Korea • KCC/KCA FI PM • 6 on-going projects (Arch and EF) • 4 new projects (Arch): NDN, DTN, Trusty net, and Smart node • Performed by ETRI and universities, including SNU • Future Internet Forum (FIF) • http://fir.kr • Chaired by YH Choi heeyoung, ETRI

  10. Any Conclusion for FI? • Seems NO • A golden opportunity for Korea to contribute our ideas 百家爭鳴 DTN heeyoung, ETRI

  11. IETF and IRTF • Two powerful organizations of US • IETF • Focuses on the shorter term issues of engineering and standards making • IRTF • Focuses on longer term research issues related to the Internet while the parallel organization, the IETF • Still focus on evolution heeyoung, ETRI

  12. IRTF RGs • Research Groups • ASRG: Anti-Spam Research Group • CFRG: Crypto Forum Research Group  • DTNRG: Delay-Tolerant Networking Research Group • HIPRG: Host Identity Protocol Research Group • ICCRG: Internet Congestion Control Research Group • MOBOPTS: IP Mobility Optimizations Research Group • NMRG: Network Management Research Group • P2PRG: Peer-to-Peer Research Group  • RRG: Routing Research Group • SAMRG: Scalable Adaptive Multicast Research Group • TMRG: Transport Modeling Research Group • VNRG: Virtual Networks Research Group Security Wireless Scalability/Mobility Transport Management P2P Virtualization heeyoung, ETRI

  13. Problem Statement of RRG • Internet addresses initially assigned in hierarchical manner • Address aggregation for inter-domain routing • However, aggregation is becoming more and more difficult • Multi-homing, provider change, assignment of new address blocks, etc. heeyoung, ETRI

  14. BGP RT Explosion • The most imminent problem of Internet Size of current BGP FIB? heeyoung, ETRI

  15. Related Documents • Report from the IAB workshop (Oct. 2006) on routing and addressing • RFC4984, Sep. 2007 • Editors: David Meyer (Cisco), Lixia Zhang(UCLA) and Kevin Fall (Intel) • On the scalability of Internet routing • Draft-narten-radir-problem-statement-05.txt, Feb. 17, 2010 • Author: Thomas Narten(IBM) • Design goals for scalableInternet routing • Draft-irtf-rrg-design-goals-06.txt, Jan. 3, 2011 • Editor: Tony Li (Cisco) • Recommendation for a routing architecture • RFC6115, Feb. 2011 • Chairs: Tony Li (Cisco) and Lixia Zhang (UCLA) heeyoung, ETRI

  16. RFC4984 • Report from IAB WS • Problem statement • Commonly recognized that today’s Internet routing and addressing system is facing serious scaling problem • Effective solutions have yet to be identified, developed, and deployed • Main objectives of WS • To identify existing and potential factors that major impacts on routing scalability • To develop a concise problem statement that may serve as input to a set to follow-on activities heeyoung, ETRI

  17. Key Findings • Problem #1: the scalability of routing system • Problem #2: the overloaded of IP address semantics • Other concerns • Scaling problem can potentially be exacerbated by IPv6’s much largerer address space • The growth in number of routers will cause slow routing convergence to become a significant problem • Misalignment of costs and benefits in today’s routing system • IETF does not consider “business model”, but the time has come to review that philosophy heeyoung, ETRI

  18. On the scalability of Internet routing • Based on 2006 IAB WS on routing & addressing [RFC4984] • Describes the "pain points" being placed on the routing system • Background • Within DFZ, both the size of the RIB/FIB and overall update rate have historically increased at a greater than linear rate : super-linear growth • Challenge for current and/or future routers • Factors that make CIDR aggregation difficult • Traffic engineering (TE), multi-homing, end site renumbering, acquisitions and merges, RIR address allocation policies, dual stack pressure on the routing table, internal customer routes, IPv4 address exhaustion, interconnection richness, … heeyoung, ETRI

  19. Design Goals for Scalable Internet Routing • Background • Internet routing and addressing architecture is facing challenges in inter-domain scalability, mobility, multi-homing, and inter-domain traffic engineering[IAB WS-RFC4984] • RRG aims to design an alternative architecture to meet these challenges • Presents a prioritized list of design goals for the target architecture heeyoung, ETRI

  20. Priority heeyoung, ETRI

  21. RFC 6115-(1) • Background • RRG was chartered to research and recommend a new routing architecture for the Internet • The goal was to explore many alternatives (15+1) and build consensus around a single proposal • Meetings from Mar. 2007 to Mar. 2010 • A general concern on the cost and structure of routing and addressing architecture • Urgent need to examine and evaluate potential scalability enhancements • The new architecture must be applicable to IPv6 • Many of Band-Aid solutions have come with a significant overhead in terms of long-term maintenance and architecture complexity heeyoung, ETRI

  22. RFC 6115-(2) • Consensus • Roughconsensus on ID/LOC split but not on a specific approach • Internet needs to support multi-homing in a manner that scales well and does not have prohibitive costs • IETF solution has to not only support multi-homing, but address the real-world constraints of the end customers • Co-chairs recommend that the IETF pursues works in the following areas: • Evolution: a short-term improvement • ILNP: a clean solution for the architecture • Renumbering: change locators at minimal cost heeyoung, ETRI

  23. Brief Summary –(1) • ID/LOC split schemes: makes LOCs topologically aggregatable heeyoung, ETRI

  24. Brief Summary –(2) • Cont’d heeyoung, ETRI

  25. Brief Summary –(3) • Effective mapping systems for ID/LOC split • Mostly related to LISP heeyoung, ETRI

  26. Brief Summary –(4) • Other approaches heeyoung, ETRI

  27. Evolution • Observation • Changes to the Internet can only be a gradual process with multiple stages • At each stage, adopters are driven by and rewarded with solving an immediate problem • Basic approach • Aggregating many routing entries to a few number • Examples heeyoung, ETRI

  28. Pros & Cons • Merits • The lowest hurdle to deployment • Does not require that all networks move to use a global mapping system or upgrade all hosts • Immediate benefits to ISP after its own deployment • Critics • Potential concerns in the technical design • FIB aggregation may introduce extra routing space that causes potential routing loop • Many potential side-effects in virtual aggregation • Not provide mobility support • Would end up with adding more and more patch to the old arch • Just short-term solution to reduce the incentives for deploying a new arch heeyoung, ETRI

  29. Two Promising Techs • LISP • Supported by Cisco • The most typical approach for ID/LOC split • Already many Internet drafts and some implementations • Note that many other proposals are closely related to LISP • ILNP • Recommended by RRG as the clean-slate approach • Likely to be discussed in IETF heeyoung, ETRI

  30. Key Ideas of LISP • Implements a ID/LOC separation mechanism using encapsulation between routers at the "edge" of the Internet • Generally called, Map & Ecap • Allows topological aggregation of the routable addresses (LOCs) • While providing stable and portable numbering of end systems (IDs) heeyoung, ETRI

  31. Gains • Topological aggregation of locator space (RLOCs) used for routing • Greatly reduces both the overall size and the "churn rate“ of the information needed to operate the Internet global routing system • Separate identifier space (EIDs) for end systems • Effectively allowing "PI for all“ without adding state to the global routing system • Improved traffic engineering capabilities • No changes required to end systems and to Internet "core" routers • Minimal and straightforward changes to "edge" routers • Day-one advantages for early adopters heeyoung, ETRI

  32. Cost • Mapping system infrastructure • Alternative Logical Topology (ALT) routers, Map Servers, Map Resolvers, • New business opportunity • Overhead for determining/maintaining locator/path liveness • A common issue for all ID/LOC separation proposals • Interworking infrastructure (ITRs, ETRs) • New business opportunity heeyoung, ETRI

  33. S D 11.0.0.1 -> 12.0.0.2 11.0.0.1 -> 12.0.0.2 EID-prefix: 2.0.0.0/8 Locator-set: 12.0.0.2, priority: 1, weight: 50 (D1) 13.0.0.2, priority: 1, weight: 50 (D2) Mapping Entry 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 S1 S2 D1 D2 Policy controlled by destination site Data Plane Source: David Meyer, “LISP, What Is It, And How Much Of It Is Real?” 2008 PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8 ETR ITR Provider A 10.0.0.0/8 Provider X 12.0.0.0/8 12.0.0.2 10.0.0.1 ITR ETR 11.0.0.1 13.0.0.2 Provider B 11.0.0.0/8 Provider Y 13.0.0.0/8 DNS entry: D.abc.com A 2.0.0.2 Legend: EIDs -> Blue Locators -> Red heeyoung, ETRI

  34. Control Plane • ALT (Alternative Logical Topology) is the most popular solution • The ALT is just an instance of BGP that carries EID prefixes • ETRs typically advertise EID-prefixes into the ALT to attract Map-Requests • ITRs use the ALT to route Map-Requests to the ETRs that are authoritative for an EID prefix • ETRs return Map-Replies on the underlying network to the requesting ITR • The ITR can now LISP-encapsulate packets directly to the destination’s ETR heeyoung, ETRI

  35. 11.0.0.1 -> 240.1.1.1 11.0.0.1 -> 240.1.1.1 240.0.0.1 -> 240.1.1.1 240.0.0.1 -> 240.1.1.1 <- 240.1.1.0/24 < - 240.1.0.0/16 <- 240.1.2.0/24 240.0.0.1 -> 240.1.1.1 240.0.0.1 -> 240.1.1.1 ITR ITR ETR ETR ETR 11.0.0.1 -> 1.1.1.1 ? ? ? ? 1.1.1.1 -> 11.0.0.1 240.0.0.1 -> 240.1.1.1 ALT-rtr ALT-rtr ALT-rtr ALT-rtr ALT-rtr ALT-rtr LISP-ALT Operation EID-prefix 240.0.0.0/24 EID-prefix 240.1.1.0/24 1.1.1.1 11.0.0.1 EID-prefix 240.1.2.0/24 2.2.2.2 12.0.0.1 Legend: EIDs -> Blue Locators -> Red GRE Tunnel Low Opex Physical link Data Packet Map-Request Map-Reply 3.3.3.3 ALT EID-prefix 240.2.1.0/24 Source: David Meyer, “LISP, What Is It, And How Much Of It Is Real?” 2008 heeyoung, ETRI

  36. Critique • A fundamental problem with any global query server network • Frequently long paths and greater risk of packet loss may cause ITRs drop or significantly delay the initial packets • ALT's delays compounded by its structure being aggressively aggregated, without regard to the geographic location of the routers • No solution for the contradiction b/w • The need for high aggregation while making ALT structure robust against single points of failure • Testing reachability of the ETRs is complex and costly • Complex communication between ITRs and ETRs • UDP and 64-bit LISP headers in all traffic packets heeyoung, ETRI

  37. Rebuttal • Initial-packet loss/delays turn out not to be a deep issue • If needed, initial packets can be sent via legacy mechanism until the ITR has a mapping • ALT is never mandatory in the long term • LISP has a standardization mapping system interface for new mapping systems heeyoung, ETRI

  38. ILNP • Motivation • If we provide a richer set of namespaces, then the Internet architecture can better support mobility, multi-homing, and other important capabilities • Key ideas • Clean separation of IDsfrom LOCs • ID names nodes, not interface • LOCs names sub-networks, equivalent to an IP routing prefix • IDs are never used for network-layer routing • Whilst LOCs are never used for node ID • Transport layer sessions use only ID, never LOC heeyoung, ETRI

  39. Naming: IP vs. ILNP Saleem Bhatti, “Naming for Networking,” 2008 e.g.‘marston.cs.st-andrews.ac.uk’ heeyoung, ETRI

  40. Address: IPv6 vs. ILNPv6 • ILNPv6 splits the IPv6 address in half • Locator (L): 64-bit name for the sub-network • Identifier (I): 64-bit name for the host Saleem Bhatti, “Naming for Networking,” 2008 heeyoung, ETRI

  41. Header Format Source address Destination address Saleem Bhatti, “Naming for Networking,” 2008 heeyoung, ETRI

  42. Mobility in ILNPv6 • Implementation in CN • Uses DNS to find MN’s set of Identifiers and Locators • Only uses ID in transport-layer session state • Uses LOC only to forward/route packets • Implementation in MN • Accepts new sessions using currently valid “I” values • When the MN moves: • ICMP Locator Update (LU) to inform other nodes of revised set of Locators for the MN • LU can be authenticated via IP Security • Secure Dynamic DNS Update to revise its LOC in its Authoritative DNS server heeyoung, ETRI

  43. ILNP Session Setup Avinash Mungur, “Analysis of Locator Identity Split Protocols in Providing End-host Mobility,” Lancaster University heeyoung, ETRI

  44. Others with ILNP • Support both site multi-homing & host multi-homing • ICMP LU mechanism handles uplink changes • Topologically aggregatable LOCs helps BGP scalability • Eliminates issues with NAT • Upper-layer protocol state is bound to I only, never to L • Only value of L changes as the NAT is traversed, so NAT function now invisible to upper-layer protocols • IP Security with ILNP • ILNP AH includes I values, but excludes L values • IPsec Security Association (SA) bound to value of I, not L • Existing IETF DNS Security can be used as-is heeyoung, ETRI

  45. Cost • End systems need to be enhanced to support ILNP • DNS servers also should be upgraded to support new DNS resource records for ILNP • Others • No globally-routable network interface name • Potential impact on SNMP MIBs • A few legacy apps might remain problematic • e.g. ftp • DNS reliance is not new, but is more explicit heeyoung, ETRI

  46. Critique • Deployment incentives and benefits? • How communication can be established if a node is sufficiently mobile? • If moving faster than the DNS update, then DNS fetch cycle can effectively propagate changes? • Presume that all communication is tied to DNS names • Some can be done with an explicit ID/LOCpair • How to determine which LOC pairs (local, remote) are actually functional? • ICMP is insufficient heeyoung, ETRI

  47. Rebuttal • Eliminates the need for PI addressing and encourage increased DFZ aggregation • Can be the incentive for the deployment • Enables both host- and site multi-homing • INLP mobility eliminates DAD • ICMP LU separately reduce the layer-3 handoff delay • High mobility problem is the same in MIP • Deployed IP nodes can track reachability via existing host mechanism or by Shim6 heeyoung, ETRI

  48. LISP vs. ILNP-(1) Saleem Bhatti, “ILNP: a whirlwind tour,” 2010 heeyoung, ETRI

  49. LISP vs. ILNP-(2) heeyoung, ETRI

  50. Observations from RFC6115 • RFC6115 is Internet leading group's thought on FI • May be one of big streams for FI • More practical, near-term than NSF architecture related pojects • IETF is doing and/or like to do related works in near future • Note that ID/LOC split is not only the solution for scalability but also the one for mobility • Mobile IP is also a sort of ID/LOC split (ID:HoA, LOC:CoA) • Mobility should be considered together at initial design stage, not as a patch-on • MOFI(www.mofi.re.kr) pursues this approach • In conclusion, ID/LOC split seems a promising arch for FI heeyoung, ETRI

More Related