DNS-SD Extensions for Service Function Discovery
draft-xu-dnssd-sf-discovery-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Xiaohu Xu | ||
| Last updated | 2014-05-06 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xu-dnssd-sf-discovery-00
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 "<Instance>.<Service>.<Domain>"
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 "<Service>.<Domain>".
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 "<Service>.<Domain>" is a
set of zero or more PTR records giving Service Instance Names of the
form:
Service Instance Name = <Instance>.<Service>.<Domain>
The <Instance> portion of the Service Instance Name is a user-
friendly name consisting of arbitrary Net-Unicode text [RFC5198].
The <Service> portion of the Service Instance Name is used to
indicate SF type or SF name, such as Firewall, DPI, NAT, etc.
The <Domain> portion of the Service Instance Name specifies the DNS
subdomain within which those names are registered. In the SFC case,
the <Domain> 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:
"<firewall>.<sfc.example.com>"
The result of this PTR lookup is a set of two PTR records giving
Service Instance Names of the form:
"<instance1>.<firewall>.<sfc.example.com>"
"<instance2>.<firewall>.<sfc.example.com>"
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
"<instance1>.<firewall>.<sfc.example.com >" 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 |
+------------------------+------------------------+--------------------+
|<instance1>.<firewall>. | Host: Service Node 1 | ssid=1000 |
|<sfc.example.com> | | |
| | 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]