Skip to main content

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]