One document matched: draft-wu-dime-pmip6-lr-00.txt
Network Working Group Q. Wu
Internet-Draft J. Xia
Intended status: Standards Track Y. Wang
Expires: April 22, 2010 Huawei
G. Zorn, Ed.
Network Zen
October 19, 2009
AAA Support for PMIP6 mobility entities Locating and Discovery during
localized routing
draft-wu-dime-pmip6-lr-00
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 April 22, 2010.
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.
Wu, et al. Expires April 22, 2010 [Page 1]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
Abstract
In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the
the Mobile Access Gateway (MAG) to which it is attached are typically
tunneled to a Local Mobility Anchor (LMA) for routing. The term
"localized routing" refers to a method by which packets are routed
directly by the MAG without involving the LMA. In order to establish
a localized routing session between two Mobile Access Gateways in a
Proxy Mobile IPv6 domain, two tasks must be accomplished:
1. The usage of local routing must be authorized for both MAGs and
2. The address of the MAG to which the Correspondent Node (CN) is
attached must be discovered
This document specifies how to accomplish these tasks using the
Diameter protocol
Wu, et al. Expires April 22, 2010 [Page 2]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Locating the Recipient of Localized Routing . . . . . . . . . 6
5. Diameter server authorizes to Query MAG Location . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Wu, et al. Expires April 22, 2010 [Page 3]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
1. Introduction
Proxy Mobile IPv6 (PMIPv6 [RFC5213] allows the Mobility Access
Gateway to optimize media delivery by locally routing packets within
itself, avoiding tunneling them to the Mobile Node's Local Mobility
Anchor. This is referred to as "local routing" in RFC 5213.
However, this mechanism is not applicable to the typical scenario
where the MN and CN are under different MAGs and belong to different
LMAs. In this scenario (as described in
[I-D.ietf-netext-pmip6-lr-ps]), the relevant information needed to
set up a localized routing path (e.g., the Mobile Access Gateways to
which the MN and CN are respectively attached) is distributed between
their respective Local Mobility Anchors. This may complicate the
setup and maintenance of localized routing.
Therefore, in order to establish a localized routing path between the
two Mobile Access Gateways, the Mobile Node's MAG must discover which
LMA is managing the Correspondent Node's traffic and then fetch the
address of the Correspondent Node's MAG from that LMA. In Proxy
Mobile IPv6, the LMA to be assigned to CN may be maintained as a
configured entry in the Correspondent Node's policy profile located
on a Authentication, Authorization and Accounting (AAA) server.
However, there is no relevant work discussing how the Correspondent
Node's LMA is discovered by Mobile Node's MAG in terms of the
Correspondent Node's Home Network Prefix (HNP) using AAA-based
mechanisms during the setup of localized routing. The method by
which the Mobile Node's MAG interacts with the Correspondent Node's
LMA to identify the Correspondent Node's MAG is also unspecified.
This document describes AAA support for the authorization and
discovery of PMIPv6 mobility entities during localized routing. In
LMA discovery, Diameter [RFC3588] is used to authorize the localized
routing service and provide the Mobile Node's MAG/LMA with
information regarding the Correspondent Node's LMA. In MAG
discovery, AAA is used to determine whether Mobile Node's MAG is
allowed to fetch the address of the Correspondent Node's MAG from the
Correspondent Node's LMA. If MAG discovery is successful, the the
Correspondent Node's LMA will respond to the Mobile Node's MAG with
the address of the Correspondent Node's MAG.
2. Terminology
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 RFC 2119 [RFC2119].
Wu, et al. Expires April 22, 2010 [Page 4]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
3. Solution Overview
MAG/LMA resolution is a prerequisite to the establishment of a direct
routing path between MAG1 and MAG2 (associated with MN1 and MN2
respectively), this document addresses how to resolve the destination
MN's MAG by means of interaction between the MAG and the AAA server,
and between the LMA and the AAA server. Figure 1 shows the reference
architecture for the MAG resolution. This reference architecture
assumes
o MN1 and MN2 belong to different LMA
o the MAG and LMA support Diameter client functionality
LMA2? +---------+
+-------------->| AAA & |
| LMA2? | Policy |<--------------+
| +-->| Profile | |
| Diameter+---------+ Diameter
Diameter AAA(a) AAA(b)
AAA(a) +--+-+ +----+ |
| |LMA1| +----->|LMA2|<-------+
| +----+ | +----+
| | | |
| // | \\
| // PMIP \\
| // | \\
| | | |
| +----+ MAG2? | +----+
+---->|MAG1|<--------+ |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 1: Local Routing Service Authorization Reference Architecture
The interaction of the MAG and LMA with the AAA server is a two step
procedure involving
1. The MAG1 or LMA1 interaction with the AAA server is used to
authorize the localized routing service and fetch the IP address
of LMA2 from the AAA server (step 'a' in (Figure 1))
2. LMA2 interaction with the AAA server is used to determine whether
MAG1 is allowed to obtain the IP address of MAG2 (step 'b' in
Wu, et al. Expires April 22, 2010 [Page 5]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
(Figure 1))
4. Locating the Recipient of Localized Routing
Figure 2 shows a scenario where MAG1 acts as a Diameter client,
processing the data packet from MN1 to MN2 and requesting the
recipient of localized routing. In this scenario, MN1 and MN2 are
anchored to LMA1 and LMA2 respectively. When MAG2 intends to setup a
localized routing path between MAG1 and MAG2, it first needs to
locate the entity which maintains the information needed to setup the
localized routing path (i.e., LMA2). The Diameter client in MAG1
sends a AAR message to the Diameter server. One new value of service
type, i.e., localized routing should be defined in the Service-Type
AVP described in [RFC4005].
and encapsulated in the MAG-HAAA AVPs of Authentication Authorization
Request (AAR) message with PMIP6-MN-HNP AVP for MN2 by the MAG1. The
Diameter server processes this new Service-Type value and PMIP6-MN-
HNP AVP for MN2 in accordance with[RFC4005]. In the successful case,
the Diameter server looks up the IP address of LMA2 based on IP
address/HNP of MN2 and responds with an Authentication Authorization
Answer (AAA) message containing the IP address of LMA2 in a new
defined AVP. MAG1 extracts the IP address of LMA2 from the Diameter
message and requests the address of MAG2 from LMA2 and uses that
address to setup the localized routing path between itself and MAG2
via the Proxy Binding Update (PBU)/Proxy Binding Acknowledgement
(PBA) message exchange [RFC5213].
Wu, et al. Expires April 22, 2010 [Page 6]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o----------------o | o-------+--------o
Data[MN1->MN2] | | | | |
|------->|AAR(service type,MN2) | | |
| |----------------->| | | |
| |AAA(LMA2) | | | |
| |<-----------------| | | |
| | |PBU(LR[MN1,MN2]) | | |
| |-------+----------+--------->| | |
| | | PBA(LR[MAG2]) | | |
| |<--------------------------- | | |
| | MAGs PBU/PBA exchange | | |
| |<----------------------------------->| |
| | | | | | |
| |====================================>|------->|
| | | | | |Data[MN2->MN1]
|<------ |<====================================|<-------|
| | | | | | |
Figure 2: Locating the Recipient of Localized Routing
Figure 3 shows another scenario, in which the LMA1 may act as a
Diameter client, processing the data packet from MN1 to MN2 and
requesting the recipient of localized routing. In this scenario, MN1
and MN2 are anchored to LMA1 and LMA2 respectively. In contrast with
the signaling flow of Figure 2 the difference is that it is LMA1
instead of MAG1 who solicits the IP address of LMA2 from the Diameter
server.
First, the Diameter client in the LMA1 sends a AAR message to the
Diameter server. One new service type for localized routing should
be defined in the Service-Type AVP and encapsulated in the LMA-HAAA
AVPs of Authenticate and authorize Request (AAR) message by the LMA1.
The Diameter server processes this new service type for PMIP6
mobility entities discovery in accordance with [RFC4005]. In the
successful case, it looks up the IP address of LMA2. based on the IP
address/HNP of MN2 obtained from the destination address of the
upstream packet from MN1 and responds to the LMA1 with a AAA message
containing the IP address of LMA2. Upon receiving the AAA message,
the LMA forwards the LMA2 IP address to MAG1 in the Notification
request message.
Wu, et al. Expires April 22, 2010 [Page 7]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o----------------o | o-------+--------o
Data[MN1->MN2] | | | | |
|------->|=====-> AAR(Service Type,MN2)| | |
| | |--------->| | | |
| Notification|AAA(LMA2) | | |
| Req[LMA2] <----------| | | |
| |<------| PBU(LR[MN1,MN2]) | | |
| |-------+----------+--------->| | |
| | | PBA(LR[MAG2]) | | |
| |<--------------------------- | | |
| | MAGs PBU/PBA exchange | | |
| |<----------------------------------->| |
| | | |
| |===================================->| |
| | | | | |------->|
| | | | | |Data[MN2->MN1]
|<------ |<-===================================|<-------|
| | | | | | |
Figure 3: Locating the Recipient of Localized Routing
Figure 4 shows the third example signaling flow for MAG and LMA
signaling interaction with AAA server. In this figure, in contrast
with the examples in the figure 2 and figure 3, the IP address of
MAG2 is resolved by LMA1 based on IP address/HNP of MN2 with the help
of AAA interaction defined in this specification and inform the MAG1
of the IP address of MAG2.
In the step 1 of example, the procedure is same as that of example in
the figure 3. What's the difference is the LMA1 does not inform the
MAG1 of LMA2 IP address, instead, during the step 2, the LMA1 solicit
LMA2 to resolve IP address of MAG2 which MN2 is currently attached to
by sending AAA request message containing IP address/HNP of MN2. In
this step, the LMA2 needs to validate the request from LMA1 by
sending AAR to the AAA server with IP address/HNP of MN1 included.
The AAA makes authorization based on the IP address/HNP of MN1 and
check the new service type for MAG resolution encapsulated in the
LMA-AAA AVPs. In successful case, the AAA responds to the LMA with
success status. And then LMA2 lookup IP address of MAG2 based on the
IP address/HNP of MN2 and responds to the LMA1 with the IP address of
MAG2 which is forwarded in the Notification request message to the
MAG1.
Wu, et al. Expires April 22, 2010 [Page 8]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o----------------o | o-------+--------o
Data[MN1->MN2] | | | | |
|------->|=====->AAR(Service Type,MN2) | | |
| | ---------->| | | |
| | AAA(LMA2) | | |
| | <----------| | | |
| | | LQ[MN1,MN2] | | |
| | |----------+--------->| | |
| | | |AAR(Service Type,MN1) |
| | | |<-------- | | |
| | | | AAA | | |
| | | |--------->| | |
| Notification| LQ[MAG2] | | |
| Req[MAG2] <-------------------- | | |
| |<----- | PBU[MN1,MAG1] | | |
| |------------------------------------>| |
| | | PBA | | | |
| |<----------------------------------- | |
| | | | | | |
| |===================================->| |
| | | | | |------->|
| | | | | |Data[MN2->MN1]
|<------ |<-===================================|<-------|
| | | | | | |
Figure 4: MAG and LMA signaling interaction with AAA server
5. Diameter server authorizes to Query MAG Location
Figure 5 shows a scenario where LMA2 may act as Diameter Client,
receiving location request and requesting authorization for MAG
location lookup. In this scenario, MN1 and MN2 are anchored to LMA1
and LMA2 respectively. Upon receiving upstream data packet, MAG1
needs to determine the recipient of localized routing, i.e., LMA2.
And then MAG1 solicit the LMA2 to lookup IP address of MAG2 to which
MN2 is currently attached by sending localized routing request
message containing IP address/HNP of MN1 and MN2. In this step, the
LMA2 needs to validate the request from MAG1 by sending Authenticate
and authorize request(AAR) to the AAA server. In the AAR message, IP
address/HNP of MN1 and the new service type for localized routing is
included. The Diameter Server makes authorization based on the IP
Wu, et al. Expires April 22, 2010 [Page 9]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
address/HNP of MN1 and checks the new service type for localized
routing encapsulated in the LMA-AAA AVPs. In successful case, the
Diameter Server responds to the LMA with success status. And then
LMA2 lookup IP address of MAG2 based on the IP address/HNP of MN2 and
respond to the MAG1 with the IP address of MAG2.
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o----------------o | o-------+--------o
Data[MN1->MN2] | | | | |
|------->| | | | | |
|+--------------+| | | | |
||Recipient=LMA2|| | | | |
|+--------------+| | | | |
| | PBU(LR[MN1,MN2]) | | |
| |-------+----------+--------->| | |
| | | |AAR(Service Type,MN1) |
| | | |<-------- | | |
| | | | AAA | | |
| | | |--------->| | |
| | |PBA(LR[MAG2]) | | |
| |<--------------------------- | | |
| | MAGs PBU/PBA exchange | | |
| |<----------------------------------->| |
| | | |
| |===================================->| |
| | | | | |------->|
| | | | | |Data[MN2->MN1]
|<------ |<-===================================|<-------|
| | | | | | |
Figure 5: Diameter Server Authorize MAG Location Query
6. Security Considerations
The security considerations for ther Diameter NASREQ [RFC4005] and
Diameter Proxy Mobile IPv6 applications [I-D.ietf-dime-pmip6] are
applicable to this document.
The service authorization solicited by the MAG or the LMA can rely on
the existing trust relationship between the MAG/LMA and the AAA
server.
Wu, et al. Expires April 22, 2010 [Page 10]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
7. IANA considerations
TBD
8. Acknowledgments
The authors would like to thank all colleagues for their review and
comments of this draft.
9. References
9.1. Normative References
[I-D.ietf-dime-pmip6]
Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A.,
and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access
Gateway and Local Mobility Anchor Interaction with
Diameter Server", draft-ietf-dime-pmip6-04 (work in
progress), September 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. Informative References
[I-D.ietf-netext-pmip6-lr-ps]
Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized
Routing Problem Statement",
draft-ietf-netext-pmip6-lr-ps-00 (work in progress),
September 2009.
Wu, et al. Expires April 22, 2010 [Page 11]
Internet-Draft AAA Support for MAG/LMA Locating October 2009
Authors' Addresses
Qin Wu
Huawei Technologies Co., Ltd.
Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
Nanjing, JiangSu 210001
China
Phone: +86-25-84565892
Email: Sunseawq@huawei.com
Jinwei Xia
Huawei Technologies Co., Ltd.
Huihong Mansion, No.91 Baixia Rd.
Nanjing, Jiangsu 21001
China
Phone: +86-025-8456-5890
Yungui Wang
Huawei Technologies Co., Ltd.
Huihong Mansion, No.91 Baixia Rd.
Nanjing, Jiangsu 21001
China
Phone: +86-025-8456-5893
Glen Zorn (editor)
Network Zen
1310 East Thomas Street
Seattle, Washington 98102
+1 (206) 377-9035
Email: gwz@net-zen.net
Wu, et al. Expires April 22, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 02:45:12 |