Huawei's GRE Tunnel Bonding Protocol (RFC8157)
Original Publication Date: 2017-May-01
Included in the Prior Art Database: 2017-May-06
Internet Society Requests For Comment (RFCs)
N. Leymann: AUTHOR [+5]
Service Providers used to provide subscribers with separate access to their fixed networks and mobile networks. It has become desirable to bond these heterogeneous networks together to offer access service to subscribers; this service will provide increased access capacity and improved reliability.
Independent Submission N. Leymann Request for Comments: 8157 C. Heidemann Category: Informational Deutsche Telekom AG ISSN: 2070-1721 M. Zhang B. Sarikaya Huawei M. Cullen Painless Security May 2017
Huawei's GRE Tunnel Bonding Protocol
There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single Service Provider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.
In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE Tunnel Bonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber. Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8157.
Leymann, et al. Informational ...