| PCE Working Group | Q. Wu |
| Internet-Draft | D. Dhody |
| Intended status: Standards Track | Huawei |
| Expires: February 13, 2014 | D. King |
| Old Dog Consulting | |
| D. Lopez | |
| Telefonica I+D | |
| August 12, 2013 |
Path Computation Element (PCE) Discovery using Domain Name System(DNS)
draft-wu-pce-dns-pce-discovery-02
Discovery of the Path Computation Element (PCE) within an IGP area or routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089]. However, in some deployment scenarios PCEs may not wish, or be able, to participate within the IGP process, therefore it would be beneficial for the Path Computation Client (PCC) (or other PCEs) to discover PCEs via an alternative mechanism to those proposed in [RFC5088] and [RFC5089].
This document specifies the requirements, use cases, procedures and extensions to support discovery via DNS for PCE.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 13, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Path Computation Element Communication Protocol (PCEP) is a transaction-based protocol carried over TCP [RFC4655]. In order to be able to direct path computation requests to the Path Computation Element (PCE), a Path Computation Client (PCC) (or other PCEs) needs to know the location and capability of a PCE.
In a network where an IGP is used and where the PCE participates in the IGP, discovery mechanisms exist for PCC (or PCE) to learn the identity and capability of each PCE. [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF Router LSA. Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE Discovery using IS-IS. Scope of the advertisement is limited to IGP area/level or Autonomous System (AS).
However in certain scenarios not all PCEs will participate in the IGP instance, section 3 (Motivation) outlines a number of use cases. In these cases, current PCE Discovery mechanisms are therefore not appropriate and another PCE discovery function would be required.
This document describes PCE discovery via DNS. The mechanism with which DNS comes to know about the PCE and its capability is out of scope of this document.
The following terminology is used in this document.
As described in [RFC4674], the PCE Discovery information should at least be composed of:
that allows PCCs to select appropriate PCEs:
This document specifies an extension to DNS for the above PCE information discovery, which is complements the existing discovery mechanism.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119].
This section discusses in more detail the motivation and use cases for an alternative DNS based PCE discovery mechanism.
When the PCE is a router participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, with all PCEP speakers in the same routing domain, a simple and efficient way to announce PCEs consists of using IGP flooding.
But the existing mechanism does not work in following situations:
Advertisement based IGP PCE discovery [RFC5088] and [RFC5089] floods the PCE information to an area, a subset of areas or to a full routing domain. By the very nature of flooding and advertisements it generates unwanted traffic and may lead to unnecessary advertisement, especially when PCE information needs frequent changes.
DNS is a query-response based mechanism, a client (say PCC) can use DNS to discover a PCE only when it needs it and does not require any other node in the network to be involved.
Incase of Intermittent PCEP session, where PCEP sessions are systematically open and closed for each PCEP request, a DNS based query-response mechanism is more suitable. One may utilize DNS based load-balancing and recovery functions.
PCEP uses TCP as the transport [RFC5440]. To secure TCP connection that underlay PCEP sessions, TLS can be used besides using TCP-MD5 [RFC2385] and TCP-AUTH [RFC5295]. When PCC and PCE support TCP-MD5 or TCP-AUTH while NAT does not, TCP connection establishment fails. When NAT gateway is in presence, a TCP or TCP/TLS connection can be opened by Interactive Connectivity Establishment (ICE) [RFC5245] for the purpose of connectivity checks. However the TCP connection cannot be established in cases where one of the peers is behind a NAT with connection-dependent filtering properties [RFC5382]. Therefore IGP discovery is limited within an IGP domain and cannot be used in this case.
Multiple PCE servers can be present in a single network domain for redundancy. DNS supports inherent load balancing where multiple PCEs (with different IP addresses) are known in DNS for a single PCE server name and are hidden from the PCC.
In an IGP advertisement based PCE discovery, one learns of all the PCEs and it is the job of the PCC to do load-balancing.
A DNS based load-balancing mechanism works well in case of Intermittent PCEP sessions and request are load-balanced among PCEs similar to HTTP request without any complexity at the client.
The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS database by iteratively applying string transformation rules until a terminal condition is reached. When DDDS uses DNS as a distributed database of rules, these rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). One of these rules is the First Well Known Rule, which says where the process starts.
In current specifications, the First Well Known Rule in a DDDS application [RFC3403] is assumed to be fixed, i.e., the domain in the tree where the lookups are to be routed to, is known. This document proposes the input to the First Well Known Rule to be dynamic, based on the search path the resolver discovers or is configured to use.
The search path of the resolver can either be pre-configured, or discovered using DHCP.
When the PCC or other PCEs needs to discover PCEs in the domain into which the PCEP speaker has visibility (e.g.,local domain), the input to the First Well Known Rule MUST be the domain the PCC knows, which is assumed to be pre-configured in the PCC or discovered using DHCP.
When the PCC needs to discover PCE in the other domain (e.g., AS, Parent PCE in the parent domain)into which the PCC has no visibility, it SHOULD know the domain name of that domain and use DHCP to discover IP address of the PCE in that domain that provides path computation service along with some PCE location information useful to a PCC for PCE selection, and contact it directly. In some instances, the discovery may result in a per protocol/application list of domain names that are then used as starting points for the subsequent NAPTR lookups. If neither the IP address nor other PCE location information can be discovered with the above procedure, the PCC MAY request a domain search list, as described in [RFC3397] and [RFC3646], and use it as input to the DDDS application.
When the PCC does not find valid domain names using the procedures above, it MUST stop the attempt to discover any PCE.
The dynamic rule described above SHOULD NOT be used for discovering services other than Path computation services described in this document, unless stated otherwise by a future specification.
The procedures defined here result in an IP address, PCE domain, neighboring PCE domain and PCE Computation Scope where the PCC can contact the PCE that hosts the service the PCC is looking for.
The PCC should know the service identifier for the Path Computation Discovery service. The service identifier for the Path Computation Discovery service is defined as "PCED", The PCE supporting "PCED" service MUST support only TCP as transport, as described in [RFC5440].
The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "ID+M2X", where ID is the service identifier defined in the previous section, and X is a letter that corresponds to a transport protocol supported by the domain. This specification only defines M2T for TCP. This document also establishes an IANA registry for mappings of NAPTR service name to transport protocol.
These NAPTR [RFC3403] records provide a mapping from a domain to the SRV [RFC2782] record for contacting a PCE with the specific transport protocol in the NAPTR services field. The resource record MUST contain an empty regular expression and a replacement value, which indicates the domain name where the SRV record for that particular transport protocol can be found. As per [RFC3403], the client discards any records whose services fields are not applicable.
The PCC MUST discard any service fields that identify a resolution service whose value is not "M2T", for values of T that indicate TCP transport protocols supported by the client. The NAPTR processing as described in RFC 3403 will result in the discovery of the most preferred transport protocol of the PCE that is supported by the client, as well as an SRV record for the PCE.
Order Pref Flags Service Regexp Replacement IN NAPTR 50 50 "s" "PCED" "" _PCED._tcp.example.com IN NAPTR 90 50 "s" "PCED+M2T" "" _PCED._tcp.example.com
As an example, consider a client that wishes to find PCED service in the example.com domain. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
;; Priority Weight Port Target IN SRV 0 1 XXXX server1.example.com IN SRV 0 2 XXXX server2.example.com
This indicates that the domain does have a PCE providing Path Computation services over TCP, in that order of preference. Since the client only supports TCP, TCP will be used, targeted to a host determined by an SRV lookup of _PCED._tcp.example.com. That lookup would return:
where XXXX represents the port number at which the service is reachable.
Note that the regexp field in the NAPTR example above is empty. The regexp field MUST NOT be used when discovering path computation services, as its usage can be complex and error prone. Also, the discovery of the path computation service does not require the flexibility provided by this field over a static target present in the TARGET field.
If the client is already configured with the information about which transport protocol is used for a path computation service in a particular domain, it can directly perform an SRV query for that specific transport using the service identifier of the path computation Service. For example, if the client knows that it should be using TCP for path computation service, it can perform a SRV query directly for_PCED._tcp.example.com.
Once the server providing the desired service and the transport protocol has been determined, the next step is to determine the IP address.
According to the specification of SRV RRs in [RFC2782], the TARGET field is a fully qualified domain name (FQDN) that MUST have one or more address records; the FQDN must not be an alias, i.e., there MUST NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query already has reported a sufficient number of these address records in the Additional Data section of the DNS response (as recommended by [RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) of the domain name, as appropriate. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously.
DNS servers MAY use DNS TXT record to give additional information about PCE service and add TXT record to the additional information section that are relevant to the answer and have the same authenticity as the data (Generally this will be made up of A and SRV records)in the answer section. The additional information includes path computation scope, capability, the PCE domains and Neighbor PCE domains associated with the PCE. the PCC MAY inspect those Additional Information section and be capable of handling responses from nameservers that never fill in the Additional Information part of a response.
As per [RFC4655], PCE-Domain is a collection of network elements within a common sphere of address management or path computational responsibility. Examples of PCE-domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASs). The DNS domain-name should have a mechanism to link the IGP area or AS to the DNS namespace.
Editors Note - To be discussed further
The usage of NAPTR records described here requires well-known values for the service fields for the transport supported by Path Computation Services. The table of mappings from service field values to transport protocols is to be maintained by IANA.
Service Field: The service field being registered. Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with reference to a document that describes the transport protocol. Name and Contact Information: The name, address, email address, and telephone number for the person performing the registration.
The registration in the RFC MUST include the following information:
Service Fields Protocol PCED+M2T TCP
The following values have been placed into the registry:
New Service Fields are to be added via Standards Action as defined in [RFC5226].
IANA is also requested to register PCED as service name in the Protocol and Service Names registry.
It is believed that this proposed DNS extension introduces no new security considerations (i.e., A list of known threats to services using DNS) beyond those described in [RFC3833]. For most of those identified threats, the DNS Security Extensions [RFC4033] does provide protection. It is therefore recommended to consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational Practices [RFC6781] when deploying Path Computation Services.
In deployments where DNSSEC usage is not feasible, measures should be taken to protect against forged DNS responses and cache poisoning as much as possible. Efforts in this direction are documented in [RFC5452].
Where inputs to the procedure described in this document are fed via DHCP, DHCP vulnerabilities can also cause issues. For instance, the inability to authenticate DHCP discovery results may lead to the Path Computation service results also being incorrect, even if the DNS process was secured.
The author would like to thank Claire Bi,Ning Kong, Liang Xia, Stephane Bortzmeyer,Yi Yang, Ted Lemon and Adrian Farrel for their review and comments that help improvement to this document.