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]