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.

RINA Tutorial at ETSI ISG NGP#3


Published on

RINA Tutorial presented at the 3rd meeting of the ETSI ISG NGP, showing basic RINA structure and mechanisms, as well as a "toy" example of a mobile network with RINA

Published in: Internet
  • Be the first to comment

RINA Tutorial at ETSI ISG NGP#3

  1. 1. RINA TUTORIAL Eduard Grasa on behalf of i2CAT, Waterford Institute of Technology, Boston University, Interoute, Telefonica 27th July 2016 © ETSI 2014. All rights reserved
  2. 2. Goals Discuss the structure of RINA (layers, components within a layer) Disuss the main operational procedures of a RINA layer (data transfer, layer management) Discuss how RINA can be applied to the design of a mobile network © ETSI 2014. All rights reserved2 2
  3. 3. RINA structure © ETSI 2014. All rights reserved3 3 Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF (Distributed IPC Facility) Host App A App B Consistent API through layers IPC API Data Transfer Data Transfer Control Layer Management SDU Delimiting Data Transfer Relaying and Multiplexing SDU Protection Retransmission Control Flow Control RIB Daemon RIB CDAP Parser/Generator CACEP Enrollment Flow Allocation Resource Allocation Routing Authentication StateVector StateVector StateVector Data TransferData Transfer Retransmission Control Retransmission Control Flow Control Flow Control Increasing timescale (functions performed less often) and complexity Namespace Management Security Management
  4. 4. Naming and addressing © ETSI 2014. All rights reserved4 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).
  5. 5. Data transfer procedures 5 © ETSI 2014. All rights reserved
  6. 6. Layer management structure © ETSI 2014. All rights reserved6 Resource Information Base (RIB): Schema that defines the external representation of the set of objects that model the state of the IPCP (object names, attributes, relationships, allowed CDAP operations and their effects) Common Distributed Application Protocol (CDAP): Application protocol that allows two applications to operate on the objects of each other’s RIB. Provides 6 operations (create/delete/read/write/start/stop). RIB Daemon: Entity that processes incoming CDAP messages (delegating RIB operations to layer mgmt tasks) and generates outgoing CDAP messages from layer management tasks’ requests
  7. 7. Mobile network example This is just an example to illustrate the main mechanics of how RINA can work in a mobile network environment -> it does not pretend to be a real design • Real design would exploit multiple layers Assumptions • Similar structure to LTE networks, so that it is easier to understand • UE can only be actively connected to one** eNodeB at a time (seems to be a constraint of current mobile networks, right?) 7 © ETSI 2014. All rights reserved
  8. 8. Tutorial Example: RINA network similar to LTE Voice Layer, Public Internet Layer, etc.. are layers allowing applications in the UE to communicate to other applications (equivalent to PDN) Mobile network top-level Layer provides flows between the UEs and Packet Gateways (flows provided by this DIF equivalent to EPS bearer). Can perform mobile network-wide congestion control, routing, resource allocation, etc. Multi-access Layer (radio). Radio DIF between the UE and eNodeB, responsible for radio resource allocation and to provide flows between UE and eNodeB supporting the mobile network top-level DIF (equivalent to RLC, MAC and PHY layers together).© ETSI 2014. All rights reserved8 Voice Layer Public Internet Layer (or other) Mobile network top-level Layer Multi-access Layer (radio) Internal Layer PtP Layer . . .UE eNodeB S-GW P-GW Op. Layer PtP Layer PtP Layer Internal layer PtP Layer . . . PtP Layer 8
  9. 9. Enrollment (UE attaches to the network) Focus on the Mobile Network top level DIF © ETSI 2014. All rights reserved9 Multi-access Layer (radio) eNodeB UE IPCP IPCP 1. Allocate N-1 flow 2. Establish application connection (CACEP, includes authentication) 1. M-CONNECT (UE to eNodeB) 2. Authentication messages 3. M_CONNECT_R (eNodeB to UE) 3. UE gets address and other information required to operate on the DIF 4. RIB update (after enrollment) Authentication = authentication, key agreement, setup of SDU Protection (encryption, message integrity) eNodeB could authenticate itself or delegate the procedure to another trusted IPCP or the Management System
  10. 10. UE enrolls to mobile network DIF without authentication, but only the MA in the UE is allowed to request the allocation of a flow, and only to the “NMS DAF” (which plays the equivalent role of the “control plane” in LTE) MA at the UE allocates flow to the NMS DAF, and enrolls to the NMS DAF; which requires authentication and key agreement, and setup of SDU protection (at the MA and NMS-Auth processes) After joining, other apps in the UE can allocate flows to destination applications Example “LTE-style” © ETSI 2014. All rights reserved10 Multi-access Layer (radio) eNodeB UE IPCPIPCP MME / Authenticating entity IPCP Mobile network DIF MA NMS – Auth NMS DAF
  11. 11. Akamai DIF Apps in the UE request flows to other apps (I) UE has not joined any DIF providing access to “end applications”. A browser app in the UE requests a flow to the destination application, with flow characteristics X, Y, Z. Request is processed by local IPC Manager, which asks DIF Allocator through what DIF is available the dest. Application • DIF Allocator keeps a distributed map of application to DIF mappings (not enough time to cover details here) © ETSI 2014. All rights reserved11 Voice DIF Public Internet DIF Mobile network top-level Layer Multi-access Layer (radio) Internal Layer PtP Layer . . .UE Op. Layer PtP Layer PtP Layer Internal layer PtP Layer . . . PtP Layer eNodeB S-GW P-GW Brow ser
  12. 12. Akamai DIF Apps in the UE request flows to other apps (I) DIF Allocator resolves to the public Internet DIF. UE creates an IPCP, that requests an N-1 flow towards the “public Internet DIF” to the mobile network top level DIF. Mobile network top level DIF resolves the “public Internet DIF” app name to the IPCP that is more convenient (public Internet DIF may be available from multiple P-GWs). Once the flow is allocated, IPCP at the UE proceeds to enroll with the DIF. • Procedure is the same regardless what DIF the UE is joining (Akamai, voice, etc..) © ETSI 2014. All rights reserved12 Voice DIF Public Internet DIF Mobile network top-level Layer Multi-access Layer (radio) Internal Layer PtP Layer . . .UE Op. Layer PtP Layer PtP Layer Internal layer PtP Layer . . . PtP Layer eNodeB S-GW P-GW Brow ser IPCP
  13. 13. Apps in the UE request flows to other apps (II) After enrollment the browser flow allocation request is processed by the public Internet DIF, and the flow allocated. NOTE, this procedure can be tailored: • UE can be made to join the relevant DIFs / a default DIF after attachment to the network (and not wait until an application makes a request) • Instead of using DIF allocator, user @ UE could configure what DIFs he would like to join (similar to the APN settings today) © ETSI 2014. All rights reserved13 Public Internet DIF Mobile network top-level Layer Multi-access Layer (radio) Internal Layer PtP Layer . . .UE Op. Layer PtP Layer PtP Layer Internal layer PtP Layer . . . PtP Layer eNodeB S-GW P-GW Brow ser
  14. 14. Structure of the mobile network DIF (idealized example) © ETSI 2014. All rights reserved14 eNodeB eNodeB eNodeB eNodeBeNodeB Tracking Area 1 Tracking Area 2 S-GW S-GW Serving Area 1 eNodeB eNodeB eNodeB eNodeBeNodeB Tracking Area 1 Tracking Area 2 S-GW S-GW Serving Area 2 P-GW P-GW UE
  15. 15. Forwarding at P-GW © ETSI 2014. All rights reserved15 P-GW is the destination of UL packets coming from UEs, so just send layer up For DL packets: if UE’s address contains the serving area where the UE is located, and S-GW address contains service area it belongs to, P-GW just needs to store @ of neighbor S-GWs in its forwarding table, and forward to any S-GW in the serving area of the destination UE • If more than one S-GW possible, chose based on load, etc. P-GW S-GW S-GW S-GW S-GW
  16. 16. Forwarding at S-GW © ETSI 2014. All rights reserved16 UL packets (dest @ is a P-GW): Just need to store the @ of neighbor P-GWs, and forward to them (1 hop) For DL packets (dest @ is a UE): Keep next hop-addresses for all UEs in the serving area. Needs to be updated every time UE changes eNodeB; 2 approaches possible: • Autonomous/distributed (via e.g. link-state routing within the serving area) or • Centralized via the NMS DAF (MME recomputes the graph and modifies forwarding rules in S-GWs) P-GW S-GW P-GW eNodeB eNodeB eNodeBeNodeB
  17. 17. Forwarding at eNodeB © ETSI 2014. All rights reserved17 UL packets (dest @ is a P-GW): • If attached to a single S-GW, forward there • If attached to multiple, need entries in the forwarding table per P-GW (disseminated via link-state in the area, for example) For DL packets (dest @ is a UE): • The UE is attached to this eNodeB, send to UE directly (single hop) • The UE is in a neighbor eNodeB (may be the case during handovers), during handover a forwarding table entry will have been installed S-GW eNodeB S-GW UE UE UE eNodeB
  18. 18. Forwarding at UE © ETSI 2014. All rights reserved18 UL packets (dest @ is a P-GW): Forward to eNodeB (next hop) For DL packets (dest @ is a UE): Send layer up eNodeB UE
  19. 19. Routing/forwarding policy: Summing up Assumptions (this is just an example routing policy to show how it can work, there can be others that are more effective): • UE @ and S-GW @ contains service area id. • S-GW and eNodeBs run Link state routing within service area P-GWs just need to store forwarding rules for direct neighbors (S-GWs) S-GWs need to store forwarding rules for i) P-GWs that are direct neighbors ii) All UEs within serving area eNodeBs need to store forwarding rules for i) S-GWs that are direct neighbors (if more than one) ii) UEs that are attached to the eNodeB or neigbhor eNodeB during Handover; iii) P-GWs if eNodeB has more than one neighbor S-GW UEs don’t need to store forwarding table entries. UE’s @ needs to change when it moves from one serving area to another (no issue in RINA, changing @s does not break active flows, see later) Lar ge- sca le RIN A Exp 19
  20. 20. Handover, what happens? (I) (within same serving area = no change of address) Handover decision is done (via NMS?, source eNodeB?, UE?, cooperation between them?), destination eNodeB is selected Source eNodeB starts buffering packets addressed to the UE (note: this would not be required if UE could be multi-homed to 2 enodeBs) Source eNodeB modifies entry in forwarding table for the UE address, with next hop the destination eNodeB (sets Timer for expiration of this entry). UE enrolls to destination eNodeB Handover is done, destination eNodeB tells source eNodeB. Source eNodeB stops buffering packets to UE. After a while the forwarding table entry for the UE in the source eNode B expires. © ETSI 2014. All rights reserved20
  21. 21. Handover, what happens? (II) (between serving areas = UE change of address) Same as before except that UE gets new address when enrolling to destination eNodeB. Dest eNodeB communicates the new address to the source eNodeB, which adds an extra fowarding table entry for the new UE address. EFCP instances in UE start using new address in outgoing EFCP PDUs. P- GWs with EFCP flows with the UE start seeing the new UE address in incoming PDUs. EFCP instances start using the new address for outgoing EFCP PDUs (old address is no longer present in EFCP PDUs). When timers expire source eNodeB removes forwarding table entries (this time there are two) and UE forgets old address. © ETSI 2014. All rights reserved21
  22. 22. Mobile network with multiple layers © ETSI 2014. All rights reserved22 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 … … … In this example “e-mall” DIFs (providing access to applications) are available via the regional DIF, but could be available also through metro or district DIFs • Essentially, every border router can be a “mobility anchor”, no need to do anything special. Under DIFs Operator core
  23. 23. Example with 4 levels (where needed) © ETSI 2014. All rights reserved23 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
  24. 24. THANKS FOR YOUR ATTENTION! © ETSI 2014. All rights reserved24