RFC 8127 PROPOSED STANDARD MOBILITY · IPV6 · CONFIGURATION
Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor
How a Proxy Mobile IPv6 anchor can tell its gateways which re-registration and heartbeat timers to use.
RFC EDITOR
Patki, D., Gundavelli, S., Lee, J., Fu, Q., and L. Bertz, "Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor", RFC 8127, DOI 10.17487/RFC8127, August 2017, <https://www.rfc-editor.org/info/rfc8127>.
BIBTEX
@misc{rfc8127,
series = {Request for Comments},
number = 8127,
howpublished = {RFC 8127},
publisher = {RFC Editor},
doi = {10.17487/RFC8127},
url = {https://www.rfc-editor.org/info/rfc8127},
author = {D. Patki and S. Gundavelli and J. Lee and Q. Fu and L. Bertz},
title = {{Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor}},
pagetotal = 14,
year = 2017,
month = aug,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Patki
Request for Comments: 8127 S. Gundavelli
Category: Standards Track Cisco
ISSN: 2070-1721 J. Lee
Sangmyung University
Q. Fu
China Mobile
L. Bertz
Sprint
August 2017
Mobile Access Gateway Configuration Parameters Controlled
by the Local Mobility Anchor
Abstract
This specification defines a new extension,
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
domain for signaling a mobile access gateway (MAG) on enforcing
specific values for various configuration parameters such as
heartbeat and binding refresh parameters.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for 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 this document, any errata,
and how to provide feedback on it may be obtained at
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. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 4
3.1. Format of the LCMP Sub-Options . . . . . . . . . . . . . 5
3.1.1. Binding Re-registration Control Sub-Option . . . . . 6
3.1.2. Heartbeat Control Sub-Option . . . . . . . . . . . . 7
4. Protocol Configuration Variables . . . . . . . . . . . . . . 8
4.1. Local Mobility Anchor -- Configuration Variables . . . . 8
5. Protocol Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Local Mobility Anchor Considerations . . . . . . . . . . 10
5.2. Mobile Access Gateway Considerations . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
A large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment, such as
residential deployment, can have tens of thousands of mobile access
gateways (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 enforced centrally 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
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], and [RFC7563].
3. Protocol Extension
The LMA-Controlled MAG Parameters (LCMPs) option is a mobility header
option used to exchange information related to the parameters that an
LMA enforces on a MAG. This option can be included only in the Proxy
Binding Acknowledge (PBA) message, and there MUST NOT be more than a
single instance of this mobility option in a given PBA message. This
option MUST contain one or more LCMP sub-options. Each LCMP sub-
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 [RFC8200].
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LMA-Controlled MAG Parameters Option
Type
MUST be set to the value of 62, indicating that it is 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)
LCMP sub-options are described in the sections below. The sub-
options can be present in any order. Inclusion of any 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 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.
This sub-option carries timer 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.
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 backoff process.
Maximum-Retransmission-Time
16-bit unsigned integer indicating maximum delay in seconds before
the last PBU retransmission message of the exponential 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.
LCMP Length
6
HB-Interval
16-bit unsigned integer indicating the heartbeat interval, 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 Control Sub-Option support. The default value of
this flag is (0), indicating that support for the Binding
Re-registration Control Sub-Option is disabled.
EnableLCMPSubOptHeartbeatControl
This flag indicates the operational state of the Heartbeat Control
Sub-Option support. The default value of this flag is (0),
indicating that support for the Heartbeat Control 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, 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 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 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], 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 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 LCMPReregistrationStartTime,
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, which
is in turn included in the PBA message. If the variable
EnableLCMPSubOptReregControl is configured and set to (1), and if any
of LCMPReregistrationStartTime, 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 Unspecified'
[RFC5213].
The LMA MUST also check if variable EnableLCMPSubOptHeartbeatControl
is configured and set to (1). If yes, and if LCMPHeartbeatInterval,
LCMPHeartbeatRetransmissionDelay, and LCMPHeartbeatMaxRetransmissions
are all set to NON_ZERO values, then it MUST include the Heartbeat
Control Sub-Option in the LCMP mobility option, which is in turn
included in the PBA message. If the variable
EnableLCMPSubOptHeartbeatControl is set to (1), and if any of
LCMPHeartbeatInterval, 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 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 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. If any of the parameters in the Binding Re-registration
Control Sub-Option 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 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, except HB-Retransmission-Delay, are
ZERO, then the PBA message MUST be ignored and an error message
SHOULD be logged.
6. IANA Considerations
IANA has updated the "Mobile IPv6 parameters" registry as described
here.
o Action 1: This specification defines a new mobility header option,
"LMA-Controlled MAG Parameters". This mobility option is
described in Section 3. The type value 62 has been assigned for
this option in the "Mobility Options" registry, as defined in
[RFC6275].
o Action 2: This specification defines a new mobility sub-option
format, the LCMP sub-option. The format of this mobility sub-
option is described in Section 3.1. This sub-option can be
carried in the LCMP option. The type values for this sub-option
are managed by IANA, under the "LMA-Controlled MAG Parameters Sub-
Option Type Values" registry. Per this document, IANA has
reserved the following type values. Approval of new LCMP sub-
option type values are to be made through Expert Review [RFC8126].
+---+-----------------------------------------------------+
| 0 | Reserved |
+---+-----------------------------------------------------+
| 1 | Binding Re-registration Control Sub-Option |
+---+-----------------------------------------------------+
| 2 | Heartbeat Control Sub-Option |
+---+-----------------------------------------------------+
7. Security Considerations
The LCMP 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 and does not require any
special security considerations.
8. References
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, March 1997,
<https://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,
<https://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, <https://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,
<https://www.rfc-editor.org/info/rfc7563>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
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
United States of America
Email: sgundave@cisco.com
Jong-Hyouk Lee
Sangmyung University
31, Sangmyeongdae-gil, Dongnam-gu
Cheonan 31066
Republic of Korea
Email: jonghyouk@smu.ac.kr
Qiao Fu
China Mobile
Xuanwumenxi Ave. No.32
Beijing
China
Email: fuqiao1@outlook.com
Lyle T. Bertz
Sprint
Kansas
United States of America
Email: Lyle.T.Bertz@sprint.com
AI ELI5
On this page
PROBLEMA large Proxy Mobile IPv6 network can have tens of thousands of gateways, and keeping their timer settings consistent is hard. Aggressive values for re-registration and heartbeats can create heavy signaling load on the anchor.
MECHANISMThe local mobility anchor (LMA) adds a new option, LMA-Controlled MAG Parameters, to its Proxy Binding Acknowledge message. The option carries sub-options that make the mobile access gateway (MAG) overwrite its local re-registration and heartbeat timers.
WHY IT MATTERSOperators can set these timers centrally on the LMA and get a predictable signaling load. This is a Proposed Standard and it has not been obsoleted or updated.
§1Why the Anchor Should Set the Timers
In Proxy Mobile IPv6 (PMIPv6, RFC 5213), mobile access gateways (MAGs) register devices with a local mobility anchor (LMA). A large residential deployment can have tens of thousands of MAGs spread across many locations. Managing them one by one is operationally hard, and it is just as hard to keep their configuration consistent.
Timer values matter because aggressive settings for re-registration and heartbeat intervals can put considerable signaling load on the LMA. This document adds an option that lets the LMA control those parameters on the MAG. The RFC points to the re-registration frequency from RFC 5213 and the heartbeat frequency from RFC 5847. Service providers get central control and a deterministic signaling load on the LMA.
If every branch manager picked their own check-in time, the head office phone would ring all day. Letting head office pick the times keeps things calm and predictable.
§3The LCMP Option and Its Sub-Options
The LMA-Controlled MAG Parameters (LCMP) option is a mobility header option. It can be included only in the Proxy Binding Acknowledge (PBA) message, and a PBA MUST NOT contain more than one instance. Its Type is 62. Length is an 8-bit count of the option's octets, excluding the Type and Length fields. The option has an alignment requirement of 4n+2.
The option MUST contain at least one LCMP sub-option, in any order. Each sub-option has an 8-bit LCMP Type, an 8-bit LCMP Length and the sub-option data, and sub-options have an alignment requirement of 4n. The types defined are 0 (Reserved), 1 (Binding Re-registration Control) and 2 (Heartbeat Control).
The Binding Re-registration Control sub-option has an LCMP Length of 6 and may appear at most once in the LCMP option. It carries three 16-bit fields:
Re-registration-Start-Time: how many time units before the PMIPv6 binding lifetime expires the refresh process should start. One time unit is 4 seconds.Initial-Retransmission-Time: the minimum delay in seconds before the first Proxy Binding Update (PBU) retransmission of the exponential backoff.Maximum-Retransmission-Time: the maximum delay in seconds before the last PBU retransmission of the exponential backoff.
The Heartbeat Control sub-option also has an LCMP Length of 6 and carries three 16-bit fields:
HB-Interval: seconds to wait after a successful heartbeat exchange (request followed by response) before the next one can be triggered.HB-Retransmission-Delay: the minimum delay in seconds before a heartbeat message is retransmitted.HB-Max-Retransmissions: the maximum number of heartbeat retransmissions.
The option is a small envelope with notes inside. One note says when to renew your registration and how to retry. The other says how often to say hello and how many times to try again.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
LCMP-TYPE | LCMP Type | 1 byte | 1 | Set to 1 for this sub-option. |
LCMP-LENGTH | LCMP Length | 1 byte | 6 | Length of the data after these two fields. |
START-TIME | Re-registration-Start-Time | 2 bytes | Time units (4 seconds each) before binding expiry to start refreshing. | |
INITIAL-RT | Initial-Retransmission-Time | 2 bytes | Minimum delay in seconds before the first PBU retransmission. | |
MAX-RT | Maximum-Retransmission-Time | 2 bytes | Maximum delay in seconds before the last PBU retransmission. |
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
LCMP-TYPE | LCMP Type | 1 byte | 2 | Set to 2 for this sub-option. |
LCMP-LENGTH | LCMP Length | 1 byte | 6 | Length of the data after these two fields. |
HB-INTERVAL | HB-Interval | 2 bytes | Seconds after a successful heartbeat exchange before the next one. | |
HB-RETX-DELAY | HB-Retransmission-Delay | 2 bytes | Minimum seconds before a heartbeat is retransmitted. | |
HB-MAX-RETX | HB-Max-Retransmissions | 2 bytes | Maximum number of heartbeat retransmissions. |
§4Configuration Variables on the LMA
The LMA is configured through system management, and the configured values MUST survive server reboots and service restarts. Two flags switch the features on: EnableLCMPSubOptReregControl and EnableLCMPSubOptHeartbeatControl. Both default to 0, which means the feature is disabled.
The value variables MAY be defined per binding, per cluster of bindings, per peering MAG, per cluster of peering MAGs or any other custom grouping. Whatever the granularity, the LMA MUST be able to determine the value for every individual binding. The defaults are:
LCMPReregistrationStartTime: 10 units of 4 seconds each.LCMPInitialRetransmissionTime: 1 second, the same as INITIAL_BINDACK_TIMEOUT in RFC 5213.LCMPMaximumRetransmissionTime: 32 seconds, the same as MAX_BINDACK_TIMEOUT in RFC 5213.LCMPHeartbeatInterval: 60 seconds. It SHOULD NOT be less than 30 or more than 3600 seconds, and MAY be derived from HEARTBEAT_INTERVAL in RFC 5847.LCMPHeartbeatRetransmissionDelay: 5 seconds, and it SHOULD be less than the heartbeat interval.LCMPHeartbeatMaxRetransmissions: 3. It MAY be derived from MISSING_HEARTBEATS_ALLOWED in RFC 5847.
Head office keeps a settings sheet with sensible defaults, and a switch for each rule that starts in the off position. It can even keep different sheets for different groups of branches.
§5How the LMA and MAG Behave
Both sides extend the conceptual data structures from RFC 5213, the Binding Cache Entry on the LMA and the Binding Update List entry on the MAG, to store the six LCMP values.
When the LMA receives a PBU from a MAG, it checks each enable flag. If a flag is 1 and all three matching variables are non-zero, the LMA MUST include the corresponding sub-option in the LCMP option of the PBA. If a flag is 1 but any matching variable is zero, the LMA MUST report a configuration error and reject the binding request with a PBA carrying status code 128, Reason Unspecified.
On the MAG side, a PBA that carries the Binding Re-registration Control sub-option makes the MAG MUST overwrite its locally configured re-registration timers with the received values. The Heartbeat Control sub-option works the same way for heartbeat timers. If any received parameter is zero, the MAG MUST ignore the PBA and SHOULD log an error. For the heartbeat sub-option, HB-Retransmission-Delay is the one field allowed to be zero.
When a branch checks in, head office either hands back the schedule or, if its own sheet has a zero where a number belongs, says no and complains. The branch always follows the schedule it is given and ignores one that has a zero in it.
MAGLMA
- PBUProxy Binding Update asks to register or refresh a binding.
- PBA with LCMP optionCarries the sub-options for the timers the LMA enforces.
§6IANA Registrations
IANA has assigned type value 62 to the new "LMA-Controlled MAG Parameters" option in the "Mobility Options" registry, which is defined by RFC 6275. It has also created a registry named "LMA-Controlled MAG Parameters Sub-Option Type Values" and reserved the three values 0, 1 and 2. New sub-option type values are approved through Expert Review, as described in RFC 8126.
A public list of numbered labels records that 62 means this option. A second list keeps track of the numbered notes that can go inside it.
§7Security Considerations
The RFC notes that the LCMP option allows the configuration of re-registration and heartbeat frequencies. It is carried in Proxy Binding Update and Proxy Binding Acknowledgement messages like any other mobility header option, and the RFC concludes that it does not require any special security considerations.
The note travels in the same sealed mailbag as every other message, so the RFC adds no new locks.
§7References
[RFC5213]RFC 5213Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.August 2008[RFC5847]RFC 5847Devarapalli, V., Ed., Koodli, R., Ed., Lim, H., Kant, N., Krishnan, S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile IPv6", RFC 5847, June 2010.June 2010[RFC7563]RFC 7563Pazhyannur, R., Speicher, S., Gundavelli, S., Korhonen, J., and J. Kaippallimalil, "Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option", RFC 7563, June 2015.June 2015[RFC6275]RFC 6275Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.July 2011[RFC8126]RFC 8126Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, June 2017.June 2017