idnits 2.17.00 (12 Aug 2021) /tmp/idnits16204/draft-wu-pce-dns-pce-discovery-05.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 abstract seems to contain references ([RFC5088], [RFC5089]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 539 has weird spacing: '...service rege...' -- The document date (March 3, 2014) is 3001 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: 'RFC5152' is mentioned on line 181, but not defined == Missing Reference: 'RFC5441' is mentioned on line 182, but not defined == Missing Reference: 'RFC5234' is mentioned on line 268, but not defined == Missing Reference: 'RFC6408' is mentioned on line 306, but not defined == Missing Reference: 'RFC6335' is mentioned on line 318, but not defined == Missing Reference: 'RFC5557' is mentioned on line 595, but not defined == Missing Reference: 'RFC5671' is mentioned on line 596, but not defined == Missing Reference: 'STATEFUL-PCE' is mentioned on line 597, but not defined == Unused Reference: 'ALTO' is defined on line 717, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1464 ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4674 ** Downref: Normative reference to an Informational RFC: RFC 6781 ** Downref: Normative reference to an Informational RFC: RFC 6805 == Outdated reference: draft-ietf-alto-server-discovery has been published as RFC 7286 == 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 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 6 errors (**), 0 flaws (~~), 13 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: Standards Track Huawei 5 Expires: September 4, 2014 D. King 6 Old Dog Consulting 7 D. Lopez 8 Telefonica I+D 9 J. Tantsura 10 Ericsson 11 March 3, 2014 13 Path Computation Element (PCE) Discovery using Domain Name System(DNS) 14 draft-wu-pce-dns-pce-discovery-05 16 Abstract 18 Discovery of the Path Computation Element (PCE) within an IGP area or 19 routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. 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 those proposed in [RFC5088] and [RFC5089]. 26 This document specifies the requirements, use cases, procedures and 27 extensions to support PCE 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 4, 2014. 46 Copyright Notice 48 Copyright (c) 2014 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 . . . . . . . . . . . . . . 5 67 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Outside the Routing Domain . . . . . . . . . . . . . . . . 6 69 3.2. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . 7 70 3.2.1. Query-Response versus Advertisement . . . . . . . . . 7 71 3.3. Network Address Translation Gateway . . . . . . . . . . . 7 72 4. Additional Capabilities . . . . . . . . . . . . . . . . . . . 8 73 4.1. Load Sharing of Path Computation Requests . . . . . . . . 8 74 5. Extended Naming Authority Pointer ( NAPTR )Service Field 75 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.1. IETF Standards Track PCE Applications . . . . . . . . . . 10 77 6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 78 7. Discovering a Path Computation Element . . . . . . . . . . . . 12 79 7.1. Determining the PCE Service and transport protocol . . . . 13 80 7.2. Determining the IP Address of the PCE . . . . . . . . . . 13 81 7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 15 82 7.3. Determining the PCE domains and Neighbor PCE domains . . . 16 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 8.1. IETF PCE Application Service Tags . . . . . . . . . . . . 17 85 8.2. PCE Application Protocol Tags . . . . . . . . . . . . . . 17 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 The Path Computation Element Communication Protocol (PCEP) is a 96 transaction-based protocol carried over TCP [RFC4655]. In order to 97 be able to direct path computation requests to the Path Computation 98 Element (PCE), a Path Computation Client (PCC) (or other PCE) needs 99 to know the location and capability of a PCE. 101 In a network where an IGP is used and where the PCE participates in 102 the IGP, discovery mechanisms exist for PCC (or PCE) to learn the 103 identity and capability of each PCE. [RFC5088] defines a PCE 104 Discovery (PCED) TLV carried in an OSPF Router LSA. Similarly, 105 [RFC5089] defines the PCED sub-TLV for use in PCE Discovery using 106 IS-IS. Scope of the advertisement is limited to IGP area/level or 107 Autonomous System (AS). 109 However in certain scenarios not all PCEs will participate in the IGP 110 instance, section 3 (Motivation) outlines a number of use cases. In 111 these cases, current PCE Discovery mechanisms are therefore not 112 appropriate and another PCE discovery function would be required. 114 This document describes PCE discovery via DNS. The mechanism with 115 which DNS comes to know about the PCE and its capability is out of 116 scope of this document. 118 1.1. Terminology 120 The following terminology is used in this document. 122 PCE-Domain: As per [RFC4655], any collection of network elements 123 within a common sphere of address management or path computational 124 responsibility. Examples of domains include Interior Gateway 125 Protocol (IGP) areas and Autonomous Systems (ASs). 127 Domain-Name: An identification string that defines a realm of 128 administrative autonomy, authority, or control on the Internet. 129 Any name registered in the DNS is a domain name. DNS Domain names 130 are used in various networking contexts and application-specific 131 naming and addressing purposes. In general, a domain name 132 represents an Internet Protocol (IP) resource. Examples of DNS 133 domain name is "www.example.com" or "example.com"[RFC1035]. 135 1.2. Requirements 137 As described in [RFC4674], the PCE Discovery information should at 138 least be composed of: 140 o The PCE location: an IPv4 and/or IPv6 address that is used to 141 reach the PCE. It is RECOMMENDED to use an address that is always 142 reachable if there is any connectivity to the PCE; 144 o The PCE path computation scope (i.e., inter-area, inter-AS, or 145 inter-layer); 147 o The set of one or more PCE-Domain(s) into which the PCE has 148 visibility and for which the PCE can compute paths; 150 o The set of zero, one, or more neighbor PCE-Domain(s) toward which 151 the PCE can compute paths; 153 These PCE discovery information allows PCCs to select appropriate 154 PCEs: 156 This document specifies the procedures and extension to facilitate 157 DNS-based PCE information discovery for specific use cases, and to 158 complement existing IGP discovery mechanism. 160 2. Conventions used in this document 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC2119 [RFC2119]. 166 3. Motivation 168 This section discusses in more detail the motivation and use cases 169 for an alternative DNS-based PCE discovery mechanism. 171 3.1. Outside the Routing Domain 173 When the PCE is a router participating in the IGP, or even a server 174 participating passively in the IGP, with all PCEP speakers in the 175 same routing domain, a simple and efficient way to announce PCEs 176 consists of using IGP flooding. 178 It has been identified that the existing PCE discovery mechanisms do 179 not work in following scenarios: 181 Inter-AS: Per domain path computation mechanism [RFC5152] or 182 Backward recursive path computation (BRPC) [RFC5441] MAY be used 183 by cooperating PCEs to compute inter-domain path. In which case 184 these cooperating PCEs should be known to other PCEs. In case of 185 inter-AS where the PCEs do not participate in a common IGP, the 186 existing IGP discovery mechanism cannot be used to discover 187 inter-AS PCE. 189 Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require 190 disclosure of internals of a child domain to the parent PCE. It 191 may be necessary for a third party to manage the parent PCEs 192 according to commercial and policy agreements from each of the 193 participating service providers [PCE-QUESTION]. [RFC6805] 194 specifies that a child PCE must be configured with the address of 195 its parent PCE in order for it to interact with its parent PCE. 196 However handling changes in parent PCE identities and coping with 197 failure events would be an issue for a configured system. There 198 is no scope for parent PCEs to advertise their presence to child 199 PCEs when they are not a part of the same routing domain. 201 BGP: [BGP-LS] describes a mechanism by which links state and traffic 202 engineering information can be collected from networks and shared 203 with external components using the BGP routing protocol. An 204 external PCE MAY use this mechanism to populate its TED and not 205 take part in the same IGP routing domain. 207 NMS/OSS: PCE MAY gain the knowledge of Topology information from 208 some management system (e.g.,NMS/OSS) and not take part in the 209 same routing domain. Also note that in some case PCC may not be a 210 router and instead be a management system like NMS and may not be 211 able to discover PCE via IGP discovery. 213 3.2. Discovery Mechanisms 215 3.2.1. Query-Response versus Advertisement 217 Advertisement based PCE discovery using IGP methods [RFC5088] and 218 [RFC5089] floods the PCE information to an area, a subset of areas or 219 to a full routing domain. By the very nature of flooding and 220 advertisements it generates unwanted traffic and may lead to 221 unnecessary advertisement, especially when PCE information needs 222 frequent changes. 224 DNS is a query-response based mechanism, a client (a PCC) can use DNS 225 to discover a PCE only when it needs to compute a path and does not 226 require any other node in the network to be involved. 228 In case of Intermittent PCEP session, where PCEP sessions are 229 systematically open and closed for each PCEP request, a DNS-based 230 query-response mechanism is more suitable. One may also utilize DNS- 231 based load-balancing and recovery functions. 233 3.3. Network Address Translation Gateway 235 PCEP uses TCP as the transport mechanism between PCC and PCE, and PCE 236 to PCE, communications [RFC5440]. To secure TCP connection that 237 underlay PCEP sessions, Transport Layer Security (TLS) can be used 238 besides using TCP-MD5 [RFC2385] and TCP-AUTH [RFC5295]. When PCC and 239 PCE support TCP-MD5 or TCP-AUTH while NAT does not, TCP connection 240 establishment fails. When NAT gateway is in presence, a TCP or TCP/ 241 TLS connection can be opened by Interactive Connectivity 242 Establishment (ICE) [RFC5245] for the purpose of connectivity checks. 243 However the TCP connection cannot be established in cases where one 244 of the peers is behind a NAT with connection-dependent filtering 245 properties [RFC5382]. Therefore IGP discovery is limited within an 246 IGP domain and cannot be used in this case. 248 4. Additional Capabilities 250 4.1. Load Sharing of Path Computation Requests 252 Multiple PCEs can be present in a single network domain for 253 redundancy. DNS supports inherent load balancing where multiple PCEs 254 (with different IP addresses) are known in DNS for a single PCE 255 server name and are hidden from the PCC. 257 In an IGP advertisement based PCE discovery, one learns of all the 258 PCEs and it is the job of the PCC to do load-balancing. 260 A DNS-based load-balancing mechanism works well in case of 261 Intermittent PCEP sessions and request are load-balanced among PCEs 262 similar to HTTP request without any complexity at the client. 264 5. Extended Naming Authority Pointer ( NAPTR )Service Field Format 266 The NAPTR service field format defined by the S-NAPTR DDDS 267 application in [RFC3958] follows this Augmented Backus-Naur Form 268 (ABNF) [RFC5234]: 270 service-parms = [ [app-service] *(":" app-protocol)] 271 app-service = experimental-service / iana-registered-service 272 app-protocol = experimental-protocol / iana-registered-protocol 273 experimental-service = "x-" 1*30ALPHANUMSYM 274 experimental-protocol = "x-" 1*30ALPHANUMSYM 275 iana-registered-service = ALPHA *31ALPHANUMSYM 276 iana-registered-protocol = ALPHA *31ALPHANUMSYM 277 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 278 DIGIT = %x30-39 ; 0-9 279 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 280 ALPHANUMSYM = ALPHA / DIGIT / SYM 281 ; The app-service and app-protocol tags are limited to 32 282 ; characters and must start with an alphabetic character. 283 ; The service-parms are considered case-insensitive. 285 This specification refines the "iana-registered-service" tag 286 definition for the discovery of PCE supporting a specific PCE 287 application or multiple PCE applications as defined below. 289 iana-registered-service =/ pce-service 290 pce-service = "pce" *("+" appln-name) 291 appln-name = non-ws-string 292 non-ws-string = 1*(%x21-FF) 294 The appln-name element is the Application Identifier used to identify 295 a specific PCE application. The PCE Application Name are allocated 296 by IANA as defined in section 8.1. 298 This specification also refines the "iana-registered-protocol" tag 299 definition for the discovery of PCE supporting a specific transport 300 protocol as defined below. 302 iana-registered-protocol =/ pce-protocol 303 pce-protocol = "pce." pce-transport 304 pce-transport = "tcp" / "tls.tcp" 306 Similar to application protocol tags defined in the [RFC6408],the 307 S-NAPTR application protocol tags defined by this specification MUST 308 NOT be parsed in any way by the querying application or Resolver. 309 The delimiter (".") is present in the tag to improve readability and 310 does not imply a structure or namespace of any kind. The choice of 311 delimiter (".") for the application protocol tag follows the format 312 of existing S-NAPTR application protocol tag registry entries, but 313 this does not imply that it shares semantics with any other 314 specifications that create registry entries with the same format. 316 The S-NAPTR application service and application protocol tags defined 317 by this specification are unrelated to the IANA "Service Name and 318 Transport Protocol Port Number Registry" (see [RFC6335]). 320 The maximum length of the NAPTR service field is 256 octets, 321 including a one-octet length field (see Section 4.1 of [RFC3403] and 322 Section 3.3 of [RFC1035]). 324 5.1. IETF Standards Track PCE Applications 326 A PCE Client MUST be capable of using the extended S-NAPTR 327 application service tag for dynamic discovery of a PCE supporting 328 Standards Track applications. Therefore, every IETF Standards Track 329 PCE application MUST be associated with a "PCE-service" tag formatted 330 as defined in this specification and allocated in accordance with 331 IANA policy (see Section 8). 333 For example, a NAPTR service field value of: 335 'PCE+gco:pce.tcp' 337 means that the PCE in the SRV or A/AAAA record supports the Global 338 Concurrent Optimization Application (See section 8.1)and the 339 Transport Control Protocol (TCP) as the transport protocol (See 340 section 8.2). 342 6. Backwards Compatibility 344 Domain Name System (DNS) administrators SHOULD also provision legacy 345 NAPTR records [RFC3403] in order to guarantee backwards compatibility 346 with legacy PCE that only support S-NAPTR DDDS application in 347 [RFC3958]. If the DNS administrator provisions both extended S-NAPTR 348 records as defined in this specification and legacy NAPTR records 349 defined in [RFC3403], then the extended S-NAPTR records MUST have 350 higher priority(e.g., lower order and/or preference values) than 351 legacy NAPTR records. 353 7. Discovering a Path Computation Element 355 The extended-format NAPTR records provide a mapping from a domain to 356 the SRV record or A/AAAA record for contacting a server supporting a 357 specific transport protocol and PCE application. The resource record 358 will contain an empty regular expression and a replacement value, 359 which is the SRV record or the A/AAAA record for that particular 360 transport protocol. 362 The assumption for this mechanism to work is that the DNS 363 administrator of the queried domain has first provisioned the DNS 364 with extended-format NAPTR entries. 366 When the PCC or other PCEs performs a NAPTR query for a server in a 367 particular realm, the PCC or other PCEs has to know in advance the 368 search path of the resolver, i.e.,in which realm to look for a PCE, 369 and in which Application Identifier it is interested. 371 The search path of the resolver can either be pre-configured, or 372 discovered using Diameter, DHCP or other means. For example, the 373 realm could be deduced from the Network Access Identifier (NAI) in 374 the User-Name attribute-value pair (AVP) or extracted from the 375 Destination-Realm AVP in Diameter [RFC6733]. 377 When pre-configuration is used, PCE domain(e.g.,AS200)can be added as 378 "subdomains" of the first-level domain of the underlying service 379 (e.g., AS200.example.com), which allows a NAPTR query for a server in 380 a PCE domain associated with DNS domain-name. 382 When DHCP is used, it SHOULD know the domain-name of that realm and 383 use DHCP to discover IP address of the PCE in that realm that 384 provides path computation service along with some PCE location 385 information useful to a PCC (or other PCE) for a PCE selection, and 386 contact it directly. In some instances, the discovery may result in 387 a per protocol/application list of domain-names that are then used as 388 starting points for the subsequent S-NAPTR lookups [RFC3958]. If 389 neither the IP address nor other PCE location information can be 390 discovered with the above procedure, the PCC (or other PCE) MAY 391 request a domain search list, as described in [RFC3397] and[RFC3646], 392 and use it as input to the DDDS application. 394 When the PCC (or other PCE) does not find valid domain-names using 395 the mechanisms above, it MUST stop the attempt to discover any PCE. 397 The following procedures result in an IP address, PCE domain, 398 neighboring PCE domain and PCE Computation Scope where the PCC (or 399 other PCE) can contact the PCE that hosts the service it is looking 400 for. 402 7.1. Determining the PCE Service and transport protocol 404 The PCC (or other PCE) should know the service identifier for the 405 Path Computation service and associated transport protocol. The 406 service identifier for the Path Computation service is defined as 407 "PCE+apX" as specified in section 5, The PCE supporting "PCE" service 408 MUST support TCP as transport, as described in [RFC5440]. 410 The services relevant for the task of transport protocol selection 411 are those with S-NAPTR service fields with values "PCE+apX:Y", where 412 'PCE+apX' is the service identifier defined in the previous 413 paragraph, and ' Y' is the letter that corresponds to a transport 414 protocol supported by the PCE. This document also establishes an 415 IANA registry for mappings of S-NAPTR service name to transport 416 protocol. 418 These NAPTR [RFC3958] records provide a mapping from a domain to the 419 SRV [RFC2782] record for contacting a PCE with the specific transport 420 protocol in the S-NAPTR services field. The resource record MUST 421 contain an empty regular expression and a replacement value, which 422 indicates the domain name where the SRV record for that particular 423 transport protocol can be found. As per [RFC3403], the client 424 discards any records whose services fields are not applicable. 426 The PCC (or other PCE) MUST discard any service fields that identify 427 a resolution service whose value is not valid. The S-NAPTR 428 processing as described in [RFC3403] will result in the discovery of 429 the most preferred PCE that is supported by the client, as well as an 430 SRV record for the PCE. 432 7.2. Determining the IP Address of the PCE 434 If the returned NAPTR service fields contain entries formatted as 435 "pce+apX:Y" where "X" indicates the Application Identifier and "Y" 436 indicates the supported transport protocol(s), the target realm 437 supports the extended format for NAPTR-based PCE discovery defined in 438 this document. 440 o If "X" contains the required Application Identifier and "Y" 441 matches a supported transport protocol, the PCEP implementation 442 resolves the "replacement" field entry to a target host using the 443 lookup method appropriate for the "flags" field. 445 o If "X" does not contain the required Application Identifier or "Y" 446 does not match a supported transport protocol, the PCEP 447 implementation abandons the peer discovery. 449 If the returned NAPTR service fields contain entries formatted as 450 "pce+apX" where "X" indicates the Application Identifier, the target 451 realm supports the extended format for NAPTR-based PCE discovery 452 defined in this document. 454 o If "X" contains the required Application Identifier, the PCEP 455 implementation resolves the "replacement" field entry to a target 456 host using the lookup method appropriate for the "flags" field and 457 attempts to connect using all supported transport protocols. 459 o If "X" does not contain the required Application Identifier, the 460 PCEP implementation abandons the PCE discovery. 462 If the returned NAPTR service fields contain entries formatted as 463 "pce:X" where "X" indicates the supported transport protocol(s), the 464 target realm supports PCEP but does not support the extended format 465 for NAPTR-based PCE discovery defined in this document. 467 o If "X" matches a supported transport protocol, the PCEP 468 implementation resolves the "replacement" field entry to a target 469 host using the lookup method appropriate for the "flags" field. 471 If the returned NAPTR service fields contain entries formatted as 472 "pce", the target realm supports PCEP but does not support the 473 extended format for NAPTR-based PCE discovery defined in this 474 document. The PCEP implementation resolves the "replacement" field 475 entry to a target host using the lookup method appropriate for the 476 "flags" field and attempts to connect using TCP (in future it SHOULD 477 attempt all supported transport Protocols) . 479 Note that the regexp field in the S-NAPTR example above is empty. 480 The regexp field MUST NOT be used when discovering PCE, as its usage 481 can be complex and error prone. Also, the discovery of the PCE does 482 not require the flexibility provided by this field over a static 483 target present in the TARGET field. 485 As the default behavior, the client is configured with the 486 information about which transport protocol is used for a path 487 computation service in a particular domain. The client can directly 488 perform an SRV query for that specific transport using the service 489 identifier of the path computation Service. For example, if the 490 client knows that it should be using TCP for path computation 491 service, it can perform a SRV query directly 492 for_PCE._tcp.example.com. 494 Once the server providing the desired service and the transport 495 protocol has been determined, the next step is to determine the IP 496 address. 498 According to the specification of SRV RRs in [RFC2782], the TARGET 499 field is a fully qualified domain-name (FQDN) that MUST have one or 500 more address records; the FQDN must not be an alias, i.e., there MUST 501 NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query 502 already has reported a sufficient number of these address records in 503 the Additional Data section of the DNS response (as recommended by 504 [RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) 505 of the domain-name, as appropriate. The result will be a list of IP 506 addresses, each of which can be contacted using the transport 507 protocol determined previously. 509 7.2.1. Examples 511 As an example, consider a client that wishes to find PCED service in 512 the as100.example.com domain. The client performs a S-NAPTR query 513 for that domain, and the following NAPTR records are returned: 515 Order Pref Flags Service Regexp Replacement 516 IN NAPTR 50 50 "s" "pce:pce.tls.tcp" "" 517 _PCE._tcp.as100.example.com 518 IN NAPTR 90 50 "s" "pce:pce.tcp" "" 519 _PCE._tcp.as100.example.com 521 This indicates that the domain does have a PCE providing Path 522 Computation services over TCP, in that order of preference. If the 523 client only supports TCP, TCP will be used, targeted to a host 524 determined by an SRV lookup of _PCE._tcp.example.com. That lookup 525 would return: 527 ;; Priority Weight Port Target 528 IN SRV 0 1 XXXX server1.as100.example.com 529 IN SRV 0 2 XXXX server2.as100.example.com 531 where XXXX represents the port number at which the service is 532 reachable. 534 As an alternative example, a client wishes to discover a PCE in the 535 ex2.example.com realm that supports the GCO application over TCP. 536 The client performs a NAPTR query for that domain, and the following 537 NAPTR records are returned: 539 ;; order pref flags service regexp replacement 540 IN NAPTR 150 50 "a" "pce:pce.tcp" "" 541 server1.ex2.example.com 542 IN NAPTR 150 50 "a" "pce:pce.tls.tcp" "" 543 server2.ex2.example.com 544 IN NAPTR 150 50 "a" "pce+gco:pce.tcp" "" 545 server1.ex2.example.com 546 IN NAPTR 150 50 "a" "pce+gco:pce.tls.tcp" "" 547 server2.ex2.example.com 549 This indicates that the server supports GCO(ID=1) over TCP and TLS/ 550 TCP via hosts server1.ex2.example.com and server2.ex2.example.com, 551 respectively. 553 7.3. Determining the PCE domains and Neighbor PCE domains 555 DNS servers MAY use DNS TXT record to give additional information 556 about PCE service and add such TXT record to the additional 557 information section (See section 4.1 of [RFC1035]) that are relevant 558 to the answer and have the same authenticity as the data (Generally 559 this will be made up of A and SRV records)in the answer section. The 560 additional information may include path computation capability, the 561 PCE domains and Neighbor PCE domains associated with the PCE. If 562 discovery of PCE supporting a specific PCE capability described in 563 section 7.2 has already been performed, capability associated with 564 the PCE does not need to be included in the additional information. 566 To store new types of information, the TXT record uses a structured 567 format in its TXT-DATA field [RFC1035]. The format consists of the 568 attribute name followed by the value of the attribute. The name and 569 value are separated by an equals sign (=). The general syntax may 570 follow one defined in section 2 of [RFC1464] as follows: 572 TXT "=" 574 For example, the following TXT records contain attributes specified 575 in this fashion: 577 ex2.example.com IN TXT "pce domain = as10" 578 ex2.example.com IN TXT "neigh domain= as5" 579 ex2.example.com IN TXT "cap=link constraint" 581 The client MAY inspect those Additional Information section in the 582 DNS message and be capable of handling responses from nameservers 583 that never fill in the Additional Information part of a response. 585 8. IANA Considerations 587 8.1. IETF PCE Application Service Tags 589 IANA specifies to create a new registry ' S-NAPTR application service 590 tags' for existing IETF PCE applications. 592 +------------------+----------------------------+ 593 | Tag | PCE Application | 594 +------------------+----------------------------+ 595 | pce+gco | GCO [RFC5557] | 596 | pce+p2mp | P2MP [RFC5671] | 597 | pce+stateful | Stateful [STATEFUL-PCE] | 598 | pce+gmpls | GMPLS [RFC7025] | 599 | pce+interas | Inter-AS[RFC5376] | 600 | pce+interarea | Inter-Area [RFC4927] | 601 | pce+interlayer | Inter-layer [RFC6457] | 602 +------------------+----------------------------+ 604 Future IETF PCE applications MUST reserve the S-NAPTR application 605 service tag corresponding to the allocated PCE Application ID as 606 defined in Section 3. 608 8.2. PCE Application Protocol Tags 610 IANA has reserved the following S-NAPTR Application Protocol Tags for 611 the PCE transport protocols in the "S-NAPTR Application Protocol Tag" 612 registry created by [RFC3958]. 613 +------------------+----------+ 614 | Tag | Protocol | 615 +------------------+----------+ 616 | pce.tcp | TCP | 617 +------------------+----------+ 619 Future PCE versions that introduce new transport protocols MUST 620 reserve an appropriate S-NAPTR Application Protocol Tag in the 621 "S-NAPTR Application Protocol Tag" registry created by [RFC3958]. 623 9. Security Considerations 625 This document specifies an enhancement to the NAPTR service field 626 format. The enhancement and modifications are based on the S-NAPTR, 627 which is actually a simplification of the NAPTR, and therefore the 628 same security considerations described in [RFC3958] are applicable to 629 this document. 631 For most of those identified threats, the DNS Security Extensions 632 [RFC4033] does provide protection. It is therefore recommended to 633 consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC 634 Operational Practices [RFC6781] when deploying Path Computation 635 Services. 637 In deployments where DNSSEC usage is not feasible, measures should be 638 taken to protect against forged DNS responses and cache poisoning as 639 much as possible. Efforts in this direction are documented in 640 [RFC5452]. 642 However a malicious host doing S-NAPTR queries learns applications 643 supported by PCEs in a certain realm faster, which might help the 644 malicious host to scan potential targets for an attack more 645 efficiently when some applications have known vulnerabilities. 647 Where inputs to the procedure described in this document are fed via 648 DHCP, DHCP vulnerabilities can also cause issues. For instance, the 649 inability to authenticate DHCP discovery results may lead to the Path 650 Computation service results also being incorrect, even if the DNS 651 process was secured. 653 10. Acknowledgements 655 The author would like to thank Claire Bi,Ning Kong, Liang Xia, 656 Stephane Bortzmeyer,Yi Yang, Ted Lemon, Adrian Farrel and Stuart 657 Cheshire for their review and comments that help improvement to this 658 document. 660 11. References 662 11.1. Normative References 664 [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND 665 SPECIFICATION", RFC 1035, November 1987. 667 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 668 Arbitrary String Attributes", RFC 1464, May 1993. 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", March 1997. 673 [RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of 674 services (DNS SRV)", RFC 2782, February 2000. 676 [RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP) 677 Domain Search Option", RFC 3397, November 2002. 679 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 680 Part Three: The Domain Name System (DNS) Database", 681 RFC 3403, October 2002. 683 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 684 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 685 December 2003. 687 [RFC3958] Daigle, D. and A. Newton, "Domain-Based Application 688 Service Location Using SRV RRs and the Dynamic Delegation 689 Discovery Service (DDDS)", RFC 3958, January 2005. 691 [RFC4033] Arends, R., "DNS Security Introduction and Requirements", 692 RFC 4033, March 2005. 694 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 695 Element (PCE)-Based Architecture", RFC 4655, August 2006. 697 [RFC4674] Droms, R., "Requirements for Path Computation Element 698 (PCE) Discovery", RFC 4674, December 2003. 700 [RFC5440] Le Roux, JL., "Path Computation Element (PCE) 701 Communication Protocol (PCEP)", RFC 5440, April 2007. 703 [RFC6733] Fajardo, V., "Diameter Base Protocol", RFC 6733, 704 October 2012. 706 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 707 Operational Practices, Version 2", RFC 6781, 708 December 2012. 710 [RFC6805] King, D. and A. Farrel, "The Application of the Path 711 Computation Element Architecture to the Determination of a 712 Sequence of Domains in MPLS and GMPLS", RFC 6805, 713 November 2012. 715 11.2. Informative References 717 [ALTO] Kiesel, S., "ALTO Server Discovery", 718 ID draft-ietf-alto-server-discovery-22, December 2013. 720 [BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and 721 TE Information using BGP", 722 ID draft-ietf-idr-ls-distribution-04, November 2013. 724 [PCE-QUESTION] 725 Farrel, A., "Unanswered Questions in the Path Computation 726 Element Architecture", 727 ID http://tools.ietf.org/html/draft-ietf-pce-questions-00, 728 July 2013. 730 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 731 Signature Option", RFC 2385, August 1998. 733 [RFC4927] Le Roux, JL., "Path Computation Element Communication 734 Protocol (PCECP) Specific Requirements for Inter-Area MPLS 735 and GMPLS Traffic Engineering", RFC 4927, June 2007. 737 [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path 738 Computation Element (PCE) Discovery", RFC 5088, 739 January 2008. 741 [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path 742 Computation Element (PCE) Discovery", RFC 5089, 743 January 2008. 745 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 746 (ICE): A Protocol for Network Address Translator (NAT) 747 Traversal for Offer/Answer Protocols", RFC 5245, 748 April 2010. 750 [RFC5295] Touch, J., "The TCP Authentication Option", RFC 5295, 751 June 2010. 753 [RFC5376] Bitar, N., "Inter-AS Requirements for the Path Computation 754 Element Communication Protocol (PCECP)", RFC 5376, 755 November 2008. 757 [RFC5382] Guha, S., "NAT Behavioral Requirements for TCP", RFC 5382, 758 October 2008. 760 [RFC5452] Hubert, A., "Measures for Making DNS More Resilient 761 against Forged Answers", RFC 5452, January 2009. 763 [RFC6457] Takeda, T., "PCC-PCE Communication and PCE Discovery 764 Requirements for Inter-Layer Traffic Engineering", 765 RFC 6457, June 2007. 767 [RFC7025] Otani, T., "Requirements for GMPLS Applications of PCE", 768 RFC 7025, September 2013. 770 Authors' Addresses 772 Qin Wu 773 Huawei 774 101 Software Avenue, Yuhua District 775 Nanjing, Jiangsu 210012 776 China 778 Email: sunseawq@huawei.com 780 Dhruv Dhody 781 Huawei 782 Leela Palace 783 Bangalore, Karnataka 560008 784 INDIA 786 Email: dhruv.dhody@huawei.com 788 Daniel King 789 Old Dog Consulting 790 UK 792 Email: daniel@olddog.co.uk 794 Diego R. Lopez 795 Telefonica I+D 797 Email: diego@tid.es 799 Jeff Tantsura 800 Ericsson 801 300 Holger Way 802 San Jose, CA 95134 803 US 805 Email: Jeff.Tantsura@ericsson.com