[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10

PCE Working Group                                                  Q. Wu
Internet-Draft                                                  D. Dhody
Intended status: Standards Track                                  Huawei
Expires: November 10, 2014                                       D. King
                                                      Old Dog Consulting
                                                                D. Lopez
                                                          Telefonica I+D
                                                             J. Tantsura
                                                                Ericsson
                                                             May 9, 2014


 Path Computation Element (PCE) Discovery using Domain Name System(DNS)
                   draft-wu-pce-dns-pce-discovery-06

Abstract

   Discovery of the Path Computation Element (PCE) within an IGP area or
   routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089].
   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
   those proposed in [RFC5088] and [RFC5089].

   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 November 10, 2014.

Copyright Notice




Wu, et al.              Expires November 10, 2014               [Page 1]


Internet-Draft               DNS based PCED                     May 2014


   Copyright (c) 2014 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  . . . . . . . . . . . . . .  5
   3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Outside the Routing Domain . . . . . . . . . . . . . . . .  6
     3.2.  Discovery Mechanisms . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  Query-Response versus Advertisement  . . . . . . . . .  7
     3.3.  PCE Virtualization . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Additional Capabilities  . . . . . . . . . . . . . . . . .  7
       3.4.1.  Handling Changes in PCE Identities . . . . . . . . . .  7
       3.4.2.  Secure Inter-domain Discovery  . . . . . . . . . . . .  8
       3.4.3.  Load Sharing of Path Computation Requests  . . . . . .  8
   4.  Extended Naming Authority Pointer ( NAPTR )Service Field
       Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  IETF Standards Track PCE Applications  . . . . . . . . . . 10
   5.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 11
   6.  Discovering a Path Computation Element . . . . . . . . . . . . 12
     6.1.  Determining the PCE Service and transport protocol . . . . 13
     6.2.  Determining the IP Address of the PCE  . . . . . . . . . . 13
       6.2.1.  Examples . . . . . . . . . . . . . . . . . . . . . . . 15
     6.3.  Determining the PCE domains and Neighbor PCE domains . . . 16
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
     7.1.  IETF PCE Application Service Tags  . . . . . . . . . . . . 17
     7.2.  PCE Application Protocol Tags  . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23




Wu, et al.              Expires November 10, 2014               [Page 2]


Internet-Draft               DNS based PCED                     May 2014


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 November 10, 2014               [Page 3]


Internet-Draft               DNS based PCED                     May 2014


   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.





























Wu, et al.              Expires November 10, 2014               [Page 4]


Internet-Draft               DNS based PCED                     May 2014


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].














































Wu, et al.              Expires November 10, 2014               [Page 5]


Internet-Draft               DNS based PCED                     May 2014


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
      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.





Wu, et al.              Expires November 10, 2014               [Page 6]


Internet-Draft               DNS based PCED                     May 2014


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.

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.





Wu, et al.              Expires November 10, 2014               [Page 7]


Internet-Draft               DNS based PCED                     May 2014


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.

   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.


























Wu, et al.              Expires November 10, 2014               [Page 8]


Internet-Draft               DNS based PCED                     May 2014


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
   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



Wu, et al.              Expires November 10, 2014               [Page 9]


Internet-Draft               DNS based PCED                     May 2014


   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).






















Wu, et al.              Expires November 10, 2014              [Page 10]


Internet-Draft               DNS based PCED                     May 2014


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 November 10, 2014              [Page 11]


Internet-Draft               DNS based PCED                     May 2014


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)can 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 November 10, 2014              [Page 12]


Internet-Draft               DNS based PCED                     May 2014


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.

   If the returned NAPTR service fields contain entries formatted as



Wu, et al.              Expires November 10, 2014              [Page 13]


Internet-Draft               DNS based PCED                     May 2014


   "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 November 10, 2014              [Page 14]


Internet-Draft               DNS based PCED                     May 2014


   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 November 10, 2014              [Page 15]


Internet-Draft               DNS based PCED                     May 2014


          ;;        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 November 10, 2014              [Page 16]


Internet-Draft               DNS based PCED                     May 2014


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].














Wu, et al.              Expires November 10, 2014              [Page 17]


Internet-Draft               DNS based PCED                     May 2014


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.

   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.






















Wu, et al.              Expires November 10, 2014              [Page 18]


Internet-Draft               DNS based PCED                     May 2014


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.













































Wu, et al.              Expires November 10, 2014              [Page 19]


Internet-Draft               DNS based PCED                     May 2014


10.  References

10.1.  Normative References

   [RFC1035]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
              SPECIFICATION", RFC 1035, November 1987.

   [RFC1464]  Rosenbaum, R., "Using the Domain Name System To Store
              Arbitrary String Attributes", RFC 1464, May 1993.

   [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.

   [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.

   [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.

   [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.

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,



Wu, et al.              Expires November 10, 2014              [Page 20]


Internet-Draft               DNS based PCED                     May 2014


              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.

10.2.  Informative References

   [ALTO]     Kiesel, S., "ALTO Server Discovery",
              ID draft-ietf-alto-server-discovery-22, December 2013.

   [BGP-LS]   Gredler, H., "North-Bound Distribution of Link-State and
              TE Information using BGP",
              ID draft-ietf-idr-ls-distribution-04, November 2013.

   [PCE-QUESTION]
              Farrel, A., "Unanswered Questions in the Path Computation
              Element Architecture",
              ID http://tools.ietf.org/html/draft-ietf-pce-questions-00,
              July 2013.

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

   [RFC4927]  Le Roux, JL., "Path Computation Element Communication
              Protocol (PCECP) Specific Requirements for Inter-Area MPLS
              and GMPLS Traffic Engineering", RFC 4927, June 2007.

   [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.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

   [RFC5295]  Touch, J., "The TCP Authentication Option", RFC 5295,
              June 2010.

   [RFC5376]  Bitar, N., "Inter-AS Requirements for the Path Computation
              Element Communication Protocol (PCECP)", RFC 5376,
              November 2008.



Wu, et al.              Expires November 10, 2014              [Page 21]


Internet-Draft               DNS based PCED                     May 2014


   [RFC5382]  Guha, S., "NAT Behavioral Requirements for TCP", RFC 5382,
              October 2008.

   [RFC5452]  Hubert, A., "Measures for Making DNS More Resilient
              against Forged Answers", RFC 5452, January 2009.

   [RFC6457]  Takeda, T., "PCC-PCE Communication and PCE Discovery
              Requirements for Inter-Layer Traffic Engineering",
              RFC 6457, June 2007.

   [RFC7025]  Otani, T., "Requirements for GMPLS Applications of PCE",
              RFC 7025, September 2013.







































Wu, et al.              Expires November 10, 2014              [Page 22]


Internet-Draft               DNS based PCED                     May 2014


Authors' Addresses

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: sunseawq@huawei.com


   Dhruv Dhody
   Huawei
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   Email: dhruv.dhody@huawei.com


   Daniel King
   Old Dog Consulting
   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 November 10, 2014              [Page 23]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/