idnits 2.17.00 (12 Aug 2021) /tmp/idnits22006/draft-bormann-t2trg-affinity-00.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(323): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (30 August 2021) is 257 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 == Outdated reference: A later version (-03) exists of draft-liu-dyncast-ps-usecases-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dyncast C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational 30 August 2021 5 Expires: 3 March 2022 7 Providing Instance Affinity in Dyncast 8 draft-bormann-t2trg-affinity-00 10 Abstract 12 Dyncast support in a network provides a client with a fresh optimal 13 path to a service provider instance, where optimality includes both 14 path and service provider characteristics. As a service invocation 15 usually takes more than one packet, dyncast needs to provide instance 16 affinity for each service invocation. Naive implementations of 17 instance affinity require per-application, per service-invocation 18 state in the network. 20 The present short document defines a way to provide instance affinity 21 that does not require, but also does not rule out per-application 22 state. 24 It also discusses how the information that an application needs to 25 operate this mechanism can be provided via the discovery mechanisms 26 offered by a CoRE (Constrained RESTful Environments) server, either 27 in "/.well-known/core" or via the CoRE resource directory. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 3 March 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 5. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8. Legacy IP Considerations . . . . . . . . . . . . . . . . . . 6 70 9. CoRE Discovery . . . . . . . . . . . . . . . . . . . . . . . 6 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 12.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Dyncast support in a network provides a client with a fresh optimal 81 path to a service provider instance, where optimality includes both 82 path and service provider characteristics. As a service invocation 83 usually takes more than one packet, dyncast needs to provide instance 84 affinity for each service invocation. Naive implementations of 85 instance affinity require per-application, per service-invocation 86 state in the network. 88 The present short document defines a way to provide instance affinity 89 that does not require, but also does not rule out per-application 90 state. 92 It also discusses how the information that an application needs to 93 operate this mechanism can be provided via the discovery mechanisms 94 offered by a CoRE (Constrained RESTful Environments) server, either 95 in "/.well-known/core" or via the CoRE resource directory. 97 [I-D.liu-dyncast-ps-usecases] lists use cases of dyncast. The 98 present document does not discuss the specifics of how the network 99 provides dyncast, such as the way service instance metrics enter path 100 computations. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in 107 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 This document uses the terminology of [I-D.liu-dyncast-ps-usecases], 111 in particular _Service_ and _Service Instance_ (the latter often 112 abbreviated to "Instance"). It also defines the following terms: 114 Client: The system that requests a service. 116 Service invocation: A single transaction between client and a 117 service instance. The client is interested in talking to the same 118 service instance throughout one service invocation. Subsequent 119 and parallel service invocations can use different service 120 instances without a problem and therefore do not require affinity. 122 Instance Affinity: The ability of the network to send all the 123 packets of a service invocation to the same service instance. 124 (Note that this doesn't necessarily imply path affinity -- the 125 client does not care about the path, only about getting to the 126 same service instance.) 128 Service period: The temporal granularity (rhythm) in which the 129 network updates the optimal paths it provides for a service. 131 Service stretch: The maximum amount of time that the network plans 132 to provide instance affinity for a service invocation. 134 3. Assumptions 136 This document makes a number of assumptions, some of which are 137 fundamental to its technical approach, but some of which are only 138 required for the exposition chosen in this document. A future 139 version of this document will clearly separate these two kinds of 140 assumptions. 142 Due to experience with overly eager load-based updates to routing 143 metrics, we assume that metrics will be updated on the scale of tens 144 of seconds. To simplify exposition we therefore set the service 145 period to 10 seconds (assumptions of this kind are intended to be 146 possible without loss of generality, but should not be wildly off). 148 We assume the affinity processing for the entire network will be on a 149 rhythm that is consistent with the service period. Updates take 150 effect at the start of a new service period. The entire network is 151 loosely synchronized on this rhythm. The clients are also aware of 152 this rhythm. 154 We assume the service stretch will be quite limited, on the order of 155 (a generous) five minutes or less. As a result, any service 156 invocation covers less than 32 service periods. Services that do 157 need longer service stretches will need to renew the service 158 invocation regularly (by checking whether the service instance has 159 changed upon such a renewal, any handover effort needed can be 160 minimized). 162 Service identifiers take the form of IPv6 addresses, or more 163 typically, IPv6 prefixes. The client is able to complete the prefix 164 with application information. (In a pinch, the client can obtain a 165 complete current address via DNS lookup.) 167 4. Objectives 169 Dyncast needs to provide instance affinity. The present document 170 outlines how to achieve this without creating per application, or 171 worse, per invocation state in the network. 173 The network does not provide any signaling to the clients beyond what 174 is expected in an IPv6 environment. 176 In summary, the objective of this draft is to define a stable client 177 interface to the instance affinity mechanism (and to motivate why 178 this interface is useful). This interface is designed to remain 179 stable even while the network support for this mechanism is evolving. 181 5. Approach 183 We number the service periods with a cyclic numbering system that 184 wraps around about every two service stretches. The network and the 185 clients are aware of the current service period number; the 186 synchronization requirement between them is that clients typically 187 aren't ahead of the network. 189 When starting a new service invocation, the client builds an IPv6 190 address out of the service identifier and its view of the current 191 service period number (or it obtains this address using a DNS 192 lookup), essentially filling in 6 bits (for the numbers assumed 193 here). Service requests and the resulting communication within the 194 invocation are addressed to this current address. The client stores 195 the current address with the service invocation when initializing it; 196 it is not ever updated for this invocation. 198 The network keeps its path optimization state relative to (or indexed 199 by) the current period number. Routing updates can be processed at 200 any time but do not lead to an update of the path optimization state 201 for any service period. The result is that the path chosen after a 202 routing update may no longer be optimal, but that instance affinity 203 is kept. For each service, a pointer for the best service instance 204 is kept for the current and the last 32 service periods. 206 6. Discussion 208 The approach presented provides instance affinity without requiring 209 per application or per invocation state in the network. It does 210 require up to 32 copies of what are essentially host routes per 211 service instance. The state scales with the number of service 212 instances, and not with the number of clients. 214 The approach is based on IPv6. It can be made to work in an IPv4 215 network, if there are plentiful IPv4 addresses available (see also 216 Section 8). 218 7. Details 220 The service period number could simply be inserted in the service 221 identifier, or more complex computation could be performed to make 222 the current addresses generated this way stand out in a forwarding 223 engine. 225 Naïve clients will start a service invocation with a DNS lookup. 226 This allows the insertion of the period number to be performed in a 227 specialized DNS server for the service. Of course, this requires 228 short time to live (TTL) values and clients that do not on their own 229 cache the look up results. 231 So the preferred variant is for the client to be aware of the current 232 service period number and to do the insertion by itself on each new 233 service invocation. 235 8. Legacy IP Considerations 237 To make this work with IPv4 addresses as service identifiers, we 238 would need 6 bits that can be varied over time. This is likely too 239 expensive for many applications. An alternative approach is to use 240 the port number for the 6 bits. This would mean that the network 241 would need to look up paths both on destination IP address and 242 destination port number (48-bit addressing). For IPv4, this should 243 be good enough. 245 9. CoRE Discovery 247 For use with IPv6, this document defines target attributes to enable 248 CoAP clients [RFC7252] to discover the availability of affinity 249 addressing and where in the address it is intended to be applied. 251 The target attributes are: 253 * "affinity-pos": The starting bit position (counting from most 254 significant bit first) of the sequence of bits where the service 255 period number can be inserted into the IPv6 address given. 257 * "affinity-len": The number of bits of the sequence of bits where 258 the service period number can be inserted into the IPv6 address 259 given. 261 * "affinity-period": The number of seconds a service period spans. 263 "affinity-period" is used as a divisor of the synchronized time in 264 seconds, yielding an incremented quotient for the next service 265 period, the lower "affinity-len" bits are then used as the service 266 period number. 268 Because of general availability of this time scale, the synchronized 269 time is interpreted according to POSIX [TIME_T]. (POSIX time is also 270 known as "UNIX Epoch time".) Note that leap seconds are handled 271 specially by POSIX time and this results in a 1 second discontinuity 272 several times per decade, which should be of rather limited 273 consequence for service affinity. 275 Using the example at the end of Section 5 of [RFC6690], a server 276 providing a large resource into a dyncast (anycast) pool could 277 include in its "/.well-known/core": 279 REQ: GET /.well-known/core?rt=firmware 281 RES: 2.05 Content 282 ;rt="firmware";sz=262144;affinity-pos=122; 283 affinity-len=6;affinity-period=10 285 (Additional line break for exposition. Obviously, more complex 286 services than simple retrieval of a large object could be offered.) 288 This link could turn up in a resource directory 289 [I-D.ietf-core-resource-directory] entry that looks like: 291 ;rt="firmware";sz=262144; 292 affinity-pos=122;affinity-len=6;affinity-period=10 294 Note that the address given here has a number of bits set in the 295 section to be overwritten by the service period number to be 296 inserted. 298 10. Security Considerations 300 TBD 302 11. IANA Considerations 304 No IANA action is required for this concept draft. 306 Currently, CoRE target attributes are not subject to registration; 307 this draft defines three new target attributes as per Section 9. 309 12. References 311 12.1. Normative References 313 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 314 Application Protocol (CoAP)", RFC 7252, 315 DOI 10.17487/RFC7252, June 2014, 316 . 318 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 319 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 320 . 322 [I-D.ietf-core-resource-directory] 323 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 324 D. Stok, "CoRE Resource Directory", Work in Progress, 325 Internet-Draft, draft-ietf-core-resource-directory-28, 7 326 March 2021, . 329 [TIME_T] The Open Group Base Specifications, "Open Group Standard: 330 Vol. 1: Base Definitions, Issue 7", Section 4.16 'Seconds 331 Since the Epoch', IEEE Std 1003.1, 2018 Edition, 2018, 332 . 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, 337 DOI 10.17487/RFC2119, March 1997, 338 . 340 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 341 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 342 May 2017, . 344 12.2. Informative References 346 [I-D.liu-dyncast-ps-usecases] 347 Liu, P., Willis, P., and D. Trossen, "Dynamic-Anycast 348 (Dyncast) Use Cases & Problem Statement", Work in 349 Progress, Internet-Draft, draft-liu-dyncast-ps-usecases- 350 01, 15 February 2021, . 353 Author's Address 355 Carsten Bormann 356 Universität Bremen TZI 357 Postfach 330440 358 D-28359 Bremen 359 Germany 360 Phone: +49-421-218-63921 361 Email: cabo@tzi.org