Diameter Support for Proxy
Mobile IPv6 Localized Routing
draft-ietf-dime-pmip6-lr-01
Abstract
In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by 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:
- The usage of local routing must be authorized for both MAGs
and
- The address of the MAG to which the Correspondent Node (CN) is
attached must be ascertained
This document specifies how to accomplish these tasks using
the Diameter protocol.
Status of this Memo
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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.”
This Internet-Draft will expire on November 26, 2010.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1.
Introduction
2.
Solution Overview
3.
Localized Routing Service Authorization
4.
Diameter Server Authorizes MAG Location Query
5.
Local Routing Service Authorization in Networks with Multiple AAA Servers
6.
Security Considerations
7.
IANA Considerations
8.
Contributors
9.
References
9.1.
Normative References
9.2.
Informative References
§
Authors' Addresses
1.
Introduction
Proxy Mobile IPv6 (PMIPv6) (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) [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
in which the MN and CN are connected to different MAGs and are
registered to different LMAs. In this scenario (as described in (Liebsch, M., Jeong, S., and W. Wu, “PMIPv6 Localized Routing Problem Statement,” January 2010.) [I‑D.ietf‑netext‑pmip6‑lr‑ps]), the
relevant information needed to set up a localized routing path (e.g.,
the addresses of 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 identify the LMA that is managing
the Correspondent Node's traffic and then obtain the address of the
Correspondent Node's MAG from that LMA. In Proxy Mobile IPv6, the LMA to
be assigned to the CN may be maintained as a configured entry in the
Correspondent Node's policy profile located on an Authentication,
Authorization and Accounting (AAA) server. However, there is no relevant
work discussing how AAA-based mechanisms can be used by the Mobile
Node's MAG to discover the address of the Correspondent Node's LMA
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] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) 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 Correspondent Node's LMA
will respond to the Mobile Node's MAG with the address of the
Correspondent Node's MAG.
2.
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 LMA and the AAA server.
Figure 1 (Local Routing Service Authorization Reference Architecture) shows the reference architecture for
Local Routing Service Authorization. This reference architecture assumes
- MN1 and MN2 belong to different LMAs
- the MAG and LMA support Diameter client functionality
+---------+
LMA2? | AAA & |
+------>| Policy |<----------+
| | Profile | |
Diameter +---------+ Diameter
AAA('a') AAA('b')
LMA2? +--+-+ +----+ |
+------->|LMA1| +----->|LMA2|<-------+
| +----+ | +----+
| | | |
| // | \\
PMIP // 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
according to the extension specified in this document considers the
follows features:
- a.
- The 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 ('a' in (Local Routing Service Authorization Reference Architecture))
- b.
- LMA2 interaction with the AAA server is used to determine whether
MAG1 is allowed to obtain the IP address of MAG2 ('b' in (Local Routing Service Authorization Reference Architecture))
3.
Localized Routing Service Authorization
Figure 2 (MAG-initiated Localized Routing Authorization) shows a scenario where MAG1 acts as a
Diameter client, processing the data packet from MN1 to MN2 and
requesting authorization of localized routing. In this scenario, MN1 and
MN2 are anchored to LMA1 and LMA2 respectively. In order to setup a
localized routing path with MAG2, MAG1 must first locate the entity that
maintains the data required to setup the path (i.e., LMA2) by sending a
Local Routing Optimization Request message ([I‑D.wu‑netext‑local‑ro] (Wu, W. and B. Sarikaya, “An Extension to Proxy Mobile IPv6 for Local Routing Optimization,” February 2010.)) to LMA1. Note that the
discovery of LMA2 is only done once; upon LMA1 know LMA2 address from
AAA serer, LMA1 may associate LMA2 address with MN’s data for future use
(e.g., handover case). The Diameter client in LMA1 sends an AA-Request
(AAR) message to the Diameter server. The message contains an instance
of the MIP6-Feature-Vector (MFV) AVP ([RFC5447] (Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, “Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction,” February 2009.),
Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit Section 7 (IANA Considerations) set and an instance of the MIP6-Home-Link-Prefix
AVP ([RFC5447] (Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, “Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction,” February 2009.), Section 4.2.4) containing the IP
address of MN2.
The Diameter server checks if
localized routing is allowed between MAG1 and MAG2 and if so, responds
with an AA-Answer (AAA) message encapsulating an instance of the
MIP6-Agent-Info AVP [RFC5779] (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,” February 2010.)
containing the IP address and/or Fully Qualified Domain Name (FQDN) of
LMA2. LMA1 then determines the IP address of LMA2 using the data
returned in the MIP6-Agent-Info and responds to MAG1 with the address of
LMA2. MAG1 then requests the address of MAG2 from LMA2 and uses that
address to setup the localized routing path between itself and MAG2 via
a Proxy Binding Update (PBU)/Proxy Binding Acknowledgement (PBA) message
exchange [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.).
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o------------------o | o-------+--------o
Data[MN1->MN2] | | | | |
|------->|LROREQ(MN2) | | | |
| |-------->| | | | |
| | | AAR(MN2,MFV) | | |
| | |--------->| | | |
| | | AAA(LMA2) | | |
| LRORSP(LMA2)<---------| | | |
| |<--------| | | | |
| | | | | |
Figure 2: MAG-initiated Localized Routing Authorization
|
Figure 3 (LMA-initiated Localized Routing Authorization ) shows another scenario, in which
the LMA1 acts as a Diameter client, processing the data packet from MN1
to MN2 and requesting the authorization 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 (MAG-initiated Localized Routing Authorization), the
difference is that it is LMA1 instead of MAG1 which initiates the setup
of the localized routing path.
The Diameter
client in LMA1 sends an AA-Request (AAR) message to the Diameter server.
The message contains an instance of the MIP6-Feature-Vector AVP ([RFC5447] (Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, “Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction,” February 2009.), Section 4.2.5) with the
INTER_MAG_ROUTING_SUPPORTED bit set and an instance of the
MIP6-Home-Link-Prefix AVP ([RFC5447] (Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, “Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction,” February 2009.), Section
4.2.4) containing the IP address of MN2. The Diameter server checks if
localized routing is allowed between MAG1 and MAG2 and if so, responds
with an AA-Answer (AAA) message encapsulating an instance of the
MIP6-Agent-Info AVP [RFC5779] (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,” February 2010.)
containing the IP address and/or Fully Qualified Domain Name (FQDN) of
LMA2. LMA1 then determines the IP address of LMA2 using the data
returned in the MIP6-Agent-Info AVP and forwards it to MAG1 in the Local
Routing Optimization message ([I‑D.wu‑netext‑local‑ro] (Wu, W. and B. Sarikaya, “An Extension to Proxy Mobile IPv6 for Local Routing Optimization,” February 2010.)).
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o--------+-------o Data[MN2->MN1] o-------+--------o
| | |<----- | | | |
| | |AAR(MFV,MN2) | | |
| | |--------->| | | |
| LROREQ |AAA(LMA2) | | | |
| (MN2,LMA2)|<---------| | | |
| |<------| | | | |
| LRORSP(Succ) | | | |
| |------>| | | | |
Figure 3: LMA-initiated Localized Routing Authorization
|
Figure 4 (LMA-initiated Localized Routing Authorization) shows another scenario, similar
to the scenario of Figure 3 (LMA-initiated Localized Routing Authorization ), the LMA1 does not
respond to MAG1 with LMA2 address, instead,setup localized routing path
directly between itself and LMA2 via localized routing signaling.
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o--------+-------o Data[MN2->MN1] o-------+--------o
| | |<----- | | | |
| | |AAR(MFV,MN2) | | |
| | |--------->| | | |
| | |AAA(LMA2) | | | |
| | |<---------| | | |
| | Localized routing setup | |
| | |<------------------->| | |
Figure 4: LMA-initiated Localized Routing Authorization
|
4.
Diameter Server Authorizes MAG Location Query
Figure 5 (Diameter Server Authorizes MAG Location Query) shows a scenario in which LMA2 acts as a
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 an upstream data packet, MAG1
needs to determine the recipient of localized routing, i.e., LMA2. And
then MAG1 solicits LMA2 to look up the IP address of the MAG to which
MN2 is currently attached (in this case, MAG2) by sending a Local
Routing Optimization Request message containing the IP addresses/HNPs of
MN1 and MN2. LMA2 validates the request from MAG1 by sending an AAR to
the AAA server containing the IP address/HNP of MN1 (encapsulated in an
instance of the MIP6-Home-Link-Prefix AVP) and an instance of the
MIP6-Feature-Vector AVP ([RFC5447] (Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, “Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction,” February 2009.), Section 4.2.5)
with the INTER_MAG_ROUTING_SUPPORTED bit set. If the authorization is
successful, LMA2 then looks up the IP address of MAG2 based on the IP
address/HNP of MN2 and responds to 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|| | | | |
|+--------------+| | | | |
| | LRREQ[MN1,MN2]) | | |
| |-------+----------+--------->| | |
| | | |AAR(MFV,MN1) | |
| | | |<-------- | | |
| | | | AAA | | |
| | | |--------->| | |
| | LRRSP[MAG2]) | | |
| |<--------------------------- | | |
| | Localized routing setup | |
| |<----------------------------------->| |
| | | |
| |===================================->| |
| | | | | |------->|
| | | | | Data[MN2->MN1]
|<------ |<-===================================|<-------|
| | | | | | |
Figure 5: Diameter Server Authorizes MAG Location Query
|
5.
Local Routing Service Authorization in Networks with Multiple AAA Servers
+------------------------------------+
( AAA )
( +--------+ Backend )
( |Redirect| )
( | Agent | )
( +--------+ )
( ^ )
( | )
( | )
( v )
( +---------+ +---------+ )
+---->| AAA1 & | | AAA2 & |<---+
| ( | Policy |<-------->| Policy | ) |
| ( | Profile | | Profile | ) |
| ( +---------+ +---------+ ) |
| ( ^ ^ ) |
| +----- | ------------------- |-------+ |
| A1 A2 |
| | | |
| | | |
Diameter v v Diameter
B1 +----+ LMA2 ? +----+ B2
| |LMA1| ------> |LMA2| |
| +----+ +----+ |
| | | |
| // \\ |
| // \\ |
| // \\ |
| | | |
| +----+ +----+ |
+---->|MAG1| |MAG2|<----+
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 6: Use of a Diameter Redirect Agent to Support Local Routing Service Authorization in Networks with Multiple AAA servers
|
Referring to an architecture with multiple AAA servers (as
illustrated in Figure 6 (Use of a Diameter Redirect Agent to Support Local Routing Service Authorization in Networks with Multiple AAA servers)), AAA1 may not maintain the
LMA to be assigned to MN2 as a configured entry in the Correspondent
Node's Policy profile, as AAA2 holds this information in its policy
store. In such a case, AAA1 contacts a Diameter redirect agent [RFC3588]
to request the AAA server being responsible for maintaining MN2's policy
profile. AAA2 checks if localized routing is allowed between MAG1 and
MAG2 and if so, responds with the IP address of LMA2 corresponding to
MN2 and sends the results back to LMA1 via AAA1. Details about the use
of redirect agents in this context are beyond scope of this
document.
6.
Security Considerations
The security considerations for the Diameter
NASREQ (Calhoun, P., Zorn, G., Spence, D., and D. Mitton, “Diameter Network Access Server Application,” August 2005.) [RFC4005] and Diameter Proxy
Mobile IPv6 (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,” February 2010.) [RFC5779] applications are also applicable to this document.
The service authorization solicited by the MAG
or the LMA relies upon the existing trust relationship between the
MAG/LMA and the AAA server.
7.
IANA Considerations
This specification specifies a new value in the Mobility Capability
registry [RFC5447] (Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, “Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction,” February 2009.) for use with the
MIP6-Feature-Vector AVP: INTER_MAG_ROUTING_SUPPORTED
(0x0000080000000000).
8.
Contributors
Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early
versions of this document.
9.
References
9.1. Normative References
| [RFC3588] |
Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” RFC 3588, September 2003 (TXT). |
| [RFC4005] |
Calhoun, P., Zorn, G., Spence, D., and D. Mitton, “Diameter Network Access Server Application,” RFC 4005, August 2005 (TXT). |
| [RFC5213] |
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” RFC 5213, August 2008 (TXT). |
| [RFC5447] |
Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, “Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction,” RFC 5447, February 2009 (TXT). |
| [RFC5779] |
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,” RFC 5779, February 2010 (TXT). |
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-02 (work in progress), January 2010 (TXT). |
| [I-D.wu-netext-local-ro] |
Wu, W. and B. Sarikaya, “An Extension to Proxy Mobile IPv6 for Local Routing Optimization,” draft-wu-netext-local-ro-05 (work in progress), February 2010 (TXT). |
Authors' Addresses
| |
Glen Zorn (editor) |
| |
Network Zen |
| |
1463 East Republican Street |
| |
#358 |
| |
Seattle, Washington 98112 |
| |
USA |
| Email: |
gwz@net-zen.net |
| | |
| |
Qin Wu (editor) |
| |
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 |
| | |
| |
Marco Liebsch |
| |
NEC Europe Ltd. |
| |
NEC Europe Ltd. |
| |
Kurfuersten-Anlage 36 |
| |
Heidelberg, 69115 |
| |
Germany |
| Email: |
liebsch@nw.neclab.eu |
| | |
| |
Jouni Korhonen |
| |
Nokia Siemens Networks |
| |
Linnoitustie 6 |
| |
Espoo FI-02600, |
| |
Finland |
| Email: |
jouni.nospam@gmail.com |