Internet DRAFT - draft-liebsch-dmm-framework-analysis
draft-liebsch-dmm-framework-analysis
DMM Working Group M. Liebsch
Internet-Draft NEC
Intended status: Standards Track P. Seite
Expires: August 18, 2014 Orange-France Telecom
G. Karagiannis
University of Twente
S. Gundavelli
Cisco
February 14, 2014
Distributed Mobility Management - Framework & Analysis
draft-liebsch-dmm-framework-analysis-03.txt
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2014.
Copyright Notice
Liebsch, et al. Expires August 18, 2014 [Page 1]
Internet-Draft DMM Framework & Analysis February 2014
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. Functional Architecture for DMM Support . . . . . . . . . . . 6
4. Different Constellations of Functional Entities . . . . . . . 11
4.1. Condensed Deployment: Mobility Protocol Centric
Solutions . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Cooperative Deployment: Distributed Architecture . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. How the framework can support a gap analysis!
Some examples.. . . . . . . . . . . . . . . . . . . . 17
A.1. Condensed Deployment using Mobile IPv6 . . . . . . . . . . 17
A.2. Condensed Deployment using Proxy Mobile IPv6 . . . . . . . 17
A.3. Cooperative Deployment using LISP . . . . . . . . . . . . 17
A.4. Cooperative Deployment using iBGP . . . . . . . . . . . . 18
Appendix B. Functional Architecture for Multicast DMM Support . . 21
Appendix C. Change Notes . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Liebsch, et al. Expires August 18, 2014 [Page 2]
Internet-Draft DMM Framework & Analysis February 2014
1. Introduction
The concept of Distributed Mobility Management (DMM) is based on the
distribution of mobility anchors towards the access networks to
provide mobile nodes with local anchors and enable optimized routing
of traffic above anchor level to any kind of serving point, e.g.
distributed content caches. The closer mobility anchors are located
to mobile nodes, the more a mobile node's handover may necessitate
the assignment of a new mobility anchor. Continuity of a mobile
node's IP address or IP address prefix enables IP session continuity,
but creates the problem of routing downlink packets to the mobile
node's current mobility anchor. Different solutions and associated
extensions to IP mobility management protocols are being discussed to
maintain a mobile node's IP session after mobility anchor relocation,
including solutions that are based on existing protocols.
This document defines a functional framework for DMM and describes an
initial set of well defined functional entities (FE), which are
required to support IP address continuity in a network with
distributed mobility anchors. Having identified the function of each
FE as well as required interfaces between FEs allows different
constellations of FEs, either by co-locating or distributing them.
Functional frameworks have been successfully used within and outside
of the IETF, such as the ITU-T [ITU-TY2018][ITU-TY2804], to support
the thorough analysis of protocols gaps with existing protocols and
to enable the design of suitable solutions. Due to the complexity of
the DMM problem and solutions space, we consider such framework of
particular importance for performing a Gap Analysis while assigning
the defined FEs to architecture components of existing protocols and
to build suitable solutions for DMM based on extensions to a single
or multiple existing protocols and architecture components.
This version of the draft introduces a basic set of FEs and
interfaces between these FEs to support IP address continuity in DMM,
without being specific to the used mobility management protocol,
which operates below the mobility anchor. The functional framework
as per this draft is protocol agnostic, such that it can apply to (1)
solutions that are solely based on existing IP mobility protocols and
to (2) solutions which get support from non-mobility protocols.
The framework enables the analysis of existing protocols' suitability
to support DMM and allows building optimized solutions for DMM
without being limited to the mobility protocol suites. In
particular, the framework can be used to build solutions on the
following challenges that are currently being discussed in the
context of DMM rechartering:
Liebsch, et al. Expires August 18, 2014 [Page 3]
Internet-Draft DMM Framework & Analysis February 2014
o Support of different deployment models, where the mobility anchors
can be located in the access networks or in the core/backbone
network
o Anchor selection mechanisms
o Control- and Data-plane separation techniques for mobility
components
o Enhancements to mobile node for operating in a DMM-enabled network
o Policy extensions for supporting DMM
o Optimized traffic steering approaches for DMM used to ensure IP
address continuity
o Exposing mobility states (incl. binding state, access network
parameters, etc.) to inter-work, for example, with SDN technology
Some examples how the framework can support the identification of
required protocol extensions to existing mobility management protocol
or alternatively the support from non-mobility protocols to design
suitable DMM solutions on system level are described in Appendix A.
Appendix B defines an additional set of functional entities, which
enables multicast support in DMM and can complement the framework for
DMM unicast support.
Liebsch, et al. Expires August 18, 2014 [Page 4]
Internet-Draft DMM Framework & Analysis February 2014
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Liebsch, et al. Expires August 18, 2014 [Page 5]
Internet-Draft DMM Framework & Analysis February 2014
3. Functional Architecture for DMM Support
The framework introduces four additional functional entities (FE)
which are relevant complement existing mobility- and transport
networks to enable DMM support for unicast traffic and to meet
essential DMM requirements as per [I-D.ietf-dmm-requirements], such
as enabling temporary IP address continuity after a mobile node got
assigned a new mobility anchor. Further FEs may be needed to enable
advanced features, such as simultaneous use of an imported mobile
node HoA or HNP to maintain ongoing data sessions and a new HoA or
HNP, which is allocated by the mobile node's new mobility anchor
after handover. Additional FEs are not considered in this revision
of the draft, but can be introduced easily in future versions of the
draft and considered for the BCP discussion and gap analysis.
The following FEs are currently considered as existing functional
entities to build the mobility- and transport network:
o FE_R: Functional Entity of a standard IP Router / Switch
o FE_MA_C: Functional Entity Mobility Anchor, Control Plane
o FE_MA_U: Functional Entity Mobility Anchor, User Plane
o FE_MU_C: Functional Entity Mobile User Client, Control Plane
o FE_MU_U: Functional Entity Mobile User Client, User Plane
The list comprises a generic router/switch function FE_R that's
supposed to build the transport network. It has no particular
function that's specific to DMM, but performs routing according to a
longest prefix match. Deployment specific aspects, such as the use
of IP/MPLS, are not (yet) considered in this draft.
The entities FE_MA_C and FE_MA_U represent the unmodified functions
of the mobility architecture's mobility anchor. In Mobile IPv6,
these function would be co-located with the Home Agent, in Proxy
Mobile IPv6, these functions would be co-located with the Local
Mobility Anchor (LMA). In a cellular IP (CIP) enabled domain, these
functions would be co-located with the domain's CIP Gateway.
The entities FE_MU_C and FE_MU_U represent the existing user client
functions, that send location updates to the mobility anchor. In
Mobile IPv6, these functions are co-located with the Mobile Node,
whereas in Proxy Mobile IPv6, these functions are co-located with the
Mobile Access Gateway.
So far, this draft defines four DMM-specific FEs, which can be either
Liebsch, et al. Expires August 18, 2014 [Page 6]
Internet-Draft DMM Framework & Analysis February 2014
distributed or co-located with existing FEs of the mobility- or
routing plane. One or more of the following FEs are currently
assumed to add to an existing mobility- and transport network to
enable DMM support for IP address continuity:
o FE_MCTX: Functional Entity Mobility Context Transfer
o FE_I: Functional Entity Ingress to DMM plane
o FE_E: Functional Entity Egress of DMM plane
o FE_IEC: Functional Entity for Ingress/Egress Control
Note: No all FEs or reference points between FEs may be relevant for
a DMM-enabled solution that is based on existing protocols and the
associated architecture. Which functions are relevant to complement
an existing protocol and architecture depends on the identified gaps.
The task of the FE_MCTX is to export relevant binding cache
information, such as the mobile node's HoA or HNP, from the mobile
node's previous mobility anchor (pMA) during mobility anchor
relocation to enable IP address continuity after mobility anchor
relocation. Furthermore, the function allows importing mobility
context on the mobile node's new mobility anchor. Imported HoA/HNP
of a mobile node will be treated as identifier and non-routable IP
address (prefix), as it probably does not match the new mobility
anchor's location in the topology. Furthermore, the FE_MCTX can
provide mobility context to the FE_IEC to allow keeping these
policies updated, which allow forwarding of packets to the MN's
currently used mobility anchor.
The function FE_I enables the ingress level of indirection by means
of deviating from the standard routing path of the mobile node's
downlink packets, which carry the mobile node's HoA/HNP in the
destination IP address field of their IP header. The FE_I can
retrieve information from a control function (FE_IEC) to establish
forwarding of the mobile node's packets to the appropriate DMM egress
function (FE_E). Forwarding can be for example accomplished by an IP
tunnel to the egress function, address translation to a routable IP
address or other means.
The function FE_E receives downlink packets being forwarded by the
DMM ingress function FE_I, e.g. by terminating a forwarding tunnel.
The state on the FE_I can be established through the DMM ingress/
egress control function (FE_IEC) and is used to identify an MN's
received packets and deliver them to the MN's current mobility anchor
(FE_MA). If the FE_E is co-located with the FE_MA, the delivery is a
local operation. If the FE_E is not co-located with the FE_MA, other
Liebsch, et al. Expires August 18, 2014 [Page 7]
Internet-Draft DMM Framework & Analysis February 2014
techniques, such as host-routes or technology such as OpenFlow may be
used to deliver the packets to the mobile node's current mobility
anchor. If not co-located with the FE_MA, the FE_E is supposed to be
located close to the mobile node's current FE_MA.
The function FE_IEC represents a control function, that establishes,
updates and removes policies (per-host or grouped) in the FE_I and
the FE_E to allow forwarding of a mobile node's downlink packets
towards the mobile node's current mobility anchor.
The mobile node's IP address (prefix) is carried in the source
address field of the uplink packet. This source address is thus
topologically incorrect after mobile node's handover. When IP
routers of the mobility domain do not apply filtering according to
the source addresses, uplink packets can be assumed to be routable
and no specific operation is required.
If source address filtering is used, relevant routers need to be
reconfigured to exclude the mobile node's IP address from filtering
rules. If such filtering is performed by a mobility anchor or a
Proxy Mobile IPv6 Mobile Access Gateway (MAG), local mobility
functions on these routers should perform the task to reconfigure the
local filter rules for uplink traffic.
When traffic indirection also applies to the uplink, e.g. to enable
bidirectional tunneling to ensure that downlink and uplink data
packets always traverse the same ingress/egress functions, FE_E and
FE_I functions come into play on the uplink path. Downlink FE_I and
FE_E become respectively FE_E and FE_I on the uplink. The uplink
FE_I forwards a mobile node's packets to the FE_E corresponding to
the downlink FE_I that has sent packets with the mobile node's
address in the destination address field. The FE_I can also retrieve
the information from the FE_IEC.
Figure 1 illustrates how the four DMM-specific FEs complement
existing FEs of the mobility architecture. These DMM-specific FEs
and associated operation on the interfaces between them can be
realized by existing protocols, extensions to them or new protocols.
Figure 1 separates the data plane from the control plane.
Liebsch, et al. Expires August 18, 2014 [Page 8]
Internet-Draft DMM Framework & Analysis February 2014
Control Plane: : Data Plane:
:
: |data packet
: v for mobile node
+----+ R_IC : +----+
|FE_I|<----------+ : |FE_I|
+----+ | : +----+
+--+ | : |
R_II| | | : |
v v v : |
+------+ : |
|FE_IEC| : |
+------+ : |
^ ^ : v
+----+ | | : +----+
|FE_E|<------+ |R_XC : |FE_E|
+----+ R_EC | : +----+
v : |
+-------+ : |
|FE_MCTX| : |
+-------+ : |
^^ ^ ^ : v
+-------+ || | | : +-------+
|FE_MA_C|<------+| +--+ : |FE_MA_U|
+-------+ R_XA | R_XX : +-------+
| : |
| : v
+-------+ | : +-------+
|FE_MU_C|<-------+ : |FE_MU_U|
+-------+ R_XU : +-------+
:
Figure 1: Basic set of functional entities (FE) and interfaces to
enable IP-address continuity in DMM
The reference points between FEs comprise the following features:
o R_XA: Enables the FE_MCTX to retrieve mobility context information
from the FE_MA of the MN's mobility anchor. Such information
includes for example the MN's Home Address (HoA) or Home Network
Prefix (HNP). In the network of the MN's new mobility anchor, the
reference point enables the FE_MCTX to provide the MN's mobility
context to the associated FE_MA, that imports the MN's mobility
context to enable IP address continuity.
o R_XU: Enables the FE_MCTX to retrieve mobility context information
from the mobile user client control function, the FE_MU_C. In host
Liebsch, et al. Expires August 18, 2014 [Page 9]
Internet-Draft DMM Framework & Analysis February 2014
mobility management, this function is located on the Mobile Node,
who could support DMM operation by notifying the FE_MCTX through
this reference point.
o R_XX: Enables the direct transfer of an MN's mobility context
between two functions FE_MCTX, which are typically located in the
network of the MN's previous and new mobility anchor respectively.
o R_IC: Enables the FE_IEC to provide policies to the FE_I, which
are used to forward the MN's downlink packets towards the MN's new
mobility anchor and the associated FE_E. These policies can be
provided to the FE_I in an unsolicited manner or on request by the
FE_I.
o R_EC: Enables the FE_IEC to provide policies to the FE_E, which
are used at the FE_E to identify received packets that belong to a
particular MN and deliver these packets to the MN's new mobility
anchor. Such policies could include, for example, tunnel endpoint
information, flow identification rules or other identification and
addressing rules.
o R_XC: Enables initialization and update of the FE_IEC about the
MN's mobility context as well as about its current location as
represented by the FE_E in the network of the MN's current
mobility anchor.
o R_II: Multiple instances of an FE_IEC can be deployed to build a
DMM architecture, e.g. to distribute load and scale better, or
distribute tasks associated with the FE_IEC to enable cooperative
solutions.
Liebsch, et al. Expires August 18, 2014 [Page 10]
Internet-Draft DMM Framework & Analysis February 2014
4. Different Constellations of Functional Entities
The defined FEs can be grouped or distributed to build a DMM
architecture that considers new architecture components or that is
based on components of existing protocols. As a starting point, this
section depicts and describes two deployment variants, which reflect
the current understanding of the WG how DMM could be accomplished
using existing protocol specifications as base. Variants of these
two deployment models or entirely new models are possible and can be
added to future versions of this document.
Note: This section is incomplete and needs further input on different
deployment models and variants.
4.1. Condensed Deployment: Mobility Protocol Centric Solutions
Mobility protocol centric solutions aim at extensions to available
mobility protocols to enable DMM, without being dependent on any
external, non-mobility component and protocol. IP address continuity
is typically established on the control plane by extensions to the
mobility protocol to convey an MN's mobility context to a new
mobility anchor, and on the data plane by the establishment of a
forwarding tunnel between mobility anchors to deliver downlink
packets from the originally assigned mobility anchor to the MN's
currently used mobility anchor after anchor relocation.
Alternatively, IP address continuity is enabled by using multiple
mobility anchors simultaneously, whereas the mobile node's IP
address(es) remain anchored at the topologically correct anchor
point. These approaches differ in the level of extensions to the
mobility protocols and in the support of certain features on the
mobile node, such as the simultaneous use of multiple mobility
anchors and associated Home Addresses. They have in common the sub-
optimal routing path, as the mobile node's downlink traffic needs to
traverse the location of the IP addresses topologically correct
mobility anchor.
Liebsch, et al. Expires August 18, 2014 [Page 11]
Internet-Draft DMM Framework & Analysis February 2014
|data destined
v to mobile node (MN)
+----+
|FE_R|
+----+
|
|
|
|
|
|
+---v--------------+ +------------------+
| +----+ | | +----+ |
| |FE_I|--==========================-->|FE_E| |
| +----+ | | +----+ |
| +------+ | | | +------+ |
| |FE_IEC| | | | |FE_IEC| |
| +------+ | | | +------+ |
| | | | |
| +-------+ | | | +-------+ |
| |FE_MCTX| | | | |FE_MCTX| |
| +-------+ | | v +-------+ |
|+-------++-------+| |+-------++-------+|
||FE_MA_C||FE_MA_U|| ||FE_MA_U||FE_MA_C||
|+-------++-------+| |+-------++-------+|
+------------------+ +---|--------------+
MN's previous MA | MN's current MA
v
+--+
|MN|
+--+
Figure 2: Condensed Deployment: Mobility Protocol Centric Solutions
4.2. Cooperative Deployment: Distributed Architecture
A distributed architecture considers protocol operation between
distributed FEs, aiming at a DMM solution that's to a large extent
independent of the mobility architecture and protocol. A further
goal is to establish optimal routing paths for the MN's traffic after
the MN's mobility anchor has been relocated and IP address continuity
must be provided.
Liebsch, et al. Expires August 18, 2014 [Page 12]
Internet-Draft DMM Framework & Analysis February 2014
|data destined
v to mobile node (MN)
+----+
|FE_R|
+----+
|
v
+----+
|FE_I|----------------------------------------+
+----+ |
+------+ |
|FE_IEC| |
+------+ |
|
+------------------+ +--------------v----+
| +-------+ | | +-------+ +----+ |
| |FE_MCTX| | | |FE_MCTX| |FE_E| |
| +-------+ | | +-------+ +----+ |
|+-------++-------+| | | |
||FE_MA_C||FE_MA_U|| |+-------+ +-------+|
|+-------++-------+| ||FE_MA_C| |FE_MA_U||
+------------------+ |+-------+ +-------+|
MN's previous +--------------|----+
mobility MN's current v
anchor mobility +--+
anchor |MN|
+--+
Figure 3: Cooperative Deployment: Distributed Architecture
Liebsch, et al. Expires August 18, 2014 [Page 13]
Internet-Draft DMM Framework & Analysis February 2014
5. Security Considerations
Different constellations of Functional Entities may allow re-use of
existing protocols' security mechanisms to protect DMM protocol
operation. In particular in a distributed model, new interfaces must
be protected, e.g. to counteract unauthorized packet redirection to a
different, possibly malicious mobility anchor. Details about
security threats will be studied when the placement of Functional
Entities for a selected set of preferred deployment models becomes
mature.
Liebsch, et al. Expires August 18, 2014 [Page 14]
Internet-Draft DMM Framework & Analysis February 2014
6. IANA Considerations
As this document represents a framework and no protocol
specification, there is no need for IANA actions.
Liebsch, et al. Expires August 18, 2014 [Page 15]
Internet-Draft DMM Framework & Analysis February 2014
7. References
7.1. Normative References
[I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management",
draft-ietf-dmm-requirements-14 (work in progress),
February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
7.2. Informative References
[ITU-TY2018]
"ITU-T Y.2018, Mobility management and control framework
and architecture within the NGN transport stratum".
[ITU-TY2804]
"ITU-T Q.1707/Y.2804, Generic framework of mobility
management for next generation networks".
Liebsch, et al. Expires August 18, 2014 [Page 16]
Internet-Draft DMM Framework & Analysis February 2014
Appendix A. How the framework can support a gap analysis! Some
examples..
A Gap analysis can be performed according to different deployment
models and variants as summarized in Section 4. A suitable set of
DMM FEs can be mapped to the architecture of existing protocols from
within or beyond the IP mobility protocol solution space to analyze
and identify gaps in the chosen protocols to support and optimize DMM
operations. This section provides a few examples about the mapping
of DMM FEs to mobility protocol FEs and non-mobility protocol FEs.
Common goal is to enable DMM support, either in a mobility protocol
centric manner or by means of a distributed architecture, relying on
the support and associated collaboration with non-mobility protocol
functions, such as routing. As examples for the distributed
architecture, the Locator-Identifier Split Protocol (LISP) and the
iBGP have been used to enable traffic indirection in the routing
plane above the topological level of distributed mobility anchors.
A.1. Condensed Deployment using Mobile IPv6
Note: A detailed example needs to be added in a next revision.
Description: Framework mapping to existing Mobile IPv6 architecture.
Technical approach is the establishment of a forwarding tunnel
between previous HA and new HA to enable IP address continuity after
anchor relocation. Approach is the identification of missing
protocol functions in Mobile IPv6 as expected from DMM functional
entities as per this specification to enable full DMM support.
A.2. Condensed Deployment using Proxy Mobile IPv6
Note: A detailed example needs to be added in a next revision.
Description: Framework mapping to existing Proxy Mobile IPv6
architecture. Technical approach is the establishment of a
forwarding tunnel between previous LMA and new LMA to enable IP
address continuity after anchor relocation. Approach is the
identification of missing protocol functions in Proxy Mobile IPv6 as
expected from DMM functional entities as per this specification to
enable full DMM support.
A.3. Cooperative Deployment using LISP
This example utilizes LISP Tunnel Ingress Routers (TIR) to perform
the LISP map and encap procedure and tunnel packets to the mobile
node's current mobility anchor (Figure 4). The mobile node's IP
address is assumed routable above TIR level. TIRs can be for example
deployed close to a mobile operator's IXP or close to operator-owned
Liebsch, et al. Expires August 18, 2014 [Page 17]
Internet-Draft DMM Framework & Analysis February 2014
traffic sources, such as a mobile Content Delivery Network (CDN). A
TIR, which receives data packets destined to the mobile node, can
consult the LISP Mapping Database (DB) to resolve the mobile node's
IP address into its current locator, which is the mobile node's
currently used mobility anchor. The mobility anchor has to terminate
the LISP tunnel at the Tunnel Egress Router (TER) function and
forward the data packets to the mobile node's current location
according to the utilized mobility management protocol. An
identified gap in a setup with LISP is the dynamic update of the
Mapping Database and the update of already established states in TIRs
in case the mobile node's location has changed from one mobility
anchor to another mobility anchor.
|data destined
v to mobile node (MN)
+----+
|TIR/| encapsulated traffic
|FE_I|-=======================================++
+----+ +----------+ ||
\ map |Mapping DB| ||
+---------->| FE_IEC | ||
+------>+----------+ ||
Update Map Entry| ||
+------------|-----+ +--------------||---+
| +-------+ | CTX | +-------+ +---+ |
| |FE_MCTX|---------------->|FE_MCTX|->|TER| |
| +-------+ | | +-------+ +---+ |
|+-------++-------+| | | |
||FE_MA_C||FE_MA_U|| |+-------+ +-------+|
|+-------++-------+| ||FE_MA_C| |FE_MA_U||
+------------------+ |+-------+ +-------+|
MN's previous +--------------|----+
mobility MN's current v
anchor mobility +--+
anchor |MN|
+--+
Figure 4: Example: DMM indirection at LISP TIRs
A.4. Cooperative Deployment using iBGP
This example utilizes the iBGP to establish per-host or group states
in iBGP routers and forward a mobile node's packets hop-by-hop to its
currently used mobility anchor. Figure 5 depicts an iBGP router with
co-located FE_E and FE_I to receive data packets and to forward these
packets to the next hop according to the routing state as per iBGP
Liebsch, et al. Expires August 18, 2014 [Page 18]
Internet-Draft DMM Framework & Analysis February 2014
update. The FE_IEC can be represented by the iBGP component to
enable the setup of distributed routing states in distributed iBGP
routers to direct the mobile node's data packets to its current
mobility anchor. Hence, the FE_IEC is distributed in all iBGP
routers to collaborate in the setup of host routes. The mobility
anchor itself must implement iBGP to contribute to the distribution
and update of host routes, e.g. after the mobile node changed its
mobility anchor while IP address continuity must be supported. Since
iBGP has been designed to propagate routing states to distributed
routers, only minor protocol gaps may be identified in a detailed
analysis. Beyond protocol gaps, further aspects need to be analyzed
in such setup, which include limitations in scalability and route
update latency.
Liebsch, et al. Expires August 18, 2014 [Page 19]
Internet-Draft DMM Framework & Analysis February 2014
iBGP Router (RTR) with DMM FEs:
+--------------------+
|+----+ +----+|
incoming data ------->|FE_E|------->|FE_I|--------->
|+----++------++----+| Forward data
| |FE_IEC| | to Next Hop
| +------+ |
| + |
+----------+---------+
+
V iBGP protocol operation
|
|data destined
v to mobile node (MN)
+----+ +----+
|iBGP|------------------->|iBGP|---------------+
|RTR | |RTR | |
+----+ <++++++iBGP+++++++>+----+ |
^ ^ |
+ +----+ + |
+++iBGP++>|iBGP|<++iBGP++++++++++++++++++++ |
|RTR | + |
+----+ + |
+ |
+ |
+ |
+------------------+ +-------------v-V---+
| +-------+ | CTX | +-------+ +----+ |
| |FE_MCTX|---------------->|FE_MCTX|->|iBGP| |
| +-------+ | | +-------+ |RTR | |
| | | +----+ |
|+-------++-------+| | | |
||FE_MA_C||FE_MA_U|| |+-------+ +-------+|
|+-------++-------+| ||FE_MA_C| |FE_MA_U||
+------------------+ |+-------+ +-------+|
MN's previous +--------------|----+
mobility MN's current v
anchor mobility +--+
anchor |MN|
+--+
Figure 5: Example: DMM indirection at iBGP routers
Liebsch, et al. Expires August 18, 2014 [Page 20]
Internet-Draft DMM Framework & Analysis February 2014
Appendix B. Functional Architecture for Multicast DMM Support
The framework for multicast DMM support is similar to the framework
for unicast DMM support introduced in Section 3 with the main
difference that the additional introduced features are needed to
support the multicast control and user plane. This framework,
similar to the one introduced in Section 3, introduces four DMM-
specific, with the main difference that these FEs are able to support
multicast traffic, instead of unicast traffic. Additional FEs might
be needed but are not considered in this revision of the draft, but
can be introduced easily in future versions of the draft and
considered for the BCP discussion and gap analysis.
The following FEs are currently considered as existing multicast
based Functional entities to build the mobility- and transport
network:
o FE_MR: Functional Entity of a standard Multicast IP Router /
Switch. This FE can be incorporated to support the functionality
of a Rendezvous Point (RP) and of a Designated Router (DR), see
e.g., [RFC4601].
o FE_MLD-P: Functional Entity of a standard Multicast Listener
Discovery Proxy (MLSD-P) used to provide MLD based forwarding,
following the operation defined in e.g., [RFC4605] and [RFC6224].
o FE_MA_C_M: Functional Entity Mobility Anchor, Control Plane, for
the support of multicast traffic
o FE_MA_U_M: Functional Entity Mobility Anchor, User Plane, for the
support of multicast traffic
o FE_MU_C: Functional Entity Mobile User Client, Control Plane, for
the support of unicast and multicast traffic. In case of
multicast traffic the FE_MU_C can operate as multicast sender and
multicast listener.
o FE_MU_U: Functional Entity Mobile User Client, User Plane, for the
support of unicast and multicast traffic. In case of multicast
traffic the FE_MU_U can operate as multicast sender and multicast
listener.
The four DMM-specific FEs used to support multicast traffic are
listed below.
o FE_MCTX_M: Functional Entity Mobility Context Transfer, used for
the support of multicast traffic.
Liebsch, et al. Expires August 18, 2014 [Page 21]
Internet-Draft DMM Framework & Analysis February 2014
o FE_I_M: Functional Entity Ingress to DMM plane, used for the
support of multicast traffic.
o FE_E_M: Functional Entity Egress of DMM plane, used for the
support of multicast traffic.
o FE_IEC_M: Functional Entity for Ingress/Egress Control, used for
the support of multicast traffic.
These FEs support similar features as the ones supported by the
FE_MCTX, FE_I, FE_E, FE_IEC FEs, respectively, described in
Section 3, with the main difference that they are used for the
support of the multicast control and user planes, instead of the
unicast control and user planes.
Figure 6 depicts the basic set of functional entities (FE) and
interfaces to enable IP-address continuity in multicast based DMM.
The four DMM-specific FEs and their associated operation on the
interfaces between them can be realized by existing protocols,
extensions to them or new protocols.
Liebsch, et al. Expires August 18, 2014 [Page 22]
Internet-Draft DMM Framework & Analysis February 2014
Control Plane: : Data Plane:
:
: |data packet
: v for mobile node
+------+ R_IC_M : +------+
|FE_I_M|<----------+ : |FE_I_M|
+------+ | : +------+
+--+ | : |
R_II_M| | | : |
v v v : |
+--------+ : |
|FE_IEC_M| : |
+--------+ : |
^ ^ : v
+------+ | | : +------+
|FE_E_M|<------+ |R_XC_M : |FE_E_M|
+------+ R_EC_M | : +------+
v : |
+-------------+ : |
|FE_MCTX_M | : |
+-------------+ : |
^ ^ ^^ ^ ^ : |
+------+ | | || | | : |
|FE_MR |<----- | || | | : |
+------+ R_XH_M | || | | : |
| || | | : |
+---------+ | || | | : |
|FE_MLD-P |<---- || | | : |
+---------+ R_XD_M || | | : |
|| | | : v
+---------+ || | | : +------------------------+
|FE_MA_C_M|<------+| +--+ : |FE_MA_U_M/FE_MR/FE_MLD-P|
+---------+ R_XA_M | R_XX_M : +------------------------+
| : |
| : v
+-------+ | : +-------+
|FE_MU_C|<-------+ : |FE_MU_U|
+-------+ R_XU_M : +-------+
Figure 6: Basic set of functional entities (FE) and interfaces to
enable IP-address continuity in multicast based DMM
The reference points between FEs are shown in Figure 6. In
particular the features comprised by the reference points R_XA_M,
R_XU_M, R_XX_M, R_IC_M, R_EC_M, R_XC_M, R_II_M, are similar to the
ones supported by the reference points R_XA, R_XU, R_XX, R_IC, R_EC,
R_XC, R_II, respectively, described in Section 3, with the difference
that they are used to support the multicast based control plane,
Liebsch, et al. Expires August 18, 2014 [Page 23]
Internet-Draft DMM Framework & Analysis February 2014
instead of supporting the unicast based control plane.
Two additional reference points are added that are comprising the
following features:
o R_XH_M: Enables the FE_MCTX_M to retrieve MR routing based
information from FE_MR following the operation defined in e.g.,
[RFC4601].
o R_XD_M: Enables the FE_MCTX_M to retrieve Multicast Listener
Discovery forwarding information from FE_MLD-P following the
operation defined in e.g., [RFC4605] and [RFC6224].
Liebsch, et al. Expires August 18, 2014 [Page 24]
Internet-Draft DMM Framework & Analysis February 2014
Appendix C. Change Notes
Changes in version 01:
o Introduced functional split between existing Mobility Anchor
Control- and User-Plane
o Introduced functional split of existing mobile user client
Control- and User-Plane
o Added uplink routing considerations in DMM architecture
o Description of a first DMM Multicast framework in the Appendix
o Added examples to the appendix about how to use the framework for
a gap analysis and for the design of optimized DMM solutions
Liebsch, et al. Expires August 18, 2014 [Page 25]
Internet-Draft DMM Framework & Analysis February 2014
Authors' Addresses
Marco Liebsch
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
D-69115 Heidelberg,
Germany
Phone: +49 6221 4342146
Email: liebsch@neclab.eu
Pierrick Seite
Orange-France Telecom
4, rue du Clos Courtel, BP 91226
Cesson-Sevigne, 35512
France
Phone:
Email: pierrick.seite@orange-ftgroup.com
Georgios Karagiannis
University of Twente
AE Enschede, 7500
Netherlands
Phone: +31 53 4894099
Email: karagian@cs.utwente.nl
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Liebsch, et al. Expires August 18, 2014 [Page 26]
