idnits 2.17.00 (12 Aug 2021) /tmp/idnits12570/draft-wu-pce-dns-pce-discovery-10.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 567 has weird spacing: '...service rege...' -- The document date (March 28, 2017) is 1873 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'PCE-QUESTION' is mentioned on line 199, but not defined == Unused Reference: 'RFC2385' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC7399' is defined on line 830, but no explicit reference was found in the text == Outdated reference: draft-ietf-idr-ls-distribution has been published as RFC 7752 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) == Outdated reference: draft-ietf-pce-stateful-pce has been published as RFC 8231 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Wu 3 Internet-Draft D. Dhody 4 Intended status: Experimental Huawei 5 Expires: September 29, 2017 D. King 6 Lancaster University 7 D. Lopez 8 Telefonica I+D 9 J. Tantsura 10 March 28, 2017 12 Path Computation Element (PCE) Discovery using Domain Name System(DNS) 13 draft-wu-pce-dns-pce-discovery-10 15 Abstract 17 Discovery of the Path Computation Element (PCE) within an IGP area or 18 routing domain is possible using OSPF and IS-IS IGP discovery. 19 However, it has been established that in certain deployment scenarios 20 PCEs may not wish, or be able to participate within the IGP process. 21 In those scenarios, it is beneficial for the Path Computation Client 22 (PCC) (or other PCE) to discover PCEs via an alternative mechanism to 23 using an IGP discovery. 25 This document specifies the requirements, use cases, procedures and 26 extensions to support PCE discovery along with certain relevant 27 information type and capability discovery via DNS. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 29, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions used in this document . . . . . . . . . . . . . . 4 67 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Outside the Routing Domain . . . . . . . . . . . . . . . 4 69 3.2. Discovery Mechanisms . . . . . . . . . . . . . . . . . . 5 70 3.2.1. Query-Response versus Advertisement . . . . . . . . . 5 71 3.3. PCE Virtualization . . . . . . . . . . . . . . . . . . . 6 72 3.4. Additional Capabilities . . . . . . . . . . . . . . . . . 6 73 3.4.1. Handling Changes in PCE Identities . . . . . . . . . 6 74 3.4.2. Secure Inter-domain Discovery . . . . . . . . . . . . 6 75 3.4.3. Load Sharing of Path Computation Requests . . . . . . 6 76 4. Extended Naming Authority Pointer ( NAPTR )Service Field 77 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 4.1. IETF Standards Track PCE Applications . . . . . . . . . . 8 79 5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 8 80 6. Discovering a Path Computation Element . . . . . . . . . . . 9 81 6.1. Determining the PCE Service and transport protocol . . . 10 82 6.2. Determining the IP Address of the PCE . . . . . . . . . . 10 83 6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 12 84 6.3. Determining the PCE domains and Neighbor PCE domains . . 13 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 7.1. IETF PCE Application Service Tags . . . . . . . . . . . . 14 87 7.2. PCE Application Protocol Tags . . . . . . . . . . . . . . 14 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 10.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 95 1. Introduction 97 The Path Computation Element Communication Protocol (PCEP) is a 98 transaction-based protocol carried over TCP [RFC4655]. In order to 99 be able to direct path computation requests to the Path Computation 100 Element (PCE), a Path Computation Client (PCC) (or other PCE) needs 101 to know the location and capability of a PCE. 103 In a network where an IGP is used and where the PCE participates in 104 the IGP, discovery mechanisms exist for PCC (or PCE) to learn the 105 identity and capability of each PCE. [RFC5088] defines a PCE 106 Discovery (PCED) TLV carried in an OSPF Router LSA. Similarly, 107 [RFC5089] defines the PCED sub-TLV for use in PCE Discovery using IS- 108 IS. Scope of the advertisement is limited to IGP area/level or 109 Autonomous System (AS). 111 However in certain scenarios not all PCEs will participate in the 112 same IGP instance, section 3 (Motivation) outlines a number of use 113 cases. In these cases, current PCE Discovery mechanisms are 114 therefore not appropriate and another PCE discovery function would be 115 required. (sec 4 of [PCE-QUESTION]). 117 This document describes PCE discovery via DNS. The mechanism with 118 which DNS comes to know about the PCE and its capability is out of 119 scope of this document. 121 1.1. Terminology 123 The following terminology is used in this document. 125 PCE-Domain: As per [RFC4655], any collection of network elements 126 within a common sphere of address management or path computational 127 responsibility. Examples of domains include Interior Gateway 128 Protocol (IGP) areas and Autonomous Systems (ASs). 130 Domain-Name: An identification string that defines a realm of 131 administrative autonomy, authority, or control on the Internet. 132 Any name registered in the DNS is a domain name. DNS Domain names 133 are used in various networking contexts and application-specific 134 naming and addressing purposes. In general, a domain name 135 represents an Internet Protocol (IP) resource. Examples of DNS 136 domain name is "www.example.com" or "example.com" [RFC1035]. 138 1.2. Requirements 140 As described in [RFC4674], the PCE Discovery information should at 141 least be composed of: 143 o The PCE location: an IPv4 and/or IPv6 address that is used to 144 reach the PCE. It is RECOMMENDED to use an address that is always 145 reachable if there is any connectivity to the PCE; 147 o The PCE path computation scope (i.e., inter-area, inter-AS, or 148 inter-layer); 150 o The set of one or more PCE-Domain(s) into which the PCE has 151 visibility and for which the PCE can compute paths; 153 o The set of zero, one, or more neighbor PCE-Domain(s) toward which 154 the PCE can compute paths; 156 o The set of communication and path computation-specific 157 capabilities. 159 These PCE discovery information allows PCCs to select appropriate 160 PCEs. 162 This document specifies the procedures and extension to facilitate 163 DNS-based PCE information discovery for specific use cases, and to 164 complement existing IGP discovery mechanism. 166 2. Conventions used in this document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC2119 [RFC2119]. 172 3. Motivation 174 This section discusses in more detail the motivation and use cases 175 for an alternative DNS-based PCE discovery mechanism. 177 3.1. Outside the Routing Domain 179 When the PCE is a router participating in the IGP, or even a server 180 participating passively in the IGP, with all PCEP speakers in the 181 same routing domain, a simple and efficient way to announce PCEs 182 consists of using IGP flooding. 184 It has been identified that the existing PCE discovery mechanisms do 185 not work very well in following scenarios: 187 Inter-AS: Per domain path computation mechanism [RFC5152] or 188 Backward recursive path computation (BRPC) [RFC5441] MAY be used 189 by cooperating PCEs to compute inter-domain path. In which case 190 these cooperating PCEs should be known to other PCEs. In case of 191 inter-AS where the PCEs do not participate in a common IGP, the 192 existing IGP discovery mechanism cannot be used to discover inter- 193 AS PCE. 195 Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require 196 disclosure of internals of a child domain to the parent PCE. It 197 may be necessary for a third party to manage the parent PCEs 198 according to commercial and policy agreements from each of the 199 participating service providers [PCE-QUESTION]. [RFC6805] 200 specifies that a child PCE must be configured with the address of 201 its parent PCE in order for it to interact with its parent PCE. 202 However handling changes in parent PCE identities and coping with 203 failure events would be an issue for a configured system. There 204 is no scope for parent PCEs to advertise their presence to child 205 PCEs when they are not a part of the same routing domain. 207 BGP-LS: [BGP-LS] describes a mechanism by which links state and 208 traffic engineering information can be collected from networks and 209 shared with external components using the BGP routing protocol. 210 An external PCE MAY use this mechanism to populate its TED and not 211 take part in the same IGP routing domain. 213 NMS/OSS: PCE MAY gain the knowledge of Topology information from 214 some management system (e.g.,NMS/OSS) and not take part in the 215 same routing domain. Also note that in some case PCC may not be a 216 router and instead be a management system like NMS and may not be 217 able to discover PCE via IGP discovery. 219 3.2. Discovery Mechanisms 221 3.2.1. Query-Response versus Advertisement 223 Advertisement based PCE discovery using IGP methods [RFC5088] and 224 [RFC5089] floods the PCE information to an area, a subset of areas or 225 to a full routing domain. By the very nature of flooding and 226 advertisements it generates unwanted traffic and may lead to 227 unnecessary advertisement, especially when PCE information needs 228 frequent changes. 230 DNS is a query-response based mechanism, a client (a PCC) can use DNS 231 to discover a PCE only when it needs to compute a path and does not 232 require any other node in the network to be involved. 234 In case of Intermittent PCEP session, where PCEP sessions are 235 systematically open and closed for each PCEP request, a DNS-based 236 query-response mechanism is more suitable. One may also utilize DNS- 237 based load-balancing and recovery functions. 239 3.3. PCE Virtualization 241 Server virtualization has gain importance since it provides better 242 reliability and high availability in the event of hardware failure. 243 It allows for higher utilization of physical resources while 244 improving administration by having a single management interface for 245 all virtual servers. 247 When one PCE instance is virtually hosted on a server and initiated 248 as a PCE instance, another PCE instance may be created on the same 249 server or a different server to provide better load balancing and 250 reliability. In such a case, where there are a large number of PCCs 251 that need to know these PCE instances' location, manual configuration 252 on PCCs for PCC and PCE relationship is not trivial or desirable. 254 3.4. Additional Capabilities 256 3.4.1. Handling Changes in PCE Identities 258 In the case of H-PCE ,when a dynamic Address is assigned to the 259 parent PCE, any existing configuration entry on child PCE becomes 260 invalid and the parent PCE becomes unreachable. In order to handle 261 changes in parent PCE identities, the DNS update can be used to 262 provide IP reachability to the parent PCE with new assigned Address. 263 The DNS update can be performed by either parent PCE or OSS/NMS that 264 is aware of PCE Identities changes. 266 3.4.2. Secure Inter-domain Discovery 268 Applications make use of DNS lookups on FQDN to find a node(e.g., 269 PCEP endpoint). When a PCE performs DNS lookup or dynamic DNS update 270 with the DNS server, the PCE MUST have a security association of some 271 type with the DNS server. The security association SHOULD be 272 established either using DNSSEC [RFC4033] or TSIG/ 273 TKEY[RFC2845][RFC2930]. DNS lookup for PCE Discovery can be applied 274 either within an administration domain or spanning across 275 administration domains. A security association is REQUIRED even if 276 the DNS server is in the same administrative domain as the PCE. 278 3.4.3. Load Sharing of Path Computation Requests 280 Multiple PCEs can be present in a single network domain for 281 redundancy. DNS supports inherent load balancing where multiple PCEs 282 (with different IP addresses) are known in DNS for a single PCE 283 server name and are hidden from the PCC. 285 In an IGP advertisement based PCE discovery, one learns of all the 286 PCEs and it is the job of the PCC to do load-balancing. 288 A DNS-based load-balancing mechanism works well in case of 289 Intermittent PCEP sessions and request are load-balanced among PCEs 290 similar to HTTP request without any complexity at the client. 292 4. Extended Naming Authority Pointer ( NAPTR )Service Field Format 294 The NAPTR service field format defined by the S-NAPTR DDDS 295 application in [RFC3958] follows this Augmented Backus-Naur Form 296 (ABNF) [RFC5234]: 298 service-parms = [ [app-service] *(":" app-protocol)] 299 app-service = experimental-service / iana-registered-service 300 app-protocol = experimental-protocol / iana-registered-protocol 301 experimental-service = "x-" 1*30ALPHANUMSYM 302 experimental-protocol = "x-" 1*30ALPHANUMSYM 303 iana-registered-service = ALPHA *31ALPHANUMSYM 304 iana-registered-protocol = ALPHA *31ALPHANUMSYM 305 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 306 DIGIT = %x30-39 ; 0-9 307 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 308 ALPHANUMSYM = ALPHA / DIGIT / SYM 309 ; The app-service and app-protocol tags are limited to 32 310 ; characters and must start with an alphabetic character. 311 ; The service-parms are considered case-insensitive. 313 This specification refines the "iana-registered-service" tag 314 definition for the discovery of PCE supporting a specific PCE 315 application or multiple PCE applications as defined below. 317 iana-registered-service =/ pce-service 318 pce-service = "pce" *("+" appln-name) 319 appln-name = non-ws-string 320 non-ws-string = 1*(%x21-FF) 322 The appln-name element is the Application Identifier used to identify 323 a specific PCE application. The PCE Application Name are allocated 324 by IANA as defined in section 8.1. 326 This specification also refines the "iana-registered-protocol" tag 327 definition for the discovery of PCE supporting a specific transport 328 protocol as defined below. 330 iana-registered-protocol =/ pce-protocol 331 pce-protocol = "pce." pce-transport 332 pce-transport = "tcp" / "tls.tcp" 334 Similar to application protocol tags defined in the [RFC6408],the 335 S-NAPTR application protocol tags defined by this specification MUST 336 NOT be parsed in any way by the querying application or Resolver. 337 The delimiter (".") is present in the tag to improve readability and 338 does not imply a structure or namespace of any kind. The choice of 339 delimiter (".") for the application protocol tag follows the format 340 of existing S-NAPTR application protocol tag registry entries, but 341 this does not imply that it shares semantics with any other 342 specifications that create registry entries with the same format. 344 The S-NAPTR application service and application protocol tags defined 345 by this specification are unrelated to the IANA "Service Name and 346 Transport Protocol Port Number Registry" (see [RFC6335]). 348 The maximum length of the NAPTR service field is 256 octets, 349 including a one-octet length field (see Section 4.1 of [RFC3403] and 350 Section 3.3 of [RFC1035]). 352 4.1. IETF Standards Track PCE Applications 354 A PCE Client MUST be capable of using the extended S-NAPTR 355 application service tag for dynamic discovery of a PCE supporting 356 Standards Track applications. Therefore, every IETF Standards Track 357 PCE application MUST be associated with a "PCE-service" tag formatted 358 as defined in this specification and allocated in accordance with 359 IANA policy (see Section 8). 361 For example, a NAPTR service field value of: 363 'PCE+gco:pce.tcp' 365 means that the PCE in the SRV or A/AAAA record supports the Global 366 Concurrent Optimization Application (See section 8.1)and the 367 Transport Control Protocol (TCP) as the transport protocol (See 368 section 8.2). 370 5. Backwards Compatibility 372 Domain Name System (DNS) administrators SHOULD also provision legacy 373 NAPTR records [RFC3403] in order to guarantee backwards compatibility 374 with legacy PCE that only support S-NAPTR DDDS application in 375 [RFC3958]. If the DNS administrator provisions both extended S-NAPTR 376 records as defined in this specification and legacy NAPTR records 377 defined in [RFC3403], then the extended S-NAPTR records MUST have 378 higher priority(e.g., lower order and/or preference values) than 379 legacy NAPTR records. 381 6. Discovering a Path Computation Element 383 The extended-format NAPTR records provide a mapping from a domain to 384 the SRV record or A/AAAA record for contacting a server supporting a 385 specific transport protocol and PCE application. The resource record 386 will contain an empty regular expression and a replacement value, 387 which is the SRV record or the A/AAAA record for that particular 388 transport protocol. 390 The assumption for this mechanism to work is that the DNS 391 administrator of the queried domain has first provisioned the DNS 392 with extended-format NAPTR entries. 394 When the PCC or other PCEs performs a NAPTR query for a server in a 395 particular realm, the PCC or other PCEs has to know in advance the 396 search path of the resolver, i.e.,in which realm to look for a PCE, 397 and in which Application Identifier it is interested. 399 The search path of the resolver can either be pre-configured, or 400 discovered using Diameter, DHCP or other means. For example, the 401 realm could be deduced from the Network Access Identifier (NAI) in 402 the User-Name attribute-value pair (AVP) or extracted from the 403 Destination-Realm AVP in Diameter [RFC6733]. 405 When pre-configuration is used, PCE domain(e.g.,AS200)may be added as 406 "subdomains" of the first-level domain of the underlying service 407 (e.g., AS200.example.com), which allows a NAPTR query for a server in 408 a PCE domain associated with DNS domain-name. 410 When DHCP is used, it SHOULD know the domain-name of that realm and 411 use DHCP to discover IP address of the PCE in that realm that 412 provides path computation service along with some PCE location 413 information useful to a PCC (or other PCE) for a PCE selection, and 414 contact it directly. In some instances, the discovery may result in 415 a per protocol/application list of domain-names that are then used as 416 starting points for the subsequent S-NAPTR lookups [RFC3958]. If 417 neither the IP address nor other PCE location information can be 418 discovered with the above procedure, the PCC (or other PCE) MAY 419 request a domain search list, as described in [RFC3397] and[RFC3646], 420 and use it as input to the DDDS application. 422 When the PCC (or other PCE) does not find valid domain-names using 423 the mechanisms above, it MUST stop the attempt to discover any PCE. 425 The following procedures result in an IP address, PCE domain, 426 neighboring PCE domain and PCE Computation Scope where the PCC (or 427 other PCE) can contact the PCE that hosts the service it is looking 428 for. 430 6.1. Determining the PCE Service and transport protocol 432 The PCC (or other PCE) should know the service identifier for the 433 Path Computation service and associated transport protocol. The 434 service identifier for the Path Computation service is defined as 435 "PCE+apX" as specified in section 5, The PCE supporting "PCE" service 436 MUST support TCP as transport, as described in [RFC5440]. 438 The services relevant for the task of transport protocol selection 439 are those with S-NAPTR service fields with values "PCE+apX:Y", where 440 'PCE+apX' is the service identifier defined in the previous 441 paragraph, and ' Y' is the letter that corresponds to a transport 442 protocol supported by the PCE. This document also establishes an 443 IANA registry for mappings of S-NAPTR service name to transport 444 protocol. 446 These NAPTR [RFC3958] records provide a mapping from a domain to the 447 SRV [RFC2782] record for contacting a PCE with the specific transport 448 protocol in the S-NAPTR services field. The resource record MUST 449 contain an empty regular expression and a replacement value, which 450 indicates the domain name where the SRV record for that particular 451 transport protocol can be found. As per [RFC3403], the client 452 discards any records whose services fields are not applicable. 454 The PCC (or other PCE) MUST discard any service fields that identify 455 a resolution service whose value is not valid. The S-NAPTR 456 processing as described in [RFC3403] will result in the discovery of 457 the most preferred PCE that is supported by the client, as well as an 458 SRV record for the PCE. 460 6.2. Determining the IP Address of the PCE 462 If the returned NAPTR service fields contain entries formatted as 463 "pce+apX:Y" where "X" indicates the Application Identifier and "Y" 464 indicates the supported transport protocol(s), the target realm 465 supports the extended format for NAPTR-based PCE discovery defined in 466 this document. 468 o If "X" contains the required Application Identifier and "Y" 469 matches a supported transport protocol, the PCEP implementation 470 resolves the "replacement" field entry to a target host using the 471 lookup method appropriate for the "flags" field. 473 o If "X" does not contain the required Application Identifier or "Y" 474 does not match a supported transport protocol, the PCEP 475 implementation abandons the peer discovery. 477 If the returned NAPTR service fields contain entries formatted as 478 "pce+apX" where "X" indicates the Application Identifier, the target 479 realm supports the extended format for NAPTR-based PCE discovery 480 defined in this document. 482 o If "X" contains the required Application Identifier, the PCEP 483 implementation resolves the "replacement" field entry to a target 484 host using the lookup method appropriate for the "flags" field and 485 attempts to connect using all supported transport protocols. 487 o If "X" does not contain the required Application Identifier, the 488 PCEP implementation abandons the PCE discovery. 490 If the returned NAPTR service fields contain entries formatted as 491 "pce:X" where "X" indicates the supported transport protocol(s), the 492 target realm supports PCEP but does not support the extended format 493 for NAPTR-based PCE discovery defined in this document. 495 o If "X" matches a supported transport protocol, the PCEP 496 implementation resolves the "replacement" field entry to a target 497 host using the lookup method appropriate for the "flags" field. 499 If the returned NAPTR service fields contain entries formatted as 500 "pce", the target realm supports PCEP but does not support the 501 extended format for NAPTR-based PCE discovery defined in this 502 document. The PCEP implementation resolves the "replacement" field 503 entry to a target host using the lookup method appropriate for the 504 "flags" field and attempts to connect using TCP (in future it SHOULD 505 attempt all supported transport Protocols) . 507 Note that the regexp field in the S-NAPTR example above is empty. 508 The regexp field MUST NOT be used when discovering PCE, as its usage 509 can be complex and error prone. Also, the discovery of the PCE does 510 not require the flexibility provided by this field over a static 511 target present in the TARGET field. 513 As the default behavior, the client is configured with the 514 information about which transport protocol is used for a path 515 computation service in a particular domain. The client can directly 516 perform an SRV query for that specific transport using the service 517 identifier of the path computation Service. For example, if the 518 client knows that it should be using TCP for path computation 519 service, it can perform a SRV query directly 520 for_PCE._tcp.example.com. 522 Once the server providing the desired service and the transport 523 protocol has been determined, the next step is to determine the IP 524 address. 526 According to the specification of SRV RRs in [RFC2782], the TARGET 527 field is a fully qualified domain-name (FQDN) that MUST have one or 528 more address records; the FQDN must not be an alias, i.e., there MUST 529 NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query 530 already has reported a sufficient number of these address records in 531 the Additional Data section of the DNS response (as recommended by 532 [RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) 533 of the domain-name, as appropriate. The result will be a list of IP 534 addresses, each of which can be contacted using the transport 535 protocol determined previously. 537 6.2.1. Examples 539 As an example, consider a client that wishes to find PCED service in 540 the as100.example.com domain. The client performs a S-NAPTR query 541 for that domain, and the following NAPTR records are returned: 543 Order Pref Flags Service Regexp Replacement 544 IN NAPTR 50 50 "s" "pce:pce.tls.tcp" "" 545 _PCE._tcp.as100.example.com 546 IN NAPTR 90 50 "s" "pce:pce.tcp" "" 547 _PCE._tcp.as100.example.com 549 This indicates that the domain does have a PCE providing Path 550 Computation services over TCP, in that order of preference. If the 551 client only supports TCP, TCP will be used, targeted to a host 552 determined by an SRV lookup of _PCE._tcp.example.com. That lookup 553 would return: 555 ;; Priority Weight Port Target 556 IN SRV 0 1 XXXX server1.as100.example.com 557 IN SRV 0 2 XXXX server2.as100.example.com 559 where XXXX represents the port number at which the service is 560 reachable. 562 As an alternative example, a client wishes to discover a PCE in the 563 ex2.example.com realm that supports the GCO application over TCP. 564 The client performs a NAPTR query for that domain, and the following 565 NAPTR records are returned: 567 ;; order pref flags service regexp replacement 568 IN NAPTR 150 50 "a" "pce:pce.tcp" "" 569 server1.ex2.example.com 570 IN NAPTR 150 50 "a" "pce:pce.tls.tcp" "" 571 server2.ex2.example.com 572 IN NAPTR 150 50 "a" "pce+gco:pce.tcp" "" 573 server1.ex2.example.com 574 IN NAPTR 150 50 "a" "pce+gco:pce.tls.tcp" "" 575 server2.ex2.example.com 577 This indicates that the server supports GCO(ID=1) over TCP and TLS/ 578 TCP via hosts server1.ex2.example.com and server2.ex2.example.com, 579 respectively. 581 6.3. Determining the PCE domains and Neighbor PCE domains 583 DNS servers MAY use DNS TXT record to give additional information 584 about PCE service and add such TXT record to the additional 585 information section (See section 4.1 of [RFC1035]) that are relevant 586 to the answer and have the same authenticity as the data (Generally 587 this will be made up of A and SRV records)in the answer section. The 588 additional information may include path computation capability, the 589 PCE domains and Neighbor PCE domains associated with the PCE. If 590 discovery of PCE supporting a specific PCE capability described in 591 section 7.2 has already been performed, capability associated with 592 the PCE does not need to be included in the additional information. 594 To store new types of information, the TXT record uses a structured 595 format in its TXT-DATA field [RFC1035]. The format consists of the 596 attribute name followed by the value of the attribute. The name and 597 value are separated by an equals sign (=). The general syntax may 598 follow one defined in section 2 of [RFC1464] as follows: 600 TXT "=" 602 For example, the following TXT records contain attributes specified 603 in this fashion: 605 ex2.example.com IN TXT "pce domain = as10" 606 ex2.example.com IN TXT "neigh domain= as5" 607 ex2.example.com IN TXT "cap=link constraint" 609 The client MAY inspect those Additional Information section in the 610 DNS message and be capable of handling responses from nameservers 611 that never fill in the Additional Information part of a response. 613 7. IANA Considerations 615 7.1. IETF PCE Application Service Tags 617 IANA specifies to create a new registry ' S-NAPTR application service 618 tags' for existing IETF PCE applications. 620 +------------------+----------------------------+ 621 | Tag | PCE Application | 622 +------------------+----------------------------+ 623 | pce+gco | GCO [RFC5557] | 624 | pce+p2mp | P2MP [RFC5671] | 625 | pce+stateful | Stateful [STATEFUL-PCE] | 626 | pce+gmpls | GMPLS [RFC7025] | 627 | pce+interas | Inter-AS[RFC5376] | 628 | pce+interarea | Inter-Area [RFC4927] | 629 | pce+interlayer | Inter-layer [RFC6457] | 630 +------------------+----------------------------+ 632 Future IETF PCE applications MUST reserve the S-NAPTR application 633 service tag corresponding to the allocated PCE Application ID as 634 defined in Section 3. 636 7.2. PCE Application Protocol Tags 638 IANA has reserved the following S-NAPTR Application Protocol Tags for 639 the PCE transport protocols in the "S-NAPTR Application Protocol Tag" 640 registry created by [RFC3958]. 642 +------------------+----------+ 643 | Tag | Protocol | 644 +------------------+----------+ 645 | pce.tcp | TCP | 646 +------------------+----------+ 648 Future PCE versions that introduce new transport protocols MUST 649 reserve an appropriate S-NAPTR Application Protocol Tag in the 650 "S-NAPTR Application Protocol Tag" registry created by [RFC3958]. 652 8. Security Considerations 654 This document specifies an enhancement to the NAPTR service field 655 format. The enhancement and modifications are based on the S-NAPTR, 656 which is actually a simplification of the NAPTR, and therefore the 657 same security considerations described in [RFC3958] are applicable to 658 this document. 660 For most of those identified threats, the DNS Security Extensions 661 [RFC4033] does provide protection. It is therefore recommended to 662 consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC 663 Operational Practices [RFC6781] when deploying Path Computation 664 Services. 666 In deployments where DNSSEC usage is not feasible, measures should be 667 taken to protect against forged DNS responses and cache poisoning as 668 much as possible. Efforts in this direction are documented in 669 [RFC5452]. 671 However a malicious host doing S-NAPTR queries learns applications 672 supported by PCEs in a certain realm faster, which might help the 673 malicious host to scan potential targets for an attack more 674 efficiently when some applications have known vulnerabilities. 676 Where inputs to the procedure described in this document are fed via 677 DHCP, DHCP vulnerabilities can also cause issues. For instance, the 678 inability to authenticate DHCP discovery results may lead to the Path 679 Computation service results also being incorrect, even if the DNS 680 process was secured. 682 9. Acknowledgements 684 The author would like to thank Claire Bi,Ning Kong, Liang Xia, 685 Stephane Bortzmeyer,Yi Yang, Ted Lemon, Adrian Farrel and Stuart 686 Cheshire for their review and comments that help improvement to this 687 document. 689 10. References 691 10.1. Normative References 693 [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND 694 SPECIFICATION", RFC 1035, November 1987. 696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 697 Requirement Levels", March 1997. 699 [RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of 700 services (DNS SRV)", RFC 2782, February 2000. 702 [RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP) 703 Domain Search Option", RFC 3397, November 2002. 705 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 706 Part Three: The Domain Name System (DNS) Database", 707 RFC 3403, October 2002. 709 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 710 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 711 December 2003. 713 [RFC3958] Daigle, D. and A. Newton, "Domain-Based Application 714 Service Location Using SRV RRs and the Dynamic Delegation 715 Discovery Service (DDDS)", RFC 3958, January 2005. 717 [RFC4033] Arends, R., "DNS Security Introduction and Requirements", 718 RFC 4033, March 2005. 720 [RFC5440] Le Roux, JL., "Path Computation Element (PCE) 721 Communication Protocol (PCEP)", RFC 5440, April 2007. 723 [RFC6733] Fajardo, V., "Diameter Base Protocol", RFC 6733, October 724 2012. 726 10.2. Informative References 728 [BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and 729 TE Information using BGP", ID draft-ietf-idr-ls- 730 distribution-10, January 2015. 732 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 733 Arbitrary String Attributes", RFC 1464, May 1993. 735 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 736 Signature Option", RFC 2385, August 1998. 738 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 739 Wellington, "Secret Key Transaction Authentication for DNS 740 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 741 . 743 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 744 RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000, 745 . 747 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 748 Element (PCE)-Based Architecture", RFC 4655, August 2006. 750 [RFC4674] Droms, R., "Requirements for Path Computation Element 751 (PCE) Discovery", RFC 4674, December 2003. 753 [RFC4927] Le Roux, JL., "Path Computation Element Communication 754 Protocol (PCECP) Specific Requirements for Inter-Area MPLS 755 and GMPLS Traffic Engineering", RFC 4927, June 2007. 757 [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path 758 Computation Element (PCE) Discovery", RFC 5088, January 759 2008. 761 [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path 762 Computation Element (PCE) Discovery", RFC 5089, January 763 2008. 765 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 766 Per-Domain Path Computation Method for Establishing Inter- 767 Domain Traffic Engineering (TE) Label Switched Paths 768 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 769 . 771 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 772 Specifications: ABNF", STD 68, RFC 5234, 773 DOI 10.17487/RFC5234, January 2008, 774 . 776 [RFC5376] Bitar, N., "Inter-AS Requirements for the Path Computation 777 Element Communication Protocol (PCECP)", RFC 5376, 778 November 2008. 780 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 781 "A Backward-Recursive PCE-Based Computation (BRPC) 782 Procedure to Compute Shortest Constrained Inter-Domain 783 Traffic Engineering Label Switched Paths", RFC 5441, 784 DOI 10.17487/RFC5441, April 2009, 785 . 787 [RFC5452] Hubert, A., "Measures for Making DNS More Resilient 788 against Forged Answers", RFC 5452, January 2009. 790 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 791 Computation Element Communication Protocol (PCEP) 792 Requirements and Protocol Extensions in Support of Global 793 Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, 794 July 2009, . 796 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 797 Path Computation Element (PCE) to Point-to-Multipoint 798 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, 799 DOI 10.17487/RFC5671, October 2009, 800 . 802 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 803 Cheshire, "Internet Assigned Numbers Authority (IANA) 804 Procedures for the Management of the Service Name and 805 Transport Protocol Port Number Registry", BCP 165, 806 RFC 6335, DOI 10.17487/RFC6335, August 2011, 807 . 809 [RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter 810 Straightforward-Naming Authority Pointer (S-NAPTR) Usage", 811 RFC 6408, DOI 10.17487/RFC6408, November 2011, 812 . 814 [RFC6457] Takeda, T., "PCC-PCE Communication and PCE Discovery 815 Requirements for Inter-Layer Traffic Engineering", 816 RFC 6457, June 2007. 818 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 819 Operational Practices, Version 2", RFC 6781, December 820 2012. 822 [RFC6805] King, D. and A. Farrel, "The Application of the Path 823 Computation Element Architecture to the Determination of a 824 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 825 2012. 827 [RFC7025] Otani, T., "Requirements for GMPLS Applications of PCE", 828 RFC 7025, September 2013. 830 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 831 Computation Element Architecture", RFC 7399, 832 DOI 10.17487/RFC7399, October 2014, 833 . 835 [STATEFUL-PCE] 836 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 837 Extensions for Stateful PCE", ID draft-ietf-pce-stateful- 838 pce-11, April 2015. 840 Authors' Addresses 842 Qin Wu 843 Huawei 844 101 Software Avenue, Yuhua District 845 Nanjing, Jiangsu 210012 846 China 848 Email: sunseawq@huawei.com 849 Dhruv Dhody 850 Huawei 851 Leela Palace 852 Bangalore, Karnataka 560008 853 INDIA 855 Email: dhruv.dhody@huawei.com 857 Daniel King 858 Lancaster University 859 UK 861 Email: daniel@olddog.co.uk 863 Diego R. Lopez 864 Telefonica I+D 866 Email: diego@tid.es 868 Jeff Tantsura 869 2330 Central Expressway 870 Santa Clara, CA 95050 871 US 873 Email: Jefftant.ietf@gmail.com