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]