INTERNET-DRAFT Mingui Zhang Intended Status: Informational Jie Dong Mach Chen Huawei Expires: January 21, 2016 July 20, 2015 GEARS: Generic and Extensible Architecture for Protocols draft-zhang-generic-extensible-protocol-platform-00.txt Abstract In the Cloud computing era, lots of protocols are proposed to meet the various requirements requested by the quickly emerging Cloud applications. However, protocols used to be independently developed by closed communities. Each protocol proposes its own specifications and encoding method. Some common functions are repeatedly developed by different protocols. The way that the protocols used to be developed significantly prolongs the process that protocols are brought to the real market. In order to address these problems, this document proposes GEARS (Generic and Extensible Architecture for pRotocolS) which provides an open platform to facilitate protocol innovations. A new protocol would be developed as an application running on this platform while those common functions provided by this platform can be reused. Customized features of this application can be easily built as add- ons with the friendly and extensible data modeling language. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Mingui Zhang Expires January 21, 2016 [Page 1] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 Copyright and License Notice Copyright (c) 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Repeating Existing Work . . . . . . . . . . . . . . . . . . 4 2.2. Complicating the Internet . . . . . . . . . . . . . . . . . 4 2.3. Closed Ecosystems . . . . . . . . . . . . . . . . . . . . . 5 2.4. Long Process to Get Deployed . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Hardware Drivers Layer . . . . . . . . . . . . . . . . . . 6 4.2. Generic Abstract Layer . . . . . . . . . . . . . . . . . . 6 4.3. Application Protocols Layer . . . . . . . . . . . . . . . . 7 4.4. Developing New Protocols . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Mingui Zhang Expires January 21, 2016 [Page 2] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 1. Introduction Various Cloud applications spring up on the Cloud infrastructure that offers different IT resources, such as computation, storage and network capacity. These Cloud applications request heterogeneous requirements. Lots of network protocols have been proposed to meet these requirements and to optimize the usage of the resources provided by the Cloud infrastructure. More and more cloud operators are expecting that protocols are designed for their own applications [NVGRE] [bgp-dc]. However, the design of protocols never becomes an easy work for protocol developers. Usually, protocols are independently developed. Protocol developers from different communities have to repeatedly spend effort on designing some common protocols functions. Network information for protocols is depicted using protocol-intrinsic encoding methods and specifications, such as the Type-Length-Value format, which are unfriendly to protocol developers. Since the protocol is proposed, it can last several years till this protocol is finally deployed. An open platform for protocol development is expected. On this platform, the common protocol functions should be implemented to be reused by various protocols. Users are allowed to develop protocols that are customized to their applications. The platform should provide the interfaces that ease the development of protocols. Users should be able to easily add new characteristics to their protocols. This document specifies GEARS, an open platform for protocol innovation. GEARS adopts a three-layered architecture. The "hardware drivers layer" locally collects the hardware related information for the upper layer. Common protocol functions are implemented in the "generic abstract layer" and offer Application Program Interfaces (APIs) to the upper layer. Network information is depicted using the widely used data modeling language which is extensible and friendly to protocol developers. Application-specific protocols are developed on the "application protocol layer" to make use of the APIs and speak to the "generic abstract layer" using data models. 1.1. Conventions used in this document 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]. 1.2. Terminology NETCONF: Network Configuration Protocol [RFC4741] Mingui Zhang Expires January 21, 2016 [Page 3] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 YANG: a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) XML: eXtensible Markup Language JSON: JavaScript Object Notation 2. Problems Lots of Internet protocols are developed and being developed in the Cloud Computing era. TRILL [RFC6325] and SPB [RFC6329] make use of IS-IS protocol as the control plane to realize pair-wise shortest path for switches. The VxLAN scheme [RFC7348] proposes to provide an Layer 2 overlay for virtualized Data Center Networks over existing Layer 3 network. EVPN [RFC7432] proposes to realize the Ethernet VPN based on BGP/MPLS. Data Center operators are also developing their own protocols for Data Center Networks. For example, [NVGRE] makes use of Generic Routing Encapsulation [RFC2890] to realize the virtualized network for multi-tenant data centers. [bgp-dc] uses BGP to build large scale data centers. Protocols or pieces of one protocol are usually specified in RFCs (Request For Comments), and there are more 7,000 RFCs that have been published by IETF (Internet Engineering Task Force). Such a large number of protocols makes the Internet system more and more complicated while less and less scalable and operable. Problems with the way that protocols are developed are analyzed as in the following subsections. 2.1. Repeating Existing Work Protocols used to be developed in a "funnel style" model: different communities independently develop the protocols and repeat a certain amount of common work again and again. For example, all these protocols need specify their own Security and Operation Administration and Maintenance (OAM) mechanisms. The complex neighbor discovery and network information exchange procedure have to be handle in each protocol. 2.2. Complicating the Internet The introduction of new network protocols or adding pieces of functions to an existing protocol usually means introducing new dependency relationships to existing protocols. These complex relationships have made the whole Internet more and more complicated to be managed and harder and harder to do trouble shooting when the network goes wrong. Mingui Zhang Expires January 21, 2016 [Page 4] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 2.3. Closed Ecosystems Network devices are implemented as boxes. Both hardware and software of these boxes are provided by vendors. Although vendor may provide customers with the Command Line Interfaces (CLI) for configuration, this kind of openness are quite limited. It is hard for customers to develop applications based on these interfaces. It is impossible to develop new protocols using these boxes. This kind of closed ecosystem hinders the innovation of protocols. 2.4. Long Process to Get Deployed It usually takes several years from a new protocol is proposed and then becomes steady and finally published as a standard. During this period, lots of characteristics might be added and lots of disputes need be resolved. For applications that need to be quickly deployed in the market, this time period is too long. 3. Requirements It's time to provide an open platform for new protocols. The requirements for this kind of platform are listed as follows. o The common functions for protocols need not be repeated in each new protocol. o On this platform, customers are allowed to develop their own protocols for emerging applications. o The platform should provide friendly interfaces and tools to the customers who need develop new protocols. o Customers can easily introduce new functions to their protocols. 4. Design GEARS adopts a three layered architecture as shown in Figure 4.1. In order to facilitate the development of new protocols, data modeling language, such as YANG [RFC6020], can be used to depict the network information. Mingui Zhang Expires January 21, 2016 [Page 5] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 +------------------------------+ |Application Protocols Layer | | +--------------------+| | | ... || | +--------------------+ || | | NDN |-+| | +--------------------+ | | | | BGP |-+ | | +--------------------+ | | | | OSPF |-+ | | | | | | +--------------------+ | | ^ ^ | +-------|------------|---------+ +-------|------------|---------+ | | v | | +---------+ +-----------+ | | |Common | |Modeled | | | |Protocol | |Network |<---> | |Functions| |Information| | | +---------+ +-----------+ | |Generic Abstract Layer | +------------------------------+ +------------------------------+ |Hardware Drivers Layer | +------------------------------+ Figure 4.1: Generic and Extensible Architecture for protocols 4.1. Hardware Drivers Layer The hardware drivers layer locally speaks to the generic abstract layer of the GEARS node. It collects the hardware related information which includes the power status of interfaces, the transmission speed of the line card, etc. 4.2. Generic Abstract Layer The common functions of the protocols are implemented in the generic abstract layer. These functions includes but not limited to the following. o Discovery: GEARS nodes discover each other on the interconnected media. o Neighboring: GEARS nodes maintain the states of neighbors. Mingui Zhang Expires January 21, 2016 [Page 6] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 o Session: GEARS nodes maintain the sessions between each other. The sessions may be set up in a point to point mode or a point to multipoint mode. o Bootstrapping: A new protocol is bootstrapped on the GEARS platform. o Capability Negotiation: GEARS nodes negotiate the capability of executing certain network functions. o Push/Pull: A GEARS node pull or push the network information from another GEARS node or a central server that speaks GEARS. The generic abstract layer provide provides content agnostic APIs of the above common functions to application protocols. Network information is depicted as data models using modeling language such as YANG. These models are shared among the GEARS nodes in the XML or JSON format. Compact encoding approaches, such as the Concise Binary Object Representation (CBOR) [RFC7049], could be used to reduce the communication overhead. 4.3. Application Protocols Layer All application-specific protocols functions are implemented in the application protocols layer. Protocols developers are allowed to specify customized characteristics and processing logic for their protocols. The information for the protocols is depicted using data modeling language. When a new application protocol is programmed, the APIs of the generic abstract layer are called. In this way, the common protocol functions of the generic abstract layer are reused. Moreover, functions of existing protocols can be implemented as "library functions" , which can further save the developing effort for future protocols. 4.4. Developing New Protocols In GEARS, network information is depicted using a common data modeling language rather than those closed per-protocol encoding specifications. Model language development tools can be leveraged in protocol development, which makes the development of new application protocols very friendly to developers, and makes GEARS an open platform for protocol development. In this paper, the modeling language YANG is used. For example, the nodes of GEARS can be depicted as follows. Mingui Zhang Expires January 21, 2016 [Page 7] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 list node{ key "name"; leaf ID { type binary; } leaf address{ type binary; } list interface { ... } } While the interfaces of the node can be further depicted as follows. list interface { key "name"; leaf name { type string; } leaf speed { type enumeration { enum 10m; enum 100m; enum auto; } } leaf observed-speed { type uint32; config false; } } The links between nodes can be depicted as follows. list link{ key "name"; leaf ID { type binary; } container{ list interface1{...} list interface2{...} } leaf metric{ type uint64; } } Mingui Zhang Expires January 21, 2016 [Page 8] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 Since the protocols are developed using the modeling language, it facilitates the extension of protocols. As an example, the above link model can be easily augmented to include a new attribute to replace the "metric" attribute to depict the power consumption of the link. With this attribute, the protocol developer can adopt power aware routing algorithms to compute the forwarding paths. The introduction of this new attribute need not go through the long process of standardization. Only the models of the GEARS nodes need be upgraded. This greatly shortens the process for a new protocol to get deployed. 5. Security Considerations This document raises no new security issues. 6. IANA Considerations No IANA action is required in this document. RFC Editor: please remove this section before publication. Acknowledgements Authors would like to thank Susan Hares and Peter Ashwood-Smith for their comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [NVGRE] P. Garg, Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization using Generic Routing Encapsulation", draft-sridharan- virtualization-nvgre-08.txt, work in progress. [bgp-dc] P. Lapukhov, A. Premji and J. Mitchell, Ed.,"Use of BGP for routing in large-scale data centers", draft-ietf-rtgwg-bgp- routing-large-dc-03.txt, work in progress. [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011. [RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329. [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, Mingui Zhang Expires January 21, 2016 [Page 9] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014. [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010. 7.2. Informative References [RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013. Mingui Zhang Expires January 21, 2016 [Page 10] INTERNET-DRAFT GEARS, a protocol innovation platform July 20, 2015 Author's Addresses Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 P.R. China EMail: zhangmingui@huawei.com Jie Dong Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 P.R. China EMail: jie.dong@huawei.com Mach Chen Huawei Technologies No. 156 Beiqing Rd. Haidian District, Beijing 100095 P.R. China EMail: mach.chen@huawei.com Mingui Zhang Expires January 21, 2016 [Page 11]