Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8157

Huawei's GRE Tunnel Bonding Protocol

Pages: 44
Informational
Part 2 of 2 – Pages 24 to 44
First   Prev   None

Top   ToC   RFC8157 - Page 24   prevText

5.3. GRE Tunnel Setup Deny

The HAAP MUST send the GRE Tunnel Setup Deny message to the HG if the GRE Tunnel Setup Request from this HG is denied. The HG MUST terminate the GRE tunnel setup process as soon as it receives the GRE Tunnel Setup Deny message.

5.3.1. Error Code

The HAAP uses the Error Code attribute to inform the HG of the error code. The error code depicts why the GRE Tunnel Setup Request is denied. Both the LTE GRE Tunnel Setup Deny message and the DSL GRE Tunnel Setup Deny message MUST include the Error Code attribute. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Error Code (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ Attribute Type Error Code, set to 17. Attribute Length Set to 4. Error Code An unsigned integer. The list of codes is as follows: 1: The HAAP was not reachable over LTE during the GRE Tunnel Setup Request. 2: The HAAP was not reachable via DSL during the GRE Tunnel Setup Request. 3: The LTE GRE tunnel to the HAAP failed.
Top   ToC   RFC8157 - Page 25
      4:  The DSL GRE tunnel to the HAAP failed.

      5:  The given DSL User ID is not allowed to use the GRE Tunnel
          Bonding service.

      6:  The given User Alias / User ID (Globally Unique Identifier
          (GUID)) is not allowed to use the GRE Tunnel Bonding service.

      7:  The LTE and DSL User IDs do not match.

      8:  The HAAP denied the GRE Tunnel Setup Request because a bonding
          session with the same User ID already exists.

      9:  The HAAP denied the GRE Tunnel Setup Request because the
          user's CIN is not permitted.

      10: The HAAP terminated a GRE Tunnel Bonding session for
          maintenance reasons.

      11: There was a communication error between the HAAP and the
          management system during the LTE GRE Tunnel Setup Request.

      12: There was a communication error between the HAAP and the
          management system during the DSL GRE Tunnel Setup Request.

5.4. GRE Tunnel Hello

After the DSL/LTE GRE tunnel is established, the HG begins to periodically send out GRE Tunnel Hello messages via the tunnel; the HAAP acknowledges the HG's messages by returning GRE Tunnel Hello messages to the HG. This continues until the tunnel is terminated.

5.4.1. Timestamp

The HAAP uses the Timestamp attribute to inform the HG of the timestamp value that is used for RTT calculation. Both the LTE GRE Tunnel Hello message and the DSL GRE Tunnel Hello message MUST include the Timestamp attribute. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Timestamp (8 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Top   ToC   RFC8157 - Page 26
   Attribute Type
      Timestamp, set to 5.

   Attribute Length
      Set to 8.

   Timestamp
      The time since the system restarted.  The high-order 4 bytes
      indicate an unsigned integer in units of 1 second; the low-order
      4 bytes indicate an unsigned integer in units of 1 millisecond.

5.4.2. IPv6 Prefix Assigned by HAAP

The HAAP uses the IPv6 Prefix Assigned by HAAP attribute to inform the HG of the assigned IPv6 prefix. This IPv6 prefix is to be captured via lawful intercept. Both the LTE GRE Tunnel Hello message and the DSL GRE Tunnel Hello message MUST include the IPv6 Prefix Assigned by HAAP attribute. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | IPv6 Prefix Assigned by HAAP (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ Attribute Type IPv6 Prefix Assigned by HAAP, set to 13. Attribute Length Set to 17. IPv6 Prefix Assigned by HAAP The highest-order 16 bytes encode an IPv6 address. The lowest-order 1 byte encodes the prefix length. These two values are put together to represent an IPv6 prefix.

5.5. GRE Tunnel Tear Down

The HAAP can terminate a DSL/LTE GRE tunnel by sending the GRE Tunnel Tear Down message to the HG via the tunnel. The Error Code attribute as defined in Section 5.3.1 MUST be included in this message. After receiving the GRE Tunnel Tear Down message, the HG removes the IP address of H, which is the destination IP addresses of the DSL and LTE GRE tunnels.
Top   ToC   RFC8157 - Page 27

5.6. GRE Tunnel Notify

The HG and the HAAP use the GRE Tunnel Notify message, which is transmitted through either the DSL GRE tunnel or the LTE GRE tunnel, to notify each other about their status regarding the DSL/LTE GRE tunnels, the information for the bonded tunnels, the actions that need to be taken, etc. Usually, the receiver just sends the received attributes back as the acknowledgement for each GRE Tunnel Notify message. However, there is an exception for the Filter List Package: since the size of the Filter List Package attribute can be very large, a special attribute -- the Filter List Package ACK attribute -- is used as the acknowledgement (see Section 5.6.12). Attributes that need to be included in the GRE Tunnel Notify message are defined below.

5.6.1. Bypass Traffic Rate

There are a few types of traffic that need to be transmitted over the raw DSL WAN interface rather than the bonded GRE tunnels. The HG has to set aside bypass bandwidth on the DSL WAN interface for these traffic types. Therefore, the available bandwidth of the DSL GRE tunnel is the entire DSL WAN interface bandwidth minus the occupied bypass bandwidth. The HG uses the Bypass Traffic Rate attribute to inform the HAAP of the downstream bypass bandwidth for the DSL WAN interface. The Bypass Traffic Rate attribute will be included in the DSL GRE Tunnel Notify message. The HAAP calculates the available downstream bandwidth for the DSL GRE tunnel as the Configured DSL Downstream Bandwidth minus the bypass bandwidth provided by the HG. The available DSL bandwidth will be used as the CIR of the coloring system [RFC2697]. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Bypass Traffic Rate (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Top   ToC   RFC8157 - Page 28
   Attribute Type
      Bypass Traffic Rate, set to 6.

   Attribute Length
      Set to 4.

   Bypass Traffic Rate
      An unsigned integer measured in kbps.

5.6.2. Filter List Package

The HAAP uses the Filter List Package attribute to inform the HG of the service types that need to bypass the bonded GRE tunnels. The full list of all Filter Items may be given by a series of Filter List Package attributes with each specifying a partial list. At the HG, a full list of Filter Items is maintained. Also, the HG needs to maintain an exception list of Filter Items. For example, the packets carrying the control messages defined in this document should be excluded from the filter list. Incoming packets that match a Filter Item in the filter list while not matching any item in the exception list MUST be transmitted over raw DSL rather than the bonded GRE tunnels. Both the LTE GRE Tunnel Notify message and the DSL GRE Tunnel Notify message MAY include the Filter List Package attribute. The DSL GRE Tunnel Notify message is preferred. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Filter List TLV (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ Attribute Type Filter List Package, set to 8. Attribute Length The total length of the Filter List TLV. The maximum allowed length is 969 bytes.
Top   ToC   RFC8157 - Page 29
   Filter List TLV
      The Filter List TLV occurs one time in a Filter List Package
      attribute.  It has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Commit_Count                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Packet_Sum               |         Packet_ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Filter Item (1)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         ......                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Filter Item (n)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each Filter Item is of the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type                  |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Enable                |     Description Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                 Description Value                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        Value                                  ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Commit_Count
         An unsigned integer that identifies the version of the Filter
         Item list.  The version is shared by all Filter List Packages
         and increases monotonically by one for each new Filter Item
         list.  The HG MUST refresh its Filter Item list when a new
         Commit_Count is received.

      Packet_Sum
         If a single Filter List Package attribute might make the
         control message larger than the MTU, fragmentation is used.
         The Packet_Sum indicates the total number of fragments.

      Packet_ID
         The fragmentation index for this Filter List Package attribute.
         Each fragment is numbered starting at 1 and increasing by one
         up to Packet_Sum.
Top   ToC   RFC8157 - Page 30
      Type
         The Type of the Filter Item.  Currently, the following types
         are supported:

                       Filter Item                  Type
                   ===========================   ============
                   FQDN [RFC7031]                    1
                   DSCP [RFC2724]                    2
                   Destination Port                  3
                   Destination IP                    4
                   Destination IP & Port             5
                   Source Port                       6
                   Source IP                         7
                   Source IP & Port                  8
                   Source MAC                        9
                   Protocol                          10
                   Source IP Range                   11
                   Destination IP Range              12
                   Source IP Range & Port            13
                   Destination IP Range & Port       14

         Other values are reserved for future use and MUST be ignored on
         receipt.

      Length
         The length of the Filter Item in bytes.  Type and Length are
         excluded.

      Enable
         An integer that indicates whether or not the Filter Item is
         enabled.  A value of 1 means "enabled", and a value of 0 means
         "disabled".  Other possible values are reserved and MUST be
         ignored on receipt.

      Description Length
         The length of the Description Value in bytes.

      Description Value
         A variable-length string value encoded in UTF-8 that describes
         the Filter List TLV (e.g., "FQDN").

      Value
         A variable-length string encoded in UTF-8 that specifies the
         value of the Filter Item (e.g., "www.yahoo.com").  As an
         example, Type = 1 and Value = "www.yahoo.com" mean that packets
         whose FQDN field equals "www.yahoo.com" match the Filter Item.
         "Source MAC" (source Media Access Control address) values are
         specified using hexadecimal numbers.  Port numbers are decimals
Top   ToC   RFC8157 - Page 31
         as assigned by IANA in [Port-NO].  For the "Protocol" type, the
         value could be either a decimal or a keyword specified by IANA
         in [Pro-NO].  The formats for IP addresses and IP address
         ranges are defined in [RFC4632] and [RFC4291] for IPv4 and
         IPv6, respectively.  A Filter Item of Type 5, 8, 13, or 14 is a
         combination of two parameters; values for the two parameters
         are separated by a colon (":").

5.6.3. Switching to DSL Tunnel

If the RTT difference is continuously detected to be in violation of the RTT Difference Threshold (see Section 5.2.4) more than the number of times specified in the RTT Difference Threshold Violation attribute (see Section 5.2.12), the HG uses the Switching to DSL Tunnel attribute to inform the HAAP to use the DSL GRE tunnel only. When the HAAP receives this attribute, it MUST begin to transmit downstream traffic to this HG solely over the DSL GRE tunnel. The DSL GRE Tunnel Notify message MAY include the Switching to DSL Tunnel attribute. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Switching to DSL Tunnel, set to 11. Attribute Length Set to 0.

5.6.4. Overflowing to LTE Tunnel

If the RTT difference is continuously detected to not be in violation of the RTT Difference Threshold (see Section 5.2.4) more than the number of times specified in the RTT Difference Threshold Compliance attribute (see Section 5.2.13), the HG uses the Overflowing to LTE Tunnel attribute to inform the HAAP that the LTE GRE tunnel can be used again. The DSL GRE Tunnel Notify message MAY include the Overflowing to LTE Tunnel attribute. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC8157 - Page 32
   Attribute Type
      Overflowing to LTE Tunnel, set to 12.

   Attribute Length
      Set to 0.

5.6.5. DSL Link Failure

When the HG detects that the DSL WAN interface status is "down", it MUST tear down the DSL GRE tunnel. It informs the HAAP about the failure by using the DSL Link Failure attribute. The HAAP MUST tear down the DSL GRE tunnel upon receipt of the DSL Link Failure attribute. The DSL Link Failure attribute SHOULD be carried in the LTE GRE Tunnel Notify message. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type DSL Link Failure, set to 18. Attribute Length Set to 0.

5.6.6. LTE Link Failure

When the HG detects that the LTE WAN interface status is "down", it MUST tear down the LTE GRE tunnel. It informs the HAAP about the failure by using the LTE Link Failure attribute. The HAAP MUST tear down the LTE GRE tunnel upon receipt of the LTE Link Failure attribute. The LTE Link Failure attribute SHOULD be carried in the DSL GRE Tunnel Notify message. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type LTE Link Failure, set to 19. Attribute Length Set to 0.
Top   ToC   RFC8157 - Page 33

5.6.7. IPv6 Prefix Assigned to Host

If the HG changes the IPv6 prefix assigned to the host, it uses the IPv6 Prefix Assigned to Host attribute to inform the HAAP. Both the LTE GRE Tunnel Notify message and the DSL GRE Tunnel Notify message MAY include the IPv6 Prefix Assigned to Host attribute. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | IPv6 Prefix Assigned to Host (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ Attribute Type IPv6 Prefix Assigned to Host, set to 21. Attribute Length Set to 17. IPv6 Prefix Assigned to Host The highest-order 16 bytes encode an IPv6 address. The lowest-order 1 byte encodes the prefix length. These two values are put together to represent an IPv6 prefix.

5.6.8. Diagnostic Start: Bonding Tunnel

The HG uses the Diagnostic Start: Bonding Tunnel attribute to inform the HAAP to switch to diagnostic mode to test the performance of the entire bonding tunnel. The Diagnostic Start: Bonding Tunnel attribute SHOULD be carried in the DSL GRE Tunnel Notify message. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Diagnostic Start: Bonding Tunnel, set to 26. Attribute Length Set to 0.
Top   ToC   RFC8157 - Page 34

5.6.9. Diagnostic Start: DSL Tunnel

The HG uses the Diagnostic Start: DSL Tunnel attribute to inform the HAAP to switch to diagnostic mode to test the performance of the DSL GRE tunnel. The Diagnostic Start: DSL Tunnel attribute SHOULD be carried in the DSL GRE Tunnel Notify message. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Diagnostic Start: DSL Tunnel, set to 27. Attribute Length Set to 0.

5.6.10. Diagnostic Start: LTE Tunnel

The HG uses the Diagnostic Start: LTE Tunnel attribute to inform the HAAP to switch to diagnostic mode to test the performance of the LTE GRE tunnel. The Diagnostic Start: LTE Tunnel attribute SHOULD be carried in the DSL GRE Tunnel Notify message. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Diagnostic Start: LTE Tunnel, set to 28. Attribute Length Set to 0.
Top   ToC   RFC8157 - Page 35

5.6.11. Diagnostic End

The HG uses the Diagnostic End attribute to inform the HAAP to stop operating in diagnostic mode. The Diagnostic End attribute SHOULD be carried in the DSL GRE Tunnel Notify message. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Diagnostic End, set to 29. Attribute Length Set to 0.

5.6.12. Filter List Package ACK

The HG uses the Filter List Package ACK attribute to acknowledge the Filter List Package sent by the HAAP. Both the LTE GRE Tunnel Notify message and the DSL GRE Tunnel Notify message MAY include the Filter List Package ACK attribute. +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ | Filter List Package ACK (5 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+ Attribute Type Filter List Package ACK, set to 30. Attribute Length Set to 5.
Top   ToC   RFC8157 - Page 36
   Filter List Package ACK
      The highest-order 4 bytes are the Commit_Count as defined in
      Section 5.6.2.  The lowest-order 1 byte encodes the following
      error codes:

      0: The Filter List Package is acknowledged.

      1: The Filter List Package is not acknowledged.  The HG is a new
         subscriber and has not ever received a Filter List Package.  In
         this case, the HAAP SHOULD tear down the bonding tunnels and
         force the HG to re-establish the GRE tunnels.

      2: The Filter List Package is not acknowledged.  The HG has
         already gotten a valid Filter List Package.  The filter list on
         the HG will continue to be used, while the HAAP need not do
         anything.

5.6.13. Switching to Active Hello State

If traffic is being sent/received over the bonding GRE tunnels before the "No Traffic Monitored Interval" expires (see Section 5.2.15), the HG sends the HAAP a GRE Tunnel Notify message containing the Switching to Active Hello State attribute. The HAAP will switch to Active Hello State and send the HG a GRE Tunnel Notify message carrying the Switching to Active Hello State attribute as the ACK. When the HG receives the ACK, it will switch to Active Hello State, start RTT detection, and start sending GRE Tunnel Hello messages with the Active Hello Interval (see Section 5.2.6). +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Switching to Active Hello State, set to 33. Attribute Length Set to 0.
Top   ToC   RFC8157 - Page 37

5.6.14. Switching to Idle Hello State

The HG initiates switching to Idle Hello State when the bonding of GRE tunnels is successfully established and the LTE GRE Tunnel Setup Accept message carrying the Idle Hello Interval attribute (see Section 5.2.14) is received. The HG sends the HAAP a GRE Tunnel Notify message containing the Switching to Idle Hello State attribute. The HAAP will switch to Idle Hello State, clear RTT state, and send the HG a GRE Tunnel Notify message carrying the Switching to Idle Hello State attribute as the ACK. When the HG receives the ACK, it will (1) switch to Idle Hello State, (2) stop RTT detection and clear RTT state, and (3) start sending GRE Tunnel Hello messages with the Idle Hello Interval (see Section 5.2.14). +-+-+-+-+-+-+-+-+ |Attribute Type | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Length | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Switching to Idle Hello State, set to 34. Attribute Length Set to 0.

5.6.15. Tunnel Verification

The HAAP uses the Tunnel Verification attribute to inform the HG to verify whether an existing LTE GRE tunnel is still functioning. The Tunnel Verification attribute SHOULD be carried in the LTE GRE Tunnel Notify message. It provides a means to detect the tunnel faster than the GRE Tunnel Hello, especially when the LTE GRE tunnel is in the Idle Hello State and it takes a much longer time to detect this tunnel. When the HAAP receives an LTE GRE Tunnel Setup Request and finds that the requested tunnel conflicts with an existing tunnel, the HAAP initiates tunnel verification. The HAAP drops all conflicting LTE GRE Tunnel Setup Request messages and sends GRE Tunnel Notify messages carrying the Tunnel Verification attribute until the verification ends. The HG MUST respond to the HAAP with the same Tunnel Verification attribute as the ACK if the tunnel is still functioning.
Top   ToC   RFC8157 - Page 38
   If the ACK of the Tunnel Verification attribute is received from the
   HG, the HAAP determines that the existing tunnel is still
   functioning.  An LTE GRE Tunnel Deny message (with Error Code = 8)
   will be sent to the HG.  The HG SHOULD terminate the GRE Tunnel Setup
   Request process immediately.

   If the HAAP does not receive a tunnel verification ACK message after
   three attempts (one initial attempt and two retries), it will regard
   the existing tunnel as failed, and the LTE GRE Tunnel Setup Request
   will be accepted.

   +-+-+-+-+-+-+-+-+
   |Attribute Type |                    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attribute Length             |    (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Attribute Type
      Tunnel Verification, set to 35.

   Attribute Length
      Set to 0.

6. Tunnel Protocol Operation (Data Plane)

GRE tunnels are set up over heterogeneous connections, such as LTE and DSL, between the HG and the HAAP. Users' IP (inner) packets are encapsulated in GRE packets that are in turn carried in IP (outer) packets. The general structure of data packets of the GRE Tunnel Bonding Protocol is shown below. +--------------------------------+ | Media Header | +--------------------------------+ | Outer IP Header | +--------------------------------+ | GRE Header | +--------------------------------+ | Inner IP Packet | +--------------------------------+

6.1. The GRE Header

The GRE header was first standardized in [RFC2784]. [RFC2890] added the optional Key and Sequence Number fields. The Checksum and the Reserved1 fields are not used in the GRE Tunnel Bonding; therefore, the C bit is set to 0.
Top   ToC   RFC8157 - Page 39
   The Key bit is set to 1 so that the Key field is present.  The Key
   field is used as a 32-bit random number.  It is generated by the HAAP
   per bonding connection, and the HG is notified (see Section 5.2.9).

   The S bit is set to 1, and the Sequence Number field is present and
   used for in-order delivery as per [RFC2890].

   The Protocol Type field in the GRE header MUST be set to 0x0800 for
   IPv4 or 0x86DD for IPv6.  So, the GRE header used by data packets of
   the GRE Tunnel Bonding Protocol has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0| |1|1| Reserved0       | Ver |  Protocol Type 0x0800/86DD    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Key                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 3: GRE Header for Data Packets of GRE Tunnel Bonding

6.2. Automatic Setup of GRE Tunnels

The HG gets the DSL WAN interface IP address (D) from the Broadband Remote Access Server (BRAS) via the Point-to-Point Protocol over Ethernet (PPPoE) and gets the LTE WAN interface IP address (E) through the Packet Data Protocol (PDP) from the Packet Data Network Gateway (PGW). The domain name of a HAAP group may be configured or obtained via the DSL/LTE WAN interface based on gateway configuration protocols such as [TR-069], where the HAAP group comprises one or multiple HAAPs. The Domain Name System (DNS) resolution of the HAAP group's domain name is requested via the DSL/LTE WAN interface. The DNS server will reply with an anycast HAAP IP address (G), which MAY be pre-configured by the operator. After the interface IP addresses have been acquired, the HG starts the following GRE Tunnel Bonding procedure. It is REQUIRED that the HG first set up the LTE GRE tunnel and then set up the DSL GRE tunnel. The HG sends the GRE Tunnel Setup Request message to the HAAP via the LTE WAN interface. The outer source IP address for this message is the LTE WAN interface IP address (E), while the outer destination IP address is the anycast HAAP IP address (G). The HAAP with the highest priority (e.g., the one that the HG has the least-cost path to reach) in the HAAP group, which receives the GRE Tunnel Setup
Top   ToC   RFC8157 - Page 40
   Request message, will initiate the procedure for authentication and
   authorization, as specified in [TS23.401], to check whether the HG is
   trusted by the PGW.

   If the authentication and authorization succeed, the HAAP sets the
   LTE WAN interface IP address (E), which is obtained from the GRE
   Tunnel Setup Request message (i.e., its outer source IP address), as
   the destination endpoint IP address of the GRE tunnel and replies to
   the HG's LTE WAN interface with the GRE Tunnel Setup Accept message
   in which an IP address (H) of the HAAP (e.g., an IP address of a Line
   Card in the HAAP) and a Session ID randomly generated by the HAAP are
   carried as attributes.  The outer source IP address for this message
   is the IP address (H) or the anycast HAAP IP address (G), while the
   outer destination IP address is the LTE WAN interface IP address (E).
   Otherwise, the HAAP MUST send to the HG's LTE WAN interface the GRE
   Tunnel Setup Deny message, and the HG MUST terminate the tunnel setup
   process once it receives the GRE Tunnel Setup Deny message.

   After the LTE GRE tunnel is successfully set up, the HG will obtain
   the C address (see Figure 1) over the tunnel from the HAAP through
   the Dynamic Host Configuration Protocol (DHCP).  After that, the HG
   starts to set up the DSL GRE tunnel.  It sends a GRE Tunnel Setup
   Request message via the DSL WAN interface, carrying the
   aforementioned Session ID received from the HAAP.  The outer source
   IP address for this message is the DSL WAN interface IP address (D),
   while the outer destination IP address is the IP address (H) of the
   HAAP.  The HAAP, which receives the GRE Tunnel Setup Request message,
   will initiate the procedure for authentication and authorization in
   order to check whether the HG is trusted by the BRAS.

   If the authentication and authorization succeed, the HAAP sets the
   DSL WAN interface IP address (D), which is obtained from the GRE
   Tunnel Setup Request message (i.e., its outer source IP address), as
   the destination endpoint IP address of the GRE tunnel and replies to
   the HG's DSL WAN interface with the GRE Tunnel Setup Accept message.
   The outer source IP address for this message is the IP address (H) of
   the HAAP, while the outer destination IP address is the DSL WAN
   interface IP address (D).  In this way, the two tunnels with the same
   Session ID can be used to carry traffic from the same user.  That is
   to say, the two tunnels are "bonded" together.  Otherwise, if the
   authentication and authorization fail, the HAAP MUST send to the HG's
   DSL WAN interface the GRE Tunnel Setup Deny message.  Meanwhile, it
   MUST send to the HG's LTE WAN interface the GRE Tunnel Tear Down
   message.  The HG MUST terminate the tunnel setup process once it
   receives the GRE Tunnel Setup Deny message and MUST tear down the LTE
   GRE tunnel that has been set up once it receives the GRE Tunnel
   Tear Down message.
Top   ToC   RFC8157 - Page 41

7. Security Considerations

Malicious devices controlled by attackers may intercept the control messages sent on the GRE tunnels. Later on, the rogue devices may fake control messages to disrupt the GRE tunnels or attract traffic from the target HG. As a security feature, the Key field of the GRE header of the control messages and the data packets is generated as a 32-bit cleartext password, except for the first GRE Setup Request message per bonding connection sent from the HG to the HAAP, whose Key field is filled with all zeros. The HAAP and the HG validate the Key value and the outer source IP address, and they discard any packets with invalid combinations. Moreover, GRE over IP Security (IPsec) could be used to enhance security.

8. IANA Considerations

IANA need not assign anything for the GRE Tunnel Bonding Protocol. The GRE Protocol Type, the Ethertype for the GRE Channel, is set to 0xB7EA, which is under the control of the IEEE Registration Authority. However, IANA has updated the "IEEE 802 Numbers" IANA web page [802Type], which is of primarily historic interest.

9. References

9.1. Normative References

[Port-NO] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers>. [Pro-NO] IANA, "Assigned Internet Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, <http://www.rfc-editor.org/info/rfc2697>.
Top   ToC   RFC8157 - Page 42
   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              DOI 10.17487/RFC2784, March 2000,
              <http://www.rfc-editor.org/info/rfc2784>.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, DOI 10.17487/RFC2890, September 2000,
              <http://www.rfc-editor.org/info/rfc2890>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291,
              February 2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632,
              August 2006, <http://www.rfc-editor.org/info/rfc4632>.

   [TR-069]   Broadband Forum, "CPE WAN Management Protocol", Issue: 1
              Amendment 5, November 2013,
              <https://www.broadband-forum.org/technical/download/
              TR-069_Amendment-5.pdf>.

   [TS23.401] 3GPP TS23.401, "General Packet Radio Service (GPRS)
              enhancements for Evolved Universal Terrestrial Radio
              Access Network (E-UTRAN) access", v11.7.0, September 2013.

9.2. Informative References

[802Type] IANA, "IEEE 802 Numbers", <http://www.iana.org/assignments/ieee-802-numbers>. [ANSI-X9.31-1998] ANSI Standard X9.31-1998, "Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA)", 1998. [RFC2724] Handelman, S., Stibler, S., Brownlee, N., and G. Ruth, "RTFM: New Attributes for Traffic Flow Measurement", RFC 2724, DOI 10.17487/RFC2724, October 1999, <http://www.rfc-editor.org/info/rfc2724>. [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, Ed., "Protocol for Access Node Control Mechanism in Broadband Networks", RFC 6320, DOI 10.17487/RFC6320, October 2011, <http://www.rfc-editor.org/info/rfc6320>.
Top   ToC   RFC8157 - Page 43
   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.

   [RFC7031]  Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
              Requirements", RFC 7031, DOI 10.17487/RFC7031,
              September 2013, <http://www.rfc-editor.org/info/rfc7031>.

   [RFC7676]  Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
              for Generic Routing Encapsulation (GRE)", RFC 7676,
              DOI 10.17487/RFC7676, October 2015,
              <http://www.rfc-editor.org/info/rfc7676>.

Contributors

Li Xue Individual Email: xueli_jas@163.com Zhongwen Jiang Huawei Technologies Email: jiangzhongwen@huawei.com
Top   ToC   RFC8157 - Page 44

Authors' Addresses

Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21-27 Berlin 10781 Germany Phone: +49-170-2275345 Email: n.leymann@telekom.de Cornelius Heidemann Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany Phone: +49-6151-5812721 Email: heidemannc@telekom.de Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China Email: zhangmingui@huawei.com Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 3 Plano, TX 75024 United States of America Email: sarikaya@ieee.org Margaret Cullen Painless Security 14 Summer St. Suite 202 Malden, MA 02148 United States of America Email: margaret@painless-security.com