One document matched: draft-ietf-netext-pmip6-cpc-00.txt
INTERNET-DRAFT Jie Hu
Intended Status: Standards Track Xiao-Ming Guang
Expires: December 30, 2010 China Telecom
June 28, 2010
A central policy controlling based PMIPv6 Solutions
draft-ietf-netext-pmip6-cpc-00.txt
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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.
Guang, et al. Expires December 30, 2010 [Page 1]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
Abstract
This document defines a central policy controlling network-based
mobility management solution through Authentication, Authorization,
Accounting (AAA), and policy controller interactions between Proxy
Mobile IPv6 entities(both Mobile Access Gateway and Local Mobility
Anchor) under an AAA server and policy server group within a Proxy
Mobile IPv6 Domain. The AAA and policy interactions are not only used
to download and update mobile node specific user data information
between Proxy Mobile IPv6 entities and a remote policy store, but
also update the local mobility anchor about the current location of
the mobile node instead of signaling messages between the mobile
access gateway and local mobility anchor.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 MAG-to-AAA interaction . . . . . . . . . . . . . . . . . . 6
2.2 AAA-to-LMA interaction . . . . . . . . . . . . . . . . . . 7
3 Application ID . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Command-Code values . . . . . . . . . . . . . . . . . . . . . . 8
4.1 PMIP6-Userdata-Request(PUR) . . . . . . . . . . . . . . . . 9
4.2 PMIP6-Userdata-Answer(PUA) . . . . . . . . . . . . . . . . 9
4.3 PMIP6-Subscription-Request(PSR) . . . . . . . . . . . . . 10
4.4 PMIP6-Subscription-Answer(PSA) . . . . . . . . . . . . . 10
4.5 PMIP6-Notification-Request (PNR) . . . . . . . . . . . . 10
4.6 PMIP6-Notification-Answer (PNA) . . . . . . . . . . . . . 11
5 Attribute Value Pair Definitions . . . . . . . . . . . . . . . 11
5.1 Proxy Care-of Address AVP . . . . . . . . . . . . . . . . 11
5.2 Handoff-Indicator AVP . . . . . . . . . . . . . . . . . . 11
5.3 Access-Technology-Type AVP . . . . . . . . . . . . . . . 12
5.4 PBU-Timestamp AVP . . . . . . . . . . . . . . . . . . . . 13
5.5 MN-Link-Layer-Identifier AVP . . . . . . . . . . . . . . 13
6 Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13
6.1 SUCCESS . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 Permanent Failures . . . . . . . . . . . . . . . . . . . 13
6.2.1 DIAMETER_ERROR_PMIP_USER_DATA_NOT_RECOGNIZED(XXXX) . 13
6.2.2 DIAMETER_ERROR_PMIP_OPERATION_NOT_ALLOWED (XXXX) . . 13
6.2.3 DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_READ(XXXX) . 14
6.2.4 DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_MODIFIED
(XXXX) . . . . . . . . . . . . . . . . . . . . . . 14
6.2.5 DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_NOTIFIED
(XXXX) . . . . . . . . . . . . . . . . . . . . . . 14
Guang, et al. Expires December 30, 2010 [Page 2]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
6.2.6 DIAMETER_ERROR_PMIP_NO_SUBSCRIPTION_TO_DATA (XXXX) . 14
6.3 Transient Failures . . . . . . . . . . . . . . . . . . . 14
6.3.1 DIAMETER_ERROR_PMIP_USER_DATA_NOT_AVAILABLE(XXXX) . 14
7 Attribute Value Pair Occurrence Tables . . . . . . . . . . . . 14
7.1 MAG-to-AAA interface . . . . . . . . . . . . . . . . . . 14
7.2 AAA-to-LMA interface . . . . . . . . . . . . . . . . . . 15
8 Examples Signaling Flows . . . . . . . . . . . . . . . . . . . 15
8.1 Generic message workflow . . . . . . . . . . . . . . . . 15
8.2 Initial Binding Registration - New Mobility Session . . . 15
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1 Command Codes . . . . . . . . . . . . . . . . . . . . . . 16
9.2 Attribute Value Pair Codes . . . . . . . . . . . . . . . 17
9.3 Result-Code AVP Values . . . . . . . . . . . . . . . . . 17
9.4 Application Identifier . . . . . . . . . . . . . . . . . 17
10 Security Considerations . . . . . . . . . . . . . . . . . . . 17
11 References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1 Normative References . . . . . . . . . . . . . . . . . . 17
11.2 Informative References . . . . . . . . . . . . . . . . . 18
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Guang, et al. Expires December 30, 2010 [Page 3]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
1 Introduction
Proxy Mobile IPv6 (PMIPv6), specified in RFC 5213 [RFC5213] provides
network based mobility management to hosts connecting to a PMIPv6
domain. The mobile access gateway in the network performs the
signaling with the local mobility agent and does the mobility
management on behalf of the mobile node (MN) attached to the
network.The mobile access gateway is responsible for tracking the
mobile node's movement to and from the access link and for signaling
the mobile node's local mobility anchor.
A central policy controlling network-based mobility management
solution is another approach solving the IP mobility challenge. When
an mobile node attaches to a PMIPv6 Domain,the mobile access gateway
on that access link, will obtain and update mobile node's user data
to and from AAA server by its MN-Identifier. A mobile node's user
data contains the type of address, prefixes to be assigned for the
mobile node in the network, the address of local mobility anchor and
the address of mobile access gateway which mobile node connects to.
The exact details on how to achieve MN-identifier is outside the
scope of this document.
If local mobility anchor subscribes to notifications from the AAA of
changes in the specific user data, the AAA will notify an local
mobility anchor of changes in data for which the local mobility
anchor previously had subscribed, and send the user data to the local
mobility anchor. Upon accepting this notify message, the local
mobility anchor will create or update the Binding Cache entry and set
up its endpoint of the bi-directional data tunnel to the mobile
access agent.
In the context of this specification, this protocol would specifies a
central policy controlling network-based mobility management
solution. Diameter [RFC3588] is applied as the AAA and policy
controlling protocol. The application notes in this mechanism are
depicted as the following:
* Mobile Access agent and Local mobility anchor share the same AAA
server and policy server or AAA/policy server group.
* The mobile node's home network prefix(es) is assigned by AAA server
or AAA server group.
The advantages of developing a central policy controlling solution
based on PMIPv6 are:
* Strengthen the network based mobility capability with a central
policy controlling and lower the PMIP entities extra requirements in
Guang, et al. Expires December 30, 2010 [Page 4]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
contrast to normal wireline and wireless broadband access nodes.
* Reduce the signaling load between the Mobile Access agent and Local
mobility anchor. The mobile access gateway and the local mobility
anchor need not implement IPsec for protecting the Proxy Mobile IPv6
signaling messages.
* Reduce the handover delays and the signaling latency and improve
the performance of Mobile IPv6 in terms of handover latency.
* Relax the specific mechanism to make the mobile node's sequence
number available to the serving mobile access gateway prior to
sending the Proxy Binding Update message.
1.1 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].
The general terminology used in this document can be found in
[RFC5213] and [NETLMM-PMIP6]. The following additional or clarified
terms are also used in this document:
Mobile Policy Decision Point (M-PDP)
Mobile Policy Decision Point is the logical entity capable of taking
a policy decision based on a set of policies upon mobile subscription
in a Proxy Mobile IPv6 domain.
When the MAG tries to access or update the mobile node's user data,
it will allocate the M-PDP the job of deciding whether or not to
authorize the user mobility based on the description of the user's
attributes. User data and applicable policies are stored on the
system and are analyzed by the M-PDP. The M-PDP makes its decision
and returns the decision.
The M-PDP is also responsible for handling events and making
decisions based on those events (i.e., changes of data),and updating
the M-PEP configuration appropriately.
Mobile Policy Enforcement Point (M-PEP)
Mobile Policy Enforcement Point is the logical entity which resides
in the MAG or LMA that enforces policies from M-PDP in a Proxy Mobile
IPv6 domain.
Guang, et al. Expires December 30, 2010 [Page 5]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
2 Solution Overview
This document defines Diameter-based AAA interactions between Proxy
Mobile IPv6 entities ( both Mobile Access Gateway and Local Mobility
Anchor ) and an AAA server within a Proxy Mobile IPv6 Domain. Figure
1 shows the participating network entities. This document specifies a
Diameter application for proxy mobility IPv6, mainly contains two
parts:
(1) To download and update user data between MAG and AAA.
(2) To request and send notifications upon the changes on user data
between AAA and LMA.
2.1 MAG-to-AAA interaction
Diameter-based AAA interactions between the MAG and the AAA are used
to obtain mobile node's user data from AAA server,and update the AAA
server with the address of MAG during the MN initial attachment to
the PMIPv6 Domain or movement to a new MAG.
The following are the mandatory fields of the user data:
* The mobile node's identifier (MN-Identifier)
* The IPv6 address of the local mobility anchor (LMAA)
* The IPv6 address of the current Mobile Access Gateway (MAGA)
+-----+
|M-PDP|
+-----+
|
| +---------+
+--------+ Diameter | +-----+ |
| |<-------->| |M-PEP| |
| AAA | | +-----+ |
| | | |
| | | LMA |
+--------+ +---------+
^ |
| // \\
+---|----------------//---\\--------------+
( | IPv4/IPv6 // \\ )
( | Network // \\ )
+---|-------------//---------\\-----------+
Guang, et al. Expires December 30, 2010 [Page 6]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
| // \\
Diameter //<- Data Only \\<- Data Only
| // Tunnel \\ Tunnel
| | |
| +---------+ +---------+
| | +-----+ | | +-----+ |
+---->| |M-PEP| | | |M-PEP| |
| +-----+ | | +-----+ |
| | | |
| MAG1 | | MAG2 |
+---------+ +---------+
| |
| |
[MN1] [MN2]
Figure 1: Proxy Mobile IPv6 Domain Interaction with Diameter AAA
Server
The followings are the optional fields of the user data:
* The mobile node's IPv6 home network prefix(es) assigned to the
mobile node's connected interface. These prefixes have to be
maintained on a per-interface basis. There can be multiple unique
entries for each interface of the mobile node. The specific details
on how the network maintains this association between the prefix set
and the interfaces, specially during the mobility session handoff
between interfaces, is outside the scope of this document.
* The mobile node's IPv6 home network Prefix lifetime. This lifetime
will be the same for all the hosted prefixes on the link, as they all
are part of one mobility session. This value can also be the same
for all the mobile node's mobility sessions.
2.2 AAA-to-LMA interaction
Diameter-based AAA interactions between the AAA and the LMA is used
to request and send notifications upon the changes of user data. This
solution is to enable the MAG update the LMA about the current
location of the mobile node without sending a Proxy Binding Update
message to the mobile node's LMA.
This document specifies a Diameter application for proxy mobility
IPv6 allows a Diameter server and a Diameter client to request and
send notifications upon the changes on user data. The LMA can
Guang, et al. Expires December 30, 2010 [Page 7]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
subscribe the notifications of changes in mobile node's user data
from AAA server. When an MN attaches to a PMIPv6 Domain, the MAG will
determine if the mobile node is authorized for the network-based
mobility management service and update the AAA server with the
address of MAG. The AAA server will notify the LMA changes in user
data for which the LMA previously had subscribed.
After receiving notifications from AAA, LMA updates the current
location of the mobile node, It also creates the Binding Cache entry
and sets up its endpoint of the bi-directional data tunnel to the
mobile access gateway.
3 Application ID
We define a new Diameter application in this document, Diameter
PMIPv6 PBU Application, with an Application Id value of XXX
(allocated by IANA). Diameter nodes conforming to this specification
in the role of PBU server MUST advertise support by including an
Auth-Application-Id AVP with a value of Diameter PMIPv6 PBU
Application in the form of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer commands [RFC3588]. The primary use of
the Diameter PMIPv6 PBU Application Id is to ensure proper routing of
the messages, and that the nodes that advertise the support for this
application do understand the new AVPs defined in section Section 6,
although these AVP have the 'M' flag cleared.
4 Command-Code values
This section defines Command-Code [RFC3588] values that MUST be
supported by all Diameter implementations conforming to this
specification.
The following Command Codes are defined in this specification:
Command-Name Abbrev. Code Reference Application
PMIP6-Userdata-Request PUR XXX RFC XXXX Diameter PMIPv6
PBU
PMIP6-Userdata-Answer PUA XXX RFC XXXX Diameter PMIPv6
PBU
PMIP6-Subscription-Request PSR XXX RFC XXXX Diameter PMIPv6
PBU
PMIP6-Subscription-Answer PSA XXX RFC XXXX Diameter PMIPv6
PBU
Guang, et al. Expires December 30, 2010 [Page 8]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
PMIP6-Notification-Request PNR XXX RFC XXXX Diameter
PMIPv6 PBU
PMIP6-Notification-Answer PNA XXX RFC XXXX Diameter
PMIPv6 PBU
4.1 PMIP6-Userdata-Request(PUR)
The PMIP6-Userdata-Request(PUR) command, indicated by the Command-
Code field set to XXX and the 'R' bit set in the Command Flags field,
is sent by a Diameter client to a Diameter server in order to request
user data.
The MAG sending the PUR message to AAA is to update Proxy Care-of
Address and obtain the user data, including the address of the mobile
node's local mobility anchor, mobile node's home network prefix.
The message format is shown below.
< PMIP6-Userdata-Request> ::=< Diameter Header: XXX, REQ, PXY>
< Session-Id >
{ Vendor-Specific-Application-Id }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*2{ MIP6-Agent-Info}
*{ Mobile-Node-Identifier }
*{ Proxy Care-of Address }
...
*[ AVP ]
4.2 PMIP6-Userdata-Answer(PUA)
The PMIP6-Userdata-Answer (PUA) command, indicated by the Command-
Code field set to XXX and the 'R' bit cleared in the Command Flags
field, is sent by a server in response to the PMIP6-Userdata-Request
command.
If the AAA determines the mobile node is authorized for the network-
based mobility management service and updates user data
successfully,the response MUST include MIP6-Agent-Info AVP.
The message format is shown below.
< PMIP6-Userdata-Answer> ::= < Diameter Header: XXX, PXY >
Guang, et al. Expires December 30, 2010 [Page 9]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
< Session-Id >
{ Vendor-Specific-Application-Id }
{ Result-Code }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*{ Mobile-Node-Identifier }
*2[ MIP6-Agent-Info ]
*[ Proxy Care-of Address ]
...
* [ AVP ]
4.3 PMIP6-Subscription-Request(PSR)
The PMIP6-Subscribe-Request(PSR)command, indicated by the Command-
Code field set to XXX and the 'R' bit set in the Command Flags field,
is sent by a Diameter client to a Diameter server in order to request
notifications of changes in user data.
The LMA send PSR message to AAA to subscribe to receive notifications
of changes in user data.
The message format is shown below.
< PMIP6-Subscription-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Mobile-Node-Identifier }
...
* [ AVP ]
4.4 PMIP6-Subscription-Answer(PSA)
The PMIP6-Subscription-Answer(PSA) command, indicated by the Command-
Code field set to XXX and the 'R' bit cleared in the Command Flags
field, is sent by a server in response to the PMIP6-Subscription-
Request command.
The message format is shown below.
< PMIP6-Subscription-Answer> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
[ Result-Code ]
{ Mobile-Node-Identifier }
...
* [ AVP ]
4.5 PMIP6-Notification-Request (PNR)
Guang, et al. Expires December 30, 2010 [Page 10]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
The PMIP6-Notification-Request(PNR)command, indicated by the Command-
Code field set to XXX and the 'R' bit set in the Command Flags field,
is sent by a Diameter server to a Diameter client in order to notify
changes in the user data in the server.
The message format is shown below.
< PMIP6-Notification-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Mobile-Node-Identifier }
*2{ MIP6-Agent-Info }
*{ Proxy Care-of Address }
{ Handoff-Indicator }
{ Access-Technology }
[ PBU-Timestamp ]
*[ Mobile Node Link-layer Identifier
] ...
*[ AVP ]
4.6 PMIP6-Notification-Answer (PNA)
The PMIP6-Notification-Answer (PNA) command, indicated by the
Command-Code field set to XXX and the 'R' bit cleared in the Command
Flags field, is sent by a server in response to the PMIP6-
Notification-Request command.
The message format is shown below.
< PMIP6-Notification-Answer> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
[ Result-Code ]
*{ Proxy Care-of Address }
{ Handoff-Indicator }
{ Access-Technology }
[ PBU-Timestamp ]
*[ Mobile Node Link-layer Identifier
] ...
*[ AVP ]
5 Attribute Value Pair Definitions
5.1 Proxy Care-of Address AVP
The Proxy Care-of Address AVP(AVP Code XXX) is of type address and
contains the global address configured on the egress interface of the
mobile access gateway and is the transport endpoint of the tunnel
between the local mobility anchor and the mobile access gateway.
5.2 Handoff-Indicator AVP
Guang, et al. Expires December 30, 2010 [Page 11]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
The Handoff-Indicator AVP(AVP Code XXX )is of type 8-bit unsigned
integer and MUST be present in the PMIP6-Userdata-Request,PMIP6-
Notification-Request and PMIP6-Notification-Answer diameter
message.The Handoff-Indicator field MUST be set to a value indicating
the handoff hint.
* The Handoff Indicator field MUST be set to a value of 1 (Attachment
over a new interface) if the mobile access gateway determines (under
the Handoff Indicator considerations specified in this section) that
the mobile node's current attachment to the network over this
interface is not as a result of a handoff of an existing mobility
session (over the same interface or through a different interface),
but as a result of an attachment over a new interface. It essentially
serves as a request to AAA to create a new user data ,then AAA notify
LMA of creation of a new Binding Cache entry and not update any
existing Binding Cache entry created for the same mobile node
connected to the Proxy Mobile IPv6 domain through a different
interface.
* The Handoff Indicator field MUST be set to a value of 2 (Handoff
between two different interfaces of the mobile node)if the mobile
access gateway definitively knows the mobile node's current
attachment is due to a handoff of an existing mobility session
between two different interfaces of the mobile node.
* The Handoff Indicator field MUST be set to a value of 3
(Handoff between mobile access gateways for the same interface) if
the mobile access gateway definitively knows the mobile node's
current attachment is due to a handoff of an existing mobility
session between two mobile access gateways and for the same interface
of the mobile node.
* The Handoff Indicator field MUST be set to a value of 4
(Handoff state unknown) if the mobile access gateway cannot
determine if the mobile node's current attachment is due to a
handoff of an existing mobility session.
5.3 Access-Technology-Type AVP
The Access-Technology-Type AVP( AVP Code XXX )is of type 8-bit
unsigned integer and MUST be present in the PMIP6-Userdata-Request
and PMIP6-Notification-Request diameter messages and set to the type
of access technology by which the mobile node is currently attached
to the mobile access gateway. The values (0 - 255) will be allocated
and managed by IANA. The following values are currently reserved for
the below specified access technology types.
0: Reserved ("Reserved")
Guang, et al. Expires December 30, 2010 [Page 12]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
1: Virtual ("Logical Network Interface")
2: PPP ("Point-to-Point Protocol")
3: IEEE 802.3 ("Ethernet")
4: IEEE 802.11a/b/g ("Wireless LAN")
5: IEEE 802.16e ("WIMAX")
5.4 PBU-Timestamp AVP
The PBU-Timestamp AVP( AVP Code XXX ) is of type 64-bit unsigned
integer. The value indicates the number of seconds since January 1,
1970, 00:00 UTC, by using a fixed point format. In this format, the
integer number of seconds is contained in the first 48 bits of the
field, and the remaining 16 bits indicate the number of 1/65536
fractions of a second.
5.5 MN-Link-Layer-Identifier AVP
The MN-Link-layer-Identifier AVP( AVP Code XXX ) is of type link-
layer addresses that identifies the attached interface of a mobile
node. An identifier that identifies the attached interface of a
mobile node. The link-layer identifier, in some cases, is generated
by the mobile node and conveyed to the mobile access gateway. This
identifier of the attached interface must be stable, as seen by any
of the mobile access gateways in a given Proxy Mobile IPv6 domain.
In some other cases, there might not be any link-layer identifier
associated with the mobile node's interface. An identifier value of
ALL_ZERO is not considered a valid identifier and cannot be used as
an interface identifier.
6 Result-Code AVP Values
6.1 SUCCESS
Errors that fall within the Success category are used to inform a
peer that a request has been successfully completed.
DIAMETER_SUCCESS_PMIP_USERDATA_REQUEST(StatusCode XXXX)
6.2 Permanent Failures
6.2.1 DIAMETER_ERROR_PMIP_USER_DATA_NOT_RECOGNIZED(XXXX)
The data received by the AAA is not supported or recognized.
6.2.2 DIAMETER_ERROR_PMIP_OPERATION_NOT_ALLOWED (XXXX)
The requested operation is not allowed for the AAA.
Guang, et al. Expires December 30, 2010 [Page 13]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
6.2.3 DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_READ(XXXX)
The requested user data is not allowed to be read.
6.2.4 DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_MODIFIED (XXXX)
The requested user data is not allowed to be modified.
6.2.5 DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_NOTIFIED (XXXX)
The requested user data is not allowed to be notified on changes.
6.2.6 DIAMETER_ERROR_PMIP_NO_SUBSCRIPTION_TO_DATA (XXXX)
The LMA received a notification of changes of the information to
which it is not subscribed.
6.3 Transient Failures
Errors that fall within the transient failures category are those
used to inform a peer that the request could not be satisfied at the
time that it was received. The request may be able to be satisfied in
the future.
6.3.1 DIAMETER_ERROR_PMIP_USER_DATA_NOT_AVAILABLE(XXXX)
The requested user data is not available at this time to satisfy the
requested operation.
7 Attribute Value Pair Occurrence Tables
The following tables list the PMIPv6 MAG-to-AAA interface and AAA-to-
LMA interface AVPs. Figure 2 contains the AVPs and their occurrences
on the MAG-to-HAAA interface.
7.1 MAG-to-AAA interface
+---------------+
| Command-Code |
|-------+-------+
Attribute Name | PUR | PUA |
-------------------------------|-------+-------+
Proxy Care-of Address | 1+ | 0+ |
Guang, et al. Expires December 30, 2010 [Page 14]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
+-------+-------+
Figure 2: MAG-to-AAA Interface Generic Diameter Request and Answer
Commands AVPs
7.2 AAA-to-LMA interface
+-----------------------+
| Command-Code |
|-----+-----+-----+-----+
Attribute Name | PSR | PSA | PNR | PNA |
-----------------------------------|-----+-----+-----+-----+
Proxy Care-of Address | 0 | 0 | 1 | 1 |
Handoff-Indicator | 0 | 0 | 1 | 1 |
Access-Technology | 0 | 0 | 1 | 1 |
PBU-Timestamp | 0-1 | 0-1 | 0-1 | 0-1 |
Mobile Node Link-layer Identifier | 0-1 | 0-1 | 0-1 | 0-1 |
+-----+-----+-----+-----+
Figure 3: AAA-to-LMA Interface Generic Diameter Request and Answer
Commands AVPs
8 Examples Signaling Flows
8.1 Generic message workflow
Diameter Client -------- Diameter Server -------- Diameter Client
------------------------------------------------------------------
MAG AAA/M-PDP LMA
------- PUR -------> <---- PSR -----
<------ PUA -------- ----- PSA ----> ----+
|
Async
|
----- PNR ----> ----+
<---- PNA -----
Figure 4: Generic Message Workflow between Diameter Client and
Diameter Server.
8.2 Initial Binding Registration - New Mobility Session
Figure 5 shows a signaling flow example during the mobile node's
attachment to the access link using the AAA interactions defined in
this specification.In step (1) of this example, The LMA subscribe to
receive notifications of changes in mobile node's user data from the
AAA server successfully. During step (2), The serving MAG detects the
Guang, et al. Expires December 30, 2010 [Page 15]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
mobile node on its access link and sends Diameter PUR message to AAA
server.If the AAA server determines the mobile node is authorized for
the network-based mobility management service,AAA server will assign
a Home Network Prefix and the address of LMA for mobile node through
Diameter PUA message to MAG. Step (3) is used to notify the LMA of
changes of the mobile node's user data,AAA server sends Diameter PNR
message to LMA, the LMA will response to it by sending Diameter PNA
message to AAA after it creates or updates the Binding Cache entry
for the mobile node successfully.
MN MAG/NAS LMA AAA
| | | |
| | | PSR+LMA-AAA AVPS | s
| | |------------------->| t
| | PSA+LMA-AAA AVPS | e
| | |<-------------------| p
| | |
| | | | 1
: : : :
: : : :
| L2 Attach | | s
|-------------------->| PUR+MAG-AAA AVPS | t
| |---------------------------------------->| e
| | PUA+MAG-AAA AVPS | p
| RA |<----------------------------------------| 2
|<--------------------| | |
| | | PNR+LMA-AAA AVPS | s
| | |<-------------------| t
| | | PNA+LMA-AAA AVPS | e
| | |------------------->| p
| IP connectivity | PMIPv6 tunnel up | |
|---------------------|====================| | 3
| | | |
Figure 5: MAG and LMA Signaling Interaction with AAA Server during
Initial Binding Registration
9 IANA Considerations
9.1 Command Codes
See Section 4 for the assignment of the namespace in this
specification.
Command Code | Value
--------------------------------------+------
PMIP6-Userdata-Request/Answ(PUR/PUA) | XXX
Guang, et al. Expires December 30, 2010 [Page 16]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
PMIP6-Subscription-Request/Answ(PSR/PSA) | XXX
PMIP6-Notification-Request/Answ(PNR/PNA) | XXX
9.2 Attribute Value Pair Codes
* Proxy Care-of address
* Handoff-Indicator
* Access-Technology-Type
* PBU-Timestamp
* MN-Link-Layer-Identifier
The AVPs are defined in Section 5.
9.3 Result-Code AVP Values
See Section 6 for the assignment of the namespace in this
specification.
Result-Code | Value
-------------------------------------------------+------
DIAMETER_SUCCESS_PMIP_USERDATA_REQUEST |XXXX
DIAMETER_ERROR_PMIP_USER_DATA_NOT_RECOGNIZED |XXXX
DIAMETER_ERROR_PMIP_OPERATION_NOT_ALLOWED |XXXX
DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_READ |XXXX
DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_MODIFIED |XXXX
DIAMETER_ERROR_PMIP_USER_DATA_CANNOT_BE_NOTIFIED |XXXX
DIAMETER_ERROR_PMIP_NO_SUBSCRIPTION_TO_DATA |XXXX
DIAMETER_ERROR_PMIP_USER_DATA_NOT_AVAILABLE |XXXX
9.4 Application Identifier
Application Identifier | Value
-----------------------------------+------
Diameter PMIPv6 PBU | X
10 Security Considerations
The security considerations for the Diameter base protocol [RFC3588],
the Diameter NASREQ application [RFC4005], and the Diameter EAP
application (with respect to network access authentication and the
transport of keying material) [RFC4072] are applicable to this
document.
11 References
11.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Guang, et al. Expires December 30, 2010 [Page 17]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V.,Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",RFC 5213, August 2008.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application",
RFC 4072, August 2005.
[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.
[RFC5778] Korhonen, J., Ed., Tschofenig, H., Bournelle, J.,Giaretta,
G., and M. Nakhjiri, "Diameter Mobile IPv6:Support for
Home Agent to Diameter Server Interaction", RFC 5778,
February 2010.
[RFC5779] Korhonen, J., Ed., Bournelle, J., Chowdhury, K.,Muhanna,
A., and Meyer, U, "Diameter Proxy Mobile IPv6: Mobile
Access Gateway and Local Mobility Anchor Interaction with
Diameter Server",RFC 5779,February 2010.
[29.229] 3GPP TS 29.229 V9.0.0 (2009-12); Technical
Specification;Technical Specification Group Core Network;
Cx and Dx interfaces based on the Diameter protocol;
Protocol details; (Release 9).
11.2 Informative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC
5226,May 2008.
Guang, et al. Expires December 30, 2010 [Page 18]
INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 28, 2010
[RFC5637] Giaretta, G., Guardini, I., Demaria, E., Bournelle,
J.,and R. Lopez, "Authentication, Authorization, and
Accounting (AAA) Goals for Mobile IPv6", RFC
5637,September 2009.
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,September
2006.
[NETLMM-PMIP6] Wakikawa, R. and S. Gundavelli, "IPv4 Support for
Proxy Mobile IPv6", Work in Progress, September 2009.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
Author's Addresses
Jie Hu
China Telecom
118,Xizhimennei Ave,Xicheng District,
Beijing 100035, China
EMail: hujie@ctbri.com.cn
Xiaoming Guang
China Telecom
118,Xizhimennei Ave,Xicheng District,
Beijing 100035, China
EMail: guangxm@ctbri.com.cn
Guang, et al. Expires December 30, 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 11:26:25 |