Embed Size (px)
Citation preview
DISTRIBUTED MOBILITY MANAGEMENT
DMM
Presented by:Abeer FathyAya MahmoudRawan RamzySara Abdulatif
Agenda
The Internet Area.
Charter of the working group.
DMM Draft.
DMM RFC
Contact Information
The Internet Area
The primary technical topics covered by the Internet Area include IP layer (both IPv4 and IPv6), implications of IPv4 address depletion, co-existence between the IP versions, DNS, host and router configuration, mobility, VPNs and various link layer technologies.
Charter of The Working GroupMobility
means the ability of a Host to overcome the location dependent nature of IP addresses by a suitable translation mechanism, and to send and receive data efficiently from any location. The user
should not be required to restart applications or in the worst-case reboot, when visiting a new network.
Network A
Node 2 Node 1
Network B
IETF DMM working group creation DMM protocol aims at distributing traffic in an optimal way and not rely on centrally deployed mobility anchors to manage IP mobility sessions.
The DMM WG will consider the latest developments in mobile networking research and operational practice and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions.
DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet.
Mobile Node Identifier Draft
The Mobile Node Identifier Option for MIPv6 has proved to be a popular design tool for providing identifiers for mobile nodes during authentication procedures with AAA protocols (Authentication, Authorization and Accounting)
IETF DMM Working Group proposes adding some basic types that are defined in various telecommunications standards.
Defining identifiers that are tied to the physical elements of the device (RFID, MAC address etc.)
IP because in many cases such identifiers are the most natural means for uniquely identifying the device.
The Tag Data standard promoted by Electronic Product Code(TM) (abbreviated EPC) supports several encoding systems or schemes including:
RFID-GID (Global Identifier),
RFID-SGTIN (Serialized Global Trade Item Number),
RFID-SSCC (Serial Shipping Container),
RFID-GLN (Global Location Number),
RFID-GRAI (Global Returnable Asset Identifier),
RFID-DOD (Department of Defense ID), and
RFID-GIAI (Global Individual Asset Identifier).
The new mobile node identifier types should be assigned values from the "Mobile Node Identifier Option Subtypes" registry.
Some identifiers are considered to be private information. If used in the MNID extension, the packet including the MNID extension should be encrypted so that personal information would not be inadvertently disclosed to passive observers.
MNIDs containing sensitive identifiers might only be used for signaling during initial network entry.
Requirements for Distributed Mobility Management RFC
Mobility management is needed because the IP address of a mobile node may change as the node moves.
At the IP (network) layer, mobility management can be client-based or network-based.
Session Identifier: the original IP address before the mobile node moves.
Forwarding Address: the new IP address of the mobile node after the node has moved.
Packets addressed to the session identifier will first route to the original network, which redirects them using the forwarding address to deliver to the session.
Centralized vs. Distributed Mobility Management
Centralized Mobility Management:The location information is kept at a single mobility anchor, and packets destined to the session identifier are forwarded via this anchor. Mobility management systems are centralized in both the control plane and the data plane.
Centralized mobility anchoring in a hierarchical network architecture.
Distributed Mobility ManagementMobility management functions can be distributed in the data plane to multiple networks, so that a mobile node in any of these networks may be served by a nearby function with appropriate forwarding management (FM) capability.
DMM is distributed in the data plane, whereas the control plane may be either centralized or distributed.
It is not necessary for other functions such as subscription management, subscription databases, and network access authentication to be similarly distributed.
Problem Statement1. Non-Optimal RoutesForwarding via a centralized anchor often results in non-optimal routes, thereby increasing the end-to-end delay.
2. Divergence from other evolutionary trends in network architectures such as distribution of content deliveryMobile networks have generally been evolving towards a flatter and flatter network. Centralized mobility management, which is non-optimal with a flatter network architecture, does not support this evolution.
3. Lack of scalability of centralized tunnel management and mobility context maintenance:Setting up tunnels through a central anchor and maintaining mobility context for each MN usually requires more concentrated resources in a centralized design, thus reducing scalability.
4. Single point of failure and attack:The impact of a successful attack on a system with centralized mobility management can be far greater than a distributed mobility system.
Solution (Req1) Servers are distributed so that each user in any location can
be close to one of the servers.
Solution Cont.
Single points of failure are avoided in a distributed system and threats against centrally deployed anchors.
DMM solutions (IP mobility, network access solutions, and forwarding solutions) MUST enable traffic to avoid traversing a single mobility anchor far from the optimal route.
5. Unnecessary mobility support to clients that do not need it:IP mobility support is usually provided to all MNs. However, it is not always required, and not every parameter of mobility context is always used. • some applications/nodes do not need a stable IP address during
a handover to maintain session continuity.• Sometimes, the entire application session runs while the MN
does not change the point of attachment. • Some sessions can handle mobility at the application layer. (do
not need IP mobility support)It is then unnecessary to provide IP mobility support for such sessions.
6. Mobility signaling overhead with peer-to-peer communication:Resources may be wasted when mobility signaling is not turned off for peer-to-peer communication.
Solution (Req2)
Selecting an IP address or prefix according to whether mobility support is needed and by not maintaining context at the mobility anchor when there is no such need.
DMM solutions MUST provide the possibility of independent handling for each application session of a user or mobile device.
7. Deployment with multiple mobility solutions
There are already many variants, extensions, and mobility solutions of MIP at other layers. Deployment of new mobility management solutions can be challenging, and debugging difficult, when they coexist with solutions already deployed in the field.
Solution (Req3)
DMM implementations MUST be able to coexist with existing network deployments, end hosts, and routers that may or may not implement existing mobility protocols.
8. Duplicate multicast traffic
IP multicast distribution over architectures using IP mobility solutions may lead to convergence of duplicated multicast subscriptions towards the downstream tunnel entity. Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths.
Solution (Req4)
• Existing multicast and non-optimal forwarding for the multicast traffic deployments have been introduced after completing the design of the reference mobility protocol, often leading to network inefficiency
• DMM should instead consider multicast early in the process, so that the multicast solutions can better consider the efficient nature of multicast traffic delivery .
RequirementsREQ5: IPv6 deployment:DMM solutions SHOULD target IPv6 as the primary deployment environment and SHOULD NOT be tailored specifically to support IPv4.
REQ6: Existing mobility protocols:DMM solution MUST first consider reusing and extending IETF standard protocols before specifying new protocols.
REQ7: Operation and management considerations:
DMM solution:• MUST support mechanisms to test whether the DMM
solution is working properly.• SHOULD expose the operational state of DMM to the
administrators of the DMM entities.• SHOULD support means to correlate the mobility flow
routing policies and the observed forwarding actions.• SHOULD support mechanisms to check the liveness of a
forwarding path.
• MUST provide fault management and monitoring mechanisms to manage situations where an update of the mobility session or the data path fails.
• SHOULD be able to monitor usage of the DMM protocol, and provide means to measure its signaling cost.
• SHOULDo Be able to monitor the number of mobility sessions per
user, as well as their average duration.o provide an indication of DMM performance (Handover
delay, Protocol reactivity).
REQ8: Security considerations
DMM solution:MUST support any security protocols and mechanisms
needed to secure the network and to make continuous security improvements.
MUST NOT introduce new security risks or amplify existing security risks that cannot be mitigated by existing security protocols and mechanisms.
Contact Information
Name E-mail
Abeer Fathy [email protected]
Aya Mahmoud [email protected]
Rawan Ramzy [email protected]
Sara Abdulatif [email protected]
