DMM WGInternet Engineering Task Force (IETF) D. PatkiInternet-DraftRequest for Comments: 8127 S. GundavelliIntended status:Category: Standards Track CiscoExpires: December 2, 2017ISSN: 2070-1721 J. Lee Sangmyung University Q. Fu China Mobile L. Bertz SprintMay 31,August 2017LMA Controlled MAG SessionMobile Access Gateway Configuration Parametersdraft-ietf-dmm-lma-controlled-mag-params-05.txtControlled by the Local Mobility Anchor Abstract This specification defines a new extension,LMA-Controlled-MAG- Session-ParamsLMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6signalingdomain fornotifying thesignaling a mobile access gatewayto conform to(MAG) on enforcing specific values for various configuration parameters such as heartbeatparametersand binding refresh parameters. Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan 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 listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication 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 ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 . . . . . . . . . . . . . . . . . . . . . . . .. 32 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 . . . . . . . . . . . . . .. 76 4.1. Local Mobility Anchor--- Configuration Variables . . . .. 76 5. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. Local Mobility Anchor Considerations . . . . . . . . . .. 98 5.2. Mobile Access Gateway Considerations . . . . . . . . . .. 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .109 7. Security Considerations . . . . . . . . . . . . . . . . . . .1110 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 . . . . . . . . . . . . . . . . . . . . . . .. 1211 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 parametersdoneenforced centrallyonfrom 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 TheLMA ControlledLMA-Controlled MAG Parameters(LCMP)(LCMPs) option is a mobility header option used to exchange information related to the parameters thataan LMA enforces on a MAG.TheThis 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 inthea given PBA message. Thismobilityoption MUST contain one or more LCMP sub-options.TheEach LCMP sub-optionsoption 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCMPSub-option(s)Sub-Option(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1:LMA ControlledLMA-Controlled MAG Parameters Option Type MUST be set to the value ofIANA-1,62, indicating that it isa LMA- Controlled-MAG-Parametersan LMA-Controlled-MAG-Parameters option. Length 8-bit unsigned integer indicating the length in octets of the option, excluding the Type and Length fields. LCMPSub-option(s)Sub-Option(s) LCMPSub-optionssub-options are described in thebelow sections.sections below. The sub- options can be present in any order. Inclusion of anyspecifcspecific 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 ControlledLMA-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 Section3.1.3. This sub-option carriesre-registration relatedtimervalues.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 ControlSub-OptionSub-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 exponentialback-offbackoff process. Maximum-Retransmission-Time 16-bit unsigned integer indicating maximum delay in seconds before the last PBU retransmission message of the exponentialback-offbackoff 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 ControlSub-OptionSub-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 BindingRe- registrationRe-registration Controlsub-optionSub-Option support. The default value of this flag is (0), indicating that support for the BindingRe- registrationRe-registration Controlsub-optionSub-Option is disabled. EnableLCMPSubOptHeartbeatControl This flag indicates the operational state of the Heartbeat Controlsub-optionSub-Option support. The default value of this flag is (0), indicating that support for the Heartbeat Controlsub-optionSub-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 peeringMAGsMAGs, 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 exponentialback-offbackoff 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 exponentialback-offbackoff 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 theLCMP option relatedinformation 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 ifall ofLCMPReregistrationStartTime,LCMPInitialRetransmissionTimeLCMPInitialRetransmissionTime, and LCMPMaximumRetransmissionTime are all set to NON_ZERO values, then it MUST include the Binding Re-registration Control Sub-Option in the LCMP mobilityoptionoption, 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,LCMPInitialRetransmissionTimeLCMPInitialRetransmissionTime, 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 ifall ofLCMPHeartbeatInterval,LCMPHeartbeatRetransmissionDelayLCMPHeartbeatRetransmissionDelay, and LCMPHeartbeatMaxRetransmissions are all set to NON_ZERO values, then it MUST include the Heartbeat Control Sub-Option in the LCMP mobilityoptionoption, which is in turn included in the PBA message. If the variable EnableLCMPSubOptHeartbeatControl is set to(1)(1), and if any of LCMPHeartbeatInterval,LCMPHeartbeatRetransmissionDelayLCMPHeartbeatRetransmissionDelay, 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 thebinding re-registration relatedtimer parameters related to binding re-registration that are configured locally on the MAG with the parameters received in the Binding Re-registration ControlSub-Option.Sub- Option. If any of the parameters in the Binding Re-registration Control Sub-Optionisare 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 theheartbeat relatedheartbeat-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 ControlSub-OptionSub-Option, exceptHB-Retransmission-Delay isHB-Retransmission-Delay, are ZERO, then the PBA message MUST be ignored and an error message SHOULD be logged. 6. IANA ConsiderationsThis document requires the followingIANAactions inhas updated the "Mobile IPv6Parameters" 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 optionneeds to be assigned from the same numbering space as allocated forin theother mobility options,"Mobility Options" registry, as defined in [RFC6275]. o Action 2: This specification defines a new mobility sub-option format, the LCMPParameterssub-option. The format of this mobilitysub-optionsub- option is described in Section 3.1. This sub-option can be carried in the LCMPParametersoption. The typevaluevalues for this sub-optionneeds to beare managed by IANA, under theregistry "LMA Controlled"LMA-Controlled MAG ParametersSub-OptionSub- Option TypeValues". This specification reservesValues" registry. Per this document, IANA has reserved the following type values. Approval of new LCMPParameters sub-optionsub- option type values are to be made throughIANAExpertReview.Review [RFC8126]. +---+-----------------------------------------------------+ | 0 | Reserved | +---+-----------------------------------------------------+ | 1 | Binding Re-registration Control Sub-Option | +---+-----------------------------------------------------+ | 2 | Heartbeat Control Sub-Option | +---+-----------------------------------------------------+ 7. Security Considerations The LCMPParametersoption 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 specifiedin [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.References9.1.8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI10.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 95134USAUnited States of America Email: sgundave@cisco.com Jong-Hyouk Lee Sangmyung University 31, Sangmyeongdae-gil, Dongnam-gu Cheonan330-72031066 Republic of Korea Email: jonghyouk@smu.ac.kr Qiao Fu China Mobile Xuanwumenxi Ave. No.32 BeijingP.R.China Email: fuqiao1@outlook.com LyleTT. Bertz Sprint KansasUSAUnited States of America Email: Lyle.T.Bertz@sprint.com