idnits 2.17.00 (12 Aug 2021) /tmp/idnits62409/draft-eckert-anima-grasp-dnssd-03.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (4 March 2022) is 71 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG T.T.E. Eckert 3 Internet-Draft Futurewei 4 Intended status: Standards Track M. Boucadair 5 Expires: 5 September 2022 C. Jacquenet 6 Orange 7 M. Behringer 8 4 March 2022 10 DNS-SD Compatible Service Discovery in GeneRic Autonomic Signaling 11 Protocol (GRASP) 12 draft-eckert-anima-grasp-dnssd-03 14 Abstract 16 DNS Service Discovery (DNS-SD) defines a framework for applications 17 to announce and discover services. This includes service names, 18 service instance names, common parameters for selecting a service 19 instance (weight or priority) as well as other service-specific 20 parameters. For the specific case of autonomic networks, GeneRic 21 Autonomic Signaling Protocol (GRASP) intends to be used for service 22 discovery in addition to the setup of basic connectivity. 23 Reinventing advanced service discovery for GRASP with a similar set 24 of features as DNS-SD would result in duplicated work. To avoid 25 that, this document defines how to use GRASP to announce and discover 26 services relying upon DNS-SD features while maintaining the intended 27 simplicity of GRASP. To that aim, the document defines name 28 discovery and schemes for reusable elements in GRASP objectives. 30 Note to the RFC Editor 32 Please replace all occurrences of rfcXXXX with the RFC number 33 assigned to this document. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 5 September 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Service and Name Objectives . . . . . . . . . . . . . . . 4 71 3.2. Objective Value Reuseable Elements Structure . . . . . . 5 72 3.3. Reuseable Elements . . . . . . . . . . . . . . . . . . . 6 73 3.3.1. Sender Loop Count . . . . . . . . . . . . . . . . . . 6 74 3.3.2. Service Element . . . . . . . . . . . . . . . . . . . 6 75 3.3.3. Name Element . . . . . . . . . . . . . . . . . . . . 9 76 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 11 77 4.1. Using GRASP Service Announcements . . . . . . . . . . . . 11 78 4.2. Further Comparison with DNS-SD . . . . . . . . . . . . . 13 79 4.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 13 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 83 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 15 85 9.1. 03 - Refresh . . . . . . . . . . . . . . . . . . . . . . 15 86 9.2. 02 - Revived after charter round 1 finished . . . . . . . 15 87 9.3. 01 - . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 9.4. 00 - Initial version . . . . . . . . . . . . . . . . . . 15 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 91 10.2. Informative References . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Overview 96 DNS Service Discovery (DNS-SD) [RFC6763] defines a framework for 97 applications to announce and discover services. This includes 98 service names, service instance names, common parameters for 99 selecting a service instance (weight, priority) as well as other 100 service-specific parameters. 102 GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] is intended to 103 also be used for service discovery purposes. Reinventing service 104 discovery for GRASP with a similar set of features would result in 105 duplication of work. Therefore, this document defines how to use 106 GRASP to announce and discover services in a way that inherits DNS-SD 107 features and also tries to be compatible in spirit as much as 108 possible while still maintaining the intended simplicity of GRASP. 110 The goal of this document is to permit defining service and their 111 parameters once and then use that in GRASP, mDNS and (unicast) DNS. 112 Future work can also define DNS-SD <-> GRASP gateway functions. 114 This document primarily defines how to perform service discovery 115 across such a GRASP domain leveraging GRASP's options to perform 116 unsolicited flooding of announcements or flooding of requests, and 117 finding the closest service instances. Also, the document allows for 118 automatically discovering DNS-SD servers. Such features is meant to 119 optimize the flooding traffic in some deployments. 121 The initial use case of this document is to support what in DNS-SD is 122 done via mDNS but in larger networks - GRASP-Domains. Beside the 123 efficient flooding, GRASP provides reliability and security, which 124 are depending on the so called substrate used by GRASP for security 125 and hop-by-hop/end-to-end transport, such as the Autonomic control 126 plane (ACP), [RFC8994]. Providing compatibility with existing mDNS 127 service announcer or clients is possible, but not described in this 128 version of the document. 130 The encoding of information chosen in this document does not try to 131 use GRASP solely as a transport layer, but to also leverage the CBOR 132 structure of GRASP messages to natively encode the message elements 133 required for services in a way that is most simple - instead of using 134 GRASP only as, e.g., an encapsulation of otherwise unchanged DNS 135 message encodings. This is done to minimize the amount of coding 136 required (and not require any DNS code unless future gateway 137 functions are required), to increase the simplicity, minimize the 138 amount of data on the wire, and allow easier extensibility. On the 139 downside, the mechanisms provided here do not cover the whole slew of 140 possible options of DNS/DNS-SD, but instead only those deemed to be 141 required. Others can be added later. 143 In support of service discovery, this document also defines name 144 discovery and schemes for reusable elements in GRASP objectives which 145 are designed to be extensible so that future work that identifies 146 elements required across multiple objectives do not need to define a 147 scheme how to do this. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 This document makes use of terms and concepts defined in [RFC8990]. 159 3. Specification 161 3.1. Service and Name Objectives 163 Unsolicited, flooded announcements (M_FLOOD) in GRASP and solicited 164 flooded discovery (M_DISCOVERY) operate on the unit of GRASP 165 technical objectives (identified by 'objective-names' as discussed in 166 Section 2.10 of [RFC8990]). Therefore, a scheme is required to 167 indicate services via 'objective-names'. 169 Note: Future work may want to reuse the encodings related to 170 services (defined below in this document) inside other (multicast 171 or unicast only) objective exchanges, in which case the service 172 names are not impacted. 174 When a technical objective (simply referred to as objective) is meant 175 to be solely about a service name, the objective MUST uses an 176 'objective-name' of 'SRV.'. This naming scheme is 177 meant to avoid creating duplicates and, potentially, inconsistent 178 name registrations for those objectives vs. registrations done, for 179 example, for DNS-SD. 181 When an objective is meant announcement and discovery of a DNS 182 compatible such as "www-internal" in "www- 183 internal.example.com", the objective SHOULD use an objective-name of 184 NAME.. See Section 3.3.3 for more details. 186 3.2. Objective Value Reuseable Elements Structure 188 Because service discovery, as explained in the prior section, needs 189 to utilize different objectives, it requires cross-objective 190 standardized encoding of the elements of services. GRASP does not 191 define standardized message elements for the message body (called 192 "objective-value") of GRASP messages. Therefore, this document 193 introduces such a feature. 195 objective-value /= { 1*elements } 196 elements //= ( @rfcXXXX: { 1*relement } ) 198 relement = ( relement-codepoint => relement-value ) 199 relement-codepoint = uint 200 relement-value = any 202 If an objective relies upon reusable elements, the 'objective-value' 203 MUST be a CBOR map and the reusable elements are found under the key 204 "@rfcXXXX". 206 Objectives that do not want reusable elements may use any objective- 207 value format including a CBOR map, but they can not use the 208 "@rfcXXXX" key if they use a map. This approach was chosen as the 209 hopefully least intrusive mechanism given how by nature all of 210 "objective-value" is meant to be defined by individual objective 211 definitions. 213 The value of "@rfcXXXX" is a map of reusable elements. Each 214 'relement' has an IANA registered element-name and codepoint (see 215 Section 6). The element-name is for documentation purposes only, 216 CBOR encodings only use the numeric codepoint for encoding efficiency 217 to minimize the risk for this solution to not be applicable to low- 218 bitrate networks such as in IoT. 220 Format and semantic of the relement-value is determined by the 221 specification of the reusable element as is the fact whether more 222 than one instances of the same reusable element are permitted. 224 Reusable elements should be defined to be extensible. The methods 225 used depend on the complexity of the element and the likely need to 226 extend/modify the element with backward or non-backward compatible 227 information. The following is a set of initial options to choose 228 from: 230 Element values that are a map MUST permit and reserve key value 0 231 (numerical) for private extensions of the element defined by the 232 individual objective. 234 Element values that are a map MUST NOT use bareword key values 235 starting with a "_". These too are for private extensions defined by 236 the individual objective. 238 Element values SHOULD be defined so that additional keys in maps and 239 additional elements at the end of arrays can be ignored by prior 240 versions of the definition. Whenever a newer definition is made for 241 an element where this rule is violated, the element SHOULD be changed 242 in a way for older version recipients to recognize that it is not 243 compatible with it. 245 One method to indicate compatibility is a traditional version 246 ".". Within the same version number, 247 increasing version numbers must be backward compatible. 248 Different version numbers are not expected to be compatible 249 with each other. If they are, then this can be indicated by 250 including multiple version numbers. 252 A compressed form of version compatibility information is the use of 253 a simple bitmask element where each bit indicates a version that the 254 represented data is compatible with. 256 3.3. Reuseable Elements 258 3.3.1. Sender Loop Count 260 relement-codepoint //= ( &(sender-loop-count:1) => 1..255 ) 262 Sender-loop-count is set by the sender of an objective message to the 263 same value as the loop-count of the message. On receipt, distance = 264 ( sender-loop-count - loop-count ) is the distance of the sender from 265 the receiver in hops. This element can be used for informational 266 purposes in M_FLOOD and M_DISCOVERY messages and may be required to 267 be used in these messages by the specification of other elements 268 (such as the service element described below). This element MUST 269 occur at most once. If a receiver expects to use the distance but 270 sender-loop-count was not announced, then distance SHOULD be assumed 271 to be 255 by the receiver. 273 3.3.2. Service Element 275 The srv-element (service element) is a reusable element to request or 276 announce a service instance or to request and list service instance 277 names. 279 relement-codepoint //= ( &(srv-element:2) => context-element ) 281 context-element = { 282 ?( &(private:0) => any), 283 ?( &(msg-type:1 => msg-type), 284 ?( &(service:2) => tstr), 285 *( &(instance:3) => tstr), 286 ?( &(domain:4) => tstr), 287 ?( &(priority:5) => 0..65535 ), 288 ?( &(weight:6) => 0..65535 ), 289 *( &(kvpairs:7) => { *(tstr: any) }, 290 ?( &(range:8) => 0..255 ), 291 *( &(clocator:9) => clocator), 292 } 293 clocator = [ context, locator-option ] 294 context = cstr 295 locator-option = ; from GRASP 297 msg-type = &( describe: 0, describe-request:1, 298 enumerate:2, enumerate-request:3 ) 300 Service: A service name registered according to RFC6335. If it is 301 not present, then objective-name MUST be SRV. where 302 is the service-name. 304 Instance: The of a DNS-SD Service Instance Name ( 305 . . ). It is optional, see 306 Section 4.2. 308 Domain: The equivalent of the field of a DNS-SD Service 309 Instance Name. If domain is not present, this is equivalent to 310 ".local" in DNS (as introduced by mDNS) and implies the unnamed 311 "local" domain, which is the GRASP domain across which the message 312 is transmitted. 314 Priority, Weight: Service Instance selection criteria as defined in 315 RFC2782. If either one is not present, its value defaults to 0. 317 Kvpairs: Map of key/value pairs that are service parameters in the 318 same format as the key/value pairs in TXT field(s) of DNS-SD TXT 319 records as defined in RFC6763, section 6.3. 321 Range: Allows to flexibly combine distance and priority/weight based 322 service selection according to the definition of distance in 323 Section 3.3.1. 325 If min-distance is the distance of the closest service announcer, 326 and min-range the range announced by it, then the recipient MUST 327 consider the priority/weight of all service announcers that are 328 not further away than (min-distance + min-range). If not 329 included, range defaults to 255. 331 If range is announced, the sender-loop-count element MUST also be 332 announced. 334 Clocator: The "contextual locator" allows to indicate zero or more 335 locators for the indicated service instance. The context element 336 indicates in which context the locator-option is to be resolved. 337 The reserved context value of "" (empty string) indicates the 338 GRASP domain used, aka: the "local" context in which the service 339 announcement is made. The reserved context value of "0" indicates 340 the default routing context of the announcing node. This is often 341 called "global table", "VRF 0" or "default VRF" on nodes using the 342 "VRF" abstraction. Any other value is a string specifying a 343 context such as another VRF. 345 The mechanism by which originator and recipient of the srv-element 346 agree on common naming for contexts is outside the scope of this 347 specification. The context therefore allows to indicate locators 348 both for the context through which the GRASP message distributed 349 the srv-element (GRASP domain) as well as that for other contexts. 350 Assume the GRASP domain is the ACP, then clocators in ACP would 351 have a context of "", clocators in the global routing table (part 352 of the data-plane) a context of "0", and clocators on other VRFs 353 (also part of data-plane) a clocator that is their string name. 355 If no locators are indicated, then the locator of the service(s) 356 is the optional locator-option of the GRASP message in which the 357 objective is contained meant to be used for the service(s) 358 indicated and the clocator implied is "". 360 If locator(s) are indicated, the messages location-option must be 361 ignored for the service (but may be necessary to be present for 362 other purposes of the objective). 364 Msg-type Type (aka: intention) of the srv-element. If not present, 365 it is assumed to be "describe". 367 Describe: Describes one service instance. At least one clocator is 368 required for a positive response, all other fields are permitted, 369 but optional. "Describe" is used in M_FLOOD for unsolicited 370 announcements of services (flooded), in M_RESPONSE messages for 371 solicited announcements of a service and in M_NEGOTIATE for 372 negotiated announcements (both unicasted). If clocator is not 373 included, then all fields except service and instance (and msg- 374 type and private) must not be included and the srv-element 375 provides a negative reply: No information about this service/ 376 service instance. This is only permitted in unicasted "describe" 377 messages. 379 Describe-request: Request for a "describe" reply. It is used in 380 M_DISCOVERY (flooded) for solicited discovery of services or in 381 M_REQ_SYN (unicasted) for negotiated discovery of service 382 instance(s). In "describe-request", only service is mandatory 383 (but can be provided via the objective-name field of the message), 384 and domain is optional. "Instance" is optional. If provided, 385 then the recipient is asked to provide information about the named 386 instance only. All other fields of srv-element are to be ignored 387 by the receiver in this specification, but a semantic for setting 388 them may be introduced in follow-up work, specifically to filter 389 replies by the indicated fields. 391 "Describe-request" without instance MAY be answered by "Enumerate" 392 (see below) if the responder has so many instances that it thinks 393 the initiator should rather first select one or fewer instances 394 and ask for their description. The sender of te "Describe- 395 request" MUST be prepared to accept that answer and as necessary 396 follow up with "Describe-request" with the instance names of 397 interest. 399 Enumerate: Used in the same GRASP messages as "describe", but 400 instead of providing information about one service instance, it is 401 listing service instance names. The purpose of enumerate is the 402 same as browsing a service in DNS-SD. It would be followed by 403 some human or automated selection of one or more instances and 404 then a "describe" M_REQ_SYN request for those instances sent to 405 the source of the "enumerate" to learn about the locators and 406 other parameters of the service instances. 408 In this specification, all fields other than service, instance and 409 domain (and msg-type and private) must be unset in "enumerate". 411 Enumerate-request: Requests an "enumerate" reply. It is used in the 412 same way as "Describe-request" except that instance would usually 413 not be set (because in that case it is more useful to send a 414 "Describe-request"). 416 3.3.3. Name Element 418 The NAME, elements is meant to provide basic name resolution 419 comparable to mDNS name resolution for GRASP domains where this is 420 desirable and no better name resolution exist - for example in the 421 ACP where there is no requirement for DNS. 423 Because the GRASP service lookup (unlike) DNS does not mandate that 424 nodes have names (not even service instance names), the use of names 425 is primarily meant to support legacy software. New designs should 426 instead look up only services and service instance names, and nodes 427 should announce their names as service instance names for the 428 services they offer: 430 For example consider a GRASP (ACP) domain of "example.com". The node 431 providing some "www" service could have a name "www-internal" which 432 means GRASP objective NAME.www-internal, that objective value would 433 include primarily the nodes IP address(es) and the port number for 434 the www service would have to be guessed (80). Better, the node 435 would announce GRASP objective SRV.www and the objective value would 436 include the service instance name www-internal and the (TCP) port 437 information (80 or a non-default port). 439 relement-codepoint //= ( &(name-element:3) => context-element ) 441 context-element //= { 442 *( &name:10) => tstr), 443 } 445 ipv6-address-option = [O_IPv4_ADDRESS, ipv6-address] 446 ipv4-address-option = [O_IPv6_ADDRESS, ipv6-address] 447 locator-option /= ipv4-address-option 448 locator-option /= ipv6-address-option 450 Name information is carried in the name-element relement. It is a 451 context-element like the one used for srv-element except that it adds 452 the name component and that it does not permit the service and 453 instance components and that it allows only describe and describe- 454 request values in the msg-type. Clocators MUST use the ipv6-address- 455 option or ipv4-address-option in the locator-option component. 457 TBD: Unclear if/how we should best formalize the differences in the 458 context element permitted information between services and names. 459 The above is quite informal. 461 Priority, weight, kvpairs, range (and of course private) MAY be used 462 in describe messages to support multiple instances of the same name, 463 as used for name anycast/prioritycast. 465 Nodes may have multiple names. These can be listed in the name 466 component. If a nodes names have the notion of a primary name and 467 secondary names then the primary name should be the first in the list 468 of names. In DNS-SD, the name pointed to by CNAME RRs can be 469 considered to be the primary name. A describe-request for a non- 470 primary name SHOULD return in the list of names the requested name 471 and the primary name. 473 Note that there is no reverse lookup defined in this version of the 474 document (no lookup from IP address to name). 476 4. Theory of Operation 478 4.1. Using GRASP Service Announcements 480 TBD: This section contains a range of details that should become 481 normative in later versions. 483 This section provides a step by step walk-through of how to use GRASP 484 service announcements and compares it to DNS-SD. 486 The most simple method to use GRASP service discovery is to select 487 (and if still necessary, register) a and start one or 488 more agents (e.g.: ASAs) announcing their service instance(s) via 489 GRASP. At minimum, an agent should periodically (default 60 seconds) 490 announce the service instance via GRASP M_FLOOD messages as an 491 objective SRV. with a srv-element and a sender-loop- 492 count element (default 255). The ttl of the GRASP message should be 493 3.5 times the announcement period, e.g.: 210000 msec. 495 Consumers of the service will use GRASP to learn of the service 496 instances and select one. This approach is most similar to the use 497 of DNS-SD with mDNS except that the scope of the announcement is a 498 whole GRASP domain (such as the ACP) as opposed to a single IP subnet 499 in mDNS and that mDNS primarily relies on request & reply but in its 500 standard not on periodic unsolicited announcements. We describe here 501 the unsolicited flooding option via M_FLOOD first because it is 502 recommended for services with a dense population of service consumers 503 and it is most simple to describe. 505 On the service announcer, the parameters priority, weight and range 506 of the service instance can be selected from intent or configuration 507 - or left at default. The default range 255 will result in selection 508 of a random target of the service like in DNS-SD. Setting priority/ 509 weight allows to prioritize and weigh the selection as in DNS-SD. 510 Setting range to 0 allows to select the closest target, priority/ 511 weight are only compared between targets of the same shortest 512 distance. Distance based options are not available in DNS-SD because 513 it does not expect that network distance is available to arbitrary 514 DNS-SD client. It is available to GRASP clients though. Using 0 < 515 range < 255 allows for a hybrid priority/weight and distance based 516 service selection (e.g.: Select the highest priority instance within 517 a range of 5 hops). 519 If the service is a non-GRASP service, then the result of the service 520 discovery has to be a transport locator to which the client can open 521 a connection and talk the protocol implied by the service. This 522 transport locator(s) have to be put into the clocator parameter. The 523 context of the clocator would normally be "", aka: the transport 524 locator is in the IP reachability associated with the GRASP domain 525 (e.g.: IPv6 of the ACP for ACP GRASP domain). 527 If an ACP service is announced via ACP GRASP, then the locator(s) can 528 be O_IPv6_LOCATOR or O_FQDN_LOCATOR. The O_IPv6_LOCATOR is used if 529 the service is defined to be available via some transport layer port 530 (TCP, UDP or other). The determination of the actual transport 531 connection to be used is the same as in DNS-SD: If the transport 532 protocol is not TCP or UDP, it has to be implied by the specification 533 of or can be detailed in kvpairs which carries the 534 same information as DNS-TXT TXT RRs of the service. Alternatively, 535 the transport-proto field of the locator can contain any valid IP 536 protocol directly (TBD), which is not possible in DNS-SD. 538 Like DNS-SD, service discovery via GRASP does not require allocation 539 and use of well-known ports for services. Unlike DNS-SD, there is no 540 need in GRASP to define service instance names or target names. In 541 DNS SD, PTR RRs resolve from a service name to a set of service 542 instance named. SRV and TXT RRs resolve from service instance names 543 to service instance parameters including the target. A target is the 544 DNS host name of the service instance. It gets resolved via A/AAAA 545 RRs to IPv4/IPv6 addresses of the target. In GRASP service 546 discovery, host names are not used. Service instance names are 547 optional too. Service instance names are useful for human 548 diagnostics and human selection of service instances. In fully 549 automated environments, they can be are less important. For 550 diagnostic purposes, it is recommended to give service instances 551 service instance names in GRASP service announcements. 553 A locator with O_URI_LOCATOR type can be used in GRASP to indicate a 554 URI for the transport method for a service instance. If the URI 555 includes a host part, care must be taken to use only IP addresses in 556 the host part if the context of the GRASP domain does not support 557 host name resolution - such as the ACP - or to use the GRASP name 558 resolution mechanisms described elsewhere in this document. And that 559 the addresses indicated are also reachable in the GRASP domain. For 560 example, in service announcements across a DULL GRASP domain, only 561 the IPv6 link-local addresses on that subnet must be used (this 562 applies equally when using the O_IPv6_LOCATOR). 564 Instead of using M_FLOOD to periodically announce service instances, 565 M_DISCOVERY can be used to actively query for service instances. The 566 msg-type type must then be "describe-request". Because no periodic 567 flooding is necessary, this solution is more lightweight for the 568 network when the number of requesting clients is small. Note though 569 that the M_DISCOVERY will terminate as soon as a provider of the 570 objective is found, so the service instances found will be based on 571 distance and therefore selection of instance by priority and weight 572 will not work equally well as with M_FLOOD. Consider for example a 573 central service instance in the NOC that should always be used (for 574 example for centralized operational diagnostics) unless the WAN 575 connection is broken, in which case distributed backup service 576 instances should be used. With the current logic of M_DISCOVERY this 577 is not possible. 579 4.2. Further Comparison with DNS-SD 581 Neither the GRASP SRV.* objective-name, the service name nor any 582 other parameter explicitly indicate the second label "_tcp" or "_udp" 583 of DNS-SD entries. DNS-SD, RFC6763 explains how this is an 584 unnecessary, historic artifact. 586 This version of the document does not define an equivalent to "_sub" 587 structuring of service enumeration. 589 This version of the document does not define mechanisms for reverse 590 resolution of arbitrary services: An inquirer may unicast M_SYNC_REC 591 to a node with a series of objectives with specific service names of 592 interest and describe-request, but there is no indication of "ANY" 593 service. 595 4.3. Open Issues 597 TBD: Examine limitations mentioned in "in this version of the text/ 598 document". 600 TBD: The GRASP specification does currently only permit TCP and UDP 601 for the transport-proto element. This draft should expand the GRASP 602 definitions to permit any valid IP protocol. We just need to decide 603 whether this should only apply to the locator in the srv element or 604 also retroactive to the locator-option in GRASP messages (maybe not 605 there ?). 607 TBD: A fitting CBOR representation for a kvpair key without value 608 needs to be specified so that it can be distinguished from an empty 609 value as outlined in RFC6763 section 6.4. 611 TBD: In this version, every service/service-instance is an element by 612 itself. Future versions of this document may add more encoding 613 options to allow more compact encoding of recurring fields. 615 TBD: Is there a way in CDDL to formally define the string names of 616 the relement-codepoint's ? 618 5. Security Considerations 620 TBD. 622 GRASP-related security issues are discussed in Section 3 of 623 [RFC8990]. 625 6. IANA Considerations 627 This document requests IANA to create a new "GRASP Objective Value 628 Standard Elements" subregistry under the "GeneRic Autonomic Signaling 629 Protocol (GRASP) Parameters" registry. 631 The values in this table are names and a unique numerical value 632 assigned to each name. Future values MUST be assigned using the RFC 633 Required policy as dedfined in Section 4.7 of [RFC8126]. The 634 numerical value is simply to be assigned sequentially. The following 635 initial values are assigned by this document: 637 sender-loop-count 1 [defined in rfcXXXX] 639 srv-element 2 [defined in rfcXXXX] 641 name-element 3 [defined in rfcXXXX] 643 This document updates the handling of the "GRASP Objective Names" 644 Table introduced in the GRASP IANA considerations as follows: 646 Assignments for objective-names of the form "SRV." and 647 "NAME." are special. 649 Assignment of "SRV." can only be requested if is also a 650 registered service-name according to RFC6335. The specification 651 required for registration of a "GRASP Objective Name" MUST declare 652 that the intended use of the objective name in GRASP is intended to 653 be compatible with the indented use of the registered service name. 655 Registration of "SRV." in the "GRASP Objective Name" table is 656 optional, but recommended for all new service-names that are meant to 657 be used with GRASP. Non-registration can for example happen with 658 DNS-SD <-> GRASP gateways that inject pre-existing service-names into 659 GRASP. Note that according to the GRASP RFC, registration is 660 mandatory, so this exemption for "SRV." is also an update to 661 that specification. 663 There MUST NOT be any assignment for objective names of the form 664 "NAME.". These names are simply used by GRASP nodes without 665 registration (just like names in mDNS). 667 7. Acknowledgements 669 8. Contributors 671 Brian Carpenter 673 9. Change log [RFC Editor: Please remove] 675 9.1. 03 - Refresh 677 9.2. 02 - Revived after charter round 1 finished 679 Reviving after ANIMA charter 01 is finished, adding new co-authors, 680 contributors. 682 Textual improvements, updating references. 684 9.3. 01 - 686 Only refreshing, no changes since -00. 688 9.4. 00 - Initial version 690 10. References 692 10.1. Normative References 694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 695 Requirement Levels", BCP 14, RFC 2119, 696 DOI 10.17487/RFC2119, March 1997, 697 . 699 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 700 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 701 . 703 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 704 Writing an IANA Considerations Section in RFCs", BCP 26, 705 RFC 8126, DOI 10.17487/RFC8126, June 2017, 706 . 708 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 709 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 710 May 2017, . 712 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 713 Autonomic Signaling Protocol (GRASP)", RFC 8990, 714 DOI 10.17487/RFC8990, May 2021, 715 . 717 10.2. Informative References 719 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 720 Autonomic Control Plane (ACP)", RFC 8994, 721 DOI 10.17487/RFC8994, May 2021, 722 . 724 Authors' Addresses 726 Toerless Eckert 727 Futurewei Technologies USA Inc. 728 2220 Central Expressway 729 Santa Clara, 95050 730 United States of America 731 Email: tte+ietf@cs.fau.de 733 Mohamed Boucadair 734 Orange 735 35000 Rennes 736 France 737 Email: mohamed.boucadair@orange.com 739 Christian Jacquenet 740 Orange 741 35000 Rennes 742 France 743 Email: christian.jacquenet@orange.com 745 Michael H. Behringer 746 Email: michael.h.behringer@gmail.com