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]