Network Working Group G. Zorn
Internet-Draft Network Zen
Intended status: Standards Track Q. Wu
Expires: August 16, 2012 Huawei
M. Liebsch
NEC
J. Korhonen
NSN
February 13, 2012
Diameter Support for Proxy Mobile IPv6 Localized Routing
draft-ietf-dime-pmip6-lr-09
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 between an MN's MAG and the MAG of its Correspondent Node
(CN) without involving any 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 August 16, 2012 [Page 1]
Internet-Draft PMIP6 Localized Routing Support February 2012
This Internet-Draft will expire on August 16, 2012.
Copyright Notice
Copyright (c) 2012 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 August 16, 2012 [Page 2]
Internet-Draft PMIP6 Localized Routing Support February 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 6
4.1. MIP6-Agent-Info AVP . . . . . . . . . . . . . . . . . . . 6
4.2. PMIP6-IPv4-Home-Address AVP . . . . . . . . . . . . . . . 6
4.3. MIP6-Home-Link-Prefix AVP . . . . . . . . . . . . . . . . 6
4.4. MIP6-Feature-Vector AVP . . . . . . . . . . . . . . . . . 6
5. Example Signaling flows . . . . . . . . . . . . . . . . . . . 7
5.1. Localized Routing Service Authorization . . . . . . . . . 7
5.2. Diameter Server Authorizes MAG Location Query . . . . . . 11
6. Localized Routing Service Authorization in Networks with
Multiple AAA Servers . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Zorn, et al. Expires August 16, 2012 [Page 3]
Internet-Draft PMIP6 Localized Routing Support February 2012
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 scenarios in
which the MN and CN are connected to different MAGs and are
registered to the same LMA or different LMAs. In these scenarios (as
described in [RFC6279]), 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 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 [I-D.ietf-dime-rfc3588bis] 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. 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].
Zorn, et al. Expires August 16, 2012 [Page 4]
Internet-Draft PMIP6 Localized Routing Support February 2012
3. Solution Overview
MAG/LMA discovery 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
Routing Service Authorization. This reference architecture assumes
o MN1 and MN2 belong to different LMAs or the same LMA. If MN1 and
MN2 belong to the same LMA, the LMA1 and LMA2 to which MN1 and MN2
are anchored in Figure 1 should be the same LMA. If MN1 and MN2
belong to different LMAs, LMA1 and LMA2 in Figure 1 are in the
same provider domain (as described in [RFC6279]).
o The MAG and LMA support Diameter client functionality.
+---------+
LMA2? | AAA & |
+------>| Policy |<----------+
| | Profile | |
Diameter +---------+ Diameter
(Step a) (Step b)
| |
| |
| |
LMA2? +--V-+ +----+ |
+------->|LMA1| |LMA2|<-------+
| +----+ +----+
| | |
| // \\
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
Zorn, et al. Expires August 16, 2012 [Page 5]
Internet-Draft PMIP6 Localized Routing Support February 2012
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 (Step 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 (Step b
in Figure 1)
Note that if MN1 and MN2 are connected to different MAGs but share
the same LMA, the interaction between LMA1 and the AAA server should
be exactly the same as the case where MNs belong to MAGs under
different LMAs.
4. Attribute Value Pair Definitions
This section describes Attribute Value Pairs (AVPs) defined by this
specification or re-used from existing specifications in a PMIPv6-
specific way.
4.1. MIP6-Agent-Info AVP
The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in
[RFC5447] and extended in [RFC5779]. This AVP is used to carry LMA
addressing in the AA-Answer (AAA) message [I-D.ietf-dime-rfc4005bis].
4.2. PMIP6-IPv4-Home-Address AVP
The PMIP6-IPv4-Home-Address AVP (AVP Code 505) is defined in
[RFC5779]. This AVP is used to carry the IPv4-MN-HoA [RFC5844] in
the AA-Request (AAR) message [I-D.ietf-dime-rfc4005bis] from the LMA
to the home AAA server (HAAA).
4.3. MIP6-Home-Link-Prefix AVP
The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779].
This AVP is used to carry the MN-HNP (if available) in the AAR from
the LMA to the HAAA.
4.4. MIP6-Feature-Vector AVP
The MIP6-Feature-Vector AVP is defined in [RFC5447]. This document
allocates a new capability flag bit according to the IANA rules in
RFC 5447.
INTER_MAG_ROUTING_SUPPORTED (TBD)
Zorn, et al. Expires August 16, 2012 [Page 6]
Internet-Draft PMIP6 Localized Routing Support February 2012
Direct routing of IP packets between MNs anchored to different
MAGs without involving any LMA is supported. This bit is used
with MN-HNP or IPv4-MN-HoA. When a LMA sets this bit in the MIP6-
Feature-Vector and MN-HNP or IPv4-MN-HoA corresponding to the
Correspondent Node is carried with this bit, it indicates to the
HAAA that the Mobile Node associated with this LMA is allowed to
use localized routing but the LMA needs to know from the HAAA if
the Correspondent Node is allowed to use localized routing. If
the MN-HNPs or IPv4-MN-HoAs corresponding to both the Mobile Node
and the Correspondent Node are carried with this bit, it indicates
that both the MN and CN are allowed to use localized routing.
Note that localized routing related signaling is required prior to
localized routing. If this bit is cleared in the returned MIP6-
Feature-Vector AVP, the HAAA does not authorize direct routing of
packets between MNs anchored to the different MAG. The LMA MUST
support this policy feature on a per-MN and per-subscription
basis.
5. Example Signaling flows
5.1. Localized Routing Service Authorization
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 the RFC5779 procedure. Localized routing can be
initiated once the destination of a received packet matches one or
more of the prefixes received during RFC5779 procedure.
Figure 2 shows an example scenario where MAG1 acts as a Diameter
client, processing the data packet from MN1 to MN2 and requesting
authorization of localized routing. In this example scenario, MN1
and MN2 are anchored to LMA1 and LMA2 respectively if MN1 and MN2
belong to different LMAs; otherwise, the LMA to which MN1 and MN2 are
anchored should be the same LMA, i.e., either LMA1 or LMA2. In the
case where MNs belong to different LMAs, 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 Request message to LMA1. Note that the discovery of LMA2
is only done once; the request message is the Localized Routing
Initialization (LRI) message in Figure 2 and belongs to the Initial
phase of the localized routing. Once LMA1 has obtained the address
of LMA2 from the AAA server, LMA1 may associate the address of LMA2
with the Mobile Node's cached data for future use (e.g., in case of a
handover). The Diameter client in LMA1 sends an AAR message to the
Diameter server. The message contains an instance of the MIP6-
Zorn, et al. Expires August 16, 2012 [Page 7]
Internet-Draft PMIP6 Localized Routing Support February 2012
Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the
INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set and an instance of
the MIP6-Home-Link-Prefix AVP ([RFC5779], Section 5.3) or an instance
of the PMIP6-IPv4-Home-Address AVP ([RFC5779], Section 5.2)
containing the IP address/HNP of MN2.
The Diameter server authorizes localized routing service by checking
if MN2 is allowed to use localized routing and if LMA2 and LMA1 are
in the same provider domain. If so, the Diameter server responds
with an 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 and an instance of the MIP6-Feature-Vector (MFV)
AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED
bit (Section 4.4) set indicating Direct routing of IP packets between
MNs anchored to different MAGs is supported. LMA1 then determines
the IP address of LMA2 using the data returned in the MIP6-Agent-Info
AVP and responds to MAG1 with the address of LMA2 in the Localized
Routing Acknowledge message (LRA in the Figure 2). If MAG1 knows
that MN1 and MN2 belong to the same LMA, it 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]. Note that
whether MN1 and MN2 belong to the same LMA can be verified by looking
up the binding cache entries corresponding to MN1 and MN2 and
comparing the addresses of LMA1 and LMA2.
In the case where MNs share the same LMA, the MAG1 should send a
request message (LRI in the Figure 2) to the LMA for localized
routing which includes the IP address of MN2. The subsequent
interaction between LMA1 and the AAA should be exactly the same as
the case where the MNs belong to different LMAs. If authorization is
successful, the LMA may look up the address of MAG2 directly based on
IP address of MN2 and send a message to MAG1 with IP address of MAG2
included.
Zorn, et al. Expires August 16, 2012 [Page 8]
Internet-Draft PMIP6 Localized Routing Support February 2012
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o------------------o | o-------+--------o
Data[MN1->MN2] | | | | |
|------->| LRI(MN2)| | | | |
| |-------->| | | | |
| | |AAR(MFV, MN2) | | |
| | |--------->| | | |
| | |AAA(MFV, LMA2) | | |
| LRA([LMA2]) |<---------| | | |
| |<--------| | | | |
| | | | | |
Figure 2: MAG-initiated Localized Routing Authorization
Figure 3 shows another example scenario, in which the LMA1 acts as a
Diameter client, processing the data packet from MN2 to MN1 and
requesting the authorization of localized routing. In this example
scenario, MN1 and MN2 are anchored to LMA1 and LMA2 respectively. In
contrast with the signaling flow of Figure 2, it is LMA1 instead of
MAG1 which initiates the setup of the localized routing path.
The Diameter client in LMA1 sends an AA-Request 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 ([RFC5779], Section 5.3) or an instance of the PMIP6-
IPv4-Home-Address AVP ([RFC5779], Section 5.2) containing the IP
address/HNP of MN2. The Diameter server authorizes localized routing
service by checking if MN2 is allowed to use localized routing and if
LMA2 and LMA1 are in the same domain. If so, the Diameter server
responds with an AA-Answer message encapsulating an instance of the
MIP6-Agent-Info AVP [RFC5779] containing the IP address and/or Fully
Qualified Domain Name (FQDN) of LMA2 and an instance of the MIP6-
Feature-Vector (MFV) AVP ([RFC5447], Section 4.2.5) with the
INTER_MAG_ROUTING_SUPPORTED bit (Section 4.4) set indicating direct
routing of IP packets between MNs anchored to different MAGs is
supported. . LMA1 then determines the IP address of LMA2 using the
data returned in the MIP6-Agent-Info AVP and responds to MAG1 with
the address of LMA2.
In the case where MNs share the same LMA, the Diameter client in LMA1
sends an AA-Request message to the Diameter server. The interaction
between LMA1 and the Diameter server should be exactly the same as
the case where MNs belong to different LMAs. If authorization is
Zorn, et al. Expires August 16, 2012 [Page 9]
Internet-Draft PMIP6 Localized Routing Support February 2012
successful, the LMA may look up the address of MAG2 directly based on
the IP address of MN2 and send a request message (LRI in Figure 3) to
the MAG1 for localized routing with the IP address of MAG2 included.
The MAG1 confirms the success of localized routing if a localized
routing path can be setup.
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o--------+-------o Data[MN2->MN1] o-------+--------o
| | |<----- | | | |
| | |AAR(MFV,MN2) | | |
| | |--------->| | | |
| LRI |AAA(MFV,LMA2) | | |
| (MN2,[LMA2])|<---------| | | |
| |<------| | | | |
| LRA(Succ) | | | | |
| |------>| | | | |
Figure 3: LMA-initiated Localized Routing Authorization
Figure 4 shows another example scenario, similar to the example
scenario illustrated in Figure 3. In this case, however, LMA1 does
not respond to MAG1 with the address of LMA2, instead initiating an
exchange between LMA1 and LMA2 to trigger the corresponding LMA to
setup binding entries on the corresponding MAG for localized routing
and configuring MAG1 and MAG2 to use the same encapsulation mechanism
as that being used for the PMIP tunnel between the MAG and LMA
without special configuration or dynamic tunneling negotiation
between MAGs. Alternatively, special configuration for other
encapsulation mechanisms or dynamic tunneling negotiation may be used
to override the default tunneling.
Zorn, et al. Expires August 16, 2012 [Page 10]
Internet-Draft PMIP6 Localized Routing Support February 2012
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o--------+-------o Data[MN2->MN1] o-------+--------o
| | |<----- | | | |
| | |AAR(MFV,MN2) | | |
| | |--------->| | | |
| | |AAA(MFV,LMA2) | | |
| | |<---------| | | |
| | Localized routing setup | |
| | |<------------------->| | |
Figure 4: LMA-initiated Localized Routing Authorization
5.2. Diameter Server Authorizes MAG Location Query
Figure 5 shows an example scenario in which LMA2 acts as a Diameter
client, receiving a MAG location request and requesting authorization
for a MAG location query from the AAA server. In this example
scenario, MN1 and MN2 may be anchored to LMA1 and LMA2 respectively
or belong to the same LMA. In the case where MNs belong to different
LMAs, MAG1 or LMA1 should already know that the recipient of
localized routing is LMA2. If MAG1 initiates LR, MAG1 may take
Option 1 in Figure 5 and solicit LMA2 to look up the IP address of
the MAG to which MN2 is currently attached (in this case, MAG2)
according to the IP addresses/HNPs of MN2. If LMA1 initiates LR,
LMA1 may take Option 2 in Figure 5 and solicit LMA2 to look up the IP
address of the MAG to which MN2 is currently attached. LMA2
validates the request (LRI in Figure 5) from MAG1 by sending an AAR
to the Diameter server containing the IP address/HNP of MN1
(encapsulated in an instance of the MIP6-Home-Link-Prefix AVP or an
instance of PMIP6-IPv4-Home-Address AVP) and an instance of the MIP6-
Feature- Vector AVP ([RFC5779], Section 5.5) with the
INTER_MAG_ROUTING_SUPPORTED bit set. If the authorization is
successful, the Diameter server responds with an AA-Answer (AAA)
message encapsulating an instance of the MIP6- Feature-Vector (MFV)
AVP ([RFC5447], Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED
bit (Section 4.4) set indicating Direct routing of IP packets between
MNs anchored to the different MAG is supported. 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 August 16, 2012 [Page 11]
Internet-Draft PMIP6 Localized Routing Support February 2012
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o----------------o | o-------+--------o
Data[MN1->MN2] | | | | |
|------->| | | | | |
| | LRI(MN1,MN2 ) | | |
| |-------+----------+--------->|\ | |
| | | | | | | |
| | | AAR(MFV,MN1)|Option 1 |
| | | |<-------- | | | |
| | | AAA(MFV,LMA1)| | | |
| | | |--------->| | | |
| | LRA(MAG2 ) | | | |
| |<--------------------------- |/ | |
| | | | |
| | |LRI(MN1,MN2) |\ | |
| | +----------+--------->| | | |
| | | AAR(MFV,MN1)|Option 2 |
| | | |<-------- | | | |
| | | AAA(MFV,LMA1)| | | |
| | | |--------->| | | |
| | | LRA(MAG2) | | | |
| | |<------------------- |/ | |
| | | | |
| | |Localized routing setup | |
| |<------+---------------------------->| |
| |===================================->| |
| | | | | |------->|
| | | | | Data[MN2->MN1]
|<------ |<-===================================|<-------|
| | | | | | |
Figure 5: Diameter Server Authorizes MAG Location Query
In the case where MNs share the same LMA, LR should be initiated by
LMA1 (i.e., LMA2) since only LMA1 knows that both MN1 and MN2 belong
to itself by looking up the binding cache entries corresponding to
MN1 and MN2. Unlike the case where MNs belong to different LMAs, the
interaction between LMAs in Option 2 is omitted since LMA1 and LMA2
are the same entity. The interaction between LMA1 and the AAA should
be exactly the same as the case where MNs belong to different LMAs.
Zorn, et al. Expires August 16, 2012 [Page 12]
Internet-Draft PMIP6 Localized Routing Support February 2012
6. 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
Zorn, et al. Expires August 16, 2012 [Page 13]
Internet-Draft PMIP6 Localized Routing Support February 2012
[I-D.ietf-dime-rfc3588bis] to request the AAA server being
responsible for maintaining MN2's policy profile. AAA2 checks if MN2
is allowed to use localized routing 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.
7. Security Considerations
The security considerations for the Diameter NASREQ
[I-D.ietf-dime-rfc4005bis] 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.
8. IANA Considerations
This specification defines a new value in the Mobility Capability
registry [RFC5447] for use with the MIP6-Feature-Vector AVP:
INTER_MAG_ROUTING_SUPPORTED (see Section 4.4).
9. Contributors
Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early
versions of this document.
10. Acknowledgements
The authors would like to thank Carlos Jesus Bernardos Cano, Dan
Romascanu, Elwyn Davies and Abhay Roy for their valuable comments and
suggestions on this document.
11. References
11.1. Normative References
[I-D.ietf-dime-rfc3588bis]
Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", draft-ietf-dime-rfc3588bis-29
(work in progress), August 2011.
Zorn, et al. Expires August 16, 2012 [Page 14]
Internet-Draft PMIP6 Localized Routing Support February 2012
[I-D.ietf-dime-rfc4005bis]
Zorn, G., "Diameter Network Access Server Application",
draft-ietf-dime-rfc4005bis-07 (work in progress),
February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
11.2. Informative References
[RFC6279] Liebsch, M., Jeong, S., and Q. Wu, "Proxy Mobile IPv6
(PMIPv6) Localized Routing Problem Statement", RFC 6279,
June 2011.
Authors' Addresses
Glen Zorn
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-040-4617
Email: glenzorn@gmail.com
Zorn, et al. Expires August 16, 2012 [Page 15]
Internet-Draft PMIP6 Localized Routing Support February 2012
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 August 16, 2012 [Page 16]