On 16-May-24 18:58, Sheng JIANG wrote:
Hi, Toerless,
Thanks for your further suggestion. It is fair to have a specific resource
deployment as a proof example alongside the framework document. Storage
could be one. Actually, I am thinking computing resource may be even more
straight forward as the newly merged resource have not been explored a lot.
I will talk around to my friends in carriers and vendors to find some people
who are interested to work on this with me. Meanwhile, I will try to
modified the current document towards an informational framework/guidance
document. By the way, I guess our prefix management could also be an example
if we take prefix availability as a type of network resource.
Yes. If you remember, I wrote a demo application of prefix management, and if
integrated with DHCPv6-PD it should work. I haven't touched the code for
several years, but it is still at
https://github.com/becarpenter/graspy/blob/master/ASA-examples/pfxm4.py
If you need a good project for a student, it is right there, to add support for
PD, as described in RFC 8992.
There is even some partly obsolete documentation at
https://github.com/becarpenter/graspy/blob/master/documentation/pfxm3.pdf.
It doesn't strictly conform to RFC 8992, since it was written before the RFC
was finalized. Also, of course, although the algorithm is distributed it needs
a single source, called the Origin ASA, presumably in the NOC, that provides
valid prefixes.
Brian
Cheers,
Sheng
-----Original Message-----
From: [email protected] <[email protected]> On
Behalf Of 'Toerless Eckert'
Sent: Wednesday, May 15, 2024 12:05 AM
To: Sheng JIANG <[email protected]>
Cc: [email protected];
[email protected]; [email protected]
Subject: Re: [Anima] draft-ietf-anima-network-service-auto-deployment-06
comments
Sheng,
I think it would be good to create a well received proof point for one
type of
resource first - for example RAM or storage. These two are also services
where
we might approach COINRG and/or NFSv4 WG to get feedback,
e.g.: ask for a slot to ask what they think.
Ultimetely, in the IETF, the hard job is always to find the lowest hanging
practical fruit that someone actually would want to implement. Finding,
selecting and aquiring/releasing some resources like this might be one
such low
hanging fruit - but we will only know if/when we talk to folks who are
closer to
those use-cases than i think we are right now.
The path based stuff would IMHO require for someone with a lot more TEAS
involvement to help/be-interested. Otherwise i fear we'd be faced with the
challenge of explaining how the work relates to TEAS, and we likely
wouldn't
have a good answer withou doing such an engagement.
Cheers
Toerless
On Sat, May 04, 2024 at 08:31:20AM +0800, Sheng JIANG wrote:
Hi, Toerless,
Thanks so much for this great comments. It is very valuable and
constructive. This draft was initiated by end-to-end deterministic
forwarding service. I was too ambitious to make it generic, even I
knew generic was very difficult. Later, we got lost between the
specific use case and a generic mechanism. We got further lost when it
came
to path-oriented.
It is a lot more complicated using node-by-node negotiation mechanism
to make up a multiple-node path-oriented mechanism than a single-round
path-through mechanism.
Actually, like we mentioned, there is a lot network resources that can
make up various services. Therefore, these seems to be worth a series
of documents. And beyond the potential documents each focuses on a
specific solution, there should be an informational framework
document. It could be the direction to modify this document, if
agreed. This would be feasible with minimum modification in an
acceptable timeline, I think. Another specific-resource document,
which had better not be path-oriented, should be also started as an use
case
of such framework.
How do you think?
Best regards,
Sheng
-----Original Message-----
From: Anima <[email protected]> On Behalf Of Toerless Eckert
Sent: Thursday, May 2, 2024 11:21 PM
To: [email protected];
[email protected]
Cc: [email protected]
Subject: [Anima] draft-ietf-anima-network-service-auto-deployment-06
comments
Dear Authors
Thank you for this work. The document sounds and currently intends
to
target
a full standard specification for arbitrary services management via
GRASP.
I
think this is an unattainable goal. What i think is attainable is to
outline how to
build such GRASP based signaling specifications, and for that the
document
has
good starting text, but it does not really well focus on that in
comparison to e.g.:
pre-existing methods.
If the resource is located on a single GRASP speaking node, such as
maybe storage, compute or memory, this is easy to imagine:
- One needs to figure out what the type of resource and the specific
resource attributes are.
- One needs to figure out how to define objectives to find server
nodes
that meet those resource attirbute needs - aka: memory of a
certain minimum
size, and for example minimum speed, with or without persistance,
etc.
pp
- One then needs to define the GRASP objectives to request/negotiate
and
re-negotiate such a service consumption request.
- Finally, one has to define the GRASP objectives to consume such a
resource,
e.g. read/write actual memory. I guess this part is not necessarily
part
of the intended scope of this draft, but could use other
pre-existing
protocols, but it would help a lot of listing all thise bullet
points
and
pointing this out explicitly.
The draft has some of these aspects covered, but it seems very
incomplete
and
in parts confusing. Primarily also because it simply enumerates a
long
list of
possible resources in section 8.2, but does not provide enough
specification to
actually implement in GRASP any single such resource management
solution, because there are no mentioning of relevant attributes to
show where GRASP could be better than existing mechanisms.
More problematic though is the implication that this draft can
support
resource
management like RSVP, aka: services for path properties. But then it
does
not
explain how the resource management would work when like for a path,
it requires allocation of resources from multiple nodes together. Is
there
some
on-path signaling like in RSVP, NSIS ? Is there a central controller ?
Does it
require some fixed path ? What happens when the path changes ? etc.
pp.
And unlike compute, storage, memory resources, path resource
management has a tremendous number of RFCs specifying thousands of
details - around
TE,
RSVP, RSVP-TE, PCE, Netconf/YANG and so on. And there is no
comparison or even specific claims of why this GRASP approach would
be beneficial for
any
scenario in which these existing solutions work or where it is
understood
that
they could be adopted to.
So, i think it would be very useful to discuss primarily the
intended
scope of the
document before going into further details of the text.
For example, i think it would be very helpful to constrain the scope
single-node
resource management and discuss the path resource
issues/complexities only in an appendix like section, pointing to
the variety of existing protocols
from
IETF and suggesting if any, some of the benefits the GRASP approach
could have.
If this makes sense, then i would also suggest to select some
example
service
and on each step of the document discuss example details of that
service.
Ideally, the service in question would already have one or more
existing consumption protocols and the GRASP solution could be
presented as a unifying single protocol to do discovery, negotiation,
selection.
Specifically
highlighting, that GRASP has network-based discovery, so it can
operate without the need of prior discovery servers (e.g.; no need
to set up a
DNS-SD
server or CORE-SD server for example)
I am not sure what the lowest-hanging fruit for such a service would
be,
e.g.:
the type of service for which this management aspect is least well
supported
today.
I do not know a lot of details of remote memory access, but i can
well
imagine
how this mechanism could be nice for storage. On the other hand, for
storage,
i can easily imagine a serious long list of service parameters
ranging
from the
consumption protocol (NFSv3, NFSv4, SMBv1, SMBv2, SMBv3, WebDAV,
and
a lot more), connection parameters (TCP, UDP, credentials),
resilience of
storage,
performance parameters, maximum size, cost, number of files, maximum
file size, etc. pp). And storage of course would have the nice
aspect that it
would
easily allow negotiation of several of those parameters (such as
maximum storage allowed, maximum through given to client, session
credentials,
sharing
of the storage across multiple clients.
Aka: I think that as soon as we think of any specific service, it
becomes
clear
that this document can not be normative for even a small part of
relevant
spec
details, but can only point out how "easy" it is to use GRASP to
define
them.
Aka:
include text about formal specification of the data model via CDDL,
and
easy
extensibility, etc. pp.
In the end it would be good to evolve this document into one that
has
enough
details of one service so that a minium interoperable implementation
could
be
built from it. Not because this should be seen as a complete
specification, but
only to have a prac tical enough explanation that coders can make
sense of
it.
And then highlight the benefits of GRASP, e.g.: why not use other
protocols:
- lightweight, binary encoded, appropriate for LLN up to SP core
networks.
- In-network discovery - no need to have third-party (services
server) dependencies
- Ability to find "closest" resource (network distance).
- separated security and transport substrate - can deploy GRASP on
various such substrates
- CDDL formal specifications of data model
- easily extensible service properties (as compared to DNS-SD TXT
record limits).
- negotation of consumption (not in DNS-SD, CORE-LF/CORE-SD).
...
And with this scope it would make a lot more sense to make this
draft
target
informational.
If this makes sense then i can provide further detail feednback
after
you've
tried to come up with a version that attempts to re-scope the
document
this
way.
If you want to keep the path-properties a core goal of the document
than
i'd
have to provide more feedback for that, but i think it would be a
lot more
work,
and much less likely to get through IETF.
Cheers
Toerless
2 ANIMA
S. Jiang, Ed.
3 Internet-Draft
BUPT
4 Intended status: Standards Track
J.
Dang
5 Expires: 4 October 2024
Huawei
6
Z. Du
7
China Mobile
8
2 April 2024
10 A Generic Autonomic Deployment and Management Mechanism for
Resource-
11 based Network Services
12
draft-ietf-anima-network-service-auto-deployment-06
14 Abstract
16 This document specifies an autonomic mechanism for
resource-based
17 network services deployment and management, using the
GeneRic
18 Autonomic Signaling Protocol (GRASP) to dynamically
exchange
the
19 information among the autonomic nodes. It supports the
coordination
20 and consistently operations within an autonomic network
domain.
This
21 mechanism is generic for most, if not all, of kinds of
network
22 resources, although this document only defines the
process of
quality
23 transmission service deployment and management. It can
be
easily
24 extended to support network services deployment and
management
that
25 is based on other types of network resources.
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with
the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet
Engineering
33 Task Force (IETF). Note that other groups may also
distribute
34 working documents as Internet-Drafts. The list of
current
Internet-
35 Drafts is at
https://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum
of six
months
38 and may be updated, replaced, or obsoleted by other
documents
at
any
39 time. It is inappropriate to use Internet-Drafts as
reference
40 material or to cite them other than as "work in
progress."
42 This Internet-Draft will expire on 4 October 2024.
44 Copyright Notice
46 Copyright (c) 2024 IETF Trust and the persons identified
as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's
Legal
50 Provisions Relating to IETF Documents
(https://trustee.ietf.org/
51 license-info) in effect on the date of publication of
this
document.
52 Please review these documents carefully, as they describe
your
rights
53 and restrictions with respect to this document. Code
Components
54 extracted from this document must include Revised BSD
License
text
as
55 described in Section 4.e of the Trust Legal Provisions
and are
56 provided without warranty as described in the Revised BSD
License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . .
. . . .
2
61 2. Requirements Language . . . . . . . . . . . . . . . .
. . . .
4
62 3. Terminology & Abbreviations . . . . . . . . . . . . .
. . . .
4
63 4. A Generic Auto-deployment Mechanism of Resource-based
Network
64 Services . . . . . . . . . . . . . . . . . . . .
. . . .
5
65 4.1. Discover RM ASA on Proper Service Responsers . .
. . . .
6
66 4.2. Authentication and Authorization . . . . . . . .
. . . .
6
67 4.3. Negotiate Resource with Service Responser . . . .
. . . .
6
68 4.4. Change Reserved Resources . . . . . . . . . . . .
. . . .
7
69 4.5. Releasing Resources during Service Ending . . . .
. . . .
8
70 5. Autonomic Resource Management Objectives . . . . . .
. . . .
8
71 6. Process of the Quality Network Transmission Service
72 Auto-deployment . . . . . . . . . . . . . . . . .
. . . .
10
73 6.1. Quality Transmission Service Scenario & Service
Type . .
10
74 6.2. Negotiation between a Service Initiator and a
Service
75 Responser . . . . . . . . . . . . . . . . . . . .
. . . .
11
76 6.3. Coordination among Multiple Service Responsers .
. . . .
12
77 6.4. Service Ending . . . . . . . . . . . . . . . . .
. . . .
12
78 7. Security Considerations . . . . . . . . . . . . . . .
. . . .
12
79 8. IANA Considerations . . . . . . . . . . . . . . . . .
. . . .
12
80 8.1. Service type . . . . . . . . . . . . . . . . . .
. . . .
13
81 8.2. Resource Type . . . . . . . . . . . . . . . . . .
. . . .
13
82 9. Acknowledgements . . . . . . . . . . . . . . . . . .
. . . .
13
83 10. References . . . . . . . . . . . . . . . . . . . . .
. . . .
13
84 10.1. Normative References . . . . . . . . . . . . . .
. . . .
13
85 10.2. Informative References . . . . . . . . . . . . .
. . . .
14
86 Authors' Addresses . . . . . . . . . . . . . . . . . . .
. . . .
14
88 1. Introduction
90 Traditionally, IP networks are based on the best-efforts
model.
The
91 IP layer does not reserve resources for upper-layer
applications.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^
nit:
s/IP layer/IP protocols/
92 However, more and more emerging applications that require
quality
93 services, such as video, VR, AR, and so on. They need
supports
from
94 steady network resources, such as bandwidth, queue,
memory,
priority,
95 computational resources, etc. On another side, from
network
side,
96 more and more generic services, such as quality
transmission
97 services, in-network data cache services and computing
services,
98 etc., are starting to be deployed so that networks can
serve
these
99 resource-consumption applications well. These network
services
are
nit:
Please provide references for "quality transmission services",
"in-nework
data
cache services", etc..
100 strongly based on the availability and stability of
network
101 resources.
103 To enable these resource-based applications and services,
IETF
have
104 developed many resource reservation mechanisms, such as
RSVP
105 [RFC2205] that is mainly to reserve bandwidth only and
path-oriented,
nit:
When you say many, please cite at least one more example, ideally
one most different from RSVP.
106 etc. However, most of them are mainly for reservation
during
the
107 deployment only and are rigid for dynamic adjustment.
Furthermore,
nit:
It is unclear what other than "during the deployment only" means.
Please explain in text.
108 most of them are dedicated for a certain type of network
resources.
110 This document introduces an enhanced and extensible
mechanism
that
111 supports dynamically dispatching of network resources,
using the
112 GeneRic Autonomic Signaling Protocol (GRASP) defined in
[RFC8990]
to
113 dynamically exchange the information among the autonomic
nodes.
Its
nit:
Please explain what "enhanced" means - readers assume enhanced
compared to RSVP, or any other prior mentioned example, but how ?
114 dynamic adjust ability is mainly enabled by the
negotiation
ability
115 defined by [RFC8990].
117 This mechanism is generic for most, if not all, of kinds
of
network
nit:
Generic itself is not very specific, but generic or not generic wrt.
to a
specific
network resource is even less clear. Please explain.
118 resources. It can be easily extended to support network
services
119 deployment and management that is based on other network
resources.
nit:
Other "network resources" than what network resource ? Please
explain in text.
120 It can be used, but no limited, in below network services
scenarios:
122 * Quality transmission services. The quality could
means
guaranteed
nit:
Please provide a reference or explain what "quality transmission
services"
means.
123 bandwidth, or jitter, etc. In order guarantee the
quality of
124 transmission services, the network should reserve
transmission
125 resource, particularly bandwidth or queues, on a
selected
path
126 from the ingress to the egress node. The dynamic
resource
127 dispatching mechanism should ensure the consistent of
reserved
128 resources on all the nodes in this path, particularly,
when
129 dynamic changes are operated on this path.
131 * Difference transmission services. The network may
provide
nit:
This probably should say "Differentiated Services" ?? If so, then
please
add
reference for DiffServ arch RFC, else explain or provide other
reference
for
what "Difference ... services" means.
132 different transmission services by putting the user
packets
into
133 different processes that have different resources,
such as
134 bandwidth, queue length, priority, etc. The results
would be
135 different user experience in delay and jitter, or even
packet
lose
136 rate.
138 * In network cache/storage services. The network may
provide
cache
139 or storage service by memory in the network devices or
attached
140 devices. The idle memory space is the resource that
need to
be
141 request and managed. The location or distance of the
memory
is
142 also relevant to user experience.
nit:
Please provide a reference for any such network cache/storage
service and
any
existing means to manage their resources. I can imagine such a
thing, but
i am
not aware of anything in the IETF context (CDNI for example does not
seem
to
be about managing resources, but rather content). Likewise "idle
memory"
space.
It is unclear to me what even a simple example of network based
memory resource (idle or not) would be.
144 * Computing services. More and more spare computational
resources
145 are from network providers. They may be idle
computational
cycles
146 on the network devices or deployed computational
servers.
The
147 occupation of these computational resources are
time-sensitive.
148 Also, the location or distance of the computational
resource
is
149 relevant to user experience.
nit:
Same question about providing example reference.
If there are no useful referrences, then it would help to provide a
simple explanation of a use-case exemplifying such a service. E.g.:
for memory
one
could think of an application that needs more memory, so it tries to
get
it from
a "memory server" and consumes it via e.g.: proprietary protocols
like
RoCEv2
(https://www.infinibandta.org/ibta-announces-new-roce-specification/).
151 * Information services. In some scenarios, network may
be
the
best
152 information provider. It may be the information are
from or
153 generated by network itself. Or the network has the
best
location
154 to provide the information.
nit:
reference and/or scenario.
156 The Autonomic Control Plane (ACP) [RFC8994] and the
Bootstrapping
157 Remote Secure Key Infrastructure (BRSKI) [RFC8995]
provide the
secure
158 precondition for this mechanism.
nit:
We should always try to emphasize how the components provided by
ANIMA can support each other but can also be used independently, e.g.:
s/provide ..."/may provide the secure precodnitions for this
mechanism/.
Nevertheless, the meachanism as presented is not dependent on them
but can equally be combined with other security mechanisms that
support mutual authentication between devices employing the mechanism
proposed here.
160 This document defines an Autonomic Resource Management
Objective in
161 Section 5. Three new corresponding registries are
defined in
162 Section 8. This document defines the process of quality
transmission
163 service deployment and management in Section 6.
165 2. Requirements Language
167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL
NOT",
168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and
169 "OPTIONAL" in this document are to be interpreted as
described
in
BCP
170 14 [RFC2119] [RFC8174] when, and only when, they appear
in all
171 capitals, as shown here.
173 3. Terminology & Abbreviations
175 This document uses terminology defined in [RFC7575].
177 RM ASA: the Resource Manager ASA on an autonomic nodes.
It
manages
178 the local resources on the node, such as bandwidth,
queue,
memory,
179 priority, computational resources, etc. The RM ASA
communicate
with
180 other counterpart RM ASAs in order to dynamically
dispatch
network
181 resources within the autonomic network domain. This
document
assumes
182 all autonomic nodes have a RM ASA.
184 Service Initiator: the autonomic node that initiates and
manages
a
185 network service. It requests and dynamically adjusts the
resources
186 of this network service through its RM ASA. Normally, a
network
187 service SHALL have one service initiator within an
autonomic
network
188 domain. However, multiple Service Initiators model MAY
also
189 operational if there were good synchronous or coordinate
mechanisms
190 among them.
192 Service Responser: the autonomic node that responses to
the
requests
193 from the Service Initiator. It receives the requests
through its
RM
194 ASA, checks or operates on its local resources, and
responds the
195 results to the Service Initiator. Typically, a network
service
MAY
196 involve multiple Service Responser. The consistency
among
them
are
197 the responsibility of the Service Initiator.
199 4. A Generic Auto-deployment Mechanism of Resource-based
Network
200 Services
202 This section describes the generic procedures of
autonomic
deployment
203 and management of the resource-based network services, as
Figure1
204 shows. The detailed implementation or internal
algorithms of
the
205 Resource Manager ASAs are out of scope of this document.
This
206 section does not cover the specific details that depend
on
certain
207 network services or certain type of network resources.
The
208 prepositive operation that indicates the Service
Initiator to
start
209 the service deployment are out of scope. The information
or
reasons
210 that trigger the dynamic service changes are also out of
scope.
212 | Node Discovery |
213 |- - - - - - - - - - - - - - - - - ->|
214 +-----------------+
+-----------------+
215 | RM ASA | | RM
ASA
|
216 |Service Initiator| |Service
Responser|
217 +-----------------+ ASA Discovery
+-----------------+
218 |----------------------------------->|
219 | Authentication and Authorization |
220 |----------------------------------->|
221 | M_RESPONSE
|
222 |<-----------------------------------|
223 |
|
224 | Multiple rounds Negotiation |
225 |<---------------------------------->|
226 | on Resource Availability |
227 |
|
228 | reserve the local
resource
229 |
|
230 ... ...
231 | Coordination with other RM ASAs |
232 |<---------------------------------->|
233 ... ...
234 | Service Ending |
235 |<---------------------------------->|
236 | release
resources
238 Figure-1: generic procedures of autonomic deployment and
management
240 4.1. Discover RM ASA on Proper Service Responsers
242 The Service Initiator MAY first discover the relevant
network
nodes
243 according to the service setup in order to reduce the
node range
of
244 sending GRASP Discovery message. It may be all the nodes
on a
giving
245 path or nodes that have idle resource available for
giving
service
246 condition, etc. The node discover methods can be
pre-configured,
247 outbound discover, path detection, etc.
249 The Service Initiator SHOULD send out a GRASP Discovery
message
that
250 contains a Resource Manager Objective option defined in
Section
5, in
251 which the network service is described. The Discovery
message
SHOULD
252 send to the reduced range nodes, by abovementioned
mechanism, or
all
253 nodes within the AN domain.
255 A RM ASA that receives the Discovery message with the
Resource
256 Manager Objective option SHOULD check its satisfaction
against
the
257 service description. If meet, the node is a proper
Service
258 Responser. It SHOULD respond a GRASP Response message
back to
the
259 Service Initiator.
261 Defined in the section 2.5.5.1 of [RFC8990], the
Discovery
message
262 MAY combine with the below negotiation process, if the
rapid
263 negotiation function has been enabled network wide. If
the
rapid
264 negotiation function has been disabled, the process would
fall
back
265 to the normal discovery-only process.
267 4.2. Authentication and Authorization
269 In principle, any operations on resources MUST be
authorized.
The
270 Service Responser SHOULD check the authentication of the
Service
271 Initiator and the authorization information for the
operation it
272 requests. This document assumes all autonomic nodes
within
the
AN
273 domain have been authenticated and their requested
operations
are
274 authorized, giving the Autonomic Control Plane (ACP)
[RFC8994]
and
275 the Bootstrapping Remote Secure Key Infrastructure
(BRSKI)
[RFC8995]
276 has provided the secure environment for this mechanism.
278 4.3. Negotiate Resource with Service Responser
280 After the discovery step, the RM ASA on the Service
Initiator
sends a
281 GRASP Request message with a Resource Manager Objective
option,
in
282 which the value of the requested resource is indicated.
284 When the RM ASA on a Service Responser receives a
subsequent
Request
285 message, it SHOULD conduct a GRASP negotiation sequence,
using
286 Negotiate, Confirm Waiting, and Negotiation End messages
as
287 appropriate. The Negotiate messages carry a Resource
Manager
288 Objective option, which will indicate the resource type
and value
289 offered to the requesting RM ASA.
291 During the negotiation, the RM ASA on the Service
Responser will
292 decide at each step how much resource can be offered.
That
decision,
293 and the decision to end the negotiation, are
implementation
choices.
294 A resource shortage on the Service Responser may cause it
to
indicate
295 the existing available value within a Resource Manager
Objective
296 option back to the Service Initiator. The Service
Initiator
might
297 decide whether to accept the request of the resource. If
not,
the RM
298 ASA on the Service Initiator MAY terminate the
negotiation via
299 Negotiation End messages.
301 Upon completion of the negotiation, the Service Responser
reserves
302 its local resources. The Service Initiator may use the
negotiated
303 resource after receiving synchronization message without
further
304 messages.
306 Normally, a network service SHALL have one service
initiator
within
307 an autonomic network domain. It is the Service
Initiator's
308 responsibility to manage the service and coordinate among
multiple
309 Service Responsers to ensure the consistent of reserved
resources.
311 4.4. Change Reserved Resources
313 After the process of automatic resource management
mechanism,
RM
ASAs
314 are allowed to change and negotiate the resource
requirements.
In
315 the lifetime of network services, there may be many
reasons that
the
316 service has to be changed upon with its reserved
resources.
Resource
317 Manager ASA needs to be able to handle resource changes
in a
timely
318 manner to meet service requirements.
320 During the renegotiation process, RM ASA on the Service
Initiator
321 resends the service's resource requirements by using
Resource
Manager
322 GRASP Objective. RM ASA on the Service Responser
receives
the
323 resource negotiation message and makes the determination.
If
the
324 resource requirements are lower than those allocated
or/and less
325 lifetime than previous, the Service Responser SHOULD
directly
confirm
326 the information and release the excess resources. If
more
resources
327 or lifetime are required, RM ASA on the Service Responser
SHOULD
328 treat it as a brand-new request and make decision or
further
329 negotiation. The bottom line is the Service Responser
MUST
allow
the
330 Service Initiator fall back to previous allocated
resource, both
on
331 volume and lifetime.
333 RM ASAs on the Service Responsers MUST NOT change
existing
resource
334 allocation until the new negotiation on resource changes
is
complete.
336 4.5. Releasing Resources during Service Ending
338 After the service is completed or expired, the reserved
network
339 resources MUST be released so that network resources can
be
used
more
340 efficiently. If the service lifetime expires, the
Service
Responser
341 MUST release its local resources and MAY send a
Synchronization
342 message to the Service Initiator to notify the state
change of
its
343 local resources. If the Service Initiator wants to end
the
service
344 before the service lifetime expires, the Service
Initiator MUST
send
345 a negotiation message to the Service Responsers to
request the
346 network resource to be changed to zero. Upon completion
of
the
347 negotiation, the Service Responser releases the resources
occupied by
348 the service.
350 5. Autonomic Resource Management Objectives
352 This section defines the GRASP technical objective
options that
are
353 used to support autonomic resource management. Resource
Manager
354 GRASP Objective allows multiple types of resources to be
requested
355 simultaneously.
357 The Resource Manager Objective option is a GRASP
Objective
option
358 conforming to the GRASP specification [RFC8990]. Its
name is
359 "Resource Manager", and it carries the following data
items as
its
360 value: the resource value. Since GRASP is based on CBOR
(Concise
361 Binary Object Representation) [RFC8949], the format of
the
Resource
362 Manager Objective option is described in the Concise Data
Definition
363 Language (CDDL) [RFC8610] as follows:
365 objective = ["Resource Manager", objective-flags,
loop-count,
366 ?objective-value]
368 objective-name = "Resource Manager"
370 objective-flags = uint .bits objective-flag ; as in the
GRASP
371 specification
373 loop-count = 0..255 ; as in the GRASP specification
374 The 'objective-value' field expresses the actual value of
a
375 negotiation or synchronization objective. So a new
objective-value
376 named autonomic-network-service-value is defined for
Network
Service
377 Auto-deployment as follows. The autonomic node can know
that it
is
378 serving Network Service Auto-deployment according to the
objective-
379 value after receiving the GRASP message. The 'objective
value'
380 contains two parts, one represents the information of the
service
381 itself, and the other represents the requirements of
resources.
383 objective-value = autonomic-network-service-value; An
autonomic-
384 network-service-value is defined as Figure-2.
386 autonomic-network-service-value =
387 [
388 [
389 service-type,
390 service-id,
391 service-lifetime,
392 service-tag
393 ],[
394 *resource-requirement-pair
395 ]
396 ]
398 Figure-2: Format of autonomic-network-service-value-value
400 service-type = 0..7
402 service-id = uint
404 service-lifetime = 0..4294967295 ; in milliseconds
406 service-tag = [ *service-tag-info]
408 The combination service-type and the service-id MUST
uniquely
409 represent a network service within the network. The
uniqueness
of
410 the combination service-type and the service-id SHOULD be
guaranteed
411 by an allocation mechanism that is out of scope of this
document.
413 The allocation of resources MUST specify the lifetime.
The
service-
414 lifetime represents the usage time of the resources
required by
the
415 service.
417 The service-tag contains other information that describes
the
418 service. This information is not necessary, but will
affect the
419 policy for RM ASA resource reservation.
421 The resource-requirement-pair describes the resource
requirements
and
422 it is defined as Figure-3. Resource requirements of
different
types
423 can be described in an objective option. The Resource
Manager
424 objective option supports multi-faceted resource
requirements
and
425 negotiation. These resource requirements are all in
pairs,
described
426 by resource type and resource value.
428 resource-requirement-pair =
429 [
430 resource-type,
431 resource-value
432 ]
434 Figure-3: Format of resource-requirement-pair
436 resource-type = 0..7
438 resource-value = uint
440 6. Process of the Quality Network Transmission Service
Auto-deployment
442 6.1. Quality Transmission Service Scenario & Service Type
444 The quality transmission service scenario is the most
important
445 resource negotiation scenario. In this scenario, RM ASAs
negotiate
446 the resource that will affect the transmission quality.
The
basic
447 resource is bandwidth and other types of resources such
as
queue
can
448 be required at the same time.
450 The autonomic deployment and management of the quality
transmission
451 service includes the Service Initiator and the Service
Responsers
all
452 have RM ASA. The Service Initiator is the resource
demander,
which
453 ensures the connection of services through negotiation
resources
with
454 RM ASAs in the domain network. Service Responsers are
the
nodes
455 which packets are forwarded in the transmission scenario
and
Service
456 Initiator asks resource from them. These nodes can be
discovered
457 through RM ASA discovery process or path discovery
methods.
459 Negotiation Resource
460
+-------------------------------------------------------------+
461 | Negotiation Resource
|
462 | +--------------------------------------------+
|
463 | | |
|
464 +--------+ Negotiation Resource +---------+ +---------+
+---------+
465 | RM ASA |<-------------------->| RM ASA | | RM ASA |
|
RM
ASA |
466 +--------+ +---------+ +---------+
+---------+
467 | SI | -------------------->| SR Node |-->| SR Node
|-->| SR
Node |
468 +--------+ Transmit data +---------+ +---------+
+---------+
469 Figure-3 shows how RM ASAs negotiate resources and how
Service
470 Initiator forwards packages. The RM ASA on the Service
Initiator
471 negotiates resources with the RM ASAs on the Service
Responsers
one
472 by one.
474 Figure-3: Negotiation procedure of a transmission service
476 6.2. Negotiation between a Service Initiator and a Service
Responser
478 In the process of negotiation, Service Initiator
negotiates
resources
479 with Service Responsers and ensures resources enough. RM
ASAs
are
480 allowed to negotiate resources for multiple rounds. It
often
happens
481 that the network resources on one node cannot meet the
resources
482 required by the service, but the service is willing to
reduce its
483 resource requirements to ensure the successful deployment
of
the
484 service. The RM ASAs on the Service Responsers feedback
the
maximum
485 available resources using Resource Management Objectives
in
the
486 response message. The RM ASA on the Service Initiator
changes
the
487 resource requirements according to the specific
requirements of
the
488 received resources and services, to carry out the next
round of
489 service negotiation.
491 +----------+
+---------+
492 | RM ASA | | RM
ASA
|
493 +----------+
+---------+
494 | SI | | SR
Node |
495 +----------+ [[0,36732,3600000,[]][[0,10]]]
+---------+
496 |------------------------------------------->|
497 | [[0,36732,3600000,[]][[0,8]]] |
498 |<-------------------------------------------|
499 | [[0,36732,3600000,[]][[0,8]]] |
500 |------------------------------------------->|
501 | Negotiation End (ACCEPT) |
502 |<-------------------------------------------|
504 Figure-4 shows an example of a negotiation process. In
the first
505 negotiation round, RM ASA on the Service Initiator wants
to get
506 resource from RM ASA on the Service Responsers. In this
example,
the
507 service type is Transmission Service and service-id is
36732.
The
508 service will last 3600 seconds and only ask for one kind
of
resource
509 10 Mbit/s bandwidth. So, the
autonomic-network-service-value
is
510 [[0,36732,3600000,[]][[0,10]]].
512 Figure-4: an example of a negotiation process
514 When RM ASA on the Service Responser Node receives the
message,
if
515 the RM ASA thinks the network can offer this required
resource,
it
516 will response the ACCEPT. But if it does not meet the
request,
it
517 will give how much resource it can offer. In this
example, the
518 Service Responser can offer 8 Mbit/s. The next step, RM
ASA
on
the
519 Service Initiator needs to decide whether to change its
resource
520 requirements according to the reply, and sends a next
round
521 negotiation. Then, RM ASA on the Service Responser finds
the
new
522 resource requirement, it can meet. So, it will response
ACCEPT.
523 This is an example how ASAs negotiate resources.
525 6.3. Coordination among Multiple Service Responsers
527 The Service Initiator decides a coordinated value of
resource and
528 negotiates with multiple Service Responsers that need to
reduce
the
529 locked resource. The Service Responsers reserve
resources for
530 service according to the negotiation results. If the
operation
is
531 successful, the Service Responser reply success message
to the
532 Service Initiator. If it fails, reply failure message to
the
Service
533 Initiator. And the Service Initiator will restart
negotiation
step.
535 When the Service Initiator receives the success message
from all
the
536 Service Responsers, the service can start to transmit the
message.
538 6.4. Service Ending
540 When the service is ended, it is the responsibility of
Service
541 Initiator to release all reserved resources through the
dialogue
with
542 the RM ASA on the Service Responser. And if the service
lifetime
is
543 exceeded, the Service Initiator SHOULD also release
reserved
resource
544 although the Service Responsers may release the reserved
resource
by
545 themselves.
547 7. Security Considerations
549 It complies with GRASP security considerations. Relevant
security
550 issues are discussed in [RFC8990]. The preferred
security model
is
551 that devices are trusted following the secure bootstrap
procedure
552 [RFC8995] and that a secure Autonomic Control Plane (ACP)
[RFC8994]
553 is in place.
555 8. IANA Considerations
557 This document defines a new GRASP Objective option names:
"Resource
558 Manager" which need to be added to the "GRASP Objective
Names"
559 registry defined by [RFC8990]. And this document defines
a
new
560 registry tables "service-type" and "resource-type" under
the
561 "Resource Manager" GRASP Objective. The following
subsections
562 describe the new parameters.
564 8.1. Service type
566 IANA has set up the "service-type" registry, which
contains 4-bit
567 value. The service-type defines the type of service
which is
used to
568 describe the type of resource requirements.
570 * 0 : Transmission Service
572 * 1 : Computing Service
574 8.2. Resource Type
576 IANA has set up the "resource-type" registry, which
contains
4-bit
577 value.
579 * 0 : bandwidth
581 * 1 : queue
583 * 2 : memery
585 * 3 : priority
587 * 4 : cache
589 * 5 : computing
591 9. Acknowledgements
593 Valuable comments were received from Michael Richardson
and
Brian
594 Carpenter. Contributions to early versions of this
document was
made
595 by Yujing Zhou.
597 10. References
599 10.1. Normative References
601 [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate
602 Requirement Levels", BCP 14, RFC 2119,
603 DOI 10.17487/RFC2119, March 1997,
604 <https://www.rfc-editor.org/info/rfc2119>.
606 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S.,
Herzog, S.,
and S.
607 Jamin, "Resource ReSerVation Protocol (RSVP)
--
Version
1
608 Functional Specification", RFC 2205, DOI
10.17487/RFC2205,
609 September 1997,
<https://www.rfc-editor.org/info/rfc2205>.
611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs
Lowercase in
RFC
612 2119 Key Words", BCP 14, RFC 8174, DOI
10.17487/RFC8174,
613 May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
615 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann,
"Concise
Data
616 Definition Language (CDDL): A Notational
Convention to
617 Express Concise Binary Object Representation
(CBOR)
and
618 JSON Data Structures", RFC 8610, DOI
10.17487/RFC8610,
619 June 2019,
<https://www.rfc-editor.org/info/rfc8610>.
621 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary
Object
622 Representation (CBOR)", STD 94, RFC 8949,
623 DOI 10.17487/RFC8949, December 2020,
624 <https://www.rfc-editor.org/info/rfc8949>.
626 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu,
Ed.,
"GeneRic
627 Autonomic Signaling Protocol (GRASP)", RFC
8990,
628 DOI 10.17487/RFC8990, May 2021,
629 <https://www.rfc-editor.org/info/rfc8990>.
631 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S.
Bjarnason,
"An
632 Autonomic Control Plane (ACP)", RFC 8994,
633 DOI 10.17487/RFC8994, May 2021,
634 <https://www.rfc-editor.org/info/rfc8994>.
636 [RFC8995] Pritikin, M., Richardson, M., Eckert, T.,
Behringer,
M.,
637 and K. Watsen, "Bootstrapping Remote Secure
Key
638 Infrastructure (BRSKI)", RFC 8995, DOI
10.17487/RFC8995,
639 May 2021,
<https://www.rfc-editor.org/info/rfc8995>.
641 10.2. Informative References
643 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S.,
Clemm, A.,
644 Carpenter, B., Jiang, S., and L. Ciavaglia,
"Autonomic
645 Networking: Definitions and Design Goals", RFC
7575,
646 DOI 10.17487/RFC7575, June 2015,
647 <https://www.rfc-editor.org/info/rfc7575>.
649 Authors' Addresses
651 Sheng Jiang (editor)
652 Beijing University of Posts and Telecommunications
653 No. 10 Xitucheng Road
654 Beijing
655 Haidian District, 100083
656 China
657 Email: [email protected]
658 Joanna Dang
659 Huawei
660 No.156 Beiqing Road
661 Beijing
662 P.R. China, 100095
663 China
664 Email: [email protected]
666 Zongpeng Du
667 China Mobile
668 32 Xuanwumen West Street
669 Beijing
670 P.R. China, 100053
671 China
672 Email: [email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
