Skip to main content

Automation Scenarios and Requirements for Level 4 Autonomous Networking (AN)
draft-yu-ccamp-service-automation-00

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]