draft-ietf-netlmm-lma-discovery-01.txt   draft-ietf-netlmm-lma-discovery-02.txt 
Network-based Localized Mobility J. Korhonen Network-based Localized Mobility J. Korhonen
Management (NetLMM) Nokia Siemens Networks Management (NetLMM) Nokia Siemens Networks
Internet-Draft V. Devarapalli Internet-Draft V. Devarapalli
Intended status: Informational WiChorus Intended status: Informational WiChorus
Expires: February 24, 2010 August 23, 2009 Expires: March 6, 2010 September 2, 2009
LMA Discovery for Proxy Mobile IPv6 LMA Discovery for Proxy Mobile IPv6
draft-ietf-netlmm-lma-discovery-01.txt draft-ietf-netlmm-lma-discovery-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 24, 2010. This Internet-Draft will expire on March 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 13 skipping to change at page 2, line 13
functionality, where a Mobile Access Gateway could dynamically functionality, where a Mobile Access Gateway could dynamically
discover a Local Mobility Anchor for a Mobile Node attaching to a discover a Local Mobility Anchor for a Mobile Node attaching to a
Proxy Mobile IPv6 domain. The purpose of the dynamic discovery Proxy Mobile IPv6 domain. The purpose of the dynamic discovery
functionality is to reduce the amount of static configuration in the functionality is to reduce the amount of static configuration in the
Mobile Access Gateway. This specification describes a number of Mobile Access Gateway. This specification describes a number of
possible dynamic Local Mobility Anchor discovery solutions. possible dynamic Local Mobility Anchor discovery solutions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. AAA-based Discovery Solutions . . . . . . . . . . . . . . . . . 3 2. AAA-based Discovery Solutions . . . . . . . . . . . . . . . . 3
2.1. Receiving LMA Address during the Network Access 2.1. Receiving LMA Address during the Network Access
Authentication . . . . . . . . . . . . . . . . . . . . . . 4 Authentication . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Receiving LMA FQDN during the Network Access 2.2. Receiving LMA FQDN during the Network Access
Authentication . . . . . . . . . . . . . . . . . . . . . . 4 Authentication . . . . . . . . . . . . . . . . . . . . . . 4
3. Lower Layers based Discovery Solutions . . . . . . . . . . . . 5 3. Lower Layers based Discovery Solutions . . . . . . . . . . . . 5
3.1. Constructing the LMA FQDN from a mobile node Identity . . . 5 3.1. Constructing the LMA FQDN from a mobile node Identity . . 5
3.2. Receiving LMA FQDN or IP Address from Lower Layers . . . . 6 3.2. Receiving LMA FQDN or IP Address from Lower Layers . . . . 6
3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6 3.3. Constructing the LMA FQDN from a Service Name . . . . . . 6
4. Domain Name System Considerations . . . . . . . . . . . . . . . 6 4. Domain Name System Considerations . . . . . . . . . . . . . . 6
5. Handover Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Handover Considerations . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments would benefit Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments would benefit
from a functionality, where a Mobile Access Gateway (MAG) could from a functionality, where a Mobile Access Gateway (MAG) could
dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node
(MN) attaching to a PMIPv6 domain. The purpose of the dynamic (MN) attaching to a PMIPv6 domain. The purpose of the dynamic
discovery functionality is to reduce the amount of static discovery functionality is to reduce the amount of static
configuration in the MAG. Other drivers for the dynamic discovery of configuration in the MAG. Other drivers for the dynamic discovery of
a LMA include LMA load balancing solutions and selecting LMA based on a LMA include LMA load balancing solutions and selecting LMA based on
skipping to change at page 6, line 9 skipping to change at page 6, line 9
The solution discussed in this section has issues if MN's identity The solution discussed in this section has issues if MN's identity
does not embed enough information. In a case the MN identity does does not embed enough information. In a case the MN identity does
not embed any LMA hosting entity information, the MAG might use a not embed any LMA hosting entity information, the MAG might use a
local database to map MN identities to corresponding LMAs. However, local database to map MN identities to corresponding LMAs. However,
this solution is unlikely to scale outside a limited PMIPv6 domain. this solution is unlikely to scale outside a limited PMIPv6 domain.
3.2. Receiving LMA FQDN or IP Address from Lower Layers 3.2. Receiving LMA FQDN or IP Address from Lower Layers
The solution described in this section is similar to the solution The solution described in this section is similar to the solution
discussed in Section 3.1. Instead of deriving the LMA FQDN from the discussed in Section 3.1. Instead of deriving the LMA FQDN from the
MN identity, the MAG receives explicit LMA FQDN or IP address MN identity, the MAG receives a LMA FQDN or an IP address information
information from lower layers. This usually means the MN is the from lower layers, for example, as a part of the normal lower layer
originator of the LMA information and explicitly participates to the signaling when the MN attaches to the network. One existing example
mobility management signaling (even if that only means providing LMA of such lower layer functionality is the Access Point Name
discovery assisting information). Information Element (APN IE) in 3GPP radio's network access signaling
capable of carrying a FQDN [3GPP.24.008]. However, in general this
means the MN is also the originator of the LMA information. The LMA
information content as such can be transparent to the MN, meaning the
MN has no knowledge it being anything LMA related.
3.3. Constructing the LMA FQDN from a Service Name 3.3. Constructing the LMA FQDN from a Service Name
Some network access technologies (including tunneling solutions) Some network access technologies (including tunneling solutions)
allow the MN to signal the service name that identifies a particular allow the MN to signal the service name that identifies a particular
service or the external network it wants to access. If the MN service or the external network it wants to access. If the MN
originated service name also embeds the information of the entity originated service name also embeds the information of the entity
hosting the service or the external network, then the MAG can hosting the service or the hosting information can be derived from
construct a generic LMA FQDN (e.g., based on some pre-configured other information available at the same time (e.g., see Section 3.1),
formatting rules) providing an access to the service or the external then the MAG can construct a generic LMA FQDN (e.g., based on some
network. Once the MAG has the FQDN it can proceed to resolve the LMA pre-defined formatting rules) providing an access to the service or
IP address(es) using the DNS. Example of such service or external the external network. The pre-defined formatting rules are usually
agreed on among operators that belong to the same inter-operator
roaming consortium or by network infrastructure vendors defining an
open networking system architecture.
Once the MAG has the FQDN it can proceed to resolve the LMA IP
address(es) using the DNS. An example of such service or external
network name is the Access Point Name (APN) [3GPP.23.003] that network name is the Access Point Name (APN) [3GPP.23.003] that
contain information of the operator providing the access to the given contain information of the operator providing the access to the given
service or the external network. service or the external network.
4. Domain Name System Considerations 4. Domain Name System Considerations
A number of LMA discovery solutions described in Section 2 and A number of LMA discovery solutions described in Section 2 and
Section 3 eventually depend on the DNS. This section discusses Section 3 eventually depend on the DNS. This section discusses
impacts of the DNS response caching and issues related to the Dynamic impacts of the DNS response caching and issues related to the Dynamic
DNS [RFC2136] updates. DNS [RFC2136] updates.
skipping to change at page 8, line 35 skipping to change at page 8, line 46
server communication relies on the security properties of the server communication relies on the security properties of the
intermediate AAA brokers and AAA proxies. intermediate AAA brokers and AAA proxies.
7. IANA Considerations 7. IANA Considerations
This specification has no actions for IANA. This specification has no actions for IANA.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Julien Laganier, Christian Vogt, The authors would like to thank Julien Laganier, Christian Vogt,
Ryuji Wakikawa, Frank Xia and Behcet Sarikaya for their comments and Ryuji Wakikawa, Frank Xia, Behcet Sarikaya and Xiangsong Cui for
suggestions on this document. their comments, extensive discussions and suggestions on this
document.
9. Informative References 9. Informative References
[3GPP.23.003] [3GPP.23.003]
3GPP, "Numbering, addressing and identification", 3GPP 3GPP, "Numbering, addressing and identification", 3GPP
TS 23.003 8.2.0, September 2008. TS 23.003 8.2.0, September 2008.
[3GPP.24.008]
3GPP, "Mobile radio interface Layer 3 specification", 3GPP
TS 24.008 8.6.0, June 2009.
[I-D.ietf-dime-pmip6] [I-D.ietf-dime-pmip6]
Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
Gateway and Local Mobility Anchor Interaction with Gateway and Local Mobility Anchor Interaction with
Diameter Server", draft-ietf-dime-pmip6-02 (work in Diameter Server", draft-ietf-dime-pmip6-03 (work in
progress), April 2009. progress), August 2009.
[I-D.ietf-mipshop-pfmipv6] [I-D.ietf-mipshop-pfmipv6]
Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", Xia, "Fast Handovers for Proxy Mobile IPv6",
draft-ietf-mipshop-pfmipv6-08 (work in progress), draft-ietf-mipshop-pfmipv6-08 (work in progress),
July 2009. July 2009.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)", "Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997. RFC 2136, April 1997.
 End of changes. 12 change blocks. 
26 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/