Distributed Mobility Management - Framework & Analysis
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
DMM Working Group M. Liebsch Internet-Draft NEC Intended status: Standards Track October 15, 2012 Expires: April 18, 2013 Distributed Mobility Management - Framework & Analysis draft-liebsch-dmm-framework-analysis-00.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 April 18, 2013. Copyright Notice Copyright (c) 2012 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 Liebsch Expires April 18, 2013 [Page 1] Internet-Draft DMM Framework & Analysis October 2012 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 . . . . . . . . . . . . . . . . . 4 3. Functional Architecture for DMM Support . . . . . . . . . . . 5 4. Different Constellations of Functional Entities . . . . . . . 9 4.1. Condensed Deployment: Mobility Anchor Centric Solutions . 9 4.2. Cooperative Deployment: Distributed Architecture . . . . . 10 5. Analysis of enabling technology according to different deployment models . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Liebsch Expires April 18, 2013 [Page 2] Internet-Draft DMM Framework & Analysis October 2012 1. Introduction The concept of Distributed Mobility Management (DMM) in based on the distribution of mobility anchors towards the access networks to provide mobile nodes with local anchors and enable optimal 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 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. We consider such framework of particular importance for the discussion of Best Current Practices (BCP) to enable DMM, and for performing a Gap Analysis while assigning the defined FEs to architecture components of existing protocols. The initial version of this 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. Liebsch Expires April 18, 2013 [Page 3] Internet-Draft DMM Framework & Analysis October 2012 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 Expires April 18, 2013 [Page 4] Internet-Draft DMM Framework & Analysis October 2012 3. Functional Architecture for DMM Support The framework introduces five functional entities (FE) which are relevant to DMM 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 first version 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 considered so far to suit basic DMM requirements: o FE_R: Functional Entity of a standard IP Router / Switch o FE_MA: Functional Entity Mobility Anchor 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 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 entity FE_MA represents an unmodified function of the mobility architecture's mobility anchor. In Mobile IPv6, this function would be co-located with the Home Agent, in Proxy Mobile IPv6, this function would be co-located with the Local Mobility Anchor (LMA). In a cellular IP (CIP) enabled domain, this function would be co- located with the domain's CIP Gateway. 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 Liebsch Expires April 18, 2013 [Page 5] Internet-Draft DMM Framework & Analysis October 2012 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 deviations 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. Uplink packets are currently assumed to be routable, as the mobile node's topologically incorrect IP address (prefix) is carried in the source address field. No filtering according to source addresses is currently considered. 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 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. Liebsch Expires April 18, 2013 [Page 6] Internet-Draft DMM Framework & Analysis October 2012 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|<------+ +--+ : |FE_MA| +-----+ R_XA R_XX : +-----+ 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_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 Liebsch Expires April 18, 2013 [Page 7] Internet-Draft DMM Framework & Analysis October 2012 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 Expires April 18, 2013 [Page 8] Internet-Draft DMM Framework & Analysis October 2012 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 Anchor Centric Solutions Mobility Anchor 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. Liebsch Expires April 18, 2013 [Page 9] Internet-Draft DMM Framework & Analysis October 2012 |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| | | |FE_MA| | | +-----+ | | +-----+ | +------------------+ +---|--------------+ MN's previous MA | MN's current MA v +--+ |MN| +--+ Figure 2: Condensed Deployment: Mobility Anchor 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 Expires April 18, 2013 [Page 10] Internet-Draft DMM Framework & Analysis October 2012 |data destined v to mobile node (MN) +----+ |FE_R| +----+ | v +----+ |FE_I|----------------------------------------+ +----+ | +------+ | |FE_IEC| | +------+ | | +------------------+ +--------------v----+ | +-------+ | | +-------+ +----+ | | |FE_MCTX| | | |FE_MCTX| |FE_E| | | +-------+ | | +-------+ +----+ | | +-----+ | | | | | |FE_MA| | | +-----+ | | +-----+ | | |FE_MA| | +------------------+ | +-----+ | MN's previous +--------------|----+ mobility MN's current v anchor mobility +--+ anchor |MN| +--+ Figure 3: Cooperative Deployment: Distributed Architecture Liebsch Expires April 18, 2013 [Page 11] Internet-Draft DMM Framework & Analysis October 2012 5. Analysis of enabling technology according to different deployment models Note: This section is incomplete. A Gap analysis can be performed based on input from Section 4 about different deployment models and variants. A reasonable set of models can be mapped to the architecture of existing protocols from within or beyond the IP mobility protocol solution space. Liebsch Expires April 18, 2013 [Page 12] Internet-Draft DMM Framework & Analysis October 2012 6. 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 Expires April 18, 2013 [Page 13] Internet-Draft DMM Framework & Analysis October 2012 7. IANA Considerations As this document represents a framework and no protocol specification, there is no need for IANA actions. Liebsch Expires April 18, 2013 [Page 14] Internet-Draft DMM Framework & Analysis October 2012 8. Normative References [I-D.ietf-dmm-requirements] Chan, A., "Requirements for Distributed Mobility Management", draft-ietf-dmm-requirements-02 (work in progress), September 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Liebsch Expires April 18, 2013 [Page 15] Internet-Draft DMM Framework & Analysis October 2012 Author's Address Marco Liebsch NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 D-69115 Heidelberg, Germany Phone: +49 6221 4342146 Email: email@example.com Liebsch Expires April 18, 2013 [Page 16]