Internet DRAFT - draft-zhang-generic-extensible-protocol-platform
draft-zhang-generic-extensible-protocol-platform
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]
