Network Working Group G. Zorn
Internet-Draft Network Zen
Intended status: Standards Track Q. Wu
Expires: September 15, 2011 Huawei
M. Liebsch
NEC
J. Korhonen
NSN
March 14, 2011
Diameter Support for Proxy Mobile IPv6 Localized Routing
draft-ietf-dime-pmip6-lr-03
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:
1. The usage of localized routing must be authorized for both MAGs
and
2. 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."
Zorn, et al. Expires September 15, 2011 [Page 1]
Internet-Draft PMIP6 Localized Routing Support March 2011
This Internet-Draft will expire on September 15, 2011.
Copyright Notice
Copyright (c) 2011 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.
Zorn, et al. Expires September 15, 2011 [Page 2]
Internet-Draft PMIP6 Localized Routing Support March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Localized Routing Service Authorization . . . . . . . . . . . 6
4. Diameter Server Authorizes MAG Location Query . . . . . . . . 8
5. Localized Routing Service Authorization in Networks with
Multiple AAA Servers . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. draft-ietf-dime-pmip6-lr-03 . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Zorn, et al. Expires September 15, 2011 [Page 3]
Internet-Draft PMIP6 Localized Routing Support March 2011
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 in
which the MN and CN are connected to different MAGs and are
registered 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 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 or LMA 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 or LMA
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
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 shows the reference architecture for Localized
Zorn, et al. Expires September 15, 2011 [Page 4]
Internet-Draft PMIP6 Localized Routing Support March 2011
Routing Service Authorization. This reference architecture assumes
o MN1 and MN2 belong to different LMAs or the same LMA.
o 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: Localized 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 interaction of LMA1 with the AAA server is used to authorize
the localized routing service and, if necessary, fetch the IP
address of LMA2 ('a' in (Figure 1))
b. LMA2 interaction with the AAA server is used to determine whether
MAG1 or LMA1 is allowed to obtain the IP address of MAG2 ('b' in
(Figure 1))
Note that if MN1 and MN2 are connected to different MAGs but share
the same LMA the interaction between LMA1 interaction and the AAA
server should be exactly the same as when MNs belong to MAGs under
different LMAs.
Zorn, et al. Expires September 15, 2011 [Page 5]
Internet-Draft PMIP6 Localized Routing Support March 2011
3. Localized Routing Service Authorization
Figure 2 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 Localized Routing Optimization Request message to LMA1.
Note that the discovery of LMA2 is only done once; once LMA1 has
obtained the address of LMA2 from AAA serer, LMA1 may associate
address of LMA2 with the Mobile Node's cached data for future use
(e.g., in the case of a handover). 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],
Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit (Section 7)
set and an instance of the MIP6-Home-Link-Prefix AVP ([RFC5447],
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]
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 can verify whether both MAGs are under the same LMA by
comparing LMA1 address with LMA2 address. 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].
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|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)<---------| | | |
| |<--------| | | | |
| | | | | |
Zorn, et al. Expires September 15, 2011 [Page 6]
Internet-Draft PMIP6 Localized Routing Support March 2011
Figure 2: MAG-initiated Localized Routing Authorization
Figure 3 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, 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], Section 4.2.5) with the
INTER_MAG_ROUTING_SUPPORTED bit set and an instance of the MIP6-Home-
Link-Prefix AVP ([RFC5447], 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] 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 Localized Routing Optimization message.
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|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 shows another scenario, similar to the scenario illustrated
in Figure 3, LMA1 does not respond to MAG1 with the address of LMA2,
instead setting up a localized routing path directly between itself
and LMA2 via localized routing signaling.
Zorn, et al. Expires September 15, 2011 [Page 7]
Internet-Draft PMIP6 Localized Routing Support March 2011
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|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
Note that Localized Routing Service Authorization also can happen
during the network access authentication procedure [RFC5779],i.e.,
before Localized routing is initialized. In this case, the
preauthorized pairs of LMA/prefix sets can be downloaded to Proxy
Mobile IPv6 entities during RFC5779 procedure. Localized routing can
be initiated once a destination of received packet matches to some of
the prefixes received during RFC5779 procedure.
4. Diameter Server Authorizes MAG Location Query
Figure 5 shows a scenario in which LMA2 acts as a Diameter client,
receiving location request and requesting authorization for MAG
location Query. In this scenario, MN1 and MN2 are anchored to LMA1
and LMA2 respectively. MAG1 or LMA1 has already known the recipient
of localized routing is LMA2. MAG1 or LMA may solicit LMA2 to look
up the IP address of the MAG to which MN2 is currently attached (in
this case, MAG2) by sending a Localized 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], 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 or LMA1 with the IP address
of MAG2.
Zorn, et al. Expires September 15, 2011 [Page 8]
Internet-Draft PMIP6 Localized Routing Support March 2011
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o----------------o | o-------+--------o
Data[MN1->MN2] | | | | |
|------->| | | | | |
| | LRREQ([LMA1],MN1,MN2 ) | | |
| |-------+----------+--------->| | |
| | LRREQ(MN1,MN2) | | |
| | +----------+--------->| | |
| | | |AAR(MFV,MN1) | |
| | | |<-------- | | |
| | | | AAA(LMA1)| | |
| | | |--------->| | |
| | LRRSP(MAG2 ) | | |
| |<--------------------------- | | |
| | | LRRSP(MAG2) | | |
| | |-------------------- | | |
| | Localized routing setup | |
| |<----------------------------------->| |
| | | |
| |===================================->| |
| | | | | |------->|
| | | | | Data[MN2->MN1]
|<------ |<-===================================|<-------|
| | | | | | |
Figure 5: Diameter Server Authorizes MAG Location Query
Zorn, et al. Expires September 15, 2011 [Page 9]
Internet-Draft PMIP6 Localized Routing Support March 2011
5. Localized 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 Localized
Routing Service Authorization in Networks with Multiple AAA servers
Referring to an architecture with multiple AAA servers (as
illustrated in Figure 6), 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
Zorn, et al. Expires September 15, 2011 [Page 10]
Internet-Draft PMIP6 Localized Routing Support March 2011
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 [RFC4005] and
Diameter Proxy Mobile IPv6 [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] 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. Change Log
9.1. draft-ietf-dime-pmip6-lr-03
The following are the major changes compared to previous version 02:
o Allow return the LMA address in all cases.
o Using localized routing for terminology consistency.
o Allow localized routing service authorization before localized
routing is initialized.
o Treat MAGs under the different LMA in the same way as the MAGs
under the same LMA.
Zorn, et al. Expires September 15, 2011 [Page 11]
Internet-Draft PMIP6 Localized Routing Support March 2011
o Get rid of references to individual drafts and only get alignment
with Localized routing PS document.
10. References
10.1. Normative References
[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.
[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.
[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.
10.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-05 (work in progress),
February 2011.
[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.
Zorn, et al. Expires September 15, 2011 [Page 12]
Internet-Draft PMIP6 Localized Routing Support March 2011
Authors' Addresses
Glen Zorn
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-040-4617
Email: gwz@net-zen.net
Qin Wu
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 21001
China
Phone: +86-25-84565892
Email: sunseawq@huawei.com
Marco Liebsch
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
Zorn, et al. Expires September 15, 2011 [Page 13]
