Automation Scenarios and Requirements for Level 4 Autonomous Networking (AN)
draft-yu-ccamp-service-automation-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
Document | Type | Active Internet-Draft (individual) | |
---|---|---|---|
Authors | Chaode Yu , Yang Zhao , LIUYUCONG | ||
Last updated | 2024-10-21 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-yu-ccamp-service-automation-00
CCAMP Working Group C. Yu Internet-Draft Huawei Technologies Intended status: Standards Track Y. Zhao Expires: 24 April 2025 Y. Liu China Mobile 21 October 2024 Automation Scenarios and Requirements for Level 4 Autonomous Networking (AN) draft-yu-ccamp-service-automation-00 Abstract This document describes OTN-WDM service automation and collaboration scenarios in transport networks and defines the functional requirements of domain controller in these scenarios. 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 https://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 24 April 2025. Copyright Notice Copyright (c) 2024 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 (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Yu, et al. Expires 24 April 2025 [Page 1] Internet-Draft service automation October 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Wavelength Adjustment Automation . . . . . . . . . . . . . . 3 2.1. Resource Planning and Validation . . . . . . . . . . . . 3 2.2. Reachability . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Pre-configuration . . . . . . . . . . . . . . . . . . . . 4 3. OTN Service Automation . . . . . . . . . . . . . . . . . . . 4 4. Service Assurance Automation . . . . . . . . . . . . . . . . 5 5. Manageability Considerations . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction There are a lot of discussions in the industry on the grading of Autonomous Networking (AN). [TMF-IG1252] suggests that the intelligence level of network can be graded into six levels, level 0 to level5. The higher level of intelligence, the fewer workflows will be manually involved, or the lower of the level of manual participation in the relevant workflows. Most of the people agree that, basic automation has been achieved in level3. And for level4, higher intelligence should be introduced to network operation and management, such as introducing AI/ML for assistance on analysis and making decision. Currently, the E2E service provisioning of transport network can be divided into two steps: provisioning of WDM service and OTN service. The provisioning of WDM service should be ahead of OTN service provisioning. And it may take one to three weeks to finish the whole service provisioning. The service provisioning of WDM service takes most of the time period. The provisioning of WDM service involves multiple department collaboration. The design department needs to accomplish the route planning, resource validation, budget determination, solution review and archiving. The Operation and maintenance department needs to accomplish resource confirmation, resource warning, restriction output, wavelength output and supplement of fiber or PSU .etc. A lot of departments need to validate the resource again and again. Once there are any conflicts, the design work needs to be restarted. This situation is more serious when the planning data is not consistent with the real data. So that the service provisioning TTM (time to market) cannot be guaranteed. Yu, et al. Expires 24 April 2025 [Page 2] Internet-Draft service automation October 2024 We consider that the current works on WDM and OTN in IETF are focusing on the automation on single level, it can support the intelligence of Level3. Only when the automation on the collaboration between OTN and WDM is achieved, service provisioning can be graded into level4. By the way, for full lifecycle management, we investigate the automation of maintenance in WDM-OTN synergy scenario. To be noted that, the transport network discussed in this document not only includes a network of single vendor, but also a partial disaggregation network (IP pluggable is also applicable). 2. Wavelength Adjustment Automation For the automation of WDM service, we consider that it needs to be improved in three aspects, including resource planning and validation, ensuring that service path calculation results are reachable, and supporting pre-configuration as planning. 2.1. Resource Planning and Validation The resource here indicates those physical devices and logical objects required by WDM service provisioning, e.g. physical devices like NE, board, port, fiber, or logical objects like wavelength. The base model in IVY working group has included these physical objects, but for the state information of these devices, it has not been covered, especially for the planning status and deployment status. A mismatch of planning status and deployment status is a common scenario in live network. If a planning resource is adopted in planning process but it is not deployed actually, it will make the resource validation fails. The solution needs to be re-designed and devices needs to be coordinated. It is wasting time. It is also needed to recognize whether the existing resource can be re-used or whether new boards need to be deployed during resource planning online process. The online planning also needs to ensure that wavelengths are idle. Currently, the WDM topology model has defined frequencies, and the domain controller needs to report these data and their changes. Yu, et al. Expires 24 April 2025 [Page 3] Internet-Draft service automation October 2024 2.2. Reachability Currently, the IETF has defined the TE tunnel path computation model and the WDM extension model. The path computation model supports multiple path computation constraints, including explicit or excluded NEs, ports and label hop, supports multiple minimum computation policies, and path separation policies. Risky link groups, and wavelength information can be specified. However, this still cannot ensure that the calculated path is reachable. For example, the current path computation interface does not support regeneration scenarios or WDM parameter commissioning. Optical parameters include the real-time fiber attenuation, EOL attenuation, and nominal gain of OA boards. To ensure that the commissioning is successful, you need to accurately evaluate the optical parameter margin based on the WDM parameters, inventory data, and WDM service configuration data. In addition, you need to simulate the service optical path modeling by using technologies such as digital twin based on the non-linear fiber model. 2.3. Pre-configuration Pre-configuration as planning includes pre-configuration of new resource and pre-configuration of OCH. If the planned path does not involve new resources, the domain controller needs to maintain related information in it, such as putting pre-occupation tags to the planned resources. In this way, these resources will not be used by other path planning. This ensures that subsequent configuration delivery to NEs does not fail due to conflicts. Even if there are new resources need to be deployed, the domain controller also needs to maintain this pre-occupation tag for these new resources. The life cycle of a planned path can be planned, engineering, or deployed. The planning state indicates that the design department has completed the path design but has not been delivered to the domain controller. In the engineering state, the designed path is delivered to the domain controller and resources are pre-occupied. In the deployment state, the service is activated and resources are occupied in reality. We suggest that the domain controller can provide different life cycle views for different user groups when querying paths. 3. OTN Service Automation Because WDM layer is the server layer of OTN layer, in the level 3 of AN, OTN service cannot be automatically provisioned until WDM service is ready. By other words, the E2E service needs to be created layer by layer, which is a bottom-up approach. Yu, et al. Expires 24 April 2025 [Page 4] Internet-Draft service automation October 2024 The readiness of WDM does not only include the provisioning of WDM service, but also including the commissioning. A common understanding for level 3 of AN, the commissioning work is not required to be done automatically but manually. So the E2E service provisioning is not totally automatic. Days would be taken for the whole process. With more and more emergence of AI usage scenarios, such as chat-GPT, various industries have strong requirements for computing power. They need to connect their industry data with the computing power center for model training and inference, making decision .etc. OTN service have got great advantage on the connection of computing power, such as large bandwidth, low latency, high reliability, and hard isolation. But the connection is not used in every minute, considering the cost of connection, the industry customers would require OTN service to support flexible provisioning and deletion capability. Days-level of AND level 3 cannot satisfy this requirement. For the level 4, the OTN service automation does not require the WDM service is ready before OTN service provisioning. The domain controller can decide to reuse the existing WDM service or to create a new one which is a top-down approach. The WDM service is commissioned during the process. The time taken will be reduced into minute-level which can satisfy most of computing connection users’ requirement. To achieve this top-down approach, the domain controller needs to take the two layers’ resource information into account at the same time. 4. Service Assurance Automation From the requirement scenarios, service assurance automation may include fault management and performance management. For AN level4, we think the domain controller needs to provide more intelligent and more user-oriented functionalities. Yu, et al. Expires 24 April 2025 [Page 5] Internet-Draft service automation October 2024 The traditional fault management only include alarm management, and it is a passive management approach which cannot satisfy the current demand. In AN level4, the service assurance should be more proactive. The domain controller should be able to discover some potential risk in advanced. The data used for alarm/risk discovery will not only includes alarms, but also performance data, log, configuration .etc. At the same time, with the help of technologies of AI etc., the domain controller can suppress the alarms into small amount of incidents, according to the correlation of alarm and other data. It is also feasible to locate the detail position by OTDR when fault is happened. So that the efficiency can be improved. For service’s performance management, the domain controller needs to provide the indicators which can indicate the user experience, such as latency, bandwidth utilization and availability/reliability. The showing of these data can be displayed in multiple perspectives, for example fiber, WDM service, OTN service level. These requirement probably can be fulfilled by the transport digital map. 5. Manageability Considerations <Add any manageability considerations> 6. Security Considerations <Add any security considerations> 7. IANA Considerations <Add any IANA considerations> 8. Normative References [TMF-IG1252] TM Forum (TMF), "Autonomous Network Levels Evaluation Methodology 1.2.3", TMF IG1252 , 2023, <https://www.tmforum.org/resources/introductory-guide/ ig1252-autonomous-network-levels-evaluation-methodology- v1-2-0/>. Acknowledgments Authors' Addresses Chaode Yu Huawei Technologies Email: [email protected] Yu, et al. Expires 24 April 2025 [Page 6] Internet-Draft service automation October 2024 Yang Zhao China Mobile Email: [email protected] Yucong Liu China Mobile Email: [email protected] Yu, et al. Expires 24 April 2025 [Page 7]