Internet DRAFT - draft-xu-dnssd-sf-discovery
draft-xu-dnssd-sf-discovery
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 "<Instance>.<Service>.<Domain>"
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
"<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.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 "<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 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:
"<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 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 |
+------------------------+------------------------+--------------------+
|<instance1>.<firewall>. | Host: SFF 1 | sfsid=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, 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, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
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,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<http://www.rfc-editor.org/info/rfc3022>.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588,
DOI 10.17487/RFC3588, September 2003,
<http://www.rfc-editor.org/info/rfc3588>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<http://www.rfc-editor.org/info/rfc5198>.
[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, <http://www.rfc-editor.org/info/rfc6146>.
[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,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
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]
