Internet DRAFT - draft-zheng-sdn-discovery
draft-zheng-sdn-discovery
Network Working Group L. Zheng
Internet-Draft Huawei Technologies
Intended status: Standards Track Y. Zhang
Expires: January 10, 2013 China Mobile Communication
Corporation
July 9, 2012
SDN Discovery
draft-zheng-sdn-discovery-00.txt
Abstract
In SDN networks, applications need to discover the location of the
local or specific SDN Orchestrator before requesting service. Other
SDN Orchestrator may also need to know its nearby SDN Orchestrators.
This is called SDN Discovery. This document introduces a discovery
scheme which employs the U-NAPTR mechanism to determine the URI of
the SDN Orchestrator.
Zheng & Zhang Expires January 10, 2013 [Page 1]
Internet-Draft SDN Discovery July 2012
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 RFC 2119 [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 January 10, 2013.
Copyright Notice
Copyright (c) 2012 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.
Zheng & Zhang Expires January 10, 2013 [Page 2]
Internet-Draft SDN Discovery July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Discovery Scenario . . . . . . . . . . . . . . . . . . . . . . 5
2.1. SDN Model . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Discovery Scenario . . . . . . . . . . . . . . . . . . . . 7
3. SDN Orchestrator Directory . . . . . . . . . . . . . . . . . . 8
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Retrieving the Domain Name . . . . . . . . . . . . . . . . 9
4.2. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Zheng & Zhang Expires January 10, 2013 [Page 3]
Internet-Draft SDN Discovery July 2012
1. Introduction
Modern applications require the ability to efficently interact and
manipulate resources provisioned and controlled by networks.
Software Driven Networks (SDN) is an approach to networks that
enables applications to manipulate the network devices and resources.
Applications can benefit from knowing the available resources and
from requesting that the network makes the resources available in
specific ways.
Applications need to know the location of the local or specific SDN
Orchestrator before requesting service, other SDN Orchestrator may
also need to know its nearby SDN Orchestrators. In the real world,
the applications/SDN Orchestrators might not know where the SDN
Orchestrator is in the network, the location/address of SDN
Orchestrator may change time to time. The locationo of SDN
Orchestrator could be either manually configured or dynamically
discovered. This document introduces a discovery scheme which
employs the U-NAPTR mechanism to determine the URI of the SDN
Orchestrator. We call both Application or SDN Orchestrator who
requesting the discovery service as Discovery Client in this
document.
As defined by this document, by querying the SDN Discovery Server,
Discovery Client discover and retrieve HTTP(S) URI of the SDN
Orchestrator Directory. The SDN Orchestrator Directory indicates the
location/address of SDN Orchestrator, and gives the further
information about the capabilities and services provided by that SDN
Orchestrator. An SDN Orchestrator MUST make an SDN Orchestrator
Directory available via the HTTP GET method to a URI discoverable by
Discovery Client.
Zheng & Zhang Expires January 10, 2013 [Page 4]
Internet-Draft SDN Discovery July 2012
2. Discovery Scenario
2.1. SDN Model
Managing a SDN network involves interactions among different
functions and components within the network. The SDN model is shown
in Figure 1. Among these interfaces/interactions, SDN Orchestratort-
to-location services Interface allows the SDN Orchestrator to
interconnect with location services. This allow the SDN Orchestrator
to register itself as a local Orchestrator, and allow other
Orchestrators and applications to find it.
Zheng & Zhang Expires January 10, 2013 [Page 5]
Internet-Draft SDN Discovery July 2012
|--------Application
v ^
+----------+ |
| Location | | <--- Application-to-
| Services | | Ochestrator protocol
+----------+ v
^ ReST API
| +-------------------+ +------------------+
|----| Orchestrator_0..N + -----> | Policy Data Base |
+-------------------+ +------------------+
^
| <--- Orchestrator-to-Plug-In Protocol
|
V
+----------+
| Plug-In |
| ReST API |
+----------+
^
*
V
+******************+
* Control Software *
* For Device_0..M *
+******************+
^
=
V
+=================+
= Data Plane =
= For Device_0..M =
+=================+
<--> interfaces and objects inside the scope of SDN
+--+
<**> interfaces and objects may be within the scope of SDN
+**+ insofar as modifcations are needed to support SDN
<==> interfaces and objects outside the scope of SDN
+==+
Figure 1 SDN Model
Zheng & Zhang Expires January 10, 2013 [Page 6]
Internet-Draft SDN Discovery July 2012
2.2. Discovery Scenario
+-------------------+ +------------------+
| Applications + 000000>| Orchestrator |
|(Discovery Client) | | Discovery Server |
+-------------------+ +------------------+
^ ^ ^
Application-to- - > | * 0
Ochestrator protocol | * 0
v * 0
ReST API * 0
+-------------------+ * +----+-------------+
| Orchestrator + ************ | Orchestrator |
+-------------------+ |(Discovery Client)|
^ +------------------+
| <- Orchestrator-to-Plug-In Protocol ^
| |
V V
0000000> SDN Discovery
*******> SDN Register
Figure 2 Discovery Scenario
Figure 2 above shows an overview on the different entities and
scenario of SDN Discovery. We call both Application or SDN
Orchestrator who requesting the discovery service as Discovery Client
in this document.The SDN Discovery mechanism is used by the Discovery
Client in order to discover and retrieve HTTP(S) URI of the SDN
Orchestrator Directory.
Zheng & Zhang Expires January 10, 2013 [Page 7]
Internet-Draft SDN Discovery July 2012
3. SDN Orchestrator Directory
A SDN Orchestrator Directory indicates to Discovery Clients the
location/address of SDN Orchestrator, and gives the further
information about the capabilities and services provided by that SDN
Orchestrator. The format of the SDN Orchestrator Directory need to
be carefully designed for scalibility, the services provided by SDN
Orchestrator need to be well named and classified. Further study is
centainly required on this. An SDN Orchestrator MUST make an SDN
Orchestrator Directory available via the HTTP GET method to a URI
discoverable by Discovery Client.
Zheng & Zhang Expires January 10, 2013 [Page 8]
Internet-Draft SDN Discovery July 2012
4. Protocol Overview
This document introduce the U-NAPTR based resolution process to
retrieve the SDN Orchestrator URL. To discover available SDN
Orchestrator, a Discovery Client need to send an U-NAPTR request to
SDN Discovery Sever, to retrieve the HTTP(S) URI of the SDN
Orchestrator Directory. Instead of using the SDN Orchestrator
discovery mechnism introduced in this document, applications MAY also
use own methods to discover an SDN Orchestrator which is outside the
scope of this document.
4.1. Retrieving the Domain Name
The U-NAPTR process needs the right domain name as input (Application
Unique String). When Discovery Client need to discover its local SDN
Orchestrator, the domain name could be determined by the IP address
of the Discovery Client and the DNS suffix of the access network
where the Discovery Client is registered in. In the case of
discovering the specific SDN Orchestrators, e.g. SDN Orchestrators
belong to specific service provider, the domain name could be a
specific well-known domain name.
In order to retrieve the DNS suffix, three different options could be
applied. The DNS suffix could be determined by user input, DHCP or
reverse DNS, in descending order of preference. A Discovery Client
MAY try other methods in case the first U-NAPTR lookup failed. The
details of DNS suffix retrieving by these three different options
will be elaborated in future version of the document.
4.2. U-NAPTR Resolution
The first step of the SDN Discovery procedure (see Section 4.1)
yielded an U-NAPTR/DDDS [RFC4848] [RFC4848]application unique
strings, in the form of a DNS name. An example is "localsdn.com".
In this second step, the SDN Discovery procedure needs to use the
U-NAPTR [RFC4848] [RFC4848]specification described below to obtain a
URI for the SDN Orchestrator Directory. In this document, only the
HTTP and HTTPS URL schemes are defined.
The following two DNS entries show the U-NAPTR resolution for
"localsdn.com" to the HTTPS URL
https://sdnorchestrator.localsdn.com/secure/directory or the HTTP URL
http://sdnorchestrator.localsdn.com/directory, with the former being
preferred.
localsdn.com.
;; order pref flags
Zheng & Zhang Expires January 10, 2013 [Page 9]
Internet-Draft SDN Discovery July 2012
IN NAPTR 100 10 "u" "SDN:https"
"!.*!https://sdnorchestrator.localsdn.com/secure/directory!" ""
IN NAPTR 200 10 "u" "SDN:http"
"!.*!http://sdnorchestrator.localsdn.com/directory!" ""
There is a potential that the U-NAPTR lookup does not yield to a
result, i.e. no SDN NAPTR record is found. In this case the
discovery procedure failed for this application unique string. It is
RECOMMENDED that the Discovery Client wait a period of time before
repeating the procedure. Discovery Clients MAY repeat the discovery
procedure for a different application unique string instantaneously.
Zheng & Zhang Expires January 10, 2013 [Page 10]
Internet-Draft SDN Discovery July 2012
5. Security Considerations
TBA as document develops.
Zheng & Zhang Expires January 10, 2013 [Page 11]
Internet-Draft SDN Discovery July 2012
6. IANA Considerations
IANA maintains a registry of U-NAPTR application service and protocol
tags. This document requests IANA to assign a U-NAPTR application
service tag.
Application Service Tag: SDN
Defining Publication: The specification contained within this
document.
This document does not request IANA to assign new protocol tag.
Zheng & Zhang Expires January 10, 2013 [Page 12]
Internet-Draft SDN Discovery July 2012
7. Acknowledgements
TBA
Zheng & Zhang Expires January 10, 2013 [Page 13]
Internet-Draft SDN Discovery July 2012
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
8.2. References
8.3. Informative References
[I-D.nadeau-sdn-problem-statement]
Nadeau, T. and P. Pan, "Software Driven Networks Problem
Statement", draft-nadeau-sdn-problem-statement-01 (work in
progress), October 2011.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)",
RFC 3404, October 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
Zheng & Zhang Expires January 10, 2013 [Page 14]
Internet-Draft SDN Discovery July 2012
Authors' Addresses
Lianshu Zheng
Huawei Technologies
China
Email: vero.zheng@huawei.com
Yunfei Zhang
China Mobile Communication Corporation
China
Email: zhangyunfei@chinamobile.com
Zheng & Zhang Expires January 10, 2013 [Page 15]
