draft-ietf-netlmm-lma-discovery-06.txt   draft-ietf-netlmm-lma-discovery-07.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 Vasona Networks Intended status: Informational Vasona Networks
Expires: March 21, 2011 September 17, 2010 Expires: April 15, 2011 October 12, 2010
LMA Discovery for Proxy Mobile IPv6 LMA Discovery for Proxy Mobile IPv6
draft-ietf-netlmm-lma-discovery-06.txt draft-ietf-netlmm-lma-discovery-07.txt
Abstract Abstract
Large Proxy Mobile IPv6 deployments would benefit from a Large Proxy Mobile IPv6 deployments would benefit from a
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 document describes several possible Mobile Access Gateway. This document describes several possible
dynamic Local Mobility Anchor discovery solutions. dynamic Local Mobility Anchor discovery solutions.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 21, 2011. This Internet-Draft will expire on April 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Authentication . . . . . . . . . . . . . . . . . . . . . . 4 Authentication . . . . . . . . . . . . . . . . . . . . . . 4
3. Discovery Solutions based on Data from Lower Layers . . . . . . 5 3. Discovery Solutions based on Data from Lower Layers . . . . . . 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 . . . . 5 3.2. Receiving LMA FQDN or IP Address from Lower Layers . . . . 5
3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6 3.3. Constructing the LMA FQDN from a Service Name . . . . . . . 6
4. Handover Considerations . . . . . . . . . . . . . . . . . . . . 6 4. Handover Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from A Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment would benefit from
a functionality, where a Mobile Access Gateway (MAG) can dynamically a functionality, where a Mobile Access Gateway (MAG) can dynamically
discover a Local Mobility Anchor (LMA) for a Mobile Node (MN) discover a Local Mobility Anchor (LMA) for a Mobile Node (MN)
attaching to a PMIPv6 domain. The purpose of the dynamic discovery attaching to a PMIPv6 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
MAG. Other drivers for the dynamic discovery of a LMA include LMA MAG. Other drivers for the dynamic discovery of a LMA include LMA
load balancing solutions and selecting a LMA based on desired load balancing solutions and selecting a LMA based on desired
services. This document describes several possible dynamic LMA services (i.e. allowing service-specific routing of traffic)
[RFC5149]. This document describes several possible dynamic LMA
discovery approaches and makes a recommendation of the preferred one. discovery approaches and makes a recommendation of the preferred one.
The following list briefly introduces solution approaches that will The following list briefly introduces solution approaches that will
be discussed in this document: be discussed in this document:
o LMA Address from AAA during the network access authentication o LMA Address is retrieved from the Authentication, Authorization
procedure when the MN attaches to the MAG. and Accounting (AAA) infrastructure during the network access
authentication procedure when the MN attaches to the MAG.
o LMA FQDN from AAA during the network access authentication, o LMA Fully Qualified Domain Name (FQDN) is retrieved from the AAA
followed by a Domain Name System (DNS) lookup. infrastructure during the network access authentication, followed
by a Domain Name System (DNS) lookup.
o LMA FQDN derived from the MN identity received from the lower o LMA FQDN is derived from the MN identity received from the lower
layers during the network attachment, followed by a DNS lookup. layers during the network attachment, followed by a DNS lookup.
o LMA FQDN or IP address received from the lower layers during the o LMA FQDN or IP address is received from the lower layers during
network attachment. The reception of an FQDN from the lower the network attachment. The reception of an FQDN from the lower
layers is followed by a DNS lookup. layers is followed by a DNS lookup.
o LMA FQDN derived from the service selection indication received o LMA FQDN is derived from the service selection indication received
from lower layers during the network attachment, followed by a DNS from lower layers during the network attachment, followed by a DNS
lookup. lookup.
When a MN performs a handover from one MAG to another, the new MAG When a MN performs a handover from one MAG to another, the new MAG
must use the same LMA that the old MAG was using. This is required must use the same LMA that the old MAG was using. This is required
for session continuity. The LMA discovery mechanism in the new MAG for session continuity. The LMA discovery mechanism in the new MAG
should be able to return the information of the same LMA that was should be able to return the information of the same LMA that was
being used by the old MAG. This document also discusses solutions being used by the old MAG. This document also discusses solutions
for LMA discovery during a handover. for LMA discovery during a handover.
skipping to change at page 4, line 33 skipping to change at page 4, line 36
Once the MAG receives the LMA IP address, it sends Proxy Binding Once the MAG receives the LMA IP address, it sends Proxy Binding
Update (PBU) message for the newly authenticated and authorized MN. Update (PBU) message for the newly authenticated and authorized MN.
The MAG expects that the LMA returned by the AAA server is able to The MAG expects that the LMA returned by the AAA server is able to
provide mobility session continuity for the MN, i.e. after a handover provide mobility session continuity for the MN, i.e. after a handover
the LMA would be the same one the MN already has a mobility session the LMA would be the same one the MN already has a mobility session
set up with. set up with.
2.2. Receiving LMA FQDN during the Network Access Authentication 2.2. Receiving LMA FQDN during the Network Access Authentication
This solution is similar to the procedure described in Section 2.1. This solution is similar to the procedure described in Section 2.1.
The difference is that the MAG receives a Fully Qualified Domain Name The difference is that the MAG receives an FQDN of the LMA instead of
(FQDN) of the LMA instead of the IP address(es). The MAG has to the IP address(es). The MAG has to query the DNS infrastructure in
query the DNS infrastructure in order to resolve the FQDN to the LMA order to resolve the FQDN to the LMA IP address(es).
IP address(es).
The LMA FQDN might be a generic name for a PMIPv6 domain that The LMA FQDN might be a generic name for a PMIPv6 domain that
resolves to one or more LMAs in the PMIPv6 domain. Alternatively the resolves to one or more LMAs in the PMIPv6 domain. Alternatively the
LMA FQDN might be resolved to exactly one LMA within the PMIPv6 LMA FQDN might be resolved to exactly one LMA within the PMIPv6
domain. The latter approach would obviously be useful if a new domain. The latter approach would obviously be useful if a new
target MAG after a handover should resolve the LMA FQDN to the LMA IP target MAG after a handover should resolve the LMA FQDN to the LMA IP
address where the MN mobility session is already located. address where the MN mobility session is already located.
The procedures described in this section and in Section 2.1 may also The procedures described in this section and in Section 2.1 may also
be used together. For example, the AAA server might return a generic be used together. For example, the AAA server might return a generic
skipping to change at page 5, line 14 skipping to change at page 5, line 16
using the AAA infrastructure once it receives the initial PBU from using the AAA infrastructure once it receives the initial PBU from
the MAG for the new mobility session. the MAG for the new mobility session.
3. Discovery Solutions based on Data from Lower Layers 3. Discovery Solutions based on Data from Lower Layers
The following section discusses solutions, where a MAG acquires The following section discusses solutions, where a MAG acquires
information from layers below the IP layer. Based on this information from layers below the IP layer. Based on this
information, the MAG is able to determine which LMA to contact when information, the MAG is able to determine which LMA to contact when
the MN attaches to the MAG. The lower layers discussed here are not the MN attaches to the MAG. The lower layers discussed here are not
explicitly defined but include different radio access technologies explicitly defined but include different radio access technologies
and tunneling solutions such as IKEv2 [RFC4306] IPsec tunnel and tunneling solutions such as IKEv2 [RFC5996] IPsec tunnel
[RFC4303]. [RFC4303].
3.1. Constructing the LMA FQDN from a Mobile Node Identity 3.1. Constructing the LMA FQDN from a Mobile Node Identity
A MAG acquires a MN identity from lower layers. The MAG can use the A MAG acquires a MN identity from lower layers. The MAG can use the
information embedded in the identity to construct a generic LMA FQDN information embedded in the identity to construct a generic LMA FQDN
(based on some pre-configured formatting rules) and then proceed to (based on some pre-configured formatting rules) and then proceed to
resolve the LMA IP address(es) using the DNS. Obviously, the MN resolve the LMA IP address(es) using the DNS. Obviously, the MN
identity must embed information that can be used to uniquely identify identity must embed information that can be used to uniquely identify
the entity hosting and operating the LMA for the MN. Examples of the entity hosting and operating the LMA for the MN. Examples of
skipping to change at page 6, line 10 skipping to change at page 6, line 10
general this means the MN is also the originator of the LMA general this means the MN is also the originator of the LMA
information. The LMA information content as such can be transparent information. The LMA information content as such can be transparent
to the MN, meaning the MN does not associate the information with any to the MN, meaning the MN does not associate the information with any
LMA function. LMA function.
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 [3GPP.24.302] service or the external network it wants to access [3GPP.24.302]
[RFC4306]. If the MN originated service name also embeds the [RFC5996]. If the MN originated service name also embeds the
information of the entity hosting the service or the hosting information of the entity hosting the service or the hosting
information can be derived from other information available at the information can be derived from other information available at the
same time (e.g., see Section 3.1), then the MAG can construct a same time (e.g., see Section 3.1), then the MAG can construct a
generic LMA FQDN (e.g., based on some pre-defined formatting rules) generic LMA FQDN (e.g., based on some pre-defined formatting rules)
providing an access to the service or the external network. The pre- providing an access to the service or the external network. The pre-
defined formatting rules [3GPP.23.003] are usually agreed on among defined formatting rules [3GPP.23.003] are usually agreed on among
operators that belong to the same inter-operator roaming consortium operators that belong to the same inter-operator roaming consortium
or by network infrastructure vendors defining an open networking or by network infrastructure vendors defining an open networking
system architecture. system architecture.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
service or the external network. For example, an FQDN for an "ims" service or the external network. For example, an FQDN for an "ims"
APN could be "ims.apn.epc.mnc015.mcc234.3gppnetwork.org". APN could be "ims.apn.epc.mnc015.mcc234.3gppnetwork.org".
4. Handover Considerations 4. Handover Considerations
Whenever a MN moves and attaches to a new MAG in a PMIPv6 domain, all Whenever a MN moves and attaches to a new MAG in a PMIPv6 domain, all
the MAGs that the MN attaches to, should use the same LMA. If there the MAGs that the MN attaches to, should use the same LMA. If there
is only one LMA per PMIPv6 domain, then there is no issue. If there is only one LMA per PMIPv6 domain, then there is no issue. If there
is a context transfer mechanism available between the MAGs, then the is a context transfer mechanism available between the MAGs, then the
new MAG knows the LMA information from the old MAG. Such a mechanism new MAG knows the LMA information from the old MAG. Such a mechanism
is described in [I-D.ietf-mipshop-pfmipv6]. If the MN related is described in [RFC5949]. If the MN related context is not
context is not transferred between the MAGs, then a mechanism to transferred between the MAGs, then a mechanism to deliver the current
deliver the current LMA information to the new MAG is required. LMA information to the new MAG is required.
Relying on DNS during handovers is not generally a working solution Relying on DNS during handovers is not generally a working solution
if the PMIPv6 domain has more than one LMA, unless the DNS if the PMIPv6 domain has more than one LMA, unless the DNS
consistently assigns a specific LMA for each given MN. In most cases consistently assigns a specific LMA for each given MN. In most cases
described in Section 3, where the MAG derives the LMA FQDN, there is described in Section 3, where the MAG derives the LMA FQDN, there is
no prior knowledge whether the LMA FQDN resolves to one or more LMA no prior knowledge whether the LMA FQDN resolves to one or more LMA
IP address(es) in the PMIPv6 domain. However, depending on the IP address(es) in the PMIPv6 domain. However, depending on the
deployment and deployment related regulation (such as inter-operator deployment and deployment related regulation (such as inter-operator
roaming consortium agreements) the situation might not be this roaming consortium agreements) the situation might not be this
desperate. For example, a MAG might be able to synthesize a LMA desperate. For example, a MAG might be able to synthesize a LMA
skipping to change at page 7, line 37 skipping to change at page 7, line 37
Solutions in Section 3 all depend on lower layers being able to Solutions in Section 3 all depend on lower layers being able to
provide information that a MAG can then use to query DNS and discover provide information that a MAG can then use to query DNS and discover
a suitable LMA. The capabilities of the lower layers and the a suitable LMA. The capabilities of the lower layers and the
interactions with them are generally out of scope of IETF, and interactions with them are generally out of scope of IETF, and
specific to a certain system and architecture. specific to a certain system and architecture.
Solutions in Section 2 depend on the existence of an AAA Solutions in Section 2 depend on the existence of an AAA
infrastructure, which is able to provide a MAG either a LMA IP infrastructure, which is able to provide a MAG either a LMA IP
address or a LMA FQDN. While there can be system and architecture address or a LMA FQDN. While there can be system and architecture
specific details regarding the AAA interactions and the use of DNS, specific details regarding the AAA interactions and the use of DNS,
the dynamic LMA discovery can be entirely implemented using protocols the dynamic LMA discovery can be implemented in an access and
and technologies developed in IETF. Therefore, using AAA based LMA technology agnostic manner, and work in the same way across
discovery solutions are recommended by this document. heterogeneous environments. Therefore, using AAA based LMA discovery
solutions are recommended by this document.
6. Security Considerations 6. Security Considerations
The use of DNS for obtaining the IP address of a mobility agent The use of DNS for obtaining the IP address of a mobility agent
carries certain security risks. These are explained in detail in carries certain security risks. These are explained in detail in
Section 9.1 of [RFC5026]. However, the risks described in [RFC5026] Section 9.1 of [RFC5026]. However, the risks described in [RFC5026]
are mitigated to a large extent in this document, since the MAG and are mitigated to a large extent in this document, since the MAG and
the LMA belong to the same PMIPv6 domain. The DNS server that the the LMA belong to the same PMIPv6 domain. The DNS server that the
MAG queries is also part of the same PMIPv6 domain. Even if the MAG MAG queries is also part of the same PMIPv6 domain. Even if the MAG
obtains the IP address of a bogus LMA from a bogus DNS server, obtains the IP address of a bogus LMA from a bogus DNS server,
skipping to change at page 8, line 27 skipping to change at page 8, line 28
This document has no actions for IANA. This document 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, Behcet Sarikaya, Charlie Perkins, Qin Wu, Ryuji Wakikawa, Frank Xia, Behcet Sarikaya, Charlie Perkins, Qin Wu,
Jari Arkko and Xiangsong Cui for their comments, extensive Jari Arkko and Xiangsong Cui for their comments, extensive
discussions and suggestions on this document. discussions and suggestions on this document.
9. Informative References 9. References
9.1. Normative References
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. 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.24.008]
3GPP, "Mobile radio interface Layer 3 specification", 3GPP 3GPP, "Mobile radio interface Layer 3 specification", 3GPP
TS 24.008 8.6.0, June 2009. TS 24.008 8.6.0, June 2009.
[3GPP.24.302] [3GPP.24.302]
3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via 3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via
non-3GPP access networks", 3GPP TS 24.302 10.0.0, non-3GPP access networks", 3GPP TS 24.302 10.0.0,
June 2010. June 2010.
[I-D.ietf-mipshop-pfmipv6]
Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6",
draft-ietf-mipshop-pfmipv6-14 (work in progress),
May 2010.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., [RFC5779] 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", RFC 5779, February 2010. Diameter Server", RFC 5779, February 2010.
[RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949,
September 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
Authors' Addresses Authors' Addresses
Jouni Korhonen Jouni Korhonen
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
FIN-02600 Espoo FIN-02600 Espoo
Finland Finland
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 20 change blocks. 
37 lines changed or deleted 48 lines changed or added

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