idnits 2.17.1 draft-li-opsawg-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 12 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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 (June 28, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8309' is mentioned on line 669, but not defined == Unused Reference: 'RFC2132' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC6020' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC8040' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'RFC6888' is defined on line 717, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 10 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: December 30, 2018 R. Kumar 6 R. Lohiya 7 Juniper Networks 8 G. Fioccola 9 Telecom Italia 10 W. Xu 11 W. Liu 12 Huawei Technologies 13 D. Ma 14 ZDNS 15 J. Bi 16 Tsinghua University 17 June 28, 2018 19 Coordinated Address Space Management architecture 20 draft-li-opsawg-address-pool-management-arch-01 22 Abstract 24 IP addresses work as a basic element for providing broadband network 25 services. However, the increase in number, diversity and complexity 26 of modern network devices and services creates unprecedented 27 challenges for the currently prevailing approach of manual IP address 28 management. Manually maintaining IP addresses could always be sub- 29 optimal for IP resource utilization. Besides, it requires heavy 30 human effort from network operators. To achieve high utilization and 31 flexible scheduling of IP network addresses, it is necessary to 32 automate the address scheduling process. This document describes an 33 architecture for the IP address space management. It includes 34 architectural concepts and components used in the CASM (Coordinated 35 Address Space Management), with a focus on those interfaces to be 36 standardized in the IETF. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 30, 2018. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. CASM Reference architecture . . . . . . . . . . . . . . . . . 4 75 4. The overall procedure of CASM . . . . . . . . . . . . . . . . 7 76 5. CASM Interface and operation . . . . . . . . . . . . . . . . 8 77 5.1. CASM App-facing Interface . . . . . . . . . . . . . . . . 8 78 5.1.1. Functional requirements . . . . . . . . . . . . . . . 8 79 5.1.2. Interface modeling requirements . . . . . . . . . . . 9 80 5.2. CASM device-facing Interface . . . . . . . . . . . . . . 9 81 5.2.1. Functional requirements . . . . . . . . . . . . . . . 10 82 5.2.2. Interface modeling requirements/Initial Address Pool 83 Configuration . . . . . . . . . . . . . . . . . . . . 10 84 5.2.3. Interface modeling requirements/Address Pool Status 85 Report . . . . . . . . . . . . . . . . . . . . . . . 12 86 5.2.4. Interface modeling requirements/Address Pool Status 87 Query . . . . . . . . . . . . . . . . . . . . . . . . 13 88 5.2.5. Interface modeling requirements/Address Exhaustion . 13 89 5.2.6. Interface modeling requirements / Address Pool 90 Release . . . . . . . . . . . . . . . . . . . . . . . 14 91 6. Services SDN Management Use Cases . . . . . . . . . . . . . . 15 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 96 9.2. Informative References . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 The address space management is an integral part of any network 102 management solution. However, the increase in number, diversity and 103 complexity of modern network devices and services creates 104 unprecedented challenges for the currently prevailing approach of 105 manual IP address management. Manually maintaining IP addresses 106 could always be sub-optimal for IP resource utilization. Besides, it 107 requires heavy human effort from network operators. 109 Another factor which drive this work is that tThe network 110 architectures are rapidly changing with the migration toward private 111 and public clouds. At the same time, application architectures are 112 also evolving with a shift toward micro-services and multi-tiered 113 approach. 115 There is a pressing need to define a new address management system 116 which can meet these diverse set of requirements. To achieve high 117 utilization and flexible scheduling of IP network addresses, Such a 118 system should be capable of automating the address scheduling 119 process. Such a system must be built with well-defined interfaces so 120 users can easily migrate from one vendor to another without rewriting 121 their network management systems. 123 This document defines a reference architecture that should become the 124 basis to develop a new address management system. This system is 125 called Coodinated Address Space Management (CSAM) system. 127 A series of use cases are defined in "Use Case Draft". For example, 128 Broadband Network Gateway (BNG), which manages a routable IP address 129 on behalf of each subscriber, should be configured with the IP 130 address pools allocated to subscribers. However, currently operators 131 are facing with the address shortage problem, the remaining IPv4 132 address pools are usually quite scattered, no more than /24 per 133 address pool in many cases. Therefore, it is complicated to manually 134 configure the address pools on lots of Broadband Network Gateway 135 (BNG) for operators. For large scale Metro Area Network (MAN), the 136 number of BNGs can be up to over one hundred. Manual configuration 137 on all the BNGs statically will not only greatly increase the 138 workload, but also decrease the utilization efficiency of the address 139 pools when the number of subscribers changes over time in the future. 141 Above is one example of use case, there are other devices which may 142 need to configure address pools as well. In this document, we 143 propose a general mechanism to manage the address pools coordinately, 144 which can be used in multiple use cases. With this approach, 145 operators do not need to configure the address pools one by one 146 manually and it also helps to use the address pools more efficiently. 148 2. Terminology 150 The following terms are used in this document: 152 CASM: Coordinated Address Space Management, a newly-defined 153 general architecture which can automate IP address management for 154 wide-variety of use cases 156 IPAM: IP Address Management, a means of planning, tracking, and 157 managing the Internet Protocol address space used in a network 159 DA: A device agent within the device, which contacts with CASM 160 Coordinator to manipulate address pool 162 CASM Coordinator: A management system which has a database manage 163 the overall address pools and allocate address pools to devices. 165 3. CASM Reference architecture 167 The figure below shows the reference architecture for CASM. This 168 figure covers the various possible scenarios that can exist in future 169 network. 171 +-------------+ +-------------+ +-------------+ 172 | CASM | | CASM | | CASM | 173 |application 1| |application j| |application n| 174 +------/------+ +------/------+ +------/------+ 175 | | | 176 | | | 177 | | | 178 | | | 179 +-------\---------------------\---------------------\-------+ 180 | Coordinated Address Space Management System (CASM) | 181 | Coordinator | 182 | +-------------+ +-------------+ +-------------+ | 183 | | Pool | | Address | | Address | | 184 | | Management | | Management | | Database | | 185 | +-------------+ +-------------+ +-------------+ | 186 | | 187 +---.-------------------------.--------------------------.--+ 188 | | | 189 | | | 190 | | | 191 | | | 192 | | | 193 +----------\--------+ +---------\---------+ +--------\----------+ 194 | | | | | | 195 | +-------------+ | | +-------------+ | | +-------------+ | 196 | | DA | | | | DA | | | | DA | | 197 | +-------------+ | | +-------------+ | | +-------------+ | 198 | | | | | | 199 | +-------------+ | | +-------------+ | | +-------------+ | 200 | | CASM | | | | CASM | | | | CASM | | 201 | | Distributor | | | | Distributor | | | | Distributor | | 202 | +-------------+ | | +-------------+ | | +-------------+ | 203 | Device 1 | | Device 2 | | Device m | 204 +-------------------+ +-------------------+ +-------------------+ 206 Figure 1: CASM reference architecture 208 Each component of CASM is introduced as below, 210 1) CASM Application 212 The CASM Application is a functional entity which usually has the 213 requirements of centralized address management to realize its 214 specific upper-layer functions. In order to achieve this goal, it 215 needs to manage, operate and maintain the CASM Coordinator. For 216 example, an operator or external user can manage the address pool in 217 the CASM Coordinator, as well as access log, address allocation 218 records, etc. 220 2) CASM Coordinator 222 The CASM Coordinator is a coordinated address management coordinator 223 for the CASM Application to maintain overall address pools, 224 addresses, address properties, etc. It maintains an address database 225 including the overall address pools (OAP) and the address pool status 226 (APS). CASM Applications can maintain their remaining address pools 227 in the OAP. They can also reserve some address pools for special 228 purposes. The address pool status is to reflect the current usage of 229 address pools for different devices. The CASM Coordinator also has 230 the capability to maintain the address pools to different devices 231 dynamically. 233 3) CASM Device 235 A CASM Device is responsible for distributing or allocating addresses 236 from local address pools received from the CASM Coordinator. CASM 237 has two components in devices. The first one is Device Agent (DA), 238 which resides in a CASM Device through which the device can contact 239 with the CASM Coordinator. On behalf of the device, the agent 240 initiates the address pool allocation requests, passes the address 241 pools to local instances, detect the availability of address pools or 242 report the status of local address pool usage and update the address 243 pool requests, etc. For some devices, e.g. IPv6 transition and VPN, 244 additional routing modules are needed to update the routing table 245 accordingly. 247 The CASM Distributor is another component in a CASM device. The DHCP 248 server is a typical distributor that can assign IP addresses to 249 client hosts, and the DHCP protocol is usually used for this task. 250 The address assignment procedure between the CASM Distributor and the 251 client host is out of the scope of this document. 253 The device determines whether the usage status of the IP address pool 254 resource within the device satisfies the condition. When the IP 255 address pool resource in the device is insufficient or excessive, the 256 device will obtain IP address pool resource request, and sends the 257 request to the CASM Coordinator. The device receives a resource 258 response with IP address pools allocated for it, then it use these 259 address pools to assign IP addresses to end users. Typical CASM 260 Devices include BNGs, BRASes, CGNs, DHCP Servers, NATs, IPv6 261 Transitions, DNS Servers, etc. 263 The form of devices is diverse, it can be physical or virtual, and it 264 can be box-integrated with a control plane and a user plane, or a 265 separated control plane remote from the box, where one or more 266 devices share the centralized control plane. In the latter case, the 267 control plane will manage multiple user plane devices. A number of 268 devices that are subordinate to the control plane will jointly share 269 the address pools to make address utilization much higher. 271 4. The overall procedure of CASM 273 1. Operators configure remaining address pools centrally in the CASM 274 Coordinator. There are multiple address pools that can be 275 configured. The CASM Coordinator server then divides the address 276 pools into addressing units (AUs) which would be allocated to 277 device agents by default. 279 2. The agent will initiate an AddressPool request to the CASM 280 Coordinator. It can carry its desired size of address pool with 281 the request, or just use a default value. The address pool size 282 in the request is only used as a hint. The actual size of the 283 address pool is totally determined by the CASM Coordinator. It 284 would also carry the DA's identification and the type of the 285 address pool. 287 3. The CASM Coordinator looks up remaining address pools in its 288 local database, and then allocates a set of address pools to the 289 DA. Each address pool has a lifetime. 291 4. The DA receives the AddressPool reply and uses it for its 292 purpose. 294 5. If the lifetime of the address pool is going to expire, the DA 295 should issue an AddressPoolRenew request to extend it, including 296 IPv4, IPv6, port numbers, etc. 298 6. The AddressPoolReport module keeps monitoring and reports the 299 usage of all current address pools for each transition mechanism. 300 If it is running out of address pools, it can renew the 301 AddressPoolRequest for a newly allocated one. It can also 302 release and recycle an existing address pool if that address pool 303 has not been used for a specific and configurable time. 305 7. When the connection of the CASM Coordinator is lost or it needs 306 the status information of certain applications, it may pre- 307 actively query the DA for its status information. 309 Currently, the CASM system focuses on the coordination of IP address 310 resources. This Solution should be extended to handle containers, 311 VLAN assignments, etc. These are subject for future work. 313 5. CASM Interface and operation 315 5.1. CASM App-facing Interface 317 The CASM architecture consists of three major distinct entities: CASM 318 Application, CASM Coordinator and network device with a device Agent 319 (DA). In order to provide address space and pools resource that CASM 320 Coordinator can centrally maintain, there is an interface between 321 CASM Applications and CASM Coordinator. The CASM Application can 322 manage the address space and pool in the CASM Coordinator, and the 323 get address allocation records, logs from CASM Coordinator. 325 5.1.1. Functional requirements 327 The CASM should support following functionality for it to be adopted 328 for wide variety of use cases. 330 1. Address pools requirements 332 A CASM system should allow ability to manage different kind of 333 address pools. The following pools should be considered for 334 implementation; this is not mandatory or exhaustive by any means but 335 given here as most commonly used in networks. The CASM system should 336 allow user-defined pools with any address objects. 338 Unicast address pool: 340 o Private IPv4 addresses 342 o Public IPv4 addresses 344 o IPv6 addresses 346 o MAC Addresses 348 Multicast address pool: 350 o IPv4 address 352 o IPv6 address 354 2. Pool management requirements 356 There should be a rich set of functionality as defined in this 357 section for operation of a given pool. 359 Address management: 361 o Address allocation either as single or block 363 o Address reservation 365 o Allocation logic such as mapping schemes or algorithm per pool 367 o 369 General management: 371 o Pool initializing, resizing, threshold markings for resource 372 monitoring 374 o Pool attributes such as used to automatically create DNS record 376 o Pool priority for searching across different pools 378 o Pool fragmentation rules, such as how pool can be sub-divided 380 o Pool lease rules for allocation requests 382 5.1.2. Interface modeling requirements 384 There are three broad categories for CASM interface definition: 386 Pool management interface: Interface to external user or applications 387 such as SDN controller to manage addresses 389 Log interface: Interface to access log and records such as DHCP, DNS, 390 NAT Integration interface: Interface to address services such as 391 DHCP, DNS, NAT 393 5.2. CASM device-facing Interface 395 In order to provide address pool manipulations between CASM 396 Coordinator and device, the CASM architecture calls for well-defined 397 protocols for interfacing between them. Protocol such as radius can 398 be used to compatible with legacy network equipment. And in more 399 modern network system, network device acts as NETCONF/RESTCONF server 400 side, device like CASM Coordinator act as client side. The network 401 device sends address pool request message carrying the requested 402 resource information to the CASM Coordinator, the CASM Coordinator 403 send response message to the network device, where the response 404 message includes address pool resource information allocated to the 405 network device, and network device receives the response message and 406 retrieve the allocated address pool resource information carried in 407 the response message. 409 5.2.1. Functional requirements 411 In order to build a complete address management system, it is 412 important that CASM should be able to integrate with other address 413 services. This will provide a complete solution to network operators 414 without requiring any manual or proprietary workflows. 416 DHCP server: 418 o Interface to initialize address pools on DHCP server 420 o Notification interface whenever an address lease is modified 422 o Interface to access address lease records from DHCP server 424 o Ability to store lease records and play back to DHCP server on 425 reboot 427 DNS server: 429 o Interface to create DNS records on DNS server based on DHCP server 430 events 432 NAT device: 434 o Interface to initialize NAT pools 436 o Interface to access NAT records from NAT device 438 o Ability to store NAT records and play back to NAT device on reboot 440 5.2.2. Interface modeling requirements/Initial Address Pool 441 Configuration 442 +--------------+ +-----------------+ 443 | Device | | CASM | 444 | Agent | | Coordinator | 445 +------+-------+ +--------+--------+ 446 | | 447 +--------+-------+ | 448 |1.DA start-up | | 449 +---------+------+ | 450 | 2.Address Pool Request | 451 |------------------------------------------>| 452 | | 453 | +--------+-------+ 454 | | 3. Check | 455 | | address pool | 456 | +--------+-------+ 457 | 4.Address Pool Reply | 458 |<------------------------------------------| 459 | | 461 Figure 2: Initial Address Pool Configuration 463 As shown in Figure 2, the procedure is as follows: 465 1. The DA checks whether there is already address pool configured in 466 the local site when it starts up. 468 2. The DA will initiate Address Pool request to the CASM 469 Coordinator. It can carry its desired size of address pool in 470 the request, or just use a default value. The address pool size 471 in the DA's request is only used as a hint. The actual size of 472 the address pool is totally determined by CASM Coordinator. It 473 will also carry the DA's identification, the type of transition 474 mechanism and the indication of port allocation support. 476 3. The CASM Coordinator determines the address pool allocated for 477 the DA based on the parameters received. 479 4. The CASM Coordinator sends the Address Pool Reply to the DA. It 480 will also distribute the routing entry of the address pool 481 automatically. In particular, if the newly received address pool 482 can be aggregated to an existing one, the routing should be 483 aggregated accordingly. 485 5.2.3. Interface modeling requirements/Address Pool Status Report 487 +--------------+ +-----------------+ 488 | Device | | CASM | 489 | Agent | | Coordinator | 490 +------+-------+ +--------+--------+ 491 | | 492 +--------+-------+ | 493 |1.Monitor and | | 494 |count the status| | 495 +--------+-------+ | 496 | 2.Address Pool Status Report | 497 |--------------------------------------------->| 498 | +--------+-------+ 499 | | 3. Record | 500 | | address pool | 501 | +--------+-------+ 502 | 4.Address Pool Report Confirm | 503 |<---------------------------------------------| 504 | | 505 | | 507 Figure 3: Address Pool Status Report 509 Figure 3 illustrates the active address pool status report procedure: 511 1. The DA will monitor and count the usage status of the local 512 address pool. The DA counts the address usage status in one 513 month, one week and one day, which includes the local address, 514 address usage ratio (peak and average values), and the port usage 515 ratio (peak and average values). 517 2. The DA reports the address pool usage status to the CASM 518 Coordinator. For example, it will report the address usage 519 status in one day, which contains the IP address, NAT44, address 520 list: 30.14.44.0/28, peak address value 14, average address usage 521 ratio 90%, TCP port usage ratio 20%, UDP port usage ratio 30% and 522 etc. 524 3. The CASM Coordinator records the status and compares with the 525 existing address information to determine whether additional 526 address pool is needed. 528 4. The CASM Coordinator will confirm the address pool status report 529 request to the DA. It will keep sending the address pool status 530 report request to the CASM Coordinator if no confirm message is 531 received. 533 5.2.4. Interface modeling requirements/Address Pool Status Query 535 When the status of CASM Coordinator is lost or the CASM Coordinator 536 needs the status information of the DAs, the CASM Coordinator may 537 actively query the TD for the status information, as shown in step 1 538 of Figure 4. The following steps 2,3,4,5 are the same as the Address 539 Pool Status Report procedure. 541 +--------------+ +-----------------+ 542 | Device | | CASM | 543 | Agent | | Coordinator | 544 +------+-------+ +--------+--------+ 545 | | 546 | | 547 | 1.Address Pool Status Query | 548 |<---------------------------------------------| 549 | | 550 +--------+-------+ | 551 |2.Monitor and | | 552 |count the status| | 553 +--------+-------+ | 554 | 3.Address Pool Status Report | 555 |--------------------------------------------->| 556 | +--------+-------+ 557 | | 4. Record | 558 | | address pool | 559 | +--------+-------+ 560 | 5.Address Pool Report Confirm | 561 |<---------------------------------------------| 562 | | 563 | | 565 Figure 4: Address Pool Status Query 567 5.2.5. Interface modeling requirements/Address Exhaustion 569 When the addresses used by the DA reaches a certain usage threshold, 570 the DA will renew the address pool request to the CASM Coordinator 571 for an additional address pool. The procedure is the same as the 572 initial address pool request. 574 5.2.6. Interface modeling requirements / Address Pool Release 576 +--------------+ +-----------------+ 577 | Device | | CASM | 578 | Agent | | Coordinator | 579 +------+-------+ +--------+--------+ 580 | | 581 +--------+-------+ | 582 |1.Address pools | | 583 | not used for a| | 584 | long time | | 585 +--------+-------+ | 586 | 2.Address Pool Release Request | 587 |--------------------------------------------->| 588 | +--------+-------+ 589 | |3. Update | 590 | | address pool | 591 | | database | 592 | +--------+-------+ 593 | 4.Address Pool Release Notification | 594 |<---------------------------------------------| 595 +--------+-------+ | 596 |5. Reduce | | 597 | address pool | | 598 +--------+-------+ | 599 | 6.Address Pool Release Confirm | 600 |--------------------------------------------->| 601 | | 602 | | 604 Figure 5: Address Pool Release 606 Figure 5 illustrates the address pool release procedure: 608 1. The counting module in the DA checks if the usage threshold of 609 address pool reaches a certain condition; 611 2. The DA sends the address pool release request to the CASM 612 Coordinator to ask the release of those addresses; 614 3. The CASM Coordinator updates the local address pool information 615 to add the new addressed released; 617 4. The CASM Coordinator notifies the TD that the addresses have been 618 release successfully; 620 5. The DA will update the local address pool. If no Address Pool 621 Release Notification is received, the DA will repeat step 2; 623 6. Optionally, the DA confirms with the CASM Coordinator that the 624 address pool has been released successfully. 626 6. Services SDN Management Use Cases 628 ------------- 629 | CASM | 630 | Application | 631 ------------- 632 : 633 ------------------ 634 | Provider | 635 | Orchestrator | 636 | | 637 .------------------. 638 . : . 639 . : . 640 ------------ ------------ ------------ 641 | | | | | | 642 | Controller | | Controller | | Controller | 643 | | | | | | 644 ------------ ------------ ------------ 645 : . . : 646 : . . : 647 : . . : 648 --------- --------- --------- --------- 649 | Network | | Network | | Network | | Network | 650 | Element | | Element | | Element | | Element | 651 --------- --------- --------- --------- 653 Figure 6: L3 and L2 Services Orchestration 655 Network Operators need to manage addressing of undelay network 656 elements in order to build end-to-end services and private or public 657 clouds. So address management of customer equipments, provider 658 edges, but also of virtual machines, virtual functions and overlay 659 networks is a very important task. In general the SDN Orchestrators 660 and other management systems must coordinate addressing schemes to 661 ensure network operation. There is need for one address management 662 system that would meet the requirements of such a network deployment. 663 The SDN Orchestrator manages IPv4, IPv6 addresses and also MAC 664 addresses to assign to network interfaces in order to install end-to- 665 end services, and this task can be achieved by the CASM coordination. 667 A typical use case is the application to the Service provisioning of 668 L3VPN and L2VPN by the SDN orchestration level. For example the 669 architecture presented in [RFC8309] and, more in general in every SDN 670 architecture, could be integrated with CASM. It is important to 671 mention also the possibility of Multi-Provider services, and in this 672 case the two CASM coordinators of the two involved Providers should 673 synchronize. The following Figure shows how CASM Application can 674 communicate with both the Network Operator Orchestrator and, in case 675 of Multi-Provider Service, with another Network Operator Orchestrator 676 too. 678 7. Security Considerations 680 8. Acknowledgements 682 N/A. 684 9. References 686 9.1. Normative References 688 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 689 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 690 . 692 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 693 C., and M. Carney, "Dynamic Host Configuration Protocol 694 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 695 2003, . 697 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 698 the Network Configuration Protocol (NETCONF)", RFC 6020, 699 DOI 10.17487/RFC6020, October 2010, 700 . 702 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 703 and A. Bierman, Ed., "Network Configuration Protocol 704 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 705 . 707 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 708 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 709 . 711 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 712 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 713 May 2017, . 715 9.2. Informative References 717 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 718 A., and H. Ashida, "Common Requirements for Carrier-Grade 719 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 720 April 2013, . 722 Authors' Addresses 724 Chen Li 725 China Telecom 726 No.118 Xizhimennei street, Xicheng District 727 Beijing 100035 728 P.R. China 730 Email: lichen@ctbri.com.cn 732 Chongfeng Xie 733 China Telecom 734 No.118 Xizhimennei street, Xicheng District 735 Beijing 100035 736 P.R. China 738 Email: xiechf.bri@chinatelecom.cn 740 Rakesh Kumar 741 Juniper Networks 742 1133 Innovation Way 743 Sunnyvale CA 94089 744 US 746 Email: rkkumar@juniper.net 748 Anil Lohiya 749 Juniper Networks 750 1133 Innovation Way 751 Sunnyvale CA 94089 752 US 754 Email: alohiya@juniper.net 755 Giuseppe Fioccola 756 Telecom Italia 757 Via Reiss Romoli, 274 758 Torino 10148 759 Italy 761 Email: giuseppe.fioccola@telecomitalia.it 763 Weiping Xu 764 Huawei Technologies 765 Bantian, Longgang District 766 shenzhen 518129 767 P.R. China 769 Email: xuweiping@huawei.com 771 Will(Shucheng) Liu 772 Huawei Technologies 773 Bantian, Longgang District 774 shenzhen 518129 775 P.R. China 777 Email: liushucheng@huawei.com 779 Di Ma 780 ZDNS 781 4 South 4th St. Zhongguancun 782 Beijing 100190 783 P.R. China 785 Email: madi@zdns.cn 787 Jun Bi 788 Tsinghua University 789 3-212, FIT Building, Tsinghua University, Haidian District 790 Beijing 100084 791 P.R. China 793 Email: junbi@tsinghua.edu.cn