Skip to main content

Providing Instance Affinity in Dyncast

Document Type Expired Internet-Draft (individual)
Expired & archived
Author Carsten Bormann
Last updated 2022-03-03 (Latest revision 2021-08-30)
Replaces draft-bormann-dyncast-affinity
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


Dyncast support in a network provides a client with a fresh optimal path to a service provider instance, where optimality includes both path and service provider characteristics. As a service invocation usually takes more than one packet, dyncast needs to provide instance affinity for each service invocation. Naive implementations of instance affinity require per-application, per service-invocation state in the network. The present short document defines a way to provide instance affinity that does not require, but also does not rule out per-application state. It also discusses how the information that an application needs to operate this mechanism can be provided via the discovery mechanisms offered by a CoRE (Constrained RESTful Environments) server, either in "/.well-known/core" or via the CoRE resource directory.


Carsten Bormann

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)