Huawei's GRE Tunnel Bonding Protocol
RFC 8157

Document Type RFC - Informational (May 2017; No errata)
Last updated 2017-05-05
Stream ISE
Formats plain text pdf html bibtex
IETF conflict review conflict-review-zhang-gre-tunnel-bonding
Stream ISE state Published RFC
Consensus Boilerplate Unknown
Document shepherd Nevil Brownlee
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 ...............21
Show full document text