[要約] RFC 9188は、Generic Multi-Access (GMA) Encapsulation Protocolに関する文書で、異なるネットワーク技術間でのデータの透過的な伝送を可能にするプロトコルを定義しています。その目的は、異種ネットワーク環境におけるデータの統一的な扱いを実現することにあり、主にモバイルネットワークや固定ネットワークの統合、IoTデバイスの接続など多様な利用場面で活用されます。
Independent Submission J. Zhu
Request for Comments: 9188 Intel
Category: Experimental S. Kanugovi
ISSN: 2070-1721 Nokia
February 2022
Generic Multi-Access (GMA) Encapsulation Protocol
一般的なマルチアクセス（GMA）カプセル化プロトコル
Abstract
概要
A device can be simultaneously connected to multiple networks, e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve the quality of experience for applications that do not have built-in multi-path capabilities. Such optimization requires additional control information, e.g., a sequence number, in each packet. This document presents a new lightweight and flexible encapsulation protocol for this need. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP. However, this document is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations in order to experiment with the protocol.
装置は、例えば、Wi - Fi、LTE、5g、およびDSLに同時に接続することができる。マルチパス機能を内蔵していないアプリケーションの経験の質を向上させるために、これらのネットワーク上の接続性をトランスポート層（L4）の下にシームレスに組み合わせることが望ましい。そのような最適化は、各パケットにおいて、追加の制御情報、例えばシーケンス番号を必要とする。この文書はこのニーズのための新しい軽量で柔軟なカプセル化プロトコルを示しています。このソリューションは、IETFと3GPPを含む複数の標準機関における経験に基づいて著者によって開発されました。ただし、この文書はインターネット規格ではなく、IETFの合意意見を表していません。この文書は、他の開発者がプロトコルを実験するために相互運用可能な実装を構築することを可能にします。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットコミュニティの実験プロトコルを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディタは、この文書をその判断で公開することを選択し、実装または展開の値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9188.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frofc9188で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
1.1. Scope of Experiment
2. Conventions Used in This Document
3. Use Case
4. GMA Encapsulation Methods
4.1. Trailer-Based IP Encapsulation
4.2. Header-Based IP Encapsulation
4.3. Header-Based Non-IP Encapsulation
4.4. IP Protocol Identifier
5. Fragmentation
6. Concatenation
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses
A device can be simultaneously connected to multiple networks, e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve the quality of experience for applications that do not have built-in multi-path capabilities.
装置は、例えば、Wi - Fi、LTE、5g、およびDSLに同時に接続することができる。マルチパス機能を内蔵していないアプリケーションの経験の質を向上させるために、これらのネットワーク上の接続性をトランスポート層（L4）の下にシームレスに組み合わせることが望ましい。
Figure 1 shows the Multi-Access Management Service (MAMS) user-plane protocol stack [MAMS], which has been used in today's multi-access solutions [ATSSS] [LWIPEP] [GRE1] [GRE2]. It consists of two layers: convergence and adaptation.
図1は、今日のマルチアクセスソリューション[ATSSS] [LWIPEP] [GRE1] [GRE1]で使用されてきたマルチアクセス管理サービス（MAMS）ユーザープレーンプロトコルスタック[MAMS]を示しています。それは2つの層から成ります。収束と適応。
The convergence layer is responsible for multi-access operations, including multi-link (path) aggregation, splitting/reordering, lossless switching/retransmission, fragmentation, concatenation, etc. It operates on top of the adaptation layer in the protocol stack. From the perspective of a transmitter, a User Payload (e.g., IP packet) is processed by the convergence layer first and then by the adaptation layer before being transported over a delivery connection; from the receiver's perspective, an IP packet received over a delivery connection is processed by the adaptation layer first and then by the convergence layer.
収束層は、マルチリンク（経路）集約、分割/並べ替え、可逆的な切替/再送、フラグメンテーション、連結などを含むマルチアクセス動作を担当する。プロトコルスタック内の適応層の上部に動作します。送信機の視点から、ユーザペイロード（例えば、IPパケット）は、最初に収束層によって処理され、次に配信接続を介して輸送される前に適応層によって処理される。受信機の観点からは、配信接続を介して受信されたIPパケットは、最初に適応層によって処理され、次に収束層によって処理される。
+-----------------------------------------------------+
| User Payload, e.g., IP Protocol Data Unit (PDU) |
+-----------------------------------------------------+
+-----------------------------------------------------------+
| +-----------------------------------------------------+ |
| | Multi-Access (MX) Convergence Layer | |
| +-----------------------------------------------------+ |
| +-----------------------------------------------------+ |
| | MX Adaptation | MX Adaptation | MX Adaptation | |
| | Layer | Layer | Layer | |
| +-----------------+-----------------+-----------------+ |
| | Access #1 IP | Access #2 IP | Access #3 IP | |
| +-----------------------------------------------------+ |
| MAMS User-Plane Protocol Stack |
+-----------------------------------------------------------+
Figure 1: MAMS User-Plane Protocol Stack
図1：MAMSユーザープレーンプロトコルスタック
GRE (Generic Routing Encapsulation) [LWIPEP] [GRE1] [GRE2] can be used as the encapsulation protocol at the convergence layer to encode additional control information, e.g., key and sequence number. However, there are two main drawbacks with this approach:
GRE（GENERICルーティングカプセル化）[LWIPEP] [GRE1] [GRE2]は、コンバージェンス層のカプセル化プロトコルとして使用して、追加の制御情報、例えばキーおよびシーケンス番号を符号化することができる。ただし、この方法では2つの主な欠点があります。
* It is difficult to introduce new control fields because the GRE header formats are already defined, and
* GREヘッダーフォーマットが既に定義されているため、新しい制御フィールドを導入することは困難です。
* IP-over-IP tunneling (required for GRE) leads to higher overhead especially for small packets.
* IP-over-IPトンネリング（GREに必要）は、特に小さなパケットのオーバーヘッドの高さにつながります。
For example, the overhead of IP-over-IP/GRE tunneling with both key and sequence Number is 32 bytes (20-byte IP header + 12-byte GRE header), which is 80% of a 40-byte TCP ACK packet.
たとえば、キーとシーケンス番号の両方を使用したIP-over-IP / GREトンネリングのオーバーヘッドは、40バイトのTCP ACKパケットの80％である32バイト（20バイトIPヘッダー12バイトGREヘッダー）です。
This document presents a lightweight Generic Multi-Access (GMA) encapsulation protocol for the convergence layer. It supports three encapsulation methods: trailer-based IP encapsulation, header-based IP encapsulation, and non-IP encapsulation. Particularly, the IP encapsulation methods avoid IP-over-IP tunneling overhead (20 bytes), which is 50% of a 40-byte TCP ACK packet. Moreover, it introduces new control fields to support fragmentation and concatenation, which are not available in GRE-based solutions [LWIPEP] [GRE1] [GRE2].
この文書は、収束層のための軽量の一般的なマルチアクセス（GMA）カプセル化プロトコルを示しています。3つのカプセル化方法をサポートします。トレーラベースのIPカプセル化、ヘッダベースのIPカプセル化、および非IPカプセル化。特に、IPカプセル化方法は、40バイトのTCP ACKパケットの50％であるIP-over-IPトンネリングオーバーヘッド（20バイト）を回避します。さらに、GREベースのソリューション[LWIPEP] [GRE1] [GRE2]では使用できない断片化と連結をサポートするための新しい制御フィールドを導入します。
The GMA protocol only operates between endpoints that have been configured to use GMA. This configuration can be through any control messages and procedures, including, for example, Multi-Access Management Services [MAMS]. Moreover, UDP or IPsec tunneling can be used at the adaptation sublayer to protect GMA operation from intermediate nodes.
GMAプロトコルは、GMAを使用するように構成されているエンドポイント間でのみ動作します。この構成は、例えばマルチアクセス管理サービス[MAMS]を含む、任意の制御メッセージおよび手順を介して行うことができる。さらに、中間ノードからGMA動作を保護するために、UDPまたはIPSecトンネリングを適応サブレイヤで使用することができる。
The solution described in this document was developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP. However, this document is not an Internet Standard and does not represent the consensus opinion of the IETF. This document presents the protocol specification to enable experimentation as described in Section 1.1 and to facilitate other interoperable implementations.
この文書に記載されている解決策は、IETFおよび3GPPを含む複数の標準機関におけるそれらの経験に基づいて著者によって開発されました。ただし、この文書はインターネット規格ではなく、IETFの合意意見を表していません。この文書は、セクション1.1で説明されているような実験を可能にし、他の相互運用可能な実装を容易にするためのプロトコル仕様を提示します。
The protocol described in this document is an experiment. The objective of the experiment is to determine whether the protocol meets the requirements, can be safely used, and has support for deployment.
この文書に記載されているプロトコルは実験です。実験の目的は、プロトコルが要件を満たしているかどうかを安全に使用できるかどうかを判断し、展開をサポートしています。
Section 4 describes three possible encapsulation methods that are enabled by this protocol. Part of this experiment is to assess whether all three mechanisms are necessary or whether, for example, all implementations are able to support the main "trailer-based" IP encapsulation method. Similarly, the experiment will investigate the relative merits of the IP and non-IP encapsulation methods.
セクション4では、このプロトコルによって有効になっている3つの可能なカプセル化方法について説明します。この実験の一部は、3つのメカニズムすべてが必要かどうか、またはたとえばすべての実装がメインの「トレーラーベースのIPカプセル化方法をサポートできるかどうかを評価することです。同様に、実験は、IPおよび非IPカプセル化方法の相対的な利点を調査します。
It is expected that this protocol experiment can be conducted on the Internet since the GMA packets are identified by an IP protocol number and the protocol is intended for single-hop propagation; devices should not be forwarding packets, and if they do, they will not need to examine the payload, while destination systems that do not support this protocol should not receive such packets and will handle them as unknown payloads according to normal IP processing. Thus, experimentation is conducted between consenting end systems that have been mutually configured to participate in the experiment as described in Section 7.
GMAパケットはIPプロトコル番号によって識別され、プロトコルがシングルホップ伝播を目的としているので、このプロトコル実験はインターネット上で行われることが予想される。デバイスはパケットを転送しないでください。このプロトコルをサポートしていない宛先システムはそのようなパケットを受け取らず、通常のIP処理に従って未知のペイロードとしてそれらを処理する必要はなく、ペイロードを調べる必要はありません。したがって、セクション7に記載されているように、実験に参加するように互いに構成されている同意エンドシステム間で実験が行われる。
Note that this experiment "reuses" the IP protocol identifier 114 as described in Section 4.4. Part of this experiment is to assess the safety of doing this. The experiment should consider the following safety mechanisms:
この実験は、セクション4.4に記載されているように、IPプロトコル識別子114を「再開」することに留意されたい。この実験の一部はこれを行う安全性を評価することです。実験は以下の安全メカニズムを考慮する必要があります。
* GMA endpoints SHOULD detect non-GMA IP packets that also use 114 and log an error to report the situation (although such error logging MUST be subject to rate limits).
* GMAエンドポイントは、114を使用し、エラーを記録して状況を報告するためにエラーを記録した非GMA IPパケットを検出する必要があります（このようなエラーロギングはレート制限の対象となる必要があります）。
* GMA endpoints SHOULD stop using 114 and switch to non-IP encapsulation, i.e., UDP encapsulation (Figure 7), after detecting any non-GMA usage of 114.
* GMAエンドポイントは、114の非GMA使用法を検出した後、114の非IPカプセル化、すなわち非IPカプセル化、すなわちUDPカプセル化（図7）に切り替える必要があります。
The experiment SHOULD use a packet tracing tool, e.g., WireShark or TCPDUMP, to monitor both ingress and egress traffic at GMA endpoints and ensure the above safety mechanisms are implemented.
実験は、GMAエンドポイントでの入力と出力トラフィックの両方を監視し、上記の安全メカニズムを実装することを確実にするために、パケットトレースツール、例えばWireSharkまたはTCPDUMPを使用する必要があります。
Path quality measurements (one-way delay, loss, etc.) and congestion detection are performed by the receiver based on the GMA control fields, e.g., Sequence Number, Timestamp, etc. The receiver will then dynamically control how to split or steer traffic over multiple delivery connections accordingly. The GMA control protocol [GMAC] MAY be used for signaling between GMA endpoints. Another objective of the experiment is to evaluate the usage of various receiver-based algorithms [GCC] [MPIP] in multi-path traffic management and the impact on the End-to-End (E2E) performance (throughput, delay, etc.) of higher-layer (transport) protocols, e.g., TCP, QUIC, WebRTC, etc.
パス品質測定（一方向遅延、損失など）および輻輳検出は、GMA制御フィールド、例えばシーケンス番号、タイムスタンプなどに基づく受信機によって実行されます。受信機は、トラフィックを分割または操縦する方法を動的に制御します。それに応じて複数の配信接続にわたって。GMA制御プロトコル[GMAC]は、GMAエンドポイント間のシグナリングに使用することができる。実験のもう1つの目的は、マルチパス交通管理における各種レシーバベースのアルゴリズム[GCC] [MPIP]の使用と、エンドツーエンド（E2E）性能（スループット、遅延など）への影響を評価することです。TCP、QUIC、WebRTCなど、高層化（輸送）プロトコル
The authors will continually assess the progress of this experiment and encourage other implementers to contact them to report the status of their implementations and their experiences with the protocol.
著者らはこの実験の進行状況を継続的に評価し、他の実装者がそれらの実装の状況とプロトコルの経験を報告するためにそれらに連絡することを奨励します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
As shown in Figure 2, a client device (e.g., smartphone, laptop, etc.) may connect to the Internet via both Wi-Fi and LTE connections, one of which (e.g., LTE) may operate as the anchor connection, and the other (e.g., Wi-Fi) may operate as the delivery connection. The anchor connection provides the IP address and connectivity for end-to-end Internet access, and the delivery connection provides an additional path between the client and Multi-Access Gateway for multi-access optimizations.
図2に示すように、クライアント装置（例えば、スマートフォン、ラップトップなど）は、Wi - FiおよびLTE接続の両方を介してインターネットに接続され、そのうちの1つ（例えば、LTE）はアンカー接続として動作することがある。その他（例えば、Wi-Fi）は配信接続として動作することがあります。アンカー接続は、エンドツーエンドのインターネットアクセスのためのIPアドレスと接続を提供し、配信接続はマルチアクセス最適化のためにクライアントとマルチアクセスゲートウェイの間の追加のパスを提供します。
Multi-Access Aggregation
マルチアクセスアグリゲーション
+---+ +---+
| |A|--- LTE Connection -----|C| |
|U|-| |-|S| Internet
| |B|--- Wi-Fi Connection ---|D| |
+---+ +---+
client Multi-Access Gateway
Figure 2: GMA-Based Multi-Access Aggregation
図2：GMAベースのマルチアクセス集約
A: The adaptation-layer endpoint of the LTE connection resides in the client.
A：LTE接続の適応層の終点はクライアントにあります。
B: The adaptation-layer endpoint of the Wi-Fi connection resides in the client.
B：Wi-Fi接続の適応層終点はクライアントにあります。
C: The adaptation-layer endpoint of the LTE connection resides in the Multi-Access Gateway, aka N-MADP (Network Multi-Access Data Proxy) in [MAMS].
C：LTE接続の適応層の終点は、マルチアクセスゲートウェイ、[MAMS]のAKA N-MADP（ネットワークマルチアクセスデータプロキシ）にあります。
D: The adaptation-layer endpoint of the Wi-Fi connection resides in the Multi-Access Gateway.
D：Wi-Fi接続の適応層の終点は、マルチアクセスゲートウェイにあります。
U: The convergence-layer endpoint resides in the client.
U：コンバージェンスレイヤエンドポイントはクライアントにあります。
S: The convergence-layer endpoint resides in the Multi-Access Gateway.
■：収束層のエンドポイントはマルチアクセスゲートウェイにあります。
For example, per-packet aggregation allows a single IP flow to use the combined bandwidth of the two connections. In another example, packets lost due to a temporary link outage may be retransmitted. Moreover, packets may be duplicated over multiple connections to achieve high reliability and low latency, where duplicated packets are eliminated by the receiving side. Such multi-access optimization requires additional control information, e.g., a sequence number, in each packet, which can be supported by the GMA encapsulation protocol described in this document.
たとえば、パケットごとの集約により、単一のIPフローが2つの接続の組み合わされた帯域幅を使用できます。別の例では、一時的なリンク停止のために失われたパケットは再送信されてもよい。さらに、パケットは、複数の接続にわたって複製されて、複製されたパケットが受信側によって除去される、高い信頼性および低い待ち時間を達成するために、パケットを複製することができる。そのようなマルチアクセス最適化は、各パケットにおいて、追加の制御情報、例えばシーケンス番号を必要とし、これはこの文書に記載されているGMAカプセル化プロトコルによってサポートされ得る。
The GMA protocol described in this document is designed for multiple connections, but it may also be used when there is only one connection between two endpoints. For example, it may be used for loss detection and recovery. In another example, it may be used to concatenate multiple small packets and reduce per-packet overhead.
この文書に記載されているGMAプロトコルは、複数の接続用に設計されていますが、2つのエンドポイント間に1つの接続しかない場合にも使用できます。例えば、損失検出および回復に使用することができる。別の例では、それは複数の小さなパケットを連結し、パケットごとのオーバーヘッドを減らすために使用され得る。
The GMA encapsulation protocol supports the following three methods:
GMAカプセル化プロトコルは、以下の3つの方法をサポートしています。
* Trailer-based IP Encapsulation (Section 4.1)
* トレーラーベースのIPカプセル化（セクション4.1）
* Header-based IP Encapsulation (Section 4.2)
* ヘッダベースのIPカプセル化（セクション4.2）
* Header-based non-IP Encapsulation (Section 4.3)
* ヘッダーベースの非IPカプセル化（セクション4.3）
Non-IP encapsulation MUST be used if the original IP packet is IPv6.
元のIPパケットがIPv6の場合は、非IPカプセル化を使用する必要があります。
Trailer-based IP encapsulation MUST be used if it is supported by GMA endpoints and the original IP packet is IPv4.
GMAエンドポイントでサポートされていて元のIPパケットがIPv4でサポートされている場合は、トレーラーベースのIPカプセル化を使用する必要があります。
Header-based encapsulation MUST be used if the trailer-based method is not supported by either the client or Multi-Access Gateway. In this case, if the adaptation layer, e.g., UDP tunneling, supports non-IP packet format, non-IP encapsulation MUST be used; otherwise, header-based IP encapsulation MUST be used.
トレーラベースのメソッドがクライアントまたはマルチアクセスゲートウェイのいずれかでサポートされていない場合は、ヘッダーベースのカプセル化を使用する必要があります。この場合、適応層、例えばUDPトンネリングが非IPパケットフォーマットをサポートする場合、非IPカプセル化を使用する必要があります。それ以外の場合は、ヘッダーベースのIPカプセル化を使用する必要があります。
If non-IP encapsulation is configured, a GMA header MUST be present in every packet. In comparison, if IP encapsulation is configured, a GMA header or trailer may be added dynamically on a per-packet basis, and it indicates the presence of a GMA header (or trailer) to set the protocol type of the GMA PDU to "114" (see Section 4.4).
IP以外のカプセル化が設定されている場合は、すべてのパケットにGMAヘッダーが存在しなければなりません。対照的に、IPカプセル化が構成されている場合、GMAヘッダまたはトレーラはパケットごとに動的に追加され、GMA PDUのプロトコルタイプを設定するためのGMAヘッダ（またはトレーラ）の存在を示す。（4.4節を参照）。
The GMA endpoints MAY configure the GMA encapsulation method through control signaling or pre-configuration. For example, the "MX UP Setup Configuration Request" message as specified in Multi-Access Management Service [MAMS] includes "MX Convergence Method Parameters", which provides the list of parameters to configure the convergence layer, and can be extended to indicate the GMA encapsulation method.
GMAエンドポイントは、制御シグナリングまたはプリコンフィギュレーションを介してGMAカプセル化方法を構成することができる。たとえば、マルチアクセス管理サービス[MAMS]で指定されている「MXアップセットアップ設定要求」メッセージは、「MX収束方法パラメータ」を含み、これはコンバージェンスレイヤを構成するためのパラメータのリストを提供し、それを示すように拡張することができる。GMAカプセル化方法
GMA endpoint MUST discard a received packet and MAY log an error to report the situation (although such error logging MUST be subject to rate limits) under any of the following conditions:
GMAエンドポイントは受信したパケットを破棄し、次のいずれかの条件の下で、状況を報告するためのエラーを記録することがあります（ただし、このようなエラーログはレート制限の対象となる必要があります）。
* The GMA version number in the GMA header (or trailer) is not understood or supported by the GMA endpoint.
* GMAヘッダ（またはトレーラ）のGMAバージョン番号は、GMAエンドポイントによって理解されていないかサポートされていません。
* A flag bit in the GMA header (or trailer) not understood or supported by the GMA endpoint is set to "1".
* GMAエンドポイントによって理解されていない、またはGMAエンドポイントによってサポートされていないGMAヘッダ（またはトレーラ）のフラグビットは「1」に設定されている。
|<---------------------GMA PDU ----------------------->|
+------------------------------------------------------+
| IP hdr | IP payload | GMA Trailer |
+------------------------------------------------------+
|<------- GMA SDU (user payload)-------->|
Figure 3: GMA PDU Format with Trailer-based IP Encapsulation
図3：トレーラベースのIPカプセル化を備えたGMA PDUフォーマット
This method SHALL NOT be used if the original IP packet (GMA service data unit (GMA SDU)) is IPv6.
元のIPパケット（GMAサービスデータユニット（GMA SDU））がIPv6の場合、この方法は使用してはならない。
Figure 3 shows the trailer-based IP encapsulation GMA protocol data unit (GMA PDU) format. A (GMA) PDU may carry one or multiple IP packets, aka (GMA) SDUs, in the payload, or a fragment of the SDU.
図3は、トレーラベースのIPカプセル化GMAプロトコルデータユニット（GMA PDU）フォーマットを示しています。（GMA）PDUは、ペイロード内の1つまたは複数のIPパケット、AKA（GMA）SDU、またはSDUのフラグメントを搬送することができる。
The protocol type field in the IP header of the GMA PDU MUST be changed to 114 (Any 0-Hop Protocol) (see Section 4.4) to indicate the presence of the GMA trailer.
GMA PDUのIPヘッダーの[プロトコルタイプ]フィールドは、GMAトレーラーの存在を示すために114（任意の0ホッププロトコル）に変更する必要があります（セクション4.4を参照）。
The following three IP header fields MUST be changed:
次の3つのIPヘッダーフィールドを変更する必要があります。
IP Length: Add the length of "GMA Trailer" to the length of the original IP packet.
IP長：元のIPパケットの長さに "GMA Trailer"の長さを追加します。
Time To Live (TTL): Set to "1".
ライブ（TTL）： "1"に設定します。
IP checksum: Recalculate after changing "protocol type", "TTL", and "IP Length".
IPチェックサム：「プロトコルタイプ」、「TTL」、「IP LENGE」を変更した後に再計算します。
The GMA (Generic Multi-Access) trailer MUST consist of two mandatory fields (the last 3 bytes): Next Header and Flags.
GMA（Generic Multi-Access）トレーラーは、2つの必須フィールド（最後の3バイト）からなる必要があります。次のヘッダーとフラグ。
This is defined as follows:
これは次のように定義されています。
Next Header (1 byte): This is the IP protocol type of the (first) SDU in a PDU; it stores the value before it was overwritten to 114.
次のヘッダー（1バイト）：PDUの（最初の）SDUのIPプロトコルタイプです。114に上書きされる前に値を格納します。
Flags (2 bytes): Bit 0 is the most significant bit (MSB), and bit 15 is the least significant bit (LSB).
フラグ（2バイト）：ビット0は最上位ビット（MSB）、ビット15は最下位ビット（LSB）です。
Checksum Present (bit 0): If the Checksum Present bit is set to 1, then the Checksum field is present.
チェックサムが存在する（ビット0）：チェックサム現在のビットが1に設定されている場合、チェックサムフィールドが存在します。
Concatenation Present (bit 1): If the Concatenation Present bit is set to 1, then the PDU carries multiple SDUs, and the First SDU Length field is present.
連結存在（ビット1）：連結現在のビットが1に設定されている場合、PDUは複数のSDUを搬送し、最初のSDU長フィールドが存在する。
Connection ID Present (bit 2): If the Connection ID Present bit is set to 1, then the Connection ID field is present.
接続ID（ビット2）：接続ID現在のビットが1に設定されている場合、接続IDフィールドが存在します。
Flow ID Present (bit 3): If the Flow ID Present bit is set to 1, then the Flow ID field is present.
フローID存在する（ビット3）：フローID現在のビットが1に設定されている場合、フローIDフィールドが存在する。
Fragmentation Present (bit 4): If the Fragmentation Present bit is set to 1, then the PDU carry a fragment of the SDU and the Fragmentation Control field is present.
断片化存在（ビット4）：フラグメンテーション現在ビットが1に設定されている場合、PDUはSDUのフラグメントを搬送し、フラグメンテーション制御フィールドが存在する。
Delivery SN Present (bit 5): If the Delivery SN (Sequence Number) Present bit is set to 1, then the Delivery SN field is present and contains the valid information.
Delivery SN（ビット5）：Delivery SN（シーケンス番号）現在のビットが1に設定されている場合、Delivery SNフィールドが存在し、有効な情報が含まれます。
Flow SN Present (bit 6): If the Flow SN Present bit is set to 1, then the Sequence Number field is present.
フローSN存在（ビット6）：フローSN現在ビットが1に設定されている場合、シーケンス番号フィールドが存在する。
Timestamp Present (bit 7): If the Timestamp Present bit is set to 1, then the Timestamp field is present.
TimesTamp現在（ビット7）：タイムスタンプ現在ビットが1に設定されている場合、TIMESTAMPフィールドが存在します。
TTL Present (bit 8): If the TTL Present bit is set to 1, then the TTL field is present.
ttl存在する（ビット8）：TTL現在のビットが1に設定されている場合、TTLフィールドが存在します。
Reserved (bit 9-12): This is set to "0" and ignored on receipt.
予約済み（ビット9-12）：これは "0"に設定され、受信時に無視されます。
Version (bit 13~15): This is the GMA version number; it is set to 0 for the GMA encapsulation protocol specified in this document.
バージョン（ビット13~15）：これはGMAバージョン番号です。この文書で指定されているGMAカプセル化プロトコルには0に設定されています。
The Flags field is at the end of the PDU, and the Next Header field is the second last. The receiver SHOULD first decode the Flags field to determine the length of the GMA trailer and then decode each optional field accordingly. The Generic Multi-Access (GMA) trailer MAY consist of the following optional fields:
FlagsフィールドはPDUの終わりにあり、次のヘッダーフィールドは2番目の最後です。受信機は、最初にFlagsフィールドを復号してGMAトレーラの長さを決定し、それに応じて各オプションフィールドを復号する必要があります。一般的なマルチアクセス（GMA）トレーラーは、次のオプションフィールドで構成されています。
Checksum (1 byte): This contains the (one's complement) checksum sum of all 8 bits in the trailer. For purposes of computing the checksum, the value of the Checksum field is zero. This field is present only if the Checksum Present bit is set to 1.
チェックサム（1バイト）：これには、トレーラーのすべての8ビットの（自分の補数）チェックサム和が含まれています。チェックサムを計算する目的で、チェックサムフィールドの値はゼロです。このフィールドは、チェックサム現在のビットが1に設定されている場合にのみ存在します。
First SDU Length (2 bytes): This is the length of the first IP packet in the PDU, only included if a PDU contains multiple IP packets. This field is present only if the Concatenation Present bit is set to 1.
最初のSDU長さ（2バイト）：これはPDU内の最初のIPパケットの長さです.PDUに複数のIPパケットが含まれている場合にのみ含まれています。このフィールドは、連結現在のビットが1に設定されている場合にのみ存在します。
Connection ID (1 byte): This contains an unsigned integer to identify the anchor and delivery connection of the GMA PDU. This field is present only if the Connection ID Present bit is set to 1.
接続ID（1バイト）：これには、GMA PDUのアンカーと配信接続を識別するための符号なし整数が含まれています。このフィールドは、接続ID現在のビットが1に設定されている場合にのみ存在します。
Anchor Connection ID (MSB 4 bits): This contains an unsigned integer to identify the anchor connection.
アンカー接続ID（MSB 4ビット）：これにはアンカー接続を識別するための符号なし整数が含まれています。
Delivery Connection ID (LSB 4 bits): This contains an unsigned integer to identify the delivery connection.
配信接続ID（LSB 4ビット）：これには配信接続を識別するための符号なし整数が含まれています。
Flow ID (1 byte): This contains an unsigned integer to identify the IP flow that a PDU belongs to, for example Data Radio Bearer (DRB) ID [LWIPEP] for a cellular (e.g., LTE) connection. This field is present only if the Flow ID Present bit is set to 1.
フローID（1バイト）：これには、PDUが属するIPフロー（例えば、LTE）接続のためのデータ無線ベアラ（DRB）ID [LWIPEP]に属するIPフローを識別するための符号なし整数が含まれています。このフィールドは、フローID現在のビットが1に設定されている場合にのみ存在します。
Fragmentation Control (FC) (1 byte): This provides necessary information for reassembly, only needed if a PDU carries fragments. This field is present only if the Fragmentation Present bit is set to 1. Please refer to Section 5 for its detailed format and usage.
フラグメンテーションコントロール（FC）（1バイト）：PDUがフラグメントを搭載している場合にのみ、再組み立てに必要な情報を提供します。このフィールドは、フラグメンテーション現在のビットが1に設定されている場合にのみ存在します。詳細フォーマットと使用方法については、セクション5を参照してください。
Delivery SN (1 byte): This contains an auto-incremented integer to indicate the GMA PDU transmission order on a delivery connection. Delivery SN is needed to measure packet loss of each delivery connection and therefore generated per delivery connection per flow. This field is present only if the Delivery SN Present bit is set to 1.
Delivery SN（1バイト）：これには、配信接続にGMA PDUの送信順序を示すための自動インクリメント整数が含まれています。各配信接続のパケット損失を測定するためには、Delivery SNが必要であり、したがってフローごとに配信接続ごとに生成されます。このフィールドは、Delivery SN現在のビットが1に設定されている場合にのみ存在します。
Flow SN (3 bytes): This contains an auto-incremented integer to indicate the GMA SDU (IP packet) order of a flow. Flow SN is needed for retransmission, reordering, and fragmentation. It SHALL be generated per flow. This field is present only if the Flow SN Present bit is set to 1.
フローSN（3バイト）：これには、フローのGMA SDU（IPパケット）順序を示す自動インクリメント整数が含まれています。フローSNは、再送、並べ替え、および断片化に必要です。それは流れ当たりに生成されなければならない。このフィールドは、フローSN現在のビットが1に設定されている場合にのみ存在します。
Timestamp (4 bytes): This contains the current value of the timestamp clock of the transmitter in the unit of 1 millisecond. This field is present only if the Timestamp Present bit is set to 1.
timestamp（4バイト）：これには、1ミリ秒単位の送信機のタイムスタンプクロックの現在の値が含まれています。このフィールドは、タイムスタンプ現在ビットが1に設定されている場合にのみ存在します。
TTL (1 byte): This contains the TTL value of the original IP header if the GMA SDU is IPv4, or the Hop-Limit value of the IP header if the GMA SDU is IPv6. This field is present only if the TTL Present bit is set to 1.
TTL（1バイト）：GMA SDUがIPv4の場合は、元のIPヘッダーのTTL値、またはGMA SDUがIPv6の場合はIPヘッダーのHOP制限値が含まれています。このフィールドは、TTL現在のビットが1に設定されている場合にのみ存在します。
Figure 4 shows the GMA trailer format with all the fields present, and the order of the GMA control fields SHALL follow the bit order in the Flags field. Note that the bits in the Flags field are ordered with the first bit transmitted being bit 0 (MSB). All fields are transmitted in regular network byte order and appear in reverse order to their corresponding flag bits. If a flag bit is clear, the corresponding optional field is absent.
図4は、すべてのフィールドが存在するすべてのフィールドを持つGMAトレーラーフォーマットを示し、GMAコントロールフィールドの順序はFLAGSフィールドのビット順に従わなければならない。フラグフィールドのビットは、ビット0（MSB）である最初のビットが送信された状態で順序付けされていることに注意してください。すべてのフィールドは通常のネットワークバイト順で送信され、対応するフラグビットに逆の順序で表示されます。フラグビットがクリアされている場合、対応するオプションフィールドは不在です。
For example, bit 0 (the MSB) of the Flags field is the Checksum Present bit, and the Checksum field is the last in the trailer with the exception of the two mandatory fields. Bit 1 is the Concatenation Present bit, and the FSL field is the second last.
たとえば、Flagsフィールドのビット0（MSB）はチェックサム現在のビットであり、チェックサムフィールドは2つの必須フィールドを除いてトレーラーの最後のものです。ビット1は連結現在のビットで、FSLフィールドは2番目の最後です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL | Timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow SN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery SN | FC | Flow ID | Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First SDU Length (FSL) | Checksum | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: GMA Trailer Format with All Optional Fields Present
図4：すべてのオプションフィールドが存在するGMAトレーラーフォーマット
This method SHALL NOT be used if the original IP packet (GMA SDU) is IPv6.
元のIPパケット（GMA SDU）がIPv6の場合、この方法は使用してはならない。
Figure 5 shows the header-based IP encapsulation format. Here, the GMA header is inserted right after the IP header of the GMA SDU, and the IP header fields of the GMA PDU MUST be changed the same way as in trailer-based IP encapsulation.
図5は、ヘッダベースのIPカプセル化フォーマットを示しています。ここでは、GMA SDUのIPヘッダの直後にGMAヘッダが挿入され、GMA PDUのIPヘッダフィールドをトレーラベースのIPカプセル化と同様に変更する必要がある。
+-----------------------------------------------+
|IP hdr | GMA Header | IP payload |
+-----------------------------------------------+
Figure 5: GMA PDU Format with Header-Based IP Encapsulation
図5：ヘッダベースのIPカプセル化を用いたGMA PDUフォーマット
Figure 6 shows the GMA header format. In comparison to the GMA trailer, the only difference is that the Flags field is now in the front so that the receiver can first decode the Flags field to determine the GMA header length.
図6にGMAヘッダフォーマットを示します。GMAトレーラと比較して、唯一の違いはFLAGSフィールドが正面にあり、受信機が最初にFLAGSフィールドを復号することができ、GMAヘッダーの長さを決定することができることです。
The "TTL" field MUST be included and the "TTL" bit in the GMA header (or Trailer) MUST be set to 1 if (trailer- or header-based) IP encapsulation is used.
「TTL」フィールドを含める必要があり、GMAヘッダー（またはトレーラー）の「TTL」ビットを1 IF（TrailerまたはHeader-Based）のIPカプセル化を使用する必要があります。
+------------------------------------------------------+
| Flags | other fields (TTL, Timestamp, Flow SN, etc.) |
+------------------------------------------------------+
Figure 6: GMA Header Format
図6：GMAヘッダーフォーマット
Figure 7 shows the header-based non-IP encapsulation format. Here, "UDP Tunneling" is configured at the MX adaptation layer. The ports for "UDP Tunneling" at the client are chosen from the Dynamic Port range, and the ports for "UDP Tunneling" at the Multi-Access Gateway are configured and provided to the client through additional control messages, e.g., [MAMS].
図7は、ヘッダベースの非IPカプセル化フォーマットを示しています。ここで、「UDPトンネリング」はMX適応層で構成されている。クライアントでの「UDPトンネリング」のポートは動的ポート範囲から選択され、マルチアクセスゲートウェイの「UDPトンネリング」のポートは、追加の制御メッセージ、例えば[MAMS]を介してクライアントに設定され提供される。
"TTL", "FSL", and "Next Header" are no longer needed and MUST not be included. Moreover, the IP header fields of the GMA SDU remain unchanged.
"ttl"、 "fsl"、および "next header"は不要になり、含めてはいけません。さらに、GMA SDUのIPヘッダフィールドは変化しないままである。
+-------------------------------------------------------------+
| IP hdr | UDP hdr | GMA Header | IP hdr | IP payload |
+-------------------------------------------------------------+
|<------- GMA SDU------------>|
|<------------------- GMA PDU------------>|
Figure 7: GMA PDU Format with Non-IP Encapsulation
図7：IP以外のカプセル化を伴うGMA PDUフォーマット
As described in Section 4.1, IP-encapsulated GMA PDUs are indicated using the IP protocol type 114. This is designated and recorded by IANA [IANA] to indicate "any 0-Hop Protocol". No reference is given in the IANA registry for the definition of this protocol type, and IANA has no record of why the assignment was made or how it is used, although it was probably assigned before 1999 [IANA1999].
セクション4.1で説明されているように、IPカプセル化GMA PDUはIPプロトコルタイプ114を使用して示されている。これは、「任意の0ホッププロトコル」を示すためにIANA [IANA]によって指定され記録される。このプロトコルタイプの定義のためのIANAレジストリには参照はありません.IANAは、割り当てが行われた理由やそれがどのように使用されているのかの記録はありませんが、1999年以前に割り当てられました[IANA1999]。
There is some risk associated with "reusing" protocol type 114 because there may be implementations of other protocols also using this protocol type. However, because the protocol described in this document is used only between adjacent devices specifically configured for this purpose, the use of protocol type 114 should be safe.
このプロトコルタイプを使用して他のプロトコルの実装形態がある可能性があるため、プロトコルタイプ114が「再利用する」プロトコルタイプ114に関連するいくつかのリスクがある。しかしながら、この文書に記載されているプロトコルは、この目的のために特別に構成された隣接する装置間でのみ使用されるので、プロトコルタイプ114の使用は安全であるべきである。
As described in Section 1.1, one of the purposes of the experiment described in this document is to verify the safety of using this protocol type. Deployments should be aware of the risk of a clash with other uses of this protocol type.
セクション1.1に記載されているように、この文書に記載されている実験の目的の1つは、このプロトコルタイプの使用の安全性を検証することです。展開は、このプロトコルタイプの他の用途との衝突の危険性を認識する必要があります。
If the MTU size of the anchor connection (for GMA SDU) is configured such that the corresponding GMA PDU length adding the GMA header (or trailer) and other overhead (UDP tunneling) MAY exceed the MTU of a delivery connection, GMA endpoints MUST be configured to support fragmentation through additional control messages [MAMS].
アンカー接続のMTUサイズ（GMA SDU）が、GMAヘッダ（またはトレーラ）および他のオーバーヘッド（UDPトンネリング）を追加する（またはUDPトンネリング）のMTUを超える可能性があるように構成されている場合、GMAエンドポイントは追加のコントロールメッセージ[MAMS]を介して断片化をサポートするように構成されています。
The fragmentation procedure at the convergence sublayer is similar to IP fragmentation [RFC0791] in principle, but with the following two differences for less overhead:
収束サブレイヤの断片化手順は、原則としてIPフラグメンテーション[RFC0791]と似ていますが、次の2つの違いが少ないと次のものがあります。
* The fragment offset field is expressed in number of fragments.
* フラグメントオフセットフィールドはフラグメントの数で表されます。
* The maximum number of fragments per SDU is 2^7 (=128).
* SDUあたりの最大フラグメント数は2 ^ 7（= 128）です。
The Fragmentation Control (FC) field in the GMA trailer (or header) contains the following bits:
GMAトレーラ（またはヘッダ）のフラグメンテーションコントロール（FC）フィールドには、次のビットが含まれています。
Bit 7: a More Fragment (MF) flag to indicate if the fragment is the last one (0) or not (1)
ビット7：フラグメントが最後のものであるかどうかを示すためのより多くのフラグメント（MF）フラグ（1）
Bit 0-6: Fragment Offset (in units of fragments) to specify the offset of a particular fragment relative to the beginning of the SDU
ビット0~6：SDUの先頭に対する特定のフラグメントのオフセットを指定するためのフラグメントオフセット（フラグメント単位）
A PDU carries a whole SDU without fragmentation if the FC field is set to all "0"s or the FC field is not present in the trailer. Otherwise, the PDU contains a fragment of the SDU.
FCフィールドがすべての「0」に設定されている場合、またはFCフィールドがトレーラに存在しない場合、PDUは断片化なしでSDU全体を搬送します。それ以外の場合、PDUにはSDUのフラグメントが含まれています。
The Flow SN field in the trailer is used to distinguish the fragments of one SDU from those of another. The Fragment Offset (FO) field tells the receiver the position of a fragment in the original SDU. The More Fragment (MF) flag indicates the last fragment.
トレーラ内のフローSNフィールドは、あるSDUのフラグメントを他のSDUのフラグメントを区別するために使用されます。フラグメントオフセット（FO）フィールドは、レシーバに元のSDU内のフラグメントの位置を伝えます。より多くのフラグメント（MF）フラグは最後のフラグメントを示します。
To fragment a long SDU, the transmitter creates n PDUs and copies the content of the IP header fields from the long PDU into the IP header of all the PDUs. The length field in the IP header of the PDU SHOULD be changed to the length of the PDU, and the protocol type SHOULD be changed to 114.
長いSDUをフラグメント化するために、送信機はN PDUを作成し、LONG PDUからのIPヘッダフィールドの内容をすべてのPDUのIPヘッダにコピーする。PDUのIPヘッダーの長さフィールドはPDUの長さに変更され、プロトコルタイプは114に変更する必要があります。
The data of the long SDU is divided into n portions based on the MTU size of the delivery connection. The first portion of the data is placed in the first PDU. The MF flag is set to "1", and the FO field is set to "0". The i-th portion of the data is placed in the i-th PDU. The MF flag is set to "0" if it is the last fragment and set to "1" otherwise. The FO field is set to i-1.
長さSDUのデータは、配信接続のMTUサイズに基づいてn個の部分に分割されている。データの最初の部分は最初のPDUに配置されます。MFフラグは "1"に設定され、FOフィールドは "0"に設定されています。データのi番目の部分は、i番目のPDUに配置されている。最後のフラグメントであればMFフラグは "0"に設定され、それ以外の場合は "1"に設定されます。FOフィールドはI - 1に設定されている。
To assemble the fragments of an SDU, the receiver combines PDUs that all have the same Flow SN. The combination is done by placing the data portion of each fragment in the relative order indicated by the Fragment Offset in that fragment's GMA trailer (or header). The first fragment will have the Fragment Offset set to "0", and the last fragment will have the More Fragment flag set to "0".
SDUのフラグメントを組み立てるために、受信機はすべて同じフローSNを持つPDUを組み合わせます。組み合わせは、そのフラグメントのGMAトレーラ（またはヘッダー）内のフラグメントオフセットによって示される相対順序で各フラグメントのデータ部分を配置することによって行われます。最初のフラグメントはフラグメントオフセットを "0"に設定され、最後のフラグメントにはフラグメントフラグが "0"に設定されます。
GMA fragmentation operates above the IP layer of individual access connection (Wi-Fi, LTE) and between the two endpoints of convergence layer. The convergence layer endpoints (client, Multi-access Gateway) SHOULD obtain the MTU of individual connection through either manual configuration or implementing Path MTU Discovery (PMTUD) as suggested in [RFC8900].
GMAフラグメンテーションは、個々のアクセス接続（Wi - Fi、LTE）のIP層と収束層の2つのエンドポイントの間で動作します。コンバージェンスレイヤエンドポイント（クライアント、マルチアクセスゲートウェイ）は、[RFC8900]で示唆されているように、手動構成またはパスMTUディスカバリの実装（PMTUD）を介して個々の接続のMTUを取得する必要があります。
The convergence sublayer MAY support concatenation if a delivery connection has a larger maximum transmission unit (MTU) than the original IP packet (SDU). Only the SDUs with the same client IP address and the same Flow ID MAY be concatenated.
配信接続が元のIPパケット（SDU）よりも大きい最大伝送ユニット（MTU）を有する場合、収束副層は連結をサポートすることができる。同じクライアントIPアドレスと同じフローIDを持つSDUのみが連結されている可能性があります。
If the (trailer- or header-based) IP encapsulation method is used, the First SDU Length (FSL) field SHOULD be included in the GMA trailer (or header) to indicate the length of the first SDU. Otherwise, the FSL field SHOULD not be included.
（予告編またはヘッダーベース）のIPカプセル化方法が使用されている場合は、最初のSDUの長さを示すために、最初のSDU長（FSL）フィールドをGMAトレーラ（またはヘッダー）に含める必要があります。それ以外の場合は、FSLフィールドを含めるべきではありません。
+-----------------------------------------------------------+
|IP hdr| IP payload |IP hdr| IP payload | GMA Trailer |
+-----------------------------------------------------------+
Figure 8: Example of GMA PDU Format with Concatenation and Trailer-Based IP Encapsulation
図8：連結とトレーラベースのIPカプセル化を備えたGMA PDUフォーマットの例
To concatenate two or more SDUs, the transmitter creates one PDU and copies the content of the IP header field from the first SDU into the IP header of the PDU. The data of the first SDU is placed in the first portion of the data of the PDU. The whole second SDU is then placed in the second portion of the data of the PDU (Figure 8). The procedure continues until the PDU size reaches the MTU of the delivery connection. If the FSL field is present, the IP Length field of the PDU SHOULD be updated to include all concatenated SDUs and the trailer (or header), and the IP checksum field SHOULD be recalculated if the packet is IPv4.
2つ以上のSDUを連結するために、送信機は1つのPDUを作成し、IPヘッダフィールドの内容を最初のSDUからPDUのIPヘッダにコピーする。第1のSDUのデータは、PDUのデータの第1部分に配置される。次に、第2のSDU全体をPDUのデータの第2の部分に配置する（図8）。PDUサイズが配信接続のMTUに達するまで手順は続行されます。FSLフィールドが存在する場合は、PDUのIP長フィールドをすべての連結SDUとトレーラー（またはヘッダー）を含めるように更新する必要があり、パケットがIPv4の場合はIPチェックサムフィールドを再計算する必要があります。
To disaggregate a PDU, if the (header- or trailer-based) IP encapsulation method is used, the receiver first obtains the length of the first SDU from the FSL field and decodes the first SDU. The receiver then obtains the length of the second SDU based on the length field in the second SDU IP header and decodes the second SDU. The procedure continues until no byte is left in the PDU. If the non-IP encapsulation method (Figure 7) is used, the IP header of the first SDU will not change during the encapsulation process, and the receiver SHOULD obtain the length of the first SDU directly from its IP header (Figure 9).
PDUを分解するために、（ヘッダ - またはトレーラベース）IPカプセル化方法が使用されている場合、受信機は最初にFSLフィールドから最初のSDUの長さを取得し、最初のSDUをデコードする。そして、受信機は、第2のSDU IPヘッダ内の長さフィールドに基づいて第2のSDUの長さを取得し、第2のSDUを復号する。手順はPDUにバイトが残っていないまで続行されます。非IPカプセル化方法（図7）が使用されている場合、最初のSDUのIPヘッダーはカプセル化プロセス中に変更されず、受信側はIPヘッダーから直接最初のSDUの長さを取得する必要があります（図9）。
|<-------1st GMA SDU------------
+---------------------------------------------------------------+
| IP hdr | UDP hdr | GMA Header | IP hdr | IP payload |
+---------------------------------------------------------------+
| IP hdr | IP payload |
+-------------------------------------------+
-------->|<-------2nd GMA SDU--------------->
Figure 9: Example of GMA PDU Format with Concatenation and Header-Based Non-IP (UDP) Encapsulation
図9：連結とヘッダベースの非IP（UDP）カプセル化を備えたGMA PDUフォーマットの例
If a PDU contains multiple SDUs, the Flow SN field is for the last SDU, and the Flow SN of other SDUs carried by the same PDU can be obtained according to its order in the PDU. For example, if the SN field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5, and 6 for the first, second, and last SDU, respectively.
PDUに複数のSDUが含まれている場合、フローSNフィールドは最後のSDU用であり、PDUの順序に従って同じPDUによって運ばれる他のSDUのフローSNを得ることができる。例えば、SNフィールドが6で、PDUが3 SDU（IPパケット）を含む場合、SNはそれぞれ4,5、および6、および最後のSDUである。
GMA concatenation can be used for packing small packets of a single application, e.g., TCP ACKs, or from multiple applications. Notice that a single GMA flow may carry multiple application flows (TCP, UDP, etc.).
GMA連結は、単一のアプリケーション、例えばTCP ACK、または複数のアプリケーションから小さなパケットをパッキングするために使用できます。単一のGMAフローが複数のアプリケーションフロー（TCP、UDPなど）を運ぶことができることに注意してください。
GMA endpoints MUST NOT perform concatenation and fragmentation in a single PDU. If a GMA PDU carries a fragmented SDU, it MUST NOT carry any other (fragmented or whole) SDU.
GMAエンドポイントは、単一のPDUで連結と断片化を実行してはいけません。GMA PDUが断片化されたSDUを運ぶ場合、それは他の（断片化または全体）SDUを運ぶべきではありません。
Security in a network using GMA should be relatively similar to security in a normal IP network. GMA is unaware of IP- or higher-layer end-to-end security as it carries the IP packets as opaque payload. Deployers are encouraged to not consider that GMA adds any form of security and to continue to use IP- or higher-layer security as well as link-layer security.
GMAを使用するネットワーク内のセキュリティは、通常のIPネットワークのセキュリティと比較的似ているはずです。IPパケットを不透明なペイロードとして運ぶため、GMAはIPまたは上位のエンドツーエンドセキュリティを認識していません。デプロイヤは、GMAがセキュリティの形式を追加し、IPまたは上位のセキュリティとリンクレイヤのセキュリティを引き続き使用することを考慮しています。
The GMA protocol at the convergence sublayer is a 0-hop protocol and relies on the security of the underlying network transport paths. When this cannot be assumed, appropriate security protocols (IPsec, DTLS, etc.) SHOULD be configured at the adaptation sublayer. On the other hand, packet filtering requires either that a firewall looks inside the GMA packet or that the filtering is done on the GMA endpoints. In those environments in which this is considered to be a security issue, it may be desirable to terminate the GMA operation at the firewall.
コンバージェンスサブレイヤのGMAプロトコルは0ホッププロトコルであり、基礎となるネットワークトランスポートパスのセキュリティに依存しています。これを想定できない場合は、適切なセキュリティプロトコル（IPSec、DTLSなど）を適応型サブレイヤで設定する必要があります。一方、パケットフィルタリングは、ファイアウォールがGMAパケットの内側に見えるか、またはGMAエンドポイントでフィルタリングが行われることを必要とする。これがセキュリティ上の問題であると考えられる環境では、ファイアウォールでのGMA操作を終了することが望ましい場合があります。
Local-only packet leak prevention (HL=0, TTL=1) SHOULD be on preventing the leak of the local-only GMA PDUs outside the "local domain" to the Internet or to another domain that could use the same IP protocol type, i.e., 114.
ローカル専用パケットリーク防止（HL = 0、TTL = 1）は、「ローカルドメイン」の外部のローカルオンリーGMA PDUのリークをインターネットまたは同じIPプロトコルタイプを使用できる別のドメインのリークを防ぐ必要があります。IE、114。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[GRE1] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.
[GRE1] DOMMYTY、G、「GREおよびシーケンス番号拡張」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<https：//www.rfc-editor.org/info/rfc2890>。
[GRE2] Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and M. Cullen, "Huawei's GRE Tunnel Bonding Protocol", RFC 8157, DOI 10.17487/RFC8157, May 2017, <https://www.rfc-editor.org/info/rfc8157>.
[GRE2] Leymann、N.、Heidemann、C.、Zhang、M.、Sarikaya、B.およびM.Cullen、「HuaweiのGREトンネルボンディングプロトコル」、RFC 8157、DOI 10.17487 / RFC8157、2017年5月、<https：//www.rfc-editor.org/info/rfc8157>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[ATSSS] 3GPP, "Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture", Release 16, 3GPP TR 23.793, December 2018, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3254>.
[ATSSS] 3GPP、「5Gシステム（5GS）アーキテクチャ」、リリース16,3GPP TR 23.793、2018年12月、<https://portal.3gpp.org/desktopModules/Specifications/ specificationDetails.aspx？specationId = 3254>。
[GCC] Holmer, S., Lundin, H., Carlucci, G., De Cicco, L., and S. Mascolo, "A Google Congestion Control Algorithm for Real-Time Communication", Work in Progress, Internet-Draft, draft-ietf-rmcat-gcc-02, 8 July 2016, <https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02>.
[GCC] Holmer、S.、Lundin、H.、Carlucci、G.、De Cicco、L.、およびS. Mascolo、「リアルタイム通信のためのGoogle Comgention Controlアルゴリズム」、進行中の作業、インターネットドラフト、draft-ietf-rmcat-gcc-02,2016、<https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02>。
[GMAC] Zhu, J. and M. Zhang, "UDP-based Generic Multi-Access (GMA) Control Protocol", Work in Progress, Internet-Draft, draft-zhu-intarea-gma-control-00, 13 October 2021, <https://datatracker.ietf.org/doc/html/draft-zhu-intarea-gma-control-00>.
[GMAC] Zhu、J.およびM. Zhang、「UDPベースの一般的なマルチアクセス（GMA）制御プロトコル」、進行中の作業、インターネットドラフト、ドラフト - Zhu-Intarea-GMA-Control-00,2021、<https://datatracker.ietf.org/doc/html/draft-zhu-intarea-gma-control-00>
[IANA] IANA, "Protocol Numbers", <https://www.iana.org/assignments/protocol-numbers>.
[IANA] IANA、「プロトコル番号」、<https：//www.iana.org/ashignments/protocol-numbers>。
[IANA1999] IANA, Wayback Machine archive of "Protocol Numbers", February 1999, <https://web.archive.org/web/19990203044112/ http://www.isi.edu:80/in-notes/iana/assignments/protocol-numbers>.
[IANA1999] IANA、Protect Numbers、1999年2月、<https://web.archive.org/wwb/199902044112/ http://www.isi.edu ::80/in-in-in-in-in-in-notes/iana/割り当て/プロトコル番号>。
[LWIPEP] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec Tunnel (LWIP) encapsulation; Protocol specification", Release 13, 3GPP TS 36.361, July 2020, <https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3037>.
[LWIPEP] 3GPP、「普遍的な地上無線アクセス（E-UTRA）; IPSECトンネル（LWIP）カプセル化を用いたLTE - WLAN無線レベル統合;プロトコル仕様書、リリース13,3GPP TS 36.361、2020年7月、<https：//portal.3gpp.org/desktopModules/Specifications/ SpecificationDetails.aspx？specationId = 3037>。
[MAMS] Kanugovi, S., Baboescu, F., Zhu, J., and S. Seo, "Multiple Access Management Services Multi-Access Management Services (MAMS)", RFC 8743, DOI 10.17487/RFC8743, March 2020, <https://www.rfc-editor.org/info/rfc8743>.
[MAMS] Kanugovi、S.、Baboescu、F.、Zhu、J.、およびS. SEO、「マルチアクセス管理サービスマルチアクセス管理サービス（MAMS）」、RFC 8743、DOI 10.17487 / RFC8743、2020年3月<https://www.rfc-editor.org/info/rfc8743>。
[MPIP] Sun, L., Tian, G., Zhu, G., Liu, Y., Shi, H., and D. Dai, "Multipath IP Routing on End Devices: Motivation, Design, and Performance", 2017, <https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/ MPIP_Tech.pdf>.
[MPIP] Sun、L.、Tian、G.、Zhu、G.、Liu、Y.、Shi、H.、およびD .Dai、「エンドデバイスのマルチパスIPルーティング：モチベーション、デザイン、パフォーマンス」、2017、<https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/ MPIP_TECH.PDF>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel、J.、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https：//www.rfc-editor.org/info/rfc791>。
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, <https://www.rfc-editor.org/info/rfc8900>.
[RFC8900]ボニャ、R。、Baker、F.、Huston、G.、Hinden、R.、Troan、O.、F。、2020年9月、<https：//www.rfc-editor.org/info/rfc8900>。
Authors' Addresses
著者の住所
Jing Zhu Intel
Jing Zhu Intel.
Email: jing.z.zhu@intel.com
Satish Kanugovi Nokia
飽和した香水ノキア
Email: satish.k@nokia.com