Dnssd Working Group X. Xu Internet-Draft Huawei Intended status: Standards Track May 6, 2014 Expires: November 7, 2014 DNS-SD Extensions for Service Function Discovery draft-xu-dnssd-sf-discovery-00 Abstract Service Function Chaining (SFC) [I-D.quinn-sfc-arch] provides a flexible way to construct services. When applying a particular service function chain to the traffic classified by the SFC classifier, the traffic needs to be steered through an ordered set of Service Functions (SFs) in the network. This document describes how to discover SFs in the SR network [I-D.xu-spring-sfc-use-case] based on DNS-SD [RFC6763]. Requirements Language 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]. 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 7, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Xu Expires November 7, 2014 [Page 1] Internet-Draft DNS-SD Extensions for SF Discovery May 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DNS-SD Extensions for SF Discovery . . . . . . . . . . . . . 3 3.1. Service Instance Enumeration (Browsing) . . . . . . . . . 4 3.2. Service Instance Resolution . . . . . . . . . . . . . . . 4 3.3. Data Syntax for DNS-SD TXT Records . . . . . . . . . . . 4 3.3.1. SF TXT Record . . . . . . . . . . . . . . . . . . . . 5 4. Example for SF Discovery . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Service Function Chaining (SFC) [I-D.quinn-sfc-arch] provides a flexible way to construct services. When applying a particular service function chain to the traffic classified by the SFC classifier, the traffic needs to be steered through an ordered set of Service Functions (SFs) in the network. This document describes how to discover SFs in the SR network [I-D.xu-spring-sfc-use-case] based on DNS-SD [RFC6763]. In a given SFC domain, multiple instances of a given SF can be enabled. As specified in [RFC6763], a particular SF instance can be described using a DNS SRV [RFC2782] and DNS TXT [RFC1035] record. The SRV record has a name of the form ".." and gives the target host (representing the Service Node) where the SF instance can be reached (Note that the port number given by the SRV record is meaningless in the SFC case). The DNS TXT record of the same name gives additional information (such as capacity, current load, service SID) about this SF instance, in a structured form using key/value pairs. A client discovers the list of available SF Xu Expires November 7, 2014 [Page 2] Internet-Draft DNS-SD Extensions for SF Discovery May 2014 instances of a given service type using a query for a DNS PTR [RFC1035] record with a name of the form ".". This document specifies that SF instances defined in the SFC architecture can be discovered and described using DNS-SD. This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. 2. Terminology This section contains definitions for terms used frequently throughout this document. However, many additional definitions can be found in [RFC6763] and [I-D.quinn-sfc-arch]. Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at the network layer or other OSI layers. A Service Function can be a virtual instance or be embedded in a physical network element. One of multiple Service Functions can be embedded in the same network element. Multiple instances of the Service Function can be enabled in the same administrative domain. A non-exhaustive list of Service Functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID injection, HTTP Header Enrichment functions, TCP optimizer, etc. Service Function Chain (SFC): A service function chain defines an ordered set of service functions that must be applied to packets and/or frames selected as a result of classification. SF Identifier (SF ID): A unique identifier that represents a service function within an SFC-enabled domain. Service Node (SN): Physical or virtual element that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery. SID: Segment Identifier Service SID: A locally unique SID indicating a particular service function on a service node. 3. DNS-SD Extensions for SF Discovery Xu Expires November 7, 2014 [Page 3] Internet-Draft DNS-SD Extensions for SF Discovery May 2014 3.1. Service Instance Enumeration (Browsing) The Service Instance Enumeration is same as defined in section 4 of [RFC6763]. [RFC6763] borrows the logical service-naming syntax and semantics from DNS SRV records, but adds one level of indirection. Instead of requesting records of type "SRV" with name "_ipp._tcp.example.com.", the client requests records of type "PTR" (pointer from one name to another in the DNS namespace) [RFC1035]. The result of this PTR lookup for the name "." is a set of zero or more PTR records giving Service Instance Names of the form: Service Instance Name = .. The portion of the Service Instance Name is a user- friendly name consisting of arbitrary Net-Unicode text [RFC5198]. The portion of the Service Instance Name is used to indicate SF type or SF name, such as Firewall, DPI, NAT, etc. The portion of the Service Instance Name specifies the DNS subdomain within which those names are registered. In the SFC case, the is SFC-enabled domain, such as "*.sfc.example.com". 3.2. Service Instance Resolution The Service Instance Resolution is same as defined in section 5 of [RFC6763]. When a client needs to contact a particular service function instance, identified by an SF Instance Name, previously discovered via Service Instance Enumeration (browsing), it queries for the SRV and TXT records of that name. The SRV record for an SF gives the target host name (i.e. Service Node) where the SF may be found. The TXT record gives additional information about the SF, such as capacity, current load, service SID, etc. In the SFC case, the port number is meaningless. 3.3. Data Syntax for DNS-SD TXT Records The Data Syntax for DNS-SD TXT Records is same as defined in section 6 of [RFC6763]. Some services discovered via Service Instance Enumeration may need more than just an IP address of the target host to completely identify the service instance. The necessary additional data is stored in a TXT record with the same name as the SRV record. Xu Expires November 7, 2014 [Page 4] Internet-Draft DNS-SD Extensions for SF Discovery May 2014 3.3.1. SF TXT Record The intention of SF TXT records is to convey a small amount of useful additional information about an SF instance. The TXT record below contains some general key/value pairs for an SF instance: +==========================+ | key | value | +==========================+ | ssid | service_sid | +-----------+--------------+ | capacity | max_no | +-----------+--------------+ | load | percentage | +-----------+--------------+ | status | F/T | +-----------+--------------+ | protocol | x | +-----------+--------------+ key=value: DNS TXT records to store arbitrary key/value pairs conveying additional information about the named SF instance. ssid=service_sid: The Service SID for the named SF instance. capacity=max_no: The capacity of the named SF instance. For example, this information can refer to the maximum number of binding entries that can be supported by a NAT SF. load=percentage: The current load of the named SF instance. This information may be used for load-balancing purposes for instance. This parameter may reflect the amount of active NAT entries vs. the total amount of entries. status=F/T: The status represents the availability of the named SF instance. F means false (i.e. not available), while T means True (i.e. available). protocol=x: The protocol that the named SF instance supports if it is allowed to communicated to its Policy Decision Point (PDP). The PDP is responsible for enforcing appropriate policies in SF. PDP-made policy rules can be forwarded to the SF by using a variety of protocols (e.g., NETCONF [RFC6241], Diameter [RFC3588]). The other exclusive key/value pairs pertaining to a particular kind of SF instance can be extended in the same way. This part is TBD. Xu Expires November 7, 2014 [Page 5] Internet-Draft DNS-SD Extensions for SF Discovery May 2014 4. Example for SF Discovery For example, SF1 (NAT), SF2 (Firewall) and SF3 (Load Balance) (as shown in Figure 1) are in the "sfc.example.com" domain. A client (e.g. SFC classifier or PDP) wants to discover the list of available instances of a given service type (e.g. Firewall). First, the client uses a query for a DNS PTR record with a name of the form: "." The result of this PTR lookup is a set of two PTR records giving Service Instance Names of the form: ".." ".." Secondly, the client queries for the SRV and TXT records of a particular SF instance (e.g. instance1). The SRV record for instance1 gives the target host name where this instance may be found, i.e. in this example, the target host name for ".." is Service Node 1. The TXT record gives additional information about instance1, as described in Table 1: Table 1: DNS SRV/TXT Record Pairs +------------------------+------------------------+--------------------+ | SF Instance | SRV Record | TXT Record | +------------------------+------------------------+--------------------+ |.. | Host: Service Node 1 | ssid=1000 | | | | | | | Port: Not Available | capacity=1024 | | | | | | | | load=60% | | | | | | | | status=T | | | | | | | | protocol=Diameter | +------------------------+------------------------+--------------------+ Lastly, the address of the SRV record's target host is given by the appropriate IPv6 "AAAA" address records or IPv4 "A" records. Xu Expires November 7, 2014 [Page 6] Internet-Draft DNS-SD Extensions for SF Discovery May 2014 --------------- ///----- SFC Domain -----\\\ //// \\\\ //// \\\\ // +-----+ +-----+ +-----+ +-----+ \\ // | SF1 | | SF2 | | SF2 | | SF3 | \\ | +-+---+ +--+--+ +-+---+ +--+--+ | | | | | | | | +--| +---+ +--| +---+ +--------+ | +----------+ | | | | | DNS | | |SFC| | | | | | | Server | | |Classifier| +---+-+---+ +---+-+---+ +--------+ | +----------+ | Service | | Service | | | | Node 1 | | Node 2 | | \\ +---------+ +---------+ // \\ // \\\\ //// \\\\ //// \\\----- -----/// --------------- Figure 1: SF Discovery 5. IANA Considerations TBD. 6. Security considerations This document does not introduce any new security considerations. 7. Acknowledgement TBD. 8. References 8.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. Xu Expires November 7, 2014 [Page 7] Internet-Draft DNS-SD Extensions for SF Discovery May 2014 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. 8.2. Informative References [I-D.quinn-sfc-arch] Quinn, P. and J. Halpern, "Service Function Chaining (SFC) Architecture", draft-quinn-sfc-arch-05 (work in progress), May 2014. [I-D.xu-spring-sfc-use-case] Xu, X., "Service Function Chaining Use Case", draft-xu- spring-sfc-use-case-00 (work in progress), April 2014. Author's Address Xiaohu Xu Huawei Email: xuxiaohu@huawei.com Xu Expires November 7, 2014 [Page 8]