Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to RINA TUTORIAL ON MOBILE NETWORK DESIGN
Similar to RINA TUTORIAL ON MOBILE NETWORK DESIGN (20)
More from ARCFIRE ICT
More from ARCFIRE ICT (19)
Recently uploaded
Recently uploaded (20)
RINA TUTORIAL ON MOBILE NETWORK DESIGN
- 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. 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. 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. 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. Data transfer procedures 5 © ETSI 2014. All rights reserved
- 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. 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. 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. 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. 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. 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 http://portal.etsi.org, 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. Akamai DIF Apps in the UE request flows to other apps (I) DIF Allocator resolves http://portal.etsi.org 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. THANKS FOR YOUR ATTENTION! © ETSI 2014. All rights reserved24
Editor's Notes
- (Good stuff ;-) You might also include the 4 characteristics of the new paradigm to really establish that this was a different world.) I put this here rather than at the end so you would see it! ;-) After visiting Boston soon after the ARPANET began, Louis Pouzin then at IRIA set out to assemble a team to build a network, called CYCLADES specifically for doing research on networks. Pouzin’s team had a couple of advantages: they could learn from BBN’s experience and were greatly assisted by them. Also, they were looking at the whole problem: the hosts and the network. Michel Elie and Hubert Zimmermann recognized that there were layers both in the hosts and the network. But more importantly, they were not simply a stack of black boxes in a system, but were a cooperative collection of processes in different systems. And most importantly, the layers had different scope. Packets could only be relayed within a layer so far before having to be relayed by the layer above. Not all systems were involved in all layers. Pouzin had previously worked on Multics the pre-cursor to Unix, where he invented the shell. IRIA (Institute Research de Informatique et Automatique) became INRIA (Nationale was added) in 1979. By 1972, CYCLADES had arrived at the concept of the layers for a network, which had increasing scope: Layer 1: The Physical Layer was the physical media. . . the wire. Layer 2: The Data Link Layer (at this early stage was a point-to-point HDLC-like protocol) ensured that datagrams were not corrupted in transit. Layer 3: The Network Layer relayed datagrams through the network, but would be subject to loss due to congestion and the rare memory error during relaying. Layer 4: The Transport Layer provides end-to-end error control and recovers from loss due to congestion. Layer 5: The Application Layer, the rationale for the network.
- Note that we don’t distinguish the processes that instantiate the layer in a system from *applications.* They are all just processes. IPC Processes consist of sub-tasks, threads, etc. perhaps even some is an FPGA. The scope of applications names is greater than any layer. Connection-id is formed by concatenating CEP-ids. Port-ids are never exchanged in protocol. Addresses are never visible the user of the layer.
- It will cause less confusion if you put SDU protection below RMT, especially the middle one where it looks like you are sending it without doing it. It is in the text, but I think people look at figures first. Your decision.
- RIB daemon also ensures that the information maintains the required level of freshness (synchronization), e.g. routing update as well as load information.
- You might want some back up slides for multiple layers. That part is going to be hard for them to grasp. Especially since they seem to have a hard time even grasping how multihoming works.
- Each layer can provide flows of different QoS, with its internal policies (like scheduling, flow control or transmission control) designed to support the advertised QoS level. With this design current LTE protocols are just policies for the common layer machinery, specifically (refer to Figure 7): The MAC protocol becomes scheduling and medium access control policies for the multi-access radio DIF. The RLC protocol becomes delimiting and retransmission control policies for the multi-access radio DIF. PDCP becomes SDU protection policies for the mobile network top-level DIF (applied only between UEs and eNodeBs). GTP-U is not needed, it is just a connection-id that is already part of the common layer machinery. EPS bearers are flows provided by the mobile network top-level DIF. Radio bearers are flows provided by the multi-access radio DIF. Since in this design the mobile network top layer is a complete layer, it can perform functions such as differential (per QoS-class) congestion control, dynamic/static QoS-aware routing or SDU protection between eNodeBs and S-GWs and SGW-s and P-GWs.
- Serving area: This is an area served by one or more serving gateways S-GW, through which the mobile can move without a change of serving gateway. Tracking area: The MME pool areas and the S-GW service areas are both made from smaller, non-overlapping units known as tracking areas (TAs). They are similar to the location and routing areas from UMTS and GSM and will be used to track the locations of mobiles that are on standby mode
- No need for tunnels nor to keep mappings between tunnels!
- Note that forgetting an old address is just part of normal operation of the routing protocols. I know they can’t do it now, but point out that multihoming the radio will greatly reduce dropped calls and simplify the handoff procedure. Destination eNodeB selects new address for UE, which still keeps old address. Destination** eNodeB tells new address to source eNodeB. 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 entry and UE forgets old address.
- Note that forgetting an old address is just part of normal operation of the routing protocols. I know they can’t do it now, but point out that multihoming the radio will greatly reduce dropped calls and simplify the handoff procedure.