idnits 2.17.1 draft-eckert-anima-grasp-dnssd-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 153: '...ng to RFC6335, the objective MUST uses...' RFC 2119 keyword, line 162: '...", the objective SHOULD use an objecti...' RFC 2119 keyword, line 187: '... MUST be a CBOR map and the reuseabl...' RFC 2119 keyword, line 206: '...useable elements SHOULD be defined to ...' RFC 2119 keyword, line 212: '...s that are a map MUST permit and reser...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 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) == Missing Reference: 'RFC8126' is mentioned on line 610, but not defined == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC6763' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-autonomic-control-plane' is defined on line 665, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-12 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG T. Eckert 3 Internet-Draft Huawei 4 Intended status: Standards Track October 30, 2017 5 Expires: May 3, 2018 7 DNS-SD compatible service discovery in GRASP 8 draft-eckert-anima-grasp-dnssd-00 10 Abstract 12 DNS Service Discovery (DNS-SD) defines the common framework for 13 applications to announce and discover services. This includes 14 service names, service instance names, common parameters for 15 selecting a service instance (weight, priority) as well as service 16 specific parameters. 18 GRASP is intended to also be used for service discovery. Reinventing 19 service discovery for GRASP with a similar set of fetures would 20 result in duplication of work. Therefore, this document defines how 21 to use GRASP to announce and discover services in a way that inherits 22 DNS-SD features and also tries to be compatible in spirit as much as 23 possibel while still maintaining the intended simplicity of GRASP. 25 The goal of this document is to permit defining service and their 26 parameters once and then use that in GRASP, mDNS and (unicast) DNS. 27 Future work can also define DNS-SD <-> GRASP gateway functions. 29 In support of service discovery, this document also defines name 30 discovery and schemes for reuseable elements in GRASP objectives 31 which are designed to be extensible so that future work that 32 identifies elements required across multiple objectives do not need 33 to define a scheme how to do this. 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 May 3, 2018. 51 Copyright Notice 53 Copyright (c) 2017 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 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Specification (Normative) . . . . . . . . . . . . . . . . . . 3 70 2.1. Service and Name Objectives . . . . . . . . . . . . . . . 4 71 2.2. Objective Value Reuseable Elements Structure . . . . . . 4 72 2.3. Reuseable Elements . . . . . . . . . . . . . . . . . . . 6 73 2.3.1. Sender Loop Count . . . . . . . . . . . . . . . . . . 6 74 2.3.2. Service Element . . . . . . . . . . . . . . . . . . . 6 75 2.3.3. Name Element . . . . . . . . . . . . . . . . . . . . 9 76 3. Explanations (Informative) . . . . . . . . . . . . . . . . . 11 77 3.1. Using GRASP service announcements . . . . . . . . . . . . 11 78 3.2. Further comparison with DNS-SD . . . . . . . . . . . . . 13 79 3.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 13 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 83 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 15 84 7.1. Initial version . . . . . . . . . . . . . . . . . . . . . 15 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 8.2. Informative References . . . . . . . . . . . . . . . . . 15 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Overview 92 DNS Service Discovery (DNS-SD) defines the common framework for 93 applications to announce and discover services. This includes 94 service names, service instance names, common parameters for 95 selecting a service instance (weight, priority) as well as service 96 specific parameters. 98 GRASP is intended to also be used for service discovery. Reinventing 99 service discovery for GRASP with a similar set of fetures would 100 result in duplication of work. Therefore, this document defines how 101 to use GRASP to announce and discover services in a way that inherits 102 DNS-SD features and also tries to be compatible in spirit as much as 103 possibel while still maintaining the intended simplicity of GRASP. 105 The goal of this document is to permit defining service and their 106 parameters once and then use that in GRASP, mDNS and (unicast) DNS. 107 Future work can also define DNS-SD <-> GRASP gateway functions. 109 GRASP exists as so-called GRASP-Domains, which are networks across 110 which GRASP is run. This document primarily defines how to perform 111 service discovery across such a domain leveraging GRASPs options to 112 perform unsolicited flooding of announcements or flooding of requests 113 and finding the closest service instances. The initial use case of 114 this document is to support what in DNS-SD is done via mDNS but in 115 larger networks - GRASP-Domains. Beside the efficient flooding, 116 GRASP provides reliability and security (depending on the so called 117 substrate used by GRASP, such as the autonomic control plane - ACP). 118 Providing compatibility with existing mDNS service announcer or 119 clients is possible, but not described in this version of the 120 document. 122 The encoding of information choosen in this document does not try to 123 use GRASP solely as a transport layer, but to also leverage the CBOR 124 structure of GRASP messages to natively encode the message elements 125 required for services in a way that is most simple - instead of using 126 GRASP only as e.g.: an encapsulation of otherwise unchanged DNS 127 message encodings. This is done to minimize the amount of coding 128 required (and not require any DNS code unless future gateway 129 functions are requireed), to increase the simplicity, minimize the 130 amount of data on the wire and allow easier extensibility. On the 131 downside, the mechanisms provided here do not cover the whole slew of 132 possible options of DNS/DNS-SD, but instead only those deemed to be 133 required. Others can be added later. 135 In support of service discovery, this document also defines name 136 discovery and schemes for reuseable elements in GRASP objectives 137 which are designed to be extensible so that future work that 138 identifies elements required across multiple objectives do not need 139 to define a scheme how to do this. 141 2. Specification (Normative) 142 2.1. Service and Name Objectives 144 Unsolicited, flooded announcements (M_FLOOD) in GRASP and solicited 145 flooded discovery (M_DISCOVERY) operate on the unit of GRASP 146 objective-names. Therefore a scheme is required to indicate services 147 via objective-names. Note: future work may wants to reuse the 148 encodings related to services (defined below in this document) inside 149 other (multicast or unicast only) objective exchanges, in which case 150 the service names are not impacted. 152 When an objective is meant to be solely about a service name as 153 defined and registered according to RFC6335, the objective MUST uses 154 an objective-name of SRV.. This naming scheme allows 155 to avoid creating duplicate and potentially inconsistent registration 156 of names for those objectives vs. registrations done for example for 157 DNS-SD. The primary use case for this naming scheme are therefore 158 service names that are intended to be used in both DNS-SD and GRASP. 160 When an objective is meant announcement and discovery of a DNS 161 compatible such as "www-internal" in "www- 162 internal.example.com", the objective SHOULD use an objective-name of 163 NAME.. See Section 2.3.3for more details. 165 See Section 5 for the detailled IANA asks relating to these 166 definitions. 168 2.2. Objective Value Reuseable Elements Structure 170 Because service discovery, as explained in the prior section, needs 171 to utilize different objectives, it requires cross-objective 172 standardized encoding of the elements of services. GRASP did not 173 define standardized message elements for the message body (called 174 "objective-value") of GRASP messages. Therefore, this document 175 introduces such a feature. 177 [RFC-editor: please remove all occurances of XXXX in rfcXXXX with the 178 RFC number assigned to this document and remove this edit note.] 180 objective-value /= { 1*elements } 181 elements //= ( @rfcXXXX: { 1*relement } ) 183 relement = ( relement-codepoint => relement-value ) 184 relement-codepoint = uint 185 relement-value = any 186 If an objective wants to use reuseable elements, the objective-value 187 MUST be a CBOR map and the reuseable elements are found under the key 188 "@rfcXXXX". Objectives that do not want reuseable elements as 189 defined here can use any objective-value format including a CBOR map, 190 but they can not use the "@rfcXXXX" key if they use a map. This 191 approach was choosen as the hopefully least intrusive mechanism given 192 how by nature all of "objective-value" is meant to be defined by 193 individual objective definitions. 195 The value of "@rfcXXXX" is a map of reuseable elements. Each 196 relement has an IANA registered element-name and codepoint (see 197 Section 5). The element-name is for documentation purposes only, 198 CBOR encodings only use the numeric codepoint for encoding efficiency 199 to minimize the risk for this solution to not be applicable to low- 200 bitrate neworks such as in IoT. 202 Format and semantic of the relement-value is determined by the 203 specification of the reuseable element as is the fact whether more 204 than one instances of the same reuseable element are permitted. 206 Reuseable elements SHOULD be defined to be extensible. The methods 207 used depend on the complexity of the element and the likely need to 208 extend/modify the element with backward or non-backward compatible 209 information. The following is a set of initial options to choose 210 from: 212 Element values that are a map MUST permit and reserve key value 0 213 (numerical) for private extensions of the element defined by the 214 individual objective. 216 Element values that are a map MUST NOT use bareword key values 217 starting with a "_". These too are for private extensions defined by 218 the individual objective. 220 Element values SHOULD be defined so that additional keys in maps and 221 additional elements at the end of arrays can be ignored by prior 222 versions of the definition. Whenever a newer definition is made for 223 an element where this rule is violated, the element SHOULD be changed 224 in a way for older version recipients to recognize that it is not 225 compatible with it. 227 One method to indicate compatibility is a traditional version 228 ".". Within the same version number, 229 increasing version numbers must be backward compatible. 230 Different version numbers are not expected to be compatible 231 with each other. If they are, then this can be indicated by 232 including multiple version numbers. 234 A compressed form of version compatibility information is the use of 235 a simple bitmask element where each bit indicates a version that the 236 represented data is compatible with. 238 2.3. Reuseable Elements 240 2.3.1. Sender Loop Count 242 relement-codepoint //= ( &(sender-loop-count:1) => 1..255 ) 244 Sender-loop-count is set by the sender of an objective message to the 245 same value as the loop-count of the message. On receipt, distance = 246 ( sender-loop-count - loop-count ) is the distance of the sender from 247 the receiver in hops. This element can be used for informational 248 purposes in M_FLOOD and M_DISCOVERY messages and may be required to 249 be used in these messages by the specification of other elements 250 (such as the service element described below). This element MUST 251 occur at most once. If a receiver expects to use the distance but 252 sender-loop-count was not announced, then distance SHOULD be assumed 253 to be 255 by the receiver. 255 2.3.2. Service Element 257 The srv-element (service element) is a reuseable element to request 258 or announce a service instance or to request and list service 259 instance names. 261 relement-codepoint //= ( &(srv-element:2) => context-element ) 263 context-element = { 264 ?( &(private:0) => any), 265 ?( &(msg-type:1 => msg-type), 266 ?( &(service:2) => tstr), 267 *( &(instance:3) => tstr), 268 ?( &(domain:4) => tstr), 269 ?( &(priority:5) => 0..65535 ), 270 ?( &(weight:6) => 0..65535 ), 271 *( &(kvpairs:7) => { *(tstr: any) }, 272 ?( &(range:8) => 0..255 ), 273 *( &(clocator:9) => clocator), 274 } 275 clocator = [ context, locator-option ] 276 context = cstr 277 locator-option = ; from GRASP 279 msg-type = &( describe: 0, describe-request:1, 280 enumerate:2, enumerate-request:3 ) 282 Service: A service name registered according to RFC6335. If it is 283 not present, then objective-name MUST be SRV. where 284 is the service-name. 286 Instance: The of a DNS-SD Service Instance Name ( 287 . . ). It is optional, see 288 Section 3.2. 290 Domain: The equivalent of the field of a DNS-SD Service 291 Instance Name. If domain is not present, this is equivalent to 292 ".local" in DNS (as introduced by mDNS) and implies the unnamed 293 "local" domain, which is the GRASP domain across which the message 294 is transmitted. 296 Priority, Weight: Service Instance selection criteria as defined in 297 RFC2782. If either one is not present, its value defaults to 0. 299 Kvpairs: Map of key/value pairs that are service parameters in the 300 same format as the key/value pairs in TXT field(s) of DNS-SD TXT 301 records as defined in RFC6763, section 6.3. 303 Range: Allows to flexibly combine distance and priority/weight based 304 service selection according to the definition of distance in 305 Section 2.3.1. 307 If min-distance is the distance of the closest service announcer, 308 and min-range the range announced by it, then the recipient MUST 309 consider the priority/weight of all service announcers that are 310 not further away than (min-distance + min-range). If not 311 included, range defaults to 255. 313 If range is announced, the sender-loop-count element MUST also be 314 announced. 316 Clocator: The "contextual locator" allows to indicate zero or more 317 locators for the indicated service instance. The context element 318 indicates in which context the locator-option is to be resolved. 319 The reserved context value of "" (empty string) indicates the 320 GRASP domain used, aka: the "local" context in which the service 321 announcement is made. The reserved context value of "0" indicates 322 the default routing context of the announcing node. This is often 323 called "global table", "VRF 0" or "default VRF" on nodes using the 324 "VRF" abtraction. Any other value is a string specifying a 325 context such as another VRF. 327 The mechanism by which originator and recipient of the srv-element 328 agree on common naming for contexts is outside the scope of this 329 specification. The context therefore allows to indicate locators 330 both for the context through which the GRASP message distributed 331 the srv-element (GRASP domain) as well as that for other contexts. 332 Assume the GRASP domain is the ACP, then clocators in ACP would 333 have a context of "", clocators in the global routing table (part 334 of the data-plane) a context of "0", and clocators on other VRFs 335 (also part of data-plane) a clocator that is their sring name. 337 If no locators are indicated, then the locator of the service(s) 338 is the optional locator-option of the GRASP message in which the 339 objective is contained meant to be used for the service(s) 340 indicated and the clocator implied is "". 342 If locator(s) are indicated, the messages location-option must be 343 ignored for the service (but may be necessary to be present for 344 other purposes of the objective). 346 Msg-type Type (aka: intention) of the srv-element. If not present, 347 it is assumed to be "describe". 349 Describe: Describes one service instance. At least one clocator is 350 required for a positive response, all other fields are permitted, 351 but optional. "Describe" is used in M_FLOOD for unsolicited 352 announcements of services (flooded), in M_RESPONSE messages for 353 solicited announcements of a service and in M_NEGOTIATE for 354 negotiated announcements (both unicasted). If clocator is not 355 included, then all fields except service and instance (and msg- 356 type and private) must not be included and the srv-element 357 provides a negative reply: No information about this service/ 358 service instance. This is only permitted in unicasted "describe" 359 messages. 361 Describe-request: Request for a "describe" reply. It is used in 362 M_DISCOVERY (flooded) for solicited discovery of services or in 363 M_REQ_SYN (unicasted) for negotiated discovery of service 364 instance(s). In "describe-request", only service is mandatory 365 (but can be provided via the objective-name field of the message), 366 and domain is optional. "Instance" is optional. If provided, 367 then the recipient is asked to provide information about the named 368 instance only. All other fields of srv-element are to be ignored 369 by the receiver in this specification, but a semantic for setting 370 them may be introduced in followup work, specifically to filter 371 replies by the indiciated fields. 373 "Describe-request" without instance MAY be answered by "Enumerate" 374 (see below) if the responder has so many instances that it thinks 375 the initiator should rather first select one or fewer instances 376 and ask for their description. The sender of te "Describe- 377 request" MUST be prepared to accept that answer and as necessary 378 follow up with "Describe-request" with the instance names of 379 interest. 381 Enumerate: Used in the same GRASP messages as "describe", but 382 instead of providing information about one service instance, it is 383 listing service instance names. The purpose of enumerate is the 384 same as browsing a service in DNS-SD. It would be followed by 385 some human or automated selection of one or more instances and 386 then a "describe" M_REQ_SYN request for those instances sent to 387 the source of the "enumerate" to learn about the locators and 388 other parameters of the service instances. 390 In this specification, all fields other than service, instance and 391 domain (and msg-type and private) must be unset in "enumerate". 393 Enumerate-request: Requests an "enumerate" reply. It is used in the 394 same way as "Describe-request" except that instance would usually 395 not be set (because in that case it is more useful to send a 396 "Describe-request"). 398 2.3.3. Name Element 400 The NAME, elements is meant to provide basic name resolution 401 comparable to mDNS name resolution for GRASP domains where this is 402 desirable and no better name resolution exist - for example in the 403 ACP where there is no requirement for DNS. 405 Because the GRASP service lookup (unlike) DNS does not mandate that 406 nodes have names (not even service instance names), the use of names 407 is primarily meant to support legacy software. New designs should 408 instead look up only services and service instance names, and nodes 409 should announce their names as service instance names for the 410 services they offer: 412 For example consider a GRASP (ACP) domain of "example.com". The node 413 providing some "www" service could have a name "www-internal" which 414 means GRASP objective NAME.www-internal, that objective value would 415 include primarily the nodes IP address(es) and the port number for 416 the www service would have to be guessed (80). Better, the node 417 would announce GRASP objective SRV.www and the objective value would 418 include the service instance name www-internal and the (TCP) port 419 information (80 or a non-default port). 421 relement-codepoint //= ( &(name-element:3) => context-element ) 423 context-element //= { 424 *( &name:10) => tstr), 425 } 427 ipv6-address-option = [O_IPv4_ADDRESS, ipv6-address] 428 ipv4-address-option = [O_IPv6_ADDRESS, ipv6-address] 429 locator-option /= ipv4-address-option 430 locator-option /= ipv6-address-option 432 Name information is carried in the name-element relement. It is a 433 context-element like the one used for srv-element except that it adds 434 the name component and that it does not permit the service and 435 instance components and that it allows only describe and describe- 436 request values in the msg-type. Clocators MUST use the ipv6-address- 437 option or ipv4-address-option in the locator-option component. 439 TBD: Unclear if/how we should best formalize the differences in the 440 context element permitted information between services and names. 441 The above is quite informal. 443 Priority, weight, kvpairs, range (and of course private) MAY be used 444 in describe messages to support multiple instances of the same name, 445 as used for name anycast/prioritycast. 447 Nodes may have multiple names. These can be listed in the name 448 component. If a nodes names have the notion of a primary name and 449 secondary names then the primary name should be the first in the list 450 of names. In DNS-SD, the name pointed to by CNAME RRs can be 451 considered to be the primary name. A describe-request for a non- 452 primary name SHOULD return in the list of names the requested name 453 and the primary name. 455 Note that there is no reverse lookup defined in this version of the 456 document (no lookup from IP address to name). 458 3. Explanations (Informative) 460 3.1. Using GRASP service announcements 462 TBD: This section contains a range of details that should become 463 normative in later versions. 465 This section provides a step by step walk-through of how to use GRASP 466 service announcements and compares it to DNS-SD. 468 The most simple method to use GRASP service discovery is to select 469 (and if still neessary, register) a and start one or 470 more agents (e.g.: ASAs) announcing their service instance(s) via 471 GRASP. At minimum, an agent should periodically (default 60 seconds) 472 announce the service instance via GRASP M_FLOOD messages as an 473 objective SRV. with a srv-element and a sender-loop- 474 count element (default 255). The ttl of the GRASP message should be 475 3.5 times the announcement period, e.g.: 210000 msec. 477 Consumers of the service will use GRASP to learn of the service 478 instances and select one. This approach is most similar to the use 479 of DNS-SD with mDNS except that the scope of the announcement is a 480 whole GRASP domain (such as the ACP) as opposed to a single IP subnet 481 in mDNS and that mDNS primarily relies on request & reply but in its 482 standard not on periodic unsolicited announcements. We describe here 483 the unsolicited flooding option via M_FLOOD first because it is 484 recommended for services with a dense population of service consumers 485 and it is most simple to describe. 487 On the service announcer, the parameters priority, weight and range 488 of the service instance can be selected from intent or configuration 489 - or left at default. The default range 255 will result in selection 490 of a random target of the service like in DNS-SD. Setting priority/ 491 weight allows to prioritize and weigh the selection as in DNS-SD. 492 Setting range to 0 allows to select the closest target, priority/ 493 weight are only compared between targets of the same shortest 494 distance. Distance based options are not available in DNS-SD because 495 it does not expect that network distance is available to arbitrary 496 DNS-SD client. It is available to GRASP clients though. Using 0 < 497 range < 255 allows for a hybrid priority/weight and distance based 498 service selection (e.g.: Select the highest priority instance within 499 a range of 5 hops). 501 If the service is a non-GRASP service, then the result of the service 502 discovery has to be a transport locator to which the client can open 503 a connection and talk the protocol implied by the service. This 504 transport locator(s) have to be put into the clocator parameter. The 505 context of the clocator would normally be "", aka: the transport 506 locator is in the IP reachability associated with the GRASP domain 507 (e.g.: IPv6 of the ACP for ACP GRASP domain). 509 If an ACP service is announced via ACP GRASP, then the locator(s) can 510 be O_IPv6_LOCATOR or O_FQDN_LOCATOR. The O_IPv6_LOCATOR is used if 511 the service is defined to be available via some transport layer port 512 (TCP, UDP or other). The determination of the actual transport 513 connection to be used is the same as in DNS-SD: If the transport 514 protocol is not TCP or UDP, it has to be implied by the specification 515 of or can be detailled in kvpairs which carries the 516 same information as DNS-TXT TXT RRs of the service. Alternatively, 517 the transport-proto field of the locator can contain any valid IP 518 protocol directly (TBD), which is not possible in DNS-SD. 520 Like DNS-SD, service discovery via GRASP does not require allocation 521 and use of well-known ports for services. Unlike DNS-SD, there is no 522 need in GRASP to define service instance names or target names. In 523 DNS SD, PTR RRs resolve from a service name to a set of service 524 instance named. SRV and TXT RRs resolve from service instance names 525 to service instance parameters including the target. A target is the 526 DNS host name of the service instance. It gets resolved via A/AAAA 527 RRs to IPv4/IPv6 addresses of the targ. In GRASP service discovery, 528 host names are not used. Service instance names are optional too. 529 Service instance names are useful for human diagnostics and human 530 selection of service instances. In fully automated environments, 531 they can be are less important. For diagnostic purposes, it is 532 recommended to give service instances service instance names in GRASP 533 service announcements. 535 A locator with O_URI_LOCATOR type can be used in GRASP to indicate a 536 URI for the transport method for a service instance. If the URI 537 includes a host part, care must be taken to use only IP addresses in 538 the host part if the context of the GRASP domain does not support 539 host name resolution - such as the ACP - or to use the GRASP name 540 resolution mechanisms described elsewhere in this document. And that 541 the addresses indicated are also reachable in the GRASP domain. For 542 example, in service announcemenets across a DULL GRASP domain, only 543 the IPv6 link-local addresses on that subnet must be used (this 544 applies equally when using the O_IPv6_LOCATOR). 546 Instead of using M_FLOOD to periodically announce service instances, 547 M_DISCOVERY can be used to actively query for service instances. The 548 msg-type type must then be "describe-request". Because no periodic 549 flooding is necessary, this solution is more lightweight for the 550 network when the number of requesting clients is small. Note though 551 that the M_DISCOVERY will terminate as soon as a provider of the 552 objective is found, so the service instances found will be based on 553 distance and therefore selection of instance by priority and weight 554 will not work equally well as with M_FLOOD. Consider for example a 555 central service instance in the NOC that should always be used (for 556 example for centralized operational diagnostics) unless the WAN 557 connection is broken, in which case distributed backup service 558 instances should be used. With the current logic of M_DISCOVERY this 559 is not possible. 561 3.2. Further comparison with DNS-SD 563 Neither the GRASP SRV.* objective-name, the service name nor any 564 other parameter explicitly indicate the second label "_tcp" or "_udp" 565 of DNS-SD entries. DNS-SD, RFC6763 explains how this is an 566 unnecessary, historic artefact. 568 This version of the document does not define an equivalent to "_sub" 569 structuring of service enumeration. 571 This version of the document does not define mechanisms for reverse 572 resolution of arbitrary services: An inquirer may unicast M_SYNC_REC 573 to a node with a series of objectives with specific service names of 574 interest and describe-request, but there is no indication of "ANY" 575 service. 577 3.3. Open Issues 579 TBD: Examine limitations mentioned in "in this version of the text/ 580 document". 582 TBD: The GRASP specification does currently only permit TCP and UDP 583 for the transport-proto element. This draft should expand the GRASP 584 definitions to permit any valid IP protocol. We just need to decide 585 whether this should only apply to the locator in the srv element or 586 also retroative to the locator-option in GRASP messages (maybe not 587 there ?). 589 TBD: A fitting CBOR representation for a kvpair key without value 590 needs to be specified so that it can be distinguished from an empty 591 value as outlined in RFC6763 section 6.4. 593 TBD: In this version, every service/service-instance is an element by 594 itself. Future versions of this document may add more encoding 595 options to allow more compact encoding of recurring fields. 597 TBD: Is there a way in CDDL to formally define the string names of 598 the relement-codepoint's ? 600 4. Security Considerations 602 TBD. 604 5. IANA Considerations 606 This document requests a new "GRASP Objective Value Standard 607 Elements" table in the GRASP Parameter Registrar. The values in this 608 table are names and a unique numerical value assigned to each name. 609 Future values MUST be assigned using the RFC Required policy defined 610 by [RFC8126]. The numerical value is simply to be assigned 611 sequentially. The following initial values are assigned by this 612 document: 614 sender-loop-count 1 [defined in rfcXXXX] 616 srv-element 2 [defined in rfcXXXX] 618 name-element 3 [defined in rfcXXXX] 620 This document updates the handling of the "GRASP Objective Names" 621 Table introduced in the GRASP IANA considerations as follows: 623 Assignments for objective-names of the form "SRV." and 624 "NAME." are special. 626 Assignment of "SRV." can only be requested if is also a 627 registered service-name according to RFC6335. The specification 628 required for registration of a "GRASP Objective Name" MUST declare 629 that the intended use of the objective name in GRASP is intended to 630 be compatible with the indended use of the registered service name. 632 Registration of "SRV." in the "GRASP Objective Name" table is 633 optional, but recommended for all new service-names that are meant to 634 be used with GRASP. Non-registration can for example happen with 635 DNS-SD <-> GRASP gateways that inject pre-existing service-names into 636 GRASP. Note that according to the GRASP RFC, registration is 637 mandatory, so this exemption for "SRV." is also an update to 638 that specification. 640 There MUST NOT be any assignment for objective names of the form 641 "NAME.". These names are simply used by GRASP nodes without 642 registration (just like names in mDNS). 644 6. Acknowledgements 646 7. Change log [RFC Editor: Please remove] 648 7.1. Initial version 650 8. References 652 8.1. Normative References 654 [I-D.ietf-anima-grasp] 655 Bormann, C., Carpenter, B., and B. Liu, "A Generic 656 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 657 grasp-15 (work in progress), July 2017. 659 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 660 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 661 . 663 8.2. Informative References 665 [I-D.ietf-anima-autonomic-control-plane] 666 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 667 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 668 plane-12 (work in progress), October 2017. 670 Author's Address 672 Toerless Eckert 673 Futurewei Technologies Inc. 674 2330 Central Expy 675 Santa Clara 95050 676 USA 678 Email: tte+ietf@cs.fau.de