[要約] RFC 8157は、HuaweiのGREトンネルボンディングプロトコルに関する技術仕様です。このRFCの目的は、GREトンネルのボンディングを実現するためのプロトコルを提供することです。
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
HuaweiのGREトンネルボンディングプロトコル
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.
このドキュメントでは、GRE（Generic Routing Encapsulation）トンネルボンディングが、顧客の家屋などの構内の有線および無線ネットワークへの結合アクセスを可能にするアプローチとして指定されています。 GREトンネルボンディングでは、ネットワーク接続ごとに1つである2つのGREトンネルがセットアップされ、互いに結合されて、加入者用の単一のGREトンネルを形成します。各サブ接続と比較して、結合接続はアクセス容量の増加と信頼性の向上を約束します。このドキュメントで説明されているソリューションは現在Huaweiによって実装され、Deutsche Telekom AGによって展開されています。このドキュメントにより、他の開発者が相互運用可能な実装を構築できるようになります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8157で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
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
5.2.12. RTT Difference Threshold Violation ................21
5.2.13. RTT Difference Threshold Compliance ...............22
5.2.14. Idle Hello Interval ...............................23
5.2.15. No Traffic Monitored Interval .....................23
5.3. GRE Tunnel Setup Deny .....................................24
5.3.1. Error Code .........................................24
5.4. GRE Tunnel Hello ..........................................25
5.4.1. Timestamp ..........................................25
5.4.2. IPv6 Prefix Assigned by HAAP .......................26
5.5. GRE Tunnel Tear Down ......................................26
5.6. GRE Tunnel Notify .........................................27
5.6.1. Bypass Traffic Rate ................................27
5.6.2. Filter List Package ................................28
5.6.3. Switching to DSL Tunnel ............................31
5.6.4. Overflowing to LTE Tunnel ..........................31
5.6.5. DSL Link Failure ...................................32
5.6.6. LTE Link Failure ...................................32
5.6.7. IPv6 Prefix Assigned to Host .......................33
5.6.8. Diagnostic Start: Bonding Tunnel ...................33
5.6.9. Diagnostic Start: DSL Tunnel .......................34
5.6.10. Diagnostic Start: LTE Tunnel ......................34
5.6.11. Diagnostic End ....................................35
5.6.12. Filter List Package ACK ...........................35
5.6.13. Switching to Active Hello State ...................36
5.6.14. Switching to Idle Hello State .....................37
5.6.15. Tunnel Verification ...............................37
6. Tunnel Protocol Operation (Data Plane) .........................38
6.1. The GRE Header ............................................38
6.2. Automatic Setup of GRE Tunnels ............................39
7. Security Considerations ........................................41
8. IANA Considerations ............................................41
9. References .....................................................41
9.1. Normative References ......................................41
9.2. Informative References ....................................42
Contributors ......................................................43
Authors' Addresses ................................................44
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.
加入者に固定ネットワークとモバイルネットワークへの個別のアクセスを提供するために使用されるサービスプロバイダー。これらの異種ネットワークを結合して、加入者にアクセスサービスを提供することが望まれています。このサービスにより、アクセス容量が増加し、信頼性が向上します。
This document focuses on the use case where a DSL (Digital Subscriber Line) connection and an LTE (Long Term Evolution) connection are bonded together. When the traffic volume exceeds the bandwidth of the DSL connection, the excess amount can be offloaded to the LTE connection. A Home Gateway (HG) is a Customer Premises Equipment (CPE) device initiating the DSL and LTE connections. A Hybrid Access Aggregation Point (HAAP) is the network function that resides in the provider's networks to terminate these bonded connections. Note that if there were more than two connections that need to be bonded, the GRE Tunnel Bonding mechanism could support that scenario as well. However, support for more than two connections is out of scope for this document. Also, the protocol specified in this document is limited to the single-operator scenario only, i.e., the two peering boxes -- the HG and the HAAP -- are operated by a single provider. The adaptation of the GRE Tunnel Bonding Protocol to the multi-provider scenario is left for future work.
このドキュメントでは、DSL（Digital Subscriber Line）接続とLTE（Long Term Evolution）接続が結合されているユースケースに焦点を当てています。トラフィック量がDSL接続の帯域幅を超えると、超過分がLTE接続にオフロードされます。ホームゲートウェイ（HG）は、DSLおよびLTE接続を開始する顧客宅内機器（CPE）デバイスです。ハイブリッドアクセス集約ポイント（HAAP）は、これらの結合された接続を終端するためにプロバイダーのネットワークに常駐するネットワーク機能です。結合する必要のある接続が3つ以上ある場合は、GREトンネルボンディングメカニズムがそのシナリオもサポートできることに注意してください。ただし、3つ以上の接続のサポートは、このドキュメントの範囲外です。また、このドキュメントで指定されているプロトコルは、単一オペレーターのシナリオのみに限定されています。つまり、2つのピアリングボックス（HGとHAAP）は、単一のプロバイダーによって運用されています。 GREトンネルボンディングプロトコルのマルチプロバイダーシナリオへの適応は、今後の作業に委ねられます。
This document bases the solution on GRE (Generic Routing Encapsulation [RFC2784] [RFC2890]), since GRE is widely supported in both fixed and mobile networks. Approaches specified in this document might also be used by other tunneling technologies to achieve tunnel bonding. However, such variants are out of scope for this document.
GREは固定ネットワークとモバイルネットワークの両方で広くサポートされているため、このドキュメントはGRE（Generic Routing Encapsulation [RFC2784] [RFC2890]）に基づくソリューションに基づいています。このドキュメントで指定されているアプローチは、トンネルボンディングを実現するために他のトンネリングテクノロジーでも使用される場合があります。ただし、そのようなバリアントはこのドキュメントの範囲外です。
For each heterogeneous connection (DSL and LTE) between the HG and the HAAP, one GRE tunnel is set up. The HG and the HAAP, respectively, serve as the common termination point of the two tunnels at both ends. Those GRE tunnels are further bonded together to form a logical GRE tunnel for the subscriber. The HG conceals the GRE tunnels from the end nodes, and end nodes simply treat the logical GRE tunnel as a single IP link. This provides an overlay: the users' IP packets (inner IP) are encapsulated in GRE, which is in turn carried over IP (outer IP).
HGとHAAP間の異種混合接続（DSLおよびLTE）ごとに、1つのGREトンネルがセットアップされます。 HGとHAAPはそれぞれ、両端の2つのトンネルの共通の終端点として機能します。これらのGREトンネルはさらに結合され、加入者用の論理GREトンネルを形成します。 HGはGREトンネルをエンドノードから隠し、エンドノードは単に論理GREトンネルを単一のIPリンクとして扱います。これにより、オーバーレイが提供されます。ユーザーのIPパケット（内部IP）はGREにカプセル化され、GREはIP（外部IP）を介して転送されます。
The GRE Tunnel Bonding Protocol is developed by Huawei and has been deployed in networks operated by Deutsche Telekom AG. This document makes this protocol available to the public, thereby enabling other developers to build interoperable implementations.
GREトンネルボンディングプロトコルはHuaweiによって開発され、Deutsche Telekom AGが運営するネットワークに展開されています。このドキュメントは、このプロトコルを公開し、他の開発者が相互運用可能な実装を構築できるようにします。
GRE: Generic Routing Encapsulation [RFC2784] [RFC2890].
GRE：Generic Routing Encapsulation [RFC2784] [RFC2890]。
DSL: Digital Subscriber Line. A family of technologies used to transmit digital data over telephone lines.
DSL：Digital Subscriber Line。電話回線を介してデジタルデータを送信するために使用される一連のテクノロジ。
LTE: Long Term Evolution. A standard for wireless communication of high-speed data for mobile phones and data terminals. Commonly marketed as 4G LTE.
LTE：Long Term Evolution。携帯電話やデータ端末向けの高速データ無線通信規格。一般的に4G LTEとして販売されています。
HG: Home Gateway. A CPE device that is enhanced to support the simultaneous use of both fixed broadband and 3GPP access connections.
HG：ホームゲートウェイ。固定ブロードバンド接続と3GPPアクセス接続の両方の同時使用をサポートするように拡張されたCPEデバイス。
HAAP: Hybrid Access Aggregation Point. A logical function in an operator's network, terminating bonded connections while offering high-speed Internet.
HAAP：ハイブリッドアクセス集約ポイント。オペレーターのネットワークにおける論理機能であり、高速インターネットを提供しながら結合接続を終了します。
CIR: Committed Information Rate [RFC2697].
CIR：認定情報レート[RFC2697]。
RTT: Round-Trip Time.
RTT：ラウンドトリップ時間。
AAA: Authentication, Authorization, and Accounting [RFC6733].
AAA：認証、承認、およびアカウンティング[RFC6733]。
SOAP: Simple Object Access Protocol. A protocol specification for exchanging structured information in the implementation of web services in computer networks.
SOAP：Simple Object Access Protocol。コンピュータネットワークでのWebサービスの実装で構造化情報を交換するためのプロトコル仕様。
FQDN: Fully Qualified Domain Name. Generally, a host name with at least one domain label under the top-level domain. For example, "dhcp.example.org" is an FQDN [RFC7031].
FQDN：完全修飾ドメイン名。通常、トップレベルドメインの下に少なくとも1つのドメインラベルが付いたホスト名。たとえば、「dhcp.example.org」はFQDN [RFC7031]です。
DSCP: The 6-bit codepoint (DSCP) of the Differentiated Services field (DS field) in the IPv4 and IPv6 headers [RFC2724].
DSCP：IPv4およびIPv6ヘッダーの[Differentiated Services]フィールド（DSフィールド）の6ビットコードポイント（DSCP）[RFC2724]。
BRAS: Broadband Remote Access Server. Routes traffic to and from broadband remote access devices such as Digital Subscriber Line Access Multiplexers (DSLAMs) on an Internet Service Provider's (ISP's) network.
BRAS：ブロードバンドリモートアクセスサーバー。インターネットサービスプロバイダー（ISP）のネットワーク上のデジタル加入者回線アクセスマルチプレクサー（DSLAM）などのブロードバンドリモートアクセスデバイスとの間でトラフィックをルーティングします。
PGW: Packet Data Network Gateway. In the Long Term Evolution (LTE) architecture for the Evolved Packet Core (EPC), acts as an anchor for user-plane mobility.
PGW：パケットデータネットワークゲートウェイ。 Evolved Packet Core（EPC）のLong Evolution（LTE）アーキテクチャでは、ユーザープレーンモビリティのアンカーとして機能します。
PDP: Packet Data Protocol. A packet transfer protocol used in wireless GPRS (General Packet Radio Service) / HSDPA (High-Speed Downlink Packet Access) networks.
PDP：パケットデータプロトコル。ワイヤレスGPRS（一般パケット無線サービス）/ HSDPA（高速ダウンリンクパケットアクセス）ネットワークで使用されるパケット転送プロトコル。
PPPoE: Point-to-Point over Ethernet. A network protocol for encapsulating PPP frames inside Ethernet frames.
PPPoE：ポイントツーポイントオーバーイーサネット。イーサネットフレーム内にPPPフレームをカプセル化するためのネットワークプロトコル。
DNS: Domain Name System. A hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network.
DNS：ドメインネームシステム。インターネット、プライベートネットワークに接続されたコンピューター、サービス、またはリソースの階層型分散命名システム。
DHCP: Dynamic Host Configuration Protocol. A standardized network protocol used on Internet Protocol (IP) networks for dynamically distributing network configuration parameters, such as IP addresses for interfaces and services.
DHCP：動的ホスト構成プロトコル。インターフェイスやサービスのIPアドレスなどのネットワーク構成パラメーターを動的に配布するために、インターネットプロトコル（IP）ネットワークで使用される標準化されたネットワークプロトコル。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Bonding Connection
+-+ ****************************
| | *+-+ +-+*
| | *|E+-- LTE Connection --+ |*
subscriber |C| *+-+ |H|* Internet
| | *+-+ | |*
| | *|D+-- DSL Connection --+ |*
| | *+-+ +-+*
+-+ ****************************
\______/ \__/
HG HAAP
C: The service endpoint of the bonding service at the HG. E: The endpoint of the LTE connection resides in the HG. D: The endpoint of the DSL connection resides in the HG. H: The endpoint for each heterogeneous connection at the HAAP.
C：HGのボンディングサービスのサービスエンドポイント。 E：LTE接続のエンドポイントはHGにあります。 D：DSL接続のエンドポイントはHGにあります。 H：HAAPでの各異種接続のエンドポイント。
Figure 1: Offloading from DSL to LTE, Increased Access Capacity
図1：DSLからLTEへのオフロード、アクセス容量の増加
If a Service Provider runs heterogeneous networks, such as fixed and mobile, subscribers might be eager to use those networks simultaneously for increased access capacity rather than just using a single network. As shown by the reference model in Figure 1, the subscriber expects a significantly higher access bandwidth from the bonding connection than from the DSL connection. In other words, when the traffic volume exceeds the bandwidth of the DSL connection, the excess amount may be offloaded to the LTE connection.
サービスプロバイダーが固定ネットワークやモバイルネットワークなどの異種ネットワークを実行している場合、サブスクライバーは、単一のネットワークを使用するだけでなく、それらのネットワークを同時に使用してアクセスキャパシティを向上させようとする場合があります。図1の参照モデルに示されているように、加入者は、DSL接続よりもボンディング接続からのアクセス帯域幅が大幅に高いことを期待しています。つまり、トラフィック量がDSL接続の帯域幅を超えると、超過分がLTE接続にオフロードされる場合があります。
Compared to per-flow load-balancing mechanisms, which are widely used nowadays, the use case described in this document requires a per-packet offloading approach. For per-flow load balancing, the maximum bandwidth that may be used by a traffic flow is the bandwidth of an individual connection, while for per-packet offloading, a single flow may use the combined bandwidth of the two connections.
現在広く使用されているフローごとのロードバランシングメカニズムと比較して、このドキュメントで説明する使用例では、パケットごとのオフロードアプローチが必要です。フローごとのロードバランシングでは、トラフィックフローで使用できる最大帯域幅は個々の接続の帯域幅ですが、パケットごとのオフロードでは、単一のフローで2つの接続の合計帯域幅を使用できます。
In this document, the widely supported GRE is chosen as the tunneling technique. With the newly defined control protocol, GRE tunnels are set up on top of the DSL and LTE connections, which are ended at D and H or at E and H, as shown in Figure 1. These tunnels are bonded together to form a single logical bonding connection between the HG and the HAAP. Subscribers use this logical connection without knowing the GRE tunnels.
このドキュメントでは、広くサポートされているGREがトンネリング技術として選択されています。図1に示すように、新しく定義された制御プロトコルを使用して、GREトンネルがDSLおよびLTE接続の上にセットアップされ、DおよびHまたはEおよびHで終了します。これらのトンネルは結合されて単一の論理を形成しますHGとHAAP間の結合接続。加入者は、GREトンネルを知らなくてもこの論理接続を使用します。
A clean-slate control protocol is designed to manage the GRE tunnels that are set up per heterogeneous connection between the HG and the HAAP. The goal is to design a compact control plane for bonding access instead of reusing existing control planes.
クリーンスレート制御プロトコルは、HGとHAAPの間の異種接続ごとに設定されるGREトンネルを管理するように設計されています。目標は、既存のコントロールプレーンを再利用する代わりに、アクセスを結合するためのコンパクトなコントロールプレーンを設計することです。
In order to measure the performance of connections, control packets need to co-route the same path with data packets. Therefore, a GRE Channel is opened for the purpose of data-plane forwarding of control-plane packets. As shown in Figure 2 (see Section 5), the GRE header [RFC2784] with the Key extension specified by [RFC2890] is being used. The GRE Protocol Type (0xB7EA) is used to identify this GRE Channel. A family of control messages is encapsulated with a GRE header and carried over this channel. Attributes, formatted in Type-Length-Value (TLV) style, are further defined and included in each control message.
接続のパフォーマンスを測定するには、制御パケットが同じパスをデータパケットと一緒にルーティングする必要があります。したがって、コントロールプレーンパケットのデータプレーン転送のためにGREチャネルが開かれます。図2に示すように（セクション5を参照）、[RFC2890]で指定されたキー拡張を持つGREヘッダー[RFC2784]が使用されています。 GREプロトコルタイプ（0xB7EA）は、このGREチャネルを識別するために使用されます。制御メッセージのファミリーは、GREヘッダーでカプセル化され、このチャネルで伝送されます。 Type-Length-Value（TLV）スタイルでフォーマットされた属性がさらに定義され、各コントロールメッセージに含まれます。
With the newly defined control plane, the GRE tunnels between the HG and the HAAP can be established, managed, and released without the involvement of operators.
新しく定義されたコントロールプレーンを使用すると、オペレーターの関与なしに、HGとHAAP間のGREトンネルを確立、管理、および解放できます。
Using the control plane defined in Section 4.1, GRE tunnels can be automatically set up per heterogeneous connection between the HG and the HAAP. For the use case described in Section 3, one GRE tunnel is ended at the DSL WAN interfaces, e.g., the DSL GRE tunnel, and another GRE tunnel is ended at the LTE WAN interfaces, e.g., the LTE GRE tunnel. Each tunnel may carry a user's IP packets as payload, which forms a typical IP-over-IP overlay. These tunnels are bonded together to offer a single access point to subscribers.
セクション4.1で定義されたコントロールプレーンを使用すると、HGとHAAP間の異種接続ごとにGREトンネルを自動的に設定できます。セクション3で説明する使用例の場合、1つのGREトンネルはDSL WANインターフェース（DSL LREトンネルなど）で終了し、別のGREトンネルはLTE WANインターフェース（LTE GREトンネルなど）で終了します。各トンネルは、典型的なIP-over-IPオーバーレイを形成するペイロードとしてユーザーのIPパケットを運ぶ場合があります。これらのトンネルは結合され、加入者に単一のアクセスポイントを提供します。
As shown in Figure 3 (see Section 6.1), the GRE header [RFC2784] with the Key and Sequence Number extensions specified by [RFC2890] is used to encapsulate data packets. The Protocol Type is either 0x0800 (listed as "0x800" in [RFC2784]) or 0x86DD [RFC7676], which indicates that the inner packet is either an IPv4 packet or an IPv6 packet, respectively. The GRE Key field is set to a unique value for the entire bonding connection. The GRE Sequence Number field is used to maintain the sequence of packets transported in all GRE tunnels as a single flow between the HG and the HAAP.
図3に示すように（セクション6.1を参照）、[RFC2890]で指定されたキーとシーケンス番号の拡張を備えたGREヘッダー[RFC2784]を使用して、データパケットをカプセル化します。プロトコルタイプは0x0800（[RFC2784]で「0x800」としてリストされている）または0x86DD [RFC7676]のいずれかであり、それぞれ内部パケットがIPv4パケットまたはIPv6パケットであることを示します。 GREキーフィールドは、ボンディング接続全体で一意の値に設定されます。 GREシーケンス番号フィールドは、HGとHAAP間の単一のフローとしてすべてのGREトンネルで転送されるパケットのシーケンスを維持するために使用されます。
For the offloading use case, the coloring mechanism specified in [RFC2697] is being used to classify subscribers' IP packets, both upstream and downstream, into the DSL GRE tunnel or the LTE GRE tunnel. Packets colored as green or yellow will be distributed into the DSL GRE tunnel, and packets colored as red will be distributed into the LTE GRE tunnel. For the scenario that requires more than two GRE tunnels, multiple levels of token buckets might be realized. However, that scenario is out of scope for this document.
オフロードのユースケースでは、[RFC2697]で指定されたカラーリングメカニズムを使用して、アップストリームとダウンストリームの両方の加入者のIPパケットをDSL GREトンネルまたはLTE GREトンネルに分類します。緑または黄色に着色されたパケットはDSL GREトンネルに配信され、赤に着色されたパケットはLTE GREトンネルに配信されます。 3つ以上のGREトンネルが必要なシナリオでは、複数レベルのトークンバケットが実現される場合があります。ただし、そのシナリオはこのドキュメントの範囲外です。
The Committed Information Rate (CIR) of the coloring mechanism is set to the total DSL WAN bandwidth minus the bypass DSL bandwidth (see Section 4.5). The total DSL WAN bandwidth MAY be configured, MAY be obtained from the management system (AAA server, SOAP server, etc.), or MAY be detected in real time using the Access Node Control Protocol (ANCP) [RFC6320].
カラーリングメカニズムの認定情報レート（CIR）は、DSL WAN帯域幅の合計からバイパスDSL帯域幅を引いた値に設定されます（セクション4.5を参照）。 DSL WAN帯域幅の合計を構成することも、管理システム（AAAサーバー、SOAPサーバーなど）から取得することも、アクセスノード制御プロトコル（ANCP）[RFC6320]を使用してリアルタイムで検出することもできます。
For the offloading use case, the recombination function at the receiver provides in-order delivery of subscribers' traffic. The receiver maintains a small reordering buffer and orders the data packets in this buffer via the Sequence Number field [RFC2890] of the GRE header. All packets carried on GRE tunnels that belong to the same bonding connection go into a single reordering buffer.
オフロードのユースケースの場合、受信側の再結合機能は、加入者のトラフィックを順番どおりに配信します。レシーバーは小さな並べ替えバッファーを維持し、GREヘッダーのシーケンス番号フィールド[RFC2890]を介してこのバッファー内のデータパケットを並べ替えます。同じボンディング接続に属するGREトンネルで運ばれるすべてのパケットは、単一の並べ替えバッファに入ります。
Operators may configure the maximum allowed size (see MAX_PERFLOW_BUFFER in [RFC2890]) of the buffer for reordering. They may also configure the maximum time (see OUTOFORDER_TIMER in [RFC2890]) that a packet can stay in the buffer for reordering. The OUTOFORDER_TIMER must be configured carefully. Values larger than the difference of the normal Round-Trip Time (RTT) (e.g., 100 ms) of the two connections are not recommended. Implementation and deployment experiences have demonstrated that there is usually a large margin for the value of MAX_PERFLOW_BUFFER. Values larger than the multiplication of the sum of the line rate of the two connections and the value of OUTOFORDER_TIMER should be used.
オペレーターは、並べ替え用のバッファーの最大許容サイズ（[RFC2890]のMAX_PERFLOW_BUFFERを参照）を構成できます。また、パケットが並べ替えのためにバッファにとどまることができる最大時間（[RFC2890]のOUTOFORDER_TIMERを参照）を構成することもできます。 OUTOFORDER_TIMERは慎重に構成する必要があります。 2つの接続の通常のラウンドトリップ時間（RTT）の差（たとえば、100 ms）より大きい値はお勧めしません。実装と展開の経験から、通常、MAX_PERFLOW_BUFFERの値には大きなマージンがあることが実証されています。 2つの接続のラインレートの合計とOUTOFORDER_TIMERの値の乗算よりも大きい値を使用する必要があります。
Service Providers provide some services that should not be delivered over the bonding connection. For example, Service Providers may not expect real-time IPTV to be carried by the LTE GRE tunnel. It is required that IPTV traffic bypass the GRE Tunnel Bonding and use the raw DSL bandwidth. Bypass traffic is not subject to the traffic classification and distribution specified above. The raw connection used for bypass traffic is not controlled by the HAAP. It may or may not go through a device in which the HAAP resides.
サービスプロバイダーは、ボンディング接続を介して配信されるべきではないいくつかのサービスを提供します。たとえば、サービスプロバイダーは、リアルタイムIPTVがLTE GREトンネルによって伝送されることを期待しない場合があります。 IPTVトラフィックはGREトンネルボンディングをバイパスし、生のDSL帯域幅を使用する必要があります。バイパストラフィックは、上記で指定されたトラフィックの分類と配信の対象ではありません。バイパストラフィックに使用される未加工の接続は、HAAPによって制御されません。 HAAPが存在するデバイスを通過する場合と通過しない場合があります。
The HAAP may announce the service types that need to bypass the bonded GRE tunnels by using the Filter List Package attribute as specified in Section 5.6.2. The HG and the HAAP need to set aside the DSL bandwidth for bypassing. The available DSL bandwidth for GRE Tunnel Bonding is equal to the total DSL bandwidth minus the bypass bandwidth.
HAAPは、セクション5.6.2で指定されているFilter List Package属性を使用して、結合されたGREトンネルをバイパスする必要があるサービスタイプをアナウンスする場合があります。 HGとHAAPは、バイパス用にDSL帯域幅を確保する必要があります。 GREトンネルボンディングで使用可能なDSL帯域幅は、合計DSL帯域幅からバイパス帯域幅を差し引いたものに等しくなります。
Since control packets are routed using the same paths as the data packets, the real performance of the data paths (e.g., the GRE tunnels) can be measured. The GRE Tunnel Hello messages specified in Section 5.4 are used to carry the timestamp information, and the RTT value can therefore be calculated based on the timestamp.
制御パケットはデータパケットと同じパスを使用してルーティングされるため、データパス（GREトンネルなど）の実際のパフォーマンスを測定できます。セクション5.4で指定されたGREトンネルのHelloメッセージは、タイムスタンプ情報の伝達に使用されるため、RTT値はタイムスタンプに基づいて計算できます。
Besides the end-to-end delay of the GRE tunnels, the HG and the HAAP need to measure the capacity of the tunnels as well. For example, the HG is REQUIRED to measure the downstream bypassing bandwidth and report it to the HAAP in real time (see Section 5.6.1).
GREトンネルのエンドツーエンドの遅延に加えて、HGとHAAPはトンネルの容量も測定する必要があります。たとえば、HGは、ダウンストリームのバイパス帯域幅を測定し、リアルタイムでHAAPに報告する必要があります（セクション5.6.1を参照）。
Operators and users may input policies into the GRE Tunnel Bonding. These policies will be "interpreted" into parameters or actions that impact the traffic classification, distribution, combination, measurement, and bypass.
オペレーターとユーザーは、GREトンネルボンディングにポリシーを入力できます。これらのポリシーは、トラフィックの分類、配信、組み合わせ、測定、およびバイパスに影響を与えるパラメーターまたはアクションに「解釈」されます。
Operators and users may offer the service types that need to bypass the bonded GRE tunnels. Service types defined by operators (see Section 5.6.2) will be delivered from the HAAP to the HG through the control plane (see Section 4.1), and the HG will use the raw connection to transmit traffic for these service types. Users may also define bypass service types on the HG. Bypass service types defined by users need not be delivered to the HAAP.
オペレーターとユーザーは、結合されたGREトンネルをバイパスする必要があるサービスタイプを提供する場合があります。オペレーターによって定義されたサービスタイプ（セクション5.6.2を参照）は、コントロールプレーン（セクション4.1を参照）を介してHAAPからHGに配信され、HGはraw接続を使用してこれらのサービスタイプのトラフィックを送信します。ユーザーは、HGでバイパスサービスタイプを定義することもできます。ユーザーが定義したバイパスサービスタイプをHAAPに配信する必要はありません。
Operators may specify the interval for sending Hello messages and the retry times for the HG or the HAAP to send out Hello messages before the failure of a connection.
オペレーターは、Helloメッセージの送信間隔と、HGまたはHAAPが接続に失敗する前にHelloメッセージを送信するための再試行時間を指定できます。
Since the GRE tunnels are set up on top of heterogeneous DSL and LTE connections, if the difference of the transmission delays of these connections exceeds a given threshold for a certain period, the HG and the HAAP should be able to stop the offloading behavior and fall back to a traditional transmission mode, where the LTE GRE tunnel is disused while all traffic is transmitted over the DSL GRE tunnel. Operators are allowed to define this threshold and period.
GREトンネルは異種DSLおよびLTE接続の上にセットアップされるため、これらの接続の伝送遅延の差が特定の期間の所定のしきい値を超える場合、HGおよびHAAPはオフロード動作を停止して、すべてのトラフィックがDSL GREトンネルを介して送信される間、LTE GREトンネルは使用されない従来の送信モードに戻ります。オペレーターは、このしきい値と期間を定義できます。
Control messages are used to establish, maintain, measure, and tear down GRE tunnels between the HG and the HAAP. Also, the control plane undertakes the responsibility to convey traffic policies over the GRE tunnels.
制御メッセージは、HGとHAAP間のGREトンネルを確立、維持、測定、および破棄するために使用されます。また、コントロールプレーンは、GREトンネルを介してトラフィックポリシーを伝達する責任を負います。
For the purpose of measurement, control messages need to be delivered as GRE encapsulated packets and co-routed with data-plane packets. The new GRE Protocol Type (0xB7EA) is allocated for this purpose, and the standard GRE header as per [RFC2784] with the Key extension specified by [RFC2890] is used. The Checksum Present bit is set to 0. The Key Present bit is set to 1. The Sequence Number Present bit is set to 0. So, the format of the GRE header for control messages of the GRE Tunnel Bonding Protocol is as follows:
測定のために、制御メッセージはGREカプセル化パケットとして配信され、データプレーンパケットと一緒にルーティングされる必要があります。新しいGREプロトコルタイプ（0xB7EA）がこの目的で割り当てられ、[RFC2784]の標準のGREヘッダーと[RFC2890]で指定されたキー拡張が使用されます。チェックサム存在ビットは0に設定されます。キー存在ビットは1に設定されます。シーケンス番号存在ビットは0に設定されます。したがって、GREトンネルボンディングプロトコルの制御メッセージのGREヘッダーのフォーマットは次のとおりです。
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|0| Reserved0 | Ver | Protocol Type 0xB7EA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key For security purposes, the Key field is used to carry a random number. The random number is generated by the HAAP, and the HG is informed of it (see Section 5.2.9).
キーセキュリティの目的で、キーフィールドは乱数を運ぶために使用されます。乱数はHAAPによって生成され、HGに通知されます（セクション5.2.9を参照）。
The general format of the entire control message is as follows:
制御メッセージ全体の一般的な形式は次のとおりです。
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|0| Reserved0 | Ver | Protocol Type 0xB7EA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MsgType|T-Type | |
+-+-+-+-+-+-+-+-+ Attributes +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of Control Messages of GRE Tunnel Bonding
図2：GREトンネルボンディングの制御メッセージのフォーマット
MsgType (4 bits) Message Type. The control message family contains the following six types of control messages (not including "Reserved"):
MsgType（4ビット）メッセージタイプ。制御メッセージファミリには、次の6種類の制御メッセージが含まれます（「予約済み」を除く）。
Control Message Family Type
========================== =========
GRE Tunnel Setup Request 1
GRE Tunnel Setup Accept 2
GRE Tunnel Setup Deny 3
GRE Tunnel Hello 4
GRE Tunnel Tear Down 5
GRE Tunnel Notify 6
Reserved 0, 7-15
T-Type (4 bits) Tunnel Type. Set to 0001 if the control message is sent via the primary GRE tunnel (normally the DSL GRE tunnel). Set to 0010 if the control message is sent via the secondary GRE tunnel (normally the LTE GRE tunnel). Values 0000 and values from 0011 through 1111 are reserved for future use and MUST be ignored on receipt.
Tタイプ（4ビット）トンネルタイプ。制御メッセージがプライマリGREトンネル（通常はDSL GREトンネル）経由で送信される場合は、0001に設定します。制御メッセージがセカンダリGREトンネル（通常はLTE GREトンネル）経由で送信される場合は、0010に設定します。値0000と0011から1111の値は将来の使用のために予約されており、受信時に無視する必要があります。
Attributes The Attributes field includes the attributes that need to be carried in the control message. Each Attribute has the following format:
属性[属性]フィールドには、制御メッセージで伝達する必要がある属性が含まれます。各属性の形式は次のとおりです。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Value ~ (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type The Attribute Type specifies the type of the attribute.
属性タイプ属性タイプは、属性のタイプを指定します。
Attribute Length Attribute Length indicates the length of the Attribute Value in bytes.
属性の長さ属性の長さは、属性値の長さをバイト単位で示します。
Attribute Value The Attribute Value includes the value of the attribute.
属性値属性値には、属性の値が含まれます。
All control messages are sent in network byte order (high-order bytes first). The Protocol Type carried in the GRE header for the control message is 0xB7EA. Based on this number, the receiver will decide to consume the GRE packet locally rather than forward it further.
すべての制御メッセージは、ネットワークバイトオーダーで送信されます（高位バイトが最初）。制御メッセージのGREヘッダーで伝送されるプロトコルタイプは0xB7EAです。この数に基づいて、受信者はGREパケットをさらに転送するのではなく、ローカルで消費することを決定します。
The HG uses the GRE Tunnel Setup Request message to request that the HAAP establish the GRE tunnels. It is sent out from the HG's LTE and DSL WAN interfaces separately. Attributes that need to be included in this message are defined in the following subsections.
HGはGREトンネルセットアップ要求メッセージを使用して、HAAPがGREトンネルを確立することを要求します。 HGのLTEおよびDSL WANインターフェイスから個別に送信されます。このメッセージに含める必要がある属性は、次のサブセクションで定義されています。
An operator uses the Client Identification Name (CIN) to identify the HG. The HG sends the CIN to the HAAP for authentication and authorization as specified in [TS23.401]. It is REQUIRED that the GRE Tunnel Setup Request message sent out from the LTE WAN interface contain the CIN attribute while the GRE Tunnel Setup Request message sent out from the DSL WAN interface does not contain this attribute.
オペレーターは、クライアント識別名（CIN）を使用してHGを識別します。 [TS23.401]で指定されているように、HGは認証と承認のためにHAAPにCINを送信します。 LTE WANインターフェースから送信されるGREトンネルセットアップリクエストメッセージにはCIN属性が含まれ、DSL WANインターフェースから送信されるGREトンネルセットアップリクエストメッセージにはこの属性が含まれないことが必要です。
The CIN attribute has the following format:
CIN属性の形式は次のとおりです。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Client Identification Name (40 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type CIN, set to 3.
属性タイプCIN、3に設定。
Attribute Length Set to 40.
属性の長さを40に設定。
Client Identification Name This is a 40-byte string value encoded in UTF-8 and set by the operator. It is used as the identification of the HG in the operator's network.
クライアント識別名これは、UTF-8でエンコードされ、オペレーターによって設定される40バイトのストリング値です。これは、オペレーターのネットワーク内のHGのIDとして使用されます。
This Session ID is generated by the HAAP when the LTE GRE Tunnel Setup Request message is received. The HAAP announces the Session ID to the HG in the LTE GRE Tunnel Setup Accept message. For those WAN interfaces that need to be bonded together, the HG MUST use the same Session ID. The HG MUST carry the Session ID attribute in each DSL GRE Tunnel Setup Request message. For the first time that the LTE GRE Tunnel Setup Request message is sent to the HAAP, the Session ID attribute need not be included. However, if the LTE GRE tunnel fails and the HG tries to revive it, the LTE GRE Tunnel Setup Request message MUST include the Session ID attribute.
このセッションIDは、LTE GREトンネルセットアップ要求メッセージが受信されたときにHAAPによって生成されます。 HAAPは、LTE GRE Tunnel Setup AcceptメッセージでセッションIDをHGに通知します。結合する必要があるWANインターフェースの場合、HGは同じセッションIDを使用する必要があります。 HGは、各DSL GREトンネルセットアップ要求メッセージでセッションID属性を伝達する必要があります。 LTE GREトンネルセットアップリクエストメッセージが初めてHAAPに送信されるときは、セッションID属性を含める必要はありません。ただし、LTE GREトンネルが失敗し、HGがそれを復活させようとする場合、LTE GREトンネルセットアップ要求メッセージにセッションID属性を含める必要があります。
The Session ID attribute has the following format:
セッションID属性の形式は次のとおりです。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Session ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
Session ID, set to 4.
Attribute Length Set to 4.
属性の長さを4に設定。
Session ID An unsigned integer generated by the HAAP. It is used as the identification of bonded GRE tunnels.
セッションID HAAPによって生成された符号なし整数。結合されたGREトンネルのIDとして使用されます。
The HG uses the DSL Synchronization Rate to notify the HAAP about the downstream bandwidth of the DSL link. The DSL GRE Tunnel Setup Request message MUST include the DSL Synchronization Rate attribute. The LTE GRE Tunnel Setup Request message SHOULD NOT include this attribute.
HGはDSL同期レートを使用して、DSLリンクのダウンストリーム帯域幅についてHAAPに通知します。 DSL GREトンネルセットアップ要求メッセージには、DSL同期レート属性を含める必要があります。 LTE GREトンネルセットアップリクエストメッセージには、この属性を含めないでください。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| DSL Synchronization Rate (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type DSL Synchronization Rate, set to 7.
属性タイプDSL同期レート、7に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
DSL Synchronization Rate An unsigned integer measured in kbps.
DSL同期レートkbpsで測定される符号なし整数。
The HAAP uses the GRE Tunnel Setup Accept message as the response to the GRE Tunnel Setup Request message. This message indicates acceptance of the tunnel establishment and carries parameters of the GRE tunnels. Attributes that need to be included in this message are defined below.
HAAPは、GREトンネルセットアップ要求メッセージへの応答としてGREトンネルセットアップ受け入れメッセージを使用します。このメッセージは、トンネル確立の受け入れを示し、GREトンネルのパラメータを伝達します。このメッセージに含める必要がある属性を以下に定義します。
The HAAP uses the H IPv4 Address attribute to inform the HG of the H IPv4 address. The HG uses the H IPv4 address as the destination endpoint IPv4 address of the GRE tunnels (the source endpoint IPv4 addresses of the GRE tunnels are the DSL WAN interface IP address (D) and the LTE WAN interface IP address (E), respectively, as shown in Figure 1). The LTE GRE Tunnel Setup Accept message MUST include the H IPv4 Address attribute.
HAAPはH IPv4アドレス属性を使用して、HGにH IPv4アドレスを通知します。 HGは、H IPv4アドレスをGREトンネルの宛先エンドポイントIPv4アドレスとして使用します（GREトンネルのソースエンドポイントIPv4アドレスは、それぞれDSL WANインターフェースIPアドレス（D）とLTE WANインターフェースIPアドレス（E）です）図1に示すように）。 LTE GREトンネルセットアップ受け入れメッセージには、H IPv4アドレス属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| H IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type H IPv4 Address, set to 1.
属性タイプH IPv4アドレス、1に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
H IPv4 Address Set to the pre-configured IPv4 address (e.g., an IP address of a Line Card in the HAAP), which is used as the endpoint IP address of GRE tunnels by the HAAP.
H IPv4アドレス事前構成されたIPv4アドレス（たとえば、HAAPのラインカードのIPアドレス）に設定します。これは、HAAPによってGREトンネルのエンドポイントIPアドレスとして使用されます。
The HAAP uses the H IPv6 Address attribute to inform the HG of the H IPv6 address. The HG uses the H IPv6 address as the destination endpoint IPv6 address of the GRE tunnels (the source endpoint IPv6 addresses of the GRE tunnels are the DSL WAN interface IP address (D) and the LTE WAN interface IP address (E), respectively, as shown in Figure 1).
HAAPはH IPv6アドレス属性を使用して、HGにH IPv6アドレスを通知します。 HGは、H IPv6アドレスをGREトンネルの宛先エンドポイントIPv6アドレスとして使用します（GREトンネルのソースエンドポイントIPv6アドレスは、それぞれDSL WANインターフェースIPアドレス（D）およびLTE WANインターフェースIPアドレス（E）です）図1に示すように）。
The LTE GRE Tunnel Setup Accept message MUST include the H IPv6 Address attribute.
LTE GRE Tunnel Setup Acceptメッセージには、H IPv6アドレス属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| H IPv6 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
H IPv6 Address, set to 2.
Attribute Length Set to 16.
属性の長さを16に設定。
H IPv6 Address Set to the pre-configured IPv6 address (e.g., an IP address of a Line Card in the HAAP), which is used as the endpoint IP address of GRE tunnels by the HAAP.
H IPv6アドレス事前構成されたIPv6アドレス（たとえば、HAAPのラインカードのIPアドレス）に設定されます。これは、HAAPによってGREトンネルのエンドポイントIPアドレスとして使用されます。
The LTE GRE Tunnel Setup Accept message MUST include the Session ID attribute as defined in Section 5.1.2.
LTE GRE Tunnel Setup Acceptメッセージには、セクション5.1.2で定義されているセッションID属性が含まれている必要があります。
The HAAP uses the RTT Difference Threshold attribute to inform the HG of the acceptable threshold of the RTT difference between the DSL link and the LTE link. If the measured RTT difference exceeds this threshold, the HG SHOULD stop offloading traffic to the LTE GRE tunnel. The LTE GRE Tunnel Setup Accept message MUST include the RTT Difference Threshold attribute.
HAAPは、RTT差異しきい値属性を使用して、DSLリンクとLTEリンク間のRTT差異の許容可能なしきい値をHGに通知します。測定されたRTT差がこのしきい値を超える場合、HGはLTE GREトンネルへのトラフィックのオフロードを停止する必要があります（SHOULD）。 LTE GRE Tunnel Setup Acceptメッセージには、RTT Difference Threshold属性が含まれている必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| RTT Difference Threshold (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type RTT Difference Threshold, set to 9.
属性タイプRTT差分しきい値、9に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
RTT Difference Threshold An unsigned integer measured in milliseconds. This value can be chosen in the range 0 through 1000.
RTT Difference Thresholdミリ秒単位で測定される符号なし整数。この値は、0から1000の範囲で選択できます。
The HAAP uses the Bypass Bandwidth Check Interval attribute to inform the HG of how frequently the bypass bandwidth should be checked. The HG should check the bypass bandwidth of the DSL WAN interface in each time period indicated by this interval. The LTE GRE Tunnel Setup Accept message MUST include the Bypass Bandwidth Check Interval attribute.
HAAPは、バイパス帯域幅チェック間隔属性を使用して、バイパス帯域幅をチェックする頻度をHGに通知します。 HGは、この間隔で示される各期間でDSL WANインターフェイスのバイパス帯域幅を確認する必要があります。 LTE GREトンネルセットアップ受け入れメッセージには、バイパス帯域幅チェック間隔属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Bypass Bandwidth Check Interval (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Bypass Bandwidth Check Interval, set to 10.
属性タイプバイパス帯域幅チェック間隔、10に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
Bypass Bandwidth Check Interval An unsigned integer measured in seconds. This value can be chosen in the range 10 through 300.
帯域幅チェック間隔のバイパス秒単位で測定される符号なし整数。この値は、10から300の範囲で選択できます。
The HAAP uses the Active Hello Interval attribute to inform the HG of the pre-configured interval for sending out GRE Tunnel Hellos. The HG should send out GRE Tunnel Hellos via both the DSL and LTE WAN interfaces in each time period as indicated by this interval. The LTE GRE Tunnel Setup Accept message MUST include the Active Hello Interval attribute.
HAAPはActive Hello Interval属性を使用して、GREトンネルHelloを送信するための事前設定された間隔をHGに通知します。 HGは、この間隔で示されているように、各期間でDSLおよびLTE WANインターフェイスの両方を介してGREトンネルHelloを送信する必要があります。 LTE GREトンネルセットアップ受け入れメッセージには、アクティブなHelloインターバル属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Active Hello Interval (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
Active Hello Interval, set to 14.
Attribute Length Set to 4.
属性の長さを4に設定。
Active Hello Interval An unsigned integer measured in seconds. This value can be chosen in the range 1 through 100.
Active Hello Interval秒単位で測定される符号なし整数。この値は、1から100の範囲で選択できます。
The HAAP uses the Hello Retry Times attribute to inform the HG of the retry times for sending GRE Tunnel Hellos. If the HG does not receive any acknowledgement from the HAAP for the number of GRE Tunnel Hello attempts specified in this attribute, the HG will declare a failure of the GRE tunnel. The LTE GRE Tunnel Setup Accept message MUST include the Hello Retry Times attribute.
HAAPは、Hello Retry Times属性を使用して、GREトンネルHelloを送信するための再試行時間をHGに通知します。この属性で指定されたGREトンネルのHello試行の回数について、HGがHAAPから確認応答を受信しない場合、HGはGREトンネルの失敗を宣言します。 LTE GRE Tunnel Setup Acceptメッセージには、Hello Retry Times属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Hello Retry Times (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Hello Retry Times, set to 15.
属性タイプHello Retry Times、15に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
Hello Retry Times An unsigned integer that takes values in the range 3 through 10.
Hello Retry Times 3から10の範囲の値を取る符号なし整数。
The HAAP uses the Idle Timeout attribute to inform the HG of the pre-configured timeout value to terminate the DSL GRE tunnel. When an LTE GRE tunnel failure is detected, all traffic will be sent over the DSL GRE tunnel. If the failure of the LTE GRE tunnel lasts longer than the Idle Timeout, subsequent traffic will be sent over raw DSL rather than over a tunnel, and the DSL GRE tunnel SHOULD be terminated. The LTE GRE Tunnel Setup Accept message MUST include the Idle Timeout attribute.
HAAPはIdle Timeout属性を使用して、事前構成されたタイムアウト値をHGに通知し、DSL GREトンネルを終了します。 LTE GREトンネルの障害が検出されると、すべてのトラフィックがDSL GREトンネルを介して送信されます。 LTE GREトンネルの障害がアイドルタイムアウトよりも長く続く場合、後続のトラフィックはトンネルではなく生のDSL経由で送信され、DSL GREトンネルを終了する必要があります（SHOULD）。 LTE GREトンネルセットアップ受け入れメッセージには、アイドルタイムアウト属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Idle Timeout (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Idle Timeout, set to 16.
属性タイプのアイドルタイムアウト、16に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
Idle Timeout An unsigned integer measured in seconds. It takes values in the range 0 through 172,800 with a granularity of 60. The default value is 86,400 (24 hours). The value 0 indicates that the idle timer never expires.
アイドルタイムアウト秒単位で測定される符号なし整数。値の範囲は0から172,800で、粒度は60です。デフォルト値は86,400（24時間）です。値0は、アイドルタイマーが期限切れにならないことを示します。
The HAAP uses the Bonding Key Value attribute to inform the HG of the number that is to be carried as the Key of the GRE header for subsequent control messages. The Bonding Key Value is generated by the HAAP and used for security purposes.
HAAPは、ボンディングキー値属性を使用して、後続の制御メッセージのGREヘッダーのキーとして伝送される番号をHGに通知します。ボンディングキー値はHAAPによって生成され、セキュリティの目的で使用されます。
The method used to generate this number is left up to implementations. The pseudorandom number generator defined in ANSI X9.31, Appendix A.2.4 [ANSI-X9.31-1998] is RECOMMENDED. Note that random number generation "collisions" are allowed in the GRE Tunnel Bonding Protocol.
この数を生成するために使用される方法は実装に任されています。 ANSI X9.31、付録A.2.4 [ANSI-X9.31-1998]で定義されている疑似乱数ジェネレータをお勧めします。 GREトンネルボンディングプロトコルでは、乱数生成の「衝突」が許可されていることに注意してください。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Bonding Key Value (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
Bonding Key Value, set to 20.
Attribute Length Set to 4.
属性の長さを4に設定。
Bonding Key Value A 32-bit random number generated by the HAAP.
結合キー値HAAPによって生成される32ビットの乱数。
The HAAP obtains the upstream bandwidth of the DSL link from the management system and uses the Configured DSL Upstream Bandwidth attribute to inform the HG. The HG uses the received upstream bandwidth as the CIR [RFC2697] for the DSL link. The DSL GRE Tunnel Setup Accept message MUST include the Configured DSL Upstream Bandwidth attribute.
HAAPはDSLリンクのアップストリーム帯域幅を管理システムから取得し、構成済みDSLアップストリーム帯域幅属性を使用してHGに通知します。 HGは、受信したアップストリーム帯域幅をDSLリンクのCIR [RFC2697]として使用します。 DSL GREトンネルセットアップ受け入れメッセージには、構成済みDSLアップストリーム帯域幅属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Configured DSL Upstream Bandwidth (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Configured DSL Upstream Bandwidth, set to 22.
属性タイプ構成済みDSLアップストリーム帯域幅、22に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
Configured DSL Upstream Bandwidth An unsigned integer measured in kbps.
構成済みDSLアップストリーム帯域幅kbpsで測定される符号なし整数。
The HAAP obtains the downstream bandwidth of the DSL link from the management system and uses the Configured DSL Downstream Bandwidth attribute to inform the HG. The HG uses the received downstream bandwidth as the base in calculating the bypassing bandwidth. The DSL GRE Tunnel Setup Accept message MUST include the Configured DSL Downstream Bandwidth attribute.
HAAPは、管理システムからDSLリンクのダウンストリーム帯域幅を取得し、構成済みDSLダウンストリーム帯域幅属性を使用してHGに通知します。 HGは、受信したダウンストリーム帯域幅を、バイパス帯域幅の計算のベースとして使用します。 DSL GREトンネルセットアップ受け入れメッセージには、構成済みDSLダウンストリーム帯域幅属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
|Configured DSL Downstream Bandwidth(4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Configured DSL Downstream Bandwidth, set to 23.
属性タイプ構成済みDSLダウンストリーム帯域幅、23に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
Configured DSL Downstream Bandwidth An unsigned integer measured in kbps.
構成済みDSLダウンストリーム帯域幅kbpsで測定される符号なし整数。
The HAAP uses the RTT Difference Threshold Violation attribute to inform the HG of the number of times in a row that the RTT Difference Threshold (see Section 5.2.4) may be violated before the HG MUST stop using the LTE GRE tunnel. If the RTT Difference Threshold is continuously violated for more than the indicated number of measurements, the HG MUST stop using the LTE GRE tunnel. The LTE GRE Tunnel Setup Accept message MUST include the RTT Difference Threshold Violation attribute.
HAAPは、RTT差分しきい値違反属性を使用して、HGがLTE GREトンネルの使用を停止する前に、RTT差分しきい値（セクション5.2.4を参照）に違反する可能性がある行の回数をHGに通知します。 RTT Difference Thresholdが指定された測定数を超えて継続的に違反する場合、HGはLTE GREトンネルの使用を停止しなければなりません（MUST）。 LTE GRE Tunnel Setup Acceptメッセージには、RTT Difference Threshold Violation属性が含まれている必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| RTT Diff Threshold Violation (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
RTT Difference Threshold Violation, set to 24.
Attribute Length Set to 4.
属性の長さを4に設定。
RTT Difference Threshold Violation An unsigned integer that takes values in the range 1 through 25. A typical value is 3.
RTT差分しきい値違反1〜25の範囲の値を取る符号なし整数。一般的な値は3です。
The HAAP uses the RTT Difference Threshold Compliance attribute to inform the HG of the number of times in a row that the RTT Difference Threshold (see Section 5.2.4) must be compliant before use of the LTE GRE tunnel can be resumed. If the RTT Difference Threshold is continuously detected to be compliant across more than this number of measurements, the HG MAY resume using the LTE GRE tunnel. The LTE GRE Tunnel Setup Accept message MUST include the RTT Difference Threshold Compliance attribute.
HAAPは、RTT差分しきい値コンプライアンス属性を使用して、LTE GREトンネルの使用を再開する前に、RTT差分しきい値（セクション5.2.4を参照）が準拠している必要があることを連続してHGに通知します。 RTT Difference Thresholdが継続的に検出され、この数を超える測定に準拠している場合、HGはLTE GREトンネルの使用を再開できます（MAY）。 LTE GRE Tunnel Setup Acceptメッセージには、RTT Difference Threshold Compliance属性が含まれている必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| RTT Diff Threshold Compliance (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type RTT Difference Threshold Compliance, set to 25.
属性タイプRTT差分しきい値コンプライアンス、25に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
RTT Difference Threshold Compliance An unsigned integer that takes values in the range 1 through 25. A typical value is 3.
RTT差分しきい値コンプライアンス1〜25の範囲の値を取る符号なし整数。通常の値は3です。
The HAAP uses the Idle Hello Interval attribute to inform the HG of the pre-configured interval for sending out GRE Tunnel Hellos when the subscriber is detected to be idle. The HG SHOULD begin to send out GRE Tunnel Hellos via both the DSL and LTE WAN interfaces in each time period as indicated by this interval, if the bonded tunnels have seen no traffic for a period longer than the "No Traffic Monitored Interval" (see Section 5.2.15). The LTE GRE Tunnel Setup Accept message MUST include the Idle Hello Interval attribute.
HAAPはIdle Hello Interval属性を使用して、加入者がアイドル状態であることが検出されたときに、GREトンネルHelloを送信するための事前設定された間隔をHGに通知します。ボンディングされたトンネルが「トラフィック監視なし間隔」より長い期間トラフィックを検出しなかった場合、HGは、この間隔で示される各期間でDSLおよびLTE WANインターフェイスの両方を介してGREトンネルHelloの送信を開始する必要があります（参照）。セクション5.2.15）。 LTE GRE Tunnel Setup Acceptメッセージには、Idle Hello Interval属性が含まれている必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Idle Hello Interval (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Idle Hello Interval, set to 31.
属性タイプIdle Hello Interval、31に設定。
Attribute Length Set to 4.
属性の長さを4に設定。
Idle Hello Interval An unsigned integer measured in seconds. This value can be chosen in the range 100 through 86,400 (24 hours) with a granularity of 100. The default value is 1800 (30 minutes).
Idle Hello Interval秒単位で測定される符号なし整数。この値は100から86,400（24時間）の範囲で100の粒度で選択できます。デフォルト値は1800（30分）です。
The HAAP uses the No Traffic Monitored Interval attribute to inform the HG of the pre-configured interval for switching the GRE Tunnel Hello mode. If traffic is detected on the bonded GRE tunnels before this interval expires, the HG SHOULD switch to the Active Hello Interval. The LTE GRE Tunnel Setup Accept message MUST include the No Traffic Monitored Interval attribute.
HAAPは、No Traffic Monitored Interval属性を使用して、GREトンネルHelloモードを切り替えるための事前設定された間隔をHGに通知します。この間隔が切れる前に結合されたGREトンネルでトラフィックが検出された場合、HGはアクティブなHello間隔に切り替えるべきです（SHOULD）。 LTE GRE Tunnel Setup Acceptメッセージには、No Traffic Monitored Interval属性が含まれている必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| No Traffic Monitored Interval (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
No Traffic Monitored Interval, set to 32.
Attribute Length Set to 4.
属性の長さを4に設定。
No Traffic Monitored Interval An unsigned integer measured in seconds. This value is in the range 30 through 86,400 (24 hours). The default value is 60.
モニターされていないトラフィック間隔秒単位で測定される符号なし整数。この値は、30から86,400（24時間）の範囲です。デフォルト値は60です。
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.
このHGからのGREトンネルセットアップ要求が拒否された場合、HAAPはGREトンネルセットアップ拒否メッセージをHGに送信する必要があります。 HGは、GREトンネルセットアップ拒否メッセージを受信するとすぐに、GREトンネルセットアッププロセスを終了する必要があります。
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.
HAAPはエラーコード属性を使用して、HGにエラーコードを通知します。エラーコードは、GREトンネルセットアップリクエストが拒否された理由を示しています。 LTE GREトンネルセットアップ拒否メッセージとDSL GREトンネルセットアップ拒否メッセージの両方に、エラーコード属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Error Code (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Error Code, set to 17.
属性タイプエラーコード、17に設定。
Attribute Length Set to 4.
属性の長さを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.
1：GREトンネルセットアップリクエスト中にLTE経由でHAAPに到達できませんでした。
2: The HAAP was not reachable via DSL during the GRE Tunnel Setup Request.
2：GREトンネルセットアップリクエスト中に、HAAPがDSL経由で到達できませんでした。
3: The LTE GRE tunnel to the HAAP failed.
3：HAAPへのLTE GREトンネルが失敗しました。
4: The DSL GRE tunnel to the HAAP failed.
4：HAAPへのDSL GREトンネルが失敗しました。
5: The given DSL User ID is not allowed to use the GRE Tunnel Bonding service.
5：指定されたDSLユーザーIDは、GREトンネルボンディングサービスの使用を許可されていません。
6: The given User Alias / User ID (Globally Unique Identifier (GUID)) is not allowed to use the GRE Tunnel Bonding service.
6：指定されたユーザーエイリアス/ユーザーID（グローバル一意識別子（GUID））は、GREトンネルボンディングサービスの使用を許可されていません。
7: The LTE and DSL User IDs do not match.
7：LTEとDSLのユーザーIDが一致しません。
8: The HAAP denied the GRE Tunnel Setup Request because a bonding session with the same User ID already exists.
8：同じユーザーIDのボンディングセッションが既に存在するため、HAAPはGREトンネルセットアップ要求を拒否しました。
9: The HAAP denied the GRE Tunnel Setup Request because the user's CIN is not permitted.
9：ユーザーのCINが許可されていないため、HAAPはGREトンネルセットアップ要求を拒否しました。
10: The HAAP terminated a GRE Tunnel Bonding session for maintenance reasons.
10：HAAPはメンテナンス上の理由でGREトンネルボンディングセッションを終了しました。
11: There was a communication error between the HAAP and the management system during the LTE GRE Tunnel Setup Request.
11：LTE GREトンネルセットアップリクエスト中に、HAAPと管理システムの間に通信エラーが発生しました。
12: There was a communication error between the HAAP and the management system during the DSL GRE Tunnel Setup Request.
12：DSL GREトンネルセットアップリクエスト中に、HAAPと管理システムの間に通信エラーが発生しました。
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.
DSL / LTE GREトンネルが確立された後、HGは、GREトンネルのHelloメッセージをトンネル経由で定期的に送信し始めます。 HAAPは、GREトンネルのHelloメッセージをHGに返すことにより、HGのメッセージを確認します。これは、トンネルが終了するまで続きます。
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.
HAAPはTimestamp属性を使用して、RTT計算に使用されるタイムスタンプ値をHGに通知します。 LTE GREトンネルのHelloメッセージとDSL GREトンネルのHelloメッセージの両方に、タイムスタンプ属性を含める必要があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Timestamp (8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
Timestamp, set to 5.
Attribute Length Set to 8.
属性の長さを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.
タイムスタンプシステムが再起動してからの時間。上位4バイトは、1秒単位の符号なし整数を示します。下位4バイトは、1ミリ秒単位の符号なし整数を示します。
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.
HAAPは、HAAP属性によって割り当てられたIPv6プレフィックスを使用して、割り当てられたIPv6プレフィックスをHGに通知します。このIPv6プレフィックスは合法的傍受を介してキャプチャされます。 LTE GRE Tunnel HelloメッセージとDSL GRE Tunnel Helloメッセージの両方に、HAAP属性によって割り当てられたIPv6プレフィックスを含める必要があります。
+-+-+-+-+-+-+-+-+
|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.
HAAPによって割り当てられた属性タイプIPv6プレフィックス、13に設定。
Attribute Length Set to 17.
属性の長さを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.
HAAPによって割り当てられるIPv6プレフィックス最上位の16バイトはIPv6アドレスをエンコードします。最下位の1バイトはプレフィックス長をエンコードします。これら2つの値を組み合わせて、IPv6プレフィックスを表します。
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.
HAAPは、GREトンネルティアダウンメッセージをトンネル経由でHGに送信することにより、DSL / LTE GREトンネルを終了できます。セクション5.3.1で定義されているエラーコード属性をこのメッセージに含める必要があります。 GREトンネルティアダウンメッセージを受信した後、HGはHのIPアドレスを削除します。これは、DSLおよびLTE GREトンネルの宛先IPアドレスです。
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.
HGとHAAPは、DSL GREトンネルまたはLTE GREトンネルのいずれかを介して送信されるGREトンネル通知メッセージを使用して、DSL / LTE GREトンネルに関するそれらのステータス、結合されたトンネルに関する情報、とるべき行動など
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).
通常、受信者は、受信した属性を各GREトンネル通知メッセージの確認応答として送り返すだけです。ただし、フィルターリストパッケージには例外があります。フィルターリストパッケージ属性のサイズは非常に大きくなる可能性があるため、特別な属性（フィルターリストパッケージACK属性）が確認応答として使用されます（セクション5.6.12を参照）。 ）。
Attributes that need to be included in the GRE Tunnel Notify message are defined below.
GREトンネル通知メッセージに含める必要がある属性を以下に定義します。
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.
結合されたGREトンネルではなく、未加工のDSL WANインターフェイスを介して送信する必要があるトラフィックにはいくつかのタイプがあります。 HGは、これらのトラフィックタイプのDSL WANインターフェイスにバイパス帯域幅を確保する必要があります。したがって、DSL GREトンネルの使用可能な帯域幅は、DSL WANインターフェイス帯域幅全体から占有バイパス帯域幅を差し引いたものです。
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].
HGはバイパストラフィックレート属性を使用して、DSL WANインターフェイスのダウンストリームバイパス帯域幅をHAAPに通知します。バイパストラフィックレート属性は、DSL GREトンネル通知メッセージに含まれます。 HAAPは、DSL GREトンネルの使用可能なダウンストリーム帯域幅を、構成済みDSLダウンストリーム帯域幅からHGによって提供されるバイパス帯域幅を引いたものとして計算します。利用可能なDSL帯域幅は、着色システム[RFC2697]のCIRとして使用されます。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Bypass Traffic Rate (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type
Bypass Traffic Rate, set to 6.
Attribute Length Set to 4.
属性の長さを4に設定。
Bypass Traffic Rate An unsigned integer measured in kbps.
バイパストラフィックレートkbpsで測定される符号なし整数。
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.
HAAPはFilter List Package属性を使用して、結合されたGREトンネルをバイパスする必要があるサービスタイプをHGに通知します。すべてのフィルターアイテムの完全なリストは、それぞれが部分的なリストを指定する一連のフィルターリストパッケージ属性で指定できます。 HGでは、フィルターアイテムの完全なリストが維持されます。また、HGはフィルターアイテムの例外リストを維持する必要があります。たとえば、このドキュメントで定義されている制御メッセージを運ぶパケットは、フィルタリストから除外する必要があります。
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.
フィルターリストのフィルターアイテムに一致し、例外リストのアイテムに一致しない着信パケットは、結合されたGREトンネルではなく、未加工のDSLを介して送信する必要があります。 LTE GREトンネル通知メッセージとDSL GREトンネル通知メッセージの両方に、フィルターリストパッケージ属性が含まれる場合があります。 DSL GREトンネル通知メッセージが推奨されます。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Filter List TLV (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Filter List Package, set to 8.
属性タイプフィルターリストパッケージ、8に設定。
Attribute Length The total length of the Filter List TLV. The maximum allowed length is 969 bytes.
属性の長さフィルターリストTLVの全長。最大許容長は969バイトです。
Filter List TLV The Filter List TLV occurs one time in a Filter List Package attribute. It has the following format:
フィルターリストTLVフィルターリストTLVは、フィルターリストパッケージ属性で1回発生します。次の形式があります。
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.
Commit_Countフィルター項目リストのバージョンを識別する符号なし整数。バージョンはすべてのフィルターリストパッケージで共有され、新しいフィルターアイテムリストごとに単調に増加します。 HGは、新しいCommit_Countを受信したときに、フィルターアイテムリストを更新する必要があります。
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_Sum単一のフィルターリストパッケージ属性が制御メッセージをMTUより大きくする可能性がある場合は、断片化が使用されます。 Packet_Sumは、フラグメントの総数を示します。
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.
Packet_IDこのフィルターリストパッケージ属性の断片化インデックス。各フラグメントには、1から始まり、Packet_Sumまで1ずつ番号が付けられます。
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.
フィルター項目が有効かどうかを示す整数。値1は「有効」を意味し、値0は「無効」を意味します。他の可能な値は予約されており、受信時に無視する必要があります。
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").
説明値フィルターリストのTLVを説明する、UTF-8でエンコードされた可変長文字列値（たとえば、「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 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 (":").
値フィルターアイテムの値を指定するUTF-8でエンコードされた可変長文字列（例： "www.yahoo.com"）。例として、Type = 1およびValue = "www.yahoo.com"は、FQDNフィールドが "www.yahoo.com"に等しいパケットがフィルターアイテムに一致することを意味します。 「ソースMAC」（ソースメディアアクセスコントロールアドレス）の値は、16進数で指定します。ポート番号は、[Port-NO]でIANAによって割り当てられた10進数です。 「プロトコル」タイプの場合、値は、10進数または[Pro-NO]でIANAによって指定されたキーワードのいずれかになります。 IPアドレスとIPアドレスの範囲の形式は、IPv4とIPv6のそれぞれについて[RFC4632]と[RFC4291]で定義されています。タイプ5、8、13、または14のフィルター項目は、2つのパラメーターの組み合わせです。 2つのパラメーターの値は、コロン（ "："）で区切られます。
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.
RTT差分が継続的に検出され、RTT差分しきい値（セクション5.2.4を参照）に違反していることが、RTT差分しきい値違反属性（セクション5.2.12を参照）で指定された回数を超えた場合、HGはスイッチングを使用します。 DSL GREトンネルのみを使用するようにHAAPに通知するには、DSLトンネル属性に。 HAAPがこの属性を受信すると、DSL GREトンネルを介してのみこのHGへのダウンストリームトラフィックの送信を開始する必要があります。 DSL GREトンネル通知メッセージには、DSLトンネルへの切り替え属性が含まれる場合があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type Switching to DSL Tunnel, set to 11.
DSLトンネルへの属性タイプの切り替え、11に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
RTT差異が継続的に検出され、RTT差異しきい値（セクション5.2.4を参照）に違反していないことが、RTT差異しきい値コンプライアンス属性（セクション5.2.13を参照）で指定された回数を超えない場合、HGはLTE GREトンネルを再び使用できることをHAAPに通知するためのLTEトンネル属性へのオーバーフロー。 DSL GREトンネル通知メッセージには、LTEトンネルへのオーバーフロー属性が含まれる場合があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
Overflowing to LTE Tunnel, set to 12.
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
HGは、DSL WANインターフェイスステータスが「ダウン」であることを検出すると、DSL GREトンネルを破棄する必要があります。 DSLリンク障害属性を使用して、障害についてHAAPに通知します。 HAAPは、DSLリンク障害属性を受信すると、DSL GREトンネルを破棄する必要があります。 DSLリンク障害属性は、LTE GREトンネル通知メッセージで伝達される必要があります（SHOULD）。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type DSL Link Failure, set to 18.
属性タイプDSLリンク障害、18に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
HGは、LTE WANインターフェイスのステータスが「ダウン」であることを検出すると、LTE GREトンネルを破棄する必要があります。 LTEリンク障害属性を使用して、障害についてHAAPに通知します。 HAAPは、LTEリンク障害属性を受信すると、LTE GREトンネルを破棄する必要があります。 LTEリンク障害属性は、DSL GREトンネル通知メッセージで伝達される必要があります（SHOULD）。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type LTE Link Failure, set to 19.
属性タイプLTEリンク障害、19に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
HGがホストに割り当てられたIPv6プレフィックスを変更した場合、HGはホストに割り当てられたIPv6プレフィックス属性を使用してHAAPに通知します。 LTE GREトンネル通知メッセージとDSL GREトンネル通知メッセージの両方に、ホスト属性に割り当てられたIPv6プレフィックスが含まれる場合があります。
+-+-+-+-+-+-+-+-+
|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.
ホストに割り当てられた属性タイプIPv6プレフィックス、21に設定。
Attribute Length Set to 17.
属性の長さを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.
ホストに割り当てられたIPv6プレフィックス最上位の16バイトはIPv6アドレスをエンコードします。最下位の1バイトはプレフィックス長をエンコードします。これら2つの値を組み合わせて、IPv6プレフィックスを表します。
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.
HGは、Diagnostic Start：Bonding Tunnel属性を使用して、HAAPに診断モードに切り替えて、ボンディングトンネル全体のパフォーマンスをテストするよう通知します。 Diagnostic Start：Bonding Tunnel属性は、DSL GRE Tunnel Notifyメッセージで伝達される必要があります（SHOULD）。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type Diagnostic Start: Bonding Tunnel, set to 26.
属性タイプ診断開始：ボンディングトンネル、26に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
HGは、Diagnostic Start：DSL Tunnel属性を使用して、HAAPに診断モードに切り替え、DSL GREトンネルのパフォーマンスをテストするよう通知します。 Diagnostic Start：DSL Tunnel属性は、DSL GRE Tunnel Notifyメッセージで伝達される必要があります（SHOULD）。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type Diagnostic Start: DSL Tunnel, set to 27.
属性タイプ診断開始：DSLトンネル、27に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
HGは、Diagnostic Start：LTE Tunnel属性を使用して、HATEに診断モードに切り替えてLTE GREトンネルのパフォーマンスをテストするよう通知します。 Diagnostic Start：LTE Tunnel属性は、DSL GRE Tunnel Notifyメッセージで伝達される必要があります（SHOULD）。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type Diagnostic Start: LTE Tunnel, set to 28.
属性タイプ診断開始：LTEトンネル、28に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
HGはDiagnostic End属性を使用して、HAAPに診断モードでの動作を停止するよう通知します。診断終了属性は、DSL GREトンネル通知メッセージで伝達される必要があります（SHOULD）。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type Diagnostic End, set to 29.
属性タイプ診断終了、29に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
HGは、フィルターリストパッケージのACK属性を使用して、HAAPによって送信されたフィルターリストパッケージを確認します。 LTE GREトンネル通知メッセージとDSL GREトンネル通知メッセージの両方に、フィルターリストパッケージのACK属性が含まれている場合があります。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Filter List Package ACK (5 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Attribute Type Filter List Package ACK, set to 30.
属性タイプフィルターリストパッケージACK、30に設定。
Attribute Length Set to 5.
属性の長さを5に設定。
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:
フィルターリストパッケージのACK最上位の4バイトは、セクション5.6.2で定義されているCommit_Countです。最下位の1バイトは、次のエラーコードをエンコードします。
0: The Filter List Package is acknowledged.
0：フィルターリストパッケージが確認されます。
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.
1：フィルターリストパッケージは確認されていません。 HGは新しいサブスクライバーであり、フィルターリストパッケージをまだ受け取っていません。この場合、HAAPはボンディングトンネルを破棄し、HGにGREトンネルの再確立を強制する必要があります（SHOULD）。
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.
2：フィルターリストパッケージは確認されていません。 HGは既に有効なフィルターリストパッケージを取得しています。 HGのフィルターリストは引き続き使用されますが、HAAPは何もする必要はありません。
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.
「トラフィック監視間隔なし」の期限が切れる前にトラフィックがボンディングGREトンネルを介して送受信されている場合（セクション5.2.15を参照）、HGはHAAPに、Switching to Active Hello State属性を含むGREトンネル通知メッセージを送信します。
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.
HAAPはActive Hello Stateに切り替え、HGにGRE Tunnel Notifyメッセージを送信し、Switching to Active Hello State属性を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).
HGがACKを受信すると、アクティブなHello状態に切り替わり、RTT検出を開始し、アクティブなHello間隔でGREトンネルのHelloメッセージの送信を開始します（セクション5.2.6を参照）。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type Switching to Active Hello State, set to 33.
属性タイプのアクティブなHello状態への切り替え、33に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
GREトンネルのボンディングが正常に確立され、Idle Hello Interval属性（5.2.14項を参照）を含むLTE GRE Tunnel Setup Acceptメッセージが受信されると、HGはIdle Hello状態への切り替えを開始します。 HGはHAAPに、Switching to Idle Hello State属性を含むGRE Tunnel Notifyメッセージを送信します。
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.
HAAPはIdle Hello Stateに切り替え、RTT状態をクリアし、HGに、Switching to Idle Hello State属性をACKとして伝送するGREトンネル通知メッセージを送信します。
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).
HGがACKを受信すると、（1）アイドルハロー状態に切り替わり、（2）RTT検出を停止してRTT状態をクリアし、（3）アイドルハロー間隔でGREトンネルハローメッセージの送信を開始します（セクション5.2.14を参照）。 ）。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type Switching to Idle Hello State, set to 34.
アイドルタイプHelloステートへの属性タイプの切り替え。34に設定します。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
HAAPはTunnel Verification属性を使用してHGに通知し、既存のLTE GREトンネルがまだ機能しているかどうかを確認します。トンネル検証属性は、LTE GREトンネル通知メッセージで伝達される必要があります（SHOULD）。これは、特にLTE GREトンネルがアイドルHello状態にあり、このトンネルの検出に非常に長い時間がかかる場合に、GREトンネルHelloよりも速くトンネルを検出する手段を提供します。
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.
HAAPがLTE GREトンネルセットアップ要求を受信し、要求されたトンネルが既存のトンネルと競合していることを検出すると、HAAPはトンネル検証を開始します。 HAAPは、すべての競合するLTE GREトンネルセットアップ要求メッセージをドロップし、検証が終了するまで、トンネル検証属性を伝えるGREトンネル通知メッセージを送信します。 HGは、トンネルがまだ機能している場合、ACKと同じトンネル検証属性でHAAPに応答する必要があります。
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.
HGからトンネル検証属性のACKを受信した場合、HAAPは既存のトンネルがまだ機能していると判断します。 LTE GREトンネル拒否メッセージ（エラーコード= 8）がHGに送信されます。 HGはGREトンネルセットアップリクエストプロセスをすぐに終了する必要があります。
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.
HAAPが3回の試行（1回の初期試行と2回の再試行）の後にトンネル検証ACKメッセージを受信しない場合、既存のトンネルは失敗したと見なされ、LTE GREトンネルセットアップ要求が受け入れられます。
+-+-+-+-+-+-+-+-+
|Attribute Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type Tunnel Verification, set to 35.
属性タイプトンネル検証、35に設定。
Attribute Length Set to 0.
属性の長さを0に設定します。
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.
GREトンネルは、HGとHAAP間のLTEやDSLなどの異種接続を介して設定されます。ユーザーのIP（内部）パケットはGREパケットにカプセル化され、GREパケットはIP（外部）パケットで運ばれます。 GREトンネルボンディングプロトコルのデータパケットの一般的な構造を以下に示します。
+--------------------------------+
| Media Header |
+--------------------------------+
| Outer IP Header |
+--------------------------------+
| GRE Header |
+--------------------------------+
| Inner IP Packet |
+--------------------------------+
The GRE header was first standardized in [RFC2784]. [RFC2890] added the optional Key and Sequence Number fields.
GREヘッダーは、[RFC2784]で最初に標準化されました。 [RFC2890]は、オプションのキーとシーケンス番号フィールドを追加しました。
The Checksum and the Reserved1 fields are not used in the GRE Tunnel Bonding; therefore, the C bit is set to 0.
チェックサムおよびReserved1フィールドは、GREトンネルボンディングでは使用されません。したがって、Cビットは0に設定されます。
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).
キービットは1に設定されているため、キーフィールドが存在します。キーフィールドは、32ビットの乱数として使用されます。ボンディング接続ごとにHAAPによって生成され、HGに通知されます（セクション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].
Sビットは1に設定され、[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:
GREヘッダーのプロトコルタイプフィールドは、IPv4の場合は0x0800に、IPv6の場合は0x86DDに設定する必要があります。したがって、GREトンネルボンディングプロトコルのデータパケットで使用されるGREヘッダーの形式は次のとおりです。
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
図3：GREトンネルボンディングのデータパケットのGREヘッダー
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.
HGは、ポイントツーポイントプロトコルオーバーイーサネット（PPPoE）を介してブロードバンドリモートアクセスサーバー（BRAS）からDSL WANインターフェイスIPアドレス（D）を取得し、パケットデータプロトコルを介してLTE WANインターフェイスIPアドレス（E）を取得します（PDP）パケットデータネットワークゲートウェイ（PGW）から。 HAAPグループのドメイン名は、[TR-069]などのゲートウェイ構成プロトコルに基づいてDSL / LTE WANインターフェイスを介して構成または取得できます。HAAPグループは1つまたは複数のHAAPで構成されます。 HAAPグループのドメイン名のドメインネームシステム（DNS）解決は、DSL / LTE WANインターフェイスを介して要求されます。 DNSサーバーはエニーキャストHAAP IPアドレス（G）で応答します。GAPはオペレーターが事前に構成できます。
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.
インターフェースIPアドレスが取得されると、HGは次のGREトンネルボンディング手順を開始します。 HGが最初にLTE GREトンネルをセットアップし、次にDSL GREトンネルをセットアップする必要があります。
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 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.
HGは、LTE WANインターフェイスを介してGREトンネルセットアップ要求メッセージをHAAPに送信します。このメッセージの外部ソースIPアドレスはLTE WANインターフェースIPアドレス（E）ですが、外部宛先IPアドレスはエニーキャストHAAP IPアドレス（G）です。 GREトンネルセットアップリクエストメッセージを受信するHAAPグループ内の最高の優先度（HGが到達するための最小コストパスを持つものなど）を持つHAAPは、[で指定されているように、認証と承認の手順を開始します。 TS23.401]、HGが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.
認証と承認が成功した場合、HAAPは、GREトンネルセットアップリクエストメッセージから取得したLTE WANインターフェースIPアドレス（E）（つまり、外部ソースIPアドレス）を、GREトンネルの宛先エンドポイントIPアドレスとして設定します。そして、HAAPのIPアドレス（H）（たとえば、HAAP内のラインカードのIPアドレス）とHAAPによってランダムに生成されたセッションIDが含まれているGREトンネルセットアップ受け入れメッセージでHGのLTE WANインターフェイスに応答します。属性として運ばれます。このメッセージの外部ソースIPアドレスはIPアドレス（H）またはエニーキャストHAAP IPアドレス（G）で、外部宛先IPアドレスはLTE WANインターフェースIPアドレス（E）です。それ以外の場合、HAAPはHGのLTE WANインターフェイスにGREトンネルセットアップ拒否メッセージを送信する必要があり、HGはGREトンネルセットアップ拒否メッセージを受信すると、トンネルセットアッププロセスを終了する必要があります。
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.
LTE GREトンネルが正常にセットアップされた後、HGは動的ホスト構成プロトコル（DHCP）を介してHAAPからトンネル経由でCアドレス（図1を参照）を取得します。その後、HGはDSL GREトンネルのセットアップを開始します。 HAAPから受信した前述のセッションIDを伝達して、DSL WANインターフェイスを介してGREトンネルセットアップ要求メッセージを送信します。このメッセージの外部送信元IPアドレスはDSL WANインターフェイスIPアドレス（D）ですが、外部宛先IPアドレスはHAAPのIPアドレス（H）です。 GREトンネルセットアップ要求メッセージを受信したHAAPは、HGが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.
認証と承認が成功した場合、HAAPはGREトンネルセットアップ要求メッセージから取得したDSL WANインターフェイスIPアドレス（D）（つまり、その外部ソースIPアドレス）をGREトンネルの宛先エンドポイントIPアドレスとして設定しますHGのDSL WANインターフェイスにGREトンネルセットアップ受け入れメッセージで応答します。このメッセージの外部送信元IPアドレスはHAAPのIPアドレス（H）であり、外部宛先IPアドレスはDSL WANインターフェイスIPアドレス（D）です。このようにして、同じセッションIDを持つ2つのトンネルを使用して、同じユーザーからのトラフィックを伝送できます。つまり、2つのトンネルは「結合」されています。それ以外の場合、認証と承認が失敗すると、HAAPはHGのDSL WANインターフェイスにGREトンネルセットアップ拒否メッセージを送信する必要があります。その間、HGのLTE WANインターフェイスにGREトンネルティアダウンメッセージを送信する必要があります。 HGは、GREトンネルセットアップ拒否メッセージを受信するとトンネルセットアッププロセスを終了し、GREトンネルティアダウンメッセージを受信するとセットアップされたLTE GREトンネルを破棄する必要があります。
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.
攻撃者によって制御される悪意のあるデバイスは、GREトンネルで送信される制御メッセージを傍受する可能性があります。後で、不正なデバイスが制御メッセージを偽造して、GREトンネルを妨害したり、ターゲット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.
セキュリティ機能として、制御メッセージとデータパケットのGREヘッダーのキーフィールドは32ビットのクリアテキストパスワードとして生成されますが、HGからHAAPに送信されたボンディング接続ごとの最初のGREセットアップ要求メッセージは例外です。キーフィールドはすべてゼロで埋められます。 HAAPとHGはキー値と外部ソースIPアドレスを検証し、無効な組み合わせのパケットを破棄します。
Moreover, GRE over IP Security (IPsec) could be used to enhance security.
さらに、GRE over IP Security（IPsec）を使用してセキュリティを強化できます。
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.
IANAは、GREトンネルボンディングプロトコルに何も割り当てる必要はありません。 GREチャネルのEthertypeであるGREプロトコルタイプは0xB7EAに設定されており、これはIEEE登録局の制御下にあります。ただし、IANAは「IEEE 802番号」IANA Webページ[802Type]を更新しました。これは主に歴史的な関心事です。
[Port-NO] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers>.
[Port-NO] IANA、「サービス名およびトランスポートプロトコルのポート番号レジストリ」、<http://www.iana.org/assignments/ service-names-port-numbers>。
[Pro-NO] IANA, "Assigned Internet Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
[Pro-NO] IANA、「割り当てられたインターネットプロトコル番号」、<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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC2697] Heinanen、J。およびR. Guerin、「A Single Rate Three Color Marker」、RFC 2697、DOI 10.17487 / RFC2697、1999年9月、<http://www.rfc-editor.org/info/rfc2697>。
[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>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<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>.
[RFC2890] Dommety、G。、「GREのキーとシーケンス番号の拡張」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<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>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<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>.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<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>.
[TR-069]ブロードバンドフォーラム、「CPE WAN管理プロトコル」、問題：2013年11月1日改訂5、<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.
[TS23.401] 3GPP TS23.401、「進化したユニバーサル地上無線アクセスネットワーク（E-UTRAN）アクセスのための一般的なパケット無線サービス（GPRS）の拡張機能」、v11.7.0、2013年9月。
[802Type] IANA, "IEEE 802 Numbers", <http://www.iana.org/assignments/ieee-802-numbers>.
[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.
[ANSI-X9.31-1998] ANSI規格X9.31-1998、「金融サービス業界向けのリバーシブル公開キー暗号化（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>.
[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>.
[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 、2011年10月、<http://www.rfc-editor.org/info/rfc6320>。
[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>.
[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>.
[RFC7031] Mrugalski、T。およびK. Kinnear、「DHCPv6フェイルオーバー要件」、RFC 7031、DOI 10.17487 / RFC7031、2013年9月、<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>.
[RFC7676] Pignataro、C.、Bonica、R。、およびS. Krishnan、「IPv6 Support for Generic Routing Encapsulation（GRE）」、RFC 7676、DOI 10.17487 / RFC7676、2015年10月、<http：//www.rfc- editor.org/info/rfc7676>。
Contributors
貢献者
Li Xue Individual Email: xueli_jas@163.com
l IX UE個別メール：Education_JA死@ 163.com
Zhongwen Jiang Huawei Technologies Email: jiangzhongwen@huawei.com
Z Hongwen Jiang hu Aはテクノロジーメールです：Chinese @华华.comを話します
Authors' Addresses
著者のアドレス
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21-27 Berlin 10781 Germany Phone: +49-170-2275345 Email: n.leymann@telekom.de
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21-27 Berlin 10781 Germany電話：+ 49-170-2275345メール：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
Cornelius Heidemann Deutsche Telekom AG Heinrich-Hertz-Strasse 3-7 Darmstadt 64295 Germany電話：+ 49-6151-5812721メール：heidemannc@telekom.de
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China Email: zhangmingui@huawei.com
min鬼Zhang hu Aはテクノロジーno。156 be iqing RD。Hショートポイントディストリクト北京100095中国Eメール：Zhang Mingui@Huawei.com
Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 3 Plano, TX 75024 United States of America Email: sarikaya@ieee.org
Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 3 Plano、TX 75024 United States 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
マーガレットカレンペインレスセキュリティ14 Summer St. Suite 202モールデン、マサチューセッツ02148アメリカ合衆国メール：margaret@painless-security.com