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