On Thu, May 16, 2024 at 02:58:15PM +0800, 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.
Thanks, Sheng There is also CATS WG which may be an adjacency and/or place to position this GRASP work in relationship to compute. Then again, it is a lot more likely that the members of that WG have already their own solution and protocol framework in mind. Alas i forgot all the technical details since i last looked into CATS effort before the WG was formed... Cheers Toerless > Cheers, > > Sheng > > > -----Original Message----- > > From: forwardingalgori...@ietf.org <forwardingalgori...@ietf.org> On > > Behalf Of 'Toerless Eckert' > > Sent: Wednesday, May 15, 2024 12:05 AM > > To: Sheng JIANG <shengji...@bupt.edu.cn> > > Cc: draft-ietf-anima-network-service-auto-deploym...@ietf.org; > > anima-cha...@ietf.org; anima@ietf.org > > 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 <anima-boun...@ietf.org> On Behalf Of Toerless Eckert > > > > Sent: Thursday, May 2, 2024 11:21 PM > > > > To: draft-ietf-anima-network-service-auto-deploym...@ietf.org; > > > > anima-cha...@ietf.org > > > > Cc: anima@ietf.org > > > > 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: shengji...@bupt.edu.cn > > > > 658 Joanna Dang > > > > 659 Huawei > > > > 660 No.156 Beiqing Road > > > > 661 Beijing > > > > 662 P.R. China, 100095 > > > > 663 China > > > > 664 Email: dangjua...@huawei.com > > > > > > > > 666 Zongpeng Du > > > > 667 China Mobile > > > > 668 32 Xuanwumen West Street > > > > 669 Beijing > > > > 670 P.R. China, 100053 > > > > 671 China > > > > 672 Email: duzongp...@chinamobile.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Anima mailing list > > > > Anima@ietf.org > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > -- > > --- > > t...@cs.fau.de > > -- --- t...@cs.fau.de _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org