An Auto-deployment Mechanism for Resource-based Network Services
draft-dang-anima-network-service-auto-deployment-00

Document Type Active Internet-Draft (individual)
Authors Joanna Dang  , Sheng Jiang  , Zongpeng Du 
Last updated 2021-07-06
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
ANIMA                                                       J. Dang, Ed.
Internet-Draft                                                  S. Jiang
Intended status: Standards Track                                  Huawei
Expires: January 8, 2022                                           Z. Du
                                                            China Mobile
                                                            July 7, 2021

    An Auto-deployment Mechanism for Resource-based Network Services
          draft-dang-anima-network-service-auto-deployment-00

Abstract

   This document specifies an auto-deployment mechanism that deploys
   resource-based network services through the Autonomic Control Plane
   (ACP) in an Autonomic Network.  This mechanism uses the GRASP in
   [RFC8990] to exchange the information among the autonomic nodes so
   that the resource among the service path can be coordinated.

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 January 8, 2022.

Copyright Notice

   Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of

Dang, et al.             Expires January 8, 2022                [Page 1]
Internet-Draft                                                 July 2021

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology & Abbreviations . . . . . . . . . . . . . . . . .   3
   4.  Architecture and components . . . . . . . . . . . . . . . . .   3
   5.  GRASP Option for Network Service Auto-deployment  . . . . . .   4
   6.  Processes of Network Service Auto-deployment  . . . . . . . .   7
     6.1.  Path-based Resource Negotiation . . . . . . . . . . . . .   7
   7.  Compatibility with Other Technologies . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   A network service is a service carried by a network.  A system of
   network service development includes a service initiator, a network
   and a service terminator.  And a network is between a service
   initiator and a service terminator.  From network perspective, this
   network service clearly has a source IP address and a destination IP
   address.  Therefore, once a network service is delivered by a
   network, this network service clearly has an access node and a
   departure node in the network.  Here, this access node is called UPE,
   and the departure node is called PE.  Actually there may be multiple
   P nodes between UPE and PE in a single domain, and even cross
   multiple domains connections through ASBRs.  And there may be one or
   more paths between UPE and PE for this network service.

   With the development of the network services, a class of services
   with resource requirements (such as bandwidth, latency, and jitter)
   are already emerging, such as video, LR, VR and so on.  To collect
   resource information of network nodes along a path, the network
   managers must analyse whether there are available resources to
   allocate on the path.  This is very demanding for network managers.
   Along with the increasing scale of the network and the increasing
   types of network services, the manual way have become increasingly
   difficult to operate.  There are two directions to solve this
   problem.  One is that network nodes perform the resource-based
   negotiation and calculation along the path, and the other is that the
   centralized control system perform network resource-based
   calculations for the path.  The former is faster and is not limited
   by the number of nodes; the latter has better global calculation

Dang, et al.             Expires January 8, 2022                [Page 2]
Internet-Draft                                                 July 2021

   results.  Based on the principle that the two methods can complement
   each other, the former is focused on in this document.

   This document specifies an auto-deployment mechanism for resource-
   based network services on the autonomic nodes in [RFC8993] to reduce
   human operation difficulty and avoid the problem of specification
   limitation and slow response in centralized systems, for the purpose
   of improving service deployment efficiency.

   The following chapters describe the architecture and functional
   components, the definition of GRASP options and processes.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

3.  Terminology & Abbreviations

   Service Initiator: It may be an end user, a Customer Edge (CE), or a
   controller that initiates a path-dependent and resource-based network
   service.

   SPE: A first hop network node where the service initiator connects to
   the network or where the path-dependent and resource-based network
   service starts.

   PE: Provider Edge node where the network service starts or ends.

   P: A transmit node between SPE and PE.

   ASBR: AS Border Router which is an edge node of the domain in the
   cross-domain scenario.  It may also be a PE node.

4.  Architecture and components

   This section describes the internal architecture of an auto-
   deployment mechanism for resource-based network services.

   As Figure 1 shows, a functional system of network service auto-
   development includes Autonomic Network Service (ANS) Request, ANS
   Deployment Function and ANS Response.

   1.  First, the network resource initiator sends an ANS Request to a
       UPE on the edge of network.

Dang, et al.             Expires January 8, 2022                [Page 3]
Internet-Draft                                                 July 2021

   2.  Then, the UPE starts to establish a resource-based path to the
       network service according to the network service requirements.  A
       resource-based path is an LSP within
       [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls].  If the
       path is successfully established, UPE will automatically
       configure the LSP.  The specific configuration command lines are
       not in the scope of this document.

   3.  Finally, UPE sends back an ANS Response with the deployment
       result to the network service initiator.

  Network Service                                        Network Service
  Initiator                                                   Terminator
  +--------+                                                  +--------+
  |        |                                                  |        |
  +--------+                                                  +--------+
       |       +--------+        +--------+       +--------+       |
       +-------|  SPE   |--------|  P     |--...--|  PE    |+------+
               +--------+        +--------+       +--------+
                  Network           Network         Network
                   Node1             Node2           NodeN
  1.ANS Request
  ------------>
                            2.ANS Deployment Function
               <------------------------------------------->
  3. ANS  Response
  <------------

   Figure-1: Architecture and Components

   These messages including ANS Request, ANS Deployment Function and ANS
   Response are exchanged between or in autonomic nodes through GRASP.
   The chapter 5 defines the optional fields of GRASP for this function,
   and the chapter 6 introduces the process.

5.  GRASP Option for Network Service Auto-deployment

   The GRASP enables autonomic nodes to dynamically discover peers, to
   synchronize state with each other, and to negotiate parameter
   settings with each other.  So an objective option is used to identify
   objectives for the purposes of discovery, negotiation, or
   synchronization.  So a new objective option is defined for Network
   Service Auto-deployment as follows.

   objective-name = EX10

   All objectives MUST be in the following format, described in
   fragmentary CDDL.

Dang, et al.             Expires January 8, 2022                [Page 4]
Internet-Draft                                                 July 2021

   objective = [objective-name, objective-flags, loop-count, ?objective-
   value]

   The 'objective-value' field expresses the actual value of a
   negotiation or synchronization objective.  So a new objective-value
   named n-s-deployment-value is defined for Network Service Auto-
   deployment as follows.  The autonomic node can know that it is
   serving Network Service Auto-deployment according to the objective-
   value after receiving the GRASP message.

   objective-value = n-s-deployment-value

   loop-count = 0..255

   An n-s-deployment-value is defined as Figure-2.

                   n-s-deployment-value
                      + service-identification
                          + service-identification-type
                          + service-identification-value
                          + resource-information
                              + resource-type
                              + resource-value
                          + n-s-deployment-type
                          + status

   Figure-2: Format of n-s-deployment-value

   n-s-deployment-value = [ service-identification 1, service-
   identification 2, ..., service-identification n ]

   More than one auto-deployed network services can share a GRASP
   channel.

   service-identification = [ service-identification-type, service-
   identification-value, ?path-identification-type, ?path-
   identification-value, resource-information, n-s-deployment-type,
   ?n-s-status ]

   resource-information = [ resource-type, resource-value ]

   The detailed fields of n-s-deployment-value are defined as follows.

   service-identification-type: 3 bits, which is used to identify
   different services within a Request Negotiation message or a
   Negotiation message.

   o  1 = MAC

Dang, et al.             Expires January 8, 2022                [Page 5]
Internet-Draft                                                 July 2021

   o  2 = VLAN

   o  3 = IP address

   o  4 = Label

   o  5~6 is reserved

   service-identification-value: TBD, which is used to identify
   different network services within a Request Negotiation message or a
   Negotiation message.

   path-identification-type: 3 bits, which is related to the network.

   o  1 = LSP

   o  2~6 is reserved

   path-identification-value: TBD

   path-identification-value, 3 bits

   o  MAC

   o  Or VLAN

   o  Or 5 tuple

   o  Or label

   resource-type: 2 bits, one service may have a type of resource
   information or more than one type of resource information.

   o  1 = bandwidth

   o  2 = latency

   o  3 = jitter

   n-s-deployment-type: 2 bits

   o  1 = network service establishment

   o  2 = network service withdrawal

   o  3 = network service update including resource information update

   n-s-status: 2 bits only in a Negotiation message

Dang, et al.             Expires January 8, 2022                [Page 6]
Internet-Draft                                                 July 2021

   o  0, default

   o  1, which indicates that the negotiation was successful.

   o  2, which indicates that the negotiation failed

6.  Processes of Network Service Auto-deployment

   The GRASP within objective-name for network service auto-deployment
   enables autonomic nodes which are a service initiator, a network and
   a service terminator.

   During the negotiation process, the service initiator first sends a
   Request Negotiation message with a service-identification to the SPE.
   After receiving the Request Negotiation message, the SPE records the
   service-identification and creates the related data block.  Next, the
   SPE starts to establish a resource-based path based on the resource
   information within service-identification.

6.1.  Path-based Resource Negotiation

   If the s-deployment-type within the Request Negotiation message is 1
   which indicates network service establishment, the resource-based
   path establishment is started.

   If s-deployment-type is 3 which indicates network service update, the
   process directly skips to the processes of the path-based resource
   negotiation.

   The UPE must check whether the network path is reachable based on
   addressing information from service-identification.  The addressing
   information may be destination MAC address in layer 2 networks, or
   destination IP address in layer 3 networks, or label in MPLS or SR
   networks , and so on.  A path is an LSP within
   [I-D.ietf-spring-segment-routing] or [I-D.ietf-mpls].

   o  If a reachable path is found out from the existing free path, the
      SPE will initiate path resource negotiation.

   o  If a reachable path isn't found out from the existing free path,
      the SPE will start path-based auto-configuration before resource
      negotiation.  If the path configuration still fails, the SPE will
      send back a Negotiation Message that the service deployment failed
      to the service initiator.

   After finding out a network reachable path, the SPE initiates a path-
   based resource negotiation based on its resource information as
   figure-3.

Dang, et al.             Expires January 8, 2022                [Page 7]
Internet-Draft                                                 July 2021

          +-----+      +----+      +----+      +-----+
          | SPE |------|  P |------|  P |------| PE  +
          +-----+      +----+      +----+      +-----+
           Request Negotiation Message
           ------------>
                        Request Negotiation Message
                        ------------>
                                       Request Negotiation Message
                                        ------------>
                                       Negotiation message
                                        <------------
                          Negotiation message
                          <------------
           Negotiation message
           <------------

   Figure-3: An example of a path-based resource negotiation

   o  Every autonomic network node along the path need to calculate the
      available resources.  If receiving the path Request Negotiation
      message, it obtains resource information from the Request
      Negotiation message, and calculate whether its own resources
      related to this path meet the requirements.

   o

      *  If they do, network autonomic node needs to send a path Request
         Negotiation message to the downstream node before related
         resources is occupies by this path.  If the negotiation message
         reaches the last node of the path and resources are available,
         the autonomic node will send a Negotiation message with
         successful negotiation back to the upstream node.  If the SPE
         receives a path Negotiation message indicating that the path
         resource negotiation is successful, it will send back to a
         service Negotiation message to the service initiator.

      *  If they do not, it will terminate this message and response a
         Negotiation message with failed resource negotiation to its
         upstream node.  If receiving it, the upstream node also
         response a path Negotiation message with failed resource
         negotiation to its upstream node.  The SPE will send back to
         the service Negotiation message failed resource negotiation to
         the service initiator after receiving this path Negotiation
         message.

   If s-deployment-type within the Request Negotiation message is 3
   which indicates network service update, the path update based on its
   resource requirement is started.  It should be emphasized that the

Dang, et al.             Expires January 8, 2022                [Page 8]
Internet-Draft                                                 July 2021

   nodes occupy the sum of the existing and updated resources before the
   nodes along the path have successfully completed the path
   negotiation.  If the update is successful, the existing resource
   along the path will be released.  If the update fails, the existing
   resource along the path will be kept.

   If s-deployment-type within the Request Negotiation message is 2
   which indicates network service withdrawal, the nodes along the path
   will release the relevant configuration and resources before
   receiving this message.

7.  Compatibility with Other Technologies

   It is worth emphasizing that the resource allocation and calculation
   methods of network nodes are different on the type of different
   resource requirements.

   Now it is explained in terms of bandwidth.  If in the MPLS network,
   the RSVP protocol system has the complete signaling mechanism and
   bandwidth resource calculation functions.  The bandwidth negotiation
   of the network-side path can be completed by RSVP.

   For latency and jitter, the GRASP mechanism is needed to complete.
   For example, the network node collects links, forwarding and queue
   scheduling delays, and performs delay or calculations.  If the
   calculated delay meets the service requirements, the other node is
   notified through the GRASP protocol.  The same principle applies to
   jitter.

8.  Security Considerations

   It complies with GRASP security consideration.

9.  IANA Considerations

   A new GRASP Objective Name is especially for network service
   deployment.  The Objective-name of n-s-deployment-value need to be
   defined.

10.  Acknowledgements

   TBD

11.  Normative References

   [I-D.ietf-mpls]
              "Multiprotocol Label Switching Architecture",
              <https://www.rfc-editor.org/info/rfc3031>.

Dang, et al.             Expires January 8, 2022                [Page 9]
Internet-Draft                                                 July 2021

   [I-D.ietf-spring-segment-routing]
              "Segment Routing Architecture",
              <https://www.rfc-editor.org/info/rfc8402>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8990]  "GeneRic Autonomic Signaling Protocol (GRASP)",
              <https://www.rfc-editor.org/info/rfc8990>.

   [RFC8993]  "A Reference Model for Autonomic Networking",
              <https://www.rfc-editor.org/info/rfc8993>.

Authors' Addresses

   Joanna Dang (editor)
   Huawei
   No.156 Beiqing Road
   Beijing, P.R. China  100095
   China

   Email: dangjuanna@huawei.com

   Sheng Jiang
   Huawei
   No.156 Beiqing Road
   Beijing, P.R. China  100095
   China

   Email: jiangsheng@huawei.com

   Zongpeng Du
   China Mobile
   32 Xuanwumen West St
   Beijing, P.R. China  100053
   China

   Email: duzongpeng@chinamobile.com

Dang, et al.             Expires January 8, 2022               [Page 10]