1 / 27

미래인터넷의 이동 네트워크 구조 연구 동향

미래인터넷의 이동 네트워크 구조 연구 동향. 한국기술교육대학교 한연희 (Youn-Hee Han) http://link.kut.ac.kr 2010.06.29. Contents. Why FI Mobility Architecture? Design Principles of FI Mobility Architecture ID/Locator Separation FI Mobility Architecture Examples AKARI MOFI Flow Mobility Summary.

genera
Télécharger la présentation

미래인터넷의 이동 네트워크 구조 연구 동향

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. 미래인터넷의 이동 네트워크 구조 연구 동향 한국기술교육대학교 한연희 (Youn-Hee Han) http://link.kut.ac.kr 2010.06.29

  2. Contents • Why FI Mobility Architecture? • Design Principles of FI Mobility Architecture • ID/Locator Separation • FI Mobility Architecture Examples • AKARI • MOFI • Flow Mobility • Summary

  3. Why FI Mobility Architecture?

  4. Why FI Mobility Architecture? • Problems of Internet in Mobile Environments 1) Mobility was not a design criterion of Internet • So many candidate technologies: Mobile IP/Proxy MIP, mSCTP, mSIP,… • No Complete Mobility Transparency 2) Mobility control in the form of patch-on 3) Integration of data and control paths 4) Stick to Host-based protocols Source: http://www.trilogy-project.org

  5. Why FI Mobility Architecture? • Problems of Internet in Mobile Environments 5) Does not well support the heterogeneous networks 6) Does not support the sensor devices (and group of them) mobility 7) No Scalability & No Efficient Routing 8) Overloading characteristic of IP address • Approach to Solve the Problems • Clean-slate approach would be REQURIED • Not the future (evolution) of the current Internet • But the network of the future • Revolution/Innovation • The backward compatibility may or may not be required

  6. Design Principles of FI Mobility Architecture • Design Principles • Mobile-oriented and Static-allowed • ID-based Communication with LOC-based Routing • Separation of Identifier and Locator • Address-free User Host • Location Privacy • Separation of Access Network and Backbone Network • Network-based Mobility Control • Intrinsic Route Optimization for Data Delivery • Separation of Mobility Control from Data Transport • Accommodation of New Services (or Networks) • Delay Tolerant Networks (Opportunistic Networks)

  7. Current Proposals for FI Mobility Architecture • ID-LOC Separation • HIP (Host Identity Protocol): IETF • Host-based solution • LISP (Locator-Identifier Separation Protocol): IETF • Network-based solution • ILNP (Identifier/Locator Network Protocol) • Host-based solution • Mobility Architecture based on ID-LOC Separation • AKARI: a Project in Japan • Host&Network-based solution • MOFI (Mobile-Oriented Future Internet): a Project in Korea • Network-based solution

  8. ID/Locator Separation • Why ID/Locator Separation? • Today IP addresses used for • Identifying purposes (“who”; in TCP connections) • Locating purposes (“where”; lookup routes) • Intentionally designed such a overloading • To avoid a system that maps between them • But, Internet has been quite complex because of the overloading feature • Complexity in Mobility Support • Complexity in (Host and Site) Multihoming Support

  9. ID/Locator Separation • Name, ID, and Locator - Human-readable (e.g., alphanumeric) - To uniquely identify a corresponding (communicating) object in the network : an object may be human, device, data, service, etc. Name Mapping • Cannot be memorized by humans (may be “bitstring”) • - End object should be identified by ID in a secure manner- Used as control information and packet headers Identifier Mapping Locators Locators Locators • Represent the location of an object in the network. • Contain the information about topological info. of an object • For efficient support of mobility and multihoming • : Multiple locators per object

  10. ID/Locator Separation • Possible Approach to Separation • New shim-layer on hosts mapbetween IDs and locators • Use of locator is transparent to (most) applications and transport • Need a new protocol to setup mapping on hosts Application Name Transport Identifier IDLocatorMapping Shim Network Locator

  11. AKARI – a FI Mobile Architecture • AKARI Project (2006 ~ Current) • “A small light in the dark pointing to the future” • "AKARI" means "a small light" in Japanese. • Goal is to build technologies for new generation network by 2015, developing a network architecture and creating a network design based on that architecture.. • NWGN (New Generation Network) • Network architectures and service conditions are different from IP networks, and it may be a new paradigm.

  12. AKARI – a FI Mobile Architecture • HNIS (HostName and Identifier System) • Hostname • Examples • Identifier • Self-allocating ID • fixed-length bit strings • Host ID & Locators mapping • The host ID is dynamically mapped to different locators • Global Locator (GLOC), Local Locator (LLOC) • For mobility • Host ID is mapped to two different locators at different instances. • For multihoming • Host ID is simultaneously mapped to two or more locators. • my-pc-20090915#mydomain.com • sensor-temp-room-5-202#my-domain.com

  13. AKARI – a FI Mobile Architecture • Identity Sublayer in Protocol Stack • Transport and upper layers • Host ID are used for host or session identification • Network layer • locators are used for finding host location and forwarding packets Use Host ID Application Application Map Host ID to Locator Transport Transport Use Locator Identity Identity Identity Network Network Network Data link Data link Data link Physical Physical Physical Host Host Link Link Gateway

  14. AKARI – a FI Mobile Architecture • Architecture Components • 1) Edge networks • 2) Global transit network • 3) Unified logical control network • HNRs • Hostname Registry • DNRs • Domain Name Registry • IDRs • ID Registry • 4) Gateways • Two main tasks • 1) translating network layer protocols or locators, • 2) updating the ID/locator mapping records of IDRs Global network L3 protocol/locator Local network L3protocol/locator GW {GLOC} {LLOC}

  15. AKARI – a FI Mobile Architecture • Data packet delivery ID Registry (IDR) ID Registry (IDR) Host1{ID,GLOC,LLOC}; Host2{ID,GLOC,LLOC}; Host2{ID,GLOC} Host1{ID,GLOC} Use GLOC to route packets Global transit network LLOC  GLOC GW GW Host2{ID,LLOC, GLOC} Host1{ID,GLOC, GW{ID,GLOC}} Host1{ID,LLOC, GLOC} Host2{ID,GLOC, GW{ID,GLOC}} LLOC  GLOC Edge Network 1 Edge Network 2 Host2 Host1 host2#domain2.com host1#domain1.com Host2{ID,LLOC} Host1{ID,LLOC} Host1{ID,LLOC} Host2{ID,LLOC}

  16. AKARI – a FI Mobile Architecture • Procedures of Mobility Management IDR_HN IDR_CN IDR Logical Control Network (5) (5) IDR_FN (2) MH{ID,LOC} CH{ID,LOC} (6) (7) (4) ID/LOC update Global Transit Network HNR_CH GW_CN (8) GW_HN GW_FN HNR_HN Correspondent Host (1) (3) New LOC configuration Correspondent Network Mobile Host Foreign Network Home Network

  17. A FI Mobility Architecture in Korea • MOFI (Mobile-Oriented Future Internet) • 미래인터넷에서의 이동환경 및 네트워크 다양성 지원구조 연구 (산업원천기술개발사업, 2010~) • 주관 및 참여 기관 • ETRI, 경북대, 충남대, 한국기술교대, 산업기술대, 서울대, 경희대, 충북대 • http://www.mofi.re.kr/

  18. MOFI – a FI Mobile Architecture • Name, ID, and Locator Separation • Name (e.g., NAI (Network Access Identifier)) • End Host ID (EID) • 128-bit fixed length • Locator (LOC)

  19. MOFI – a FI Mobile Architecture • MOFI Protocols • FIP (Future Internet Protocol): for end-to-end HID-based communication • ADP (Access Delivery Protocol): for data transport in the access network • Current IP: for data transport in the backbone network • HBP (HID Binding Protocol): for binding of HID and Link address to AR • LMP (LOC Management Protocol): for LOC binding/query and handover

  20. MOFI – a FI Mobile Architecture • MOFI – Reference Model

  21. MOFI – a FI Mobile Architecture • MOFI: Protocol Stack (Data Plane) • MOFI: Protocol Stack (Control Plane)

  22. IETF Standards on Mobility Management [IETF 표준화 중심(관련 WG: MEXT, MIPSHOP, NETEXT)- 2010년 6월 현재] Host-based IP Mobility Network-basedIP Mobility Proxy Mobile IPv6 [RFC 5213, Aug. 2008] IPv4 Support for Proxy Mobile IPv6 [RFC 5844, May 2010] Fast Handovers for Proxy Mobile IPv6 [draft-ietf-mipshop-pfmipv6-14] Multiple Care-of Addresses Registration & Flow Bindings in Proxy Mobile IPv6 [draft-krishnan-netext-intertech-ps-02] [draft-hui-netext-multihoming-00] [draft-melia-netext-muho-solution-00] [draft-xia-netext-flow-binding-00] [draft-hui-netext-service-flow-identifier-01] [draft-koodli-netext-flow-handover-00] Mobility Support in IPv6 [RFC 3775, June 2004] Mobile IPv6 Support for Dual Stack Hosts and Routers [RFC 5555, June 2009] Fast Handovers for Mobile IPv6 [RFC 4068, July 2005] Multiple Care-of Addresses Registration [RFC 5648, Oct. 2009] Flow Bindings in Mobile IPv6 and NEMO Basic Support [draft-ietf-mext-flow-binding-14] Traffic Selectors for Flow Binding [draft-ietf-mext-binary-ts-04] Horizontal Handover A handover is initiated when mobile device exits the boundaries of an administrative domain. Single interface is used. Vertical Handover A mobile device does need to move in order to initiate a handover. Multiple interfaces are required, but use one interface at a time. Complexity Level Multiple Interface Management Simultaneous use of multiple interfaces and access networks. Association of an application with an interface Multiple Flow Management Ability to split individual flows between links with respect to the requirements of the flows and the user preferences Next Research Items

  23. Multihoming Scenario

  24. Flow Mobility Scenario • Flow Mobility Scenario • Scenario 1: Move some of flows to a new interface • If another access is enabled on the MN, some of the existing flows could be moved over, to achieve, e.g., load balancing and better user experience Binding Update with Binding ID & Flow ID HA HA Mobile IPTVflow Mobile IPTVflow Router Router Router Router VoIPflow VoIPflow WiBro 3G WiBro 3G 새로운 인터페이스로 세션을 이동  Vertical 핸드오버 VoIP 세션만 옮겨아지! WiBro 3G WiBro 3G MN MN

  25. Flow Mobility Scenario • Flow Mobility Scenario • Scenario 2: Setting up Mobility Sessions on Demand • Create additional mobility sessions on demand • e.g., additional connection for a particular service • A new mobility session with a new prefix is created Binding Update with Binding ID (No Flow ID) LMA LMA Mobile IPTVflow Mobile IPTVflow HTTPflow Router Router Router Router Binding Update with Binding ID Flow ID & Traffic Selector VoIPflow VoIPflow WiBro 3G WiBro 3G 다른 인터페이스의 스위치를 올려서 단순하게 접속만 시도 세션이동은 하지 말아야지… HTTP 세션은 3G 인터페이스로 열어야지… WiBro 3G WiBro 3G MN MN

  26. Summary • Key Technologies for FI Mobility Architecture • ID-LOC Separation • Binding <Name  ID  Location> Management • Handover Management • Scalability Issue • Flow Mobility Management • Per-flow binding  Scalability Issue • Further Works • FI Mobility Architecture should incorporate “Delay-Tolerant Networks” • Host Intelligence vs. Network Intelligence

  27. References • V. P. Kafle, H. Otsuki, and M. Inoue, “An ID/locator split architecture for future networks,” IEEE Communication Magazine, Vol. 48, No. 2, pp. 148-144, 2010. • AKARI • http://akari-project.nict.go.jp/ • MOFI (Mobile-Oriented Future Internet) • http://protocol.knu.ac.kr/MOFI/ • Flow Bindings in Mobile IPv6 and NEMO Basic Support • draft-ietf-mext-flow-binding-14 • “미래인터넷을 위한 Addressing 및 Routing 아키텍쳐 연구 동향” • 정보과학회지, 2010년 1월 (28권 1호)

More Related