Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The hague rina-workshop-mobility-eduard


Published on

RINA Mobility

Published in: Internet
  • Be the first to comment

  • Be the first to like this

The hague rina-workshop-mobility-eduard

  1. 1. Naming, addressing, mobility in RINA Naming, addressing, mobility in RINA Eduard Grasa, FP7 PRISTINE SDN World Congress 2016, The Hague, October 2016
  2. 2. What is H2020 ARCFIRE doing? Naming, addressing, mobility in RINA 2 Experimentally validate the real benefits of the RINA technology, leveraging the FIRE+ experimental infrastructure, making compelling business cases that motivate for its deployment and adoption 100+ nodes 10s - 100s of DIFs 1 week long exp. DDoS attacks Multi-layer Mgmt Heterogen. access Polyservice networks Experimental facilities RINA tooling for FIRE+ Procedures for RINA exp. Converged operators Application developers End Users
  3. 3. Naming & addressing in one slide Application names: Assigned to applications. Location independent. Uniquely identify application within an application namespace. In general name a set (can have a single member). Addresses: Location-dependent synonym of an App name. Facilitates locating the app within a certain context (e.g. IPCPs in a DIF). Its scope is restricted to the DIF. Port-ids: Identifies one end of a flow within a system (local identifier), only id shared with user.** Connection endpoint ids (cep-ids): Identify the EFCP instances that are the endpoints of a connection. QoS-id: Identifies the QoS cube to which the EFCP PDUs belong (PDUs belonging to the same QoS-id receive receive a consistent treatment through the DIF). Naming, addressing, mobility in RINA 3
  4. 4. Implications for multi-homing Naming, addressing, mobility in RINA 4 G A B C E D F H 1 2 6 5 8 3 14 18 17 16 15 19 21 13 20 9 11 10 12 4 7 2 2 G A B C E D F H 1 2 3 1 2 1 3 4 1 2 3 1 2 3 1 2 3 1 1 2 2 2 • Addressing the node instead of the interface: 3-4x time routing/forwarding table reduction! • No need for special protocols to support multi-homing Addresses assigned to interfaces (like in IP) Addresses assigned to nodes (like in RINA)
  5. 5. Implications for mobility • Mobility is just dynamic multi-homing with expected failures • No need for tunnels -> handovers trigger routing updates • Addresses are just temporary synonyms -> IPCP name is stable Naming, addressing, mobility in RINA 5 BS 1.2.1 BS 1.2.2 BS 1.2.3 BS 1.2.5 BS 1.2.4 S-GW 1.1.1 S-GW 1.1.2 Serving Area 1 BS 2.2.1 BS 2.2.2 BS 2.2.3 BS 2.2.5 BS 2.2.4 S-GW 2.1.1 S-GW 2.1.2 Serving Area 2 P-GW 0.1.0 P-GW 0.2.0 UE 1.0.1 UE 1.0.1 UE 2.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 2.0.1 Example: Mobility within a single DIF
  6. 6. Mobile network with multiple layers Border Router Core DIF Under DIFs Border Router Under DIFs Border Router Interior Router (Base Station) Host (Mobile) BD DIF (radio) Under DIFs District DIF Metro DIF Regional DIF Public Internet DIF Application-specific DIF Mobile Infrastructure NetworkCustomer Terminal … … … Under DIFs Operator core • Create as many DIFs as needed depending on density of mobile devices and speed of mobility in different parts of the mobile network • Each application can use the DIF it provides enough scope and QoS for its communication needs -> not restricted to the “top ones” • All layers have the same structure and protocols, implementations can be highly optimized; overhead of adding new layers is minimal
  7. 7. Example with 4 levels (where needed) Urban Sub-urban Urban UrbanDense Urban BS DIF District DIF LegendMetro DIF Regional DIF • 4 levels of DIFs may not be needed everywhere (e.g. suburban, not enough density to require a district DIF). • If more levels needed to scale can be added anywhere in the network
  8. 8. Renumbering demo • Goal: show an example of a use case enabled by a complete naming and addressing architecture • Since addresses are just temporary synonyms assigned to the node in the layer (IPCP), renumbering is no problem (can be done live, without impacting existing flows or new ones) • Applications: – Change addressing policy/scheme as network grows – Consolidate two different addressing policies after merge – Mobility: Keep addresses of IPCPs in mobile nodes aligned to an abstraction of the network connectivity graph as they move (to minimize size of forwarding tables in the DIF) Naming, addressing, mobility in RINA 8
  9. 9. Demo: renumbering in a single DIF 9 MADLIS DUB LON PAR BRU AMS LUX BER N ROM VAL LJU ATH NIC ANK SOF BUCBUD ZAG VIE BER PRA COP OSLO STO TAL RIGA VIL WAR MOS N-flows N-1 flows • IPCPs change addresses randomly (change period uniformly distributed 30-60s) • 4 flows (allocated by echo application), between: – Lisbon-Riga / Dublin-Ankara / Valletta-Oslo / Brussels-Nicosia • Show that address change is not noticed by applications using the DIF: – Existing flows continue operating; new flows can be allocated
  10. 10. • Addresses are internal to the DIF, upper layers (applications or other DIFs) never get to see them -> flow allocation is based on application names • Each DIF has an internal directory to map application names to IPCP addresses -> if IPCP addresses change, just issue a directory update • E.g. current demo DIF uses a directory policy that replicates the directory across all IPCPs in the DIF (equivalent to distribution of link-state routing info). Many other policies are possible and adequate for different environments (e.g. ARP-like, DNS-like, DHT-like, etc..) How does this work? Nothing special (I) PtP DIF IPCP MAD IPCP LIS IPCP MOSDIF “Renumber” Client 1 Server 1 IPCP BER PtP DIF PtP DIF IPCP BERN PtP DIF
  11. 11. • When an IPCP changes addresses, it needs to distribute the new address through the routing system, so that other IPCPs will know how to forward traffic to it, but still doesn’t deprecate the old address. Details on how to do it depend on the routing policy used in the DIF. – E.g. for link-state routing, the IPCP just advertises new LSAs with its new address • After a while all IPCPs in the DIF will know how to forward traffic to the new address. Then the IPCP can start using it. How? Just start using the new address as the source address in all EFCP PDUs – EFCP receivers in other IPCPs will notice the change and start using the new address as the destination address of EFCP PDUs • After a while all IPCPs in the DIF are using the new address, so the IPCP can let the old address die. To do that, it just advertises the old address as deprecated via the routing system. – E.g. for link-sate routing, the IPCP advertises the LSAs with the old address as deprecated (expired), so that the other IPCPs will remove it from their databases How does this work? Nothing special (II)
  12. 12. Naming, addressing, mobility in RINA Thanks for your attention! 12