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]