Area: Internet Area Working Group: Distributed Mobility Management (DMM) Draft: MN Identifier Types for RFC 4283 Mobile Node Identifier Option (draft-ietf-dmm-4283mnids-01 ) RFC: Requirements for Distributed Mobility Management (rfc7333)

1. DISTRIBUTED MOBILITY
MANAGEMENT
DMM
Presented by:
Abeer Fathy
Aya Mahmoud
Rawan Ramzy
Sara Abdulatif

2. Agenda
 The Internet Area.
 Charter of the working group.
 DMM Draft.
 DMM RFC
 Contact Information

3. The InternetArea
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.

4. Charter of The Working Group
Mobility
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

5. 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.

6. 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.

7. 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.

8. 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).

9. 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.

10. 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.

11. 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.

12. Centralized mobility anchoring in a hierarchical network
architecture.

13. Distributed Mobility Management
Mobility 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.

14. 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.

15. Problem Statement
1. Non-Optimal Routes
Forwarding via a centralized anchor often results in non-optimal
routes, thereby increasing the end-to-end delay.

16. 2. Divergence from other evolutionary trends in network
architectures such as distribution of content delivery
Mobile 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.

17. 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.

18. Solution (Req1)
 Servers are distributed so that each user in any location can
be close to one of the servers.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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 .

27. Requirements
REQ5: 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.

28. 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.

29. • 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.
• SHOULD
o 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).

30. 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.

31. Contact Information
Name E-mail
Abeer Fathy abeerswelam93@gmail.com
Aya Mahmoud ayamahmoud1193@gmail.com
Rawan Ramzy RawanRamzy11@gmail.com
Sara Abdulatif Sabdullatife@gmail.com