One document matched: draft-ietf-dime-pmip6-lr-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5213 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY rfc3588 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY I-D.ietf-dime-pmip6 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-pmip6-04.xml">
<!ENTITY rfc4005 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.xml">
<!ENTITY rfc5447 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5447.xml">
<!ENTITY I-D.ietf-netext-pmip6-lr-ps PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netext-pmip6-lr-ps.xml">
<!ENTITY I-D.wu-netext-local-ro PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wu-netext-local-ro.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-dime-pmip6-lr-00" ipr="trust200902">
<front>
<title abbrev="PMIP6 Localized Routing Support">Diameter Support for Proxy Mobile IPv6 Localized Routing</title>
<author fullname="Glen Zorn" initials="G." surname="Zorn" role="editor">
<organization abbrev="Network Zen">Network Zen</organization>
<address>
<postal>
<street>1463 East Republican Street</street>
<street>#358</street>
<city>Seattle</city>
<region>Washington</region>
<code>98112</code>
<country>USA</country>
</postal>
<email>gwz@net-zen.net</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu" role="editor">
<organization abbrev="Huawei">Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.</street>
<city>Nanjing</city>
<region>JiangSu</region>
<code>210001</code>
<country>China</country>
</postal>
<phone>+86-25-84565892</phone>
<email>Sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Marco Liebsch" initials="M." surname="Liebsch ">
<organization abbrev="NEC">NEC Europe Ltd.</organization>
<address>
<postal>
<street>NEC Europe Ltd.</street>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<region></region>
<code>69115</code>
<country>Germany</country>
</postal>
<email>liebsch@nw.neclab.eu</email>
</address>
</author>
<author fullname="Jouni Korhonen" initials="J." surname="Korhonen ">
<organization abbrev="NSN">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo FI-02600</city>
<region></region>
<code></code>
<country>Finland</country>
</postal>
<email>jouni.nospam@gmail.com</email>
</address>
</author>
<date year="2010" />
<abstract>
<t>
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:
<list style="numbers">
<t>
The usage of local routing must be authorized for both MAGs
and
</t>
<t>
The address of the MAG to which the Correspondent Node (CN) is
attached must be ascertained
</t>
</list>
This document specifies how to accomplish these tasks using the
Diameter protocol.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="RFC5213">Proxy Mobile IPv6 (PMIPv6)</xref>
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 (<xref target="I-D.ietf-netext-pmip6-lr-ps">as
described in</xref>), 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.
<vspace blankLines="1" />
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.
<vspace blankLines="1" />
This document describes AAA
support for the authorization and discovery of PMIPv6 mobility entities
during localized routing. In LMA discovery, Diameter
<xref target="RFC3588"></xref>
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.
</t>
</section>
<section title="Terminology">
<t>
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
<xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Solution Overview">
<t>
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.
<xref target="ref_arch"></xref> shows the reference architecture for
Local Routing Service Authorization. This reference architecture assumes
<list style="symbols">
<t>
MN1 and MN2 belong to different LMAs
</t>
<t>
the MAG and LMA support Diameter client functionality
</t>
</list>
<figure align="center" anchor="ref_arch" title="Local Routing Service Authorization Reference Architecture"><artwork><![CDATA[
+---------+
LMA2? | AAA & |
+------>| Policy |<----------+
| | Profile | |
Diameter +---------+ Diameter
AAA(a) AAA(b)
LMA2? +--+-+ +----+ |
+------->|LMA1| +----->|LMA2|<-------+
| +----+ | +----+
| | | |
| // | \\
PMIP // PMIP \\
| // | \\
| | | |
| +----+ MAG2? | +----+
+---->|MAG1|<--------+ |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
]]></artwork></figure>
The interaction of the MAG and LMA with the AAA server is a
two step procedure involving
<list style="letters">
<t>
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 (<xref target="ref_arch">step 'a' in</xref>)
</t>
<t>
LMA2 interaction with the AAA server is used to determine whether
MAG1 is allowed to obtain the IP address of MAG2
(<xref target="ref_arch">step 'b' in</xref>)
</t>
</list>
</t>
</section>
<section title="Localized Routing Service Authorization">
<t>
<xref target="fig2"></xref> 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
(<xref target="I-D.wu-netext-local-ro"></xref>)
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
(<xref target="RFC5447"></xref>, Section 4.2.5) with the INTER_MAG_ROUTING_SUPPORTED bit <xref target="IANA"/>
set
and an instance of the MIP6-Home-Link-Prefix AVP
(<xref target="RFC5447"></xref>, Section 4.2.4) containing the IP
address of MN2.
<vspace blankLines="1" />
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 <xref target="I-D.ietf-dime-pmip6"></xref>
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
<xref target="RFC5213"></xref>.
<figure anchor="fig2" title="MAG-initiated Localized Routing Authorization"><artwork><![CDATA[
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|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) | | | |
| |<--------| | | | |
| | PBU(LR[MN1,MN2]) | | |
| |---------+----------+------->| | |
| | PBA(LR[MAG2]) | | |
| |<--------+----------+--------| | |
| | MAGs PBU/PBA exchange| | |
| |<--------+----------+--------------->| |
| | | Data[MN1->MN2] | | |
| |=========|==========|==============->|------->|
| | | Data[MN2->MN1] | | |
|<-------|<========|==========|================|<-------|
| | | | | | |
]]></artwork></figure>
<xref target="fig3"></xref>
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 <xref target="fig2"/>,
the difference is that
it is LMA1 instead of MAG1 which initiates the setup of the localized routing path.
<vspace blankLines="1" />
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 (<xref target="RFC5447"></xref>, Section 4.2.5)
with the INTER_MAG_ROUTING_SUPPORTED bit set and an instance
of the MIP6-Home-Link-Prefix AVP
(<xref target="RFC5447"></xref>, 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
<xref target="I-D.ietf-dime-pmip6"></xref>
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
(<xref target="I-D.wu-netext-local-ro"/>).
<figure align="center" anchor="fig3" title="LMA-initiated Localized Routing Authorization"><artwork><![CDATA[
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|MN1| |MAG1| |LMA1| |AAA| |LMA2| |MAG2| |MN2|
+-+-+ +-+--+ +-+--+ +-+-+ +-+--+ +-+--+ +-+-+
| | | | | | |
| Anchored | | | Anchored |
o--------+-------o | o-------+--------o
| Data[MN2->MN1] | | | | |
|--------+------>| | | | |
| | |AAR(MN2,MFV) | | |
| | |--------->| | | |
| | |AAA(LMA2) | | | |
| | |<---------| | | |
| LROREQ(MN2,LMA2) | | | |
| |<------| | | | |
| LRORSP(Succ) | | | |
| |------>| | | | |
| | | PBU(LR[MN1,MN2]) | | |
| |---------------------------->| | |
| | | PBA(LR[MAG2]) | | |
| |<----------------------------| | |
| | | MAGs PBU/PBA exch | | |
| |<----------------------------------->| |
|Data[MN1->MN2] | |
|------->|====================================>|------->|
| | | | | | |
| | | | | Data[MN2->MN1]|
|<-------|<====================================|<-------|
| | | | | | |
]]></artwork></figure>
</t>
</section>
<section title="Diameter Server Authorizes MAG Location Query">
<t>
<xref target="fig4"></xref> 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 (<xref target="RFC5447"></xref>, 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.
<figure align="center" anchor="fig4" title="Diameter Server Authorizes MAG Location Query"><artwork><![CDATA[
+---+ +----+ +----+ +---+ +----+ +----+ +---+
|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]
|<-------|<====================================|<-------|
| | | | | | |
]]></artwork></figure>
</t>
</section>
<section title="Local Routing Service Authorization in Networks with Multiple AAA Servers">
<figure align="left" anchor="fig5" title="Use of a Diameter Redirect Agent to Support Local Routing Service Authorization in Networks with Multiple AAA servers"><artwork><![CDATA[
+------------------------------------+
( 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|
+---+ +---+
]]></artwork></figure>
<t>
Referring to an architecture with multiple AAA servers (as illustrated in
<xref target="fig5"></xref>), 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.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The security considerations for the
<xref target="RFC4005">Diameter NASREQ</xref> and
<xref target="I-D.ietf-dime-pmip6">Diameter Proxy Mobile IPv6</xref>
applications are also applicable to this document.
<vspace blankLines="1"/>
The service authorization solicited by the MAG or the LMA relies upon
the existing trust relationship between the MAG/LMA and the AAA server.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This specification specifies a new value in the Mobility Capability
registry <xref target="RFC5447"/> for use with the MIP6-Feature-Vector AVP: INTER_MAG_ROUTING_SUPPORTED (0x0000080000000000).
</t>
</section>
<section title="Contributors">
<t>
Paulo Loureiro, Jinwei Xia and Yungui Wang all contributed to early versions of this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&I-D.ietf-dime-pmip6;
&rfc3588;
&rfc5213;
&rfc4005;
&rfc5447;
</references>
<references title="Informative References">
&I-D.ietf-netext-pmip6-lr-ps;
&I-D.wu-netext-local-ro;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:31 |