@techreport{bormann-t2trg-affinity-00,
    number =    {draft-bormann-t2trg-affinity-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-bormann-t2trg-affinity/00/},
    author =    {Carsten Bormann},
    title =     {{Providing Instance Affinity in Dyncast}},
    pagetotal = 9,
    year =      2021,
    month =     aug,
    day =       30,
    abstract =  {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.},
}