Netext Working Group Jie Hu INTERNET-DRAFT Xiao-Ming Guang Intended Status: Standards Track China Telecom Expires: December 31, 2010 June 29, 2010 A central policy controlling based PMIPv6 Solutions draft-jie-netext-cpc-pmip6-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 31, 2010 [Page 1] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 2] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 3] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 4] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 5] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 6] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 7] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 8] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 9] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 10] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 11] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 12] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 13] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 14] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 15] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 16] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 17] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 18] INTERNET DRAFT A Central Policy Controlling based PMIPv6 June 29, 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 31, 2010 [Page 19]