Huawei's GRE Tunnel Bonding Protocol
RFC 8157
Document | Type |
RFC - Informational
(May 2017; No errata)
Was draft-zhang-gre-tunnel-bonding (individual)
|
|
---|---|---|---|
Authors | Nicolai Leymann , Cornelius Heidemann , Mingui Zhang , Behcet Sarikaya , Margaret Cullen | ||
Last updated | 2018-12-20 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
IETF conflict review | conflict-review-zhang-gre-tunnel-bonding | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2017-01-11) | ||
IESG | IESG state | RFC 8157 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | "Nevil Brownlee" <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | IANA OK - Actions Needed | |
IANA action state | RFC-Ed-Ack |
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 Abstract 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 [Page 1] RFC 8157 GRE Tunnel Bonding May 2017 Copyright Notice Copyright (c) 2017 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. Table of Contents 1. Introduction ....................................................3 2. Acronyms and Terminology ........................................4 3. Use Case ........................................................6 4. Overview ........................................................7 4.1. Control Plane ..............................................7 4.2. Data Plane .................................................7 4.3. Traffic Classification and Distribution ....................8 4.4. Traffic Recombination ......................................8 4.5. Bypass .....................................................9 4.6. Measurement ................................................9 4.7. Policy Control Considerations ..............................9 5. Control Protocol Specification (Control Plane) .................10 5.1. GRE Tunnel Setup Request ..................................12 5.1.1. Client Identification Name .........................12 5.1.2. Session ID .........................................13 5.1.3. DSL Synchronization Rate ...........................14 5.2. GRE Tunnel Setup Accept ...................................14 5.2.1. H IPv4 Address .....................................15 5.2.2. H IPv6 Address .....................................15 5.2.3. Session ID .........................................16 5.2.4. RTT Difference Threshold ...........................16 5.2.5. Bypass Bandwidth Check Interval ....................17 5.2.6. Active Hello Interval ..............................17 5.2.7. Hello Retry Times ..................................18 5.2.8. Idle Timeout .......................................18 5.2.9. Bonding Key Value ..................................19 5.2.10. Configured DSL Upstream Bandwidth .................20 5.2.11. Configured DSL Downstream Bandwidth ...............21Show full document text