idnits 2.17.1 draft-sun-i2apm-address-pool-management-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2016) is 2847 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC6674' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC6888' is defined on line 436, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Sun 3 Internet-Draft C. Xie 4 Intended status: Informational China Telecom 5 Expires: January 8, 2017 J. Bi 6 Tsinghua University 7 W. Xu 8 Huawei Technologies 9 July 7, 2016 11 Interface to the Address Pool Management 12 draft-sun-i2apm-address-pool-management-arch-01 14 Abstract 16 This document describes an mechanism for a standard, programmatic 17 interface for address pool management. With the remaining IPv4 18 address becoming more and more scattered, it is complicated to 19 manually configure the address pools on lots of Broadband Network 20 Gateways(BNGs) for operators. By introducing SDN/NFV in BNG, the 21 address pools can be allocated in a centralized way. It will not 22 only simplify the address management for operators, but also improve 23 the utilization efficiency of the address pool. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 8, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 3 62 4. Initial Address Pool Configuration . . . . . . . . . . . . . 5 63 5. Address Pool Status Report . . . . . . . . . . . . . . . . . 7 64 6. Address Pool Status Query . . . . . . . . . . . . . . . . . . 8 65 7. Address Exhaustion . . . . . . . . . . . . . . . . . . . . . 8 66 8. Address Pool Release . . . . . . . . . . . . . . . . . . . . 8 67 9. Control Protocol consideration . . . . . . . . . . . . . . . 10 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 12.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 The Broadband Network Gateway(BNG), which manages a routable IP 78 address on behalf of each subscriber, should be configured with the 79 IP address pools allocated to subscribers. However, currently 80 operators are facing with the address shortage problem, the remaining 81 IPv4 address pools are usually quite scattered, no more than /24 per 82 address pool in many cases. Therefore, it is complicated to manually 83 configure the address pools on lots of Broadband Network Gateway(BNG) 84 for operators. For large scale MAN, the number of BNGs can be up to 85 over one hundred. Manual configuration on all the BNGs statically 86 will not only greatly increase the workload, but also decrease the 87 utilization efficiency of the address pools when the number of 88 subscribers changes in the future. 90 Another use case which needs to configure the address pools is IPv6 91 migration. For IPv6 transition mechanisms, e.g. DS-Lite, lw4over6, 92 etc., they all need to be configured with address pools as translated 93 routeable addresses. When high availability features, e.g. active- 94 active/active-standby failover mechanism, etc., are enabled for these 95 IPv6 transition mechanisms, different address pools need to be 96 configured on each transition instance. This will further increase 97 the number of address pools need to be configured. Besides, the 98 occupation of the address pools may vary during different transition 99 periods, (e.g. at the early stage of IPv6 transition, IPv4 traffic 100 will normally occupy a great portion of the total traffic, while in 101 the later stage of IPv6 transition, IPv4 traffic will decrease and 102 the amount of IPv4 address pools will decrease accordingly. 104 There are other devices which may need to configure address pools as 105 well. For example, the Firewall need to configure the address pool 106 for acl/NAT process. The VPN also needs to configure the address 107 pools for end-users. 109 When SDN/NFV is introduced in the network, these devices (e.g. BNG, 110 CGN, firewall, VPN, etc.) will run as VNFs in virtualized 111 environment. A common centralized address management server can 112 interact with different VNFs and allocate address pools 113 automatically. 115 In this document, we propose a mechanism to manage the address pools 116 centrally. In this way, operators do not need to configure the 117 address pools one by one manually and it also helps to use the 118 address pools more efficiently. 120 2. Terminology 122 The following terms are used in this document: 124 APMS A management system which has a centralized databse manage 125 the overall address pools and allocate address pools to the device 126 in the devices. 128 DA A device agent in device, which contact with APM server to 129 manipulate address pool. 131 3. Architectural Overview 133 In this architecture, the Address Pool Management (APM) server is a 134 centralized address pool management server for operators to configure 135 the overall address pools. It maintains the address pool database 136 including the overall address pools (OAP) and the address pool 137 status(APS). Operators can configure its remaining address pools in 138 the OAP. They can also reserve some address pool for special-purpose 139 usage. The address pools status is to reflects the current usage of 140 the address pools for different devices. APM also has the interface 141 to configure the address pools to different devices dynamically. 143 In each device, there is an device agent (DA) to contact with APM 144 server. It initiates the address pools allocation requests, passes 145 the address pools to local instances, report the status of local 146 address pool usage and update the address pools requests, etc. For 147 some devices, e.g. v6transition, VPN, etc., additional routing 148 modules needs to update the routing table accordingly. 150 +*********************+ 151 | APM server | 152 | +------------+ | 153 | | Address DB | | 154 | +------------+ | 155 +***^*****^******^*^**+ 156 | | | 157 | | | 158 +------------+ | +------------+ 159 | | | 160 | | | 161 +------v------+ +------v------+ +------v------+ 162 | +--------+ | | +--------+ | | +--------+ | 163 | | agent | | | | agent | | | | agent | | 164 | +----+---+ | | +----+---+ | | +----+---+ | 165 | | | | | | | | | 166 | v | | v | | v | 167 | +--------+ | | +---------+ | | +---------+ | 168 | | Local | | | | v6tra | | | | VPN | | 169 | | Conf | | | | instance| | | |instance | | 170 | +--------+ | | +----+----+ | | +---------+ | 171 +-------------+ | | | | | | 172 | v | | v | | v | 173 | +---------+ | | +---------+ | | +---------+ | 174 | | routing | | | | routing | | | | routing | | 175 | +---------+ | | +---------+ | | +---------+ | 176 +-------------+ +-------------+ +-------------+ 177 BNG/vBNG v6tra/fw VPN 179 Figure 1: Interface to Address Pool Management (APM) 181 The overall procedure is as follows: 183 o Operators will configure remaining address pools centrally in the 184 Address Pool Management System (APMS). There are multiple address 185 pools which can be configured centrally. The APMS server will 186 then divide the address pools into addressing unit (AU) which will 187 be allocated to the agent in devices by default. 189 o The agent will initiate Address Pool request to the APMS. It can 190 carry its desired size of address pool the request, or just use a 191 default value. The address pool size in the request is only used 192 as a hint. The actual size of the address pool is totally 193 determined by APMS. It will also carry the DA's identification 194 and the type of address pool. 196 o APMS looks up the remaining address pool in its local database. 197 It will then allocate a set of address pools to the DA. Each 198 address pool has a related lifetime. 200 o DA receives the AddressPool reply and use them for their purpose. 202 o If the lifetime of the address pool is going to expire, the DA 203 should issue an AddressPoolRenew request to extend the 204 lifetime,including the IPv4, IPv6, Ports, etc. 206 o The AddressPoolReport module keeps monitoring and reports the 207 current usage of all current address pools for each transition 208 mechanism. if it is running out of address pools, it can renew the 209 AddressPoolRequest for a newly allocated one. It can also release 210 and recycle an existing address pool if the that address pool has 211 not been used for a specific and configurable time. 213 o When the connection of APMS is lost or the APMS needs the status 214 information of certain applications, the APMS may pre-actively 215 query the DA for the status information. 217 4. Initial Address Pool Configuration 218 +--------------+ +-----------------+ 219 | Device | |AddrPoolMangement| 220 | Agent | | Server | 221 +------+-------+ +--------+--------+ 222 | | 223 +--------+-------+ | 224 |1.DA start-up | | 225 +---------+------+ | 226 | 2.Address Pool Request | 227 |------------------------------------------>| 228 | | 229 | +--------+-------+ 230 | | 3. Check | 231 | | address pool | 232 | +--------+-------+ 233 | 4.Address Pool Reply | 234 |<------------------------------------------| 235 | | 236 | | 238 Figure 2: Initial Address Pool Configuration 240 Figure 2 illustrates the initial address pool configuration 241 procedure: 243 1. The DA checks whether there is already address pool configured in 244 the local site when it starts up. if no, it means the initial 245 start-up or the address pool has been released. if yes, the 246 address pool could be used directly. 248 2. The DA will initiate Address Pool request to the APMS. It can 249 carry its desired size of address pool in the request, or just 250 use a default value. The address pool size in the DA's request 251 is only used as a hint. The actual size of the address pool is 252 totally determined by APMS. It will also carry the DA's 253 identification, the type of transition mechanism and the 254 indication of port allocation support. 256 3. The APMS determines the address pool allocated for the DA based 257 on the parameters received. 259 4. The APMS sends the Address Pool Reply to the DA. It will also 260 distribute the routing entry of the address pool automatically. 261 In particular, if the newly received address pool can be 262 aggregated to an existing one, the routing should be aggregated 263 accordingly. 265 5. Address Pool Status Report 267 +--------------+ +-----------------+ 268 | Device | |AddrPoolMangement| 269 | Agent | | Server | 270 +------+-------+ +--------+--------+ 271 | | 272 +--------+-------+ | 273 |1.Monitor and | | 274 |count the status| | 275 +--------+-------+ | 276 | 2.Address Pool Status Report | 277 |--------------------------------------------->| 278 | +--------+-------+ 279 | | 3. Record | 280 | | address pool | 281 | +--------+-------+ 282 | 4.Address Pool Report Confirm | 283 |<---------------------------------------------| 284 | | 285 | | 287 Figure 3: Address Pool Status Report 289 Figure 3 illustrates the active address pool status report procedure: 291 1. The DA will monitor and count the usage status of the local 292 address pool. The DA counts the address usage status in one 293 month, one week and one day, which includes the local address, 294 address usage ratio (peak and average values), and the port usage 295 ratio (peak and average values). 297 2. The DA reports the address pool usage status to the APMS. for 298 example, it will report the address usage status in one day, 299 which contains the IP address, NAT44, address list: 300 30.14.44.0/28, peak address value 14, average address usage ratio 301 90%, TCP port usage ratio 20%, UDP port usage ratio 30% and etc. 303 3. The APMS records the status and compares with the existing 304 address information to determine whether additional address pool 305 is needed. 307 4. The APMS will confirm the address pool status report request to 308 the DA. It will keep sending the address pool status report 309 request to the APMS if no confirm message is received. 311 6. Address Pool Status Query 313 When the status of APMS is lost or the AMS needs the status 314 information of the DAs, the APMS may actively query the TD for the 315 status information, as shown in step 1 of Figure 4. The following 316 steps 2,3,4,5 are the same as the Address Pool Status Report 317 procedure. 319 +--------------+ +-----------------+ 320 | Device | |AddrPoolMangement| 321 | Agent | | Server | 322 +------+-------+ +--------+--------+ 323 | | 324 | | 325 | 1.Address Pool Status Query | 326 |<---------------------------------------------| 327 | | 328 +--------+-------+ | 329 |2.Monitor and | | 330 |count the status| | 331 +--------+-------+ | 332 | 3.Address Pool Status Report | 333 |--------------------------------------------->| 334 | +--------+-------+ 335 | | 4. Record | 336 | | address pool | 337 | +--------+-------+ 338 | 5.Address Pool Report Confirm | 339 |<---------------------------------------------| 340 | | 341 | | 343 Figure 4: Address Pool Status Query 345 7. Address Exhaustion 347 When the DA uses up the addresses allocated, it will renew the 348 address pool request to the APMS for an additional address pool. The 349 procedure is the same as the initial address pool request. 351 8. Address Pool Release 352 +--------------+ +-----------------+ 353 | Device | |AddrPoolMangement| 354 | Agent | | Server | 355 +------+-------+ +--------+--------+ 356 | | 357 +--------+-------+ | 358 |1.Address pools | | 359 | not used for a| | 360 | long time | | 361 +--------+-------+ | 362 | 2.Address Pool Release Request | 363 |--------------------------------------------->| 364 | +--------+-------+ 365 | |3. Update | 366 | | address pool | 367 | | database | 368 | +--------+-------+ 369 | 4.Address Pool Release Notification | 370 |<---------------------------------------------| 371 +--------+-------+ | 372 |5. Reduce | | 373 | address pool | | 374 +--------+-------+ | 375 | 6.Address Pool Release Confirm | 376 |--------------------------------------------->| 377 | | 378 | | 380 Figure 5: Address Pool Release 382 Figure 5 illustrates the address pool release procedure: 384 1. The counting module in the DA checks that there are addresses not 385 used for a long time; 387 2. The DA sends the address pool release request to the APMS to ask 388 the release of those addresses; 390 3. The APMS updates the local address pool information to add the 391 new addressed released. 393 4. The APMS notifies the TD that the addresses have been release 394 successfully; 396 5. The DA will update the local address pool. if no Address Pool 397 Release Notification is received, the DA will repeat step 2; 399 6. The DA confirms with the APMS that the addres pool has been 400 released successfully. 402 9. Control Protocol consideration 404 The I2APM architecture consists of two major distinct entities: APM 405 Server and network equipment with an APM Agent. In order to provide 406 address pool manipulations between these two entities, the I2APM 407 architecture calls for well-defined protocols for interfacing between 408 them. For compatibility with legacy network equipment, the 409 architecture reuse legacy protocol such as radius. While the IETF 410 may also choose to define one or more specific approaches to 411 manipulate address pool, such as NETCONF or RESTCONF with address 412 pool YANG data model. 414 10. Security Considerations 416 11. Acknowledgements 418 N/A. 420 12. References 422 12.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 12.2. Informative References 431 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 432 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 433 DOI 10.17487/RFC6674, July 2012, 434 . 436 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 437 A., and H. Ashida, "Common Requirements for Carrier-Grade 438 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 439 April 2013, . 441 Authors' Addresses 442 Qiong Sun 443 China Telecom 444 No.118 Xizhimennei street, Xicheng District 445 Beijing 100035 446 P.R. China 448 Email: sunqiong@ctbri.com.cn 450 Chongfeng Xie 451 China Telecom 452 No.118 Xizhimennei street, Xicheng District 453 Beijing 100035 454 P.R. China 456 Email: xiechf@ctbri.com.cn 458 Jun Bi 459 Tsinghua University 460 3-212, FIT Building, Tsinghua University, Haidian District 461 Beijing 100084 462 P.R. China 464 Email: junbi@tsinghua.edu.cn 466 Weiping Xu 467 Huawei Technologies 468 Bantian, Longgang District 469 shenzhen 518129 470 P.R. China 472 Email: xuweiping@huawei.com