Dnssd Working Group X. Xu Internet-Draft J. You Intended status: Standards Track Huawei Expires: March 3, 2016 R. Raszuk Individual August 31, 2015 DNS-SD Extensions for Service Function Discovery draft-xu-dnssd-sf-discovery-02 Abstract Service Function Chaining provides a flexible way to construct services. When applying a particular Service Function Chain (SFC) 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 SPRING networks based on DNS-SD. 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 March 3, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Xu, et al. Expires March 3, 2016 [Page 1] Internet-Draft DNS-SD Extensions for SF Discovery August 2015 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 . . . . . . . . . . . . . 4 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Service Function Chaining [I-D.ietf-sfc-architecture] 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 SPRING networks (a.k.a. Segment Routing networks, SR networks) [I-D.xu-sfc-using-mpls-spring] 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 Function Forwarder) 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 function SID) about this SF instance, Xu, et al. Expires March 3, 2016 [Page 2] Internet-Draft DNS-SD Extensions for SF Discovery August 2015 in a structured form using key/value pairs. A client discovers the list of available SF 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.ietf-sfc-architecture]. Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a Service Function can be realized as a virtual element or be embedded in a physical network element. One or more Service Functions can be embedded in the same network element. Multiple occurrences of the Service Function can exist in the same administrative domain. Service Function Chain (SFC): A service function chain defines a set of abstract service functions and ordering constraints 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 Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. SID: Segment Identifier Service Function SID: A locally unique SID indicating a particular service function on an SFF. Xu, et al. Expires March 3, 2016 [Page 3] Internet-Draft DNS-SD Extensions for SF Discovery August 2015 3. DNS-SD Extensions for SF Discovery 3.1. Service Instance Enumeration (Browsing) The Service Instance Enumeration is the 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 Function Forwarder) where the SF may be found. The TXT record gives additional information about the SF, such as capacity, current load, service function 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, et al. Expires March 3, 2016 [Page 4] Internet-Draft DNS-SD Extensions for SF Discovery August 2015 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 | +====================================+ | sfsid | service_function_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. sfsid=service_function_sid: The Service Function 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, et al. Expires March 3, 2016 [Page 5] Internet-Draft DNS-SD Extensions for SF Discovery August 2015 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 SFF 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: SFF 1 | sfsid=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, et al. Expires March 3, 2016 [Page 6] Internet-Draft DNS-SD Extensions for SF Discovery August 2015 --------------- ///----- SFC Domain -----\\\ //// \\\\ //// \\\\ // +-----+ +-----+ +-----+ +-----+ \\ // | SF1 | | SF2 | | SF2 | | SF3 | \\ | +-+---+ +--+--+ +-+---+ +--+--+ | | | | | | | | +--| +---+ +--| +---+ +--------+ | +----------+ | | | | | DNS | | |SFC | | | | | | Server | | |Classifier| +---+-+---+ +---+-+---+ +--------+ | +----------+ | | | | | | | SFF 1 | | SFF 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, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Xu, et al. Expires March 3, 2016 [Page 7] Internet-Draft DNS-SD Extensions for SF Discovery August 2015 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, DOI 10.17487/RFC3588, September 2003, . [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, 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, DOI 10.17487/RFC6146, April 2011, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . 8.2. Informative References [I-D.ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture-11 (work in progress), July 2015. [I-D.xu-sfc-using-mpls-spring] Xu, X., Li, Z., Shah, H., and L. Contreras, "Service Function Chaining Using MPLS-SPRING", draft-xu-sfc-using- mpls-spring-03 (work in progress), March 2015. Xu, et al. Expires March 3, 2016 [Page 8] Internet-Draft DNS-SD Extensions for SF Discovery August 2015 Authors' Addresses Xiaohu Xu Huawei Email: xuxiaohu@huawei.com Jianjie You Huawei 101 Software Avenue, Yuhuatai District Nanjing, 210012 China Email: youjianjie@huawei.com Robert Raszuk Individual Email: robert@raszuk.net Xu, et al. Expires March 3, 2016 [Page 9]