1. 1 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Presented to Routing Research Group (RRG), Internet Research Task Force Meeting Minneapolis, November 21, 2008 These slides are available at: http://www.cse.wustl.edu/~jain/ietf/rangi.htm Routing Architecture for the Next Generation Internet (RANGI) Xiaohu Xu, Dayong Guo, Raj Jain, Jianli Pan, Subharthi Paul

2. 2 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Overview  Part I: Long Term View – Internet 3.0  Internet 3.0: Next Generation Internet  User- Host- and Data Centric Models  Triple Tier Virtualization  Part II: Short Term View – RANGI  A proposal to meet RRG Design Goals and More

3. 3 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Internet 3.0: Next Generation Internet  Internet 3.0 is the name of the Washington University project on the next generation Internet  Named by me along the lines of “Web 2.0”  Internet 3.0 is more intuitive then GENI/FIND  Goal 1: Develop a clean slate architecture to overcome limitations of the current internet  Goal 2: Develop an incremental approach to implement the architecture

4. 4 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Internet 3.0: Next Generation Internet  Internet 1.0 (1969 – 1989) – Research project  RFC1 is dated April 1969.  ARPA project started a few years earlier.  IP, TCP, UDP  Mostly researchers  Industry was busy with proprietary protocols: SNA, DECnet, AppleTalk, XNS  Internet 2.0 (1989 – Present) – Commerce  new requirements  Security RFC1108 in 1989  NSFnet became commercial  Inter-domain routing: OSPF, BGP,  IP Multicasting  Address Shortage IPv6  Congestion Control, Quality of Service,…

5. 5 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Key Problems with Current Internet 1. Security:  Inability to enforce policies related to Authorization, authentication, privacy, resource utilizations  Perimeter based representation of organization is not sufficient Trusted Un-trusted Executives Workers Accounting Suppliers

6. 6 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Problems (cont) 2. No representation for real end systems: the human. 3. Identity and location in one (IP Address) Makes mobility complex. [Well known] Ref: For a bigger list see our Milcom 2006 paper [1]

7. 7 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Realms  Object names and Ids are defined within a realm  A realm is a logical grouping of objects under an administrative domain  The Administrative domain may be based on Trust Relationships  A realm represents an organization  Realm managers set policies for communications  Realm members can share services.  Objects are generally members of multiple realms  Realm Boundaries: Organizational, Governmental, ISP, P2P,… Realm = Administrative Group

8. 8 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Physical vs. Logical Connectivity  Physically and logically connected: All computers in my lab = Private Network, Firewalled Network  Physically disconnected but logically connected: My home and office computers  Physically connected but logically disconnected: Passengers on a plane, Neighbors, Conference attendees sharing a wireless network, A visitor Physical connectivity  Trust

9. 9 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Id-Locator Split Architecture (MILSA)  Realm managers:  Resolve current location for a given host-ID  Enforce policies related to authentication, authorization, privacy  Allow mobility, multi-homing, location privacy  Similar to several other proposals  Ref: Our Globecom 2008 paper [2] User Host Location Realm Manager Data Host Location Realm Manager

10. 10 http://www.cse.wustl.edu/~jain/ietf/rangi.htm User- Host- and Data Centric Models  All discussion so far assumed host-centric communication  Host mobility and multihoming  Policies, services, and trust are related to hosts  User Centric View:  Bob wants to watch a movie  Starts it on his media server  Continues on his iPod during commute to work  Movie exists on many servers  Bob may get it from different servers at different times or multiple servers at the same time  Can we just give addresses to users and treat them as hosts? No!  Policy Oriented Naming Architecture (PONA)

11. 11 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Policy Oriented Naming/Routing  Both Users and data need hosts for communication  Data is easily replicable. All copies are equally good.  Users, Hosts, Infrastructure, Data belong to different realms (organizations).  Each object has to follow its organizational policies. User Host Location User RM Host RM Location RM Data Host Location Data RM Host RM Location RM RM = Realm Manager

12. 12 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Virtualizable Network Concept substrate router substrate link metalink metanet protocol stack substrate links may run over Ethernet, IP, MPLS,... meta router Ref: T. Anderson, L. Peterson, S. Shenker, J. Turner, "Overcoming the Internet Impasse through Virtualization," Computer, April 2005, pp. 34 – 41. Slide taken from Jon Turner’s presentation at Cisco Routing Research Symposium

13. 13 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Realm Virtualization  Old: Virtual networks on a common infrastructure  New: Virtual user realms on virtual host realms on a group of infrastructure realms. 3-level hierarchy not 2-level. Multiple organizations at each level.  Ref: Our PONA paper [3] Infrastructure Realm 1 Host Realm 1 User Realm 1User Realm n Host Realm n Infrastructure Realm n

14. 14 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Summary: Part I 1.Internet 3.0 is the next generation of Internet. 2.It must be secure, allow mobility, and be energy efficient. 3.Must be designed for commerce  Must represent multi-organizational structure and policies 4.Moving from host centric view to user-data centric view  Important to represent users and data objects 5.Users, Hosts, and infrastructures belong to different realms (organizations). Users/data/hosts should be able to move freely without interrupting a network connection.

15. 15 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Part II: Immediate Goals for the Next Generation Routing 1.Routing Scalability 2.Traffic Engineering 3.Mobility and Multihoming 4.Simplified Renumbering 5.Decoupling Location and Identification 6.Routing Quality 7.Routing Security 8.Incremental Deployability Ref: RRG Workshop

16. 16 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Current State of the Internet  IPv4 is ubiquitous among hosts and routers  IPv6 has been implemented in hosts (Windows) But most routers are still IPv4  Inter-Domain routing is complex  Renumbering  Customers want PI addresses  Service providers have difficulty supporting PI addresses  Need a solution for the current state  Routing Architecture for the Next Generation Internet (RANGI)

17. 17 http://www.cse.wustl.edu/~jain/ietf/rangi.htm RANGI Design Goals 1.Routing Scalability 2.Traffic Engineering 3.Mobility and Multihoming 4.Simplified Renumbering 5.Decoupling Location and Identification 6.Routing Quality 7.Routing Security: Also avoids ID theft 8.Incremental Deployability 9.Business friendly realm and domain boundaries Ref: HRA paper [4]

18. 18 http://www.cse.wustl.edu/~jain/ietf/rangi.htm RANGI Assumptions  Hosts:  Have IPv4 local addresses (Local = assigned by the organization network manager)  Have IPv6 128-bit global addresses  Have 128-bit global IDs (Hierarchical)  Support IPv6 over IPv4 tunnel  Have IPv6 aware higher layer protocols: TCP, UDP, FTP,...  Border Routers:  Support all requirements of the hosts (Routers = n hosts)  Can establish BGP session using IPv6 global address  Core Routers (non-border):  Have IPv4 local or IPv6 address. Understand IPv4 or IPv6. Host Border Router Core Router

19. 19 http://www.cse.wustl.edu/~jain/ietf/rangi.htm RANGI Mechanisms 1.ID/Locator split  Mobility 2.Hierarchical ID  Administrative Scalability 3.Cryptographic ID  Security (like HIP) 4.128-bit ID = IPv6 Addresses (like CGA)  Easy Application Transition 5.Local IPv4 embedded in IPv6  Simplify renumbering (like ISATAP) 6.IPv6 tunnel over IPv4 (ISATAP tunnel)  Easy transition (allow IPv4 intra-domain routers) 7.Address overwriting at border routing (Six/One or GSE)  Traffic engineering 8.Policy control (during ID to locator translation)

20. 20 http://www.cse.wustl.edu/~jain/ietf/rangi.htm RANGI Overview LD #2 LD #1 LD #3 Tunneled to local LDBR 2 Packets forwarded based on Dest LDID 3 4 5 4 1 Get ID and Locator of Dest host Host IDLocator Routing System Mapping System BR1 BR2 BR3 BR4 ID/Locator Mapping System DHT DNS RM DNS LD= Locator Domain LDID = Locator Domain ID LDBR = LD Border Router LD #3 Transport Host ID IPv6 Locator IPv4 Layer 6 BR4 Packets tunneled based on local locator Transport Host ID IPv6 Locator IPv4 Layer Transport Host ID IPv6 Locator 1

21. 21 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Hierarchical Host ID  Administrative Domain ID  Organizational semantics  Easy to deploy filtering policy based on organization boundary  Local Host ID  The Hash of the public key and the AD ID Administrative Domain IDLocal Host ID Region IDCountry IDAuthority ID n bits128-n bits Scalability with security 层 次化 主机 ID Host ID Example

22. 22 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Hierarchical Locator  LD (Locator Domain) ID  To globally identify each LD, that is a /96 IPv6 prefix  Has a hierarchical structure  LL (Local Locator) = IPv4  Each LD adopts independent (local) IPv4 address space  GL (Global Locator)=LD ID + Local Locator  Special IPv6 address with IPv4 address embedded LD IDLL(IPv4) 96 bits32 bits Local IPv4 address  Easy renumbering 层 次化 Locator

23. 23 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Hierarchical Routing  LD ID(/96 IPv6 Prefix) based routing by LDBR  IPv4 based routing by internal router within each LD  IPv6 over IPv4 tunnel between LDBRs LD #1 (IPv4 only) HI(A)  HI(B) IPv4(A)  IPv4(BR1) IPv6(A)  IPv6(B) IPv4(BR4)  IPv4(B) IPv6(A)  IPv6(B) Payload HI(A)  HI(B) Payload HI(A)  HI(B) Payload LD #2 (IPv4 only) LD #3 (IPv4 only) Host A Host B IPv4 Internal routers  Quick transition Routing System BR3 BR1 IPv4(BR2)  IPv4(BR3) IPv6(A)  IPv6(B) HI(A)-  HI(B) Payload BR2BR1BR4

24. 24 http://www.cse.wustl.edu/~jain/ietf/rangi.htm IPv6 BR End-host Inter-Domain =IPv6 Overlay Intra-Domain =IPv4/IPv6 WUSTL AT&T Intel Overlay View IPv4/IPv6 router

25. 25 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Key RANGI Features 1.Allows easy transition from IPv4 to IPv6 2.Allows site multi-homing 3.Allows site traffic engineering 4.Allows network mobility 5.And more …

26. 26 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Transition from IPv4 to IPv6  Eliminate the IPv6 over IPv4 tunnel layer between LDBRs once the internal routers within LD are upgraded to IPv6 LD #1 (IPv4 only) LD #2 (IPv6 only) LD #3 (IPv6 only) Host A Host B Smooth the transition from IPv4 to IPv6 BR4 BR1 Payload HI(A)->HI(B) IPv6(A)->IPv6(B) IPv4(A) ->IPv4(BR1) Payload HI(A)->HI(B) IPv6(A)->IPv6(B) Payload HI(A)->HI(B) IPv6(A)->IPv6(B) BR1BR2BR3

27. 27 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Site Multi-homing LD #1 ISP #2 Host A ISP #1 LDID1+LL(A)  GL(B) Policy routing based on the source LD ID LDID1+LL(A)  GL(B) Host B  Multiple PA LDID assigned to the multi-homed site network  Routing system scales well due to the usage of the PA LDID LDID1+LL(A)  GL(B) Routing System BR1 BR2 BR3

28. 28 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Site Traffic Engineering LD #1 ISP #2 Host A ISP #1 LDID1+LL(A)  GL(B) LDID2+LL(A)  GL(B) Host B Site BR rewrites source LD of the outgoing packets LDID2+LL(A)  GL(B) Routing System BR1 BR2 BR3 Rewrite source LDID. Route using source LDID

29. 29 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Site Traffic Engineering (Cont) LD #1 ISP #2 Host A ISP #1 GL(B)  LDID2+LL(A) Host B GL(B)  LDID2+LL(A) GL(B)  LDID2+LL(A Routing System BR1 BR2 BR3  Return packets follow the same path  Possible to load balance also  Idea similar to GSE, 8+8, Six/One

30. 30 http://www.cse.wustl.edu/~jain/ietf/rangi.htm RANGI and RRG Design Goals 1.Routing Scalability  Solved by keeping separate local and global locators  Provider assigned locator domain ID 2.Traffic Engineering  Realm managers and border routers can select locator and path 3.Mobility and Multihoming  Identifier locator split  Session portability 4.Simplified Renumbering  Local IPv4 addresses do not change  Global ID does not change

31. 31 http://www.cse.wustl.edu/~jain/ietf/rangi.htm RANGI and RRG Design Goals (Cont) 5.Decoupling Location and Identification 6.Routing Quality  Allows BRs to select the paths with shorter delay or better performance  Size of global routing table and update frequency reduced significantly 7.Routing Security  RM enforce policies including security  Local addresses and paths are not disclosed outside 8.Incremental Deployability  Allow step by step deployment and long-term evolution

32. 32 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Summary 1.RANGI = Routing Architecture for the next generation Internet Solves scalability, mobility, multihoming, …, policy 2.RANGI-awareness required only in the hosts and in the border routers 3.Non-border routers can remain IPv4 or IPv6 4.Organizations have complete control over naming, addressing inside their organization (Local addressing) and resolution 5.Incremental deployment of RANGI and IPv6

33. 33 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Future Work  Incremental deployment of RANGI border routers: Some clouds may not have RANGI border routers.  Incremental deployment of RANGI in the domain Some hosts may and some may not have RANGI  Policy enforcement of end-to-end trust  Policy enforcement of path

34. 34 http://www.cse.wustl.edu/~jain/ietf/rangi.htm References 1.Jain, R., “Internet 3.0: Ten Problems with Current Internet Architecture and Solutions for the Next Generation,” in Proceedings of Military Communications Conference (MILCOM 2006), Washington, DC, October 23-25, 2006, http://www.cse.wustl.edu/~jain/papers/gina.htm http://www.cse.wustl.edu/~jain/papers/gina.htm 2.Subharthi Paul, Raj Jain, Jianli Pan, and Mic Bowman, “A Vision of the Next Generation Internet: A Policy Oriented View,” British Computer Society Conference on Visions of Computer Science, Sep 2008, http://www.cse.wustl.edu/~jain/papers/pona.htm http://www.cse.wustl.edu/~jain/papers/pona.htm 3.Jianli Pan, Subharthi Paul, Raj Jain, and Mic Bowman, “MILSA: A Mobility and Multihoming Supporting Identifier- Locator Split Architecture for Naming in the Next Generation Internet,,” Globecom 2008, Nov 2008, http://www.cse.wustl.edu/~jain/papers/milsa.htm http://www.cse.wustl.edu/~jain/papers/milsa.htm

35. 35 http://www.cse.wustl.edu/~jain/ietf/rangi.htm References (Cont) 4.Xiaohu Xu and Dayong Guo, “Hierarchical Routing Architecture,” Proc. 4 th Euro-NGI Conference on Next Generation Internetworks, Krakow, Poland, 28-30 April 2008, 7 pp., http://www.cse.wustl.edu/~jain/papers/hra.htmhttp://www.cse.wustl.edu/~jain/papers/hra.htm

36. 36 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Thank You!

37. 37 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Acknowledgment: Sources of Ideas √ √ √ √ √ √ √ √ √ √

38. 38 http://www.cse.wustl.edu/~jain/ietf/rangi.htm ID-Locator Mapping: Example  ID of Bob.x.foo.com = 1110 0110 001 00000111111 DNS RM FOO.COM RM X.FOO.COM BOB.X.FOO.COM ALICE.Y.BAR.EDU RM BAR.EDU RM Y.BAR.EDU Data Plane 1 12 3 4 45 5 5 6 7 Infrastructure Layer RM = Realm Manager 2 ComFooxBob Innovation Reasonable business model and robustness 层 次化 路由系统 Mapping System Host Layer Register Query Locator of RM

39. 39 http://www.cse.wustl.edu/~jain/ietf/rangi.htm ID-Locator Mapping (Cont) 1. Bob and Alice register with RMs. All organizational policies checked and nodes authenticated. 2. Bob asks RM to resolve Alice.Y.BAR.EDU. No direct trust relationship  Request forwarded higher 3. RM for FOO.COM uses DNS request to get one locator of the RM for BAR.EDU. Sets up trust relationship. 4. RM for realm BAR.EDU forwards the request to the RM of the sub-realm Y.BAR.EDU. 5. RM for realm Y.BAR.EDU sends back a response: RANGI ID and Locator of Alice. 6. The response is sent back to Bob. 7. Data link is set up between Bob and Alice. Note: RM’s verify their policies before forwarding. RM = Resolution + Policy enforcement + Mobility registration

40. 40 http://www.cse.wustl.edu/~jain/ietf/rangi.htm  Network mobility uses the mechanism of NEMO  Avoid registration from a huge amount of hosts within the mobile network Network Mobility Home Network Mobile Network Host A Host B HI(A)->HI(B) GL(A)->GL(B) Payload HI(A)->HI(B) GL(A)->GL(B) Payload HI(A)->HI(B) GL(A)->GL(B) Payload GL(HA)->GL(MR) MR registers its location to the home agent Routing System MR HA

41. 41 http://www.cse.wustl.edu/~jain/ietf/rangi.htm Internet 1.0 vs. Internet 3.0 FeatureInternet 1.0Internet 3.0 1.Energy EfficiencyAlways-on Green  Mostly Off 2.MobilityMostly stationary computersMostly mobile objects 3.Computer-Human Relationship Multi-user systems  Machine to machine comm. Multi-systems user  Personal comm. systems 4.End SystemsSingle computersGlobally distributed systems 5.Protocol SymmetryCommunication between equals  Symmetric Unequal: PDA vs. big server  Asymmetric 6.Design Goal Research  Trusted SystemsCommerce  No Trust Map to organizational structure 7.OwnershipNo concept of ownershipHierarchy of ownerships, administrations, communities 8.Sharing Sharing  Interference, QoS Issues Sharing and Isolation  Critical infrastructure 9.Switching unitsPacketsPackets, Circuits, Wavelengths, Electrical Power Lines, … 10.ApplicationsEmail and TelnetInformation Retrieval, Distributed Computing, Distributed Storage, Data diffusion