One document matched: draft-cui-netext-lma-redirection-solution-00.txt
NETEXT working group X. Cui
Internet Draft Huawei
Intended status: Standards Track July 27, 2009
Expires: January 2010
LMA Redirection Solution
draft-cui-netext-lma-redirection-solution-00.txt
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 26 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
In network-based mobility management domain, LMA is used to manage
the mobility of IP node attached to MAG. LMA discovery and LMA
Cui Expires January 26, 2010 [Page 1]
Internet-Draft LMA redirection solution July 2009
redirection mechanism are used to improve the network flexibility.
This document is used to introduce a recommended solution for this
purpose. In this solution Redirect Agent function is adopted to
accomplish the requirement.
Conventions used in this document
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].
Table of Contents
1. Introduction....................................................3
2. Terminology.....................................................3
3. Solution Consideration..........................................4
4. Existing solutions and comparison...............................5
5. Message and options.............................................6
6. Conclusion and proposal.........................................7
7. Security Considerations.........................................7
8. IANA Considerations.............................................7
9. Acknowledgments.................................................7
10. References.....................................................7
10.1. Normative References......................................7
10.2. Informative References....................................8
Author's Addresses.................................................8
Cui Expires January 26, 2010 [Page 2]
Internet-Draft LMA redirection solution July 2009
1. Introduction
LMA redirection is an accepted feature in NETEXT Working Group. By
this feature, a LMA can re-assign another more appropriate LMA to the
MAG and the mobile node, when the MAG requests binding to the given
LMA.
There are already some documents describing the procedure of LMA
discovery and LMA redirection, such as [RFC5447], [I-D.ietf-NETLMM-
LMA-Discovery] and [I-D.ietf-korhonen-redirect].
[RFC5447] introduces a solution for Home Agent assignment. AAA Client
can get the Home Agent information from the AAA Server during access
authentication.
[I-D.ietf-NETLMM-LMA-Discovery] brings the mechanism into NETLMM
network. The MAG can also get the LMA information from the AAA Server
during access authentication.
[I-D.ietf-korhonen-redirect] introduces some solutions for LMA
redirection. The precondition is that the redirection functionality
is enabled in LMA and the principle is that the roLMA forwards the
PBU message received from a MAG to the rnLMA with the address of
roLMA attached. PBA message from the rnLMA may be replied to the MAG
through the roLMA or directly.
Another one solution is introduced in this document to enrich the LMA
direction mechanism. The introduced solution is presented in Section
3. In Section 4, the introduced solution is compared to solutions in
other documents. New messages and options are introduced in Section 5
to accomplish the solution. And in Section 6 the conclusion and
proposal are offered.
2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in the Proxy Mobile IPv6 [RFC5213].
This document also provides the following context-specific
explanation to the following terms used in this document.
roLMA
The old LMA in LMA redirection procedure, which receives the original
PBU from a MAG and reply a redirect response to recommend an
alternate candidate LMA.
Cui Expires January 26, 2010 [Page 3]
Internet-Draft LMA redirection solution July 2009
rcLMA
The candidate LMA in LMA redirection procedure, which is supplied in
the redirect response message to a MAG.
rnLMA
The new LMA in LMA redirection procedure, which a MAG was redirected
to.
3. Solution Consideration
[RFC5447] provides a mechanism for HA discovery. MIP6-Agent-Info AVP
is introduced in section 4.2.1 of [RFC5447]. MIP6-Agent-Info AVP is
used to contain Home Agent information and MIP6-Agent-Info AVP
contains either the MIP-Home-Agent-Address AVP, the MIP-Home-Agent-
Host AVP, or both AVPs. Additionally, the MIP-Home-Agent-Host may
point to a group of HAs located within the same realm and offer an
additional level of indirection by using the DNS infrastructure.
This means the MAG may get a group of LMAs located within the same
realm. So the MAG has two choices when the first requested LMA is not
appropriate for the binding. MAG may choose the other LMA from the
LMA group assigned by AAA Server, or request the roLMA to achieve the
LMA redirection on behalf of the MAG.
In some scenario the MAG should be aware of the redirection and
involve in it. In order to avoid the limitation of one choice, the
MAG may be involved in the indirection procedure, as this document
introduces.
In this solution, the MAG inserts an option in the PBU message to
indicate the concern. When the concern option is attached in the
received PBU request, the roLMA SHOULD NOT forward the PBU request.
The roLMA MAY either reply a redirect response with an attached rcLMA
option to supply a recommended rcLMA, or reply a redirect response
without rcLMA option to indicate the MAG to achieve the redirection
procedure by itself. In both cases the final decision and enforcement
is achieved by the profile in the MAG. The MAG can determine how to
carry out the LMA redirection procedure and send PBU message to the
chosen LMA (i.e. the rnLMA). The profile may be to accept the rcLMA
as the rnLMA, or to try each LMA in the cached LMA list in sequence,
or to get the rnLMA information in other way.
The redirect flow is shown in Figure 1.
Cui Expires January 26, 2010 [Page 4]
Internet-Draft LMA redirection solution July 2009
MAG roLMA rnLMA
| | |
| | |
a. |----PBU---->| | concern option in the PBU message
| | |
b. |<-Redirect--| | rcLMA in the Redirect Reponse or not
| | |
c. | | | profile in MAG enforced
| | |
d. |-----------PBU---------->| rnLMA is the destination of the PBU
| | |
e. |<----------PBA-----------| normal binding procedure
| | |
f. |<==========data=========>|
| | |
g. |-----------PBU---------->|
| | |
h. |<----------PBA-----------|
Figure 1. redirection flow
The detailed descriptions are as follows:
a. MAG initiates a binding with a concern option in the PBU message;
b. The roLMA replies a redirect response to indicate the redirection,
rcLMA option in or not in the response message;
c. The profile in MAG is enforced and the rnLMA is determined;
d. MAG initiates a new binding towards rnLMA;
e. rnLMA replies PBA as specified in [RFC5213];
f~h. Data transmission and binding as normal procedure in [RFC5213].
4. Existing solutions and comparison
[I-D.ietf-korhonen-redirect] provides a forwarding redirection
solution, while this document introduces a reply redirection
solution.
The difference between the two solutions is that, MAG works as Proxy
Agent in the forwarding redirection solution and as Redirection Agent
in reply redirection solution.
Cui Expires January 26, 2010 [Page 5]
Internet-Draft LMA redirection solution July 2009
Proxy Agent and Redirect Agent are different functionality entities
exactly. For example, as defined in Diameter Base Protocol [RFC3588],
Proxy Agent is "in addition to forwarding requests and responses,
proxies make policy decisions relating to resource usage and
provisioning", and Redirect Agent is "refer clients to servers and
allow them to communicate directly".
The concept of Proxy, Relay and Redirect are exactly different. In
PMIP domain, the definition is also applicable.
In the Proxy Agent redirection solution, the MAG can't affect the
roLMA how to process the LMA redirection. The MAG is excluded in the
redirection decision-making, although this solution is a little
quicker.
In the Redirect Agent redirection solution, the MAG is aware the LMA
redirection procedure and involves in the redirection
decision-making. In some scenario, maybe this solution is a better
way.
The advantage of Redirect Agent solution includes following:
1. MAG can involve in the LMA redirection procedure and choose the
alternate LMA by the preference of itself, but not others.
2. The redirection function may be concentrated in some capable
servers (such as AAA Server, DNS server or others), but not
every LMA node. So the Redirect Agent solution is much easier
to administrate and maintain for the network operators.
3. In the Redirect Agent solution, the LMA-LMA protocol between
nodes in the redirection domain is much easier. The nodes in
Redirect Agent solution constitute a star network or a tree
network, while the nodes in Proxy Agent solution constitute a
full-mesh network. The LMA-LMA protocol is more complex in the
Proxy Agent redirection solution, because the Proxy LMA must
know all other LMAs' information to balance the load well.
5. Message and options
TBD.
Cui Expires January 26, 2010 [Page 6]
Internet-Draft LMA redirection solution July 2009
6. Conclusion and proposal
The Proxy Agent solution may be used in small-scale network, as a
distributed solution.
The Redirect Agent solution may be used in large-scale network, as a
centralized solution or a client-aware solution.
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. Acknowledgments
TBD.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Sri, G., Kent, L., Vijay, D. Kuntal, C. and Basavaraj, P.,
"Proxy Mobile IPv6", RFC 5213, August 2008.
Cui Expires January 26, 2010 [Page 7]
Internet-Draft LMA redirection solution July 2009
[RFC5447] Jouni, K., Julien, B., Hannes, T., Charles, P. and Kuntal
C., "Diameter Mobile IPv6: Support for Network Access
Server to Diameter Server Interaction", RFC 5447, February
2009.
[I-D.ietf-NETLMM-LMA-Discovery]
Jouni, K. and Vijay, D. ''LMA Discovery for Proxy Mobile
IPv6'', draft-ietf-netlmm-lma-discovery-00.txt, May 2009.
[I-D.ietf-korhonen-redirect]
Jouni, K., Sri, G. and Hidetoshi, Y., ''Runtime LMA
Assignment Support for Proxy Mobile IPv6'', draft-korhonen-
netext-redirect-02.txt, May 2009
10.2. Informative References
[RFC3588] Pat, C., John, L., Jari, A., Erik, G. and Glen, Z.,
"Diameter Base Protocol", RFC3588, September, 2003.
Author's Addresses
Xiangsong Cui
Huawei Technologies
KuiKe Bld., No.9 Xinxi Rd.,
Shang-Di Information Industry Base,
Hai-Dian District, Beijing, P.R. China, 100085
Email: Xiangsong.Cui@huawei.com
Cui Expires January 26, 2010 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 08:00:56 |