Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6
Extracted elements (26)
A load-balancer in front of an LMA cluster becomes a bottleneck if all PMIPv6 traffic must traverse it indefinitely. Runtime LMA assignment lets the MAG learn the unicast address of the actual serving LMA blade after the initial PBU/PBA exchange, bypassing the load-balancer for all subsequent traffic and enabling stateless load-balancers.
DNS- and AAA-based LMA selection cannot reflect runtime load because DNS caching and unpredictable zone-update delays prevent MAGs from receiving current LMA load status, and AAA typically returns an FQDN representing a group of LMAs rather than a specific IP address. Runtime assignment via PMIPv6 signaling fills this gap.
For multi-homed mobile nodes, runtime LMA assignment should be applied only on the very first initial attach; the assigned r2LMA address is then stored in the policy profile so that all subsequent mobility sessions for the same MN are anchored to the same r2LMA without contacting the rfLMA again.
IPv6 anycast addressing is used for initial MAG-to-rfLMA contact so that a blade-architecture LMA can present a single address to the MAG; after the PBU/PBA exchange the MAG learns the unicast address of the assigned r2LMA blade and all subsequent communication uses that unicast address.
In the separate rfLMA/r2LMA model the r2LMA can be any RFC 5213- or RFC 5844-compliant LMA with no knowledge of this specification when IPv6 transport is used; for IPv4 transport the r2LMA MUST also implement the Alternate IPv4 Care-of Address option defined in Section 4.4.
After a successful runtime LMA assignment, the MAG MUST update its BULE to contain the r2LMA address from the Redirect option, MUST send all user traffic to the r2LMA address, and MUST send all subsequent binding refresh PBUs (lifetime extension, handoff, etc.) to the r2LMA address.
Dynamic negotiation of Security Associations between MAGs and LMAs using IKEv2 SHOULD be supported, though it is out of scope of this specification.
Each LMA in a runtime assignment domain MUST be reachable at a unicast IP address, and the rfLMA and r2LMA MUST have a prior agreement, adequate means to secure their inter-LMA communication, and an established trust relationship.
If a MAG receives a PBA containing the Redirect mobility option without having first included the Redirect-Capability option in the corresponding PBU, the MAG MUST ignore the Redirect option and process the PBA as described in RFC 5213.
If the rfLMA cannot assign the MAG to any r2LMA and is also unwilling or unable to serve as a normal RFC 5213 LMA, it MUST reject the PBU by returning a PBA with Status Value 130 (Insufficient resources).
If the rfLMA in proxy-MAG role receives an error PBA' (e.g., Status 130, no response, or missing A4CoA echo), it SHOULD attempt reassignment to a new r2LMA and retry; if all attempts fail it MUST propagate the latest failure Status Value (or 130 if no response) to the MAG.
In the proxy-MAG model with IPv4 transport (RFC 5844), the rfLMA MUST include the Alternate IPv4 Care-of Address (A4CoA) option in PBU' containing the IPv4 Proxy Care-of Address of the original MAG; the r2LMA uses this address for tunnel setup and BCE creation.
The rfLMA MUST only assign a MAG to an r2LMA with which it knows the MAG has an existing SA or can establish one dynamically; the rfLMA MUST NOT assign the MAG to an r2LMA lacking a prior agreement and trust relationship, and MUST NOT change the transport IP address family during the assignment.
In the separate rfLMA/r2LMA (proxy-MAG) model, the rfLMA acts as a non-transparent proxy: it creates a proxy state, constructs a new PBU' to the r2LMA containing all non-security mobility options from the original PBU plus an ACoA/A4CoA carrying the original MAG's Proxy Care-of Address, then upon receiving the r2LMA's PBA' sends a final PBA to the MAG with the Redirect option.
The Load Information option may be included in any PBA to report the LMA's Priority, Sessions in Use, Maximum Sessions, Used Capacity, and Maximum Capacity, enabling a MAG or proxy-MAG to maintain an internal priority ordering of candidate LMAs for load-balancing decisions.
The Redirect-Capability option is included by a MAG in a PBU that establishes a new mobility session (Handoff Indicator = 1) to signal to the LMA that the MAG supports and has enabled the runtime LMA assignment functionality. Its presence is a prerequisite for the rfLMA to perform redirection.
The Redirect option is returned by the rfLMA in a PBA to convey the unicast address of the assigned r2LMA. The address family of the r2LMA address MUST match the transport family currently used between the MAG and rfLMA, and there can be at most one Redirect option per PBA.
Four new entries added to the RFC 6275 'Mobility Options' IANA registry: Redirect-Capability Mobility Option (46), Redirect Mobility Option (47), Load Information Mobility Option (48), and Alternate IPv4 Care-of Address (49).
An incorrectly configured LMA may trigger runtime assignment attempts to non-existing or incompatible LMAs, causing failed binding updates, unsuccessful mobility session creation, and biased load distribution. All participating LMAs must have adequate prior agreements and trust relationships.
Manually keyed SAs (which may be necessary when the rfLMA uses an anycast address) cannot typically provide the anti-replay service of ESP-protected PMIPv6 traffic; this is a known deployment-specific limitation.
When the rfLMA must modify the outer IP packet of a PBU/PBA (e.g., in the proxy-MAG model), the security mechanism MUST NOT cover the outer IP fields that will be changed; alternatively, the rfLMA handles all security processing and inter-LMA communication is protected by other means such as layer-2 VPNs.
Co-located rfLMA/r2LMA model: on receiving a PBU with Redirect-Capability destined to the rfLMA (anycast/loopback) address, the co-located LMA creates a BCE in an r2LMA role, then sends a PBA sourced from the rfLMA address containing the Redirect option with the r2LMA unicast address. PBUs arriving directly at the r2LMA unicast address are processed per RFC 5213 with no Redirect option in the response.
Alternate IPv4 Care-of Address (A4CoA) Mobility Option: Option Type = 49 (8-bit), Option Length = 4 (8-bit), Alternate IPv4 Care-of Address (32-bit). Alignment requirement 4n+2.
Load Information Mobility Option: Option Type = 48 (8-bit), Option Length = 18 (8-bit), Priority (16-bit unsigned, lower = higher priority), Sessions in Use (32-bit), Maximum Sessions (32-bit), Used Capacity in kB/s (32-bit), Maximum Capacity in kB/s (32-bit). Alignment requirement 4n.
Redirect-Capability Mobility Option: Option Type = 46 (8-bit), Option Length = 2 (8-bit, excludes Type and Length), followed by a 16-bit Reserved field that MUST be set to zero. Alignment requirement 4n.
Redirect Mobility Option: Option Type = 47 (8-bit), Option Length variable (18 if K-flag set, 6 if N-flag set; K and N cannot both be set or both unset), K-flag indicates presence of 128-bit IPv6 r2LMA address, N-flag indicates presence of 32-bit IPv4 r2LMA address. Alignment requirement 4n.