Behave WG W. Meng Internet-Draft C. Wang Intended status: Standards Track ZTE Corporation Expires: March 31, 2013 J. Hu China Telecom September 27, 2012 Share Public IP Address pools among Devices draft-meng-behave-ip-resources-share-00 Abstract This document specifies a solution to enable IP addresses sharing among multiple CGN devices, including requesting and releasing IP addresses. Through this solution, the operators can make the dynamic sharing of IP addresses, improve the IP address sharing rate, realize resources'optimization, provide a more convenient platform for operators to manage of IP address pools. In addition, due to the unified management of IP addresses from the AAA server, CGN device MAY reboot without provisioned IP address pools. 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." This Internet-Draft will expire on March 31, 2013. 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 Meng, et al. Expires March 31, 2013 [Page 1] Internet-Draft Share pools among Devices September 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 3. Module Classify . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. User configuration module . . . . . . . . . . . . . . . . 5 3.2. IP address resources requesting/releasing module . . . . . 5 3.3. IP address resources management module . . . . . . . . . . 5 3.4. AAA server management module . . . . . . . . . . . . . . . 5 4. Modules Configuration . . . . . . . . . . . . . . . . . . . . 6 4.1. RADIUS message extensions . . . . . . . . . . . . . . . . 6 4.2. The AAA server configuration . . . . . . . . . . . . . . . 8 4.2.1. Configure Pools . . . . . . . . . . . . . . . . . . . 8 4.2.2. Manage the priority . . . . . . . . . . . . . . . . . 8 4.2.3. Manage logging . . . . . . . . . . . . . . . . . . . . 9 4.3. The CGN device configuration . . . . . . . . . . . . . . . 9 4.3.1. Configure the priority of CGN device . . . . . . . . . 9 4.3.2. Configure requesting/releasing threshold(the threshold can be calculated as the rate of idle resources) . . . . . . . . . . . . . . . . . . . . . . 9 4.3.3. Configure the releasing strategy . . . . . . . . . . . 10 4.3.4. Configure the step . . . . . . . . . . . . . . . . . . 11 4.3.5. Configure hold-down time after failed requesting/releasing . . . . . . . . . . . . . . . . . 11 5. IP address requesting/releasing procedure . . . . . . . . . . 12 5.1. A CGN device preliminary requesting of IP addresses . . . 12 5.1.1. Normal procedure, see Figure 6 . . . . . . . . . . . . 12 5.1.2. Abnormal procedure . . . . . . . . . . . . . . . . . . 13 5.2. A CGN device re-requests IP addresses . . . . . . . . . . 14 5.2.1. Normal procedure, see Figure 6 . . . . . . . . . . . . 14 5.2.2. Abnormal procedure . . . . . . . . . . . . . . . . . . 15 5.3. A CGN device releases IP addresses . . . . . . . . . . . . 16 5.3.1. Normal procedure, see Figure 10 . . . . . . . . . . . 16 5.3.2. Abnormal procedure . . . . . . . . . . . . . . . . . . 17 5.4. Other exceptional procedure . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Normative References . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Meng, et al. Expires March 31, 2013 [Page 2] Internet-Draft Share pools among Devices September 2012 1. Introduction With the depletion of IPv4 addresses, Network Address Translation ( NAT ) technology has been widely used. However, the address resources cannot be dynamically shared among multiple CGN ( Carrier Grade NAT) devices. Currently, NAT public address pools are directly or indirectly configured in CGN devices, this may cause the some CGN devices rich and the other CGN devices poor of address resources. For the operators, the total number of IP addresses is limited. The imbalance of user number in periods and regions often results that IP address resources sometimes are surplus and sometimes are insufficient. For example, both region "A" and "B" have N public IP addresses. Region "A" organizes a large-scale activity, which leads too many people flow to region "A" from region "B". It results that : Region "A" lacks of IP addresses heavily, while Region "B" resources utilization rate drops to nearly 0%. Meng, et al. Expires March 31, 2013 [Page 3] Internet-Draft Share pools among Devices September 2012 2. Convention and 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 [RFC2119]. CELL : IP address management unit. Usually, one CELL has one or more IP addesses, depending on the operators' classification. Preliminary Request: After CGN device complete initializion , it will send a requesting RADIUS message at the first time. Meng, et al. Expires March 31, 2013 [Page 4] Internet-Draft Share pools among Devices September 2012 3. Module Classify In order to realize the IP address sharing, each CGN device requires the following modules: 3.1. User configuration module 1)Priority configuration 2)Requesting threshold configuration 3)Releasing threshold configuration 4)Releasing strategy 5)Requesting step 6)Hold-down time after failed requesting 3.2. IP address resources requesting/releasing module The IP address resource requesting/releasing module is used to calculate the rate of idle resources, then decide whether CGN devices requests or releases IP addresses. This module can be carried out for the following operations: 1)Calculating the rate of idle resources 2)Processing RADIUS messages 3.3. IP address resources management module The IP address resources management module is used to manage IP address resources, such as implementing out the releasing strategy in the released state. 3.4. AAA server management module The AAA server management module is used to manage the whole IP address resources by operators. This module can be carried out for the following operations: 1)Pool management 2)Priority management 3)Logging management Meng, et al. Expires March 31, 2013 [Page 5] Internet-Draft Share pools among Devices September 2012 4. Modules Configuration In order to realize the IP address resources sharing, it can perform the following operations: 4.1. RADIUS message extensions Extending field of six RADIUS message codes: see Figure 1, the value of the code field can be but not limited to the value shown in Figure 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code 31 Address-Request 32 Address-Request-Reply 33 Address-Request-Reply-Ack 34 Address-Request-Reject 35 Address-Release 36 Address-Release-Reply 37 Address-Release-Reject Figure 1: RADIUS message codes Extending field of four RADIUS attributes : such as device number, priority, CELLs information, requesting step. These four types of message format are, see Figure 2 to Figure 5. Meng, et al. Expires March 31, 2013 [Page 6] Internet-Draft Share pools among Devices September 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1: Type of Device Number Length 4 Value Value of Device Number Figure 2: Attribute 1--Device Number 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | revd | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2: Type of Priority Length 1 Revd Fill with 0 Value Value of priority,4 bits(0-15). Figure 3: Attribute 2-- Priority Meng, et al. Expires March 31, 2013 [Page 7] Internet-Draft Share pools among Devices September 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value ...... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 3: Type of CELL Information Length 4+4*(IP Address Number) Value The first 4 bytes is CELL ID,following the IP addresses Figure 4: Attribute 3-- CELL Information 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4: Type of Step of CELL requesting Length 1 Value Number of CELLs be requested each time Figure 5: Attribute 4-- Step 4.2. The AAA server configuration 4.2.1. Configure Pools Configure address pools, meanwhile can bind at least one IP address to a CELL. CELL is the base management unit of IP address requesting or releasing . 4.2.2. Manage the priority The AAA server manages all CGN devices!_ priority and corresponding CELLs. When receives the first message of IP address resource requesting, AAA server allocates several CELLs according to the Meng, et al. Expires March 31, 2013 [Page 8] Internet-Draft Share pools among Devices September 2012 priority of the requesting message. The priority level is different amang CGN devices, and the assigned number of CELLs SHOULD be different too. 4.2.3. Manage logging The AAA server enables logging management, used for recording the logging information for follow-up query. Logging management includes following fields: 1)Time stamp 2)Device number ( identify the device who requests or releases IP addresses) 3)The assigned IP addresses 4)Message type ( request, release) 5)The execution result ( success, failure) 4.3. The CGN device configuration 4.3.1. Configure the priority of CGN device The priority determines the requesting ability about CELL number, so it SHOULD be configured when CGN device initializes. The number of CELLs has its upper limit and lower limit.The priority is only for the preliminary requesting of IP address resource.In particular, the CGN device need not to configure any address pool itself. 4.3.2. Configure requesting/releasing threshold(the threshold can be calculated as the rate of idle resources) Because the PAT mapping is based on protocols, and the same port can be multiplexed by any protocols, so the threshold needs distinct protocols. Specifically, when the resource idle rate of ANY protocol is lower than the requesting threshold, it triggers CGN device to re-request one or more CELLs. For the releasing threshold, when resource idle rate of ALL protocols is higher than the releasing threshold, it triggers CGN device to release one or more CELLs. In practical application, requesting threshold SHOULD be greater than Meng, et al. Expires March 31, 2013 [Page 9] Internet-Draft Share pools among Devices September 2012 the releasing threshold. 1)The algorithm of resources sum of a protocol is : 65535* the number of IP addresses 2)The algorithm of idle resources of a protocol is: the sum of unused ports of each IP address 3)The algorithm of resources idle rate of a protocol is: idle resources / resources sum The protocol includes but not limited to TCP , UDP , ICMP. When the resource idle rate of any kind of unicast protocol is lower than the requesting threshold, it will trigger CGN device to request one or more IP address resource CELLs; The resource idle rate of all kind of unicast protocols is higher than the releasing threshold, it will trigger the CGN device to release one or more CELLs; If the address pools distinguish between NAT type and PAT type, single IP address in NAT type occupies 65535 resources, this means a NAT session occupies 65535 resources. The algorithm of resource idle rate is also applicable to CGN mapping mode (EIM/ADM/APDM ), filter mode (EIF/ADF/APDF) etc.. 4.3.3. Configure the releasing strategy When the resource idle rate is higher than the releasing threshold, and CGN sessions occupies all CELLs, this means in any CELL, at least one IP address is occupied by CGN session. Then there is no CELL can be released. This is called released state. From this moment, creating follow-up sessions is upon the releasing strategy. The releasing strategy can be one of the following cases: 1)Focus strategy; Namely, under the released state, assigning IP addresses for new sessions will to focus on one CELL. The each remaining CELL SHOULD wait for all of the corresponding sessions to be aging or manually removed, then release the CELL. 2)Arbitrary stategy Namely, under the released state, select the least sessions CELL, and the CELL is forbidden to be used by the new session. And then delete all the sessions belong to this CELL and release this CELL. 3)Neglect strategy Meng, et al. Expires March 31, 2013 [Page 10] Internet-Draft Share pools among Devices September 2012 Namely, under the released state, if there is no idle CELL ( idle CELL refers to the CELL without IP address occupied by the session ), new session ignore the released state, and assign IP address resources to generate the session just like before. When any idle CELL exists, this CELL releasing process starts. 4.3.4. Configure the step The definition of the step of CELL is that how many CELLs CGN device can request from the AAA server each time. Supposing that the step is assigned 3, when the resource idle rate reached the requesting threshold, CGN device requested 3 CELLs from the AAA server. In practical application, the CGN device is initialized after the preliminary requesting of CELLs number according to the priority, when next time resource idle rate reaches the requesting threshold, CGN device can request CELLs number according to the assigned step. 4.3.5. Configure hold-down time after failed requesting/releasing Supposing that , assigned hold-down time after failed requesting/ releasing is T1, namely, if one requesting or releasing message gets no response or gets reject response, another requesting or releasing message should not be sent to AAA server in T1 time. Meng, et al. Expires March 31, 2013 [Page 11] Internet-Draft Share pools among Devices September 2012 5. IP address requesting/releasing procedure 5.1. A CGN device preliminary requesting of IP addresses 5.1.1. Normal procedure, see Figure 6 Step 1 Start a CGN device, initialize NAT module, and it requests IP addresses to a AAA server through RADIUS message. It sends a RADIUS message encapsulated "Address-Request" in code field ( see Figure 1 ), device number ( see Figure 2 ) and priority ( see Figure 3 ) in attribute field. Step 2 After the AAA server receives a RADIUS message about IP address requesting, AAA server allocate a CELL according to the priority in this message. Then it encapsulats a RADIUS message with "Address- Request-Reply" , device number ( see Figure 2 ) and CELL ID and IP addresses ( see Figure 4 ) in attribute field. If it needs to send multiple CELLs, repeat encapsulating as above before the message be sent. Step 3 When the CGN device receives the RADIUS message encapsulated "Address-Request-Reply", it loads CELL(s) or IP addresse(s) into its data management system. Then it sends a RADIUS message to the AAA server encapsulated "Address-Request-Reply-Ack" in code filed and device number ( see Figure 2 ) in attribute field. Now, CGN device initialization complete. CGN(NAS) AAA | | |-------- Address-Request -------->| | | | | |<------Address-Request-Reply------| | | | | |----Address-Request-Reply-Ack---->| | | | | Figure 6: A CGN device preliminarily requests IP addresses Meng, et al. Expires March 31, 2013 [Page 12] Internet-Draft Share pools among Devices September 2012 5.1.2. Abnormal procedure Case 1 ( see Figure 7 ) In the Normal procedure step 1 mentioned above, after the CGN device sending a RADIUS message to the AAA server for the IP addresses requesting, the CGN device does not receive response from AAA server. At this point, CGN device will continue to send same requesting message for N times. If there is still no response from AAA server, the CGN device SHOULD stop initializing and send alarm. CGN(NAS) AAA | | |-------- Address-Request -------->| | | | | |-------- Address-Request -------->| | . | | . N times | | . | |-------- Address-Request -------->| | | | | | | Figure 7: A CGN requests IP addresses with AAA no reply (Abnormal procedure) Case 2 ( see Figure 8 ) In the Normal procedure step 2 above, if the AAA server found that there was not enough CELL(s) to be assigned to the CGN device, it will send RADIUS message to the CGN device encapsulated "Address- Request-Reject" ( see Figure 1 ) in code field and device number ( see Figure 2 ) in attribute field. If the CGN device receives the message, it SHOULD stop initializing and send alarm. CGN(NAS) AAA | | |-------- Address-Request -------->| | | | | |<------Address-Request-Reject-----| | | Figure 8: A CGN requests IP addresses with AAA rejection (Abnormal procedure) Meng, et al. Expires March 31, 2013 [Page 13] Internet-Draft Share pools among Devices September 2012 Case 3 ( see Figure 9 ) If the AAA server did not receive "Address-Request-Reply-Ack" message from CGN device after step 3 of the Normal procedure. Then the AAA server will try to send "Address-Request-Reply" message to the CGN device again for N times until recieve the response from CGN device. Finally, if it still not receive "Address-Request-Reply-Ack" message ( note the CGN device failure or communication problems), lock CELL(s) and send alarm. CGN(NAS) AAA | | |-------- Address-Request -------->| | | | | |<------Address-Request-Reply------| | | | | |<------Address-Request-Reply------| | . | | . N times | | . | |<------Address-Request-Reply------| | | Figure 9: A CGN requests IP addresses with CGN failure (Abnormal procedure) Case 4 When the CGN device is running, the device MAY restart for plenty of reasons. Then the AAA server receives "Address-Request" message (Preliminarily Requesting) similar to that of step 1 from the CGN device which has just restarted, and find that it has already assigned CELL(s) to related CGN device. Then the AAA server will send all CELL(s) with "Address-Request-Reply" message similar to that of step 2 to the CGN device. 5.2. A CGN device re-requests IP addresses 5.2.1. Normal procedure, see Figure 6 Step 1 When a CGN device is running, it MAY create sessions sequentially. Once a session is created, the CGN device will compare the rate of idle resources with the value of requesting threshold that be configured before, according to a session belongs to a certain Meng, et al. Expires March 31, 2013 [Page 14] Internet-Draft Share pools among Devices September 2012 protocol. Step 2 If the rate of idle resources is lower than the configured requesting threshold, the CGN device will send a RADIUS message encapsulated "Address-Request" in code field ( see Figure 1 ), device number ( see Figure 2 ) and step ( see Figure 5 ) in attribute field. Step 3 Receiving the RADIUS message, the AAA server allocate appropriate number of CELLs according to the value of step carried in the message. Then it sends RADIUS message encapsulated "Address-Request- Reply" in code field, device number ( see Figure 2 ), CELL ID and IP addresses ( see Figure 4 ) in attribute field. If it needs to send multiple CELLs, repeat encapsulating as above. Step 4 When the CGN device receives the RADIUS message encapsulated "Address-Request-Reply", it loads CELL(s) or IP addresse(s) into its data management system. Then it sends a RADIUS message to the AAA server encapsulated "Address-Request-Reply-Ack" in code filed and device number ( see Figure 2 ) in attribute field. Now, CGN device initialization complete. 5.2.2. Abnormal procedure Case 1( see Figure 8 ) In step 3 of Normal procedure, if the AAA server finds that there is not enough CELL(s) to be assigned to the CGN device, it will send a RADIUS message to the CGN device encapsulated "Address-Request- Reject" ( see Figure 1 ) in code field and device number ( see Figure 2 ) in attribute field. If the CGN device receives the message, it will set hold-down time ,e.g. T1. It means that the CGN device MUST not re-send requesting message during T1. Case 2( see Figure 7 ) In step 2 of Normal procedure, after the CGN device send a RADIUS message to the AAA server for the IP addresses requesting, the CGN device does not receive response from AAA server. At this point, CGN device will continue to send the same requesting message for N times. If the CGN device receives the message, it will set hold-down time ,e.g. T1. It means that the CGN device MUST not re-send requesting message during T1. Meng, et al. Expires March 31, 2013 [Page 15] Internet-Draft Share pools among Devices September 2012 Case 3 ( see Figure 9 ) After the Normal procedure step 4 above, the AAA server did not receive "Address-Request-Reply-Ack" message from CGN deviece. Then the AAA server will try to send "Address-Request-Reply" message to the CGN device again for N times until recieve the response from CGN device. finally, if it still not receive "Address-Request-Reply-Ack" message ( note the CGN device failure or communication problems), lock CELL and send alarm. 5.3. A CGN device releases IP addresses 5.3.1. Normal procedure, see Figure 10 Step 1 When a CGN device is running, it MAY delete session occasionally because of sessions aging or manually deleting. Once the CGN device delete a session, CGN device will compare the rate of the idle resources with the value of releasing threshold according to protocol the session belongs to. Step 2 If the rate of the idle resources is lower than configured releasing threshold, CGN device will check whether there is any idle CELL(s). Idle CELL means that any IP address belong to the CELL is not assigned to sessions. Step 3 If there is a idle CELL, CGN device will send a RADIUS message encapsulated "Address-Release" in code field ( see Figure 1 ), device number ( see Figure 2 ), CELL information ( see Figure 4 )in attribute field. Step 4 If there is no idle CELL, CGN device will create new sessions according to releasing policy until aging or deleting cause creating idle CELL(s). Step 5 When AAA server receiving a RADIUS message about "Address-Release", it releases the specific CELL(s) and sends a message encapsulated "Address-Request-Reply" in code field ( see Figure 1 )to CGN device. Meng, et al. Expires March 31, 2013 [Page 16] Internet-Draft Share pools among Devices September 2012 Step 6 When CGN device recieving the message about "Address-Release-Reply", it will release the IP address resources and delete the CELL(s) in its configuration. CGN(NAS) AAA | | |-------- Address-Release -------->| | | | | |<------Address-Release-Reply------| | | Figure 10: A CGN releases IP addresses 5.3.2. Abnormal procedure Case 1( see Figure 11 ) In step 5 Normal procedure, if the AAA server find that it cannot complete the releasing process, it will send a RADIUS message to the CGN device encapsulated "Address-Release-Reject" ( see Figure 1 ) in code field and device number ( see Figure 2 ) in attribute field. If the CGN device receives the message, it will set hold-down time ,e.g. T1. It means that the CGN device MUST not re-send requesting message during T1. CGN(NAS) AAA | | |-------- Address-Release -------->| | | | | |<------Address-Release-Reject-----| | | Figure 11: A CGN releases IP addresses with AAA rejection (Abnormal procedure) Case 2( see Figure 12 ) In step 6 of Normal procedure, after the CGN device sends a RADIUS message to the AAA server for the IP addresses releasing, the CGN device does not receive response from AAA server. At this point, CGN device will continue to send the same releasing message for N times. If the CGN device receives the message, it will set hold-down time ,e.g. T1. It means that the CGN device MUST not re-send requesting message during T1. Meng, et al. Expires March 31, 2013 [Page 17] Internet-Draft Share pools among Devices September 2012 CGN(NAS) AAA | | |-------- Address-Release -------->| | | | | |-------- Address-Release -------->| | . | | . N times | | . | |-------- Address-Release -------->| | | | | | | Figure 12: A CGN releases IP addresses with AAA rejection (Abnormal procedure) 5.4. Other exceptional procedure Case 1 CGN device SHOULD have duplicate checking function, i.e. when continuously receiving the "Address-Request-Reply" or other types of message, the device SHOULD make continuous "Address-Request-Reply- Ack" response or other appropriate message, but the same CELL in CGN device MUST not be re-received; Case 2 Once a CGN device breaks down, AAA server MUST support manually releasing CELL(s) which have assigned to the CGN device. Case 3 Priority of a CGN device determines the upper limit and lower limit of CELL number( operator decisions ). When the CGN device CELL number reaching a lower limit, do no more releasing operation. When the upper limit of CELL number is reached, do no more requesting operation. Case 4 When CGN device is in requesting or releasing procedure, it is not allowed for other requesting or releasing operations at the same time. Meng, et al. Expires March 31, 2013 [Page 18] Internet-Draft Share pools among Devices September 2012 6. Security Considerations This document has no additional security considerations beyond those already identified in [RFC2865] for the RADIUS protocol and in [RFC5176] for CoA messages. Meng, et al. Expires March 31, 2013 [Page 19] Internet-Draft Share pools among Devices September 2012 7. IANA Considerations Per this document, IANA has allocated new RADIUS code and attribute types from the IANA registry "Radius Attribute Types" located at http://www.iana.org/assignments/radius-types. Meng, et al. Expires March 31, 2013 [Page 20] Internet-Draft Share pools among Devices September 2012 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. Meng, et al. Expires March 31, 2013 [Page 21] Internet-Draft Share pools among Devices September 2012 Authors' Addresses Wei Meng ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing 210012 China Email: meng.wei2@zte.com.cn Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: wang.cui1@zte.com.cn Jie Hu China Telecom No.118, Xizhimennei Beijing China Email: huj@ctbri.com.cn Meng, et al. Expires March 31, 2013 [Page 22]