draft-ietf-netlmm-lma-discovery-05.txt   draft-ietf-netlmm-lma-discovery-06.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 17, 2011 September 13, 2010 Expires: March 21, 2011 September 17, 2010
LMA Discovery for Proxy Mobile IPv6 LMA Discovery for Proxy Mobile IPv6
draft-ietf-netlmm-lma-discovery-05.txt draft-ietf-netlmm-lma-discovery-06.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 17, 2011. This Internet-Draft will expire on March 21, 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 3, line 14 skipping to change at page 3, line 14
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 (i.e. allowing service-specific routing of traffic) services. This document describes several possible dynamic LMA
[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 from AAA during the network access authentication
procedure when the MN attaches to the MAG. procedure when the MN attaches to the MAG.
o LMA FQDN from AAA during the network access authentication, o LMA FQDN from AAA during the network access authentication,
followed by a Domain Name System (DNS) lookup. followed by a Domain Name System (DNS) lookup.
skipping to change at page 4, line 20 skipping to change at page 4, line 19
attaching to the network, the PMIPv6 related parameters are attaching to the network, the PMIPv6 related parameters are
bootstrapped in parallel with authentication for the network access bootstrapped in parallel with authentication for the network access
and authorization for the mobility services. The PMIPv6 parameters and authorization for the mobility services. The PMIPv6 parameters
bootstrapping involves the Policy Profile download over the AAA bootstrapping involves the Policy Profile download over the AAA
infrastructure to the MAG (see Appendix A of [RFC5213]). infrastructure to the MAG (see Appendix A of [RFC5213]).
2.1. Receiving LMA Address during the Network Access Authentication 2.1. Receiving LMA Address during the Network Access Authentication
After the MN has successfully authenticated for the network access After the MN has successfully authenticated for the network access
and authorized for the mobility service, the MAG receives the LMA IP and authorized for the mobility service, the MAG receives the LMA IP
address(es) from the AAA server over the AAA infrastructure. The LMA address from the AAA server over the AAA infrastructure. The LMA IP
IP address information would be part of the AAA message that ends the address information would be part of the AAA message that ends the
successful authentication and authorization AAA exchange. successful authentication and authorization AAA exchange.
Once the MAG receives the LMA IP address(es), 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 a Fully Qualified Domain Name
skipping to change at page 5, line 4 skipping to change at page 4, line 51
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
LMA FQDN during the MN initial attach and once the LMA gets selected, LMA FQDN during the MN initial attach and once the LMA gets selected,
return the LMA IP address during the subsequent attachments to other return the LMA IP address during the subsequent attachments to other
MAGs in the PMIPv6 domain. In order for this to work, the resolved MAGs in the PMIPv6 domain. In order for this to work, the resolved
and selected LMA IP address must be updated to the remote Policy and selected LMA IP address must be updated to the remote Policy
Store. For example, the LMA could perform the update once it Store. For example, the LMA could perform the Policy Store update
receives the initial PBU from the MAG for the new mobility session. using the AAA infrastructure once it receives the initial PBU from
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 [RFC4306] IPsec tunnel
[RFC4303]. [RFC4303].
skipping to change at page 6, line 25 skipping to change at page 6, line 25
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.
Once the MAG has the FQDN it can proceed to resolve the LMA IP 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 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. For example, an FQDN for an "ims"
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 [I-D.ietf-mipshop-pfmipv6]. If the MN related
context is not transferred between the MAGs, then a mechanism to context is not transferred between the MAGs, then a mechanism to
skipping to change at page 7, line 35 skipping to change at page 7, line 36
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, the dynamic LMA specific details regarding the AAA interactions and the use of DNS,
discovery can be entirely implemented using protocols and the dynamic LMA discovery can be entirely implemented using protocols
technologies developed in IETF. Therefore, using AAA based LMA and technologies developed in IETF. Therefore, using AAA based LMA
discovery solutions are recommended by this document. 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
skipping to change at page 9, line 15 skipping to change at page 9, line 16
[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", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. 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.
[RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Selection for Mobile IPv6", RFC 5149, February 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 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.
Authors' Addresses Authors' Addresses
 End of changes. 10 change blocks. 
17 lines changed or deleted 15 lines changed or added

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