DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling Protocol (GRASP)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 17 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Overview

GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] is intended to be used for Service Announcement, Discovery and Selection especially in network or for network services intended to be deployable without dependencies against centralized "server" entities, such as fully autonomous networks or Autonomous Service Agents (ASA).¶

To support these goals, GRASP provides a hop-by-hop network wide flooding of announcement or discover messages reliably and secured and without looping messages. This flooding is achieved with a per-hop GRASP agent responsible for per-hop flooding of GRASP messages.¶

While such flooding based procedures do not necessarily scale to arbitrarily large number of services or services instances, it is easy to calculate how many service anouncement and/or discovery messages can be supported in a target network without exceeding reasonable limits on those service messages use of network resources. Typically, all services required by the network infrastructure, as well as core application services will scale perfectly well with this model and eradicate the requirement for provisioning of centralized entities and building redundancy for them.¶

DNS-SD via mDNS [RFC6763] was introduced with the same purposes, but does not have a solid multi-hop flooding modely to rely on because it solely relies on ASM IP Multicast, and there is no IETF standards track solution through which this service can be autonomously provided. Instead, it would have to rely on protocols such as PIM-SM or Bidir-PIM which all require careful planning of centralized service entities called Rendesvous points - as well as planning and deployment redundancy for them. The non-ability to use his service for DNS-SD with mDNS first lead to attempts building flooding for mDNS messages without an underlying IP multicast service as an mDNS message flooding through various commercial vendors, but these solutions all suffered from the problem, that mDNS messages themselves do not provide the means for loop detection.¶

Ultimately, mDNS today is strongly recommended to only be used within IP subnets, and no expectation of reach beyond a single subnet. Instead, any larger-scale network deployments of mDNS would rely on mDNS to unicast DNS proxies which in turn depend on explicitly provisioned and "centralized" deployed DNS servers. Which is not a well enough feasible solution for service that easily could and should operate autonomously: Just plug a few routers together, have services on them be able to run and be used by any other client in the network without any configuration. This is what ANIMA ANI achieves to deliver, but this is also what very ilghtweight implementations of only GRASP on every router can deliver - without necessarily requirring the rest of ANI - BRSKI or ACP.¶

What GRASP itself does not define though is what DNS-SD defines very well, and that is the nature of what a service announcement/discover is: What is the name of a service ? When there are multiple instances (entities) that offer the service, how are they distinguished from one another (service-instance names) ? How should a client for a service determine, which service instance to use ? Some services may be high priority than others. Other instances may be equally well usebable but have different performances and load sharing by clients is desired. These and others are all questions and requirements for any service announcement/discovery/selection mechanism, and DNS-SD has well defined them. So it seems frivolous to have to reinvent all these solutions, especially when it would lead to useless duplication of IANA registries such as service registries already existing for use with any service discovery mechanism, but primarily used for DNS-SD.¶

When attempting to thus reuse what was well defined for DNS-SD, the first idea coming to mind is likely to simply encapsulate mDNS messages into GRASP, but that wold simply create a lot of unnecessary overhead on the wire as well as unnecessary processing.¶

As RFC6763 explains, DNS-SD itself is not necessarily the ideal way to define signalling for service announcement/discovery/selection, but it is based on decades long experience in Apple with the (proprietary) Name Binding Protocol (NBP), and DNS-SD was merely the approach on how to map the information required for services into DNS. Both DNS unicast, as well as DNS multicast (mDNS). This effectively lead to a whole layer of complexity, which is to split of the information required for a single service into multiple DNS Resource Records (DNS-RR) because that is how DNS operates. In result, a single DNS-SD service instance consists of a SRV RR, PTR RR, TXT RR, A and/or AAAA RR.¶

None of this complexity is necessary in GRASP, because in GRASP it is very simple to define a CBOR structure carrying all the desired information elements for a service instance announcement and/or discovery, and this document is exactly doing this: Specifying a direct binding from the service instance information elements as specified in RFC6760 and then detailled in DNS-SD (RFC6763) into a single type of GRASP message (GRASP objective) so that there can be a single consistent service instance definition with its information elements, but two different mappings into separate underlying "protocol machineries": DNS-SD into DNS (unicast/multicast) and this document defining mapping into GRASP.¶

One of the big benefits of this approach is that it also allows to easily convert DNS-SD service information into GRASP and vice versa. For example via proxies. It is equally possible to build APIs for applications that only need to b