Enhanced Mobility Anchoring in Distributed Mobility Management
draft-yhkim-dmm-enhanced-anchoring-04
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Younghan Kim , Seil Jeon | ||
Last updated | 2016-03-21 | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-yhkim-dmm-enhanced-anchoring-04
DMM Y. Kim Internet-Draft Soongsil University Intended status: Standards Track S. Jeon Expires: September 22, 2016 Instituto de Telecomunicacoes March 21, 2016 Enhanced Mobility Anchoring in Distributed Mobility Management draft-yhkim-dmm-enhanced-anchoring-04.txt Abstract This document presents a new perspective for the solution design of enhanced mobility anchoring over DMM deployment models described in [draft-sijeon-dmm-deployment-models]. 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 September 22, 2016. Copyright Notice Copyright (c) 2016 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. Kim & Jeon Expires September 22, 2016 [Page 1] Internet-Draft Enhanced Mobility Anchoring in DMM March 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 3. Enhanced Mobility Anchoring . . . . . . . . . . . . . . . . . 3 3.1. Distributed AM, LM, and FM (with centralized LM) - All- in-One . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Distributed AF-DP, LM and FM with centralized AF-CP (+ LM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Distributed AF-DP and FM-DP with centralized AF-CP, LM, and FM-CP . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This document aims to identify what should be enhanced for mobility anchoring and to provide possible approaches for enhanced mobility anchoring over deployment models presented in [draft-sijeon-dmm- deployment-models]. 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]. This document focuses on enhanced mobility anchoring based on the functional deployment models presented in [draft-sijeon-dmm- deployment-models], which describes deployment models with mobility management functions in [RFC7429]. Anchoring Function (AF) is defined as a combined control-plane and data-plane functions. For the control-plane function, it allocates an IP address, i.e., Home Address (HoA), or prefix, i.e., Home Network Prefix (HNP) a mobile node, topologically anchored by the advertising node. That is, the anchor node is able to advertise a connected route into the routing infrastructure for the allocated IP prefixes. It also takes a data-plane anchor point where packets destined to the IP address or IP prefix allocated by the anchor should pass through. Kim & Jeon Expires September 22, 2016 [Page 2] Internet-Draft Enhanced Mobility Anchoring in DMM March 2016 It can be deployed in a decoupled way, i.e. separated control plane and data plane. In that case, following two terms - AF Control Plane (AF-CP) and AF Data Plane (AF-DP) - are used. AF-CP is responsible of allocating the IP address and advertising a connected route for an associated terminal while AF-DP is responsible of anchoring received data packets destined to the IP address allocated by the anchor. Internetwork Location Management (LM) is a control-plane function, which manages and keeps track of the internetwork location of an MN. The location information may be a binding of the advertised IP address/prefix, e.g., HoA or HNP, to the IP routing address of the MN, or it may be a binding of a node that can forward packets destined to the MN. Note that the LM could belong to the AF-CP, as it is done in several solutions, i.e. Mobile IP (MIP) and Proxy Mobile IPv6 (PMIPv6). However, in this draft, each function is indicated distinctively, as those functions could be deployed in different locations to allow advanced control and smooth evolution for DMM. Forwarding Management (FM) function performs packet interception and forwarding to/from the IP address/prefix assigned to the MN, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to their destination. Following the FM definition in [RFC7429], it may be split into the control plane (FM-CP) and data plane (FM-DP). 3. Enhanced Mobility Anchoring We present enhanced mobility anchoring operations based on the three deployment models presented in [draft-sijeon-dmm-deployment-models]. For the details of the deployment models, check following draft [draft-sijeon-dmm-deployment-models]. 3.1. Distributed AM, LM, and FM (with centralized LM) - All-in-One Kim & Jeon Expires September 22, 2016 [Page 3] Internet-Draft Enhanced Mobility Anchoring in DMM March 2016 +--------------------------+ | (LM) | +--------------------------+ ^ ^ | | | | v v +-------------+ +-------------+ |AF + LM + FM | (<---->) |AF + LM + FM | +-------------+ +-------------+ +------+ | MN | +------+ Figure 1. Distributed AM, LM, and FM functions (with centralized LM) Fig. 1 shows AF is distributed with LM and FM at edge mobility routers. The AF allocates an IP address or IP prefix and advertises a connected route of the mobile terminal configured with the allocated IP address or IP prefix, when the terminal is attached at a mobility router. It takes a role of intercepting packets destined to the allocated IP address/prefix of the mobile terminal. 3.2. Distributed AF-DP, LM and FM with centralized AF-CP (+ LM) +--------------------------+ | AF-CP (+ LM) | +--------------------------+ ^ ^ | | | | v v +-----------+ +-----------+ | AF-DP + | | AF-DP + | | LM + FM | (<----->) | LM + FM | +-----------+ +-----------+ +------+ | MN | +------+ Figure 2. Distributed AF-DP, LM and FM functions with centralized AF-CP (+ LM) Kim & Jeon Expires September 22, 2016 [Page 4] Internet-Draft Enhanced Mobility Anchoring in DMM March 2016 Origin: (a) "The domain name that appears at the top of a zone (just below the cut that separates the zone from its parent). The name of the zone is the same as the name of the domain at the zone's origin." (Quoted from [RFC2181], Section 6.) These days, this sense of "origin" and "apex" (defined below) are often used interchangeably. (b) The domain name within which a given relative domain name appears in zone files. Generally seen in the context of "$ORIGIN", which is a control entry defined in [RFC1035], Section 5.1, as part of the master file format. For example, if the $ORIGIN is set to "example.org.", then a master file line for "www" is in fact an entry for "www.example.org.". Apex: The point in the tree at an owner of an SOA and corresponding authoritative NS RRset. This is also called the "zone apex". [RFC4033] defines it as "the name at the child's side of a zone cut". The "apex" can usefully be thought of as a data-theoretic description of a tree structure, and "origin" is the name of the same concept when it is implemented in zone files. The distinction is not always maintained in use, however, and one can find uses that conflict subtly with this definition. [RFC1034] uses the term "top node of the zone" as a synonym of "apex", but that term is not widely used. These days, the first sense of "origin" (above) and "apex" are often used interchangeably. Zone cut: The delimitation point between two zones where the origin of one of the zones is the child of the other zone. "Zones are delimited by 'zone cuts'. Each zone cut separates a 'child' zone (below the cut) from a 'parent' zone (above the cut). (Quoted from [RFC2181], Section 6; note that this is barely an ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as 'zone cut'." Delegation: The process by which a separate zone is created in the name space beneath the apex of a given domain. Delegation happens when an NS RRset is added in the parent zone for the child origin. Delegation inherently happens at a zone cut. The term is also commonly a noun: the new zone that is created by the act of delegating. Glue records: "[Resource records] which are not part of the authoritative data [of the zone], and are address resource records for the [name servers in subzones]. These RRs are only necessary if the name server's name is 'below' the cut, and are only used as Hoffman, et al. Expires May 31, 2018 [Page 20] Internet-Draft DNS Terminology November 2017 part of a referral response." Without glue "we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn." (Definition from [RFC1034], Section 4.2.1) A later definition is that glue "includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub-zones (NS records), address records that accompany those NS records (A, AAAA, etc), and any other stray data that might appear" ([RFC2181], Section 5.4.1). Although glue is sometimes used today with this wider definition in mind, the context surrounding the [RFC2181] definition suggests it is intended to apply to the use of glue within the document itself and not necessarily beyond. In-bailiwick: An adjective to describe a name server whose name is either subordinate to or (rarely) the same as the zone origin. In-bailiwick name servers may have glue records in their parent zone (using the first of the definitions of "glue records" in the definition above). "In-bailiwick" names are divided into two type of name server names: "in-domain" names and "sibling domain" names: * In-domain -- an adjective to describe a name server whose name is either subordinate to or (rarely) the same as the owner name of the NS resource records. An in-domain name server name MUST have glue records or name resolution fails. For example, a delegation for "child.example.com" may have "in-domain" name server name "ns.child.example.com". * Sibling domain: -- a name server's name that is either subordinate to or (rarely) the same as the zone origin and not subordinate to or the same as the owner name of the NS resource records. Glue records for sibling domains are allowed, but not necessary. For example, a delegation for "child.example.com" in "example.com" zone may have "sibling" name server name "ns.another.example.com". Out-of-bailiwick: The antonym of in-bailiwick. An adjective to describe a name server whose name is not subordinate to or the same as the zone origin. Glue records for out-of-bailiwick name servers are useless. Authoritative data: "All of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone." (Quoted from [RFC1034], Section 4.2.1) It is noted that this definition might Hoffman, et al. Expires May 31, 2018 [Page 21] Internet-Draft DNS Terminology November 2017 inadvertently also include any NS records that appear in the zone, even those that might not truly be authoritative because there are identical NS RRs below the zone cut. This reveals the ambiguity in the notion of authoritative data, because the parent-side NS records authoritatively indicate the delegation, even though they are not themselves authoritative data. Root zone: The zone of a DNS-based tree whose apex is the zero- length label. Also sometimes called "the DNS root". Empty non-terminals (ENT): &Kim & Jeon Expires September 22, 2016 [Page 5] Internet-Draft Enhanced Mobility Anchoring in DMM March 2016 5. Security Considerations T.B.D. 6. Acknowledgements 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. 7.2. Informative References [I-D.sijeon-dmm-deployment-models] Jeon, S. and Y. Kim, "Deployment Models for Distributed Mobility Management", draft-sijeon-dmm-deployment- models-01 (work in progress), October 2015. [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and CJ. Bernardos, "Distributed Mobility Management: Current Practices and Gap Analysis", RFC 7429, DOI 10.17487/RFC7429, January 2015, <http://www.rfc-editor.org/info/rfc7429>. Authors' Addresses Younghan Kim Soongsil University 369, Sangdo-ro, Dongjak-gu Seoul 156-743 Korea Email: younghak@ssu.ac.kr Seil Jeon Instituto de Telecomunicacoes Campus Universitario de Santiago Aveiro 3810-193 Portugal Email: seiljeon@av.it.pt Kim & Jeon Expires September 22, 2016 [Page 6]