PCE Working Group Q. Wu
Internet-Draft D. Dhody
Intended status: Experimental Huawei
Expires: June 8, 2016 D. King
Lancaster University
D. Lopez
Telefonica I+D
J. Tantsura
Ericsson
December 6, 2015
Path Computation Element (PCE) Discovery using Domain Name System(DNS)
draft-wu-pce-dns-pce-discovery-09
Abstract
Discovery of the Path Computation Element (PCE) within an IGP area or
routing domain is possible using OSPF and IS-IS IGP discovery.
However, it has been established that in certain deployment scenarios
PCEs may not wish, or be able to participate within the IGP process.
In those scenarios, it is beneficial for the Path Computation Client
(PCC) (or other PCE) to discover PCEs via an alternative mechanism to
using an IGP discovery.
This document specifies the requirements, use cases, procedures and
extensions to support PCE discovery along with certain relevant
information type and capability discovery via DNS.
Status of This Memo
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 June 8, 2016.
Wu, et al. Expires June 8, 2016 [Page 1]
Internet-Draft DNS based PCE Discovery December 2015
Copyright Notice
Copyright (c) 2015 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Outside the Routing Domain . . . . . . . . . . . . . . . 4
3.2. Discovery Mechanisms . . . . . . . . . . . . . . . . . . 5
3.2.1. Query-Response versus Advertisement . . . . . . . . . 5
3.3. PCE Virtualization . . . . . . . . . . . . . . . . . . . 6
3.4. Additional Capabilities . . . . . . . . . . . . . . . . . 6
3.4.1. Handling Changes in PCE Identities . . . . . . . . . 6
3.4.2. Secure Inter-domain Discovery . . . . . . . . . . . . 6
3.4.3. Load Sharing of Path Computation Requests . . . . . . 6
4. Extended Naming Authority Pointer ( NAPTR )Service Field
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. IETF Standards Track PCE Applications . . . . . . . . . . 8
5. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 8
6. Discovering a Path Computation Element . . . . . . . . . . . 9
6.1. Determining the PCE Service and transport protocol . . . 10
6.2. Determining the IP Address of the PCE . . . . . . . . . . 10
6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Determining the PCE domains and Neighbor PCE domains . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. IETF PCE Application Service Tags . . . . . . . . . . . . 14
7.2. PCE Application Protocol Tags . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Wu, et al. Expires June 8, 2016 [Page 2]
Internet-Draft DNS based PCE Discovery December 2015
1. Introduction
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 PCE) 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
same 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. (sec 4 of [PCE-QUESTION]).
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.
1.1. Terminology
The following terminology is used in this document.
PCE-Domain: As per [RFC4655], any collection of network elements
within a common sphere of address management or path computational
responsibility. Examples of domains include Interior Gateway
Protocol (IGP) areas and Autonomous Systems (ASs).
Domain-Name: An identification string that defines a realm of
administrative autonomy, authority, or control on the Internet.
Any name registered in the DNS is a domain name. DNS Domain names
are used in various networking contexts and application-specific
naming and addressing purposes. In general, a domain name
represents an Internet Protocol (IP) resource. Examples of DNS
domain name is "www.example.com" or "example.com" [RFC1035].
1.2. Requirements
As described in [RFC4674], the PCE Discovery information should at
least be composed of:
Wu, et al. Expires June 8, 2016 [Page 3]
Internet-Draft DNS based PCE Discovery December 2015
o The PCE location: an IPv4 and/or IPv6 address that is used to
reach the PCE. It is RECOMMENDED to use an address that is always
reachable if there is any connectivity to the PCE;
o The PCE path computation scope (i.e., inter-area, inter-AS, or
inter-layer);
o The set of one or more PCE-Domain(s) into which the PCE has
visibility and for which the PCE can compute paths;
o The set of zero, one, or more neighbor PCE-Domain(s) toward which
the PCE can compute paths;
o The set of communication and path computation-specific
capabilities.
These PCE discovery information allows PCCs to select appropriate
PCEs.
This document specifies the procedures and extension to facilitate
DNS-based PCE information discovery for specific use cases, and to
complement existing IGP discovery mechanism.
2. Conventions used in this document
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].
3. Motivation
This section discusses in more detail the motivation and use cases
for an alternative DNS-based PCE discovery mechanism.
3.1. Outside the Routing Domain
When the PCE is a router participating in the 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.
It has been identified that the existing PCE discovery mechanisms do
not work very well in following scenarios:
Inter-AS: Per domain path computation mechanism [RFC5152] or
Backward recursive path computation (BRPC) [RFC5441] MAY be used
by cooperating PCEs to compute inter-domain path. In which case
these cooperating PCEs should be known to other PCEs. In case of
Wu, et al. Expires June 8, 2016 [Page 4]
Internet-Draft DNS based PCE Discovery December 2015
inter-AS where the PCEs do not participate in a common IGP, the
existing IGP discovery mechanism cannot be used to discover inter-
AS PCE.
Hierarchy of PCE: The H-PCE [RFC6805] architecture does not require
disclosure of internals of a child domain to the parent PCE. It
may be necessary for a third party to manage the parent PCEs
according to commercial and policy agreements from each of the
participating service providers [PCE-QUESTION]. [RFC6805]
specifies that a child PCE must be configured with the address of
its parent PCE in order for it to interact with its parent PCE.
However handling changes in parent PCE identities and coping with
failure events would be an issue for a configured system. There
is no scope for parent PCEs to advertise their presence to child
PCEs when they are not a part of the same routing domain.
BGP-LS: [BGP-LS] describes a mechanism by which links state and
traffic engineering information can be collected from networks and
shared with external components using the BGP routing protocol.
An external PCE MAY use this mechanism to populate its TED and not
take part in the same IGP routing domain.
NMS/OSS: PCE MAY gain the knowledge of Topology information from
some management system (e.g.,NMS/OSS) and not take part in the
same routing domain. Also note that in some case PCC may not be a
router and instead be a management system like NMS and may not be
able to discover PCE via IGP discovery.
3.2. Discovery Mechanisms
3.2.1. Query-Response versus Advertisement
Advertisement based PCE discovery using IGP methods [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 (a PCC) can use DNS
to discover a PCE only when it needs to compute a path and does not
require any other node in the network to be involved.
In case 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 also utilize DNS-
based load-balancing and recovery functions.
Wu, et al. Expires June 8, 2016 [Page 5]
Internet-Draft DNS based PCE Discovery December 2015
3.3. PCE Virtualization
Server virtualization has gain importance since it provides better
reliability and high availability in the event of hardware failure.
It allows for higher utilization of physical resources while
improving administration by having a single management interface for
all virtual servers.
When one PCE instance is virtually hosted on a server and initiated
as a PCE instance, another PCE instance may be created on the same
server or a different server to provide better load balancing and
reliability. In such a case, where there are a large number of PCCs
that need to know these PCE instances' location, manual configuration
on PCCs for PCC and PCE relationship is not trivial or desirable.
3.4. Additional Capabilities
3.4.1. Handling Changes in PCE Identities
In the case of H-PCE ,when a dynamic Address is assigned to the
parent PCE, any existing configuration entry on child PCE becomes
invalid and the parent PCE becomes unreachable. In order to handle
changes in parent PCE identities, the DNS update can be used to
provide IP reachability to the parent PCE with new assigned Address.
The DNS update can be performed by either parent PCE or OSS/NMS that
is aware of PCE Identities changes.
3.4.2. Secure Inter-domain Discovery
Applications make use of DNS lookups on FQDN to find a node(e.g.,
PCEP endpoint). When a PCE performs DNS lookup or dynamic DNS update
with the DNS server, the PCE MUST have a security association of some
type with the DNS server. The security association SHOULD be
established either using DNSSEC [RFC4033] or TSIG/
TKEY[RFC2845][RFC2930]. DNS lookup for PCE Discovery can be applied
either within an administration domain or spanning across
administration domains. A security association is REQUIRED even if
the DNS server is in the same administrative domain as the PCE.
3.4.3. Load Sharing of Path Computation Requests
Multiple PCEs 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.
Wu, et al. Expires June 8, 2016 [Page 6]
Internet-Draft DNS based PCE Discovery December 2015
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.
4. Extended Naming Authority Pointer ( NAPTR )Service Field Format
The NAPTR service field format defined by the S-NAPTR DDDS
application in [RFC3958] follows this Augmented Backus-Naur Form
(ABNF) [RFC5234]:
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
This specification refines the "iana-registered-service" tag
definition for the discovery of PCE supporting a specific PCE
application or multiple PCE applications as defined below.
iana-registered-service =/ pce-service
pce-service = "pce" *("+" appln-name)
appln-name = non-ws-string
non-ws-string = 1*(%x21-FF)
The appln-name element is the Application Identifier used to identify
a specific PCE application. The PCE Application Name are allocated
by IANA as defined in section 8.1.
This specification also refines the "iana-registered-protocol" tag
definition for the discovery of PCE supporting a specific transport
protocol as defined below.
iana-registered-protocol =/ pce-protocol
pce-protocol = "pce." pce-transport
pce-transport = "tcp" / "tls.tcp"
Similar to application protocol tags defined in the [RFC6408],the
S-NAPTR application protocol tags defined by this specification MUST
Wu, et al. Expires June 8, 2016 [Page 7]
Internet-Draft DNS based PCE Discovery December 2015
NOT be parsed in any way by the querying application or Resolver.
The delimiter (".") is present in the tag to improve readability and
does not imply a structure or namespace of any kind. The choice of
delimiter (".") for the application protocol tag follows the format
of existing S-NAPTR application protocol tag registry entries, but
this does not imply that it shares semantics with any other
specifications that create registry entries with the same format.
The S-NAPTR application service and application protocol tags defined
by this specification are unrelated to the IANA "Service Name and
Transport Protocol Port Number Registry" (see [RFC6335]).
The maximum length of the NAPTR service field is 256 octets,
including a one-octet length field (see Section 4.1 of [RFC3403] and
Section 3.3 of [RFC1035]).
4.1. IETF Standards Track PCE Applications
A PCE Client MUST be capable of using the extended S-NAPTR
application service tag for dynamic discovery of a PCE supporting
Standards Track applications. Therefore, every IETF Standards Track
PCE application MUST be associated with a "PCE-service" tag formatted
as defined in this specification and allocated in accordance with
IANA policy (see Section 8).
For example, a NAPTR service field value of:
'PCE+gco:pce.tcp'
means that the PCE in the SRV or A/AAAA record supports the Global
Concurrent Optimization Application (See section 8.1)and the
Transport Control Protocol (TCP) as the transport protocol (See
section 8.2).
5. Backwards Compatibility
Domain Name System (DNS) administrators SHOULD also provision legacy
NAPTR records [RFC3403] in order to guarantee backwards compatibility
with legacy PCE that only support S-NAPTR DDDS application in
[RFC3958]. If the DNS administrator provisions both extended S-NAPTR
records as defined in this specification and legacy NAPTR records
defined in [RFC3403], then the extended S-NAPTR records MUST have
higher priority(e.g., lower order and/or preference values) than
legacy NAPTR records.
Wu, et al. Expires June 8, 2016 [Page 8]
Internet-Draft DNS based PCE Discovery December 2015
6. Discovering a Path Computation Element
The extended-format NAPTR records provide a mapping from a domain to
the SRV record or A/AAAA record for contacting a server supporting a
specific transport protocol and PCE application. The resource record
will contain an empty regular expression and a replacement value,
which is the SRV record or the A/AAAA record for that particular
transport protocol.
The assumption for this mechanism to work is that the DNS
administrator of the queried domain has first provisioned the DNS
with extended-format NAPTR entries.
When the PCC or other PCEs performs a NAPTR query for a server in a
particular realm, the PCC or other PCEs has to know in advance the
search path of the resolver, i.e.,in which realm to look for a PCE,
and in which Application Identifier it is interested.
The search path of the resolver can either be pre-configured, or
discovered using Diameter, DHCP or other means. For example, the
realm could be deduced from the Network Access Identifier (NAI) in
the User-Name attribute-value pair (AVP) or extracted from the
Destination-Realm AVP in Diameter [RFC6733].
When pre-configuration is used, PCE domain(e.g.,AS200)may be added as
"subdomains" of the first-level domain of the underlying service
(e.g., AS200.example.com), which allows a NAPTR query for a server in
a PCE domain associated with DNS domain-name.
When DHCP is used, it SHOULD know the domain-name of that realm and
use DHCP to discover IP address of the PCE in that realm that
provides path computation service along with some PCE location
information useful to a PCC (or other PCE) for a 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 S-NAPTR lookups [RFC3958]. If
neither the IP address nor other PCE location information can be
discovered with the above procedure, the PCC (or other PCE) MAY
request a domain search list, as described in [RFC3397] and[RFC3646],
and use it as input to the DDDS application.
When the PCC (or other PCE) does not find valid domain-names using
the mechanisms above, it MUST stop the attempt to discover any PCE.
The following procedures result in an IP address, PCE domain,
neighboring PCE domain and PCE Computation Scope where the PCC (or
other PCE) can contact the PCE that hosts the service it is looking
for.
Wu, et al. Expires June 8, 2016 [Page 9]
Internet-Draft DNS based PCE Discovery December 2015
6.1. Determining the PCE Service and transport protocol
The PCC (or other PCE) should know the service identifier for the
Path Computation service and associated transport protocol. The
service identifier for the Path Computation service is defined as
"PCE+apX" as specified in section 5, The PCE supporting "PCE" service
MUST support TCP as transport, as described in [RFC5440].
The services relevant for the task of transport protocol selection
are those with S-NAPTR service fields with values "PCE+apX:Y", where
'PCE+apX' is the service identifier defined in the previous
paragraph, and ' Y' is the letter that corresponds to a transport
protocol supported by the PCE. This document also establishes an
IANA registry for mappings of S-NAPTR service name to transport
protocol.
These NAPTR [RFC3958] records provide a mapping from a domain to the
SRV [RFC2782] record for contacting a PCE with the specific transport
protocol in the S-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 (or other PCE) MUST discard any service fields that identify
a resolution service whose value is not valid. The S-NAPTR
processing as described in [RFC3403] will result in the discovery of
the most preferred PCE that is supported by the client, as well as an
SRV record for the PCE.
6.2. Determining the IP Address of the PCE
If the returned NAPTR service fields contain entries formatted as
"pce+apX:Y" where "X" indicates the Application Identifier and "Y"
indicates the supported transport protocol(s), the target realm
supports the extended format for NAPTR-based PCE discovery defined in
this document.
o If "X" contains the required Application Identifier and "Y"
matches a supported transport protocol, the PCEP implementation
resolves the "replacement" field entry to a target host using the
lookup method appropriate for the "flags" field.
o If "X" does not contain the required Application Identifier or "Y"
does not match a supported transport protocol, the PCEP
implementation abandons the peer discovery.
Wu, et al. Expires June 8, 2016 [Page 10]
Internet-Draft DNS based PCE Discovery December 2015
If the returned NAPTR service fields contain entries formatted as
"pce+apX" where "X" indicates the Application Identifier, the target
realm supports the extended format for NAPTR-based PCE discovery
defined in this document.
o If "X" contains the required Application Identifier, the PCEP
implementation resolves the "replacement" field entry to a target
host using the lookup method appropriate for the "flags" field and
attempts to connect using all supported transport protocols.
o If "X" does not contain the required Application Identifier, the
PCEP implementation abandons the PCE discovery.
If the returned NAPTR service fields contain entries formatted as
"pce:X" where "X" indicates the supported transport protocol(s), the
target realm supports PCEP but does not support the extended format
for NAPTR-based PCE discovery defined in this document.
o If "X" matches a supported transport protocol, the PCEP
implementation resolves the "replacement" field entry to a target
host using the lookup method appropriate for the "flags" field.
If the returned NAPTR service fields contain entries formatted as
"pce", the target realm supports PCEP but does not support the
extended format for NAPTR-based PCE discovery defined in this
document. The PCEP implementation resolves the "replacement" field
entry to a target host using the lookup method appropriate for the
"flags" field and attempts to connect using TCP (in future it SHOULD
attempt all supported transport Protocols) .
Note that the regexp field in the S-NAPTR example above is empty.
The regexp field MUST NOT be used when discovering PCE, as its usage
can be complex and error prone. Also, the discovery of the PCE does
not require the flexibility provided by this field over a static
target present in the TARGET field.
As the default behavior, the client is configured with the
information about which transport protocol is used for a path
computation service in a particular domain. The client 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_PCE._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.
Wu, et al. Expires June 8, 2016 [Page 11]
Internet-Draft DNS based PCE Discovery December 2015
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.
6.2.1. Examples
As an example, consider a client that wishes to find PCED service in
the as100.example.com domain. The client performs a S-NAPTR query
for that domain, and the following NAPTR records are returned:
Order Pref Flags Service Regexp Replacement
IN NAPTR 50 50 "s" "pce:pce.tls.tcp" ""
_PCE._tcp.as100.example.com
IN NAPTR 90 50 "s" "pce:pce.tcp" ""
_PCE._tcp.as100.example.com
This indicates that the domain does have a PCE providing Path
Computation services over TCP, in that order of preference. If the
client only supports TCP, TCP will be used, targeted to a host
determined by an SRV lookup of _PCE._tcp.example.com. That lookup
would return:
;; Priority Weight Port Target
IN SRV 0 1 XXXX server1.as100.example.com
IN SRV 0 2 XXXX server2.as100.example.com
where XXXX represents the port number at which the service is
reachable.
As an alternative example, a client wishes to discover a PCE in the
ex2.example.com realm that supports the GCO application over TCP.
The client performs a NAPTR query for that domain, and the following
NAPTR records are returned:
Wu, et al. Expires June 8, 2016 [Page 12]
Internet-Draft DNS based PCE Discovery December 2015
;; order pref flags service regexp replacement
IN NAPTR 150 50 "a" "pce:pce.tcp" ""
server1.ex2.example.com
IN NAPTR 150 50 "a" "pce:pce.tls.tcp" ""
server2.ex2.example.com
IN NAPTR 150 50 "a" "pce+gco:pce.tcp" ""
server1.ex2.example.com
IN NAPTR 150 50 "a" "pce+gco:pce.tls.tcp" ""
server2.ex2.example.com
This indicates that the server supports GCO(ID=1) over TCP and TLS/
TCP via hosts server1.ex2.example.com and server2.ex2.example.com,
respectively.
6.3. Determining the PCE domains and Neighbor PCE domains
DNS servers MAY use DNS TXT record to give additional information
about PCE service and add such TXT record to the additional
information section (See section 4.1 of [RFC1035]) 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 may include path computation capability, the
PCE domains and Neighbor PCE domains associated with the PCE. If
discovery of PCE supporting a specific PCE capability described in
section 7.2 has already been performed, capability associated with
the PCE does not need to be included in the additional information.
To store new types of information, the TXT record uses a structured
format in its TXT-DATA field [RFC1035]. The format consists of the
attribute name followed by the value of the attribute. The name and
value are separated by an equals sign (=). The general syntax may
follow one defined in section 2 of [RFC1464] as follows:
<owner> <class> <ttl> TXT "<attribute name>=<attribute value>"
For example, the following TXT records contain attributes specified
in this fashion:
ex2.example.com IN TXT "pce domain = as10"
ex2.example.com IN TXT "neigh domain= as5"
ex2.example.com IN TXT "cap=link constraint"
The client MAY inspect those Additional Information section in the
DNS message and be capable of handling responses from nameservers
that never fill in the Additional Information part of a response.
Wu, et al. Expires June 8, 2016 [Page 13]
Internet-Draft DNS based PCE Discovery December 2015
7. IANA Considerations
7.1. IETF PCE Application Service Tags
IANA specifies to create a new registry ' S-NAPTR application service
tags' for existing IETF PCE applications.
+------------------+----------------------------+
| Tag | PCE Application |
+------------------+----------------------------+
| pce+gco | GCO [RFC5557] |
| pce+p2mp | P2MP [RFC5671] |
| pce+stateful | Stateful [STATEFUL-PCE] |
| pce+gmpls | GMPLS [RFC7025] |
| pce+interas | Inter-AS[RFC5376] |
| pce+interarea | Inter-Area [RFC4927] |
| pce+interlayer | Inter-layer [RFC6457] |
+------------------+----------------------------+
Future IETF PCE applications MUST reserve the S-NAPTR application
service tag corresponding to the allocated PCE Application ID as
defined in Section 3.
7.2. PCE Application Protocol Tags
IANA has reserved the following S-NAPTR Application Protocol Tags for
the PCE transport protocols in the "S-NAPTR Application Protocol Tag"
registry created by [RFC3958].
+------------------+----------+
| Tag | Protocol |
+------------------+----------+
| pce.tcp | TCP |
+------------------+----------+
Future PCE versions that introduce new transport protocols MUST
reserve an appropriate S-NAPTR Application Protocol Tag in the
"S-NAPTR Application Protocol Tag" registry created by [RFC3958].
8. Security Considerations
This document specifies an enhancement to the NAPTR service field
format. The enhancement and modifications are based on the S-NAPTR,
which is actually a simplification of the NAPTR, and therefore the
same security considerations described in [RFC3958] are applicable to
this document.
Wu, et al. Expires June 8, 2016 [Page 14]
Internet-Draft DNS based PCE Discovery December 2015
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].
However a malicious host doing S-NAPTR queries learns applications
supported by PCEs in a certain realm faster, which might help the
malicious host to scan potential targets for an attack more
efficiently when some applications have known vulnerabilities.
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.
9. Acknowledgements
The author would like to thank Claire Bi,Ning Kong, Liang Xia,
Stephane Bortzmeyer,Yi Yang, Ted Lemon, Adrian Farrel and Stuart
Cheshire for their review and comments that help improvement to this
document.
10. References
10.1. Normative References
[RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC2782] Gulbrandsen, A., "A DNS RR for specifying the location of
services (DNS SRV)", RFC 2782, February 2000.
[RFC3397] Aboba, B., "Dynamic Host Configuration Protocol (DHCP)
Domain Search Option", RFC 3397, November 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
Wu, et al. Expires June 8, 2016 [Page 15]
Internet-Draft DNS based PCE Discovery December 2015
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3958] Daigle, D. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC4033] Arends, R., "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC5440] Le Roux, JL., "Path Computation Element (PCE)
Communication Protocol (PCEP)", RFC 5440, April 2007.
[RFC6733] Fajardo, V., "Diameter Base Protocol", RFC 6733, October
2012.
10.2. Informative References
[BGP-LS] Gredler, H., "North-Bound Distribution of Link-State and
TE Information using BGP", ID draft-ietf-idr-ls-
distribution-10, January 2015.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
Wellington, "Secret Key Transaction Authentication for DNS
(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
<http://www.rfc-editor.org/info/rfc2845>.
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, DOI 10.17487/RFC2930, September 2000,
<http://www.rfc-editor.org/info/rfc2930>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4674] Droms, R., "Requirements for Path Computation Element
(PCE) Discovery", RFC 4674, December 2003.
[RFC4927] Le Roux, JL., "Path Computation Element Communication
Protocol (PCECP) Specific Requirements for Inter-Area MPLS
and GMPLS Traffic Engineering", RFC 4927, June 2007.
Wu, et al. Expires June 8, 2016 [Page 16]
Internet-Draft DNS based PCE Discovery December 2015
[RFC5088] Le Roux, JL., "OSPF Protocol Extensions for Path
Computation Element (PCE) Discovery", RFC 5088, January
2008.
[RFC5089] Le Roux, JL., "IS-IS Protocol Extensions for Path
Computation Element (PCE) Discovery", RFC 5089, January
2008.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing Inter-
Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<http://www.rfc-editor.org/info/rfc5152>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5376] Bitar, N., "Inter-AS Requirements for the Path Computation
Element Communication Protocol (PCECP)", RFC 5376,
November 2008.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.
[RFC5452] Hubert, A., "Measures for Making DNS More Resilient
against Forged Answers", RFC 5452, January 2009.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557,
July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009,
<http://www.rfc-editor.org/info/rfc5671>.
Wu, et al. Expires June 8, 2016 [Page 17]
Internet-Draft DNS based PCE Discovery December 2015
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter
Straightforward-Naming Authority Pointer (S-NAPTR) Usage",
RFC 6408, DOI 10.17487/RFC6408, November 2011,
<http://www.rfc-editor.org/info/rfc6408>.
[RFC6457] Takeda, T., "PCC-PCE Communication and PCE Discovery
Requirements for Inter-Layer Traffic Engineering",
RFC 6457, June 2007.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, December
2012.
[RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS", RFC 6805, November
2012.
[RFC7025] Otani, T., "Requirements for GMPLS Applications of PCE",
RFC 7025, September 2013.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014,
<http://www.rfc-editor.org/info/rfc7399>.
[STATEFUL-PCE]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", ID draft-ietf-pce-stateful-
pce-11, April 2015.
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: sunseawq@huawei.com
Wu, et al. Expires June 8, 2016 [Page 18]
Internet-Draft DNS based PCE Discovery December 2015
Dhruv Dhody
Huawei
Leela Palace
Bangalore, Karnataka 560008
INDIA
Email: dhruv.dhody@huawei.com
Daniel King
Lancaster University
UK
Email: daniel@olddog.co.uk
Diego R. Lopez
Telefonica I+D
Email: diego@tid.es
Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
US
Email: Jeff.Tantsura@ericsson.com
Wu, et al. Expires June 8, 2016 [Page 19]