idnits 2.17.1 draft-wu-pce-dns-pce-discovery-07.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 -- The document date (October 27, 2014) is 3462 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) == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-06 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-09 -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: April 27, 2015 D. King 6 Lancaster University 7 D. Lopez 8 Telefonica I+D 9 J. Tantsura 10 Ericsson 11 October 27, 2014 13 Path Computation Element (PCE) Discovery using Domain Name System(DNS) 14 draft-wu-pce-dns-pce-discovery-07 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 April 27, 2015. 47 Copyright Notice 49 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 9 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. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 90 8.1. DNS-based PCE Discovery Experimentation . . . . . . . . . 15 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 95 11.2. Informative References . . . . . . . . . . . . . . . . . 18 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 The Path Computation Element Communication Protocol (PCEP) is a 101 transaction-based protocol carried over TCP [RFC4655]. In order to 102 be able to direct path computation requests to the Path Computation 103 Element (PCE), a Path Computation Client (PCC) (or other PCE) needs 104 to know the location and capability of a PCE. 106 In a network where an IGP is used and where the PCE participates in 107 the IGP, discovery mechanisms exist for PCC (or PCE) to learn the 108 identity and capability of each PCE. [RFC5088] defines a PCE 109 Discovery (PCED) TLV carried in an OSPF Router LSA. Similarly, 110 [RFC5089] defines the PCED sub-TLV for use in PCE Discovery using IS- 111 IS. Scope of the advertisement is limited to IGP area/level or 112 Autonomous System (AS). 114 However in certain scenarios not all PCEs will participate in the 115 same IGP instance, section 3 (Motivation) outlines a number of use 116 cases. In these cases, current PCE Discovery mechanisms are 117 therefore not appropriate and another PCE discovery function would be 118 required. (sec 4 of [PCE-QUESTION]). 120 This document describes PCE discovery via DNS. The mechanism with 121 which DNS comes to know about the PCE and its capability is out of 122 scope of this document. 124 1.1. Terminology 126 The following terminology is used in this document. 128 PCE-Domain: As per [RFC4655], any collection of network elements 129 within a common sphere of address management or path computational 130 responsibility. Examples of domains include Interior Gateway 131 Protocol (IGP) areas and Autonomous Systems (ASs). 133 Domain-Name: An identification string that defines a realm of 134 administrative autonomy, authority, or control on the Internet. 135 Any name registered in the DNS is a domain name. DNS Domain names 136 are used in various networking contexts and application-specific 137 naming and addressing purposes. In general, a domain name 138 represents an Internet Protocol (IP) resource. Examples of DNS 139 domain name is "www.example.com" or "example.com" [RFC1035]. 141 1.2. Requirements 143 As described in [RFC4674], the PCE Discovery information should at 144 least be composed of: 146 o The PCE location: an IPv4 and/or IPv6 address that is used to 147 reach the PCE. It is RECOMMENDED to use an address that is always 148 reachable if there is any connectivity to the PCE; 150 o The PCE path computation scope (i.e., inter-area, inter-AS, or 151 inter-layer); 153 o The set of one or more PCE-Domain(s) into which the PCE has 154 visibility and for which the PCE can compute paths; 156 o The set of zero, one, or more neighbor PCE-Domain(s) toward which 157 the PCE can compute paths; 159 o The set of communication and path computation-specific 160 capabilities. 162 These PCE discovery information allows PCCs to select appropriate 163 PCEs. 165 This document specifies the procedures and extension to facilitate 166 DNS-based PCE information discovery for specific use cases, and to 167 complement existing IGP discovery mechanism. 169 2. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC2119 [RFC2119]. 175 3. Motivation 177 This section discusses in more detail the motivation and use cases 178 for an alternative DNS-based PCE discovery mechanism. 180 3.1. Outside the Routing Domain 182 When the PCE is a router participating in the IGP, or even a server 183 participating passively in the IGP, with all PCEP speakers in the 184 same routing domain, a simple and efficient way to announce PCEs 185 consists of using IGP flooding. 187 It has been identified that the existing PCE discovery mechanisms do 188 not work very well in following scenarios: 190 Inter-AS: Per domain path computation mechanism [RFC5152] or 191 Backward recursive path computation (BRPC) [RFC5441] MAY be used 192 by cooperating PCEs to compute inter-domain path. In which case 193 these cooperating PCEs should be known to other PCEs. In case of 194 inter-AS where the PCEs do not participate in a common IGP, the 195 existing IGP discovery mechanism cannot be used to discover inter- 196 AS PCE. 198 Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require 199 disclosure of internals of a child domain to the parent PCE. It 200 may be necessary for a third party to manage the parent PCEs 201 according to commercial and policy agreements from each of the 202 participating service providers [PCE-QUESTION]. [RFC6805] 203 specifies that a child PCE must be configured with the address of 204 its parent PCE in order for it to interact with its parent PCE. 205 However handling changes in parent PCE identities and coping with 206 failure events would be an issue for a configured system. There 207 is no scope for parent PCEs to advertise their presence to child 208 PCEs when they are not a part of the same routing domain. 210 BGP-LS: [BGP-LS] describes a mechanism by which links state and 211 traffic engineering information can be collected from networks and 212 shared with external components using the BGP routing protocol. 213 An external PCE MAY use this mechanism to populate its TED and not 214 take part in the same IGP routing domain. 216 NMS/OSS: PCE MAY gain the knowledge of Topology information from 217 some management system (e.g.,NMS/OSS) and not take part in the 218 same routing domain. Also note that in some case PCC may not be a 219 router and instead be a management system like NMS and may not be 220 able to discover PCE via IGP discovery. 222 3.2. Discovery Mechanisms 224 3.2.1. Query-Response versus Advertisement 226 Advertisement based PCE discovery using IGP methods [RFC5088] and 227 [RFC5089] floods the PCE information to an area, a subset of areas or 228 to a full routing domain. By the very nature of flooding and 229 advertisements it generates unwanted traffic and may lead to 230 unnecessary advertisement, especially when PCE information needs 231 frequent changes. 233 DNS is a query-response based mechanism, a client (a PCC) can use DNS 234 to discover a PCE only when it needs to compute a path and does not 235 require any other node in the network to be involved. 237 In case of Intermittent PCEP session, where PCEP sessions are 238 systematically open and closed for each PCEP request, a DNS-based 239 query-response mechanism is more suitable. One may also utilize DNS- 240 based load-balancing and recovery functions. 242 3.3. PCE Virtualization 244 Server virtualization has gain importance since it provides better 245 reliability and high availability in the event of hardware failure. 246 It allows for higher utilization of physical resources while 247 improving administration by having a single management interface for 248 all virtual servers. 250 When one PCE instance is virtually hosted on a server and initiated 251 as a PCE instance, another PCE instance may be created on the same 252 server or a different server to provide better load balancing and 253 reliability. In such a case, where there are a large number of PCCs 254 that need to know these PCE instances' location, manual configuration 255 on PCCs for PCC and PCE relationship is not trivial or desirable. 257 3.4. Additional Capabilities 259 3.4.1. Handling Changes in PCE Identities 261 In the case of H-PCE ,when a dynamic Address is assigned to the 262 parent PCE, any existing configuration entry on child PCE becomes 263 invalid and the parent PCE becomes unreachable. In order to handle 264 changes in parent PCE identities, the DNS update can be used to 265 provide IP reachability to the parent PCE with new assigned Address. 266 The DNS update can be performed by either parent PCE or OSS/NMS that 267 is aware of PCE Identities changes. 269 3.4.2. Secure Inter-domain Discovery 271 Applications make use of DNS lookups on FQDN to find a node(e.g., 272 PCEP endpoint). When a PCE performs DNS lookup or dynamic DNS update 273 with the DNS server, the PCE MUST have a security association of some 274 type with the DNS server. The security association SHOULD be 275 established either using DNSSEC [RFC4033] or TSIG/ 276 TKEY[RFC2845][RFC2930]. DNS lookup for PCE Discovery can be applied 277 either within an administration domain or spanning across 278 administration domains. A security association is REQUIRED even if 279 the DNS server is in the same administrative domain as the PCE. 281 3.4.3. Load Sharing of Path Computation Requests 283 Multiple PCEs can be present in a single network domain for 284 redundancy. DNS supports inherent load balancing where multiple PCEs 285 (with different IP addresses) are known in DNS for a single PCE 286 server name and are hidden from the PCC. 288 In an IGP advertisement based PCE discovery, one learns of all the 289 PCEs and it is the job of the PCC to do load-balancing. 291 A DNS-based load-balancing mechanism works well in case of 292 Intermittent PCEP sessions and request are load-balanced among PCEs 293 similar to HTTP request without any complexity at the client. 295 4. Extended Naming Authority Pointer ( NAPTR )Service Field Format 297 The NAPTR service field format defined by the S-NAPTR DDDS 298 application in [RFC3958] follows this Augmented Backus-Naur Form 299 (ABNF) [RFC5234]: 301 service-parms = [ [app-service] *(":" app-protocol)] 302 app-service = experimental-service / iana-registered-service 303 app-protocol = experimental-protocol / iana-registered-protocol 304 experimental-service = "x-" 1*30ALPHANUMSYM 305 experimental-protocol = "x-" 1*30ALPHANUMSYM 306 iana-registered-service = ALPHA *31ALPHANUMSYM 307 iana-registered-protocol = ALPHA *31ALPHANUMSYM 308 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 309 DIGIT = %x30-39 ; 0-9 310 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 311 ALPHANUMSYM = ALPHA / DIGIT / SYM 312 ; The app-service and app-protocol tags are limited to 32 313 ; characters and must start with an alphabetic character. 314 ; The service-parms are considered case-insensitive. 316 This specification refines the "iana-registered-service" tag 317 definition for the discovery of PCE supporting a specific PCE 318 application or multiple PCE applications as defined below. 320 iana-registered-service =/ pce-service 321 pce-service = "pce" *("+" appln-name) 322 appln-name = non-ws-string 323 non-ws-string = 1*(%x21-FF) 325 The appln-name element is the Application Identifier used to identify 326 a specific PCE application. The PCE Application Name are allocated 327 by IANA as defined in section 8.1. 329 This specification also refines the "iana-registered-protocol" tag 330 definition for the discovery of PCE supporting a specific transport 331 protocol as defined below. 333 iana-registered-protocol =/ pce-protocol 334 pce-protocol = "pce." pce-transport 335 pce-transport = "tcp" / "tls.tcp" 337 Similar to application protocol tags defined in the [RFC6408],the 338 S-NAPTR application protocol tags defined by this specification MUST 339 NOT be parsed in any way by the querying application or Resolver. 340 The delimiter (".") is present in the tag to improve readability and 341 does not imply a structure or namespace of any kind. The choice of 342 delimiter (".") for the application protocol tag follows the format 343 of existing S-NAPTR application protocol tag registry entries, but 344 this does not imply that it shares semantics with any other 345 specifications that create registry entries with the same format. 347 The S-NAPTR application service and application protocol tags defined 348 by this specification are unrelated to the IANA "Service Name and 349 Transport Protocol Port Number Registry" (see [RFC6335]). 351 The maximum length of the NAPTR service field is 256 octets, 352 including a one-octet length field (see Section 4.1 of [RFC3403] and 353 Section 3.3 of [RFC1035]). 355 4.1. IETF Standards Track PCE Applications 357 A PCE Client MUST be capable of using the extended S-NAPTR 358 application service tag for dynamic discovery of a PCE supporting 359 Standards Track applications. Therefore, every IETF Standards Track 360 PCE application MUST be associated with a "PCE-service" tag formatted 361 as defined in this specification and allocated in accordance with 362 IANA policy (see Section 8). 364 For example, a NAPTR service field value of: 366 'PCE+gco:pce.tcp' 368 means that the PCE in the SRV or A/AAAA record supports the Global 369 Concurrent Optimization Application (See section 8.1)and the 370 Transport Control Protocol (TCP) as the transport protocol (See 371 section 8.2). 373 5. Backwards Compatibility 375 Domain Name System (DNS) administrators SHOULD also provision legacy 376 NAPTR records [RFC3403] in order to guarantee backwards compatibility 377 with legacy PCE that only support S-NAPTR DDDS application in 378 [RFC3958]. If the DNS administrator provisions both extended S-NAPTR 379 records as defined in this specification and legacy NAPTR records 380 defined in [RFC3403], then the extended S-NAPTR records MUST have 381 higher priority(e.g., lower order and/or preference values) than 382 legacy NAPTR records. 384 6. Discovering a Path Computation Element 386 The extended-format NAPTR records provide a mapping from a domain to 387 the SRV record or A/AAAA record for contacting a server supporting a 388 specific transport protocol and PCE application. The resource record 389 will contain an empty regular expression and a replacement value, 390 which is the SRV record or the A/AAAA record for that particular 391 transport protocol. 393 The assumption for this mechanism to work is that the DNS 394 administrator of the queried domain has first provisioned the DNS 395 with extended-format NAPTR entries. 397 When the PCC or other PCEs performs a NAPTR query for a server in a 398 particular realm, the PCC or other PCEs has to know in advance the 399 search path of the resolver, i.e.,in which realm to look for a PCE, 400 and in which Application Identifier it is interested. 402 The search path of the resolver can either be pre-configured, or 403 discovered using Diameter, DHCP or other means. For example, the 404 realm could be deduced from the Network Access Identifier (NAI) in 405 the User-Name attribute-value pair (AVP) or extracted from the 406 Destination-Realm AVP in Diameter [RFC6733]. 408 When pre-configuration is used, PCE domain(e.g.,AS200)can be added as 409 "subdomains" of the first-level domain of the underlying service 410 (e.g., AS200.example.com), which allows a NAPTR query for a server in 411 a PCE domain associated with DNS domain-name. 413 When DHCP is used, it SHOULD know the domain-name of that realm and 414 use DHCP to discover IP address of the PCE in that realm that 415 provides path computation service along with some PCE location 416 information useful to a PCC (or other PCE) for a PCE selection, and 417 contact it directly. In some instances, the discovery may result in 418 a per protocol/application list of domain-names that are then used as 419 starting points for the subsequent S-NAPTR lookups [RFC3958]. If 420 neither the IP address nor other PCE location information can be 421 discovered with the above procedure, the PCC (or other PCE) MAY 422 request a domain search list, as described in [RFC3397] and[RFC3646], 423 and use it as input to the DDDS application. 425 When the PCC (or other PCE) does not find valid domain-names using 426 the mechanisms above, it MUST stop the attempt to discover any PCE. 428 The following procedures result in an IP address, PCE domain, 429 neighboring PCE domain and PCE Computation Scope where the PCC (or 430 other PCE) can contact the PCE that hosts the service it is looking 431 for. 433 6.1. Determining the PCE Service and transport protocol 435 The PCC (or other PCE) should know the service identifier for the 436 Path Computation service and associated transport protocol. The 437 service identifier for the Path Computation service is defined as 438 "PCE+apX" as specified in section 5, The PCE supporting "PCE" service 439 MUST support TCP as transport, as described in [RFC5440]. 441 The services relevant for the task of transport protocol selection 442 are those with S-NAPTR service fields with values "PCE+apX:Y", where 443 'PCE+apX' is the service identifier defined in the previous 444 paragraph, and ' Y' is the letter that corresponds to a transport 445 protocol supported by the PCE. This document also establishes an 446 IANA registry for mappings of S-NAPTR service name to transport 447 protocol. 449 These NAPTR [RFC3958] records provide a mapping from a domain to the 450 SRV [RFC2782] record for contacting a PCE with the specific transport 451 protocol in the S-NAPTR services field. The resource record MUST 452 contain an empty regular expression and a replacement value, which 453 indicates the domain name where the SRV record for that particular 454 transport protocol can be found. As per [RFC3403], the client 455 discards any records whose services fields are not applicable. 457 The PCC (or other PCE) MUST discard any service fields that identify 458 a resolution service whose value is not valid. The S-NAPTR 459 processing as described in [RFC3403] will result in the discovery of 460 the most preferred PCE that is supported by the client, as well as an 461 SRV record for the PCE. 463 6.2. Determining the IP Address of the PCE 465 If the returned NAPTR service fields contain entries formatted as 466 "pce+apX:Y" where "X" indicates the Application Identifier and "Y" 467 indicates the supported transport protocol(s), the target realm 468 supports the extended format for NAPTR-based PCE discovery defined in 469 this document. 471 o If "X" contains the required Application Identifier and "Y" 472 matches a supported transport protocol, the PCEP implementation 473 resolves the "replacement" field entry to a target host using the 474 lookup method appropriate for the "flags" field. 476 o If "X" does not contain the required Application Identifier or "Y" 477 does not match a supported transport protocol, the PCEP 478 implementation abandons the peer discovery. 480 If the returned NAPTR service fields contain entries formatted as 481 "pce+apX" where "X" indicates the Application Identifier, the target 482 realm supports the extended format for NAPTR-based PCE discovery 483 defined in this document. 485 o If "X" contains the required Application Identifier, the PCEP 486 implementation resolves the "replacement" field entry to a target 487 host using the lookup method appropriate for the "flags" field and 488 attempts to connect using all supported transport protocols. 490 o If "X" does not contain the required Application Identifier, the 491 PCEP implementation abandons the PCE discovery. 493 If the returned NAPTR service fields contain entries formatted as 494 "pce:X" where "X" indicates the supported transport protocol(s), the 495 target realm supports PCEP but does not support the extended format 496 for NAPTR-based PCE discovery defined in this document. 498 o If "X" matches a supported transport protocol, the PCEP 499 implementation resolves the "replacement" field entry to a target 500 host using the lookup method appropriate for the "flags" field. 502 If the returned NAPTR service fields contain entries formatted as 503 "pce", the target realm supports PCEP but does not support the 504 extended format for NAPTR-based PCE discovery defined in this 505 document. The PCEP implementation resolves the "replacement" field 506 entry to a target host using the lookup method appropriate for the 507 "flags" field and attempts to connect using TCP (in future it SHOULD 508 attempt all supported transport Protocols) . 510 Note that the regexp field in the S-NAPTR example above is empty. 511 The regexp field MUST NOT be used when discovering PCE, as its usage 512 can be complex and error prone. Also, the discovery of the PCE does 513 not require the flexibility provided by this field over a static 514 target present in the TARGET field. 516 As the default behavior, the client is configured with the 517 information about which transport protocol is used for a path 518 computation service in a particular domain. The client can directly 519 perform an SRV query for that specific transport using the service 520 identifier of the path computation Service. For example, if the 521 client knows that it should be using TCP for path computation 522 service, it can perform a SRV query directly 523 for_PCE._tcp.example.com. 525 Once the server providing the desired service and the transport 526 protocol has been determined, the next step is to determine the IP 527 address. 529 According to the specification of SRV RRs in [RFC2782], the TARGET 530 field is a fully qualified domain-name (FQDN) that MUST have one or 531 more address records; the FQDN must not be an alias, i.e., there MUST 532 NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query 533 already has reported a sufficient number of these address records in 534 the Additional Data section of the DNS response (as recommended by 535 [RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) 536 of the domain-name, as appropriate. The result will be a list of IP 537 addresses, each of which can be contacted using the transport 538 protocol determined previously. 540 6.2.1. Examples 542 As an example, consider a client that wishes to find PCED service in 543 the as100.example.com domain. The client performs a S-NAPTR query 544 for that domain, and the following NAPTR records are returned: 546 Order Pref Flags Service Regexp Replacement 547 IN NAPTR 50 50 "s" "pce:pce.tls.tcp" "" 548 _PCE._tcp.as100.example.com 549 IN NAPTR 90 50 "s" "pce:pce.tcp" "" 550 _PCE._tcp.as100.example.com 552 This indicates that the domain does have a PCE providing Path 553 Computation services over TCP, in that order of preference. If the 554 client only supports TCP, TCP will be used, targeted to a host 555 determined by an SRV lookup of _PCE._tcp.example.com. That lookup 556 would return: 558 ;; Priority Weight Port Target 559 IN SRV 0 1 XXXX server1.as100.example.com 560 IN SRV 0 2 XXXX server2.as100.example.com 562 where XXXX represents the port number at which the service is 563 reachable. 565 As an alternative example, a client wishes to discover a PCE in the 566 ex2.example.com realm that supports the GCO application over TCP. 567 The client performs a NAPTR query for that domain, and the following 568 NAPTR records are returned: 570 ;; order pref flags service regexp replacement 571 IN NAPTR 150 50 "a" "pce:pce.tcp" "" 572 server1.ex2.example.com 573 IN NAPTR 150 50 "a" "pce:pce.tls.tcp" "" 574 server2.ex2.example.com 575 IN NAPTR 150 50 "a" "pce+gco:pce.tcp" "" 576 server1.ex2.example.com 577 IN NAPTR 150 50 "a" "pce+gco:pce.tls.tcp" "" 578 server2.ex2.example.com 580 This indicates that the server supports GCO(ID=1) over TCP and TLS/ 581 TCP via hosts server1.ex2.example.com and server2.ex2.example.com, 582 respectively. 584 6.3. Determining the PCE domains and Neighbor PCE domains 586 DNS servers MAY use DNS TXT record to give additional information 587 about PCE service and add such TXT record to the additional 588 information section (See section 4.1 of [RFC1035]) that are relevant 589 to the answer and have the same authenticity as the data (Generally 590 this will be made up of A and SRV records)in the answer section. The 591 additional information may include path computation capability, the 592 PCE domains and Neighbor PCE domains associated with the PCE. If 593 discovery of PCE supporting a specific PCE capability described in 594 section 7.2 has already been performed, capability associated with 595 the PCE does not need to be included in the additional information. 597 To store new types of information, the TXT record uses a structured 598 format in its TXT-DATA field [RFC1035]. The format consists of the 599 attribute name followed by the value of the attribute. The name and 600 value are separated by an equals sign (=). The general syntax may 601 follow one defined in section 2 of [RFC1464] as follows: 603 TXT "=" 605 For example, the following TXT records contain attributes specified 606 in this fashion: 608 ex2.example.com IN TXT "pce domain = as10" 609 ex2.example.com IN TXT "neigh domain= as5" 610 ex2.example.com IN TXT "cap=link constraint" 612 The client MAY inspect those Additional Information section in the 613 DNS message and be capable of handling responses from nameservers 614 that never fill in the Additional Information part of a response. 616 7. IANA Considerations 618 7.1. IETF PCE Application Service Tags 620 IANA specifies to create a new registry ' S-NAPTR application service 621 tags' for existing IETF PCE applications. 623 +------------------+----------------------------+ 624 | Tag | PCE Application | 625 +------------------+----------------------------+ 626 | pce+gco | GCO [RFC5557] | 627 | pce+p2mp | P2MP [RFC5671] | 628 | pce+stateful | Stateful [STATEFUL-PCE] | 629 | pce+gmpls | GMPLS [RFC7025] | 630 | pce+interas | Inter-AS[RFC5376] | 631 | pce+interarea | Inter-Area [RFC4927] | 632 | pce+interlayer | Inter-layer [RFC6457] | 633 +------------------+----------------------------+ 635 Future IETF PCE applications MUST reserve the S-NAPTR application 636 service tag corresponding to the allocated PCE Application ID as 637 defined in Section 3. 639 7.2. PCE Application Protocol Tags 641 IANA has reserved the following S-NAPTR Application Protocol Tags for 642 the PCE transport protocols in the "S-NAPTR Application Protocol Tag" 643 registry created by [RFC3958]. 645 +------------------+----------+ 646 | Tag | Protocol | 647 +------------------+----------+ 648 | pce.tcp | TCP | 649 +------------------+----------+ 651 Future PCE versions that introduce new transport protocols MUST 652 reserve an appropriate S-NAPTR Application Protocol Tag in the 653 "S-NAPTR Application Protocol Tag" registry created by [RFC3958]. 655 8. Implementation Status 657 The concept and protocol procedures describe in this I-D were used as 658 a prototype for a "Transport PCE" based on the principles of Network 659 Function Virtualization (NFV). 661 This work was lead by: 663 o Ricard Vilalta (ricard.vilalta@cttc.es) 665 o Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) 667 The experiment proposed the adoption of the NFV architecture to 668 deploy a PCE dedicated to path computation of a transport network as 669 a Virtual Network Function (VNF). Although the NFV architecture has 670 successfully been demonstrated for mobile networks, there have been 671 only few attempts to introduce this architecture to core networks. 673 A PCE NFV orchestrator is introduced, so that the proposed transport 674 PCE NFV is able to handle intense peak loads of path computation 675 requests. The NFV orchestrator dynamically deploys virtual PCEs 676 (vPCEs) on demand to keep the quality of the VNF (e.g., in terms of 677 latency, request processing time, dedicated algorithms, etc.). 679 A vPCE is a PCE instance, which is run as a software application on a 680 cloud computing environment (e.g., a virtual machine). The use of 681 DNS-based PCE discovery was to offer the deployed vPCEs mechanisms 682 (and multiple VNFs) to perceived as a single vPCE by the different 683 Path Computation Clients (PCC). 685 8.1. DNS-based PCE Discovery Experimentation 687 The prototype, using the DNS-based discovery proposal, is described 688 as follows: 690 o The cloud infrastructure used dynamic deployment and release of 691 virtual machines with custom images running vPCE as an 692 application. 694 o The cloud infrastructure assigned each vPCE a new IP address from 695 a pool of available IP addresses. 697 o This IP address is parsed and the PCE DNS is notified with the new 698 IP address for a new available vPCE. 700 o As a DNS is a query-response based mechanism. A PCC may use DNS 701 to discover a PCE only when it needs to compute a path. 703 In the case of vPCE applications and intermittent PCEP session, which 704 are systematically opened and closed for each PCEP request, a DNS- 705 based query-response mechanism is much more suitable, than IGP-based 706 discovery, in the virtualized environment. 708 It was also established that DNS-based discovery facilities load 709 balancing where multiple vPCEs (with different IP addresses) are 710 identified via DNS using a single PCE server name. This is seen by 711 the PCCs as a single resource. Ensuring requests are load-balanced 712 among vPCEs with with minimal complexity, and in the event of failure 713 of the VNFs, a new VNF or VM (hosting the VNFs) may be spawned 714 without having to update PCE reachability information on the PCC or 715 flooding the IGP with the PCE location each time the IP address 716 changes. 718 Full details of the prototyping can be found at: 720 R. Vilalta, R. Munoz, R. Casellas, R. Martinez, V. Lopez, D. 721 Lopez "Transport PCE Network Function Virtualization", in Proc. of 722 European Conference on Optical Communication (ECOC 2014), September 723 21-25, Cannes (France). 725 728 [Note to the RFC Editor - This section is intended to be removed 729 before publication.] 731 9. Security Considerations 733 This document specifies an enhancement to the NAPTR service field 734 format. The enhancement and modifications are based on the S-NAPTR, 735 which is actually a simplification of the NAPTR, and therefore the 736 same security considerations described in [RFC3958] are applicable to 737 this document. 739 For most of those identified threats, the DNS Security Extensions 740 [RFC4033] does provide protection. It is therefore recommended to 741 consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC 742 Operational Practices [RFC6781] when deploying Path Computation 743 Services. 745 In deployments where DNSSEC usage is not feasible, measures should be 746 taken to protect against forged DNS responses and cache poisoning as 747 much as possible. Efforts in this direction are documented in 748 [RFC5452]. 750 However a malicious host doing S-NAPTR queries learns applications 751 supported by PCEs in a certain realm faster, which might help the 752 malicious host to scan potential targets for an attack more 753 efficiently when some applications have known vulnerabilities. 755 Where inputs to the procedure described in this document are fed via 756 DHCP, DHCP vulnerabilities can also cause issues. For instance, the 757 inability to authenticate DHCP discovery results may lead to the Path 758 Computation service results also being incorrect, even if the DNS 759 process was secured. 761 10. Acknowledgements 763 The author would like to thank Claire Bi,Ning Kong, Liang Xia, 764 Stephane Bortzmeyer,Yi Yang, Ted Lemon, Adrian Farrel and Stuart 765 Cheshire for their review and comments that help improvement to this 766 document. 768 11. References 770 11.1. Normative References 772 [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND 773 SPECIFICATION", RFC 1035, November 1987. 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", March 1997. 778 [RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of 779 services (DNS SRV)", RFC 2782, February 2000. 781 [RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP) 782 Domain Search Option", RFC 3397, November 2002. 784 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 785 Part Three: The Domain Name System (DNS) Database", RFC 786 3403, October 2002. 788 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 789 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 790 December 2003. 792 [RFC3958] Daigle, D. and A. Newton, "Domain-Based Application 793 Service Location Using SRV RRs and the Dynamic Delegation 794 Discovery Service (DDDS)", RFC 3958, January 2005. 796 [RFC4033] Arends, R., "DNS Security Introduction and Requirements", 797 RFC 4033, March 2005. 799 [RFC5440] Le Roux, JL., "Path Computation Element (PCE) 800 Communication Protocol (PCEP)", RFC 5440, April 2007. 802 [RFC6733] Fajardo, V., "Diameter Base Protocol", RFC 6733, October 803 2012. 805 11.2. Informative References 807 [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 808 Ray, "North-Bound Distribution of Link-State and TE 809 Information using BGP", draft-ietf-idr-ls-distribution-06 810 (work in progress), September 2014. 812 [STATEFUL-PCE] 813 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 814 Extensions for Stateful PCE", draft-ietf-pce-stateful- 815 pce-09 (work in progress), June 2014. 817 [PCE-QUESTION] 818 Farrel, A. and D. King, "Unanswered Questions in the Path 819 Computation Element Architecture", draft-ietf-pce- 820 questions-08 (work in progress), October 2014. 822 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 823 Arbitrary String Attributes", RFC 1464, May 1993. 825 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 826 Wellington, "Secret Key Transaction Authentication for 827 DNS (TSIG)", RFC 2845, May 2000. 829 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS 830 (TKEY RR)", RFC 2930, September 2000. 832 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 833 Element (PCE)-Based Architecture", RFC 4655, August 2006. 835 [RFC4674] Droms, R., "Requirements for Path Computation Element 836 (PCE) Discovery", RFC 4674, December 2003. 838 [RFC4927] Le Roux, JL., "Path Computation Element Communication 839 Protocol (PCECP) Specific Requirements for Inter-Area MPLS 840 and GMPLS Traffic Engineering", RFC 4927, June 2007. 842 [RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path 843 Computation Element (PCE) Discovery", RFC 5088, January 844 2008. 846 [RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path 847 Computation Element (PCE) Discovery", RFC 5089, January 848 2008. 850 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 851 Path Computation Method for Establishing Inter-Domain 852 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 853 5152, February 2008. 855 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 856 Specifications: ABNF", STD 68, RFC 5234, January 2008. 858 [RFC5376] Bitar, N., "Inter-AS Requirements for the Path Computation 859 Element Communication Protocol (PCECP)", RFC 5376, 860 November 2008. 862 [RFC5452] Hubert, A., "Measures for Making DNS More Resilient 863 against Forged Answers", RFC 5452, January 2009. 865 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 866 Backward-Recursive PCE-Based Computation (BRPC) Procedure 867 to Compute Shortest Constrained Inter-Domain Traffic 868 Engineering Label Switched Paths", RFC 5441, April 2009. 870 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 871 Computation Element Communication Protocol (PCEP) 872 Requirements and Protocol Extensions in Support of 873 Global Concurrent Optimization", RFC 5557, July 2009. 875 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of 876 the Path Computation Element (PCE) to Point-to- 877 Multipoint (P2MP) MPLS and GMPLS Traffic Engineering 878 (TE)", RFC 5671, October 2009. 880 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 881 Cheshire, "Internet Assigned Numbers Authority (IANA) 882 Procedures for the Management of the Service Name and 883 Transport Protocol Port Number Registry", BCP 165, RFC 884 6335, August 2011. 886 [RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter 887 Straightforward-Naming Authority Pointer (S-NAPTR) 888 Usage", RFC 6408, November 2011. 890 [RFC6457] Takeda, T., "PCC-PCE Communication and PCE Discovery 891 Requirements for Inter-Layer Traffic Engineering", RFC 892 6457, June 2007. 894 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 895 Operational Practices, Version 2", RFC 6781, December 896 2012. 898 [RFC6805] King, D. and A. Farrel, "The Application of the Path 899 Computation Element Architecture to the Determination of a 900 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 901 2012. 903 [RFC7025] Otani, T., "Requirements for GMPLS Applications of PCE", 904 RFC 7025, September 2013. 906 Authors' Addresses 908 Qin Wu 909 Huawei 910 101 Software Avenue, Yuhua District 911 Nanjing, Jiangsu 210012 912 China 914 Email: sunseawq@huawei.com 916 Dhruv Dhody 917 Huawei 918 Leela Palace 919 Bangalore, Karnataka 560008 920 INDIA 922 Email: dhruv.dhody@huawei.com 924 Daniel King 925 Lancaster University 926 UK 928 Email: d.king@lancaster.ac.uk 930 Diego R. Lopez 931 Telefonica I+D 933 Email: diego@tid.es 935 Jeff Tantsura 936 Ericsson 937 300 Holger Way 938 San Jose, CA 95134 939 US 941 Email: Jeff.Tantsura@ericsson.com