Distributed Mobility Management in the Context of the MEDIEVAL Project: MEVICO Final Seminar, Part 2

1. Distributed mobility management in the context of the MEDIEVAL project MEVICO Final Seminar, part 2 23rd November 2012 Carlos J. Bernardos, UC3M cjbc@it.uc3m.es

2. Why MEDIEVAL? • Video is a major challenge for the future Internet • Current mobile Internet IS NOT designed for video • Today’s architectures are very inefficient when handling video • Future mobile Internet architecture should be tailored to efficiently support the requirements of this type of traffic • Specific enhancements for videoshould be introduced at all layers of the protocol stack where needed

3. Our Vision Evolutionary path for a truly video-for-all philosophy

4. The Consortium MEDIEVAL is an operator-driven project specifying and demonstrating a mobile video architecture with cross-layer mechanisms to provide high quality of experience to users

5. DMM + CDN MEDIEVAL has designed and is evaluating amobile Internet architecture to efficiently support the upcoming growth of video services • Based on the Distributed Mobility Management (DMM) paradigm • Integrating the mobility services with video content distribution services – the DMM+CDN concept • Video caches are co-located with the mobility anchors of theDMM architecture

6. Why DMM? • Current Internet mobility schemes rely on a centralized mobility anchor. E.g.: • Home Agent (HA) in MIPv6 • Local Mobility Anchor (LMA) in PMIPv6 • These entities are the cardinal node both for control and data plane • Hence they are prone to several problems and limitations • Longer (sub-optimal) routing paths • Scalability issues • Single point of failure • Lack of granularity on the mobility service

7. Distributed Mobility Management • The IETF community chartered a working group called Distributed Mobility Management (DMM) to develop new mobility solutions • http://datatracker.ietf.org/wg/dmm/is the WG homepage • http://datatracker.ietf.org/doc/draft-ietf-dmm-requirements/ is the first WG document • http://tools.ietf.org/id/draft-bernardos-dmm-pmip-01.txt is the network-based mobility solution proposed by MEDIEVAL • http://tools.ietf.org/id/draft-bernardos-mext-dmm-cmip-00.txt is the client-based solution proposed by MEDIEVAL

8. The MEDIEVAL DMM solution • The central anchor is removed • The mobility services are pushedtowardsthe edge of the network,offered in a distributed wayby the access routers

9. The MEDIEVAL solution • A new node is introduced • Mobility Access Router (MAR) • First IP-hop and default gateway seen by aMobile Node (MN) • It implements the following functionalities defined by IETF standards: • Home Agent (HA) – Mobile IPv6, RFC 6275 • Local Mobility Anchor (LMA) – Proxy Mobile IPv6, RFC 5213 • Mobile Access Gateway (MAG) – Proxy Mobile IPv6, RFC 5213

10. The MEDIEVAL solution • A set of interconnected MARs forms aLocalized Mobility Domain (LMD) • Within the LMD, the mobility service is provided in a network-based fashion (PMIPv6-like) • The MN is not required to update its new location • MARs learn about the MN’s movements by means of a dedicated Layer 2 control infrastructure • IEEE 802.21 Media Independent Handover Services • The MNs’ mobility sessions are distributed among the MARs • MARs exchange Proxy Binding Update and Acknowledgement messages to update the MNs’ mobility sessions and set up the appropriate routing

11. Layer 2 Handover • The handover is prepared, assisted and notified to upper layers using a dedicated control plane: • IEEE 802.21 Media Independent Handover (MIH) Services • Make-Before-Break handover • Radio link degradation detection • Resource availability query in surroundingPoints of Attachment (PoA) • Target selection and resource preparation before handoff • Detachment and attachment detection • Vertical (i.e., inter-technology) handover support • Drives the whole handover phase by means of MIH users running in the terminal and in the network

12. IP mobility management (I) • When a Mobile Node attaches to a MAR it gets an IPv6 prefix from the MAR’s prefix pool, with which it configures an address topologically anchored at the MAR • The MN starts communications withthe just configured address • The MAR acts as standard IPv6router for this flow • MN can send/receive trafficwith no packet encapsulation MAR1 MAR3 MAR2 Pref1::Addr1

13. IP mobility management (II) • Upon moving to a new MAR, the MN gets another IPv6 prefix to configure a new address • In order to maintain ongoing communication, the new MARsends a Proxy Binding Update message to theprevious MAR, indicating its own addressas the MN’s Care-of-Address (CoA) • The old MAR replies with a ProxyBinding Acknowledgment message;a tunnel is established between thetwo MARs and flows can be deliveredto the MN’s new location MAR1 MAR3 MAR2 PBU PBA ? Pref1::Addr1 Pref2::Addr2

14. IP mobility management (III) • This situation for the green flow recalls PMIPv6, giventhat MAR2 acts as a MAG and MAR1 as the LMA • However, new communicationsare started using the IP addressacquired from the MARthe MN is currently attached to • The new flow does notrequire tunnels nor specialpacket handling MAR1 MAR3 MAR2 Pref2::Addr2 Pref1::Addr1

15. IP mobility management (IV) • When another handover occurs, the new MAR updates MN’s location at all the MARs anchoring active flows • A PBU/PBA handshake takes placewith each of such MARs • Tunnels are moved/createdand the flows are redirected MAR1 MAR3 MAR2 PBU PBA PBA PBU ? Pref2::Addr2 Pref3::Addr3 Pref1::Addr1

16. DMM + CDN (I) • The DMM protocol allows to benefit from the shortest path from the MN to destination • Because a new IP address is used by the MN for new IP connections • Ongoing flows are maintained alive through the reachabilityof old addresses Applying this concept to video streams,MEDIEVAL enhances the quality of video delivery, by following the principle that a MN should download the video from the MARit is currently attached to

17. DMM + CDN (II) • CDN nodes are co-located with MARs • MARs are provided with video caches • Data delivery through HTTP progressive download • Video file fragmented into chunks, each chunk downloaded using HTTP • If the requested content is available locally, the MAR starts sending it to the MN • During the video playback, if the MN moves to another MAR: • Current chunk is transferred using the mobility tunnel • Next chunks are downloaded from the new MAR

18. DMM + CDN Demo • The MN moves within a MEDIEVAL domain with heterogeneous access technologies, consuming a video stream while having a VoIP communication • The MN starts being connectedwith 3G to MAR1 • The video is requested to thevideo server • MAR1 intercepts the request andsends the file to the MN • The MN switches to WiFi andconnects to MAR2 • The video is delivered by MAR2 • The VoIP flow is anchored to MAR1 • The MN finally moves to LTE and MAR3 • The behavior is replicated in the new access network • CDN nodes are co-located with MARs • The MN is able to download the video from the MAR it is currently attached to

19. Conclusion • Mobile data traffic is expected to greatly increase in future years (especially video) • Current mobility management solutions might not be able to cope with such large amount of traffic • MEDIEVAL project’s objective is to design a mobile architecture optimized for video transport • The mobility management follows a distributed and dynamic approach • An hybrid scheme using both PMIPv6 and MIPv6 has been investigated as baseslinefor the development • The handover control is delegated to IEEE 802.21 • Controllers in the MN and in the network have been introduced to perform mobility at flow-level and on-demand

20. Thank you for the attention Questions? http://www.ict-medieval.eu/