DMM WG
Internet Engineering Task Force (IETF)                          D. Patki
Internet-Draft
Request for Comments: 8127                                 S. Gundavelli
Intended status:
Category: Standards Track                                          Cisco
Expires: December 2, 2017
ISSN: 2070-1721                                                   J. Lee
                                                    Sangmyung University
                                                                   Q. Fu
                                                            China Mobile
                                                                L. Bertz
                                                                  Sprint
                                                            May 31,
                                                             August 2017

                 LMA Controlled MAG Session

       Mobile Access Gateway Configuration Parameters
            draft-ietf-dmm-lma-controlled-mag-params-05.txt Controlled
                      by the Local Mobility Anchor

Abstract

   This specification defines a new extension, LMA-Controlled-MAG-
   Session-Params
   LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6.  This option
   can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 signaling
   domain for notifying
   the signaling a mobile access gateway to conform to (MAG) on enforcing
   specific values for various configuration parameters such as
   heartbeat parameters and binding refresh parameters.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 December 2, 2017.
   http://www.rfc-editor.org/info/rfc8127.

Copyright Notice

   Copyright (c) 2017 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
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
     2.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Extension  . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Format of the LCMP Sub-Options  . . . . . . . . . . . . . .   4
       3.1.1.  Binding Re-registration Control Sub-Option  . . . . . .   5
       3.1.2.  Heartbeat Control Sub-Option  . . . . . . . . . . . . .   6
   4.  Protocol Configuration Variables  . . . . . . . . . . . . . . .  7   6
     4.1.  Local Mobility Anchor - -- Configuration Variables  . . . . .  7   6
   5.  Protocol Considerations . . . . . . . . . . . . . . . . . . .   8
     5.1.  Local Mobility Anchor Considerations  . . . . . . . . . . .  9   8
     5.2.  Mobile Access Gateway Considerations  . . . . . . . . . . . 10   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . 11  10
   8.  Acknowledgements . .  References  . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . 11
     9.1.  Normative References . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . 11
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 12  11

1.  Introduction

   A large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment, such as
   residential deployment, can have tens of thousands of mobile access
   gateways (MAG) (MAGs) spread across geographical locations.  While it can
   be operationally challenging to manage such a large number of MAGs,
   it can also be very difficult to ensure configuration consistency
   across all the MAGs if they are not centrally managed.  Configuring
   aggressive values of parameters such as re-registration timeout and
   heartbeat interval can potentially create considerable signaling load
   on the local mobility anchor (LMA).  This document provides a new
   option to enable the LMA to control various parameters on the MAG
   such as the re-registration frequency [RFC5213] and heartbeat
   frequency [RFC5847].  With this option, the configuration of these
   tunable parameters done enforced centrally on from the LMA enables Service
   Providers to have better control on the behavior of the MAGs with
   deterministic signaling load on the LMA.

2.  Conventions and Terminology

2.1.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Terminology

   All the terms used in this document are to be interpreted as defined
   in [RFC5213], [RFC5847] [RFC5847], and [RFC7563].

3.  Protocol Extension

   The LMA Controlled LMA-Controlled MAG Parameters (LCMP) (LCMPs) option is a mobility header
   option used to exchange information related to the parameters that a an
   LMA enforces on a MAG.  The  This option can be included only in the Proxy
   Binding Acknowledge (PBA) message only, message, and there MUST NOT be more than a
   single instance of this mobility option in the a given PBA message.  This
   mobility
   option MUST contain one or more LCMP sub-options.  The  Each LCMP sub-
   options
   option carries a specific configuration parameter.  The sub-options
   are defined in Section 3.1.  The LCMP option has an alignment
   requirement of 4n+2 [RFC2460].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |      Type     |   Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LCMP Sub-option(s) Sub-Option(s)                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: LMA Controlled LMA-Controlled MAG Parameters Option

   Type

      MUST be set to the value of IANA-1, 62, indicating that it is a LMA-
      Controlled-MAG-Parameters an
      LMA-Controlled-MAG-Parameters option.

   Length
      8-bit unsigned integer indicating the length in octets of the
      option, excluding the Type and Length fields.

   LCMP Sub-option(s) Sub-Option(s)

      LCMP Sub-options sub-options are described in the below sections. sections below.  The sub-
      options can be present in any order.  Inclusion of any specifc specific
      sub-option is optional, but at least one sub-option MUST be
      present.

3.1.  Format of the LCMP Sub-Options

   The LCMP sub-options are used for carrying information elements
   related to various parameters that need to be configured on the MAG.
   These sub-options can be included in the LCMP option defined in
   Section 3.  The LCMP sub-options have an alignment requirement of 4n.
   The format of this sub-option is as follows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   LCMP Type   | LCMP Length   |       Sub-Option Data         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: LMA Controlled LMA-Controlled MAG Parameters Sub-Option

   Type

      8-bit unsigned integer indicating the type of the LCMP sub-option.
      This specification defines the following types:

      0 - Reserved

      1 - Binding Re-registration Control Sub-Option

      2 - Heartbeat Control Sub-Option

   Length

      8-bit unsigned integer indicating the number of octets needed to
      encode the Option Data, excluding the LCMP Type and LCMP Length
      fields of the sub-option.

3.1.1.  Binding Re-registration Control Sub-Option

   The Binding Re-registration Control Sub-Option is a mobility sub-
   option carried in the LCMP mobility option defined in Section 3.1. 3.
   This sub-option carries re-registration related timer values. values related to re-registration.
   There MUST be no more than a single instance of this sub-option in
   the LCMP option.  The format of this sub-option is defined below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LCMP Type = 1 |  LCMP Length  |  Re-registration-Start-Time   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Initial-Retransmission-Time  | Maximum-Retransmission-Time   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 3: Binding Re-registration Control Sub-Option

   LCMP Type

      1 for the Binding Re-registration Control Sub-Option Sub-Option.

   LCMP Length

      6

   Re-registration-Start-Time

      16-bit unsigned integer indicating the number of time units before
      the expiry of the PMIPv6 binding lifetime when the registration
      refresh process needs to be activated.  One time unit is 4
      seconds.

   Initial-Retransmission-Time

      16-bit unsigned integer indicating minimum delay in seconds before
      the first Proxy Binding Update (PBU) retransmission of the
      exponential back-off backoff process.

   Maximum-Retransmission-Time

      16-bit unsigned integer indicating maximum delay in seconds before
      the last PBU retransmission message of the exponential back-off backoff
      process.

3.1.2.  Heartbeat Control Sub-Option

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LCMP Type = 2 |  LCMP Length  |        HB-Interval            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    HB-Retransmission-Delay    |    HB-Max-Retransmissions     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: Heartbeat Control Sub-Option

   LCMP Type

      2 for the Heartbeat Control Sub-Option Sub-Option.

   LCMP Length

      6

   HB-Interval

      16-bit unsigned integer indicating the heartbeat interval, i.e. i.e.,
      time delay in seconds after a successful heartbeat exchange
      (heartbeat request followed by response) when the next heartbeat
      exchange can be triggered.

   HB-Retransmission-Delay

      16-bit unsigned integer indicating minimum time delay in seconds
      before a heartbeat message is retransmitted.

   HB-Max-Retransmissions

      16-bit unsigned integer indicating maximum number of heartbeat
      retransmissions.

4.  Protocol Configuration Variables

4.1.  Local Mobility Anchor - -- Configuration Variables

   This specification defines the following variables to be configured
   by the system management.  The configured values for these protocol
   variables MUST survive server reboots and service restarts.

   EnableLCMPSubOptReregControl
      This flag indicates the operational state of the Binding Re-
      registration
      Re-registration Control sub-option Sub-Option support.  The default value of
      this flag is (0), indicating that support for the Binding Re-
      registration
      Re-registration Control sub-option Sub-Option is disabled.

   EnableLCMPSubOptHeartbeatControl

      This flag indicates the operational state of the Heartbeat Control
      sub-option
      Sub-Option support.  The default value of this flag is (0),
      indicating that support for the Heartbeat Control sub-option Sub-Option is
      disabled.

   The following variables MAY be defined at various granularities such
   as per binding, per cluster of bindings, per peering MAG, per cluster
   of peering MAGs MAGs, or any other custom grouping.  Regardless of the
   granularity of this configuration, the LMA MUST be able to determine
   the value of these variables for every individual binding.

   LCMPReregistrationStartTime

      This variable is used to set the minimum time interval in number
      of seconds before the expiry of the PMIPv6 binding lifetime when
      the registration refresh process SHOULD be activated.  The default
      value of this variable is 10 units, where each unit is 4 seconds.

   LCMPInitialRetransmissionTime

      This variable is used to set the minimum delay in seconds before
      the first PBU retransmission of the exponential back-off backoff process.
      This variable is the same as INITIAL_BINDACK_TIMEOUT mentioned in
      Section 6.9.4 of [RFC5213].  The default value of this variable is
      1 second.

   LCMPMaximumRetransmissionTime

      This variable is used to set the maximum delay in seconds before
      the last PBU retransmission message of the exponential back-off backoff
      process.  This variable is the same as MAX_BINDACK_TIMEOUT
      mentioned in Section 6.9.4 of [RFC5213].  The default value of
      this variable is 32 seconds.

   LCMPHeartbeatInterval

      This variable is used to set the time delay in seconds after a
      successful heartbeat exchange (heartbeat request followed by
      response) when the next heartbeat exchange can be triggered.  The
      default value of this variable is 60 seconds.  The time delay
      SHOULD NOT be less than 30 seconds or more than 3600 seconds.  The
      value of this variable MAY be derived from the variable
      HEARTBEAT_INTERVAL defined in Section 5 of [RFC5847] if configured
      on the LMA.

   LCMPHeartbeatRetransmissionDelay

      This variable is used to set the minimum time delay in seconds
      before a heartbeat message is retransmitted.  The value of this
      variable SHOULD be less than LCMPHeartbeatInterval.  The default
      value of this variable is 5 seconds.

   LCMPHeartbeatMaxRetransmissions

      This variable is used to set the maximum number of heartbeat
      retransmissions.  The default value of this variable is 3.  The
      value of this variable MAY be derived from the variable
      MISSING_HEARTBEATS_ALLOWED defined in Section 5 of [RFC5847] if
      configured on the LMA.

5.  Protocol Considerations

   The following considerations apply to the LMA and the MAG.

   For supporting this extension, the conceptual Binding Cache Entry
   data structure maintained by the LMA, described in Section 5.1 of
   [RFC5213]
   [RFC5213], and the conceptual Binding Update List entry data
   structure maintained by the MAG, described in Section 6.1 of
   [RFC5213], need to be extended to store the LCMP option related information elements
   related to the LCMP option that are defined below.

   o  LCMPReregistrationStartTime

   o  LCMPInitialRetransmissionTime

   o  LCMPMaximumRetransmissionTime

   o  LCMPHeartbeatInterval

   o  LCMPHeartbeatRetransmissionDelay

   o  LCMPHeartbeatMaxRetransmissions

5.1.  Local Mobility Anchor Considerations

   On receiving a PBU message [RFC5213] from a MAG, the LMA MUST check
   if the variable EnableLCMPSubOptReregControl is configured and set to
   (1).  If yes, and if all of LCMPReregistrationStartTime,
   LCMPInitialRetransmissionTime
   LCMPInitialRetransmissionTime, and LCMPMaximumRetransmissionTime are
   all set to NON_ZERO values, then it MUST include the Binding
   Re-registration Control Sub-Option in the LCMP mobility option option, which
   is in turn included in the PBA message.  If the variable
   EnableLCMPSubOptReregControl is configured and set to (1) (1), and if any
   of LCMPReregistrationStartTime, LCMPInitialRetransmissionTime LCMPInitialRetransmissionTime, and
   LCMPMaximumRetransmissionTime is set to ZERO value, then the LMA MUST
   report a configuration error and reject the binding request by
   sending a PBA message with status code '128-Reason '128 - Reason Unspecified'
   [RFC5213].

   The LMA MUST also check if variable EnableLCMPSubOptHeartbeatControl
   is configured and set to (1).  If yes, and if all of LCMPHeartbeatInterval, LCMPHeartbeatRetransmissionDelay
   LCMPHeartbeatRetransmissionDelay, and LCMPHeartbeatMaxRetransmissions
   are all set to NON_ZERO values, then it MUST include the Heartbeat
   Control Sub-Option in the LCMP mobility option option, which is in turn
   included in the PBA message.  If the variable
   EnableLCMPSubOptHeartbeatControl is set to (1) (1), and if any of
   LCMPHeartbeatInterval, LCMPHeartbeatRetransmissionDelay LCMPHeartbeatRetransmissionDelay, and
   LCMPHeartbeatMaxRetransmissions is set to ZERO value, then the LMA
   MUST report a configuration error and reject the binding request by
   sending a PBA message with status code '128-Reason '128 - Reason Unspecified'
   [RFC5213].

5.2.  Mobile Access Gateway Considerations

   If the PBA message [RFC5213] received from the LMA contains the LCMP
   mobility option and the Binding Re-registration Control Sub-Option,
   then the MAG MUST overwrite the binding re-registration related timer parameters related to binding
   re-registration that are configured locally on the MAG with the
   parameters received in the Binding Re-registration Control Sub-Option. Sub-
   Option.  If any of the parameters in the Binding Re-registration
   Control Sub-Option is are ZERO, then the PBA message MUST be ignored and
   an error message SHOULD be logged.

   Similarly, if the LCMP mobility option contains the Heartbeat Control
   Sub-Option, then the MAG MUST overwrite the heartbeat related heartbeat-related timer
   parameters configured locally on the MAG with the parameters received
   in the Heartbeat Control Sub-Option.  If any of the parameters in the
   Heartbeat Control Sub-Option Sub-Option, except HB-Retransmission-Delay is HB-Retransmission-Delay, are
   ZERO, then the PBA message MUST be ignored and an error message
   SHOULD be logged.

6.  IANA Considerations

   This document requires the following

   IANA actions in has updated the "Mobile IPv6
   Parameters" registry. parameters" registry as described
   here.

   o  Action 1: This specification defines a new mobility header option,
      "LMA Controlled
      "LMA-Controlled MAG Parameters".  This mobility option is
      described in Section 3.  The type value (IANA-1) 62 has been assigned for
      this option
      needs to be assigned from the same numbering space as allocated
      for in the other mobility options, "Mobility Options" registry, as defined in
      [RFC6275].

   o  Action 2: This specification defines a new mobility sub-option
      format, the LCMP Parameters sub-option.  The format of this mobility sub-option sub-
      option is described in Section 3.1.  This sub-option can be
      carried in the LCMP Parameters option.  The type value values for this sub-option needs to be
      are managed by IANA, under the registry
      "LMA Controlled "LMA-Controlled MAG Parameters Sub-Option Sub-
      Option Type Values".  This
      specification reserves Values" registry.  Per this document, IANA has
      reserved the following type values.  Approval of new LCMP Parameters sub-option sub-
      option type values are to be made through IANA Expert Review. Review [RFC8126].

      +---+-----------------------------------------------------+
      | 0 | Reserved                                            |
      +---+-----------------------------------------------------+
      | 1 | Binding Re-registration Control Sub-Option          |
      +---+-----------------------------------------------------+
      | 2 | Heartbeat Control Sub-Option                        |
      +---+-----------------------------------------------------+

7.  Security Considerations

   The LCMP Parameters option defined in this specification allows the
   configuration of re-registration and heartbeat frequencies.  This
   option is defined for carrying it in Proxy Binding Update and Proxy
   Binding Acknowledgement messages.  This option is carried like any
   other mobility header option as specified in [RFC5213] and does not require any
   special security considerations.

8.  Acknowledgements

   The authors would like to thank the DMM working group for all the
   comments and discussions on this document.  The authors would also
   like to thank Suresh Krishnan, Ralph Droms, Mirja Kuehlewind, Alexey
   Melnikov and Ben Campbell for their review feedback.

9.  References

9.1.

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/
              RFC2119, 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <http://www.rfc-editor.org/info/rfc5213>.

   [RFC5847]  Devarapalli, V., Ed., Koodli, R., Ed., Lim, H., Kant, N.,
              Krishnan, S., and J. Laganier, "Heartbeat Mechanism for
              Proxy Mobile IPv6", RFC 5847, DOI 10.17487/RFC5847, June
              2010, <http://www.rfc-editor.org/info/rfc5847>.

   [RFC7563]  Pazhyannur, R., Speicher, S., Gundavelli, S., Korhonen,
              J., and J. Kaippallimalil, "Extensions to the Proxy Mobile
              IPv6 (PMIPv6) Access Network Identifier Option", RFC 7563,
              DOI 10.17487/RFC7563, June 2015,
              <http://www.rfc-editor.org/info/rfc7563>.

9.2.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <http://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <http://www.rfc-editor.org/info/rfc6275>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <http://www.rfc-editor.org/info/rfc8126>.

Acknowledgements

   The authors would like to thank the DMM Working Group for all the
   comments and discussions on this document.  The authors would also
   like to thank Suresh Krishnan, Ralph Droms, Mirja Kuhlewind, Alexey
   Melnikov, and Ben Campbell for their review feedback.

   The work of Jong-Hyouk Lee was supported by 'The Cross-Ministry Giga
   KOREA Project' grant from the Ministry of Science, ICT and Future
   Planning, Korea.

Authors' Addresses
   Dhananjay Patki
   Cisco
   Cessna Business Park SEZ, Kadubeesanahalli
   Bangalore, Karnataka  560087
   India

   Email: dhpatki@cisco.com

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA
   United States of America

   Email: sgundave@cisco.com

   Jong-Hyouk Lee
   Sangmyung University
   31, Sangmyeongdae-gil, Dongnam-gu
   Cheonan 330-720 31066
   Republic of Korea

   Email: jonghyouk@smu.ac.kr

   Qiao Fu
   China Mobile
   Xuanwumenxi Ave. No.32
   Beijing
   P.R.
   China

   Email: fuqiao1@outlook.com

   Lyle T T. Bertz
   Sprint
   Kansas
   USA
   United States of America

   Email: Lyle.T.Bertz@sprint.com