Multicast Mobility in Mobile IP Version 6 (MIPv6) : Problem Statement and Brief Survey

Publisher PD

Roaming Real-Time Applications - Mobility Services in IPv6 Networks

Emerging mobility standards within the next generation Internet Protocol, IPv6, promise to continuously operate devices roaming between IP networks. Associated with the paradigm of ubiquitous computing and communication, network technology is on the spot to deliver voice and videoconferencing as a standard internet solution. However, current roaming procedures are too slow, to remain seamless for real-time applications. Multicast mobility still waits for a convincing design. This paper investigates the temporal behaviour of mobile IPv6 with dedicated focus on topological impacts. Extending the hierarchical mobile IPv6 approach we suggest protocol improvements for a continuous handover, which may serve bidirectional multicast communication, as well. Along this line a multicast mobility concept is introduced as a service for clients and sources, as they are of dedicated importance in multipoint conferencing applications. The mechanisms introduced do not rely on assumptions of any specific multicast routing protocol in use.Comment: 15 pages, 5 figure

A Common API for Transparent Hybrid Multicast

Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group

Analysis of IPv6 Neighbor Discovery for Mobile and Wireless Networks

The majority of the current 3GPP and M2M networks use or will use IPv6 for accessing the internet. These IPv6 networks use Neighbor Discovery as defined in RFC 4861 to identify their neighbors on the link and see if they are active. The increase in the complexity of wireless networks and introduction of battery operated devices sets forth notable challenges to certain assumptions in the RFC 4861. The RFC 4861 is more suited for wired networks and its implementation in wireless networks makes it more inefficient. This thesis work focuses on the energy efficient implementation of RFC 4861 using the protocols mentioned in draft-chakrabarti-nordmark-6man-efficient-nd-06. The draft suggests a method of registering all the nodes in the network to their default router, so that the router takes care of all the basic neighbor discovery functionalities without disturbing the battery operated devices which are in sleepy mode. Alongside the legacy Neighbor Discovery, the optimizations proposed by the draft are implemented, on a RADVD based router and an Ubuntu host, to reduce redundant multicast signaling in mobile networks. These optimizations are theoretically analyzed to check if the draft is beneficial for the scalability and transient nature of the wireless networks.Popular Science Report With the rise of Internet of Things (IoT) and Machine to Machine communication (M2M) based networks, more and more wireless devices are communicating to each other and hence there is a need for IPv6 (Internet Protocol version 6) addressing. This new type of addressing forces us to make some design changes in the existing protocols. Wireless devices are mostly mobile, battery operated (hence a power constraint exists) and can undergo several disconnections and reconnections while moving inside the network, whereas wired devices are less prone to network instabilities and almost always connected to a power source. Because of these differences, the protocols of wired devices are not always suitable for wireless networks. Still today’s wireless devices often use protocols that were designed for wired devices and tend to be inefficient. This thesis work deals with one such protocol called Internet Control Message Protocol (ICMP), which is widely used to send control messages across the network between different nodes. Neighbor Discovery Protocol (NDP) is a part of ICMPv6 that helps a node in the network identify its Neighbors on the other side of the link. Present generation wireless devices use the protocols defined in RFC 4861 (a common reference used by major communication companies while creating products) for Neighbor discovery. But this protocol proves to be inefficient by flooding the network with unwanted multicast control messages. Hence we analyze a modified version of the existing NDP against the legacy protocol. RFC 4861 based ‘legacy NDP’ works based on multicasting. Every IPv6 host is a part of several solicited node multicast groups. All nodes with the same last 24 IPv6 address bits belong to the same solicited node multicast group. NDP is also performed based on 4 major control message packets namely, Router Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation (NS) and Neighbor Advertisement (NA). RA is the packet from the router which contains all the information about the network and the router. It is flooded periodically through an all node multicast group to all IPv6 nodes. When a node wants a particular router to send some information about the network immediately without waiting for periodic RAs, it sends an RS. Neighbor Advertisement is used by a node to send information about itself to other nodes in the network. Neighbor Solicitation, as name suggests, is used by a particular node to request for information about another node. Consider the case of a network with a host and a router, and a new node enters the network. It sends out RS to the all routers multicast group, and the router responds with an RA. The new host reads the information about the network and begins address configuration. Stateless Address Auto Configuration (SLAAC) is the most suitable method of address configuration for M2M networks. Hence according to SLAAC, the new host chooses an IP address and checks if the address has already been used by some other host. This process is called as Duplicate Address Detection (DAD) and is carried out by sending out NS for that chosen IP address at the solicited node multicast group address. This means that the new host asks information about a node with that IP address, which may or may not exist at all. If a reply comes, it means that there is a node using this address. If a reply does not come, then it is free to choose the address. The response NA in case of a duplicate address, will be broadcast to all IPv6 nodes. A NS-NA pair is also used to resolve each other’s IP addresses against their MAC addresses. One of the major reasons why this method seems to be inefficient is that current wireless devices are programmed to be in sleep modes when not in use. The flow of control messages to unrelated nodes (because of multicast) will only lead to disrupted sleep. Consider a host A in the network which is in sleep mode, and has an IP address aaaa::aaaa:aaaa:a. When a new host arrives and wants to register itself with an address of aaaa::baaa:aaaa:a, it sends out NS to the multicast group of A (because A has the same last 24 bits). When a packet reaches A, it wakes up from sleep mode, reads the message and identifies that this message was not destined to it. If there was another host in the group which used the same IP address, then host A will also receive another NA, which again is not of any use. Hence this protocol proves to be inefficient. The new proposed protocol works with an efficient implementation of the NDP. It introduces a concept of registering a host with a router. And the router sends out NS and NA instead of the host. Hence each router’s NCE will be the source of information for those hosts which are registered to that router. If a node will request for details about another host, the details will either be fetched from that router’s NCE or the NS will be forwarded to that particular host instead of being multicast. The router to whom the destination host is registered will then send NAs on behalf of its host. Hence in this protocol, the router performs more work and the host less, allowing the host to stay in sleep modes without any problems. The analysis of the two protocols begins with their implementation. We decided to test the working of the two protocols at two specific case scenarios: when several hosts join the network and when the channel links are unsteady. Both protocols were implemented and compared. The implementation of the legacy NDP began with a router and a host system. We used an Ubuntu PC (which generally works as a host) as a router. RADVD is an open source software that helps to generate RAs and Wireshark the software used to analyze packets in the network. To make a host work as a router, the following changes were made: 1. Turn on forwarding in the PC 2. Configure the router with a static IP address 3. Configure the interfaces and add corresponding routing information 4. Install RADVD and include all the network parameters in the config file 5. Turn on Wireshark 6. Turn on RADVD Once all these steps are done in order, the RADVD sends out periodic RAs that can be viewed on the Wireshark. When the host is connected to the network, the entire process of address configuration and DAD can be identified. When pinged, the address resolution process can also be verified. To implement the new protocol, we downloaded the source code of the open source RADVD from GitHub and change the packet formats of the RA, NS and NA. When the router works as a NEAR (Neighbor Discovery Efficiency Aware Router), the host has to understand that it should not use legacy NDP anymore and must act as an Efficiency Aware host (EAH). This information comes with the RA in the form of a flag. When this is done, the host sends an NS in the form of registration request. The details of the host go in the Address Resolution Option (ARO) of the NS. The router responds with an NA which is the acknowledgement for the registration request. Now the host can enter into sleep mode and the router will send control packets to it only when required. When the registration expires, a new registration process has to be setup or a de-registration process has to happen by setting the ARO option in the NS to 0. To implement the changes in the host side, we downloaded the source code for Linux from GitHub and led the decoder side. The process ends by making all the necessary code changes, recompiling a new Kernel and installing the new version of Linux on the hosts. However, the complete reprogramming of the kernel is not handled in this thesis work. But the entire plan for the programming and the rest of the implementation is included in this report. The theoretical analysis of the protocols is also included in this report. This report concludes with a general analysis of the whole protocol. The whole protocol which was completely decentralized has a certain degree of centralized control now. As with all systems, centralization introduces better control but there is always a problem of device failure which can completely collapse the system. The protocol also provides solutions for router failure and recovery and hence the system is a good compromise between centralized and decentralized systems. If properly implemented, there will be an increase in the network efficiency (inversely proportional to the number of control packets for every single data point). This thesis ends with the theoretical analysis. A proper implementation followed by a practical analysis would be a natural future amendment to the projec

Design and implementation of multicast listener discovery protocol on constrained devices

Para la aplicación y apoyo del uso de IPv6 en 6LoWPANs (Low-power Wireless Personal Area Networks), ha habido numerosas investigaciones y se han desarrollado protocolos y mecanismos estandarizados. Sin embargo para la comunicación multicast en estas redes, el tema esta aún bastante abierto a la investigación. La comunicación multicast permite conectar routers con hosts preseleccionados por grupos. La comunicación multicast es muy beneficiosa para aplicaciones con dispositivos con recursos limitados ya que ahorra energía y ancho de banda. A continuación mostramos posibles ejemplos de estas aplicaciones, la iluminación de un edificio organizada por plantas, una red de sensores de temperatura organizados por áreas y un largo número de aplicaciones basadas en la comunicación de un punto a varios puntos preseleccionados. El grupo de investigación de la universidad de Aalto (Finlandia) llamado MAMMoTH (Massive Scale Machine-to-Machine Service) tiene como uno de sus objetivos construir un protocolo multicast para dispositivos con recursos limitados. Para el desarrollo de este protocolo, es necesario un protocolo de encaminamiento multicast y un protocolo de gestión de grupos multicast. Este último, es el protocolo que he desarrollado como “research assistant” para mi proyecto final de carrera. En este proyecto final de carrera, se ha diseñado, implementado y evaluado el protocolo MLD para dispositivos con recursos limitados. MLD permite a un router IPv6 gestionar grupos multicast. No obstante, el uso de MLD en LoWPANs tiene varios problemas como la definición del area local, el tamaño de los paquete y la complejidad del comportamiento del router. El protocolo ha sido implementado en Contiki, un sistema operativo para desarrollar para el “Internet of Things”. Contiki permite conectar sistemas pequeños de poco coste con poca potencia a Internet. Hemos ampliado la pila TCP/IP de Contiki para respaldar MLD. El protocolo ha sido evaluado y analizado sobre un simulador en diferentes topologías para validar el funcionamiento. Del mismo modo, también se ha verificado que el tamaño del objeto creado no ocupaba más memoria de la disponible en los dispositivos Z1 Zolertia

Distributed mobility management - framework & analysis

Mobile operators consider the distribution of mobility anchors to enable offloading some traffic from their core network. The Distributed Mobility Management (DMM) Working Group is investigating the impact of decentralized mobility management to existing protocol solutions, while taking into account well defined requirements, which are to be met by a future solution. This document discusses DMM using a functional framework. Functional Entities to support DMM as well as reference points between these Functional Entities are introduced and described. The described functional framework allows distribution and co-location of Functional Entities and build a DMM architecture that matches the architecture of available protocols. Such methodology eases the analysis of best current practices with regard to functional and protocol gaps

Network-based localized IP mobility management: Proxy Mobile IPv6 and current trends in standardization

IP mobility support has been a hot topic over the last years, recently fostered by the role of IP in the evolution of the 3G mobile communication networks. Standardization bodies, namely IETF, IEEE and 3GPP are working on different aspects of the mobility aiming at improving the mobility experience perceived by users. Traditional IP mobility support mechanisms, Mobile IPv4 or Mobile IPv6, are based on the operation of the terminal to keep ongoing sessions despite the movement. The current trend is towards network-based solutions where mobility support is based on network operation. Proxy Mobile IPv6 is a promising specification that allows network operators to provide localized mobility support without relying on mobility functionality or configuration present in the mobile nodes, which greatly eases the deployment of the solution. This paper presents Proxy Mobile IPv6 and the different extensions that are been considered by the standardization bodies to enhance the basic protocol with interesting features needed to offer a richer mobility experience, namely, flow mobility, multicast and network mobility support.European Community's Seventh Framework ProgramThe research leading to the results presented in this paper has received funding from the Spanish MICINN through the I-MOVING project (TEC2010-18907) and from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement 258053 (MEDIEVAL project).Publicad

Monitoring multicast traffic in heterogeneous networks

Estágio realizado no INESC - Porto e orientado pelo Prof. Doutor Ricardo MorlaTese de mestrado integrado. Engenharia Electrotécnica e de Computadores - Major Telecomunicações. Faculdade de Engenharia. Universidade do Porto. 200