idnits 2.17.1 draft-li-casm-address-pool-management-arch-00.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 (March 6, 2017) is 2607 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC6674' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'RFC6888' is defined on line 466, 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 C. Li 3 Internet-Draft C. Xie 4 Intended status: Informational China Telecom 5 Expires: September 7, 2017 J. Bi 6 Tsinghua University 7 W. Xu 8 Huawei Technologies 9 March 6, 2017 11 Interface to the Address Pool Management 12 draft-li-casm-address-pool-management-arch-00 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 September 7, 2017. 42 Copyright Notice 44 Copyright (c) 2017 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. Compatibility of different forms of devices . . . . . . . . . 10 68 10. Control Protocol consideration . . . . . . . . . . . . . . . 10 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 13.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 The Broadband Network Gateway(BNG), which manages a routable IP 79 address on behalf of each subscriber, should be configured with the 80 IP address pools allocated to subscribers. However, currently 81 operators are facing with the address shortage problem, the remaining 82 IPv4 address pools are usually quite scattered, no more than /24 per 83 address pool in many cases. Therefore, it is complicated to manually 84 configure the address pools on lots of Broadband Network Gateway(BNG) 85 for operators. For large scale MAN, the number of BNGs can be up to 86 over one hundred. Manual configuration on all the BNGs statically 87 will not only greatly increase the workload, but also decrease the 88 utilization efficiency of the address pools when the number of 89 subscribers changes in the future. 91 Another use case which needs to configure the address pools is IPv6 92 migration. For IPv6 transition mechanisms, e.g. DS-Lite, lw4over6, 93 etc., they all need to be configured with address pools as translated 94 routeable addresses. When high availability features, e.g. active- 95 active/active-standby failover mechanism, etc., are enabled for these 96 IPv6 transition mechanisms, different address pools need to be 97 configured on each transition instance. This will further increase 98 the number of address pools need to be configured. Besides, the 99 occupation of the address pools may vary during different transition 100 periods, (e.g. at the early stage of IPv6 transition, IPv4 traffic 101 will normally occupy a great portion of the total traffic, while in 102 the later stage of IPv6 transition, IPv4 traffic will decrease and 103 the amount of IPv4 address pools will decrease accordingly. 105 There are other devices which may need to configure address pools as 106 well. For example, the Firewall need to configure the address pool 107 for acl/NAT process. The VPN also needs to configure the address 108 pools for end-users. 110 When SDN/NFV is introduced in the network, these devices (e.g. BNG, 111 CGN, firewall, VPN, etc.) will run as VNFs in virtualized 112 environment. A common centralized address management server can 113 interact with different VNFs and allocate address pools 114 automatically. 116 In this document, we propose a mechanism to manage the address pools 117 centrally. In this way, operators do not need to configure the 118 address pools one by one manually and it also helps to use the 119 address pools more efficiently. 121 2. Terminology 123 The following terms are used in this document: 125 APMS A management system which has a centralized databse manage 126 the overall address pools and allocate address pools to the device 127 in the devices. 129 DA A device agent in device, which contact with APM server to 130 manipulate address pool. 132 3. Architectural Overview 134 In this architecture, the Address Pool Management (APM) server is a 135 centralized address pool management server for operators to configure 136 the overall address pools. It maintains the address pool database 137 including the overall address pools (OAP) and the address pool 138 status(APS). Operators can configure its remaining address pools in 139 the OAP. They can also reserve some address pool for special-purpose 140 usage. The address pools status is to reflects the current usage of 141 the address pools for different devices. APM also has the interface 142 to configure the address pools to different devices dynamically. 144 In each device, there is an device agent (DA) to contact with APM 145 server. It initiates the address pools allocation requests, passes 146 the address pools to local instances, report the status of local 147 address pool usage and update the address pools requests, etc. For 148 some devices, e.g. v6transition, VPN, etc., additional routing 149 modules needs to update the routing table accordingly. 151 +*********************+ 152 | APM server | 153 | +------------+ | 154 | | Address DB | | 155 | +------------+ | 156 +***^*****^******^*^**+ 157 | | | 158 | | | 159 +------------+ | +------------+ 160 | | | 161 | | | 162 +------v------+ +------v------+ +------v------+ 163 | +--------+ | | +--------+ | | +--------+ | 164 | | agent | | | | agent | | | | agent | | 165 | +----+---+ | | +----+---+ | | +----+---+ | 166 | | | | | | | | | 167 | v | | v | | v | 168 | +--------+ | | +---------+ | | +---------+ | 169 | | Local | | | | v6tra | | | | VPN | | 170 | | Conf | | | | instance| | | |instance | | 171 | +--------+ | | +----+----+ | | +---------+ | 172 +-------------+ | | | | | | 173 | v | | v | | v | 174 | +---------+ | | +---------+ | | +---------+ | 175 | | routing | | | | routing | | | | routing | | 176 | +---------+ | | +---------+ | | +---------+ | 177 +-------------+ +-------------+ +-------------+ 178 BNG/vBNG v6tra/fw VPN 180 Figure 1: Interface to Address Pool Management (APM) 182 The overall procedure is as follows: 184 o Operators will configure remaining address pools centrally in the 185 Address Pool Management System (APMS). There are multiple address 186 pools which can be configured centrally. The APMS server will 187 then divide the address pools into addressing unit (AU) which will 188 be allocated to the agent in devices by default. 190 o The agent will initiate Address Pool request to the APMS. It can 191 carry its desired size of address pool the request, or just use a 192 default value. The address pool size in the request is only used 193 as a hint. The actual size of the address pool is totally 194 determined by APMS. It will also carry the DA's identification 195 and the type of address pool. 197 o APMS looks up the remaining address pool in its local database. 198 It will then allocate a set of address pools to the DA. Each 199 address pool has a related lifetime. 201 o DA receives the AddressPool reply and use them for their purpose. 203 o If the lifetime of the address pool is going to expire, the DA 204 should issue an AddressPoolRenew request to extend the 205 lifetime,including the IPv4, IPv6, Ports, etc. 207 o The AddressPoolReport module keeps monitoring and reports the 208 current usage of all current address pools for each transition 209 mechanism. if it is running out of address pools, it can renew the 210 AddressPoolRequest for a newly allocated one. It can also release 211 and recycle an existing address pool if the that address pool has 212 not been used for a specific and configurable time. 214 o When the connection of APMS is lost or the APMS needs the status 215 information of certain applications, the APMS may pre-actively 216 query the DA for the status information. 218 4. Initial Address Pool Configuration 219 +--------------+ +-----------------+ 220 | Device | |AddrPoolMangement| 221 | Agent | | Server | 222 +------+-------+ +--------+--------+ 223 | | 224 +--------+-------+ | 225 |1.DA start-up | | 226 +---------+------+ | 227 | 2.Address Pool Request | 228 |------------------------------------------>| 229 | | 230 | +--------+-------+ 231 | | 3. Check | 232 | | address pool | 233 | +--------+-------+ 234 | 4.Address Pool Reply | 235 |<------------------------------------------| 236 | | 237 | | 239 Figure 2: Initial Address Pool Configuration 241 Figure 2 illustrates the initial address pool configuration 242 procedure: 244 1. The DA checks whether there is already address pool configured in 245 the local site when it starts up. if no, it means the initial 246 start-up or the address pool has been released. if yes, the 247 address pool could be used directly. 249 2. The DA will initiate Address Pool request to the APMS. It can 250 carry its desired size of address pool in the request, or just 251 use a default value. The address pool size in the DA's request 252 is only used as a hint. The actual size of the address pool is 253 totally determined by APMS. It will also carry the DA's 254 identification, the type of transition mechanism and the 255 indication of port allocation support. 257 3. The APMS determines the address pool allocated for the DA based 258 on the parameters received. 260 4. The APMS sends the Address Pool Reply to the DA. It will also 261 distribute the routing entry of the address pool automatically. 262 In particular, if the newly received address pool can be 263 aggregated to an existing one, the routing should be aggregated 264 accordingly. 266 5. Address Pool Status Report 268 +--------------+ +-----------------+ 269 | Device | |AddrPoolMangement| 270 | Agent | | Server | 271 +------+-------+ +--------+--------+ 272 | | 273 +--------+-------+ | 274 |1.Monitor and | | 275 |count the status| | 276 +--------+-------+ | 277 | 2.Address Pool Status Report | 278 |--------------------------------------------->| 279 | +--------+-------+ 280 | | 3. Record | 281 | | address pool | 282 | +--------+-------+ 283 | 4.Address Pool Report Confirm | 284 |<---------------------------------------------| 285 | | 286 | | 288 Figure 3: Address Pool Status Report 290 Figure 3 illustrates the active address pool status report procedure: 292 1. The DA will monitor and count the usage status of the local 293 address pool. The DA counts the address usage status in one 294 month, one week and one day, which includes the local address, 295 address usage ratio (peak and average values), and the port usage 296 ratio (peak and average values). 298 2. The DA reports the address pool usage status to the APMS. for 299 example, it will report the address usage status in one day, 300 which contains the IP address, NAT44, address list: 301 30.14.44.0/28, peak address value 14, average address usage ratio 302 90%, TCP port usage ratio 20%, UDP port usage ratio 30% and etc. 304 3. The APMS records the status and compares with the existing 305 address information to determine whether additional address pool 306 is needed. 308 4. The APMS will confirm the address pool status report request to 309 the DA. It will keep sending the address pool status report 310 request to the APMS if no confirm message is received. 312 6. Address Pool Status Query 314 When the status of APMS is lost or the AMS needs the status 315 information of the DAs, the APMS may actively query the TD for the 316 status information, as shown in step 1 of Figure 4. The following 317 steps 2,3,4,5 are the same as the Address Pool Status Report 318 procedure. 320 +--------------+ +-----------------+ 321 | Device | |AddrPoolMangement| 322 | Agent | | Server | 323 +------+-------+ +--------+--------+ 324 | | 325 | | 326 | 1.Address Pool Status Query | 327 |<---------------------------------------------| 328 | | 329 +--------+-------+ | 330 |2.Monitor and | | 331 |count the status| | 332 +--------+-------+ | 333 | 3.Address Pool Status Report | 334 |--------------------------------------------->| 335 | +--------+-------+ 336 | | 4. Record | 337 | | address pool | 338 | +--------+-------+ 339 | 5.Address Pool Report Confirm | 340 |<---------------------------------------------| 341 | | 342 | | 344 Figure 4: Address Pool Status Query 346 7. Address Exhaustion 348 When the DA uses up the addresses allocated, it will renew the 349 address pool request to the APMS for an additional address pool. The 350 procedure is the same as the initial address pool request. 352 8. Address Pool Release 353 +--------------+ +-----------------+ 354 | Device | |AddrPoolMangement| 355 | Agent | | Server | 356 +------+-------+ +--------+--------+ 357 | | 358 +--------+-------+ | 359 |1.Address pools | | 360 | not used for a| | 361 | long time | | 362 +--------+-------+ | 363 | 2.Address Pool Release Request | 364 |--------------------------------------------->| 365 | +--------+-------+ 366 | |3. Update | 367 | | address pool | 368 | | database | 369 | +--------+-------+ 370 | 4.Address Pool Release Notification | 371 |<---------------------------------------------| 372 +--------+-------+ | 373 |5. Reduce | | 374 | address pool | | 375 +--------+-------+ | 376 | 6.Address Pool Release Confirm | 377 |--------------------------------------------->| 378 | | 379 | | 381 Figure 5: Address Pool Release 383 Figure 5 illustrates the address pool release procedure: 385 1. The counting module in the DA checks that there are addresses not 386 used for a long time; 388 2. The DA sends the address pool release request to the APMS to ask 389 the release of those addresses; 391 3. The APMS updates the local address pool information to add the 392 new addressed released. 394 4. The APMS notifies the TD that the addresses have been release 395 successfully; 397 5. The DA will update the local address pool. if no Address Pool 398 Release Notification is received, the DA will repeat step 2; 400 6. The DA confirms with the APMS that the addres pool has been 401 released successfully. 403 9. Compatibility of different forms of devices 405 As described in section 3, each device has its address pools, the 406 Address Pool Management (APM) server act as a centralized address 407 pool management server for operators to configure the overall address 408 pools of each devices. In this form of device, the user plane and 409 the control plane are integrated in the box. There are another form 410 of device, the control plane is separated from the box and one or 411 more devices share centralized control plane. In this device form, 412 the control plane will manage multiple user plane devices. A number 413 of devices that are subordinate to a control plane will jointly share 414 the address pools. The control plane device, together with the 415 dependent multiple user plane devices, forms a "big" device. This 416 bigger device contacts with the APM server to manipulate IP address 417 pool. For example, the device acts as a server side when running the 418 NETCONF protocol between the device and the APM. It determines 419 whether the usage status of the IP address pool resource in device is 420 satisfies the condition. For example, the address pool resource of 421 device is not enough or excessive. It sends address pools resource 422 request to the APM server, and receives response with address pools 423 resource for this device allocated from APM server. Then it passes 424 the address pools resource to local instances. In addition, it 425 report the status of local address pool resource usage and update the 426 address pools requests, etc. 428 10. Control Protocol consideration 430 The I2APM architecture consists of two major distinct entities: APM 431 Server and network equipment with an APM Agent. In order to provide 432 address pool manipulations between these two entities, the I2APM 433 architecture calls for well-defined protocols for interfacing between 434 them. For compatibility with legacy network equipment, the 435 architecture reuse legacy protocol such as radius. While the IETF 436 may also choose to define one or more specific approaches to 437 manipulate address pool, such as NETCONF or RESTCONF with address 438 pool YANG data model.In modern network management system, the NETCONF 439 or RESTCONF is used widely, the device implements as the NETCONF or 440 RESTCONF server, and the network management system implements as the 441 NETCONF or RESTCONF client, that achieving more automated network 442 management. 444 11. Security Considerations 446 12. Acknowledgements 448 N/A. 450 13. References 452 13.1. Normative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, 456 DOI 10.17487/RFC2119, March 1997, 457 . 459 13.2. Informative References 461 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 462 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 463 DOI 10.17487/RFC6674, July 2012, 464 . 466 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 467 A., and H. Ashida, "Common Requirements for Carrier-Grade 468 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 469 April 2013, . 471 Authors' Addresses 473 Chen Li 474 China Telecom 475 No.118 Xizhimennei street, Xicheng District 476 Beijing 100035 477 P.R. China 479 Email: lichen.bri@chinatelecom.cn 481 Chongfeng Xie 482 China Telecom 483 No.118 Xizhimennei street, Xicheng District 484 Beijing 100035 485 P.R. China 487 Email: xiechf.bri@chinatelecom.cn 488 Jun Bi 489 Tsinghua University 490 3-212, FIT Building, Tsinghua University, Haidian District 491 Beijing 100084 492 P.R. China 494 Email: junbi@tsinghua.edu.cn 496 Weiping Xu 497 Huawei Technologies 498 Bantian, Longgang District 499 shenzhen 518129 500 P.R. China 502 Email: xuweiping@huawei.com